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/ |