Hi! I see that the change below has already been made in -09. However, I don’t think that an Update applies in this case.
In general, when Updating another document we’re basically saying: “change what was specified there for what is specified in here”…which, in this case, translates to rfc7432 implementations having to also be compliant with this document (for all cases). As far as I can tell, the extensions defined in this document are specific to the DCI case and not general to any EVPN scenario. If that is correct then we shouldn’t be formally Updating rfc7432. Having said that, Sasha is correct in pointing out that there are several differences with respect to rfc7432. That is properly captured in the text at the end of Section 2 (for the DCI scenario), without the need for the formal Update. Thanks! Alvaro. On February 20, 2018 at 5:40:59 PM, Rabadan, Jorge (Nokia - US/Mountain View) (jorge.raba...@nokia.com) wrote: 1. From my POV this draft should be marked as updating RFC 7432 in its metadata. The update should refer to several aspects including at least the following: a. Use of Ethernet PWs (see Figure 1 in the draft) as an Ethernet Segment. RFC 7432 defines Ethernet Segment as a set of Ethernet links that connect a customer sit to one or more PEs. b. Use of the Unknown MAC Route (UMR). RFC 7432 only says that a PE may flood unicast frames with unknown destination MAC to all other PEs but does not have to do that, with the decision being a matter of local policy; it neither defines any mechanisms that advertise a specific PE and a specific Ethernet Segment attached to this PE as the “default next Hop” for all unknown destination MAC addresses, nor prevents usage of such mechanisms. [JORGE] I marked it as updating RFC7432 and explained why in section 2.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
