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.
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.” 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. 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. Regards, Ali
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
