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

[Thomas Morin <[e-mail]>]

Hello,

It occurred to me that if/when the PIM assert mechanism is used on PMSI
tunnels, then there is a small issue related to S-PMSIs that does not
seem to be addressed in current specifications : when two PEs happen to
send traffic for a same (S,G) on a P-tunnel, at least one of the PEs
needs to receive the packets sent by the other PE or the PIM Assert
mechanism won't get triggered. But if we are in a situation where the
two PEs have bound an (S,G) to an S-PMSI, then nothing guarantees that
one of them will see the packets from the other.

I would see different ways to resolve this (there might be others):
* impose that PEs join all S-PMSI tunnels for (C-S,C-G) as soon as they
have VRF PIM state for (C-S,C-G), *even* if the RPF interface is not the
MI-PMSI or such an S-PMSI  -- that way we can be sure that the PIM
Assert mechanism will trigger
* or, impose that, when there are multiple S-PMSI signalled for a said
(C-S,C-G), a said PE with state for (C-S,C-G) does not join more than
one of them -- that way even though the PIM assert doesn't trigger, we
avoid duplicates being forwarded down to the CEs
* (or, make it clear that the upstream dataplane check is mandatory and
that the PIM Asserts mechanism is not used on the MI-PMSI)
* (or, don't use S-PMSIs when their are dual-homed sources and PIM-based
C-multicast routing is used)

(the above does not apply if BGP-based C-multicast routing is used)

Thank you,

-Thomas


Danny McPherson :
> 
> Please consider today the start of a 2-week last call
> for draft-ietf-l3vpn-2547bis-mcast, available here:
> 
> http://tools.ietf.org/html/draft-ietf-l3vpn-2547bis-mcast-07
> 
> Input on this draft's suitability for publication as an
> Internet Standards Track document is solicited, feedback
> ends December 9, 2008.
> 
> Thanks in advance for your feedback!
> 
> Danny & Marshall