Ben, Thanks for your help. I think Ali will add the text from Amanda in the next published version of the draft.
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Wednesday, June 9, 2021 1:28 PM > To: John E Drake <jdr...@juniper.net> > Cc: Ali Sajassi (sajassi) <saja...@cisco.com>; 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 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 > > > > AS> 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 > > > > AS> 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/e > > > vpn.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/ev > > > pn.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
