Hi, I corresponded with Amanda Baber and she says we can add a note to the IANA Considerations section of the IRB draft stating that "This document has been listed as an additional reference for the MAC/IP Advertisement route in the EVPN Route Type registry".
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Saturday, February 27, 2021 6:57 PM > To: Ali Sajassi (sajassi) <saja...@cisco.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-bess-evpn-inter-subnet- > forward...@ietf.org; bess-cha...@ietf.org; bess@ietf.org > Subject: Re: Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn- > inter-subnet-forwarding-09 > > [External Email. Be cautious of content] > > > Hi Ali, > > Sorry for the slow response -- the IESG was working hard the past two weeks > based on the page-count on the telechat. > > On Wed, Feb 10, 2021 at 11:29:04PM +0000, Ali Sajassi (sajassi) wrote: > > > > Hi Ben, > > > > I responded to your comments in the current thread but let me respond to > your comments in the draft’s ballot page more specifically here so that you > don’t have to go through that email. Please let me know if you have any > further > comments. > > Thanks for pulling out the latest datatracker comments, as those are the most > important ones. (I think there are a couple things in the other thread I > will also > reply to for completeness.) > > > > > 1) I think draft-ietf-bess-evpn-irb-extended mobility needs to be a > > normative reference, since "the procedures in [it] must be exercised" > > incorporates its procedures by reference. > > > > AS> The draft-ietf-bess-evpn-irb-extended-mobility describes the mobility > procedures when a host has several IP addresses and a single MAC address (or > vise versa); whereas, this draft describes the mobility procedures when the > host > has a single IP address and a single MAC address. As such the > extended-mobility > draft does not need to be a normative reference. There was some confusion > about IPv6 Link Local address & host mobility and I provided further > clarification > in the corresponding paragraph which is cut & pasted below for your > convenience. > > > > > > “Depending on the expexted TS's behavior, an NVE needs to handle at > > > > least the first bullet and should be able to handle the 2nd and the > > > > 3rd bullet. The following subsections describe the procedures for > > > > each of them where it is assumed that the MAC and IP addresses of a > > > > TS have one-to-one relationship (i.e., there is one IP address per > > > > MAC address and vice versa). The procedures for host mobility > > > > detection in the presence of many-to-one relationship is outside > > the > > > > scope of this document and it is covered in > > > > [I-D.ietf-bess-evpn-irb-extended-mobility]. The many-to-one > > > > relationship means many host IP addresses corresponding to a single > > > > host MAC address or many host MAC addresses corresponding to a > > single > > > > IP address. It should be noted that in case of IPv6, a link-local > > IP > > > > address does not count in many-to-one relationship because that > > > > address is confined to single Ethernet Segment and it is not used > > for > > > > host moblity (i.e., by definition host mobility is between two > > > > different Ethernet Segments). Therefore, when an IPv6 host is > > > > configured with both a Global Unicast address (or a Unique Local > > > > address) and a Link Local address, for the purpose of host > > mobility, > > > > it is considered with a single IP address.” > > Okay, this should work. > > > > > 2) Similarly, > > draft-ietf-idr-tunnel-encaps seems like a normative reference since we > > require the RT-2 route used by this document to be advertised along > > with the EC that indicates the tunnel type. > > > > AS> Yes, this draft needs to be normative and the correction has been made. > > Thanks! > > > > > 3) I still think we need to discuss whether this document Updates: 7432. > > RFC 7432 specifies the layout and interpretation of the RT-2 (MAC-IP > > Advertisement Route) EVPN NRLI, but we extend it in several ways > > (e.g., the Label1 and Label2 (which we spell "Label-1" and "Label-2", > > unfortunately) are only MPLS labels in 7432, but we expand that to > > also allow VNI values in those fields; likewise, 7432 gives no > > semantics at all for Label2, but we define some). I understand that > > 7432 only covers the L2 case but this document adds mixed L2/L3 (IRB), > > and furthermore that the IRB case can be inferred based on the contets > > of the fields in the advertisement, *if you know how to look for > > them*. But I still can't shake the feeling that this document should > > either be added as an additional reference for EVPN Route Type 2, or > > listed as Updating 7432, in order to indicate that we provide more > > details for the interpretation and contents of the RT-2 NLRI. > > > > AS> This document doesn’t introduce any new EVPN routes and it doesn’t > expand the definition of existing routes. With regard to allowing Label1 and > Label2 being use as either MPLS labels or VxLAN VNIs, this document uses the > precedence set in RFC8365. This document builds on top of RFC 7432 and > RFC8365. RFC 8365 describes the use of Label1 field in RT-2 as VNI because of > VxLAN encapsulation. Furthermore, the Lable2 field is not used at all in > either > RFC 7432 or RFC 8365 because its only application is for IRB use cases and > both > 7432 and 8365 are for pure layer-2 only. > > If Label2 is not used at all in RFC 7432 (which is true) then how can we say > that > RFC 7432 is the only reference for that field? > > I can go to IANA > (https://urldefense.com/v3/__https://www.iana.org/assignments/evpn/evpn.xh > tml__;!!NEt6yMaO-gk!VG06iaDGqWTCtTagaV- > P7sLkE54OST95IG1iVkpsfNbs5XXC8A9j_-CQhfwQ7C4$ ), find the entry for RT-2, > and get pointed at RFC 7432. If I want to implement EVPN and handle RT-2 > traffic, RFC 7432 tells me the layout of the "Route Type specific" NLRI field > for > the MAC/IP Advertisement Route, yes. It tells me that there may or may not be > an "MPLS Label2" field, but says absolutely nothing about how I process it or > what to do with its contents. > In other words, for an arbitrary packet I receive of RT-2, sometimes RFC > 7432 will tell me all I need to process it, and sometimes I *absolutely must > consult this document* in order to be able to process that packet. > How am I to know that I must consult this document, just starting from > https://urldefense.com/v3/__https://www.iana.org/assignments/evpn/evpn.xh > tml__;!!NEt6yMaO-gk!VG06iaDGqWTCtTagaV- > P7sLkE54OST95IG1iVkpsfNbs5XXC8A9j_-CQhfwQ7C4$ ? > > I really do not care whether this goal is achieved by adding this document as > an > additional reference in the IANA registry or by marking it as Updating RFC > 7432, > but I simply don't see how it's acceptable to give no indication at all that > the > semantics of a protocol field (MPLS Label2) for > RT-2 are described in this document. Isn't it the point of the "Reference" > field in the registry to tell me what I need to know in order to implement > and use > that codepoint? > > Perhaps there is a small precedent for RFC 8365 modifying the semantics to be > a > VNI value vs an MPLS label, but IMO that is bad precedent and we need not be > bound by it (and we could even rectify that now by also adding RFC > 8365 as a reference in the IANA registry). But the definition of any kind of > semantics at all for the Label2 field seems a qualitatively larger matter. > > Thanks, > > Ben _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
