Subject: [Idr] unknown BGP capability

From: Joe Maimon <[email-masked]>
Date: Fri, 18 Aug 2006 08:45:34 -0400

Hello All,

I have been advised that this post

http://www.merit.edu/mail.archives/nanog/msg01754.html

would be on topic for this email list, and in accordance with that 
advice, I am hoping to query this list for an answer.

To recap:

Peer A went down after being up for a while. When it came back up and 
tried to peer with B, A received a capability 64 and then sent a 
NOTIFICATION to B of Unsupported Capability.

Is A's behavior proper/reasonable?

I have attempted to read this situation into rfc3392 but all I see there 
is a scenario where A peers with B and sends B a capability 64. If A 
does not receive capability 64 from B, A may decide to send a 
notification. If A sends the notification, neither A nor B should 
attempt to automaticaly retry the connection.

Thanks,

Joe

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Aug 2006 09:13:49 -0400

Joe,

> attempt to automaticaly retry the connection.

http://www.iana.org/assignments/capability-codes will show you that
64 is graceful restart.  Ironically, it's trying to be better
about how the session deals with resetting. :-)

Not re-establishing the connection automatically is the spec
compliant behavior.

In this case, call your provider and tell them to turn off GR
if you're unable to support it. :-)

-- Jeff

---

From: Joe Maimon <[email-masked]>
Date: Fri, 18 Aug 2006 09:20:06 -0400

> Not re-establishing the connection automatically is the spec

But is terminating the connection (our equipment) spec compliant 
behavior? Good idea? Bad idea?

> if you're unable to support it. :-)

They took it off long enough for us to come back up, but we will 
probably have some time convincing them to disable BGP SSO/NSF on their 
router which will affect all their other customers.

> -- Jeff

Thanks for your reply.

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Aug 2006 09:44:38 -0400

> Is A's behavior proper/reasonable?

   No. (Unless A is actually objecting to the _absence_ of some other
capability.)

   The original message is clearer than the recap...
] 
] If A tries to peer with B, and B sends a BGP capability 64 to A,
] if A does not support that capability what would proper and/or
] reasonable behavior for A be?

   Per rfc3392:
}
} A BGP speaker that supports a particular capability may use this
} capability with its peer after the speaker determines (as described
} above) that the peer supports this capability.

   Receiving a capability advertisement is permissive only: it creates
no obligation to use that capability.

] a) send
] 
] unsupported capability code 64 lengh 6

   No.

   This is a misreading of 3392 -- understandable because of the
unfortunate choice of name for the subcode. "Unsupported Capability",
as I understand it, is intended for cases where a BGP speaker cannot
carry on with a peer which does not support some capability _it_
advertised.

   (Whether this should happen at all is perhaps worthy of discussion;
but I'll merely say that such an action is unfriendly at best and
downright nasty in a case where peering has been routine for an
extended period.)

b) ignore it

   Yes.

> attempt to automaticaly retry the connection.

   (You shouldn't confuse the issue by who goes first. Otherwise,
your reading is quite correct.)

   Incidentally, I do not read into 3392 any requirement that A is
obligated to _ever_ send a capability advertisement if it receives
a capability advertisement which does not contain some capability
it insists upon. Thus, the actual content of the Notification only
means that administrators of both ends need to talk to each other
to find out what the incompatibility is.

--
John Leslie <[email-masked]>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Aug 2006 09:36:19 -0400

Joe,

> behavior? Good idea? Bad idea?

Well, I did mention it was spec compliant.  Here it is:

RFC 3392, Section 3:

   If a BGP speaker that supports a certain capability determines that
   its peer doesn't support this capability, the speaker MAY send a
   NOTIFICATION message to the peer, and terminate peering (see Section
   "Extensions to Error Handling" for more details).  The Error Subcode
   in the message is set to Unsupported Capability.  The message SHOULD
   contain the capability (capabilities) that causes the speaker to send
   the message.  The decision to send the message and terminate peering
   is local to the speaker.  If terminated, such peering SHOULD NOT be
   re-established automatically.

