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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Jun 2021 10:27:38 -0700

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

---

From: John E Drake <[email-masked]>
Date: Wed, 9 Jun 2021 18:47:06 +0000

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

> Sent: Wednesday, June 9, 2021 1:28 PM
> To: John E Drake <[email-masked]>
> Cc: Ali Sajassi (sajassi) <[email-masked]>; The IESG <[email-masked]>; draft-
> [email-masked]; [email-masked];
> [email-masked]
> 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
> 
> > 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
> >
> >
> > > Sorry for the slow response -- the IESG was working hard the past
> > > two weeks based on the page-count on the telechat.
> > >
> > > 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"
> > > > 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.
> > > >
> > > >
> > > >    detection in the presence of many-to-one relationship is
> > > > outside the
> > > >
> > > >    IP address.  It should be noted that in case of IPv6, a
> > > > link-local IP
> > > >
> > > >    address is confined to single Ethernet Segment and it is not
> > > > used for
> > > >
> > > > 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.
> > > >
> > > > 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",
> > > > 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
> > > 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
> > > 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
> > > 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.
> > > 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.
> > > 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
> > > 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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 10 Jun 2021 18:02:07 +0000

Hi Ben,

I just published rev-14 of the draft with the updates to the IANA section.

Cheers,
Ali

From: John E Drake <[email-masked]>
Date: Wednesday, June 9, 2021 at 11:47 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Ali Sajassi (sajassi) <[email-masked]>, The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: RE: Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09
Ben,

Yours Irrespectively,

John

> > > https://urldefense.com/v3/__https://www.iana.org/assignments/evpn/ev<https://urldefense.com/v3/__https:/www.iana.org/assignments/evpn/ev>
> > > pn.xh