draft-ietf-l2vpn-vpls-pim-snooping-02.txt   draft-ietf-l2vpn-vpls-pim-snooping-03.txt 
Layer 2 Virtual Private Networks O. Dornon Layer 2 Virtual Private Networks O. Dornon
Internet-Draft J. Kotalwar Internet-Draft J. Kotalwar
Intended status: Informational Alcatel-Lucent Intended status: Informational Alcatel-Lucent
Expires: January 17, 2013 J. Zhang Expires: July 18, 2013 J. Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
V. Hemige V. Hemige
Alcatel-Lucent
July 16, 2012 R. Qiu
Huawei Technologies, USA
January 14, 2013
PIM Snooping over VPLS PIM Snooping over VPLS
draft-ietf-l2vpn-vpls-pim-snooping-02 draft-ietf-l2vpn-vpls-pim-snooping-03
Abstract Abstract
In Virtual Private LAN Service (VPLS), as also in IEEE Bridged In Virtual Private LAN Service (VPLS), as also in IEEE Bridged
Networks, the switches simply flood multicast traffic on all ports in Networks, the switches simply flood multicast traffic on all ports in
the LAN by default. IGMP Snooping is commonly deployed to ensure the LAN by default. IGMP Snooping is commonly deployed to ensure
multicast traffic is not forwarded on ports without IGMP receivers. multicast traffic is not forwarded on ports without IGMP receivers.
The procedures and recommendations for IGMP Snooping are defined in The procedures and recommendations for IGMP Snooping are defined in
[IGMP-SNOOP]. But when any protocol other than IGMP is used, the [IGMP-SNOOP]. But when any protocol other than IGMP is used, the
common practice is to simply flood multicast traffic to all ports. common practice is to simply flood multicast traffic to all ports.
skipping to change at page 2, line 15 skipping to change at page 2, line 16
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 17, 2013. This Internet-Draft will expire on July 18, 2013.
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
skipping to change at page 4, line 9 skipping to change at page 4, line 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 31 5. Security Considerations . . . . . . . . . . . . . . . . . . . 31
6. Contributers . . . . . . . . . . . . . . . . . . . . . . . . . 31 6. Contributers . . . . . . . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Appendix A. PIM-BIDIR Thoughts . . . . . . . . . . . . . . . . . 33 Appendix A. PIM-BIDIR Thoughts . . . . . . . . . . . . . . . . . 33
Appendix B. Example Network Scenario . . . . . . . . . . . . . . 33 Appendix B. Example Network Scenario . . . . . . . . . . . . . . 33
B.1. Pim Snooping Example . . . . . . . . . . . . . . . . . . . 34 B.1. Pim Snooping Example . . . . . . . . . . . . . . . . . . . 34
B.2. PIM Proxy Example with (S,G) / (*,G) interaction . . . . . 36 B.2. PIM Proxy Example with (S,G) / (*,G) interaction . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices In Virtual Private LAN Service (VPLS), the Provider Edge (PE) devices
provide a logical interconnect such that Customer Edge (CE) devices provide a logical interconnect such that Customer Edge (CE) devices
belonging to a specific VPLS instance appear to be connected by a belonging to a specific VPLS instance appear to be connected by a
single LAN. Forwarding information base for particular VPLS instance single LAN. Forwarding information base for particular VPLS instance
is populated dynamically by source MAC address learning. This is a is populated dynamically by source MAC address learning. This is a
straightforward solution to support unicast traffic, with reasonable straightforward solution to support unicast traffic, with reasonable
flooding for unicast unknown traffic. Since a VPLS provides LAN flooding for unicast unknown traffic. Since a VPLS provides LAN
skipping to change at page 31, line 48 skipping to change at page 31, line 48
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
5. Security Considerations 5. Security Considerations
Security considerations provided in VPLS solution documents (i.e., Security considerations provided in VPLS solution documents (i.e.,
[VPLS-LDP] and [VPLS-BGP]) apply to this document as well. [VPLS-LDP] and [VPLS-BGP]) apply to this document as well.
6. Contributers 6. Contributers
Yetik Serbest, Suresh Boddapati co-authored earlier versions.
Karl (Xiangrong) Cai and Princy Elizabeth made significant Karl (Xiangrong) Cai and Princy Elizabeth made significant
contributions to bring the specification to its current state, contributions to bring the specification to its current state,
especially in the area of Join forwarding rules. especially in the area of Join forwarding rules.
Yetik Serbest, Ray Qiu, Suresh Boddapati co-authored earlier
versions.
7. Acknowledgements 7. Acknowledgements
Many members of the L2VPN and PIM working groups have contributed to Many members of the L2VPN and PIM working groups have contributed to
and provided valuable comments and feedback to this draft, including and provided valuable comments and feedback to this draft, including
Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lassere, Vach Kompella, Shane Amante, Sunil Khandekar, Rob Nath, Marc Lassere,
Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, Himanshu Shah Yuji Kamite, Yiqun Cai, Ali Sajassi, Jozef Raets, Himanshu Shah
(Ciena), Himanshu Shah (Alcatel-Lucent). (Ciena), Himanshu Shah (Alcatel-Lucent).
8. References 8. References
skipping to change at page 34, line 38 skipping to change at page 34, line 38
In the examples below, JT(Port,S,G,N) is the downstream Join Expiry In the examples below, JT(Port,S,G,N) is the downstream Join Expiry
Timer on the specified Port for the (S,G) with upstream neighbor N. Timer on the specified Port for the (S,G) with upstream neighbor N.
B.1. Pim Snooping Example B.1. Pim Snooping Example
In the network depicted in Figure 3, S is the source of a multicast In the network depicted in Figure 3, S is the source of a multicast
stream (S,G). CE1 and CE2 both have two ECMP routes to reach the stream (S,G). CE1 and CE2 both have two ECMP routes to reach the
source. source.
1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3. 1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3.
2. PE1 snoops on the Join(S,G) while flooding it in the VPLS. PE2 2. PE1 snoops on the Join(S,G) and builds forwarding states, since it
and PE3 also snoop on the Join(S,G) while flooding it in the is received on an AC and is targeting a neighbor residing across
a PW it sends the join to all PW's while flooding it in the VPLS.
PE2 and PE3 also snoop on the Join(S,G) while flooding it in the
VPLS. VPLS.
The resulting states at the PEs is as follows: The resulting states at the PEs is as follows:
At PE1: At PE1:
JT(AC1,S,G,CE3) = JP_HoldTime JT(AC1,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 } UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 } OutgoingPortList(S,G) = { AC1, PW12 }
skipping to change at page 34, line 51 skipping to change at page 35, line 4
The resulting states at the PEs is as follows: The resulting states at the PEs is as follows:
At PE1: At PE1:
JT(AC1,S,G,CE3) = JP_HoldTime JT(AC1,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 } UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 } OutgoingPortList(S,G) = { AC1, PW12 }
At PE2: At PE2:
JT(PW12,S,G,CE3) = JP_HoldTime JT(PW12,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 } UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 } OutgoingPortList(S,G) = { PW12, AC3 }
At PE3: At PE3:
PE3 doesn't create a forwarding state for (S,G) because PE3 doesn't create a forwarding state for (S,G) because
the Join(S,G) was received on a PW and the Upstream RPort the Join(S,G) was received on a PW and the Upstream RPort
is a PW too. <<<<< is a PW too.
3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1 3. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1
4. Now CE2 sends a Join(S,G) with Upstream Neighbor(S,G) = CE4. 4. Now CE2 sends a Join(S,G) with Upstream Neighbor(S,G) = CE4.
5. All PEs snoop on the Join(S,G). 5. All PEs snoop on the Join(S,G).
The resulting states at the PEs: The resulting states at the PEs:
At PE1: At PE1:
JT(AC1,S,G,CE3) = active JT(AC1,S,G,CE3) = active
JT(AC2,S,G,CE4) = JP_HoldTime. JT(AC2,S,G,CE4) = JP_HoldTime.
UpstreamNeighbors(S,G) = { CE3, CE4 } UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { PW12, PW13 } UpstreamPorts(S,G) = { PW12, PW13 }
OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 } OutgoingPortList(S,G) = { AC1, PW12, AC2, PW13 }
At PE2: Note: Since PE2 already has (S,G) state, it does not At PE2: Note: Since PE2 already has (S,G) state, it does not
ignore the Join(S,G) even though it received the ignore the Join(S,G) even though it received the
Join(S,G) on a PW and the Upstream Rport is a PW. <<<<<< Join(S,G) on a PW and the Upstream Rport is a PW.
JT(PW12,S,G,CE4) = JP_HoldTime JT(PW12,S,G,CE4) = JP_HoldTime
JT(PW12,S,G,CE3) = active JT(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3, CE4 } UpstreamNeighbors(S,G) = { CE3, CE4 }
UpstreamPorts(S,G) = { AC3, PW23 } UpstreamPorts(S,G) = { AC3, PW23 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 } OutgoingPortList(S,G) = { PW12, AC3, PW23 }
At PE3: At PE3:
JT(PW13,S,G,CE4) = JP_HoldTime JT(PW13,S,G,CE4) = JP_HoldTime
UpstreamNeighbors(S,G) = { CE4 } UpstreamNeighbors(S,G) = { CE4 }
UpstreamPorts(S,G) = { AC4 } UpstreamPorts(S,G) = { AC4 }
skipping to change at page 36, line 33 skipping to change at page 36, line 35
Note that at the end of the assert election, there should be no Note that at the end of the assert election, there should be no
duplicate traffic forwarded downstream and traffic should flow only duplicate traffic forwarded downstream and traffic should flow only
on the desired path. Also note that there are no unnecessary (S,G) on the desired path. Also note that there are no unnecessary (S,G)
states on PE3 after the assert election. states on PE3 after the assert election.
B.2. PIM Proxy Example with (S,G) / (*,G) interaction B.2. PIM Proxy Example with (S,G) / (*,G) interaction
In the same network, let us assume CE4 is the Upstream Neighbor In the same network, let us assume CE4 is the Upstream Neighbor
towards the RP for G. towards the RP for G.
JPST(S,G,N) is the JP sending timer for the (S,G) with upstream
neighbor N.
1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3. 1. CE1 Sends a Join(S,G) with Upstream Neighbor(S,G) = CE3.
2. PE1 consumes the Join(S,G). PE1 looks up the neighbor database
and determines CE3 was learnt on PW12. PE1 sends a Proxy PE1 consumes the Join(S,G). Since is is received on an AC and is
Join(S,G) to the resulting UpstreamPorts(G). i.e. it sends the targeting a neighbor that is residing across a PW it sends the join
proxy Join(S,G) on PW12. over all PWs.
3. Likewise, PE2 consumes the Join(S,G) and sends a proxy Join(S,G)
on AC3 with Upstream Neighbor = CE3. PE2 consumes the Join(S,G). Since the join is received on a PW and
targets an AC it only sends the join only over AC3.
PE3 & PE4 ignore the Join(S,G) because it is received over a PW and
targets a PW, and no states exist for S,G.
The resulting states at the PEs is as follows: The resulting states at the PEs is as follows:
At PE1: PE1 states:
JT(AC1,S,G,CE3) = JP_HoldTime JT(AC1,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 } UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 } OutgoingPortList(S,G) = { AC1, PW12 }
At PE2: PE2 states:
JT(PW12,S,G,CE3) = JP_HoldTime JT(PW12,S,G,CE3) = JP_HoldTime
JPST(S,G,CE3) = t_periodic
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 } UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 } OutgoingPortList(S,G) = { PW12, AC3 }
At PE3: PE3 did not receive any PIM Join(S,G). So it has 2. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1.
no (S,G) state.
4. The multicast stream (S,G) flows along CE3 -> PE2 -> PE1 -> CE1. 3. Now let us say CE1 sends a Join(*,G) towards CE4.
5. Now let us say CE1 sends a Join(*,G) towards CE4.
6. PE1 consumes the Join(*,G). PE1 sends a Proxy Join(*,G) to the
resulting UpstreamPorts(G). Since UpstreamPorts(G) now has both
PW12 and PW13, the Join(*,G) gets sent on both PW12 and PW13.
Note that the UpstreamPorts(S,G) and OutgoingPortList(S,G)
inherit the corresponding (*,G) sets, but not vice versa.
remove "but not vice versa"
COMMENT : > Original "but not vice versa" applies to OutgoingPortList(S,G) only,
I assume, because of the earlier definition:
UpstreamPorts(G): This set is the union of all the PE1 snoops this Join(*,G). Since the join is received on an A and is
UpstreamPorts(S,G) and UpstreamPorts(*,G) for a given G targeting a neighbor residing on a PW it sends the join over all PWs.
7. PE2 and PE3 perform a similar function. PE2 received the PE2 consumes this Join(*,G) because it has a state for (S,G) with an AC
Join(*,G) on a PW and the Upstream Neighbor is also on a PW. in UpstreamPorts(S,G). Since the join is received in a PW and targets
Hence PE2 only adds UpstreamPorts(*,G) to OutgoingPortList(*,G) another PW it does not send the join anywhere, but adds
and not the downstream port PW12. UpstreamPorts(*,G) to OutgoingPortList(*,G) and not the
downstream port PW12.
PE3 consumes the Join(*,G). Since the join is received on a PW and
targets an AC it only sends the join only over AC4.
At PE1: The resulting states at the PEs is as follows:
PE1 states:
JT(AC1,S,G,CE3) = active JT(AC1,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12, PW13 } UpstreamPorts(S,G) = { PW12, PW13 }
OutgoingPortList(S,G) = { AC1, PW12, PW13 } OutgoingPortList(S,G) = { AC1, PW12, PW13 }
JT(AC1,*,G,CE4) = JP_HoldTime. JT(AC1,*,G,CE4) = JP_HoldTime
JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 } UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 } UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC1, PW13 } OutgoingPortList(*,G) = { AC1, PW13 }
UpstreamPorts(G) = { PW12, PW13 } PE2 states:
At PE2:
JT(PW12,S,G,CE3) = active JT(PW12,S,G,CE3) = active
JPST(S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3, PW23 } UpstreamPorts(S,G) = { AC3, PW23 }
OutgoingPortList(S,G) = { PW12, AC3, PW23 } OutgoingPortList(S,G) = { PW12, AC3, PW23 }
JT(PW12,*,G,CE4) = JP_HoldTime JT(PW12,*,G,CE4) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE4 } UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(G) = { PW23 } UpstreamPorts(G) = { PW23 }
OutgoingPortList(*,G) = { PW23 } OutgoingPortList(*,G) = { PW23 }
At PE3: PE3 states:
JT(PW13,*,G,CE4) = JP_HoldTime JT(PW13,*,G,CE4) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE4 } JPST(*,G,CE4) = t_periodic
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 } UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 } OutgoingPortList(*,G) = { PW13, AC4 }
8. The above state results in both (S,G) and (*,G) streams to be 4. In the case that there is no traffic yet and PE1 sends a periodic
Join(S,G) to PE2 and PE3 (step 2 is delayed after step 4).
PE1 & PE2, nothing changes except for a refresh of the timers
PE3 consumes the JOIN(S,G) because it has a (*,G) state with an AC in
UpstreamPorts(*,G). Since the join is received in a PW and targets
another PW it does not send the join anywhere.
PE3 States:
JT(PW13,*,G,CE4) = active
JPST(S,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
JT(PW13,S,G,CE3) = JP_HoldTime
UpstreamNeighbors(*,G) = { CE3 }
UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW13, AC4, PW23 }
5. The above state results in both (S,G) and (*,G) streams to be
forwarded to AC1. The above state also results in the (S,G) forwarded to AC1. The above state also results in the (S,G)
stream to be forwarded from CE3 to CE4 resulting in an (S,G) stream to be forwarded from CE3 to CE4 resulting in an (S,G)
assert election. Following the assert election, CE3 becomes the assert election. Following the assert election, CE3 becomes the
(S,G) assert winner. CE4 stops sending (S,G) stream down the (S,G) assert winner. CE4 stops sending (S,G) stream down the
RPT. RPT.
9. CE1 notices an RPF change due to assert. It sends a 9. CE1 notices an RPF change due to assert. It sends a
Prune(S,G,rpt) with Upstream Neighbor = CE4. Prune(S,G,rpt) with Upstream Neighbor = CE4.
10. PE1 consumes the Prune(S,G,rpt) and forwards the
Prune(S,G,rpt) to both PW12 and PW13. PE2 consumes the
Prune(S,G,rpt) and updates its states. PE3 updates its states
and forwards the Prune(S,G,rpt) on AC4.
At PE1: 10. PE1 consumes the Prune(S,G,rpt) and since PruneDesired(S,G,Rpt,CE4) is
TRUE, it needs to send the Prune(S,G,rpt) to CE4.
This Prune(S,G,rpt) needs to be sent to both PW12 and PW13.
PE2 consumes the Prune(S,G,rpt), it should not send out any
Prune(S,G,rpt) since this Prune(S,G,rpt) has double PW ports.
PE3 consumes the Prune(S,G,rpt) and since PruneDesired(S,G,rpot,CE4)
is TRUE it sends the Prune(S,G,rpt) on AC4.
PE1 states:
JT(AC1,S,G,CE3) = active JT(AC1,S,G,CE3) = active
JPST(AC1,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 }
JT(AC1,S,G,CE4) = JP_Holdtime with FLAG sgrpt prune
JPST(AC1,S,G,CE4) = none, since JPST(AC1, *,G,CE4) is there
UpstreamPorts(S,G,rpt) = { PW13 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW12 } UpstreamPorts(S,G) = { PW12 }
OutgoingPortList(S,G) = { AC1, PW12 } OutgoingPortList(S,G) = { AC1, PW12 }
JT(AC1,*,G,CE4) = active. JT(AC1,*,G,CE4) = active
JPST(*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 } UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW13 } UpstreamPorts(*,G) = { PW13 }
OutgoingPortList(*,G) = { AC1, PW13 } OutgoingPortList(*,G) = { AC1, PW13 }
At PE2: At PE2:
JT(PW12,S,G,CE3) = active JT(PW12,S,G,CE3) = active
JPST(PW12,S,G,CE3) = active
UpstreamNeighbors(S,G) = { CE3 } UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(*,G) = { AC3 }
OutgoingPortList(S,G) = { PW12, AC3 }
JT(PW12,*,G,CE4) = JP_HoldTime JT(PW12,S,G,CE4) = JP_Holdtime with FLAG sgrpt prune
JPST(PW12,S,G,CE4) = none, no Prune(S,G,rpt) should be sent
UpstreamPorts(S,G,rpt) = { PW23 }
UpstreamNeighbors(S,G,rpt) = { CE4 }
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { AC3 }
OutgoingPortList(*,G) = { PW12, AC3 }
JT(PW12,*,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 } UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(*,G) = { PW23 } UpstreamPorts(*,G) = { PW23 }
OutgoingPortList(*,G) = { PW23 } OutgoingPortList(*,G) = { PW23 }
At PE3: At PE3:
JT(PW13,*,G,CE4) = JP_HoldTime JT(PW13,S,G,CE4) = JP_Holdtime with S,G,rpt prune flag
JPST(PW13,S,G,CE4) = none, no Prune(S,G,rpt) should be sent
UpstreamNeighbors(S,G,rpt) = { CE4 }
UpstreamPorts(S,G,rpt) = { AC4 }
OutgoingPortList(S,G) = { empty }
JT(PW13,*,G,CE4) = active
JPST(S,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 }
11. If we're in case 4 for PE3
At PE3:
JT(PW13,S,G,CE3) = active
JPST(PW13,S,G,CE4) = none, this state is created by double join
UpstreamNeighbors(S,G) = { CE3 }
UpstreamPorts(S,G) = { PW23 }
OutgoingPortList(S,G) = { PW23 }
JT(PW13,S,G,CE4) = JP_Holdtime with S,G,rpt prune flag
JPST(PW13,S,G,CE4) = none, no Prune(S,G,rpt) should be sent
UpstreamNeighbors(S,G,rpt) = { CE4 }
UpstreamPorts(S,G,rpt) = { AC4 }
JT(PW13,*,G,CE4) = active
JPST(S,G,CE4) = active
UpstreamNeighbors(*,G) = { CE4 } UpstreamNeighbors(*,G) = { CE4 }
UpstreamPorts(G) = { AC4 } UpstreamPorts(G) = { AC4 }
OutgoingPortList(*,G) = { PW13, AC4 } OutgoingPortList(*,G) = { PW13, AC4 }
Even in this example, at the end of the (S,G) / (*,G) assert Even in this example, at the end of the (S,G) / (*,G) assert
election, there should be no duplicate traffic forwarded downstream election, there should be no duplicate traffic forwarded downstream
and traffic should flow only to the desired CEs. and traffic should flow only to the desired CEs.
However, the reason we don't have duplicate traffic is because one of
the CE stops sending traffic due to assert, not because we don't have
any forwarding state in PE to do this forwarding. Moreover, when JP
received order is different, the PE state could be different (like
PE3 could have OutgoingPortList(S,G) be PW23 or empty). This is
confusing, though from traffic forwarding POV it is still correct.
Other more complex scenarios exist. This draft should addressin PIM- Other more complex scenarios exist. This draft should addressin PIM-
SM and the rules specified in this draft should ensure that assert is SM and the rules specified in this draft should ensure that assert is
triggered among the CEs in all scenarios. triggered among the CEs in all scenarios.
Authors' Addresses Authors' Addresses
Olivier Dornon Olivier Dornon
Alcatel-Lucent Alcatel-Lucent
50 Copernicuslaan 50 Copernicuslaan
Antwerp, B2018 Antwerp, B2018
skipping to change at page 39, line 37 skipping to change at page 41, line 29
Email: jayant.kotalwar@alcatel-lucent.com Email: jayant.kotalwar@alcatel-lucent.com
Jeffrey Zhang Jeffrey Zhang
Juniper Networks, Inc. Juniper Networks, Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
Email: zzhang@juniper.net Email: zzhang@juniper.net
Venu Hemige Venu Hemige
Alcatel-Lucent
701 East Middlefield Rd.
Mountain View, CA 94043
Email: Venu.hemige@alcatel-lucent.com Email: vhemige@gmail.com
Ray Qiu
Huawei Technologies, USA
2330 Central Expressway
Santa Clara, CA 95050
Email: ray.qiu@huawei.com
 End of changes. 44 change blocks. 
66 lines changed or deleted 151 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/