draft-ietf-mpls-pim-sm-over-mldp-02.txt   draft-ietf-mpls-pim-sm-over-mldp-03.txt 
Network Working Group Yakov Rekhter Network Working Group Yakov Rekhter
Internet Draft Juniper Networks Internet Draft Juniper Networks
Intended status: Standards Track Intended status: Standards Track
Expires: April 2015 Rahul Aggarwal Expires: May 2015 Rahul Aggarwal
Arktan Arktan
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
Quintin Zhao Quintin Zhao
Huawei Huawei
Richard Li Richard Li
Huawei Huawei
October 20, 2014 November 28, 2014
Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs
draft-ietf-mpls-pim-sm-over-mldp-02.txt draft-ietf-mpls-pim-sm-over-mldp-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 3, line 11 skipping to change at page 3, line 11
Point-to-Multipoint Label Switched Paths are established using Label Point-to-Multipoint Label Switched Paths are established using Label
Distribution Protocol Extensions for Point-to-Multipoint and Distribution Protocol Extensions for Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP). Multipoint-to-Multipoint Label Switched Paths Multipoint LDP (mLDP).
Table of Contents Table of Contents
1 Introduction ................................................. 3 1 Introduction ................................................. 3
1.1 Specification of Requirements ................................ 5 1.1 Specification of Requirements ................................ 5
2 Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 5 2 Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 5
2.1 Originating Source Active Auto-Discovery Routes (Mechanism 1) .. 5 2.1 Originating Source Active Auto-Discovery Routes (Mechanism 1) .. 5
2.2 Receiving BGP Source Active Auto-Discovery Route by LSR ....... 6 2.2 Receiving Source Active Auto-Discovery Route by LSR .......... 6
2.3 Handling (S, G, RPT-bit) State ............................... 6 2.3 Handling (S, G, RPT-bit) State ............................... 6
3 Mechanism 2 - Transitive Mapping of IP Multicast Shared Tree ... 6 3 Mechanism 2 - Transitive Mapping of IP Multicast Shared Tree ... 6
3.1 In-band Signaling for IP Multicast Shared Trees .............. 7 3.1 In-band Signaling for IP Multicast Shared Trees .............. 7
3.2 Originating Source Active Auto-Discovery Routes (Mechanism 2) .. 8 3.2 Originating Source Active Auto-Discovery Routes (Mechanism 2) .. 8
3.3 Receiving BGP Source Active Auto-Discovery Route ............. 9 3.3 Receiving Source Active Auto-Discovery Route ................. 9
3.4 Pruning Sources Off the Shared Tree .......................... 9 3.4 Pruning Sources Off the Shared Tree .......................... 9
3.5 More on Handling (S,G,RPT-bit) State ......................... 10 3.5 More on Handling (S,G,RPT-bit) State ......................... 10
4 IANA Considerations .......................................... 10 4 IANA Considerations .......................................... 10
5 Security Considerations ...................................... 10 5 Security Considerations ...................................... 10
6 Acknowledgements ............................................. 10 6 Acknowledgements ............................................. 10
7 Normative References ......................................... 11 7 Normative References ......................................... 11
8 Informative References ....................................... 11 8 Informative References ....................................... 11
9 Authors' Addresses ........................................... 11 9 Authors' Addresses ........................................... 11
1. Introduction 1. Introduction
[RFC6826] describes how to map Point-to-Multipoint Label Switched [RFC6826] describes how to map Point-to-Multipoint Label Switched
Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees
created by PIM-SM in Source-Specific Multicast (SSM) mode [RFC4607]. created by PIM-SM in Source-Specific Multicast (SSM) mode [RFC4607].
This document describes how to map mLDP P2MP trees to multicast trees This document describes how to map mLDP P2MP trees to multicast trees
created by PIM-SM in Any-Source Multicast (ASM) mode. It describes created by PIM-SM in Any-Source Multicast (ASM) mode. It describes
two possible mechanisms for doing this. two possible mechanisms for doing this.
The first mechanism, described in Section 3, is optional for The first mechanism, described in Section 2, is OPTIONAL for
implementations, but the second mechanism, described in Section 4, is implementations, but the second mechanism, described in Section 3, is
mandatory for all implementations claiming conformance to this REQUIRED for all implementations claiming conformance to this
specification. specification.
Note that from a deployment point of view these two mechanisms are Note that from a deployment point of view these two mechanisms are
mutually exclusive. That is on the same network one could deploy mutually exclusive. That is on the same network one could deploy
either one of the mechanisms, but not both. either one of the mechanisms, but not both.
The reader of this document is expected to be familiar with PIM-SM The reader of this document is expected to be familiar with PIM-SM
[RFC4601] and mLDP [RFC6388]. [RFC4601] and mLDP [RFC6388].
This document relies on the procedures in [RFC6826] to support Source This document relies on the procedures in [RFC6826] to support Source
Trees. E.g., following these procedures a Label Switching Router Trees. E.g., following these procedures a Label Switching Router
(LSR) may initiate an mLDP Label Map with the Transit IPv4/IPv6 (LSR) may initiate an mLDP Label Map with the Transit IPv4/IPv6
Source TLV for (S, G) when receiving a PIM (S,G) Join. Source TLV for (S, G) when receiving a PIM (S,G) Join.
This document uses BGP Source Active auto-discovery routes, as This document uses BGP Source Active auto-discovery routes, as
defined in [RFC6514]. defined in [RFC6514]. For the sake of brevity in the rest of the
document we'll refer to these routes as just "Source Active auto-
discovery routes".
In a deployment scenario where the service provider has provisioned Consider a deployment scenario where the service provider has
the network in such a way that the Rendezvous Point (RP) for a provisioned the network in such a way that the Rendezvous Point (RP)
particular ASM group G is always between the receivers and the for a particular ASM group G is always between the receivers and the
sources. If the network is provisioned in this manner, the ingress PE sources. If the network is provisioned in this manner, the ingress PE
for (S,G) is always the same as the ingress PE for the RP, and thus for (S,G) is always the same as the ingress PE for the RP, and thus
the Source Active auto-discovery (A-D) routes are never needed. If it the Source Active auto-discovery (A-D) routes are never needed. If it
is known a priori that the network is provisioned in this manner, is known a priori that the network is provisioned in this manner,
mLDP in-band signaling can be supported using a different set of mLDP in-band signaling can be supported using a different set of
procedures, as specified in [draft-wijnands]. A service provider will procedures, as specified in [draft-wijnands]. A service provider will
provision the PE routers either to use [draft-wijnands] procedures or provision the PE routers either to use [draft-wijnands] procedures or
to use the procedures of this document. to use the procedures of this document.
Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP
skipping to change at page 5, line 22 skipping to change at page 5, line 22
This mechanism does not transit IP multicast shared trees over the This mechanism does not transit IP multicast shared trees over the
MPLS network. Therefore, when an LSR creates (*, G) state (as a MPLS network. Therefore, when an LSR creates (*, G) state (as a
result of receiving PIM messages on one of its IP multicast result of receiving PIM messages on one of its IP multicast
interfaces), the LSR does not propagate this state in mLDP. interfaces), the LSR does not propagate this state in mLDP.
2.1. Originating Source Active Auto-Discovery Routes (Mechanism 1) 2.1. Originating Source Active Auto-Discovery Routes (Mechanism 1)
Whenever (as a result of receiving either PIM Register or MSDP Whenever (as a result of receiving either PIM Register or MSDP
messages) an RP discovers a new multicast source, the RP SHOULD messages) an RP discovers a new multicast source, the RP SHOULD
originate a BGP Source Active auto-discovery route. The route carries originate a Source Active auto-discovery route. The route carries a
a single MCAST-VPN Network Layer Reachability Information (NLRI) single MCAST-VPN Network Layer Reachability Information (NLRI)
[RFC6514] constructed as follows: [RFC6514] constructed as follows:
+ The Route Distinguisher (RD) in this NLRI is set to 0. + The Route Distinguisher (RD) in this NLRI is set to 0.
+ The Multicast Source field is set to S. This could be either an + The Multicast Source field is set to S. This could be either an
IPv4 or an IPv6 address. The Multicast Source Length field is set IPv4 or an IPv6 address. The Multicast Source Length field is set
appropriately to reflect the address type. appropriately to reflect the address type.
+ The Multicast Group field is set to G. This could be either an + The Multicast Group field is set to G. This could be either an
IPv4 or an IPv6 address. The Multicast Group Length field is set IPv4 or an IPv6 address. The Multicast Group Length field is set
skipping to change at page 6, line 5 skipping to change at page 6, line 5
to the AS of the advertising RP this route SHOULD carry the NO_EXPORT to the AS of the advertising RP this route SHOULD carry the NO_EXPORT
Community ([RFC1997]). Community ([RFC1997]).
Using the normal BGP procedures the Source Active auto-discovery Using the normal BGP procedures the Source Active auto-discovery
route is propagated to all other LSRs within the AS. route is propagated to all other LSRs within the AS.
Whenever the RP discovers that the source is no longer active, the RP Whenever the RP discovers that the source is no longer active, the RP
MUST withdraw the Source Active auto-discovery route if such a route MUST withdraw the Source Active auto-discovery route if such a route
was previously advertised by the RP. was previously advertised by the RP.
2.2. Receiving BGP Source Active Auto-Discovery Route by LSR 2.2. Receiving Source Active Auto-Discovery Route by LSR
Consider an LSR that has some of its interfaces capable of IP Consider an LSR that has some of its interfaces capable of IP
multicast and some capable of MPLS multicast. multicast and some capable of MPLS multicast.
When as a result of receiving PIM messages on one of its IP multicast When as a result of receiving PIM messages on one of its IP multicast
interfaces an LSR creates in its Tree Information Base (TIB) a new interfaces an LSR creates in its Tree Information Base (TIB) a new
(*, G) entry with a non-empty outgoing interface list that contains (*, G) entry with a non-empty outgoing interface list that contains
one or more IP multicast interfaces, the LSR MUST check if it has any one or more IP multicast interfaces, the LSR MUST check if it has any
Source Active auto-discovery routes for that G. If there is such a Source Active auto-discovery routes for that G. If there is such a
route, S of that route is reachable via an MPLS interface, and the route, S of that route is reachable via an MPLS interface, and the
skipping to change at page 8, line 24 skipping to change at page 8, line 24
latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the latter signals (S,G) state using Transit IPv4/IPv6 Source TLVs, the
former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs. former signals (*,G) state using Transit IPv4/IPv6 Shared Tree TLVs.
3.2. Originating Source Active Auto-Discovery Routes (Mechanism 2) 3.2. Originating Source Active Auto-Discovery Routes (Mechanism 2)
Consider an LSR that has some of its interfaces capable of IP Consider an LSR that has some of its interfaces capable of IP
multicast and some capable of MPLS multicast. multicast and some capable of MPLS multicast.
Whenever such an LSR creates an (S, G) state as a result of receiving Whenever such an LSR creates an (S, G) state as a result of receiving
an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G) an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G)
the LSR MUST originate a BGP Source Active auto-discovery route if the LSR MUST originate a Source Active auto-discovery route if all of
all of the following are true: the following are true:
+ S is reachable via one of the IP multicast capable interfaces, + S is reachable via one of the IP multicast capable interfaces,
+ the LSR determines that G is in the PIM-SM in ASM mode range, and + the LSR determines that G is in the PIM-SM in ASM mode range, and
+ the LSR does not have an (*, G) state with one of the IP + the LSR does not have an (*, G) state with one of the IP
multicast capable interfaces as an incoming interface (iif) for multicast capable interfaces as an incoming interface (iif) for
that state. that state.
The route carries a single MCAST-VPN NLRI constructed as follows: The route carries a single MCAST-VPN NLRI constructed as follows:
skipping to change at page 9, line 23 skipping to change at page 9, line 23
Note that whenever an LSR creates an (S,G) state as a result of Note that whenever an LSR creates an (S,G) state as a result of
receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for
(S,G) with S reachable via one of the IP multicast capable (S,G) with S reachable via one of the IP multicast capable
interfaces, and the LSR already has a (*,G) state with RP reachable interfaces, and the LSR already has a (*,G) state with RP reachable
via one of the IP multicast capable interfaces as a result of via one of the IP multicast capable interfaces as a result of
receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree
TLV for (*,G), the LSR does not originate a Source Active auto- TLV for (*,G), the LSR does not originate a Source Active auto-
discovery route. discovery route.
3.3. Receiving BGP Source Active Auto-Discovery Route 3.3. Receiving Source Active Auto-Discovery Route
Procedures for receiving BGP Source Active Auto-Discovery routes are Procedures for receiving Source Active Auto-Discovery routes are the
the same as with Mechanism 1. same as with Mechanism 1.
3.4. Pruning Sources Off the Shared Tree 3.4. Pruning Sources Off the Shared Tree
If after receiving a new Source Active auto-discovery route for (S,G) If after receiving a new Source Active auto-discovery route for (S,G)
the LSR determines that (a) it has the (*, G) entry in its TIB, (b) the LSR determines that (a) it has the (*, G) entry in its TIB, (b)
the incoming interface list (iif) for that entry contains one of the the incoming interface list (iif) for that entry contains one of the
IP interfaces, (c) at least one of the MPLS interfaces is in the IP interfaces, (c) at least one of the MPLS interfaces is in the
outgoing interface list (oif) for that entry, and (d) the LSR does outgoing interface list (oif) for that entry, and (d) the LSR does
not originate an mLDP Label Mapping message for (S,G) with the not originate an mLDP Label Mapping message for (S,G) with the
Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the
skipping to change at page 10, line 34 skipping to change at page 10, line 34
------+------------------------------+------------ ------+------------------------------+------------
TBD1 | Transit IPv4 Shared Tree TLV | [This.I-D] TBD1 | Transit IPv4 Shared Tree TLV | [This.I-D]
TBD2 | Transit IPv6 Shared Tree TLV | [This.I-D] TBD2 | Transit IPv6 Shared Tree TLV | [This.I-D]
IANA is requested to assign consecutive values. IANA is requested to assign consecutive values.
5. Security Considerations 5. Security Considerations
All the security considerations for mLDP ([RFC6388]) apply here. All the security considerations for mLDP ([RFC6388]) apply here.
From the security considerations point of view use of Shared Tree
TLVs is no different than use of Source TLVs [RFC6826].
6. Acknowledgements 6. Acknowledgements
Use of Source Active auto-discovery routes was borrowed from Use of Source Active auto-discovery routes was borrowed from
[RFC6514]. Some text in this document was borrowed from [RFC6514]. [RFC6514]. Some text in this document was borrowed from [RFC6514].
Some of the text in this document was borrowed from [RFC6826]. Some of the text in this document was borrowed from [RFC6826].
We would like to acknowledge Arkadiy Gulko for his review and We would like to acknowledge Arkadiy Gulko for his review and
comments. comments.
skipping to change at page 11, line 13 skipping to change at page 11, line 14
and Adrian Farrell for their review and comments. and Adrian Farrell for their review and comments.
7. Normative References 7. Normative References
[RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute", [RFC1997] R. Chandra, P. Traina, T. Li, "BGP Communities Attribute",
RFC1997, August 1996. RFC1997, August 1996.
[RFC2119] "Key words for use in RFCs to Indicate Requirement [RFC2119] "Key words for use in RFCs to Indicate Requirement
Levels.", Bradner, RFC2119, March 1997. Levels.", Bradner, RFC2119, March 1997.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
[RFC6388] Minei, I., "Label Distribution Protocol Extensions for [RFC6388] Minei, I., "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Point-to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC6388, November 2011. Paths", RFC6388, November 2011.
[RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP [RFC6514] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal et al., RFC6514, February 2012 VPNs", R. Aggarwal et al., RFC6514, February 2012
[RFC6826] "In-band signaling for Point-to-Multipoint and Multipoint- [RFC6826] "In-band signaling for Point-to-Multipoint and Multipoint-
to-Multipoint Label Switched Paths", I. Wijnands et al., RFC6826, to-Multipoint Label Switched Paths", I. Wijnands et al., RFC6826,
January 2013 January 2013
8. Informative References 8. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[draft-wijnands] Wijnands IJ, et. al., "mLDP In-Band Signaling with [draft-wijnands] Wijnands IJ, et. al., "mLDP In-Band Signaling with
Wildcards", draft-ietf-mpls-mldp-in-band-wildcard-encoding, work in Wildcards", draft-ietf-mpls-mldp-in-band-wildcard-encoding, work in
progress progress
9. Authors' Addresses 9. Authors' Addresses
Yakov Rekhter Yakov Rekhter
 End of changes. 16 change blocks. 
24 lines changed or deleted 29 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/