[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: [bess] FW: New Version Notification for draft-litkowski-bess-rfc5549revision-00.txt
From:       Gyan Mishra <hayabusagsm () gmail ! com>
Date:       2019-11-23 15:52:40
Message-ID: 7BB2C539-9234-41D9-A085-825EF08EB15C () gmail ! com
[Download RAW message or body]

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------


[prev in list] [next in list] [prev in thread] [next in thread]