Subject: Re: BGP4 draft ; section 6.2

From: [email-masked]
Date: Tue, 17 Sep 2002 12:58:01 +0200

All,

Thanks for the replies on this question.

I have tried to group all answers I have received sofar below, toegther
with some observations from my side.

Hans De Vleeschouwer.

Original question:

All,

I have a doubt related to section 6.2: OPEN message error handling,
related to the statement:

" If one of the optional parameters in the Open mesage is not recognized,
then the error subcode is set to 'unsupported optional parameters"

We have hit on this line when we were testing a BGP connection between
a speaker that supported capability negotiation and a speaker that did
not.

The speaker that did not support the neogotiation closed down the peering
session using the error clause mentioned above.  Sometimes this lead
to the other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes.

This router manufacturer stated in a reply to this that :

"One should not close down the connection if an optional parameter
is unrecognised. That would make this parameter basically mandatory.

This is an well known error in the BGP spec. Neither Cisco or Juniper
do this"

If this is true it might be good to adapt the text.

Hans de Vleeschouwer

Alcatel.

Replies received:

Mathew Richardson wrote:

> [email-masked] <[email-masked]>
[Fri, Sep 13, 2002 at 03:43:55PM +0200]:

From rfc2842:

A BGP speaker determines that its peer doesn't support
capabilities

advertisement, if in response to an OPEN message that
carries the

Capabilities Optional Parameter, the speaker receives
a NOTIFICATION

message with the Error Subcode set to Unsupported Optional
Parameter.

In this case the speaker should attempt to re-establish
a BGP

connection with the peer without sending to the peer the
Capabilities

Optional Parameter.

mrr

This section from the Capabilities Advertisement RFC, is indeed
inline with the section 6.2 of the BGP4 specification.  For me however
the question remains if most implementations do no simply ignore optional
parameters that are unknown. And if so, if the text stated above reflects
what is implemented by routers that do not have capability advertisement
at all.

"Natale, Jonathan" wrote:

I just re-read your email; it is the rtr that does
not have capabilities at

all...

1) currently, not too many implementations do the exponential back off
in

response to an error, and the whole FSM thing is being re-hashed now.
So it

will flap.

2) ignoring options (since *I think*(???) capabilities is the only one
used

anywhere) is probably not that bad of an idea since sending capabilities
are

only saying what the sender supports, not what the receiver supports.

Obviously, ignoring capabilities is better when peering with a vendor
that

does not re-open without the capabilities as they should per rfc2842
(or

maybe a config switch for this).  This is not spelled out in any
rfc that I

am aware of

3) I do not know about the Juniper side of this.

4) you might want to check the vendor's bugs.

5) I *think* what the vendor was referring to is:

From: Natale, Jonathan [mailto:[email-masked]]

Sent: Tuesday, August 06, 2002 4:19 PM

To: [email-masked]'

Subject: capability

I would like to propose:

>"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."

>be changed to:

>"If a BGP speaker that **does not want its peer to support** a certain

>capability determines that

>    its peer **does** 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, the peer
MAY re-open the

>    connection without the offending capability-this
is known as capability

>    negotiation.**"

... The response I got was basically that the draft is already done.

Here I find 3 elements:

1. the matter of the exponential backoff. This is indeed an interesting
thing, since I have noticed during testing that most routers do not seem
to do this, at least not in all cases (e.g. no exponential backoff in case
of a TCP connection that fails with an RST message.).

However, as I understood this matter is subject of new ongoing work,
and is therefore not part of the current rework of the BGP draft?

2. the reaction to unrecognised TLVs. Here I understand that Mathew
is prepared to discuss changing the way a peer should react to such an
event, i.e. changing the wording of section 6.2 so that  unrecognised
optional TLVs should be ignored.

3. the reaction to an 'undesired' capability. This again is an interesting
question that is to my opinion not fully clear (several vendors again react
differently in this case). However it is taking the original problem one
step further, so I would like to have this outside of this discussion for
now.

---

From: [email-masked]
Date: Wed, 18 Sep 2002 12:19:48 +0200

[email-masked] wrote:

> Hans,
>
> Please send your mails with plain ASCII text encoding.  It is a mess to
> read your html in mutt.
>

Sorry for this, please find attached the version in plain ascii.

> Thanks!
> Andrew

All,

I have tried to group all answers I have received sofar below, toegther with some observations
from my side.

Hans De Vleeschouwer.

Original question:

  All,

  I have a doubt related to section 6.2: OPEN message error handling, related to the statement:

  " If one of the optional parameters in the Open mesage is not recognized, then the error
subcode is set to
  'unsupported optional parameters"

  We have hit on this line when we were testing a BGP connection between a speaker that supported
capability
  negotiation and a speaker that did not.

  The speaker that did not support the neogotiation closed down the peering session using the
error clause mentioned
  above.  Sometimes this lead to the other router to repeat the OPEN message with the Capability
optional parameter; a
  game that went on for minutes.

       "One should not close down the connection if an optional parameter is unrecognised. That
would make
       this parameter basically mandatory.

       This is an well known error in the BGP spec. Neither Cisco or Juniper do this"

  Hans de Vleeschouwer
  Alcatel.

Replies received:

Mathew Richardson wrote:

  > [email-masked] <[email-masked]> [Fri, Sep 13, 2002 at
03:43:55PM
  +0200]:

  From rfc2842:

     A BGP speaker determines that its peer doesn't support capabilities
     advertisement, if in response to an OPEN message that carries the
     Capabilities Optional Parameter, the speaker receives a NOTIFICATION
     message with the Error Subcode set to Unsupported Optional Parameter.
     In this case the speaker should attempt to re-establish a BGP
     connection with the peer without sending to the peer the Capabilities
     Optional Parameter.

  mrr

This section from the Capabilities Advertisement RFC, is indeed inline with the section 6.2 of
the BGP4 specification.
For me however the question remains if most implementations do no simply ignore optional
parameters that are
unknown. And if so, if the text stated above reflects what is implemented by routers that do not
have capability
advertisement at all.

  I just re-read your email; it is the rtr that does not have capabilities at
  all...

  1) currently, not too many implementations do the exponential back off in
  response to an error, and the whole FSM thing is being re-hashed now.  So it
  will flap.

  2) ignoring options (since *I think*(???) capabilities is the only one used
  anywhere) is probably not that bad of an idea since sending capabilities are
  only saying what the sender supports, not what the receiver supports.
  Obviously, ignoring capabilities is better when peering with a vendor that
  does not re-open without the capabilities as they should per rfc2842 (or
  maybe a config switch for this).  This is not spelled out in any rfc that I
  am aware of

  I would like to propose:

  >    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
  >    its peer **does** 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, the peer MAY re-open the
  >    connection without the offending capability-this is known as capability
  >    negotiation.**"
  >

Here I find 3 elements:

1. the matter of the exponential backoff. This is indeed an interesting thing, since I have
noticed during testing that most
routers do not seem to do this, at least not in all cases (e.g. no exponential backoff in case of
a TCP connection that fails
with an RST message.).
However, as I understood this matter is subject of new ongoing work, and is therefore not part of
the current rework of
the BGP draft?

2. the reaction to unrecognised TLVs. Here I understand that Mathew is prepared to discuss
changing the way a peer
should react to such an event, i.e. changing the wording of section 6.2 so that  unrecognised
optional TLVs should be
ignored.

3. the reaction to an 'undesired' capability. This again is an interesting question that is to my
opinion not fully clear
(several vendors again react differently in this case). However it is taking the original problem
one step further, so I
would like to have this outside of this discussion for now.