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
