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

From: "Susan Hares" <[email-masked]>
Date: Thu, 11 Feb 2010 13:18:13 -0500

Folks:

We have received a request to adopt draft-chen-bgp-ext-opt-param as a IDR working group document.  Please send comments to the list. 
The deadline is February 25, 2010. 

The draft's full name is: Extended Optional Parameter Length for BGP OPEN Message.

(http://tools.ietf.org./html/draft-chen-bgp-ext-opt-param).

A presentation given at IETF-75 is at:

http://www.ietf.org/proceedings/75/slides/idr-2.pdf

Please comment early and often if you desire this draft.  

John gave a call for comments on 9/29/09, but it received insufficient response.  Afterward, people indicated they missed their opportunity to comment so we are again making the call.  

Sue Hares
Co-chair.

---

From: Keyur Patel <[email-masked]>
Date: Thu, 11 Feb 2010 11:35:22 -0800

Hi Sue:

I believe we should accept this doc as a WG doc.

-Keyur

Susan Hares wrote:
> Folks:
>  
> We have received a request to adopt draft-chen-bgp-ext-opt-param as a 
> IDR working group document.  Please send comments to the list.
> John gave a call for comments on 9/29/09, but it received insufficient 
> response.  Afterward, people indicated they missed their opportunity to 
> comment so we are again making the call. 
>  
> Sue Hares
> Co-chair.  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: "Pradosh Mohapatra (pmohapat)" <[email-masked]>
Date: Thu, 11 Feb 2010 13:45:52 -0800

I Support the adoption of this draft.

-          Pradosh

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Susan Hares
Sent: Thursday, February 11, 2010 10:18 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] Working Group Last Call for
draft-chen-bgp-ext-opt-param-02

Folks:

The draft's full name is: Extended Optional Parameter Length for BGP
OPEN Message.

Sue Hares

Co-chair.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 12 Feb 2010 11:38:59 +0200

Naturally, I support this :-).

Also naturally, my WG Chair hat is off and my individual contributor hat, on.

--John

---

From: John Leslie <[email-masked]>
Date: Fri, 12 Feb 2010 12:09:29 -0500

> (http://tools.ietf.org./html/draft-chen-bgp-ext-opt-param).

   I have a couple of problems with this:

- it's kludgy and messy;

- it's somewhat in conflict with a proposed-charter item.

   This ID proposes to change the interpretation of an OPEN message:
" 
" Accordingly, when the length of Optional Parameters in the BGP OPEN
" message is greater than 255, the OPEN message format is modified to
" be the following...

but, of course, this modification can only work if the other end of
the session supports it, which is by definition unknown if you are
the originator of the OPEN.

   (I'm not saying this can't be made to work: I'm just saying it's
kludgy and messy, and invites non-obvious coding error that will
surprise us later on.)

   And, it's a poor fit to the item in our proposed Revised Charter:
" 
" - Specify a means to non-disruptively introduce new BGP Capabilities
" to an existing BGP session.

   I support that as a work item; and it implies that there must be
a way to advertise capabilities while a session remains OPEN. Thus
(if the Revised Charter is adopted) we must define an (optional) new
message format to carry Capability Advertisements, removing any need
to crowd all capabilities into one OPEN message.

> http://www.ietf.org/proceedings/75/slides/idr-2.pdf

   Thanks for the pointer to this: it is worth reading.

   IMHO, we'd be better advised to pass on this proposal, and instead
start with a method to advertise capabilities in a BGP message other
than OPEN.

   (I suppose this means I volunteer to help write such a draft...)

--
John Leslie <[email-masked]>

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 12 Feb 2010 21:10:16 +0200

John,

(Of course, posting with chair hat off and individual contributor hat on.)

With regard to "kludgy and messy", chacun à son goût I suppose.  I would prefer to think of it as a hack rather than a kluge :-) and I'm more sanguine than you are regarding implementors' abilities to get it right.

