Re: [bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09
Hi Ben, I just published rev-14 of the draft with the updates to the IANA section. Cheers, Ali From: John E Drake Date: Wednesday, June 9, 2021 at 11:47 AM To: Benjamin Kaduk Cc: Ali Sajassi (sajassi) , The IESG , draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org , bess-cha...@ietf.org , bess@ietf.org Subject: RE: Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09 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 Juniper Business Use Only > -Original Message- > From: Benjamin Kaduk > Sent: Wednesday, June 9, 2021 1:28 PM > To: John E Drake > Cc: Ali Sajassi (sajassi) ; The IESG ; > draft- > ietf-bess-evpn-inter-subnet-forward...@ietf.org; bess-cha...@ietf.org; > bess@ietf.org > Subject: Re: Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn- > inter-subnet-forwarding-09 > > [External Email. Be cautious of content] > > > 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 +, 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 > > > Sent: Saturday, February 27, 2021 6:57 PM > > > To: Ali Sajassi (sajassi) > > > Cc: The IESG ; draft-ietf-bess-evpn-inter-subnet- > > > forward...@ietf.org; bess-cha...@ietf.org; bess@ietf.org > > > 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 +, 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 > > > > 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. > > > > > > > > > > > > “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 add
Re: [bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09
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 Juniper Business Use Only > -Original Message- > From: Benjamin Kaduk > Sent: Wednesday, June 9, 2021 1:28 PM > To: John E Drake > Cc: Ali Sajassi (sajassi) ; The IESG ; > draft- > ietf-bess-evpn-inter-subnet-forward...@ietf.org; bess-cha...@ietf.org; > bess@ietf.org > Subject: Re: Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn- > inter-subnet-forwarding-09 > > [External Email. Be cautious of content] > > > 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 +, 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 > > > Sent: Saturday, February 27, 2021 6:57 PM > > > To: Ali Sajassi (sajassi) > > > Cc: The IESG ; draft-ietf-bess-evpn-inter-subnet- > > > forward...@ietf.org; bess-cha...@ietf.org; bess@ietf.org > > > 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 +, 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 > > > > 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. > > > > > > > > > > > > “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 > > &
Re: [bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09
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 +, 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 > > Sent: Saturday, February 27, 2021 6:57 PM > > To: Ali Sajassi (sajassi) > > Cc: The IESG ; draft-ietf-bess-evpn-inter-subnet- > > forward...@ietf.org; bess-cha...@ietf.org; bess@ietf.org > > 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 +, 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, > > &
Re: [bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09
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 > Sent: Saturday, February 27, 2021 6:57 PM > To: Ali Sajassi (sajassi) > Cc: The IESG ; draft-ietf-bess-evpn-inter-subnet- > forward...@ietf.org; bess-cha...@ietf.org; bess@ietf.org > 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 +, 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;
Re: [bess] Benjamin Kaduk's DISCUSS ballot comment on draft-ietf-bess-evpn-inter-subnet-forwarding-09
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 +, 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
