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

From: John E Drake <[email-masked]>
Date: Tue, 11 May 2021 21:26:08 +0000

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 <[email-masked]>
> Sent: Saturday, February 27, 2021 6:57 PM
> To: Ali Sajassi (sajassi) <[email-masked]>
> Cc: The IESG <[email-masked]>; draft-ietf-bess-evpn-inter-subnet-
> [email-masked]; [email-masked]; [email-masked]
> 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