Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Tue, 13 Apr 2021 09:36:50 +0000

Hello,

This email begins a two-weeks WG adoption poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1].

Please review the draft and post any comments to the BESS working group list.

We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as an author or a contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR, copying the BESS mailing list. The document will not  progress without answers from all of the authors and contributors.

Currently, there are no IPR disclosures against this document.

If you are not listed as an author or a contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

This poll for adoption closes on April 27th 2021.

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 13 Apr 2021 07:29:08 -0400

As co-author of this BCP for edge peering to carry IPv4 NLRI  over an IPv6
single peer, eliminating the IPv4 peer, I support WG adoption.

I am not aware of any IPR related to this draft.

Thank you

Gyan

On Tue, Apr 13, 2021 at 5:37 AM Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:

> Hello,
>
>
>
> This email begins a two-weeks WG adoption poll for
> draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03 [1].
>
>
>
> We are also polling for knowledge of any undisclosed IPR that applies to
> this document, to ensure that IPR has been disclosed in compliance with
> IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>
>
>
> If you are listed as an author or a contributor of this document, please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR, copying the BESS mailing list. The document will
> not  progress without answers from all of the authors and contributors.
>
>
>
> If you are not listed as an author or a contributor, then please
> explicitly respond only if you are aware of any IPR that has not yet been
> disclosed in conformance with IETF rules.
>
>
>
> [1]
> https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/
>
>
>
>
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Apr 2021 13:37:32 +0000

I support adoption.

             Ron

Juniper Business Use Only
From: BESS <[email-masked]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, April 13, 2021 5:37 AM
To: [email-masked]; [email-masked]
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

[External Email. Be cautious of content]

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!R2BXBgD-HPt_GGxqMyjb69q4UCepxIGsVOCIprORnD_s0lkKTJDSdI9NM5F7XsD-$>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 13 Apr 2021 15:53:12 +0200

support adoption

On Tue, Apr 13, 2021 at 3:38 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> *From:* BESS <[email-masked]> *On Behalf Of *Bocci, Matthew (Nokia
> - GB)
> *Sent:* Tuesday, April 13, 2021 5:37 AM
> *To:* [email-masked];
> [email-masked]
> *Subject:* [bess] WG Adoption and IPR Poll for
> draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
>
>
>
> *[External Email. Be cautious of content]*
>
>
>
> Hello,
>
>
>
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!R2BXBgD-HPt_GGxqMyjb69q4UCepxIGsVOCIprORnD_s0lkKTJDSdI9NM5F7XsD-$>
>
>
>
>

---

From: Huaimo Chen <[email-masked]>
Date: Tue, 13 Apr 2021 13:55:55 +0000

Hi Everyone,

    I support the adoption.

Best Regards,
Huaimo

Hello,

Regards,

Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh%2F__%3B!!NEt6yMaO-gk!R2BXBgD-HPt_GGxqMyjb69q4UCepxIGsVOCIprORnD_s0lkKTJDSdI9NM5F7XsD-%24&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C1d92a460ab1e40d175be08d8fe815462%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539178742566131%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Bc2YsxUqnlQ9GOm2KJYI3Iy9pXHqadVev6IPNcJdvEw%3D&reserved=0>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Apr 2021 10:15:42 -0400

this document provides a clear description of how and why to use the 
tools we have standardized to improve operational capabilities as part 
of migrating to IPv6.  I support adopting this document.

Yours,
Joel

On 4/13/2021 5:36 AM, Bocci, Matthew (Nokia - GB) wrote:
> Hello,
> 
> This email begins a two-weeks 
> WG adoption pollfordraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03[1].**
> 
> relevant undisclosed IPR, copying the BESS mailing list. The document 
> will not  progress without answers from all of the authors and contributors.
> 
> explicitly respond only if you are aware of any IPR that has not yet 
> been disclosed in conformance with IETF rules.
> 
> Thispollfor adoption closes on April 27^th 2021.
> 
> Regards,
> 
> Matthew and Stephane
> 
> [1]https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/ 
> <https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/>
> 
>

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 13 Apr 2021 07:56:35 -0700

Hi,
I've read the draft and found it very useful. It addresses a real problem
and allows the operator to simplify the control plane. I support the
adoption of draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh by the WG.

Regards,
Greg

---

From: "Mankamana Mishra (mankamis)" <[email-masked]>
Date: Tue, 13 Apr 2021 16:00:32 +0000

Support, not aware of any IPR

Mankamana
________________________________
From: Bocci, Matthew (Nokia - GB) <[email-masked]>
Sent: Tuesday, April 13, 2021 2:36:50 AM
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,

Matthew and Stephane

---

From: Michael McBride <[email-masked]>
Date: Tue, 13 Apr 2021 17:54:58 +0000

Support.

Since the draft states "The goal of this document is to provide operators interoperability test result data from external BGP PE-CE edge peering between vendors Cisco, Juniper, Arista, Nokia and Huawei.", the authors should consider moving that data up and out of the appendix as well as mention interoperability testing in the abstract/intro.

mike

From: BESS <[email-masked]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, April 13, 2021 2:37 AM
To: [email-masked]; [email-masked]
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C5ad85b9d846f42e6c80008d8fe5fb74f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539034368863506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wwX8GQUTAS03UsrRG%2BJC7v1RaVyRx3sZ8pR%2B33N9p10%3D&reserved=0>

---

From: Lili Wang <[email-masked]>
Date: Tue, 13 Apr 2021 18:15:21 +0000

As one of the co-authors of this BCP for edge peering to carry IPv4 NLRI  over an IPv6 single peer, eliminating the IPv4 peer, I support WG adoption.

Thanks,

Lili

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Tuesday, April 13, 2021 at 5:37 AM
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, April 13, 2021 at 5:37 AM

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!Xa-VMVN4aoeF4YD6t7swC_DbrbhSvdr57DhmRsur9XyFknR8WxoVex9rwhkJYtI$>

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 13 Apr 2021 15:22:01 -0400

Hi Mike

Good points.  I will make the recommended adjustments.

Thanks

Gyan

On Tue, Apr 13, 2021 at 1:55 PM Michael McBride <
[email-masked]> wrote:

> Support.
>
>
>
> Since the draft states “The goal of this document is to provide operators
> interoperability test result data from external BGP PE-CE edge peering
> between vendors Cisco, Juniper, Arista, Nokia and Huawei.”, the authors
> should consider moving that data up and out of the appendix as well as
> mention interoperability testing in the abstract/intro.
>
>
>
> mike
>
>
>
> *Sent:* Tuesday, April 13, 2021 2:37 AM
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh%2F&data=04%7C01%7Cmichael.mcbride%40futurewei.com%7C5ad85b9d846f42e6c80008d8fe5fb74f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539034368863506%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wwX8GQUTAS03UsrRG%2BJC7v1RaVyRx3sZ8pR%2B33N9p10%3D&reserved=0>
>
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 13 Apr 2021 19:26:06 +0000

Support.

Jeffrey

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!VMYOi4tt6-X5KN_IRyliW_p2htN4RoiTgjain3m3rzxpA9R3bEnuZUkY-WqGhK4m$>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Apr 2021 19:41:52 +0000

