draft-rekhter-mpls-pim-sm-over-mldp-04.txt   draft-rekhter-mpls-pim-sm-over-mldp-05.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: March 2014 August 2, 2013 Wim Henderickx (Alcatel-Lucent)
Quintin Zhao (Huawei)
Richard Li (Huawei)
Expiration Date: March 2014 August 20, 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-04.txt draft-rekhter-mpls-pim-sm-over-mldp-05.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 4, line 38 skipping to change at page 4, line 38
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 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 route 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 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.
skipping to change at page 6, line 24 skipping to change at page 6, line 24
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, as a result of receiving an mLDP Label Map with the interfaces, and the LSR already has a (*, G) state with RP reachable
Transit IPv4/IPv6 Shared Tree TLV for (*, G), the LSR already has a via one of the IP multicast capable interfaces as a result of
(*, G) state with RP reachable via one of the IP multicast capable receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree
interfaces, the LSR does not originate a Source Active auto-discovery TLV for (*, G), the LSR does not originate a Source Active auto-
route. 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)
skipping to change at line 351 skipping to change at page 9, line 4
Rahul Aggarwal Rahul Aggarwal
e-mail: raggarwa_1@yahoo.com e-mail: raggarwa_1@yahoo.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
Winterfeldtstrasse 21 Winterfeldtstrasse 21
Berlin 10781 Berlin 10781
Germany Germany
e-mail: nicolai.leymann@t-systems.com e-mail: nicolai.leymann@t-systems.com
Wim Henderickx
Alcatel-Lucent
Email: wim.henderickx@alcatel-lucent.com
Richard Li
Huawei
Email: renwei.li@huawei.com
Quintin Zhao
Huawei
Email: quintin.zhao@huawei.com
 End of changes. 5 change blocks. 
8 lines changed or deleted 11 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/