Re: [bess] RTG-DIR Telechat review of draft-ietf-bess-dci-evpn-overlay

[Alvaro Retana <[e-mail]>]

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) ([e-mail]) 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.