Re: [v6ops] New version of Design Guidelines draft

[Philip Matthews <[e-mail]>]

Thanks for your comment.
I was not aware of the multi-session doc. I will look at it.
- Philip

On 2012-11-08, at 15:53 , Rob Shakir wrote:

> On Mon, Oct 22, 2012 at 02:28:49PM -0400, Philip Matthews wrote:
>> Folks:
>> 
>> I have just posted a new version (-01) of the Design Guidelines draft:
>>     https://datatracker.ietf.org/doc/draft-matthews-v6ops-design-guidelines/  OR
>>     http://tools.ietf.org/html/draft-matthews-v6ops-design-guidelines-01
> 
> Hi Philip,
> 
> Apologies, I did not notice this to comment at the mic in the meeting.
> 
> In the draft on the subject of eBGP sessions, you state:
> 
>   However, there are three main concerns with option (a).  First, on
>   most existing implementations, adding or removing an address family
>   to an established BGP session will cause the router to tear down and
>   re-establish the session.  Thus adding the IPv6 family to an existing
>   session carrying just IPv4 routes will disrupt the session, and the
>   eventual removal of IPv4 from the dual IPv4/IPv6 session will also
>   disrupt the session.  This disruption problem will persist until
>   something similar to [I-D.ietf-idr-dynamic-cap] is widely deployed.
> 
> One should note that dynamic-cap is not the only option for not disrupting a
> session between two devices by adding new capabilities to it. For
> IPv4/IPv6/VPNv4/VPNv6, running multi-session [0] will allow separate sessions to
> be utilised for each <AFI,SAFI>. In this case, the transport is still over the
> single underlying IP transport (whether it be IPv4, or IPv6).
> 
> This is notable because:
> A) It allows adding new AFIs to an adjacency in a non-disruptive way.
> B) It is already implemented in at least one major shipping implementation - where
>   dynamic-cap is not implemented in any that I know of.
> C) It provides some fault isolation between UPDATE and other BGP errors in
>   {IP,VPN}v4/{IP,VPN}v6 AFIs.  
> D) It retains the management simplicity of having a
>   single identifier for a remote peer, whilst having some of the advantages of
>   separate sessions.
> 
> Of course it does not address the other concerns around different transport
> planes that are contained in the same section, but it is perhaps worth nothing
> in your draft.
> 
> Thanks,
> r.
> 
> 
> [0]: http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-07
>