Re: [v6ops] New version of Design Guidelines draft

[Rob Shakir <[e-mail]>]

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