Regarding whether it conflicts with the "non-disruptively introduce new BGP Capabilities" proposed charter item, I submit that it doesn't conflict.  At worst, it overlaps.  In fact, I agree that if we had dynamic capabilities ubiquitously implemented and deployed, we likely wouldn't need to extend the Capability space in the OPEN.  However, that isn't the situation we have.  Dynamic capabilities are a larger and trickier piece of work as compared to extending the OPEN Capability space -- the former is a fairly large feature, the latter, a bug fix.  If you're concerned about the relatively minor complexity of draft-chen-bgp-ext-opt-param-02, IMO you should consider the substantially greater complexity of draft-ietf-idr-dynamic-cap-10 before proposing it as the solution for this problem.  Anyway, I see no need to let the perfect be the enemy of the good in this case.  

Regards,

--John

---

From: Rob Shakir <[email-masked]>
Date: Sat, 13 Feb 2010 13:35:47 +0000

> to crowd all capabilities into one OPEN message.

I am not entirely sure that this is true. Are there situations in which one would want a session to be opened with a specific set of capabilities, and not even entertain the idea that there might be further capabilities added to these? (I'm not sure that this is actually a concern in any deployment that I am currently aware of, one would expect that if the capability is not supported at one end, a request to add it is not a disaster.)

The other point that I can think of is that there is some "duplicate" work being done by a BGP speaker if it is unable to send an OPEN with the full set of its capabilities, and instead needs to send an OPEN and then negotiate any capabilities.

I agree with John here, at worst this would appear to be an overlap - and there would appear to be no harm in progressing this proposal. The draft would mitigate the situation that there is some period in which we need >255 bytes in the Optional Parameters, and there no (stable ;-)) implemented dynamic capabilities support.

As such, I therefore would support adoption of this draft as a WG document.

Kind regards,
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: "Shyam Sethuram (shsethur)" <[email-masked]>
Date: Sat, 13 Feb 2010 10:22:37 -0800

I support adopting this as a WG doc.

thanks--shyam

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Susan Hares
> We have received a request to adopt 
> draft-chen-bgp-ext-opt-param as a IDR working group document. 
>  Please send comments to the list. 
> John gave a call for comments on 9/29/09, but it received 
> insufficient response.  Afterward, people indicated they 
> missed their opportunity to comment so we are again making the call.  
>  
> Sue Hares
> Co-chair.  
>

---

From: John Leslie <[email-masked]>
Date: Sat, 13 Feb 2010 16:53:06 -0500

Rob Shakir <[email-masked]> wrote:
> I am not entirely sure that this is true.

   "Any need" may seem to overstate the case: I was thinking that there
could be no need if your peer _supports_ dynamic capabilities.

   I agree there _could_ be a need to crowd capabilities into one OPEN
message when you know you're speaking to a peer with no support (at all)
of receiving Capability advertisements after the OPEN (which of course
you can't know if you're the first to send an OPEN).

   I am not aware of any cases which come anywhere close to the 704
byte "theoretical maximum" on John Scudder's slides; and I'm pretty
sure that dynamic capabilities would be a better solution than revising
the OPEN message. If I'm wrong on either of these, please say so.

> Are there situations in which one would want a session to be opened
> with a specific set of capabilities, and not even entertain the idea
> that there might be further capabilities added to these?

   This is possible, but seems less than reasonable if your BGP speaker
supports dynamic capabilities.

> (I'm not sure that this is actually a concern in any deployment that
> I am currently aware of, one would expect that if the capability is
> not supported at one end, a request to add it is not a disaster.)

   I agree: at worst, it would require a NAK; and in most cases it's
entirely safe to ignore a capability advertisement.

> The other point that I can think of is that there is some "duplicate
> work being done by a BGP speaker if it is unable to send an OPEN with
> the full set of its capabilities, and instead needs to send an OPEN
> and then negotiate any capabilities.

   Unfortunately there's "duplicate work" in any case...

   IMHO, the case you name is at least clean: you learn that your peer
won't listen to dynamic capabilities, so you close and open with the
capabilities you care most to advertise. (For that matter, if you know
that list ahead of time, you can include all of them in the first OPEN.)

   Under draft-chen-bgp-ext-opt-param, you must first send all the
capabilites you care about; then see whether your peer sends you a
NOTIFICATION saying in essence "I don't understand ext-opt-param;"
then send an OPEN scaled back to a set that fits in 256 bytes.

   This is messy: it's easy to imagine implementations that send