I supported the WG adoption for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03.
However, I have some questions about the draft, hope the authors can address them:

  *   Section 3 (Page 5) states "The goal of this document is to provide operators interoperability test result data from ..."

But I can't find any section in the draft describing the "interoperability test result".

  *   RFC8950 already allows IPv4 NLRI with next hop address being IPv6, and RFC4684 allows the Next Hop address to be either IPv4 or IPv6.  It is not very clear to me of the additional features enabled by this draft. Is it PE-CE? The draft did mention the value of applying RFC8950 to PE-CE, but I am not sure if it is the only feature. Can authors clarify?

Best regards,
Linda Dunbar

---------- Forwarded message ---------
From: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Date: Tue, Apr 13, 2021 at 5:37 AM
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C00d16e81bee7402c471508d8fe722946%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539113559887467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vJT5wlJa8YHphfqT8v5HI%2B4jXPY3xaiW6BerWtYRMkM%3D&reserved=0>

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C00d16e81bee7402c471508d8fe722946%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539113559897457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=A%2BXrIgTcTKVnwju6A2l4W9p7JUaJwwXLmuVYpDpfXJs%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C00d16e81bee7402c471508d8fe722946%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539113559897457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OCL69w254g190jdZ0ud8jx5PpPUauPFidl7GeJw2Vko%3D&reserved=0>

Gyan Mishra

Network Solutions Architect

Email [email-masked]<mailto:[email-masked]>

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 13 Apr 2021 15:58:31 -0400

Hi Linda

Responses in-line

Kind Regards

Gyan

On Tue, Apr 13, 2021 at 3:42 PM Linda Dunbar <[email-masked]>
wrote:

> I supported the WG adoption for
> draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03.
>
>    - Section 3 (Page 5) states “The goal of this document is to provide
>    operators interoperability test result data from …”
>
> But I can’t find any section in the draft describing the “interoperability
> test result”.
>
> Gyan> The test results are  in the appendix which we plan to move it up to
> section 3.
>
>    - RFC8950 already allows IPv4 NLRI with next hop address being IPv6,
>    and RFC4684 allows the Next Hop address to be either IPv4 or IPv6.  It is
>    not very clear to me of the additional features enabled by this draft. Is
>    it PE-CE? The draft did mention the value of applying RFC8950 to PE-CE, but
>    I am not sure if it is the only feature. Can authors clarify?
>
> Gyan> Yes PE-CE is the only feature. This drafts goal is focused on PE-CE
> Core and Data Center or any flavor edge peering and provide vendor
> interoperability results using RFC 8950 next hop encoding extension to
> carry control plane IPv4 NLRI over an IPv6 next hop.
>
> Best regards,
>
> Linda Dunbar
>
>
>
>
>
>
>
>
>
> From: *Bocci, Matthew (Nokia - GB)* <[email-masked]>
> Subject: [bess] WG Adoption and IPR Poll for
> To: [email-masked] <
> [email-masked]>,
> [email-masked] <[email-masked]>
>
>
>
> Hello,
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C00d16e81bee7402c471508d8fe722946%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539113559887467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=vJT5wlJa8YHphfqT8v5HI%2B4jXPY3xaiW6BerWtYRMkM%3D&reserved=0>
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C00d16e81bee7402c471508d8fe722946%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539113559897457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=A%2BXrIgTcTKVnwju6A2l4W9p7JUaJwwXLmuVYpDpfXJs%3D&reserved=0>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C00d16e81bee7402c471508d8fe722946%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539113559897457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OCL69w254g190jdZ0ud8jx5PpPUauPFidl7GeJw2Vko%3D&reserved=0>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Apr 2021 20:16:55 +0000

Gyan,

Thank you very much for the explanation.
If PE-CE is the only feature enabled by the draft, can you make it more clear in the introduction section?
The following statement in the Abstraction doesn't quite clearly say about PE-CE using RFC8950.
"This document describes the critical use case and OPEX savings of
being able to leverage the MP-BGP capability exchange usage as a pure
transport, allowing both IPv4 and IPv6 to be carried over the same
(Border Gateway Protocol) BGP TCP session."

Thank you.
Linda
From: Gyan Mishra <[email-masked]>
Sent: Tuesday, April 13, 2021 2:59 PM
To: Linda Dunbar <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]
Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hi Linda

Responses in-line

Kind Regards

Gyan

On Tue, Apr 13, 2021 at 3:42 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
I supported the WG adoption for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03.
However, I have some questions about the draft, hope the authors can address them:

Gyan> The test results are  in the appendix which we plan to move it up to section 3.

  *   RFC8950 already allows IPv4 NLRI with next hop address being IPv6, and RFC4684 allows the Next Hop address to be either IPv4 or IPv6.  It is not very clear to me of the additional features enabled by this draft. Is it PE-CE? The draft did mention the value of applying RFC8950 to PE-CE, but I am not sure if it is the only feature. Can authors clarify?
Gyan> Yes PE-CE is the only feature. This drafts goal is focused on PE-CE Core and Data Center or any flavor edge peering and provide vendor interoperability results using RFC 8950 next hop encoding extension to carry control plane IPv4 NLRI over an IPv6 next hop.
Best regards,
Linda Dunbar

---------- Forwarded message ---------
From: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>
Date: Tue, Apr 13, 2021 at 5:37 AM
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
To: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255284889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ldtU%2Fe4da4JKOXJHbQ0FKlnonmySuHDvu7w7T5iefBg%3D&reserved=0>

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255294883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TNrnLHITuLPy9CpIbGJhIkahJRxtBSBctUxIcCCJFnw%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255304883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hL5vkXtg1W0WPbBPF4NdeNiVeVbnGddfhCwYSfcejKg%3D&reserved=0>

Gyan Mishra

M 301 502-1347

_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255304883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qyW7LlCC59Vlv%2Fplpe5xC9%2FXoYTgm6sRP6yUk7KeGmc%3D&reserved=0>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255314875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lO%2Byi4rovhNTcvXRhIL%2B5Q5GMuWkr4gPv8TcZuGr5Jk%3D&reserved=0>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 13 Apr 2021 16:26:02 -0400

Hi Linda

Thank you for your comments and I will make the abstract clearer by adding
PE-CE as the only relevance for this drafts interoperability testing.

Thank you

Gyan

On Tue, Apr 13, 2021 at 4:16 PM Linda Dunbar <[email-masked]>
wrote:

> The following statement in the Abstraction doesn’t quite clearly say about
> PE-CE using RFC8950.
>
> *“This document describes the critical use case and OPEX savings of*
>
> *being able to leverage the MP-BGP capability exchange usage as a pure*
>
> *transport, allowing both IPv4 and IPv6 to be carried over the same*
>
> *(Border Gateway Protocol) BGP TCP session.”*
>
>
>
> Thank you.
>
> Linda
>
> *From:* Gyan Mishra <[email-masked]>
> *Sent:* Tuesday, April 13, 2021 2:59 PM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]
> *Subject:* Re: [bess] WG Adoption and IPR Poll for
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255284889%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ldtU%2Fe4da4JKOXJHbQ0FKlnonmySuHDvu7w7T5iefBg%3D&reserved=0>
>
>
>
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255294883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=TNrnLHITuLPy9CpIbGJhIkahJRxtBSBctUxIcCCJFnw%3D&reserved=0>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255304883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hL5vkXtg1W0WPbBPF4NdeNiVeVbnGddfhCwYSfcejKg%3D&reserved=0>
>
> *Gyan Mishra*
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fbess&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255304883%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qyW7LlCC59Vlv%2Fplpe5xC9%2FXoYTgm6sRP6yUk7KeGmc%3D&reserved=0>
>
> --
>
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C45d53282841b4bcb4de408d8feb68a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637539407255314875%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lO%2Byi4rovhNTcvXRhIL%2B5Q5GMuWkr4gPv8TcZuGr5Jk%3D&reserved=0>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Tue, 13 Apr 2021 23:32:44 +0000

