Re: [bess] BESS - IETF 115 update 4 drafts IPv4-Only PE Design / ALL SAFI , IPv6-Only PE design / ALL SAFI

[Gyan Mishra <[e-mail]>]

All,

Sorry I was not able to complete the presentation due to audio issues in
the room as well attendees in the queue were not able to ask questions so
taking questions  here to the ML.  Thank you for your feedback!!

*Recap from today's presentation below:*

These (4) drafts provide an ultra optimized alternative paradigm shift to
traditional "Dual Stacking" carrying both IPv4 & IPv6 NLRI over an single
IPv4 peer or single IPv6 peer while maintaining the data plane IPv4 & IPv6
forwarding  same identical functionality of Dual stacking with the IPv4
addressing savings & IPv4 peering savings for IPv6-Only PE design / ALL
SAFI and IPv6 addressing & IPv6 peering savings for IPv4-Only PE design /
ALL SAFI.

Both IPv4-Only PE design & IPv6-Only PE design use a vendor specific knob
so that  both IPv4 & IPv6 forwarding can occur w/o the dual stacked IPv4 or
IPv6 address on the interface thus yielding OPEX savings and eliminating
IPv4 address depletion issues for IPv6-Only PE design & IPv6 addressing
procurement savings for IPv4-Only PE Design.

IETF 114 - There was mention of certain SAFI that is not IPv4 or IPv6 AFI
and so those have been removed as being supported by the ALL SAFI drafts

*BESS WG Drafts:*

IPv6-Only PE Design:

draft-ietf-bess-ipv6-only-pe-design-02 (BCP) Vendor POC testing

draft-ietf-bess-ipv6-only-pe-design-all-safi-01 Design Draft (Standards
Track)


IPv4-Only PE Design:(Similar concept as IPv6-Only PE but now IPv4-Only peer
carrying IPv6 NLRI / SAFI)

draft-mishra-bess-ipv4-only-pe-design-02 Vendor POC testing & standard for
NH encoding(Standards track)

draft-mishra-bess-ipv4-only-pe-design-all-safi-01 Design Draft (Standards
Track)

>From IETF 114 I have combined the following 2 drafts


https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design/
(Standards Track) - POC Testing draft for SAF 1, 128, 1289

https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/
(Standards Track) - Extensibility to all supportable SAFI


into


https://datatracker.ietf.org/doc/draft-mishra-bess-ipv4-only-pe-design-all-safi/
(Standards
Track) - Extensibility to all supportable SAFI--> Queuing for WG adoption


>From IETF 114  - I had received feedback to combine both of these drafts
however since the 2nd ALL SAFI draft provides extensibility to the 1st
draft I did not think

it would be possible --> so I am planning to proceed with the 2nd draft
below to progress separately


https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/
<https://datatracker.ietf.org/doc/draft-ietf-bess-ipv6-only-pe-design/>-
Adopted April 2021 as BCP


https://datatracker.ietf.org/doc/draft-mishra-bess-ipv6-only-pe-design-all-safi/
(Standards Track)--> Queuing for WG adoption


*POC testing & timelines slide 5:*

We are planning to complete all the IPv6-Only PE design testing - Cisco,
Juniper, Nokia by End of Year so the draft can be progressed to WGLC


We will start the POC testing of IPv4-Only PE design ALL SAFI (Standards
Track) once it has been adopted - queuing for adoption


We will only be testing SAFI 1, 128, 129 as part of the BCP testing for
both the IPv4-Only PE design & IPv6-Only PE design


The idea is that with that basis of the 3 SAFI POC tested we are providing
the extensibility of the design to all other supportable SAFI which will be
deferred to each vendors development teams to support based on their own
roadmaps & timelines after the draft is published.


IPv4-Only PE Design standardizes a new next hop encoding --> I would like
to get feedback from the WG on this as I think a very good to be
standardized per below - excerpt from slide 8 below:


We will plan to test using the currently implemented IPv4 next hop encoding
and once the new IANA codepoint is allocated and the development of the new
next hop encoding is completed we would POC test the new next hop encoding
standard.

for SAFI 1, 128, 129.



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

•I would like to add information to IDR Wiki on which vendors support the
IPv4 mapped IPv6 address and which support the RFC 5549/RFC 8950 style
encoding.  As well if the vendor does not support the new next hop
encoding, it would continue to use the IPv4 mapped IPv6 address format
until the P2P peering both neighbors MP-BGP MP_REACH BGP capability
exchange is for the new IPv4 Next hop encoding codepoint. ---------->
Thoughts on this idea  ??



Attached is the slide deck I had shared today.



Many Thanks!!



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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*