slightly different NOTIFICATIONS...

> I agree with John here, at worst this would appear to be an overlap
> - and there would appear to be no harm in progressing this proposal.

   "No" harm is overstating the case: publishing ext-opt-param as
an RFC takes significant effort; coding it in "all" implementations
takes significant time and effort; and the complexity it introduces
increases the chances of late bugs.

> The draft would mitigate the situation that there is some period
> in which we need >255 bytes in the Optional Parameters, and there [is]
> no (stable ;-)) implemented dynamic capabilities support.

   A situation I would be most happy to avoid!

   The sooner we finish off draft-ietf-idr-dynamic-cap, the less chance
such a period will occur. The simpler we make it, the less chance
stable implementation won't be available.

   I would suggest we strip draft-ietf-idr-dynamic-cap of anything which
really is a matter of "tuning", and clarify that a NAK is perfectly
acceptable to a request to withdraw an advertised capability. This would
enable partial implementations to ship and get field-testing.

   (Heck, NAK should be acceptable to _anything_ you don't want to
bother with: it's just that "ordinary" capabilities can safely be
completely ignored.)

   Limiting an implementation to the same functions now done during
processing of capability advertisements currently parsed during an OPEN
would greatly reduce the likelihood of non-stable implementations.

   We _really_should_ resist the temptation to crowd too much into any
particular BGP extension...

---

From: Enke Chen <[email-masked]>
Date: Sat, 13 Feb 2010 15:35:35 -0800

Hi, John:

The dynamic capability is a big hammer for this small nail :-)

While the dynamic capability is generic, I suspect that only a very 
small subset of capabilities (such as address families) will be 
implemented and made dynamic - due to complexities involved and the 
absence of the requirements for most of the capabilities.  Thus I 
believe that the solution offered in draft-checn-bgp-ext-opt-param-02 is 
necessary, and it is a better solution due to its simplicity (though 
"hacky" as pointed out).

Regards,   -- Enke

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 14 Feb 2010 00:51:43 +0100

Enke and all,

I support progressing the draft to the RFC.

I don't think that what is in fact proposed in the draft is that 
"hacky". Assigning a special meaning to a given value (here 255) is IMHO 
a natural way to extend the available space.

Of course there could be other ways to extend the capability space .. 
mark other value to mean OPEN2 msg will follow .. introduce hierarchy 
within each AF etc .. but those would be truly hacky or at least much 
more hacky :-).

Cheers,
R.

>>>> " " - Specify a means to non-disruptively introduce new BGP 
>>>> Capabilities

---

From: Rob Shakir <[email-masked]>
Date: Mon, 15 Feb 2010 21:31:00 +0000

Hi John,

> could be no need if your peer _supports_ dynamic capabilities.