I support adoption of this draft.

I have a couple of comments:

In section 6, “Changes resulting from a single IPv6 transport peer carrying IPv4 NLRI and IPv6 NLRI below:”

It may be worth noting that this model may have some change to feature that use Pop-n-Forward MPLS-label forwarding.

There may be some platform specific nuances.  Pop-n-Forward is used by features like EPE and L3VPN (per-nexthop label). EPE is an IPv4/v6-Unicast feature, so it may be in-scope even if we consider L3VPN currently out of scope.

Today, v4 routes and v6 routes get a different EPE-label/VPN-label, because of different v4/v6 EBGP peering.

With single IPv6-transport, v4 and v6 routes may allocate the same MPLS-label, as it is the same v6-nexthop. So whether a platform supports such MPLS-in-IP[v4/v6] forwarding for both v4 and v6 traffic when using a single nexthop is a question..

I wonder if the test-cases could be broken down into more granular pieces:

               V4 route with V6 nexthop (single-hop EBGP).
               V4 route with V6 nexthop (multi-hop EBGP).
               V4 route with V6 nexthop (multi-hop IBGP, tunneled)
               MPLS route with V6 nexthop (single-hop away)
               MPLS route with V6 nexthop (multi-hop away)

     Where the MPLS payload can be either v4 or v6.

Different platforms of the same vendor may have different capabilities. So draft may need to record as part of test-results, which specific platforms were tested.

Thanks
Kaliraj

From: BESS <[email-masked]> on behalf of Bocci, Matthew (Nokia - GB) <[email-masked]>
Date: Tuesday, April 13, 2021 at 2:37 AM
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
[External Email. Be cautious of content]

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!RHh1RdZRCsfZX-7cqzDM-y25JSr4cNV_xgzlk2PNsQtpUO2Zm72Z_T66Yr6hkkZv$>

---

From: <[email-masked]>
Date: Wed, 14 Apr 2021 08:38:56 +0800 (CST)

Support the adoption.

Thanks,

Sandy

原始邮件

