draft-rekhter-mpls-pim-sm-over-mldp-03.txt   draft-rekhter-mpls-pim-sm-over-mldp-04.txt 
Network Working Group Yakov Rekhter (Juniper Networks) Network Working Group Yakov Rekhter (Juniper Networks)
Internet Draft Rahul Aggarwal Internet Draft Rahul Aggarwal
Intended Status: Proposed Standard Nicolai Leymann (Deutsche Telekom) Intended Status: Proposed Standard Nicolai Leymann (Deutsche Telekom)
Expiration Date: February 2014 July 29, 2013 Expiration Date: March 2014 August 2, 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-03.txt draft-rekhter-mpls-pim-sm-over-mldp-04.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 2, line 34 skipping to change at page 2, line 34
IN-BAND-SIGNALLING] describes how to accomplish this when the trees IN-BAND-SIGNALLING] describes how to accomplish this when the trees
are created by PIM-SM in SSM mode [RFC4607], but does not describe are created by PIM-SM in SSM mode [RFC4607], but does not describe
how to accomplish this when the trees are created by PIM-SM in ASM how to accomplish this when the trees are created by PIM-SM in ASM
mode [RFC4601]. mode [RFC4601].
This document describes how a combination of mLDP and BGP can be used This document describes how a combination of mLDP and BGP can be used
to accomplish this for multicast trees created by PIM-SM in ASM mode, to accomplish this for multicast trees created by PIM-SM in ASM mode,
and P2MP LSPs created by mLDP. It describes two possible options for and P2MP LSPs created by mLDP. It describes two possible options for
doing this. doing this.
An implementation MUST 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 MAY 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.
A deployment of the procedures specified in this document MAY use
neither Option 1, nor Option 2 if all the Last Hop Routers and RPs
are provisioned to return FALSE in the SwitchToSPTDesired [RFC4601].
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].
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. The approach specified in this document can scope of this document.
be viewed as an optimization, compared to the reuse of the entire BGP
MVPN procedures, and may be beneficial in certain deployment
scenarios.
2. Option 1 2. 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 2.1. Originating Source Active auto-discovery routes
skipping to change at page 4, line 42 skipping to change at page 4, line 35
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.
3. Option 2 3. 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
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
other scenario where no Source Active auto-discovery route will be
used is described in section "Originating Source Active auto-
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
Tree, as described in the next section.
3.1. In-band signaling for IP Multicast Shared Tree 3.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.
skipping to change at page 5, line 20 skipping to change at page 5, line 29
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 3.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), S is mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S, G), if
reachable via one of the IP multicast capable interfaces, and the LSR all of the following are true:
determines that G is in the PIM-SM in ASM mode range, the LSR MUST
originate a BGP Source Active auto-discovery route. The route carries
a single MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to 0. + S is reachable via one of the IP multicast capable interfaces,
+ The Multicast Source field MUST be set to S. The Multicast + the LSR determines that G is in the PIM-SM in ASM mode range, and
Source Length field is set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. The Multicast Group + the LSR does not have an (*, G) state with one of the IP
Length field is set appropriately to reflect this. multicast capable interfaces as an incoming interface (iif) for
that state
the LSR MUST originate a BGP Source Active auto-discovery route.
The route carries a single MCAST-VPN NLRI constructed as follows:
+ The RD in this NLRI is set to 0.
+ The Multicast Source field MUST be set to S. The Multicast Source
Length field is set appropriately to reflect this.
+ The Multicast Group field MUST be set to G. 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 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
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
interfaces, and, as a result of receiving an mLDP Label Map with the
Transit IPv4/IPv6 Shared Tree TLV for (*, G), the LSR already has a
(*, G) state with RP reachable via one of the IP multicast capable
interfaces, the LSR does not originate a Source Active auto-discovery
route.
3.3. Receiving BGP Source Active auto-discovery route 3.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 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
 End of changes. 11 change blocks. 
22 lines changed or deleted 42 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/