It is arguable that for certain capabilities it is possible to
"negotiate" a capability away, much like PPP will negotiate a
number of parameters.  For example, the fact your router said
"I don't understand this capability 64 thing" could be enough
for the remote router to attempt to re-establish the connection
without that capability.  The connection would come up and
you'd be happy.

Negotiation, however, is often a bad idea.  It means that regardless
of what each side configures, you may not end up with the expected
effective configuration.  For routers, this is usually a Bad Thing.
The trend has been "bring initial misconfigurations to the operator's
attention by not allowing the session to come up".

> router which will affect all their other customers.

I'd be shocked if this isn't a per-peer configuration item on their
box.  Just because they support NSF doesn't mean they have to
advertise it to you. :-)

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 18 Aug 2006 11:25:51 -0400

In short, I agree with John's analysis.  A's behavior as described 
isn't per spec.

A few more comments below:

>carry on with a peer which does not support some capability _it_

I apologize for the choice of nomenclature.  Unfortunately it would 
probably cause more confusion than it would benefit to rename 
"Unsupported Capability" to something else at this late date.

>downright nasty in a case where peering has been routine for an

"This" being "drop the session if a capability you require isn't 
supported by your peer"?  I agree it's a heavy hammer; however one 
can posit cases where it's necessary.  A reasonable implementation 
wouldn't do this unless, as you say, the lack of support by the peer 
makes the peering impossible (either by policy or for some 
fundamental technical reason).  In such a case (which I *believe* is 
purely hypothetical at present) I don't see a better option than to 
drop the session.

>it insists upon.

I don't understand this sentence.

>Thus, the actual content of the Notification only

That seems like a fair characterization.  (One could imagine 
automatically doing something on the basis of the notification, but 
such schemes are usually better left in the imagination.)

--John

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Aug 2006 17:07:03 -0400

> "Unsupported Capability" to something else at this late date.

   I quite agree.

> supported by your peer"?

   I was thinking more in terms of "this" meaning an implementation
requiring some extended capability to talk at all; regardless, I can
certainly imagine a legitimate need -- one example being a BGP speaker
assigned a 4-byte ASN.

> I agree it's a heavy hammer; however one can posit cases where it's
> necessary.

   Agreed. By "worthy of discussion" I meant only to suggest that
perhaps not all of us understand _why_ it might be necessary: perhaps
understanding the necessity would make the spec easier to understand.

> A reasonable implementation wouldn't do this unless, as you say,
> the lack of support by the peer makes the peering impossible
> (either by policy or for some fundamental technical reason). In
> such a case (which I *believe* is purely hypothetical at present)
> I don't see a better option than to drop the session.

   Nor do I.

> I don't understand this sentence.

   The issue at hand is whether a particular extended capability is
needed for BGP speaker A to peer with B. This in no way depends upon
whether B has seen A's advertisement of capabilities. Indeed, if A
receives an Open _without_ an advertisement of a capability it needs,
it "knows" immediately that the session B is requesting is doomed.

   I do not read 3392 as prohibiting A from sending the Notification
_before_ it sends an Open.

   (This distinction would be pointless, except that I meant to call
attention to the fact that A might be sending the Notification to B
not because it didn't support capability 64, but because it _required_
some capability not advertised by B. That, IMHO, would be in-spec,
albeit confusing.)

---

From: Erblichs <[email-masked]>
Date: Fri, 18 Aug 2006 15:24:03 -0700

Ok,

	Inquiring minds want to know..

	Is "Unsupported Capability":

	1) A capability not currently configured on this
           interface?

	2) A capability not currently configured on this
	   router?

	3) A capability that can't be configured?

	4) A capability that requires all peers to support,
	   thus because 1 peer doesn't support it, it isn't
	   supported?

	5) A resource specific capability that can be exausted?

	6) A non-negotiated capability?

	7) A 1-way or a 2-way capability? ie: 1-way: we can only
	   import or export that functionality.

	A combination of the above or none of the above?

	IMO, it is a very generic term that can mean 1 or more
	things and in the past could have had a better definition.

	Mitchell Erblich
	-----------------

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Aug 2006 19:54:25 -0400

> 3) A capability that can't be configured?

   "Unsupported Capability" is merely the title given to one error