发件人：Bocci,Matthew(Nokia-GB)
收件人：[email-masked];[email-masked];
日 期 ：2021年04月13日 17:37
主 题 ：[bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

 

 

 

 

 

 

 

Regards,

Matthew and Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 13 Apr 2021 21:32:41 -0400

Hi Kaliraj

Thank you for your comments.

Responses in-line

Many thanks

Gyan

On Tue, Apr 13, 2021 at 7:33 PM Kaliraj Vairavakkalai <kaliraj=
[email-masked]> wrote:

> It may be worth noting that this model may have some change to feature
> that use Pop-n-Forward MPLS-label forwarding.
>
>
>
> There may be some platform specific nuances.  Pop-n-Forward is used by
> features like EPE and L3VPN (per-nexthop label). EPE is an IPv4/v6-Unicast
> feature, so it may be in-scope even if we consider L3VPN currently out of
> scope.
>
> Gyan> From the edge perspective PE-CE edge peering is in scope for any
> softwire mesh framework where IPv4 edge is transported over an IPv6-Only
> core which could  be an IP, MPLS, SR.   So all the middle core flavors IP,
> MPLS, SR are in scope for the single IPv6 peer PE-CE edge.  We also have to
> take into account L3 VPN per CE aggregate label as now that would be both
> IPv4 and IPv6 versus per prefix  label.
>
>  Gyan>  Agreed with the separate edge PE-CE IPv4 and IPv6 peers, IPv4
> prefixes have VPN label  PE-RR and are carried in AFI/SAFI 1/28 and IPv6
> edge prefixes VPN label PE-RR are carried in AFI/SAFI 2/128.
>
> With single IPv6-transport, v4 and v6 routes may allocate the same
> MPLS-label, as it is the same v6-nexthop. So whether a platform supports
> such MPLS-in-IP[v4/v6] forwarding for both v4 and v6 traffic when using a
> single nexthop is a question..
>
>  Gyan>  Agreed.  With a single IPv6 edge PE-CE peer for both IPv4 and
> IPv6 NLRI , IPv4 and IPv6 edge prefixes may have the same  VPN label  PE-RR
> using AFI/SAFI 2/128 for both IPv4 and IPv6 prefixes.  So the platform
> specific question is if both IPv4 and IPv6 NLRI AFI/SAFI 1/1 and 2/1 - can
> they both be carried by the same VPN label PE-RR peer AFI/SAFI 2/128.  So
> the PE-RR VPN-IPv4 that was carrying IPv4 NLRI would not be needed as IPv4
> NLRI would be carried by AFI/SAFI 2/128.
>
So this will be in scope as part of the interoperability testing to ensure
> that by combining the IPv4 and IPv6 NLRI at the edge over IPv6 transport
> the caveat is that in a VPN overlay  PE-RR VPN label VPN-IPv6 AFI/SAFI
> 2/128 will now have to carry both IPv4 and IPv6 NLRI.
>
We would also QA test if it’s possible to keep the VPN label separate for
> v4 and v6 if possible, so even though the edge is a single IPv6 peer to
> have separate VPN label and peer PE-RR as before with IPv4 NLRI using
> VPN-IPv4 AFI/SAFI 1/128 and IPv6 NLRI using VPN-IPv6 AFI/SAFI 2/128.
>

              I will expand on this in the section 3.

>  Gyan> Agreed.  I will add all the permutations of scenarios to section 3.
>
> Different platforms of the same vendor may have different capabilities. So
> draft may need to record as part of test-results, which specific platforms
> were tested.
>
>  Gyan> Agreed.  We will record platform and code revisions tested.
>
> Thanks
>
> Kaliraj
>
>
>
>
>
> *From: *BESS <[email-masked]> on behalf of Bocci, Matthew (Nokia -
> GB) <[email-masked]>
> *Date: *Tuesday, April 13, 2021 at 2:37 AM
> *To: [email-masked] <
> *Subject: *[bess] WG Adoption and IPR Poll for
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!RHh1RdZRCsfZX-7cqzDM-y25JSr4cNV_xgzlk2PNsQtpUO2Zm72Z_T66Yr6hkkZv$>
>
>
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Wed, 14 Apr 2021 01:59:16 +0000

Thanks Gyan,

Just a minor clarification:

I am less concerned about control-plane, that may just work.

My comment about platform-dependency was about whether the Pop-n-Forward forwarding will work for the MPLS label. E.g. if same label is used for both v4,v6 routes, then in forwarding plane, the box may need to peak into the mpls payload traffic, to determine whether it needs to send a v4 or v6 pkt towards the CE. Whether the platform supports such forwarding ability is the question.

Thanks
Kaliraj
From: Gyan Mishra <[email-masked]>
Date: Tuesday, April 13, 2021 at 6:33 PM
To: Kaliraj Vairavakkalai <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>
Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
[External Email. Be cautious of content]

Hi Kaliraj

Responses in-line

Many thanks

Gyan

On Tue, Apr 13, 2021 at 7:33 PM Kaliraj Vairavakkalai <kaliraj=[email-masked]<mailto:[email-masked]>> wrote:
I support adoption of this draft.

There may be some platform specific nuances.  Pop-n-Forward is used by features like EPE and L3VPN (per-nexthop label). EPE is an IPv4/v6-Unicast feature, so it may be in-scope even if we consider L3VPN currently out of scope.
Gyan> From the edge perspective PE-CE edge peering is in scope for any softwire mesh framework where IPv4 edge is transported over an IPv6-Only core which could  be an IP, MPLS, SR.   So all the middle core flavors IP, MPLS, SR are in scope for the single IPv6 peer PE-CE edge.  We also have to take into account L3 VPN per CE aggregate label as now that would be both IPv4 and IPv6 versus per prefix  label.
Today, v4 routes and v6 routes get a different EPE-label/VPN-label, because of different v4/v6 EBGP peering.
 Gyan>  Agreed with the separate edge PE-CE IPv4 and IPv6 peers, IPv4 prefixes have VPN label  PE-RR and are carried in AFI/SAFI 1/28 and IPv6 edge prefixes VPN label PE-RR are carried in AFI/SAFI 2/128.
With single IPv6-transport, v4 and v6 routes may allocate the same MPLS-label, as it is the same v6-nexthop. So whether a platform supports such MPLS-in-IP[v4/v6] forwarding for both v4 and v6 traffic when using a single nexthop is a question..
 Gyan>  Agreed.  With a single IPv6 edge PE-CE peer for both IPv4 and IPv6 NLRI , IPv4 and IPv6 edge prefixes may have the same  VPN label  PE-RR using AFI/SAFI 2/128 for both IPv4 and IPv6 prefixes.  So the platform specific question is if both IPv4 and IPv6 NLRI AFI/SAFI 1/1 and 2/1 - can they both be carried by the same VPN label PE-RR peer AFI/SAFI 2/128.  So the PE-RR VPN-IPv4 that was carrying IPv4 NLRI would not be needed as IPv4 NLRI would be carried by AFI/SAFI 2/128.
So this will be in scope as part of the interoperability testing to ensure that by combining the IPv4 and IPv6 NLRI at the edge over IPv6 transport the caveat is that in a VPN overlay  PE-RR VPN label VPN-IPv6 AFI/SAFI 2/128 will now have to carry both IPv4 and IPv6 NLRI.
We would also QA test if it’s possible to keep the VPN label separate for v4 and v6 if possible, so even though the edge is a single IPv6 peer to have separate VPN label and peer PE-RR as before with IPv4 NLRI using VPN-IPv4 AFI/SAFI 1/128 and IPv6 NLRI using VPN-IPv6 AFI/SAFI 2/128.

From: BESS <[email-masked]<mailto:[email-masked]>> on behalf of Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>

Hello,

Regards,
Matthew and Stephane

Juniper Business Use Only
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgIZm1nQb$>
--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgPTYJFvQ$>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 13 Apr 2021 22:27:54 -0400

Thanks Kaliraj for clarification.  Good point.

I will add comments to section 3 and 4 related to this.

If the control plane for IPv4 and IPv6 can remain separate for SAFI 128 or
129, the data plane would then know the payload as the data plane
forwarding would follow the control plane AFI and would not need the deep
packet inspection into the MPLS payload.  Agreed?

This will all be included in the testing to determine the optimal overall
solution.

Kind Regards

Gyan

On Tue, Apr 13, 2021 at 9:59 PM Kaliraj Vairavakkalai <[email-masked]>
wrote:

> My comment about platform-dependency was about whether the Pop-n-Forward
> forwarding will work for the MPLS label. E.g. if same label is used for
> both v4,v6 routes, then in forwarding plane, the box may need to peak into
> the mpls payload traffic, to determine whether it needs to send a v4 or v6
> pkt towards the CE. Whether the platform supports such forwarding ability
> is the question.
>
>
>
> Thanks
>
> Kaliraj
>
> *From: *Gyan Mishra <[email-masked]>
> *Date: *Tuesday, April 13, 2021 at 6:33 PM
> *To: *Kaliraj Vairavakkalai <[email-masked]>
> *Cc: *Bocci, Matthew (Nokia - GB) <[email-masked]>, [email-masked]
> <[email-masked]>,
> [email-masked] <
> [email-masked]>
> *Subject: *Re: [bess] WG Adoption and IPR Poll for
>  Gyan>  Agreed.  With a single IPv6 edge PE-CE peer for both IPv4 and IPv6
> NLRI , IPv4 and IPv6 edge prefixes may have the same  VPN label  PE-RR
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bess__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgIZm1nQb$>
>
> --
>
>
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TRrLASKRAwVabaAjaYw6GycMgvRCOcZqwEzLB_gdI291NWcjL4Q0mbwkgPTYJFvQ$>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Kaliraj Vairavakkalai <[email-masked]>
Date: Wed, 14 Apr 2021 03:06:19 +0000

Agreed. If the label allocated for 1/128 route is different from the 2/128 route, even if the routes share the same nexthop, then the label can potentially be used to distinguish whether we need v4 or v6 forwarding.

That means the label allocation in control-plane may need to consider the AFI also as part of the key, beside the nexthop, when doing per-nexthop label allocation. The platforms that don’t support peaking into the mpls-packet in forwarding-plane may need to implement such a label allocation scheme in control-plane.

But another thing is: given no v4-interface-address exists towards the CE, whether pointing a label towards v4-forwarding is possible is another question. Forwarding-experts of the concerned platform may have a better idea.

Hence the suggestion on asking the respective platform-owners to confirm the scenario is supported. They may use either same-label or different labels for v4,v6; whichever method works for the platform.

Thanks
Kaliraj
Date: Tuesday, April 13, 2021 at 7:28 PM

If the control plane for IPv4 and IPv6 can remain separate for SAFI 128 or 129, the data plane would then know the payload as the data plane forwarding would follow the control plane AFI and would not need the deep packet inspection into the MPLS payload.  Agreed?

This will all be included in the testing to determine the optimal overall solution.

Kind Regards

Gyan

On Tue, Apr 13, 2021 at 9:59 PM Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Gyan,

Thanks
Kaliraj
From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 13, 2021 at 6:33 PM
To: Kaliraj Vairavakkalai <[email-masked]<mailto:[email-masked]>>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
[External Email. Be cautious of content]

Hi Kaliraj

Responses in-line

Many thanks

Gyan

Hello,

Regards,
Matthew and Stephane

Gyan Mishra

M 301 502-1347

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TTV94R9E06kpmjVoI73JYVMmBTOp-iWcwhdDM_-JifrYJPOZW074fHPa5xzFZ_t_$>

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 13 Apr 2021 23:43:54 -0400

Thank you Kaliraj for your valuable feedback.

We will take it back to the team.

Kind Regards

Gyan

On Tue, Apr 13, 2021 at 11:06 PM Kaliraj Vairavakkalai <[email-masked]>
wrote:

> Agreed. If the label allocated for 1/128 route is different from the 2/128
> route, even if the routes share the same nexthop, then the label can
> potentially be used to distinguish whether we need v4 or v6 forwarding.
>
>
>
> That means the label allocation in control-plane may need to consider the
> AFI also as part of the key, beside the nexthop, when doing per-nexthop
> label allocation. The platforms that don’t support peaking into the
> mpls-packet in forwarding-plane may need to implement such a label
> allocation scheme in control-plane.
>
>
>
> But another thing is: given no v4-interface-address exists towards the CE,
> whether pointing a label towards v4-forwarding is possible is another
> question. Forwarding-experts of the concerned platform may have a better
> idea.
>
>
>
> Hence the suggestion on asking the respective platform-owners to confirm
> the scenario is supported. They may use either same-label or different
> labels for v4,v6; whichever method works for the platform.
>
>
>
> Thanks
>
> Kaliraj
>
> *Date: *Tuesday, April 13, 2021 at 7:28 PM
> <https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!TTV94R9E06kpmjVoI73JYVMmBTOp-iWcwhdDM_-JifrYJPOZW074fHPa5xzFZ_t_$>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: John E Drake <[email-masked]>
Date: Wed, 14 Apr 2021 15:14:38 +0000

Support, this is good work

Yours Irrespectively,

John

Hello,

Regards,
Matthew and Stephane

[1] https://datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh/__;!!NEt6yMaO-gk!UW4uSasGoPwLgoFYHVKax-l74OAP140DsVhE7rsfBVcVffJgRKDUtXLhwE9K1Qs$>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 14 Apr 2021 15:25:01 -0700

Support as co-author.
Not aware of any undisclosed IPR.

Thanks,
Jeff

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Thu, 15 Apr 2021 00:29:15 +0000

Hi,

I have read the document and support the adoption.

Thanks,
Jingrong

From: BESS [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, April 13, 2021 5:37 PM
To: [email-masked]; [email-masked]
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,
Matthew and Stephane

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 15 Apr 2021 11:50:30 +0800

Yes，Support its adoption.

I think this draft gives the operator confidences to deploy pure IPv6 transport network in coming days.

Some comments for the drafts are below:

1.     Should the test scenarios, test items and test results be described in more detail in the body of this draft?

2.     I think such guidelines can also be used within the operator’s network domain(PE-RR, or PE-PE), not only the emphasized PE-CE edge.

3.     Is it necessary for the section 4?  I think changing that content to describe some guidelines for how to using the RFC 8950 may be more beneficial?

Some Nits:

1.     Section 8  Security Considerations:

“The extensions defined in this document allow BGP to propagate reachability information about IPv6 routes over an MPLS IPv4 core network.”

Should it be:

“The extensions defined in this document allow BGP to propagate reachability information about IPv4 routes over an IPv6 core network.” 

2.     Section 6 “Operational Consideration”  said “Both IPv4 and IPv6 peer now exists under the IPv6 address family configuration.”  

Should it be “Both IPv4 and IPv6 prefixes reachable information now exists under the IPv6 address family configuration.”

3.     A.1 Router and Switch Vendors Support and Quality Assurance:

GUI----》GUA

Best Regards

Aijun Wang

China Telecom

From: [email-masked] <[email-masked]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Tuesday, April 13, 2021 5:37 PM
To: [email-masked]; [email-masked]
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,

Matthew and Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 15 Apr 2021 00:56:42 -0400

Hi Aijun

Responses in-line

Many Thanks for your valuable feedback!

Gyan

On Wed, Apr 14, 2021 at 11:50 PM Aijun Wang <[email-masked]>
wrote:

> 1.     Should the test scenarios, test items and test results be
> described in more detail in the body of this draft?
>
>      Gyan> Yes this will be moved from Appendix to section 3
interoperability testing in the next revision

> 2.     I think such guidelines can also be used within the operator’s
> network domain(PE-RR, or PE-PE), not only the emphasized PE-CE edge.
>

     Gyan> From the feedback and test use cases as the PE-CE IPv6 only
peering applies to all IPv6-only  IP / MPLS / SR core scenarios and is an
integral part of the testing.  So I will add PE-RR or PE-PE (No RR)
IPv6-only peering with SAFI stacking as well to section 3.  I will expand
the BCP to cover IPv6 only core software mesh framework RFC 5565 and
reasons why the “BGP free” P core is not recommended to be dual stacked and
should be IPv6-Only and in that section will add the control plane
IPv6-Only PE-RR peering.  From some of the feedback we will test both per
prefix VPN and Per CE next hop label allocation modes.  Also many more
permutations.

> 3.     Is it necessary for the section 4?  I think changing that content
> to describe some guidelines for how to using the RFC 8950 may be more
> beneficial?
>
>  Gyan> Agreed. I can add some pertinent verbiage that relates to the
> testing.
>
> Some Nits:
>
> “The extensions defined in this document allow BGP to propagate
> reachability information about IPv6 routes over an MPLS IPv4 core network.”
>
> Should it be:
>
> “The extensions defined in this document allow BGP to propagate
> reachability information about IPv4 routes over an IPv6 core network.”
>
>  Gyan> Typo.  Good catch!
>
> 2.     Section 6 “Operational Consideration”  said “Both IPv4 and IPv6
> peer now exists under the IPv6 address family configuration.”
>
> Should it be “Both IPv4 and IPv6 prefixes reachable information now exists
> under the IPv6 address family configuration.”
>
>  Gyan> Yes will fix. The IPv4 and IPv6 NLRI AFI/SAFI is now under the
> IPv6 address family.
>
          Gyan> Will fix typo

>
>
>
>
>
>
> Best Regards
>
>
>
> Aijun Wang
>
> China Telecom
>
>
>
> *From:* [email-masked] <[email-masked]> *On Behalf Of *Bocci,
> Matthew (Nokia - GB)
> *Sent:* Tuesday, April 13, 2021 5:37 PM
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Chenshuanglong <[email-masked]>
Date: Sat, 17 Apr 2021 01:54:11 +0000

Support as co-author.

Best Regards
Shuanglong

From: Bocci, Matthew (Nokia - GB) [mailto:[email-masked]]
Sent: Tuesday, April 13, 2021 5:37 PM
To: [email-masked]; [email-masked]
Subject: WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,
Matthew and Stephane

---

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Sat, 17 Apr 2021 02:44:06 +0000

Hi WG,

This document provides a valid solution to address transition scenario from the IPv4 edge to the IPv6 core, which avoids IPv4 address depletion.
Support adoption.

Best
Xuesong

Hello,

Regards,
Matthew and Stephane

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 17 Apr 2021 04:21:13 +0000

Hello Authors,

A few comments/observations on this draft:

  1.  The BCP categorization does not seem right for this document and perhaps informational is better. Is this really something that has already seen widespread deployment such that the IETF community can say that it is the best “current” practice?
  2.  I do not think that the term “legacy” is appropriate for IPv4 and IPv4 based services.
  3.  RFC5565 specifies the dual-stack PEs and IPv6-only P routers for delivering IPv4-based BGP services between the PEs via various mechanisms. This proposal brings that notion to the PE-CE link. The CE is dual-stack and the PE is IPv6-only. However, it is not describing how the forwarding plane works between PE and CE – an explanation or reference is required and without that clarity I am unable to understand how to actually deploy this.
  4.  The document touches on IXP deployments, but again does not actually cover how the forwarding works nor provides references for how this proposal works for that deployment.
  5.  Is section 4 really required? Wouldn’t a simple reference to RFC8950 suffice? The BGP signalling part for IPv4 over a single IPv6 peering and over IPv6 NH is already specified and covered in various Standards Track document (esp RFC8950) – so using their references rather than repeating them would be better.
  6.  If/when this gets published as an RFC, is the goal of this document to describe interop test results between specific vendors, OR is it do document the design, its operational considerations, and how it can be realized? E.g. RFC7938 – does something of that sorts. I do not think that IETF RFCs are good for documenting interop and it is better done via other “live” documents since these aspects change over course of time. It might even give an exclusionary impression for vendors not included in this document or those who might add this capability down the line. I’ve generally seen implementation status sections being taken out of Standards Track documents before publishing as RFC.
  7.  I would request the authors to explicitly clarify the Objective/Purpose of this draft in more precise and crisp manner in a section of its own so the WG knows what it is taking up. It might also help repeating the same throughout the document.
  8.  Finally, there is some language as follows in Sec 3 which perhaps needs to be revisiting?

   The test results published from this document provide concrete
   evidence that this is now the Best Practice for Edge peering.  The
   document will be the de-facto standard for operators to now use a
   single PE-CE Edge IPv6 peer to carry both IPv4 and IPv6 NLRI.

Would also request the WG and chairs to share their views on some of the above points – (1), (2), (6) and (7). Clarity on these points is, IMHO, important and necessary before the WG considers adoption of this document.

Thanks,
Ketan

From: BESS <[email-masked]> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: 13 April 2021 15:07
To: [email-masked]; [email-masked]
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,
Matthew and Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 17 Apr 2021 02:40:11 -0400

Hi Ketan

Thanks you for your feedback on the draft.

Most of your comments have been mentioned on the ML are being addressed in
the next draft update.

Responses in-line

Many Thanks!!

Gyan

> A few comments/observations on this draft:

1. The BCP categorization does not seem right for this document and perhaps
> informational is better. Is this really something that has already seen
> widespread deployment such that the IETF community can say that it is the
> best “current” practice?
>

   Gyan> This draft addresses a real issue that has been discussed at NANOG
and other operator groups around the world related to IXP major peering
points where 1000s have IPv4 & IPv6 dual stacked peering exist and IPv4
address depletion have been a major issue issue for many years now.

Operators around the world are clamoring for a solution that can help with
worldwide address IPv4 depletion issues at the IXP peering points.  With
this solution IXPs as well as all infrastructure Core, DC PE-CE public or
private can now utilize this solution and reap the benefits immediately on
address space saving.  This can be used for IPv4 core or IPv6 core and I
will clarify in the draft.  All infrastructure peering with this draft
along with RFC 5565 now becomes officially IPv6-Only.

With this draft as it stands today as a BCP, the POC QA testing from the 5
major vendors that make up almost 90%+ of the router and switch market
share Cisco, Juniper, Arista, Nokia, Huawei, the idea is that all other
vendors will follow suit and adopt this BCP and implement and support this
solution to help with IPv4 address depletion issues faced by their
customers.  We not trying to be not inclusive of all vendors, as it’s
impossible to test every vendor.  With this  draft being a BCP, as
strategy, we would now once this draft is published as a best practice be
able create an industry shift momentum that now all operators all around
the world including Verizon as well as other tier 1 carriers as well as
Tier 2 and 3 and all ISPs can use this solution immediately and start
deployment once this draft becomes an RFC.  This will also help with the
underlying goal of worldwide IPv6 proliferation.

> 2. do not think that the term “legacy” is appropriate for IPv4 and IPv4
> based services.
>
Gyan> Understood. I can remove the word legacy

3. RFC5565 specifies the dual-stack PEs and IPv6-only P routers for
> delivering IPv4-based BGP services between the PEs via various mechanisms.
> This proposal brings that notion to the PE-CE link. The CE is dual-stack
> and the PE is IPv6-only. However, it is not describing how the forwarding
> plane works between PE and CE – an explanation or reference is required and
> without that clarity I am unable to understand how to actually deploy this.
>
Gyan> The next update will have a section that talks about IPv4 forwarding
plane processing without an IPv4 address.  Both the PE and CE will not have
an IPv4 address, but will be able to process and forward IPv4 packets.  The
concept is very similar to the cisco “IPv6 enable” command where you don’t
need an IPv6 address configured on the interface for IPv6 processing and
forwarding.  Juniper and Nokia have tested and confirmed they have a CLI
command for IPv4 forwarding without an IPv6 address.  We are investigating
a similar IPv4 forwarding option with the other vendors including Cisco.
This is part of implementation space and each vendor will have their own
existing knob if one exist or create a new knob for IPv4 forwarding without
an IPv4 address.  The PE-CE IPv4 forwarding without an IPv4 address
configured with all the functionality and line rate processing capabilities
will all be major part of the QA interoperability POC and test results.

> 4. The document touches on IXP deployments, but again does not actually
> cover how the forwarding works nor provides references for how this
> proposal works for that deployment.
>
   Gyan> Answered above

> 5. Is section 4 really required? Wouldn’t a simple reference to RFC8950
> suffice? The BGP signalling part for IPv4 over a single IPv6 peering and
> over IPv6 NH is already specified and covered in various Standards Track
> document (esp RFC8950) – so using their references rather than repeating
> them would be better.
>
    Gyan> As the draft pertains to PE-CE edge IPv6 only peering the use
cases involved end to end forwarding over all permutations of DC or Core
scenarios including both IPv4-Only and IPv6-Only core so I will be adding a
section that talks specifically about the PE-CE IPv6 only peering in
relation to RFC 5565 v4 edge over a v6 core and v6 edge over a v4 core.  So
as the core peering is all in scope as part of the interoperability testing
we will keep the RFC 8950 section in the draft as it would be relevant in
the POC.  I will update that section as to how the RFC 8950 update to RFC
5549 is now relevant to the interoperability testing.

> 6. If/when this gets published as an RFC, is the goal of this document to
> describe interop test results between specific vendors, OR is it do
> document the design, its operational considerations, and how it can be
> realized? E.g. RFC7938 – does something of that sorts. I do not think that
> IETF RFCs are good for documenting interop and it is better done via other
> “live” documents since these aspects change over course of time. It might
> even give an exclusionary impression for vendors not included in this
> document or those who might add this capability down the line. I’ve
> generally seen implementation status sections being taken out of Standards
> Track documents before publishing as RFC.
>

    Gyan> Answered in #1.   This draft document the design solution to a
problem and as a BCP will allow operators to have the comfort level to
start deployments immediately once published.   The test results currently
in the Appendix will all be moved to Section 3.

> 7. I would request the authors to explicitly clarify the Objective/Purpose
> of this draft in more precise and crisp manner in a section of its own so
> the WG knows what it is taking up. It might also help repeating the same
> throughout the document.
>
Gyan> Understood. I will clarify in the next update.

8. Finally, there is some language as follows in Sec 3 which perhaps needs
> to be revisiting?

>  Gyan>  I will clean up the language.
>
> Would also request the WG and chairs to share their views on some of the
> above points – (1), (2), (6) and (7). Clarity on these points is, IMHO,
> important and necessary before the WG considers adoption of this document.
>
>  Gyan> I have complied all the feedback from the adoption call thus far
> including your comments, and will be submitting the updated draft this
> weekend.
>
> Thanks,
>
> Ketan
>
>
>
> *Sent:* 13 April 2021 15:07
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Sat, 17 Apr 2021 07:50:47 +0000

Hi Gyan,

Thanks for your quick and detailed response. Please check inline below.

From: Gyan Mishra <[email-masked]>
Sent: 17 April 2021 12:10
To: Ketan Talaulikar (ketant) <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hi Ketan

Most of your comments have been mentioned on the ML are being addressed in the next draft update.

Responses in-line

Many Thanks!!

Gyan

On Sat, Apr 17, 2021 at 12:21 AM Ketan Talaulikar (ketant) <ketant=[email-masked]<mailto:[email-masked]>> wrote:
Hello Authors,

   Gyan> This draft addresses a real issue that has been discussed at NANOG and other operator groups around the world related to IXP major peering points where 1000s have IPv4 & IPv6 dual stacked peering exist and IPv4 address depletion have been a major issue issue for many years now.

Operators around the world are clamoring for a solution that can help with worldwide address IPv4 depletion issues at the IXP peering points.  With this solution IXPs as well as all infrastructure Core, DC PE-CE public or private can now utilize this solution and reap the benefits immediately on address space saving.  This can be used for IPv4 core or IPv6 core and I will clarify in the draft.  All infrastructure peering with this draft along with RFC 5565 now becomes officially IPv6-Only.
[KT] I am not questioning the need for a design to address this problem space. It is real and relevant – something that the WG should take up. So thanks to the authors for bringing this up. Just emphasising it, in case anyone got a different impression from my initial response.

With this draft as it stands today as a BCP, the POC QA testing from the 5 major vendors that make up almost 90%+ of the router and switch market share Cisco, Juniper, Arista, Nokia, Huawei, the idea is that all other vendors will follow suit and adopt this BCP and implement and support this solution to help with IPv4 address depletion issues faced by their customers.  We not trying to be not inclusive of all vendors, as it’s impossible to test every vendor.  With this  draft being a BCP, as strategy, we would now once this draft is published as a best practice be able create an industry shift momentum that now all operators all around the world including Verizon as well as other tier 1 carriers as well as Tier 2 and 3 and all ISPs can use this solution immediately and start deployment once this draft becomes an RFC.  This will also help with the underlying goal of worldwide IPv6 proliferation.
[KT] This is my concern exactly and I think we perhaps differ on the definition of BCP. As also, differ on the use of IETF stream RFC as the means for publication of interop test results. I will suggest to the authors as well as the WG to consider using such a document for capturing the design as informational. More specifically, I will recommend somewhat on similar lines as RFC7938 or even draft-ietf-mpls-seamless-mpls (even though the later didn’t get to RFC). That, IMHO, would be valuable for everyone in the community (including vendors and operators).
2. do not think that the term “legacy” is appropriate for IPv4 and IPv4 based services.
Gyan> Understood. I can remove the word legacy

3. RFC5565 specifies the dual-stack PEs and IPv6-only P routers for delivering IPv4-based BGP services between the PEs via various mechanisms. This proposal brings that notion to the PE-CE link. The CE is dual-stack and the PE is IPv6-only. However, it is not describing how the forwarding plane works between PE and CE – an explanation or reference is required and without that clarity I am unable to understand how to actually deploy this.
Gyan> The next update will have a section that talks about IPv4 forwarding plane processing without an IPv4 address.  Both the PE and CE will not have an IPv4 address, but will be able to process and forward IPv4 packets.  The concept is very similar to the cisco “IPv6 enable” command where you don’t need an IPv6 address configured on the interface for IPv6 processing and forwarding.  Juniper and Nokia have tested and confirmed they have a CLI command for IPv4 forwarding without an IPv6 address.  We are investigating a similar IPv4 forwarding option with the other vendors including Cisco.  This is part of implementation space and each vendor will have their own existing knob if one exist or create a new knob for IPv4 forwarding without an IPv4 address.  The PE-CE IPv4 forwarding without an IPv4 address configured with all the functionality and line rate processing capabilities will all be major part of the QA interoperability POC and test results.
[KT] This is the heart of the matter and the most critical part for the design that we are talking about here. I am afraid some of these mechanisms are not standardized. Even on this adoption call, I thought I saw some assumptions (maybe I read that wrong?) being made about the use of MPLS as the data-plane. The draft in the current state is missing this most important part.
4. The document touches on IXP deployments, but again does not actually cover how the forwarding works nor provides references for how this proposal works for that deployment.
   Gyan> Answered above
5. Is section 4 really required? Wouldn’t a simple reference to RFC8950 suffice? The BGP signalling part for IPv4 over a single IPv6 peering and over IPv6 NH is already specified and covered in various Standards Track document (esp RFC8950) – so using their references rather than repeating them would be better.
    Gyan> As the draft pertains to PE-CE edge IPv6 only peering the use cases involved end to end forwarding over all permutations of DC or Core scenarios including both IPv4-Only and IPv6-Only core so I will be adding a section that talks specifically about the PE-CE IPv6 only peering in relation to RFC 5565 v4 edge over a v6 core and v6 edge over a v4 core.  So as the core peering is all in scope as part of the interoperability testing we will keep the RFC 8950 section in the draft as it would be relevant in the POC.  I will update that section as to how the RFC 8950 update to RFC 5549 is now relevant to the interoperability testing.
[KT] That was really an editorial comment. Will look forward to those details that you mention for both PE-CE and IXP designs.
6. If/when this gets published as an RFC, is the goal of this document to describe interop test results between specific vendors, OR is it do document the design, its operational considerations, and how it can be realized? E.g. RFC7938 – does something of that sorts. I do not think that IETF RFCs are good for documenting interop and it is better done via other “live” documents since these aspects change over course of time. It might even give an exclusionary impression for vendors not included in this document or those who might add this capability down the line. I’ve generally seen implementation status sections being taken out of Standards Track documents before publishing as RFC.

    Gyan> Answered in #1.   This draft document the design solution to a problem and as a BCP will allow operators to have the comfort level to start deployments immediately once published.   The test results currently in the Appendix will all be moved to Section 3.
[KT] So you are proposing to publish interop testing reports in an RFC that is going to be a BCP? Again, I don’t believe this is the right approach and will let the chairs and others in the WG advise.

   The test results published from this document provide concrete
   evidence that this is now the Best Practice for Edge peering.  The
   document will be the de-facto standard for operators to now use a
   single PE-CE Edge IPv6 peer to carry both IPv4 and IPv6 NLRI.
 Gyan>  I will clean up the language.
Would also request the WG and chairs to share their views on some of the above points – (1), (2), (6) and (7). Clarity on these points is, IMHO, important and necessary before the WG considers adoption of this document.
 Gyan> I have complied all the feedback from the adoption call thus far including your comments, and will be submitting the updated draft this weekend.
[KT] Will look forward to that update since I am hoping that it will clarify the goal/purpose of the document better (at least for me). We agree on the need to address the problem statement – my concerns are on how to go about it and if this document (in the current/updated form) provides the right platform for it.
Thanks
Ketan
Thanks,
Ketan

From: BESS <[email-masked]<mailto:[email-masked]>> On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: 13 April 2021 15:07
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,
Matthew and Stephane

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<http://www.verizon.com/>

Gyan Mishra

M 301 502-1347

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 19 Apr 2021 23:57:52 +0000

I also believe that a table of conforming implementations is not
appropriate in an RFC, as it is forever changing as software is upgraded.
What is however appropriate is a list of test cases that must be passed
in order to claim interoperability. Claiming that a session comes up is not good enough.
An example of what I mean is at
https://standards.iso.org/ittf/PubliclyAvailableStandards/c030932_ISO_IEC_10589_2002(E).zip
Annex A, A.5 to A.7

Regards,
Jakob.

From: BESS <[email-masked]> On Behalf Of Ketan Talaulikar (ketant)
Sent: Saturday, April 17, 2021 12:51 AM
To: Gyan Mishra <[email-masked]>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hi Gyan,

From: Gyan Mishra <[email-masked]<mailto:[email-masked]>>
Sent: 17 April 2021 12:10
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>
Cc: Bocci, Matthew (Nokia - GB) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hi Ketan

Responses in-line

Many Thanks!!

Gyan

Hello,

Regards,
Matthew and Stephane

Gyan Mishra

M 301 502-1347

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 20 Apr 2021 05:46:19 -0400

Hi Jakob

Thank you for reviewing the draft.

We will have included in detail the list of test cases in the
interoperability testing that must be passed.

Thanks

Gyan
On Mon, Apr 19, 2021 at 7:57 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* BESS <[email-masked]> *On Behalf Of * Ketan Talaulikar
> (ketant)
> *Sent:* Saturday, April 17, 2021 12:51 AM
> *To:* Gyan Mishra <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>;
> [email-masked]; [email-masked]
> *Sent:* 17 April 2021 12:10
> *To:* Ketan Talaulikar (ketant) <[email-masked]>
> *Cc:* Bocci, Matthew (Nokia - GB) <[email-masked]>; [email-masked];
> [email-masked]
> 1. The BCP categorization does not seem right for this document and
> perhaps informational is better. Is this really something that has already
> seen widespread deployment such that the IETF community can say that it is
> the best “current” practice?
>
>
>
>    Gyan> This draft addresses a real issue that has been discussed at
> NANOG and other operator groups around the world related to IXP major
> peering points where 1000s have IPv4 & IPv6 dual stacked peering exist and
> IPv4 address depletion have been a major issue issue for many years now.
>
>
>
> *[KT] I am not questioning the need for a design to address this problem
> space. It is real and relevant – something that the WG should take up. So
> thanks to the authors for bringing this up. Just emphasising it, in case
> anyone got a different impression from my initial response. *
>
>
>
> *[KT] This is my concern exactly and I think we perhaps differ on the
> definition of BCP. As also, differ on the use of IETF stream RFC as the
> means for publication of interop test results. I will suggest to the
> authors as well as the WG to consider using such a document for capturing
> the design as informational. More specifically, I will recommend somewhat
> on similar lines as RFC7938 or even draft-ietf-mpls-seamless-mpls (even
> though the later didn’t get to RFC). That, IMHO, would be valuable for
> everyone in the community (including vendors and operators).*
>
> *[KT] This is the heart of the matter and the most critical part for the
> design that we are talking about here. I am afraid some of these mechanisms
> are not standardized. Even on this adoption call, I thought I saw some
> assumptions (maybe I read that wrong?) being made about the use of MPLS as
> the data-plane. The draft in the current state is missing this most
> important part.*
>
> *[KT] That was really an editorial comment. Will look forward to those
> details that you mention for both PE-CE and IXP designs.*
>
> *[KT] So you are proposing to publish interop testing reports in an RFC
> that is going to be a BCP? Again, I don’t believe this is the right
> approach and will let the chairs and others in the WG advise.*
>
>
>
> *[KT] Will look forward to that update since I am hoping that it will
> clarify the goal/purpose of the document better (at least for me). We agree
> on the need to address the problem statement – my concerns are on how to go
> about it and if this document (in the current/updated form) provides the
> right platform for it.*
>
> *Thanks*
>
> *Ketan *
>
> Thanks,
>
> Ketan
>
>
>
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 21 Apr 2021 02:57:22 +0000

Hi,

I support the adoption of this document, it provides useful information which can help the transition towards IPv6.

Best regards,
Jie

Hello,

Regards,
Matthew and Stephane

---

From: Qing Yang <[email-masked]>
Date: Tue, 27 Apr 2021 09:11:49 -0700

I support the adoption of this document, and I am not aware of any IPR related
to this draft.

On Tue, Apr 20, 2021 at 7:57 PM Dongjie (Jimmy) <[email-masked]> wrote:

> Hi,
>
>
>
> I support the adoption of this document, it provides useful information
> which can help the transition towards IPv6.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* BESS [mailto:[email-masked]] *On Behalf Of *Bocci, Matthew
> (Nokia - GB)

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 27 Apr 2021 13:02:37 -0400

Hi Matthew

All authors have now replied to IPR poll.

Thank you

Gyan

On Tue, Apr 27, 2021 at 12:12 PM Qing Yang <qyang=
[email-masked]> wrote:

>> *From:* BESS [mailto:[email-masked]] *On Behalf Of *Bocci,
>> Matthew (Nokia - GB)
-- 

*Gyan Mishra*

*M 301 502-1347*

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 27 Apr 2021 17:01:07 -0700

Hi,

As co-author - I support the adoption of this document, and not aware of any IPR related to this draft.

Cheers,
Jeff

---

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wed, 28 Apr 2021 09:45:27 +0000

This poll for adoption is now concluded and there is clear consensus to adopt this draft as a BESS working group document.

Please upload the next version of the draft as draft-ietf-bess-deployment-guide-ipv4nlri-ipv6nh-00.

Regards

Matthew

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Tuesday, 13 April 2021 at 10:36
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: WG Adoption and IPR Poll for draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03

Hello,

Regards,
Matthew and Stephane

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 28 Apr 2021 11:36:58 -0400

Thank you Matthew.

I will upload.

Kind Regards

Gyan

On Wed, Apr 28, 2021 at 5:45 AM Bocci, Matthew (Nokia - GB) <
[email-masked]> wrote:

> This poll for adoption is now concluded and there is clear consensus to
> adopt this draft as a BESS working group document.
>
>
>
> Please upload the next version of the draft as
> draft-ietf-bess-deployment-guide-ipv4nlri-ipv6nh-00.
>
>
>
> Regards
>
>
>
> Matthew
>
>
>
>
>
> *From: *"Bocci, Matthew (Nokia - GB)" <[email-masked]>
> *Date: *Tuesday, 13 April 2021 at 10:36
> *To: *"[email-masked]" <
> [email-masked]>, "
> [email-masked]" <[email-masked]>
> *Subject: *WG Adoption and IPR Poll for
-- 

*Gyan Mishra*

*M 301 502-1347*