Alvaro, On the same issue: - UMR as an EVPN construct has been first defined in RFC 7543
- RFC 7543 has not been marked as updating RFC 7432, possibly its usage of UMR has been considered as not generic enough - Now the EVPN Overlay for DCI draft uses UMR in a context that is different from the original context of RFC 7543. Taking all these inputs together, which of these documents should be marked as updating RFC 7432? The options are, IMHO: - None - RFC 7543 (retroactively, possibly following a Erratum report) - The EVPN Overlay for DCI draft (and the RFC to which it will hopefully be progressed) - Both - but this is clearly superfluous... What do you think? Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com From: Alexander Vainshtein Sent: Wednesday, February 21, 2018 3:17 PM To: 'Alvaro Retana' <aretana.i...@gmail.com>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com> Cc: draft-ietf-bess-dci-evpn-overlay....@ietf.org; rtg-...@ietf.org; rtg-...@ietf.org; bess@ietf.org Subject: RE: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay Alvaro, PWs as an a “virtual ES” are also used in conjunction with EVPN in the scenarios that are not directly related to DCI. One example (actually pointed to me by Jorge during the review process) is the EVPN Virtual Ethernet Segment<https://tools.ietf.org/html/draft-sajassi-bess-evpn-virtual-eth-segment-02> draft (now expired). It is, of course, up to you to decide whether this justifies marking the draft I’ve reviewed as Updating RFC 7432 because it also defined PWs as a (virtual) ES for EVPN. Alternatively, it is possible to wait until the EVPN Virtual segment draft is resuscitated and progressed – but this can take quite some time... Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com> From: Alvaro Retana [mailto:aretana.i...@gmail.com] Sent: Wednesday, February 21, 2018 3:04 PM To: Alexander Vainshtein <alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com>>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Cc: draft-ietf-bess-dci-evpn-overlay....@ietf.org<mailto:draft-ietf-bess-dci-evpn-overlay....@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; rtg-...@ietf.org<mailto:rtg-...@ietf.org>; bess@ietf.org<mailto:bess@ietf.org> Subject: Re: RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay 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<mailto: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. ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
