Subject: [bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 10 Feb 2021 23:29:04 +0000

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 27 Feb 2021 15:56:54 -0800

Hi Ali,

Sorry for the slow response -- the IESG was working hard the past two weeks
based on the page-count on the telechat.

> 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…

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.)

>    it is considered with a single IP address.”

Okay, this should work.

> AS>  Yes, this draft needs to be normative and the correction has been made.

Thanks!

> 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 V…

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