Michael, The chairs asked me to take my comments to the list, so here you are.
1. Section 2.6 – RT5 synch * using non-zero ESI *and* non-zero GW-IP in the IP Prefix routes is non-backwards compatible with draft-ietf-bess-evpn-prefix-advertisement and will break interoperability with existing RRs. So I think it is a serious concern. * If you really need to encode the CE next-hop, my suggestion would be to use a different attribute. I think the TEA (tunnel encap attribute) could be used, with maybe the egress endpoint sub-TLV, or even a new TLV. 1. Multicast state synch * Section 1.2 talks about PIM DR election between PE1 and PE2. Doesn’t that imply PE1 and PE2 are attached to the same Broadcast Domain? And if so, existing procedures for routes type 7/8 would suffice? Could you please clarify? 1. Multicast sources * The doc talks about synchronization of states, or in other words multihomed receivers. But it does not talk about multihomed sources. Is that out of scope? If not, I think you should clarify how you avoid the downstream MVPN PE (assuming you use MVPN) from doing a UMH selection to the PE that does not receive the multicast stream from the multihomed PE. I would appreciate feedback on those points. Thank you! Jorge
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess