Hi John, As I wrote to Ali just now, my apologies for taking almost a month to reply.
Adding a note to the registry entry for the MAC/IP Advertisement route would be a great path forward, and would be enough for me to clear my discuss. (Just to confirm: I don't think this is in the published I-D yet, right?) Thanks again, Ben On Tue, May 11, 2021 at 09:26:08PM +0000, John E Drake wrote: > 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
