Subject: draft-ietf-l3vpn-2547bis-mcast-bgp section 13

From: "HEMIGE Venu" <[email-masked]>
Date: Fri, 12 Dec 2008 09:53:53 -0600

I think the specification in section 13 needs some enhancement.
Otherwise, there are cases where it would not work.
 
1. Section 13.2: This sections says that if an egress PE has (C-*,C-G)
states and it has "one or more" source-active routes, then it must pick
"one of them" and setup a (C-S,C-G) forwarding state to accept traffic
for that (C-S,C-G) from the originator of that source-active route. If
all PEs select a single upstream PE for an (C-S,C-G), there should be
only one source-active route available. I suppose more than one is
possible when you have a PE configured as RP and hence it sends source
active routes into the MVPN cloud. Is that correct?
 
2. Section 13.2: If the above assumption is correct, then I think it is
wrong to say that the egress PE must pick one of the source-active
routes and setup forwarding state to accept traffic from the
"originator" of that source-active route. It is possible that the
orignator may not be in the path to C-S. Even if it is, it would break
the "single upstream PE" rule. I think the RPF tunnel should be the one
from the single forwarder PE regardless of where the Soure-Active is
received from. Section 14 says this but Section 13 does not.
 
3. Section 13.2: I think it is insufficient to say that the egress PE
creates just the forwarding state for (C-S,C-G). I think the egress PE
MUST send a Source Join Route to explicitly join the (C-S, C-G) tree.
Here is why: It could be that the only reason for the Source Join Route
and hence the Source-Active in the MVPN is because C-RP sent it after
C-S sends PIM registers to C-RP. As per section 13.2.1, the upstream PE
for the (C-*,C-G) creates a (C-S,C-G,rpt) prune state and sends this
prune to the RP when it receives a Source Active. As a result, C-RP
would prune itself off the (C-S,C-G) tree and this would result in the
Source Join and Source-Active routes from getting withdrawn from the
MVPN. This would result in a repetitious cycle of Source Join,
Source-Active, S,G,Rpt prune, Withdraw Source-Join, Withdraw
Source-Active, S,G,Rpt join, ...
 
The best way to fix these issus is to require that all egress PEs that
have (C-*,C-G) states MUST send Source Join Routes when they receive a
Source-Active. 
 
Please let me know if I am missing something.
 
Thanks,
-Venu

---

From: "NAPIERALA, MARIA H, ATTLABS" <[email-masked]>
Date: Wed, 17 Dec 2008 17:29:25 -0500

>3. Section 13.2: I think it is insufficient to say that the egress PE
creates just the >forwarding state for (C-S,C-G). I think the egress PE
MUST send a Source Join Route to >explicitly join the (C-S, C-G) tree.
Here is why: It could be that the only reason for the >Source Join Route
and hence the Source-Active in the MVPN is because C-RP sent it after
C-S >sends PIM registers to C-RP. As per section 13.2.1, the upstream PE
for the (C-*,C-G) creates a >(C-S,C-G,rpt) prune state and sends this
prune to the RP when it receives a Source Active. As a >result, C-RP
would prune itself off the (C-S,C-G) tree and this would result in the
Source Join >and Source-Active routes from getting withdrawn from the
MVPN. This would result in a >repetitious cycle of Source Join,
Source-Active, S,G,Rpt prune, Withdraw Source-Join, Withdraw

>The best way to fix these issus is to require that all egress PEs that
have (C-*,C-G) states >MUST send Source Join Routes when they receive a
Source-Active. 

>Please let me know if I am missing something.

This is correct, egress PEs always have to sent (C-S,C-G) Source Join
Route for each active C-S. 

The RFC 4106 says:

   "The (S,G) Keepalive Timer is updated by data being forwarded using

   this (S,G) forwarding state.  It is used to keep (S,G) state alive in

   the absence of explicit (S,G) Joins.  Amongst other things, this is

   necessary for the so-called "turnaround rules" -- when the RP uses

   (S,G) joins to stop encapsulation, and then (S,G) prunes to prevent

   traffic from unnecessarily reaching the RP."

Maria

From: [email-masked] [mailto:[email-masked]] On Behalf
Of HEMIGE Venu
Sent: Friday, December 12, 2008 10:54 AM
To: [email-masked]
Subject: draft-ietf-l3vpn-2547bis-mcast-bgp section 13

Thanks,

-Venu