Re: WG LC: draft-ietf-l3vpn-2547bis-mcast-bgp

[Mark Fine <[e-mail]>]

Comments on draft-ietf-l3vpn-2547bis-mcast-bgp section 13 and
draft-ietf-l3vpn-2547bis-mcast section 9.1:

With C-RP behind PE1, PE2 having (C-*,C-G) state, C-S behind PE3, and
C-S sending traffic to C-G...

C-RP will upstream join (C-S,C-G) since inherited_olist(C-S,C-G) will
contain joins(C-*,C-G) from PE2's (C-*,C-G) state.

Per 13.1 and 9.1, PE3 creates (C-S,C-G) state as a result of receiving
the Source Tree Join C-multicast route from PE1, and PE3 originates
the Source Active route.

Per 13.2 and 9.1, PE2 sets up its forwarding path to receive (C-S,C-G)
from PE3's tunnel as a result of receiving the Source Active route
from PE3.

Per 13.2.1 and 9.1, PE1 creates (C-S,C-G,rpt) state as a result of
receiving the Source Active route from PE3 and having (C-*,C-G) state
with an iif containing a PE-CE interface.

C-RP will upstream prune (C-S,C-G) since inherited_olist(C-S,C-G) will
be NULL from PE1's (C-S,C-G,rpt) state.

Per 13.1 and 9.1, PE3 deletes (C-S,C-G) state as a result of the
withdrawn Source Tree Join C-multicast route from PE1, and PE3
withdraws the Source Active route.

Per 13.2.1 and 9.1, PE1 deletes (C-S,C-G,rpt) state as a result of the
withdrawn Source Active route from PE3.

C-RP will upstream join (C-S,C-G) since inherited_olist(C-S,C-G) will
no longer be NULL from after deleting PE1's (C-S,C-G,rpt) state.

... per 13 and 9.1, the above suggests a continuous cycle of joining
C-RP to SPT, pruning C-S off RPT, pruning C-RP from SPT, joining C-S
to RPT, joining C-RP to SPT... only forwarding (C-S,C-G) traffic to
PE2 in the intervals where C-RP is joined to SPT.