draft-ietf-mpls-seamless-mcast-13.txt   draft-ietf-mpls-seamless-mcast-14.txt 
skipping to change at page 1, line 21 skipping to change at page 1, line 21
I. Grosclaude I. Grosclaude
France Telecom France Telecom
N. Leymann N. Leymann
Deutsche Telekom AG Deutsche Telekom AG
S. Saad S. Saad
AT&T AT&T
June 10 2014 June 30 2014
Inter-Area P2MP Segmented LSPs Inter-Area P2MP Segmented LSPs
draft-ietf-mpls-seamless-mcast-13.txt draft-ietf-mpls-seamless-mcast-14.txt
Abstract Abstract
This document describes procedures for building inter-area point-to- This document describes procedures for building inter-area point-to-
multipoint (P2MP) segmented service LSPs by partitioning such LSPs multipoint (P2MP) segmented service LSPs by partitioning such LSPs
into intra-area segments and using BGP as the inter-area routing and into intra-area segments and using BGP as the inter-area routing and
label distribution protocol. Within each IGP area the intra-area label distribution protocol. Within each IGP area the intra-area
segments are either carried over intra-area P2MP LSPs, using P2MP LSP segments are either carried over intra-area P2MP LSPs, using P2MP LSP
hierarchy, or instantiated using ingress replication. The intra-area hierarchy, or instantiated using ingress replication. The intra-area
P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress
skipping to change at page 6, line 52 skipping to change at page 6, line 52
achieved using downstream-assigned labels alone. achieved using downstream-assigned labels alone.
The ingress area segment of a P2MP service LSP is rooted at a PE (or The ingress area segment of a P2MP service LSP is rooted at a PE (or
at an ASBR in the case where the P2MP service LSP spans multiple at an ASBR in the case where the P2MP service LSP spans multiple
ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the ASes). The leaves of this segment are other PEs/ASBRs and ABRs in the
same area as the root PE. same area as the root PE.
The backbone area segment is rooted at an ABR that is connected to The backbone area segment is rooted at an ABR that is connected to
the ingress area (ingress ABR), or at an ASBR if the ASBR is present the ingress area (ingress ABR), or at an ASBR if the ASBR is present
in the backbone area, or at a PE if the PE is present in the backbone in the backbone area, or at a PE if the PE is present in the backbone
area. The backbone area segment has as its leaves ABRs that are area. The backbone area segment has its leaves ABRs that are
connected to the egress area(s) or PEs in the backbone area, or ASBRs connected to the egress area(s) or PEs in the backbone area, or ASBRs
in the backbone area. in the backbone area.
The egress area segment is rooted at an ABR in the egress area The egress area segment is rooted at an ABR in the egress area
(egress ABR), and has as its leaves PEs and ASBR in that egress area (egress ABR), and has its leaves PEs and ASBR in that egress area
(the latter covers the case where the P2MP service LSP spans multiple (the latter covers the case where the P2MP service LSP spans multiple
ASes). Note that for a given P2MP service LSP there may be more than ASes). Note that for a given P2MP service LSP there may be more than
one backbone segment, each rooted at its own ingress ABR, and more one backbone segment, each rooted at its own ingress ABR, and more
than one egress area segment, each rooted at its own egress ABR. than one egress area segment, each rooted at its own egress ABR.
This document uses the term "A-D routes" for "auto-discovery routes". This document uses the term "A-D routes" for "auto-discovery routes".
An implementation that supports this document MUST implement the An implementation that supports this document MUST implement the
procedures described in the following sections to support inter-area procedures described in the following sections to support inter-area
point-to-multipoint (P2MP) segmented service LSPs. point-to-multipoint (P2MP) segmented service LSPs.
skipping to change at page 17, line 26 skipping to change at page 17, line 26
segment then the Leaf A-D route MUST carry a downstream assigned segment then the Leaf A-D route MUST carry a downstream assigned
label in the P-Tunnel Attribute where the P-Tunnel type is set to label in the P-Tunnel Attribute where the P-Tunnel type is set to
Ingress Replication. A PE MUST assign a distinct MPLS label for each Ingress Replication. A PE MUST assign a distinct MPLS label for each
Leaf A-D route originated by the PE. Leaf A-D route originated by the PE.
To constrain distribution of this route, the originating PE To constrain distribution of this route, the originating PE
constructs an IP-based Route Target community by placing the IP constructs an IP-based Route Target community by placing the IP
address of the upstream node in the Global Administrator field of the address of the upstream node in the Global Administrator field of the
community, with the Local Administrator field of this community set community, with the Local Administrator field of this community set
to 0. The originating PE then adds this Route Target Extended to 0. The originating PE then adds this Route Target Extended
Community to this Leaf A-D route. The upstream node's address is as Community to this Leaf A-D route. The upstream node's address is
determined in section 6.1 ("Determining the Upstream ABR/PE/ASBR determined as specified in section 6.1 ("Determining the Upstream
(Upstream Node)"). ABR/PE/ASBR (Upstream Node)").
The PE then advertises this route to the upstream node. The PE then advertises this route to the upstream node.
6.3. PIM-SM in ASM mode for Global Table Multicast 6.3. PIM-SM in ASM mode for Global Table Multicast
This specification allows two options for supporting global table This specification allows two options for supporting global table
multicast with PIM-SM in ASM mode. The first option does not transit multicast with PIM-SM in ASM mode. The first option does not transit
IP multicast shared trees over the MPLS network. The second option IP multicast shared trees over the MPLS network. The second option
does transit shared trees over the MPLS network and relies on shared does transit shared trees over the MPLS network and relies on shared
tree to source tree switchover. tree to source tree switchover.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
network. Therefore, when an (egress) PE creates (*, G) state (as a network. Therefore, when an (egress) PE creates (*, G) state (as a
result of receiving PIM or IGMP messages on one of its IP multicast result of receiving PIM or IGMP messages on one of its IP multicast
interfaces), the PE does not propagate this state using Leaf A-D interfaces), the PE does not propagate this state using Leaf A-D
routes. routes.
6.3.1.1. Originating Source Active A-D Routes 6.3.1.1. Originating Source Active A-D Routes
Whenever as a result of receiving PIM Register or MSDP messages an RP Whenever as a result of receiving PIM Register or MSDP messages an RP
that is co-located with a PE discovers a new multicast source, the that is co-located with a PE discovers a new multicast source, the
RP/PE SHOULD originate a BGP Source Active A-D route. Similarly RP/PE SHOULD originate a BGP Source Active A-D route. Similarly
whenever as a result of receiving MSDP messages a PE, that is not whenever as a result of receiving MSDP messages, a PE that is not
configured as a RP, discovers a new multicast source the PE SHOULD configured as a RP, discovers a new multicast source the PE SHOULD
originate a BGP Source Active A-D route. The BGP Source Active A-D originate a BGP Source Active A-D route. The BGP Source Active A-D
route carries a single MCAST-VPN NLRI constructed as follows: route carries a single MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to 0. + The RD in this NLRI is set to 0.
+ The Multicast Source field MUST be set to S. The Multicast + The Multicast Source field MUST be set to S. The Multicast
Source Length field is set appropriately to reflect this. Source Length field is set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. The Multicast + The Multicast Group field MUST be set to G. The Multicast
skipping to change at page 18, line 42 skipping to change at page 18, line 42
Using the normal BGP procedures the Source Active A-D route is Using the normal BGP procedures the Source Active A-D route is
propagated to all other PEs within the AS. propagated to all other PEs within the AS.
Whenever the RP/PE discovers that the source is no longer active, the Whenever the RP/PE discovers that the source is no longer active, the
RP MUST withdraw the Source Active A-D route, if such a route was RP MUST withdraw the Source Active A-D route, if such a route was
previously advertised by the RP. previously advertised by the RP.
6.3.1.2. Receiving BGP Source Active A-D Route by PE 6.3.1.2. Receiving BGP Source Active A-D Route by PE
When as a result of receiving PIM or IGMP messages on one of its IP When as a result of receiving PIM or IGMP messages on one of its IP
multicast interfaces an (egress) PE creates in its Tree Information multicast interfaces an egress PE creates in its Tree Information
Base (TIB) a new (*, G) entry with a non-empty outgoing interface Base (TIB) a new (*, G) entry with a non-empty outgoing interface
list that contains one or more IP multicast interfaces, the PE MUST list that contains one or more IP multicast interfaces, the PE MUST
check if it has any Source Active A-D routes for that G. If there is check if it has any Source Active A-D routes for that G. If there is
such a route, S of that route is reachable via an MPLS interface, and such a route, S of that route is reachable via an MPLS interface, and
the PE does not have (S, G) state in its TIB for (S, G) carried in the PE does not have (S, G) state in its TIB for (S, G) carried in
the route, then the PE originates a Leaf A-D route carrying that (S, the route, then the PE originates a Leaf A-D route carrying that (S,
G), as specified in section 6.2.2 ("Leaf A-D Route for Global Table G), as specified in section 6.2.2 ("Leaf A-D Route for Global Table
Multicast"). Multicast").
When an (egress) PE receives a new Source Active A-D route, the PE When an egress PE receives a new Source Active A-D route, the PE MUST
MUST check if its TIB contains an (*, G) entry with the same G as check if its TIB contains an (*, G) entry with the same G as carried
carried in the Source Active A-D route. If such an entry is found, S in the Source Active A-D route. If such an entry is found, S is
is reachable via an MPLS interface, and the PE does not have (S, G) reachable via an MPLS interface, and the PE does not have (S, G)
state in its TIB for (S, G) carried in the route, then the PE state in its TIB for (S, G) carried in the route, then the PE
originates a Leaf A-D route carrying that (S, G), as specified in originates a Leaf A-D route carrying that (S, G), as specified in
section 6.2.2 ("Leaf A-D Route for Global Table Multicast"). section 6.2.2 ("Leaf A-D Route for Global Table Multicast").
6.3.1.3. Handling (S, G, rpt) state 6.3.1.3. Handling (S, G, rpt) state
Creation and deletion of (S, G, rpt) state on a PE that resulted from Creation and deletion of (S, G, rpt) state on a PE that resulted from
receiving PIM messages on one of its IP multicast interfaces does not receiving PIM messages on one of its IP multicast interfaces does not
result in any BGP actions by the PE. result in any BGP actions by the PE.
6.3.2. Option 2 6.3.2. Option 2
This option does transit IP multicast shared trees over the MPLS This option does transit IP multicast shared trees over the MPLS
network. Therefore, when an (egress) PE creates (*, G) state (as a network. Therefore, when an egress PE creates (*, G) state (as a
result of receiving PIM or IGMP messages on one of its IP multicast result of receiving PIM or IGMP messages on one of its IP multicast
interfaces), the PE does propagate this state using Leaf A-D routes. interfaces), the PE does propagate this state using Leaf A-D routes.
6.3.2.1. Originating Source Active A-D Routes 6.3.2.1. Originating Source Active A-D Routes
Whenever a PE creates an (S, G) state as a result of receiving Leaf Whenever a PE creates an (S, G) state as a result of receiving Leaf
A-D routes associated with the global table multicast service, if S A-D routes associated with the global table multicast service, if S
is reachable via one of the IP multicast capable interfaces, and the is reachable via one of the IP multicast capable interfaces, and the
PE determines that G is in the PIM-SM in ASM mode range, the PE MUST PE determines that G is in the PIM-SM in ASM mode range, the PE MUST
originate a BGP Source Active A-D route. The route carries a single originate a BGP Source Active A-D route. The route carries a single
skipping to change at page 25, line 32 skipping to change at page 25, line 32
advertising ABR, and the Local Administrator field set to 0. PEs in advertising ABR, and the Local Administrator field set to 0. PEs in
the egress area that participate in the global table multicast will the egress area that participate in the global table multicast will
import this route. import this route.
A PE in the egress area SHOULD join the P2MP LSP advertised in the A PE in the egress area SHOULD join the P2MP LSP advertised in the
PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the PMSI Tunnel attribute of the wildcard S-PMSI A-D route if (a) the
Originating Router's IP Address field in the S-PMSI A-D route has the Originating Router's IP Address field in the S-PMSI A-D route has the
same value as the Ingress PE's IP address in at least one of the Leaf same value as the Ingress PE's IP address in at least one of the Leaf
A-D routes for global table multicast originated by the PE, and (b) A-D routes for global table multicast originated by the PE, and (b)
the upstream ABR for the Ingress PE's IP address in that Leaf A-D the upstream ABR for the Ingress PE's IP address in that Leaf A-D
route is the (egress) ABR that advertises the wildcard S-PMSI A-D route is the egress ABR that advertises the wildcard S-PMSI A-D
route. route.
7.2.3. Global Table Multicast and the Expected Upstream Node 7.2.3. Global Table Multicast and the Expected Upstream Node
If the mapping between the inter-area P2MP service LSP for global If the mapping between the inter-area P2MP service LSP for global
table multicast service and the intra-area P2MP LSP is many-to-one table multicast service and the intra-area P2MP LSP is many-to-one
then an egress PE must be able to determine whether a given multicast then an egress PE must be able to determine whether a given multicast
packet for a particular (S, G) is received from the "expected" packet for a particular (S, G) is received from the "expected"
upstream node. The expected node is the node towards which the Leaf upstream node. The expected node is the node towards which the Leaf
A-D route is sent by the egress PE. Packets received from another A-D route is sent by the egress PE. Packets received from another
skipping to change at page 33, line 10 skipping to change at page 33, line 10
the label stack to include identification of the sender upstream the label stack to include identification of the sender upstream
node. When P2MP LSPs are used this requires that PHP MUST be turned node. When P2MP LSPs are used this requires that PHP MUST be turned
off. When Ingress Replication is used the egress PE knows the off. When Ingress Replication is used the egress PE knows the
incoming downstream assigned label to which it has bound a particular incoming downstream assigned label to which it has bound a particular
(S/*, G) and must accept packets with only that label for that (S/*, (S/*, G) and must accept packets with only that label for that (S/*,
G). G).
13.3. Data Plane Procedures on Ingress PEs 13.3. Data Plane Procedures on Ingress PEs
An Ingress PE must perform application specific forwarding procedures An Ingress PE must perform application specific forwarding procedures
to identify the outgoing inta-area segment of an incoming packet. to identify the outgoing intra-area segment of an incoming packet.
If the outgoing intra-area segment is instantiated using a P2MP LSP, If the outgoing intra-area segment is instantiated using a P2MP LSP,
and if there is a one-to-one mapping between the outgoing intra-area and if there is a one-to-one mapping between the outgoing intra-area
segment and the P2MP LSP, then the ingress PE MUST encapsulate the segment and the P2MP LSP, then the ingress PE MUST encapsulate the
packet in the label stack of the outgoing P2MP LSP. If there is a packet in the label stack of the outgoing P2MP LSP. If there is a
many-to-one mapping between outgoing intra-area segments and the P2MP many-to-one mapping between outgoing intra-area segments and the P2MP
LSP then the PE MUST first push the upstream assigned label LSP then the PE MUST first push the upstream assigned label
corresponding to the outgoing intra-area segment, if such a label has corresponding to the outgoing intra-area segment, if such a label has
been assigned, and then push the label stack of the outgoing P2MP been assigned, and then push the label stack of the outgoing P2MP
LSP. LSP.
skipping to change at page 39, line 9 skipping to change at page 39, line 9
state on ABRs, it would also result in bandwidth inefficiency, as (C- state on ABRs, it would also result in bandwidth inefficiency, as (C-
S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also S1, C-G1) will be delivered not just to PE2, PE3, and PE4, but also
to PE5, which has no receivers for this stream. Likewise, (C-S2, C- to PE5, which has no receivers for this stream. Likewise, (C-S2, C-
G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2, G2) will be delivered not just to PE3, PE4, and PE5, but also to PE2,
which has no receivers for this stream. which has no receivers for this stream.
15. IANA Considerations 15. IANA Considerations
This document defines a new BGP Extended Community called "Inter-area This document defines a new BGP Extended Community called "Inter-area
P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented P2MP Segmented Next-Hop" (see section "Inter-area P2MP Segmented
Next-Hop Extended Community"). This community is IP Address Specific, Next-Hop Extended Community"). This may be either a Transitive
of an extended type, and is transitive. A codepoint for this IPv4-Address-Specific Extended Community or a Transitive
community has been assigned both from the IPv4 Address Specific IPv6-Address-Specific Extended Community. IANA has assigned the
Extended Community registry, and from the IPv6 Address Specific value 0x12 in the Transitive IPv4-Address-Specific Extended Community
Extended Community registry. IANA is requested to change in these Sub-Types registry, and IANA has assigned the value 0x0012 in the
registries the reference to the RFC number as soon as this document Transitive IPv6-Address-Specific Extended Community Types registry.
is published as an RFC. This document is the reference for both codepoints. IANA is
requested to change in these registries the reference to the RFC
number as soon as this document is published as an RFC.
This document also assigns a new Tunnel Type in the PMSI Tunnel IANA is requested to assign a value from the PMSI Tunnel Types
Attribute, called the "Transport Tunnel" (see section "Transport registry [pmsi-registry] for "Transport Tunnel" (see section
Tunnel Type"). This Tunnel Type is assigned a value of 8. "Transport Tunnel Type"). The value 0x08 is requested.
16. Security Considerations 16. Security Considerations
Procedures described in this document are subject to similar security Procedures described in this document are subject to similar security
threats as any MPLS deployment. It is recommended that baseline threats as any MPLS deployment. It is recommended that baseline
security measures are considered as described in Security Framework security measures are considered as described in Security Framework
for MPLS and GMPLS networks [RFC5920], in the mLDP specification for MPLS and GMPLS networks [RFC5920], in the mLDP specification
[RFC6388] and in P2MP RSVP-TE specification [RFC3209]. [RFC6388] and in P2MP RSVP-TE specification [RFC3209].
17. Acknowledgements 17. Acknowledgements
We would like to thank Eric Rosen for his comments. We also would We would like to thank Eric Rosen for his comments. We also would
like to thank Loa Andersson for his review and comments. like to thank Loa Andersson and Qin Wu for their review and comments.
18. References 18. References
18.1. Normative References 18.1. Normative References
[RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC [RFC1997] "BGP Communities Attribute", Ravi Chandra, et al., RFC
1997, August 1996 1997, August 1996
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, RFC 2119, March 1997 Levels.", Bradner, RFC 2119, March 1997
skipping to change at page 41, line 11 skipping to change at page 41, line 13
Multipoint and Multipoint-to-Multipoint Label Switched Paths", Multipoint and Multipoint-to-Multipoint Label Switched Paths",
Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, RFC Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas, RFC
6388, November 2011 6388, November 2011
[RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric [RFC6625] "Wildcards in Multicast VPN Auto-Discovery Routes", Eric
Rosen, et al., RFC 6625, May 2012 Rosen, et al., RFC 6625, May 2012
[RFC7117] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, RFC [RFC7117] "Multicast in VPLS", R. Aggarwal, Y. Kamite, L. Fang, RFC
7117, February 2014 7117, February 2014
[pmsi-registry] L. Andersson, et al., "IANA registry for PMSI Tunnel
Type code points", draft-ietf-l3vpn-pmsi-registry, work in progress
18.2. Informative References 18.2. Informative References
[SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al., [SEAMLESS-MPLS] "Seamless MPLS Architecture", N. Leymann et. al.,
draft-ietf-mpls-seamless-mpls, work in progress draft-ietf-mpls-seamless-mpls, work in progress
[RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang, [RFC5920] "Security Framework for MPLS and GMPLS Networks", L. Fang,
et al., RFC 5920, July 2010 et al., RFC 5920, July 2010
[RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et. [RFC7024] "Virtual Hub-and-Spoke in BGP/MPLS VPNs", Huajin Jeng et.
al., RFC 7024, October 2013 al., RFC 7024, October 2013
 End of changes. 15 change blocks. 
27 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/