Re: [spring] [bess] FW: New Version Notification for draft-litkowski-bess-rfc5549revision-00.txt

Hi Stephanie 

+ 6MAN & Spring 

I was thinking about the BGP capability exchange between address families concept from a 6MAN and operations perspective treating the next hop as a pure ubiquitous transport carrying v4 and v6 NLRI and the significance and advantages from a deployment perspective.

So RFC 5549 has been around now for 10 years but from an operations perspective it has not gotten as much adoption industry wide to take advantage of this major benefit.

I think what would help in the update of this draft is defining use cases for operators along with the technical specifications related to carrying IPv4 NLRI in IPv6 next hop.  I think also should mention carrying IPv6 NLRI in IPv4 next hop.  

From a use case perspective I think this would provide a significant advantage towards moving to an IPv6 core.  So that could be an underlay of  MPLS LDPv6, SR-MPLS, SRv6.  The result of keeping the next hop peering as a pure transport and leveraging carrying IPv4 NLRI with IPv6 next hop would be the elimination of IPV4 peers at the edge as well as now within the core being IPv6 only.  This from an operations perspective would be an initial learning curve with the FFFF:loopback IPv4 derived IPv6 next hop but from a support perspective all IPv4 peers and VPNV4 peers could be eliminated for both enterprise and service provider deployments.

I had not thought about MVPN and EVPN but I guess this same concept could apply treating the next hop IPv6 peering as pure transport and carrying V4 NLRI route types.

Thoughts?

Gyan

Sent from my iPhone

> On Nov 20, 2019, at 12:43 AM, Stephane Litkowski (slitkows) <slitkows@cisco.com> wrote:
> 
> Hi,
> 
> Following our fruitful discussion during BESS meeting yesterday, I have published a draft to revise RFC5549.
> 
> Brgds,
> 
> Stephane
> 
> 
> -----Original Message-----
> From: internet-drafts@ietf.org <internet-drafts@ietf.org> 
> Sent: mercredi 20 novembre 2019 13:39
> To: Swadesh Agrawal <swaagrawa@cisco.com>; Stephane Litkowski (slitkows) <slitkows@cisco.com>; Krishna Muddenahally Ananthamurthy (kriswamy) <kriswamy@cisco.com>; Krishna Muddenahally Ananthamurthy (kriswamy) <kriswamy@cisco.com>; Keyur Patel <keyur@arrcus.com>
> Subject: New Version Notification for draft-litkowski-bess-rfc5549revision-00.txt
> 
> 
> A new version of I-D, draft-litkowski-bess-rfc5549revision-00.txt
> has been successfully submitted by Stephane Litkowski and posted to the IETF repository.
> 
> Name:        draft-litkowski-bess-rfc5549revision
> Revision:    00
> Title:        Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop
> Document date:    2019-11-19
> Group:        Individual Submission
> Pages:        13
> URL:            https://www.ietf.org/internet-drafts/draft-litkowski-bess-rfc5549revision-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-litkowski-bess-rfc5549revision/
> Htmlized:       https://tools.ietf.org/html/draft-litkowski-bess-rfc5549revision-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-litkowski-bess-rfc5549revision
> 
> 
> Abstract:
>   Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of
>   network-layer protocols to which the address carried in the Next Hop
>   field may belong is determined by the Address Family Identifier (AFI)
>   and the Subsequent Address Family Identifier (SAFI).  The current
>   AFI/SAFI definitions for the IPv4 address family only have provisions
>   for advertising a Next Hop address that belongs to the IPv4 protocol
>   when advertising IPv4 Network Layer Reachability Information (NLRI)
>   or VPN-IPv4 NLRI.  This document specifies the extensions necessary
>   to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop
>   address that belongs to the IPv6 protocol.  This comprises an
>   extension of the AFI/SAFI definitions to allow the address of the
>   Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong to the IPv6
>   protocol, the encoding of the Next Hop in order to determine which of
>   the protocols the address actually belongs to, and a new BGP
>   Capability allowing MP-BGP Peers to dynamically discover whether they
>   can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess