[bess] Re: Fwd: I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt

[Gyan Mishra <[e-mail]>]

Hi Gunter

Many Thanks for your feedback on the draft.

Responses in-line

On Fri, Aug 2, 2024 at 5:30 AM Gunter van de Velde (Nokia) <
[e-mail]> wrote:

> [speaking as individual contributor]
>
>
>
> Hi Gyan,
>
>
>
> Thanks for the update. I wasn’t paying attention to this draft until
> IETF120. Now that i realize this document exists i do have some comments.
>
>
>
> When glancing through the document, i am slightly lost what is the
> objective of the document and how it aligns with the BESS charter.
>
> Understanding this is important for any WGLC to succeed.
>
> Gyan> Understood.  I will make more clear in the next revision.
>
> This draft seems to contain two big chunks of information:
>
>
>
> (1) define a new IPv4 BGP next hop encoding standard that uses an IPv4
> address as the next hop and not an IPv4 mapped IPv6 address
>
    Gyan> Correct

This document provides test results of eBGP use cases for RFC 8950 IPv4
NLRI over IPv6 NH (IPv6 Only PE Design) and IPV6 NLRI over IPv4 next hop
(IPv4 Only PE Design) and new proposed for IPv4 next hop encoding being an
IPv4 address.

> This smells as something that impacts BGP in its romantic heart. Modifying
> the BGP Next Hop attribute involves a formal procedural change that
> significantly impacts BGP operations. The BGP Next Hop is a critical
> attribute, and any modifications to it must be meticulously evaluated to
> ensure they do not adversely affect BGP functionality.
>
    Gyan> Understood.  My thoughts on that is it would be very similar to
how RFC 5549/RFC 8950 IPv4 NLRI over IPv6 next hop was introduced.
Anything not supporting would utilize the IPv4 mapped IPv6 and anything
upgraded supporting the new next hop encoding.  As the MP Reach capability
code has to have send / receive state of the capability meaning both sides
of P2P peering have to support before it’s the new IP4 next hop is used.
That P2P capability negotiation will help with backwards compatibility.

> When considering a request for WGLC, it is imperative that this proposal
> be validated by IDR and explicitly approved. I think that WGLC should not
> be requested to BESS chairs until this approval is obtained, as otherwise
> WGLC progress would be blocked any way.
>
>  Gyan> Understood
>
> (2) Extensive Test Results
>
>
>
> The draft header indicates that it is a proposed standard; however, the
> document predominantly consists of informational test results and use-case
> descriptions where implementations function as expected. Additionally, I am
> not comfortable with calling out specific vendors in an IETF document. Test
> and implementation results represent only a static snapshot at a particular
> point in time, and vendor implementations may change over time. While
> referencing specific vendor implementations is permissible under certain
> conditions, it is generally discouraged to maintain neutrality and broad
> applicability.
>
>  Gyan> All of the testing done in the the draft is informational and if
> there is anything that makes it seem otherwise I will make sure is
> corrected.  The draft is standards track due to the IANA request for IPv4
> next hop encoding.  The tests here all serve as a baseline although static
> snapshot it is a crucial baseline proof of concept of the design and given
> this particular case would not change over time. So In this case as the
> testing done by the vendors is the crux of the document and proof that it
> the solution does work and would be static and not change, I would like to
> request that here in this case be permissible.  I understand the idea of
> maintaining neutrality and broader applicability and agree and would add
> that vendor list is a short list litmus test to show that the solution is
> possible and can be expanded to every vendor.  I have some mention of the
> goal of broader applicability to all vendors and not confined to just the
> vendors involved in the testing.
>
> Would it not be more appropriate to maintain a separate wiki for
> implementation and test reports? This approach would help maintain the
> neutrality and broad applicability of our IETF documents. In IDR we can
> find for example https://wiki.ietf.org/group/idr/implementations.
>
>  Gyan> I would like to discuss with the authors as well and seek feedback
> from the WG as well.  I agree the goal is broader applicability.  If that
> goal is diminished by mentioning the vendors in the draft I do agree with
> using the separate wiki approach to maintain neutrality is a great idea.
> As I mentioned above I think this could be an exception use case and we
> could place more detailed information about the test results on the wiki
> and abbreviated results summary in the draft given the reasons I stated
> above.  Also we can make crystal clear that the goal is broader
> applicability.
>

>
> Btw you may want to look at the references for this document. When running
> the idnits tool there are errors found:
>
>
> https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-bess-v4-v6-pe-all-safi-01.txt
>
>  Gyan>  I will fix in next revision
>
Many Thanks!

