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

[Gyan Mishra <[e-mail]>]

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

On Sat, Apr 17, 2021 at 12:21 AM Ketan Talaulikar (ketant) <ketant=
[e-mail]> wrote:

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

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

>
>    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.
>
> Thanks,
>
> Ketan
>
>
>
> *From:* BESS <[e-mail]> *On Behalf Of *Bocci, Matthew (Nokia
> - GB)
> *Sent:* 13 April 2021 15:07
> *To:* [e-mail];
> [e-mail]
> *Subject:* [bess] WG Adoption and IPR Poll for
> draft-mishra-bess-deployment-guide-ipv4nlri-ipv6nh-03
>
>
>
> 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/
>
>
>
>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*