draft-rekhter-mpls-pim-sm-over-mldp-05.txt   draft-rekhter-mpls-pim-sm-over-mldp-06.txt 
Network Working Group Yakov Rekhter (Juniper Networks) Network Working Group Yakov Rekhter
Internet Draft Rahul Aggarwal Internet Draft Juniper Networks
Intended Status: Proposed Standard Nicolai Leymann (Deutsche Telekom) Intended status: Standards Track
Wim Henderickx (Alcatel-Lucent) Expires: February 2014 Rahul Aggarwal
Quintin Zhao (Huawei) Arktan
Richard Li (Huawei)
Expiration Date: March 2014 August 20, 2013 Nicolai Leymann
Deutsche Telekom
Wim Henderickx
Alcatel-Lucent
Quintin Zhao
Huawei
Richard Li
Huawei
August 29 2013
Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs Carrying PIM-SM in ASM mode Trees over P2MP mLDP LSPs
draft-rekhter-mpls-pim-sm-over-mldp-05.txt draft-rekhter-mpls-pim-sm-over-mldp-06.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 1, line 37 skipping to change at page 2, line 7
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
When IP multicast trees created by PIM-SM in ASM mode need to pass When IP multicast trees created by PIM-SM in Any Source Multicast
through an MPLS domain, it may be desirable to map such trees to (ASM) mode need to pass through an MPLS domain, it may be desirable
Point-to-Multipoint Label Switched Paths. This document describes how to map such trees to Point-to-Multipoint Label Switched Paths. This
to accomplish this in the case where such Point-to-Multipoint Label document describes how to accomplish this in the case where such
Switches Paths are established using mLDP. Point-to-Multipoint Label Switches Paths are established using mLDP.
Specification of Requirements Table of Contents
1 Specification of Requirements ......................... 3
2 Introduction .......................................... 3
3 Option 1 .............................................. 4
3.1 Originating Source Active auto-discovery routes ....... 4
3.2 Receiving BGP Source Active auto-discovery route by LSR ...5
3.3 Handling (S, G, RPT-bit) state ........................ 6
4 Option 2 .............................................. 6
4.1 In-band signaling for IP Multicast Shared Tree ........ 6
4.2 Originating Source Active auto-discovery routes ....... 7
4.3 Receiving BGP Source Active auto-discovery route ...... 9
4.4 Pruning Sources off the Shared Tree ................... 9
4.5 More on handling (S,G,RPT-bit) state .................. 9
5 IANA Considerations ................................... 10
6 Security Considerations ............................... 10
7 Acknowledgements ...................................... 10
8 Normative References .................................. 10
9 Non-normative References .............................. 11
10 Authors' Addresses .................................... 11
1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1. Introduction 2. Introduction
When IP multicast trees need to pass through an MPLS domain, it may [MLDP-IN-BAND-SIGNALLING] describes how to map Point-to-Multipoint
be desirable to map such trees to Point-to-Multipoint Label Switched Label Switched Paths (P2MP LSPs) created by mLDP [mLDP] to multicast
Paths (P2MP LSPs). When P2MP LSPs are created by mLDP [mLDP], [MLDP- trees created by PIM-SM in SSM mode [RFC4607]. This document
IN-BAND-SIGNALLING] describes how to accomplish this when the trees describes how to map mLDP P2MP tress to multicast trees created by
are created by PIM-SM in SSM mode [RFC4607], but does not describe PIM-SM in ASM mode. It describes two possible options for doing this.
how to accomplish this when the trees are created by PIM-SM in ASM
mode [RFC4601].
This document describes how a combination of mLDP and BGP can be used The reader of this document is expected to be familiar with PIM-SM
to accomplish this for multicast trees created by PIM-SM in ASM mode, [RFC4601] and mLDP [mLDP].
and P2MP LSPs created by mLDP. It describes two possible options for
doing this.
An implementation MAY support Option 1, as described in Section 2 of An implementation MAY support Option 1, as described in Section 2 of
this document. An implementation MUST support Option 2, as described this document. An implementation MUST support Option 2, as described
in Section 3 of this document. in Section 3 of this document.
This document uses BGP Source Active auto-discovery routes, as This document uses BGP Source Active auto-discovery routes, as
defined in [MVPN-BGP]. defined in [MVPN-BGP]. This document also identifies the deployment
scenarios where BGP Source Active auto-discovery routes will not be
used.
Like [MLDP-IN-BAND-SIGNALLING], each IP multicast tree is mapped one- Like [MLDP-IN-BAND-SIGNALLING], each IP multicast tree is mapped one-
to-one to a P2MP LSP in the MPLS network. This type of service works to-one to a P2MP LSP in the MPLS network. This type of service works
well if the number of LSPs that are created is under control of the well if the number of LSPs that are created is under control of the
MPLS network operator, or if the number of LSPs for a particular MPLS network operator, or if the number of LSPs for a particular
service are known to be limited in number. service are known to be limited in number.
It is to be noted that the existing BGP MVPN [MVPN-BGP] procedures It is to be noted that the existing BGP MVPN [MVPN-BGP] procedures
may be used to map Internet IP multicast trees to P2MP LSPs. These may be used to map Internet IP multicast trees to P2MP LSPs. These
procedures would accomplish this for IP multicast trees created by procedures would accomplish this for IP multicast trees created by
PIM-SM in SSM mode as well as for IP multicast trees created by PIM- PIM-SM in SSM mode as well as for IP multicast trees created by PIM-
SM in ASM mode. Furthermore, these procedures would also support the SM in ASM mode. Furthermore, these procedures would also support the
ability to aggregate multiple IP multicast trees to one P2MP LSP in ability to aggregate multiple IP multicast trees to one P2MP LSP in
the MPLS network. The details of this particular approach are out of the MPLS network. The details of this particular approach are out of
scope of this document. scope of this document.
2. Option 1 This document assumes that a given LSR may have some of its
interfaces IP multicast capable, while other interfaces being MPLS
capable. This document further assumes that a given interface on an
LSR is either IP multicast capable, or MPLS capable, but not both.
3. Option 1
This option does not transit IP multicast shared trees over the MPLS This option does not transit IP multicast shared trees over the MPLS
network. Therefore, when an LSR creates (*, G) state (as a result of network. Therefore, when an LSR creates (*, G) state (as a result of
receiving PIM messages on one of its IP multicast interfaces), the receiving PIM messages on one of its IP multicast interfaces), the
LSR does not propagate this state in mLDP. LSR does not propagate this state in mLDP.
2.1. Originating Source Active auto-discovery routes 3.1. Originating Source Active auto-discovery routes
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) a Rendezvous Point (RP) discovers a new multicast source,
originate a BGP Source Active auto-discovery route. The route carries the RP SHOULD originate a BGP Source Active auto-discovery route.
a single MCAST-VPN NLRI constructed as follows: The route carries a single MCAST-VPN NLRI [MVPN-BGP] constructed as
follows:
+ The RD in this NLRI is set to 0. + The Route Distinguisher (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. This could be either
Source Length field is set appropriately to reflect this. an IPv4 or an IPv6 address. The Multicast Source Length field is
set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. The Multicast Group + The Multicast Group field MUST be set to G. This could be either
Length field is set appropriately to reflect this. an IPv4 or an IPv6 address. The Multicast Group Length field is
set appropriately to reflect this.
To constrain distribution of the Source Active auto-discovery route To constrain distribution of the Source Active auto-discovery route
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 previousely advertised by the RP. was previously advertised by the RP.
2.2. Receiving BGP Source Active auto-discovery route by LSR 3.2. Receiving BGP 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 such LSR creates in its Tree Information Base (TIB) a new interfaces such 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 4, line 22 skipping to change at page 6, line 5
SIGNALLING]. SIGNALLING].
When an LSR receives a new Source Active auto-discovery route, the When an LSR receives a new Source Active auto-discovery route, the
LSR MUST check if its TIB contains an (*, G) entry with the same G as LSR MUST check if its TIB contains an (*, G) entry with the same G as
carried in the Source Active auto-discovery route. If such an entry carried in the Source Active auto-discovery route. If such an entry
is found, S is reachable via an MPLS interface, and the LSR does not is found, S is reachable via an MPLS interface, and the LSR does not
have (S, G) state in its TIB for (S, G) carried in the route, then have (S, G) state in its TIB for (S, G) carried in the route, then
the LSR originates an mLDP Label Map with the Transit IPv4/IPv6 the LSR originates an mLDP Label Map with the Transit IPv4/IPv6
Source TLV carrying (S,G), as specified in [MLDP-IN-BAND-SIGNALLING]. Source TLV carrying (S,G), as specified in [MLDP-IN-BAND-SIGNALLING].
2.3. Handling (S, G, RPTbit) state 3.3. Handling (S, G, RPT-bit) state
Creation and deletion of (S, G, RPTbit) state on a LSR that resulted Creation and deletion of (S, G, RPT-bit) PIM state ([RFC4601]) on a
from receiving PIM messages on one of its IP multicast interfaces LSR that resulted from receiving PIM messages on one of its IP
does not result in any mLDP and/or BGP actions by the LSR. multicast interfaces does not result in any mLDP and/or BGP actions
by the LSR.
3. Option 2 4. Option 2
This option enables transit of IP multicast shared trees over the This option enables transit of IP multicast shared trees over the
MPLS network. Therefore, when an LSR creates (*, G) state as a result MPLS network. Therefore, when an LSR creates (*, G) state as a result
of receiving PIM messages on one of its IP multicast interfaces, the of receiving PIM messages on one of its IP multicast interfaces, the
LSR does propagate this state in mLDP, as described below. LSR does propagate this state in mLDP, as described below.
Note that in the deployment scenarios where for a given G none of the Note that in the deployment scenarios where for a given G none of the
PEs originate an (S, G) mLDP Label Map with the Transit IPv4/IPv6 PEs originate an (S, G) mLDP Label Map with the Transit IPv4/IPv6
Source TLV, no Source Active auto-discovery routes will be used. One Source TLV, no Source Active auto-discovery routes will be used. One
other scenario where no Source Active auto-discovery routes will be other scenario where no Source Active auto-discovery routes will be
used is described in section "Originating Source Active auto- used is described in section "Originating Source Active auto-
discovery routes". In all these scenarios the only part of Option 2 discovery routes". In all these scenarios the only part of Option 2
that will be used is the in-band signaling for IP Multicast Shared that will be used is the in-band signaling for IP Multicast Shared
Tree, as described in the next section. Tree, as described in the next section.
3.1. In-band signaling for IP Multicast Shared Tree 4.1. In-band signaling for IP Multicast Shared Tree
To provide support for in-band mLDP signaling of IP multicast shared To provide support for in-band mLDP signaling of IP multicast shared
trees this document defines two new mLDP TLVs: Transit IPv4 Shared trees this document defines two new mLDP TLVs: Transit IPv4 Shared
Tree TLV, and Transit IPv6 Shared Tree TLV. Tree TLV, and Transit IPv6 Shared Tree TLV.
These two TLVs have exactly the same encoding/format as the IPv4/IPv6 These two TLVs have exactly the same encoding/format as the IPv4/IPv6
Source Tree TLVs defined in [MLDP-IN-BAND-SIGNALLING], except that Source Tree TLVs defined in [MLDP-IN-BAND-SIGNALLING], except that
instead of the Source field they have the RP field, and this field instead of the Source field they have the RP field, and this field
carries the address of the RP. carries the address of the RP, as follows:
Transit IPv4 Shared Tree TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD (to be assigned by IANA).
Length: 8
RP: IPv4 RP address, 4 octets.
Group: IPv4 multicast group address, 4 octets.
Transit IPv6 Shared Tree TLV:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD (to be assigned by IANA).
Length: 32
Source: IPv6 RP address, 16 octets.
Group: IPv6 multicast group address, 16 octets.
Procedures for in-band signaling for IP multicast shared trees with Procedures for in-band signaling for IP multicast shared trees with
mLDP follow the same procedures as for in-band signaling for IP mLDP follow the same procedures as for in-band signaling for IP
multicast source trees specified in [MLDP-IN-BAND-SIGNALLING], except multicast source trees specified in [MLDP-IN-BAND-SIGNALLING], except
that while the latter signals (S,G) state using Transit IPv4/IPv6 that while the latter signals (S,G) state using Transit IPv4/IPv6
Source TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Source TLVs, the former signals (*,G) state using Transit IPv4/IPv6
Shared Tree TLVs. Shared Tree TLVs.
3.2. Originating Source Active auto-discovery routes 4.2. Originating Source Active auto-discovery routes
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 LSR creates an (S, G) state as a result of receiving an Whenever such 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), if mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G), if
all of the following are true: all of 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,
skipping to change at page 6, line 15 skipping to change at page 8, line 32
+ The Multicast Group field MUST be set to G. The Multicast Group + The Multicast Group field MUST be set to G. The Multicast Group
Length field is set appropriately to reflect this. Length field is set appropriately to reflect this.
To constrain distribution of the Source Active auto-discovery route To constrain distribution of the Source Active auto-discovery route
to the AS of the advertising LSR this route SHOULD carry the to the AS of the advertising LSR this route SHOULD carry the
NO_EXPORT Community ([RFC1997]). NO_EXPORT 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 LSR deletes the (S, G) state that was previously created Whenever the LSR deletes the (S,G) state that was previously created
as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6 as a result of receiving an mLDP Label Map with the Transit IPv4/IPv6
Source TLV for (S, G), the LSR that deletes the state MUST also Source TLV for (S,G), the LSR that deletes the state MUST also
withdraw the Source Active auto-discovery route, if such a route was withdraw the Source Active auto-discovery route, if such a route was
advertised when the state was created. advertised when the state was created.
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 4.3. Receiving BGP Source Active auto-discovery route
Procedures for receiving BGP Source Active auto-discovery routes are Procedures for receiving BGP Source Active auto-discovery routes are
the same as with Option 1. the same as with Option 1.
3.4. Pruning Sources off the Shared Tree 4.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
(S,G,rpt) downstream state to the Prune state. [Conceptually the PIM (S,G,RPT-bit) downstream state to the Prune state. [Conceptually the
state machine on the LSR will act "as if" it had received PIM state machine on the LSR will act "as if" it had received
Prune(S,G,Rpt) on one of its MPLS interfaces, without actually having Prune(S,G,rpt) on one of its MPLS interfaces, without actually having
received one.] Depending on the (S,G,rpt) state on the iif, this may received one.] Depending on the (S,G,RPT-bit) state on the iif, this
result in the LSR using PIM procedures to prune S off the Shared may result in the LSR using PIM procedures to prune S off the Shared
(*,G) tree. (*,G) tree.
The LSR MUST keep the (S,G,rpt) downstream state machine in the Prune The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the
state for as long as (a) the outgoing interface list (oif) for (*, G) Prune state for as long as (a) the outgoing interface list (oif) for
contains one of the MPLS interfaces, and (b) the LSR has at least one (*, G) contains one of the MPLS interfaces, and (b) the LSR has at
Source Active auto-discovery route for (S,G), and (c) the LSR does least one Source Active auto-discovery route for (S,G), and (c) the
not originate the mLDP Label Mapping message for (S,G) with the LSR does not originate the mLDP Label Mapping message for (S,G) with
Transit IPv4/IPv6 Source TLV. Once either of these conditions become the Transit IPv4/IPv6 Source TLV. Once either of these conditions
no longer valid, the LSR MUST transition the (S,G,rpt) downstream become no longer valid, the LSR MUST transition the (S,G,RPT-bit)
state machine to the NoInfo state. downstream state machine to the NoInfo state.
Note that except for the scenario described in the first paragraph of Note that except for the scenario described in the first paragraph of
this section, in all other scenarios relying solely on PIM procedures this section, in all other scenarios relying solely on PIM procedures
on the LSR is sufficient to ensure the correct behavior when pruning on the LSR is sufficient to ensure the correct behavior when pruning
sources off the shared tree. sources off the shared tree.
3.5. More on handling (S, G, RPTbit) state 4.5. More on handling (S,G,RPT-bit) state
Creation and deletion of (S, G, RPTbit) state on a LSR that resulted Creation and deletion of (S,G,RPT-bit) state on a LSR that resulted
from receiving PIM messages on one of its IP multicast interfaces from receiving PIM messages on one of its IP multicast interfaces
does not result in any mLDP and/or BGP actions by the LSR. does not result in any mLDP and/or BGP actions by the LSR.
4. IANA Considerations 5. IANA Considerations
This document defines two new mLDP TLVs: Transit IPv4 Shared Tree This document requires allocation from the LDP MP Opaque Value
TLV, and Transit IPv6 Shared Tree TLV. Element type name space managed by IANA the following two new mLDP
TLVs: Transit IPv4 Shared Tree TLV, and Transit IPv6 Shared Tree TLV.
5. Security Considerations 6. Security Considerations
All the security considerations for mLDP apply here. All the security considerations for mLDP ([mLDP]) apply here.
6. Acknowledgements 7. Acknowledgements
Use of Source Active auto-discovery routes was borrowed from [MVPN- Use of Source Active auto-discovery routes was borrowed from [MVPN-
BGP]. Some text in this document was borrowed almost verbatim from BGP]. Some text in this document was borrowed from [MVPN-BGP].
[MVPN-BGP].
Some of the text in this document was borrowed almost verbatim from Some of the text in this document was borrowed from [MLDP-IN-BAND-
[MLDP-IN-BAND-SIGNALLING]. SIGNALLING].
We would like to acknowledge Arkadiy Gulko for his review and We would like to acknowledge Arkadiy Gulko for his review and
comments. comments.
7. Normative References 8. Normative References
[mLDP] Minei, I., "Label Distribution Protocol Extensions for Point- [mLDP] Minei, I., "Label Distribution Protocol Extensions for Point-
to- Multipoint and Multipoint-to-Multipoint Label Switched Paths", to- Multipoint and Multipoint-to-Multipoint Label Switched Paths",
draft-ietf-mpls-ldp-p2mp-05 (work in progress), June 2008. RFC6388, November 2011.
[MLDP-IN-BAND-SIGNALLING] "In-band signaling for Point-to-Multipoint [MLDP-IN-BAND-SIGNALLING] "In-band signaling for Point-to-Multipoint
and Multipoint-to-Multipoint Label Switched Paths", I. Wijnands et and Multipoint-to-Multipoint Label Switched Paths", I. Wijnands et
al., draft-wijnands-mpls-mldp-in-band-signaling (work in progress) al., RFC6826, January 2013
[MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP [MVPN-BGP] "BGP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", R. Aggarwal et al., draft-ietf-l3vpn-2547bis-mcast-bgp (work VPNs", R. Aggarwal et al., RFC6514, February 2012
in progress)
[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.
8. Non-normative References 9. Non-normative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006. 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.
9. Authors' Addresses 10. Authors' Addresses
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
e-mail: yakov@juniper.net e-mail: yakov@juniper.net
Rahul Aggarwal Rahul Aggarwal
e-mail: raggarwa_1@yahoo.com e-mail: raggarwa_1@yahoo.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
 End of changes. 47 change blocks. 
88 lines changed or deleted 167 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/