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

["Gunter van de Velde (Nokia)" <[e-mail]>]

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

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

(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.

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.


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

  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]<mailto:[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]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>


--

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

Gyan Mishra

Network Solutions Architect

Email [e-mail]<mailto:[e-mail]>

M 301 502-1347