Subject: Re: [Idr] Working Group Last Callfor draft-chen-bgp-ext-opt-param-02

From: Andy Davidson <[email-masked]>
Date: Sun, 14 Mar 2010 05:19:44 +0000

Hi,

On 12 Feb 2010, at 17:09, John Leslie wrote:

> I support that as a work item; and it implies that there must be a way to advertise capabilities while a session remains OPEN. 

[...]

On 24 Feb 2010, at 00:21, Enke Chen wrote:

> The behavior of each capability should be clear, and the dynamic revision of a capability should not change that.   Your example of "4byte AS" seems to be more about the "overhead", or implementation complexities, than about ambiguity in behavior.

'Overhead', and 'implementation complexities'... actually it sounds like a bug magnet and implementation nightmare. 

I really do not like the proposal of capabilities changing during a session.  

We do have a risk that we may have to negotiate more capabilities than there is room for in the OPEN.  I have not fully considered this yet, but I would prefer a 'Extended Capability Negotiation' process in between the open message and prefix-exchange process, so that capabilities were still negotiated at session establishment and remained constant during the bgp session.

Andy

---

From: Rob Shakir <[email-masked]>
Date: Mon, 15 Mar 2010 21:42:28 +0000

> We do have a risk that we may have to negotiate more capabilities than there is room for in the OPEN.  I have not fully considered this yet, but I would prefer a 'Extended Capability Negotiation' p…

Hi Andy/All,

I'm very interested in this comment, as this is something that we've also been discussing internally.

Typically, the only sessions in our network on which we have 'changing' capabilities are those that are (e)?iBGP. On these sessions, the reason to change capabilities is typically to add additional functionality (e.g. 6PE, VPNv6 etc). 

Our inter-AS sessions tend to be relatively static in terms of the capabilities that they support, typically only running a single address family, and then RR/GR/Multisession capabilities if these are advertised by the peer. In general, eBGP sessions never change capabilities, since the typical transport for a session is the address-family that we're exchanging. In my experience this is pretty typical of how inter-AS peering, and transit works (at least within my experience!).

Within our network, we'd expect that a BGP speaker has more than one device from which it is able to receive the prefixes that it requires to fulfil the functionality that it provides. We'd expect this to be either from some route reflector devices, or from intra-confederation sessions. The motivation for this is to ensure that if there is some event, or error condition that occurs, there is still some means to provide service to our customers, or the required intra-network routing.

With this in mind, and considering the requirement above that additional capabilities are added only on these internal sessions, is there a clear operational deployment case in which the potential risks of deploying dynamic capabilities are justified?

In my view, withdrawing prefixes and flapping the session is far less likely to trigger bugs, and can be done without an outage to any functionality that I expect of a BGP speaker. Hence there are few cases in which I see there being a need for dynamic-capabilities functionality.

I would be interested in opinions on the above. The argument clearly makes some assumptions around the way that people are using BGP, and is heavily biased towards an SP-type deployment. However, I'm not really in a position to comment on anything else!

Is there a feeling on the list that dynamic capabilities are something that is operationally a requirement for any live deployment?

I should add that I'm not necessarily decided on whether I think dynamic capabilities are a good or bad thing, I'd just like to hear other's thoughts on the above argument!

Many thanks,
Rob

-- 
Rob Shakir                      <[email-masked]>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http://www.vialtus.com/disclaimer.html

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 18 Mar 2010 20:15:39 -0400

Brent Smith has been having trouble sending to the list and asked me to forward this.  Reply-to set accordingly.

--John

From: "Smith, Brent" <IMCEAEX-_O=GLOBAL+20CROSSING_OU=NA_CN=RECIPIENTS_CN=[email-masked]>
Date: March 17, 2010 1:26:25 PM EDT
To: "[email-masked]" <[email-masked]>, 'Andy Davidson' <[email-masked]>, 'Rob Shakir' <[email-masked]>
Subject: RE: [Idr] Requirement for Dynamic Capabilities?