>   Checking references for intended status: Proposed Standard
>
>
> ----------------------------------------------------------------------------
>
>
>
>      (See RFCs 3967 and 4897 for information about using normative
> references
>
>      to lower-maturity documents in RFCs)
>
>
>
>   == Unused Reference: 'I-D.ietf-bess-bgp-multicast' is defined on line
> 1855,
>
>      but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-bess-ipv6-only-pe-design' is defined on
> line
>
>      1863, but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-bgp-car' is defined on line 1871, but
> no
>
>      explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-flowspec-nvo3' is defined on line
> 1878,
>
>      but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-rpd' is defined on line 1886, but no
>
>      explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-sdwan-edge-discovery' is defined on
> line
>
>      1894, but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-segment-routing-te-policy' is defined
> on
>
>      line 1902, but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-l3vpn-bgpvpn-auto' is defined on line
> 1910,
>
>      but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-lsvr-bgp-spf' is defined on line 1917, but
>
>      no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.mpmz-bess-mup-safi' is defined on line 1932,
> but
>
>      no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4291' is defined on line 1956, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4364' is defined on line 1960, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4761' is defined on line 1969, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC5492' is defined on line 1979, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC8277' is defined on line 2018, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC9015' is defined on line 2038, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'I-D.ietf-idr-dynamic-cap' is defined on line 2046,
>
>      but no explicit reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4659' is defined on line 2053, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4798' is defined on line 2065, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC4925' is defined on line 2071, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC5549' is defined on line 2076, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC5565' is defined on line 2081, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC6074' is defined on line 2085, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC6513' is defined on line 2091, but no explicit
>
>      reference was found in the text
>
>
>
>   == Unused Reference: 'RFC8126' is defined on line 2100, but no explicit
>
>      reference was found in the text
>
>
>
>   ** Downref: Normative reference to an Experimental draft:
>
>      draft-ietf-idr-bgp-car (ref. 'I-D.ietf-idr-bgp-car')
>
>
>
>   ** Downref: Normative reference to an Informational draft:
>
>      draft-ietf-l3vpn-bgpvpn-auto (ref. 'I-D.ietf-l3vpn-bgpvpn-auto')
>
>
>
>   -- Possible downref: Normative reference to a draft: ref.
>
>      'I-D.nalawade-kapoor-tunnel-safi'
>
>
>
>   ** Downref: Normative reference to an Experimental RFC: RFC 5747
>
>
>
>   ** Downref: Normative reference to an Historic RFC: RFC 6037
>
>
>
>   ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552)
>
>
>
>   -- Obsolete informational reference (is this intentional?): RFC 5549
>
>      (Obsoleted by RFC 8950)
>
>
>
>
>
>
>
> G/
>
>
>
>
>
>
>
> *From:* Gyan Mishra <[e-mail]>
> *Sent:* Monday, July 29, 2024 9:11 AM
> *To:* BESS <[e-mail]>; [e-mail]; Mankamana Mishra
> (mankamis) <[e-mail]>
> *Subject:* [bess] Fwd: I-D Action:
> draft-ietf-bess-v4-v6-pe-all-safi-01.txt
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Dear BESS WG & Chairs
>
>
>
> I have updated the draft and it is close to being ready for WGLC planning
> for the fall timeframe as discussed when I presented at IETF 120 last week.
>
> Also some cleanup in the draft to make it more readable in preparation for
> WGLC.
>
> Awaiting testing completion by Cisco & Huawei.
>
> Also SRv6 Compression CSID Next SID endpoint flavor applicability testing
> by all vendors.
>
>
>
> Updates:
>
> Removed RFC 8950 section-
>
>
>
> Added section for SRv6 Compression CSID Next SID flavor test cases-
>
>
>
> Updated Vendor list - removed Arista
>
>
>
> Testing update -
>
> Test 1-4 is now just Unicast SAFI 1 ,
>
> Test 5-128 IP VPN
>
>
>
> Juniper & Nokia 100% completed-
>
> Cisco & Huawei - plan to completed in Fall timeframe
>
>
>
> Added section for Typed NLRI that are N/A for the draft & updated AFI/SAFI
> table for Typed NLRI being N/A
>
> ·       MCAST-VPN [RFC6514 <https://datatracker.ietf.org/doc/html/rfc6514>]
>
> ·       MCAST-VPLS [RFC7117 <https://datatracker.ietf.org/doc/html/rfc7117>]
>
> ·       EVPN [RFC7432 <https://datatracker.ietf.org/doc/html/rfc7432>]
>
> ·       BGP-LS [RFC7752 <https://datatracker.ietf.org/doc/html/rfc7752>]
>
> ·       CAR [Color-aware routing draft <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-car-10>]
>
>
>
> *When this draft was created we combined 3 drafts since the work all pertained to the same concept of the following:*
>
> *3 design concepts:*
>
> 1-IPv4 Only PE design - Single IPv4 peer carrying both IPV4 & IPv6 NLRI w/ IPv4 only interface(Optimized dual stacking)
>
> 2-IPv6 Only PE design - Single IPv6 peer carrying both IPV4 & IPv6 NLRI w/ IPv6 only interface(Optimized dual stacking)
>
> 3-IPv4 Only PE design - IPv4 next hop encoding proposed to use instead of using mix of
>
> ipv4 mapped ipv6 address for next hop and a variety of other encodings to now standardize to use IPv4 address as the next hop
>
> identical parity with simplicity to RFC 8950 IP4v4 NLRI over IPv6 next hop.
>
>
>
> The eventual goal of this draft once it progresses to RFC is to make this design an industry wide paradigm shift to using this new alternative dual stacking methodology for the two commonly used SAFI "Unicast" and "IP VPN" tested in detail with the 12 test cases and as vendors get comfortable with the proliferation of the IPv4 Only PE design & IPv6 Only PE design which both are applicable for "IPv4 core" or "IPv6 core" which is the beauty behind it and the tremendous CAPEX and OPEX savings, is that operators can go down the list of SAFIs supported by this solution in the table at the end of the draft and work with their vendors on additional testing and proliferation of any of the other SAFIs that are supported in the future.
>
>
>
> My Future plans are to publish an operations draft in RTGWG, GROW and SRv6OPS for this solution and as well present this work at Operator Groups worldwide.
>
>
>
> Original
>
> adopted draft:
>
> draft-ietf-bess-ipv6-only-pe-design-04
>
>
>
> ! these 3 drafts were combined and all 3 are being replaced by
>
> 1. IPv6 ONLY PE design - single IPv6 peer to carry both IPv4 & IPv6 NLRI with IPv6 only interface
>
> draft-mishra-bess-ipv6-only-pe-design-all-safi-04-> IPR attached  (BCP)
>
>
>
> 2. IPv4 ONLY PE design - single IPv6 peer to carry both IPv4 & IPv6 NLRI
> with IPv6 only interface
>
> draft-mishra-bess-ipv4-only-pe-design-all-safi-05--> IPR attached
> (Standards Track)
>
> This draft also has IANA allocation for IPv4 next hop encoding proposal
> for IPv4 address next hop
>
>
>
> 3. Original adopted draft
>
> draft-ietf-bess-ipv6-only-pe-design-04 -->IP4 -> IPR attached (BCP)
>
>
>
> New draft (Standards Track)
>
> *draft-ietf-bess-v4-v6-**pe**-all-safi*
>
>
>
> *IPv4-Only PE Design Next Hop Encoding Standardization:*
>
> ·        RFC 4798 (6PE) section 2 defines how the next hop should be encoded for IPv6 NLRI over an IPv4 next hop using IPv4 mapped IPv6 address ::FFFF:192.168.1.1.  RFC 4659 BGP MPLS VPNs section 3.2.1.2 defines VPN SAFI next hop encoding of IPv4 mapped IPv6 address ::FFFF:192.168.1.1.
>
> ·        RFC 5549 and now updated by RFC 8950 defines the IPv6 next hop encoding to carry IPv4 NLRI over an IPv6 next hop.  The IPv6 next hop encoding defined is not an IPv6 mapped IPv4 address.  The IPv6 next hop encoding is 16/32 byte ( RFC 2545 – NH address  = IPv6 address  + Link Local address) for Unicast SAFI 1, Multicast SAFI 2 and BGP-LU SAFI 4, and 24/48 byte (RFC 2545 – NH address  / IPv6 address  + link local address) for VPN SAFI 128, MVPN SAFI 129.  The IANA BGP Capability codepoint defined with RFC 5549 is value 5 for Extended Next hop encoding.
>
> ·        The industry implementation uses a mix of IPv4 mapped IPv6 address for IPv6 NLRI carried over an IPv4 address next hop and uses 4 byte field for IPv4 next hop address for Unicast SAFI 1, Multicast SAFI2 and BGP-LU SAFI 4, and 12 byte next hop field, 4 byte IPv4 address plus 8 byte RD (Route Distinguisher) set to 0 for VPN SAFI 128, MVPN SAFI 129.
>
> ·        This draft standardizes the encoding to use an IPv4 address next hop and uses 4 byte field for IPv4 next hop address for Unicast SAFI 1, Multicast SAFI2 and BGP-LU SAFI 4, and 12 byte next hop field, 4 byte IPv4 address plus 8 byte RD (Route Distinguisher) set to 0 for VPN SAFI 128, MVPN SAFI 129.
>
> ·        This draft standardizes that encoding to ensure interoperability with IANA BGP Capability codepoint allocation thus providing parity between the RFC 5549/RFC 8950 IPv6 next hop encoding where the next hop address follows the underlay core which is an IPv6 core and how the next hop here being an IPv6 address and not following the NLRI with IPv6 mapped IPv4 address.  Now with this draft the next hop encoding follows the  underlay core which is an IPv4 core and so now the next hop being an IPv4 address and not following the NLRI with an IPv4 mapped IPv6 address.  So this parity between IPv4 next encoding and IPv6 next hop encoding savings in OPEX and operations troubleshooting as well as interoperability that all vendor implementations now use the same IPv4 next hop encoding is the reason the encoding must be standardized.
>
> ·        This IPv4 next hop encoding is applicable for IPv6 NLRI for both iBGP control plane (CP) peering as well as eBGP PE-CE, PE-PE in-line control / data plane (CP-DP) peering which is used for IPv4-Only PE design.
>
> ·        Completed research on vendors using IPv4 mapped IPv6 address versus IPv4 next hop and within the same vendor in many cases with the same SAFI I have even noticed a mix of both options in the RIB and FIB programming which this standardization to use IPv4 next hop will cleanup discrepancies even within the same vendor on the same platforms as well as all platforms across all vendors.
>
> ·
>
> ·        IANA BGP Capability - New codepoint for IPv4 Next hop encoding
>
> ·        https://www.iana.org/assignments/capability-codes/capability-codes.xhtml
>
> ·
>
> We will plan to have one of the 4 vendors add the IPv4 next hop encoding implemented prior to WGLC.
>
>
>
> Thank you
>
>
>
> Gyan
>
>
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Jul 29, 2024 at 2:11 AM
> Subject: [bess] I-D Action: draft-ietf-bess-v4-v6-pe-all-safi-01.txt
> To: <[e-mail]>
> Cc: <[e-mail]>
>
>
>
> Internet-Draft draft-ietf-bess-v4-v6-pe-all-safi-01.txt is now available.
> It
> is a work item of the BGP Enabled ServiceS (BESS) WG of the IETF.
>
>    Title:   IPv4-Only and IPv6-Only PE Design DESIGN ALL SAFI
>    Authors: Gyan Mishra
>             Sudha Madhavi
>             Adam Simpson
>             Mankamana Mishra
>             Jeff Tantsura
>             Shuanglong Chen
>    Name:    draft-ietf-bess-v4-v6-pe-all-safi-01.txt
>    Pages:   54
>    Dates:   2024-07-28
>
> Abstract:
>
>    As Enterprises and Service Providers upgrade their brown field or
>    green field MPLS/SR core to an IPv6 transport, Multiprotocol BGP (MP-
>    BGP)now plays an important role in the transition of their Provider
>    (P) core network as well as Provider Edge (PE) Inter-AS peering
>    network from IPv4 to IPv6.  Operators must have flexiblity to
>    continue to support IPv4 customers when both the Core and Edge
>    networks migrate to IPv6.  As well as must be able to support IPv6
>    networks in cases where operators decide to remain on an IPv4 network
>    or during transition.
>
>    This document details the External BGP (eBGP) PE-PE Inter-AS and PE-
>    CE Edge peering IPv4-Only PE design where both IPv4 and IPv6 all
>    supported SAFI NLRI can be advertised over a single IPv4 peer and
>    IPv6-Only PE Design where all supported SAFI NLRI can be advertised
>    over a single IPv6 peer.
>
>    This document also defines a new IPv4 BGP next hop encoding standard
>    that uses an IPv4 address as the next hop and not an IPv4 mapped IPv6
>    address.
>
>    This document also provides vendor specific test cases for the
>    IPv4-Only peering design and IPv6-Only PE design as well as test
>    results for the four major vendors stakeholders in the routing and
>    switching indusrty, Cisco, Juniper, Nokia and Huawei.  With the test
>    results provided for the IPv6-Only Edge peering design, the goal is
>    that all other vendors around the world that have not been tested
>    will begin to adopt and implement the design.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-v4-v6-pe-all-safi/
>
> There is also an HTMLized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-bess-v4-v6-pe-all-safi-01
>
> A diff from the previous version is available at:
>
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-v4-v6-pe-all-safi-01
>
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
>
>
> _______________________________________________
> BESS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>
>
> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions Architect *
>
> *Email [e-mail] <[e-mail]>*
>
> *M 301 502-1347*
>
>
>