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://www.iana.org/assignments/evpn/evpn.xhtml), 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://www.iana.org/assignments/evpn/evpn.xhtml ? 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