Comments inline from my experience here at Global Crossing.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Rob Shakir
> Sent: Monday, March 15, 2010 2:42 PM
> 
>> We do have a risk that we may have to negotiate more capabilities
> than there is room for in the OPEN.  I have not fully considered this
> yet, but I would prefer a 'Extended Capability Negotiation' process in
> between the open message and prefix-exchange process, so that
> capabilities were still negotiated at session establishment and
> remained constant during the bgp session.
> 
> Hi Andy/All,
> 
> Typically, the only sessions in our network on which we have 'changing'
> capabilities are those that are (e)?iBGP. On these sessions, the reason
> to change capabilities is typically to add additional functionality
> (e.g. 6PE, VPNv6 etc).
> 
> Our inter-AS sessions tend to be relatively static in terms of the
> capabilities that they support, typically only running a single address
> family, and then RR/GR/Multisession capabilities if these are
> advertised by the peer. In general, eBGP sessions never change
> capabilities, since the typical transport for a session is the address-
> family that we're exchanging. In my experience this is pretty typical
> of how inter-AS peering, and transit works (at least within my
> experience!).
[BS]Agreed. Our external sessions we do typically not change in capability. If there was a capability change needed, we would want to control it manually and would probably not be comfortable with dynamic changes. There could be some cases where it might be useful on an external session, but I cannot think of one.

> Within our network, we'd expect that a BGP speaker has more than one
> device from which it is able to receive the prefixes that it requires
> to fulfil the functionality that it provides. We'd expect this to be
> either from some route reflector devices, or from intra-confederation
> sessions. The motivation for this is to ensure that if there is some
> event, or error condition that occurs, there is still some means to
> provide service to our customers, or the required intra-network
> routing.
[BS]We have these redundant sessions for our reflectors/clients, but both of these sessions must be placed in the same configuration group to conserve memory utilization. This is the case with all of our vendor implementations. With both reflectors in the same configuration group, we cannot change one session without affecting the other simultaneously. With the choice between widescale hardware upgrades and an infrequent operational hit (see below), we choose the latter.

> With this in mind, and considering the requirement above that
> additional capabilities are added only on these internal sessions, is
> there a clear operational deployment case in which the potential risks
> of deploying dynamic capabilities are justified?
[BS] Yes. There are times that we need to add or remove an address family or labeled routes on our iBGP sessions. This is typically when we are adding a new capability (e.g. L2VPN) or changing an existing one (6PE to native IPv6). Today that means that each PE has to re-establish both its RR sessions, losing all iBGP routes. If these families could be dynamically enabled or disabled, that would save us an outage on every PE changed.

-Brent Smith

---

From: John Leslie <[email-masked]>
Date: Thu, 18 Mar 2010 21:28:46 -0400

John G. Scudder <[email-masked]> wrote:
>... 
> [BS] Yes. There are times that we need to add or remove an address
> family or labeled routes on our iBGP sessions. This is typically when
> we are adding a new capability (e.g. L2VPN) or changing an existing one
> (6PE to native IPv6). Today that means that each PE has to re-establish
> both its RR sessions, losing all iBGP routes. If these families could
> be dynamically enabled or disabled, that would save us an outage on
> every PE changed.

   I can see this as a reason to _add_ an address-family capability;
but I don't follow the need to _remove_ a capability. Can someone help
me?

--
John Leslie <[email-masked]>

---

From: Rob Shakir <[email-masked]>
Date: Fri, 19 Mar 2010 19:29:54 +0000

> [BS]We have these redundant sessions for our reflectors/clients, but both of these sessions must be placed in the same configuration group to conserve memory utilization. This is the case with all…

I hadn't thought of this actually, the question here is whether this is something that is an operational weakness of a certain routing platform, or something that would require protocol changes. I do not think we should introduce additional features to a protocol due to implementation details - it would appear relatively practical to decouple the configuration groups and negotiated capabilities, whilst maintaining update-groups as required. However, I am definitely not in an authoritative position to comment on implementations.

Kind regards,
Rob