So, picking up on this, should we cater for a scenario where there are enough capabilities that they do not fit into the existing OPEN yet the vendor has not implemented dynamic capabilities? In some ways, these drafts may not overlap, but could be seen to compliment each other. One could envisage a scenario where a peer is configured with enough capabilities that they do not fit into the existing OPEN - hence a NOTIFICATION is sent. Do we then need to define which capabilities are important enough that they should be included? (Of my existing set of configured capabilities, assuming that there is growth of other information signalled by BGP, I'm not sure I know which the most important are completely!)

> the OPEN message. If I'm wrong on either of these, please say so.

ACK on the 704 byte "theoretical maximum" - I have no specific case to state here. I'm sure that dynamic capabilities is _one_ solution to this problem, but does the scenario I describe above ever exist?

> slightly different NOTIFICATIONS...

This ties in to the first point I make in this mail I think - perhaps I should have addressed it here instead, since it seems more pertinent to this paragraph.

> increases the chances of late bugs.

So, the question here might come down to how one considers implementations. In terms of this draft, can I expect that less bugs are introduced since it suggests a comparatively simple fix to opening a session with many capabilities? Dynamic capabilities may result in a more complex implementation that introduces more bugs.

I appreciate this is not a pure protocol perspective. From this perspective, it seems very suboptimal to duplicate behaviour, however, from my (operator's) point of view, I think that if I can turn off a complex extension to a protocol (dynamic capabilities in this case), and introduce something somewhat more simple, then this lets me limit any implementation bug's impact. There is probably a case for balancing these two approaches to the same problem.

With respect to draft-ietf-idr-dynamic-cap - and your comments, I really need to review this draft thoroughly, and it's history before I would want to comment about specific inclusions.

Kind regards,
Rob

---

From: Ananth Suryanarayana <[email-masked]>
Date: Fri, 19 Feb 2010 10:55:31 -0800

Hi,

I support progressing this draft to RFC.

-- 
Regards,
Ananth

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Feb 2010 14:56:50 +0000

On Thu, Feb 11, 2010 at 01:18:13PM -0500, Susan Hares wrote:
> We have received a request to adopt draft-chen-bgp-ext-opt-param as a IDR
> working group document.  Please send comments to the list. 

I support adoption of this draft as a working group item.

Comment to the authors:
:   In the event that the length of Optional Parameters in the BGP OPEN
:   message does not exceed 255, the encodings of the base BGP
:   specification [RFC4271] MUST be used without alteration.
:
:   However, if the length of Optional Parameters is greater than 255,
:   four octets are used for the length field.  Each of the first two
:   octets is set to 255, and the remaining two octets carry the actual
:   length.  In addition, the "Parameter Length" field of each Optional
:   Parameter is enlarged to two octets.  Other than the larger sizes of
:   the given fields, there is no change to the BGP OPEN message defined
:   in [RFC4271].

You're not really using 4 octets for the length field.  You're signaling
that the Extended Optional Parameter format is used for the optional
parameters and that the length is 2 octets.  Perhaps something more like:

If the length of the Optional Parameters is greater than 255, the Extended
Optional Parameter format may be used.  Use of this format is signaled by
setting the Optional Parameter Length to 255 and the first Optional
Parameter Type to 255.  When the Extended Optional Paramter format has been
signaled, the OPEN message format is modified to be the following:

[packet diagrams elided]

:   In parsing an OPEN message, a BGP speaker MUST use the value of the
:   one-octet "Optional Parameters Length" field and the value of the
:   octet following it to determine the encoding of the Optional
:   Parameters length, as well as the size of the "Parameter Length"
:   field of the Optional Parameters.  If both values are 255, then the
:   four-octet encoding described above is used for the Optional
:   Parameters length.  Otherwise the encoding defined in [RFC4271] is
:   used.

This paragraph, even without some verbiage change above, is somewhat
redundant.

:   This encoding is chosen for backward compatibility reasons -- a BGP
:   speaker which has not been upgraded to support this specification may
:   legitimately send Optional Parameters whose length equals exactly
:   255, thus the Optional Parameters Length field alone is insufficient
:   as an indicator.  However, such a speaker would never legitimately
:   send an Optional Parameter whose type code is 255, since that value
:   has been reserved by this specification.

Pedantically, you should also note that the value of 255 must be excluded
from the list of optional parameter types in the extended format.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Feb 2010 15:03:23 +0000

> the OPEN message. If I'm wrong on either of these, please say so.

Dynamic capabilities, while sort of nifty, are problematic in the sense they
require the peering session to change some behaviors that might be best
dealt with only upon session initialization.  The dynamic capability
specification basically says that each extension that uses it should define
how it should behave when signaled dynamically.  IMO, that's always been a
bit messy.

(No offense to the dynamic caps spec.  In the absence of extended optional
parameters, it was the best hammer we had.)

IMO, we're really better off with multiple parallel peering sessions and
extended optional parameters as a paired set of features than having to
worry about dynamic capability behaviors for many BGP extensions.

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 23 Feb 2010 12:23:04 -0500

Jeff:

Can you provide a bit more detail on why Dynamic capabilities is "messy"?

> how it should behave when signaled dynamically.  IMO, that's always been a

Best wishes,

Sue Hares

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 23 Feb 2010 22:48:57 +0000

Sue,

> Can you provide a bit more detail on why Dynamic capabilities is "messy"?

Pretty much exactly what I said: It requires each feature that can be
dynamically updated via adding or removing its capability to define its
behaviors when being dynamically added or deleted.  While the mechanism for
altering the capabilities is clear in the specification, per-extension
behaviors are not.

To pick a random example, if we have or have not negotiated 4-byte AS
support, changing that behavior may impose such Update messaging overhead
that it is probably cleaner to just terminate the peering session.

Speaking in the "it'd be nice if this were the way thing were" sense, I
believe that Graceful Restart, multi-session BGP and the most recent
proposal to extend Optional Parameter length as a set is a cleaner mechanism
than dynamically altering capabilities:

 - The Optional Parameter specification allows us to have a much longer
   capability set, obviating the need for a smaller capability set that must
   be appended to using dynamic capabilities.
 - Multi-session BGP permits errors in semantically different reachability
   (AFI/SAFI, e.g.) to not impact other semantic information piggybacking on
   the same peering session.  This improves the resilience of the protocol,
   especially in the face of future extensions.
 - In the case where some changes must be negotiated, graceful restart could
   allow this to happen without impacting forwarding.  This allows peering
   sessions to have a "fresh start" without having to worry about potential
   stale state that must be adjusted on a per-capability basis.

But that's all "it'd be nice".  Dynamic capabilities have been around for a
while but only one of the above features has seen deployment.

-- Jeff

---

From: Enke Chen <[email-masked]>
Date: Tue, 23 Feb 2010 16:21:54 -0800

Hi, Jeff:

I am not sure what you meant by "per-extension behaviors are not".   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.

The dynamic capability was motivated by the config / de-config of 
address families over the same session.  IMO the motivation still stands 
- although the Graceful Restart can help alleviate the negative impact 
of a session reset.   Also my opinion is that the dynamic revision is 
only needed for a very small number of capabilities such as address 
families.  Thus the implementation complexities should be contained.

-- Enke

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Feb 2010 15:30:20 +0000

> about ambiguity in behavior.

I had not intended "messy" to specifically be constrained to protocol
behavior and I was indeed also talking about implementation complexity.
While our specifications are intended to define on-the-wire behaviors, they
also have impacts on implementation.  We should consider those consequences.

To give a different example, if I remote the AFI IPv6/unicast capability,
what should my on-the-wire behavior be?  Arguably, if I treat it as if that
capability wasn't negotiated, I should discard all IPv6/unicast reachability
I had received.  But if I wanted to be a polite BGP implementation, perhaps
I should also send withdrawals for all of that reachability first?

In the above situation, if there is a misordering of capability removal
acknowledgement and withdrawals then the peering session may be reset since
that AFI/SAFI is no longer negotiated.

Please note that I am *not* saying that we couldn't have clear behaviors for
how each capability add/delete could be handled.  I'm just saying that right
now there is room for unclear behavior resulting in poor or suboptimal
interoperability.

> Also my opinion is that the dynamic revision is  

The draft is not constrained to that small set.

-- Jeff

---

From: Enke Chen <[email-masked]>
Date: Wed, 24 Feb 2010 11:28:22 -0800

Hi, Jeff:

> I should also send withdrawals for all of that reachability first?

Sure, there are always tradeoffs to make in implementation.  In this 
example, though, the end result should be that neither speaker would 
have ipv4/unicast routes from each other.  It would be wasteful (and 
perhaps not so "polite") to send withdraws first by a "polite bgp 
implementation" :-)  Regardless the end result will still be the same.

> The draft is not constrained to that small set.

No doubt.  The spec is generic for all capabilities.

When the draft was revised several years ago, I actually went through 
the logic of revising the 4byte AS capability dynamically. Admittedly 
it's not something that needs the dynamic revision.  But it's a good 
example to verify the spec - as the capability changes the UPDATE 
message on the wire, thus we must know the demarcation of these message 
of different encoding. The implementation complexity seemed moderate.

-- Enke

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 24 Feb 2010 19:56:42 +0000

> implementation" :-)  Regardless the end result will still be the same.

And yet the point stands: If one side decides that ipv6 reachability is no
longer valid to receive and the other side sends the withdrawals, then a
notification would be sent.

A bit more specificity makes the corner case a non-problem.   Corner cases are
often what make our routers bounce their sessions in the wild.

-- Jeff