subcode. It means that a capability "required" by the BGP speaker
sending the Notification is not supported by the prospective peer.

   (It may or may not have anything to do with configuration of any
interface; it certainly _is_ a capability not currently configured
on the BGP speaker _receiving_ the Notification.)

   Alas, the Notification includes no information on what particular
capability is "unsupported"...

>    thus because 1 peer doesn't support it, it isn't

   There are only two peers involved in the session in question.
Generally "Unsupported Capability" will result from a capability
supported on the router sending the Notification, but not
supported on the router receiving the Notification. However, this
is not _necessarily_ the case.

> 5) A resource specific capability that can be exausted?

   Unlikely. All "capabilities" are extension to the basic BGP-4.
They might deal with what to do when some resource is in danger
of being exhausted, but only in order to avoid having to abort the
session.

> 6) A non-negotiated capability?

   There is no meaningful "negotiation" here. The example I like
is that if you are assigned a 4-byte AS number, you can't peer
with anyone who doesn't support the 4-byte-ASN extension.

>    import or export that functionality.

   There is nothing which is necessarily 2-way here. It's perfectly
possible for one BGP speaker to send updates in accordance with
an extension, while not advertising that capability itself because
it can't handle all cases. (No, I'm not aware of any current
implementation which does this!)

> A combination of the above or none of the above?

   None of your descritions caught the essence of it.

> things and in the past could have had a better definition.

   I quite agree it could have had a better _name_. I also agree
with John Scudder that it's too late to change the name.

   I don't agree that its "definition" is deficient. Perhaps
I could write a better one; but I didn't volunteer at the time
RFC 3392 was written, so I won't criticize the definition in
RFC 3392.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 18 Aug 2006 18:54:23 -0400

Mitchell,

None of the above.  As John Leslie previously pointed out, and I agreed with,

     "Unsupported Capability" [...] is intended for cases where a
     BGP speaker cannot carry on with a peer which does not support
     some capability _it_ [the BGP speaker] advertised.

In the subsequent discussion, I said,

     A reasonable implementation wouldn't do this unless [...]
     the lack of support by the peer makes the peering impossible
     (either by policy or for some fundamental technical reason).

So, once again:  "Unsupported Capability X" means "I am complaining 
that you have not advertised capability X to me, and I require it."

As for why you might choose to terminate the session instead of 
carrying on as best you can in such a situation, as I said this is 
currently a hypothetical and I don't think it would be productive to 
get into enumerating all the situations in which it might come into 
play.

I'll give you one imaginary example, though, in hopes that it makes 
matters clearer.  Suppose someone decided to make a BGP 
implementation that supported only the multiprotocol BGP NLRI 
encoding and not the classic encoding.  If it didn't see capability 
code 1 from its peer, then it'd have no choice but to drop the 
session.

IMO RFC 3392 is unambiguous on this point, though I agree that the 
choice of name for "Unsupported Capability" was regrettable.

Hope this helps.

--John

---

From: Erblichs <[email-masked]>
Date: Fri, 18 Aug 2006 17:25:06 -0700

Heys guys,

	Yes, I know what you guys are saying, but the default
	expectation seems to be dependent on the implementation.

	Here is a re-statement of the first two items...

	1) Can two peers be requesting "X" at the same time on the
	   same interface and ONLY 1 gets an Unsupported Capability?
	
	2) Can two peers be requesting "X" at the same time on
	   different interfaces and BECAUSE they are on different
	   interfaces recieve different types of replies?

	These first two questions actually deal with configuring "Capabilities"
	on a per nbr, per intf, or per rtr.

	In my experience, I have seen implementations that differ
	on each of the items, because some implementations allow
	different scopes (nbr/peer, intf, and rtr).

	Thus, I feel that if a document is reviewing "Capabilities",
	that some type of "BEST PRACTICE/scope" document be specified to
	improve on the consistency.

	Mitchell Erblich
	-----------------------

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 18 Aug 2006 20:29:46 -0400

>capability is "unsupported"...

It ought to.  From 3392 section 5,

                                     The Data field in the NOTIFICATION
    message SHOULD list the set of capabilities that cause the speaker to
    send the message.  Each such capability is encoded the same way as it
    would be encoded in the OPEN message.

