Hi Murray, I feel that our discussion and changes helped to make the document clearer, improved it. And I like the manner you've re-worked text in Section 4.2. I'll use it.
Regards, Greg On Fri, Dec 18, 2020 at 6:49 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > Hi Greg, > > Just to be clear, this is purely a suggestion on my part that might > improve the document. It's not a DISCUSS, so you're not obligated to > indulge my suggestions unless you think they're a worthwhile improvement. > > Yes, those all look good to me. For the 4.2 changes, I might suggest a > slightly different presentation: > > NEW: > > When a PE supporting this specification receives a C-multicast route for a > particular (C-S, C-G) for which all of the following are true: > > o the RT carried in the route results in importing the route into a > particular VRF on the PE; > > o the route carries the Standby PE BGP Community; and > > o the PE determines (via a method of failure detection that is outside the > scope of this document) that C-S is not reachable through some other PE > (more details are in Section 4.3), > > then the PE MAY install VRF PIM state corresponding to this Standby BGP > C-multicast route (the result will be that a PIM Join message will be sent > to the CE towards C-S, and that the PE will receive (C-S, C-G) traffic), > and the PE MAY forward (C-S, C-G) traffic received by the PE to other PEs > through a P-tunnel rooted at the PE. > > -MSK >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