That is, you're supposed to tell your peer which capability you're 
complaining about the lack of.

--John

---

From: Erblichs <[email-masked]>
Date: Fri, 18 Aug 2006 17:25:06 -0700

Heys guys,

	

	Mitchell Erblich
	-----------------------

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 18 Aug 2006 20:29:46 -0400

--John

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Aug 2006 21:21:12 -0400

John G. Scudder <[email-masked]> wrote:
>    The Data field in the NOTIFICATION message SHOULD list the set of
>    capabilities that cause the speaker to send the message.

   I read carelessly. :^(

   I saw the "SHOULD" and thought, "I can't depend on anything".

   I saw "set of capabilities that cause" and thought "the set of
capabilities as received."

   I agree your reading is more reasonable. I have no idea how this
is actually implemented by different router vendors...

---

From: John Leslie <[email-masked]>
Date: Fri, 18 Aug 2006 21:42:39 -0400

>    same interface and ONLY 1 gets an Unsupported Capability?

   I don't think you get it. :^(

   A Capabilities Advertisement is not a "request" for anything. It
is rather a promise to support something.

   Apparently there are implementations that think it's a request.
They are non-compliant. I wouldn't begin to guess what various
non-compliant implementations might do.

>    interfaces recieve different types of replies?

   This seems unlikely (ignoring the "requesting" misnomer). At
first blush, I can't think of a case where the requirement for a
capability would vary by interface.

   No.

   While "configuring" which capabilities to advertise may be
possible, it's done mostly to kludge around incompatibilities.
While not all of these are actual non-compliance issues, it's
just as hard to guess what incompatibilities one may be trying
to rectify by "configuring" capabilities.

> different scopes (nbr/peer, intf, and rtr).

   I'm not surprised that implementations differ.

   I do not believe it is appropriate for Standards-Track RFCs
to discuss how implementations actually differ. (The information
changes too quickly, for one thing...)

> improve on the consistency.

   "Best practices" also change.

   Such a discussion would be helpful, I agree, if it can be kept
up-to-date. I can't think how to ensure this; nor do I see an
acceptable path for publication as an RFC.

---

From: Joe Maimon <[email-masked]>
Date: Mon, 21 Aug 2006 08:10:20 -0400

> Joe Maimon <[email-masked]> wrote:

<snip>

> carry on with a peer which does not support some capability _it_

<snip>

> to find out what the incompatibility is.

Is some kind of update to rfc3392 in order? Perhaps something along the 
lines that specifies that Capability Unknown should not be sent when a 
BGP speaker receives a capability anouncement it does not support, but 
rather when it does not receive a capability announcement that is 
locally determined to be essential for peering?

An explanation to such required behavior could be that this allows for 
expansion of BGP features via capabilities without requiring 
interoperability for all new features.

In that manner Unsupported Capability should rather be named Required 
Capability.

As it stands, apparently sending notification when receiving a 
unsupported capability announcment is not within spec -- since it is 
unspecified and illogical, but not because the spec discusses this 
behavior one way or the other.

I can take to my vendor that rfc3392 only "authorizes" the sending of 
Unsupported Capability when a required capability is not received from 
the peer, but that may not be enough for them or for others.

Thanks all,

Joe

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Aug 2006 15:11:44 -0400

> In that manner Unsupported Capability should rather be named Required 

I tend to think of this as "unacceptable capability set".  This covers
the case where you require it and it isn't sent, or you are sent
the capability and you can't live with it for some weird reason.

> behavior one way or the other.

It's mostly out of scope of the spec.  It depends on the capability
and the features supported by the implementation.

I have to apologize for my previous comments on this thread.  I was
mostly addressing the protocol correctness component of it rather
than "does this make sense".  

> the peer, but that may not be enough for them or for others.

Noting the point of view in the wording helps make this a bit more clear:

   If a BGP speaker that supports a certain capability determines that
   its peer doesn't support this capability, 

I.e. "If *you* support a capability, but determine that *they* don't".
This means that you know the capability.

It is also possible that your vendor's implementation may be from
the days when the feature was called "capability negotiation" and
there was confusion as to whether the unsupported capability functionality
was used to converge on a set of acceptable capability (like PPP).

-- Jeff