Subject: RE: BGP4 draft ; section 6.2

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 13 Sep 2002 11:17:57 -0400

Kind of a buggy area.  Try "neighbor 1.1.1.1 dont-capability-negotiate".
Not sure on the Juniper side.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 
Sent: Friday, September 13, 2002 9:44 AM
To: BGP mailing list
Subject: BGP4 draft ; section 6.2

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.

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 13 Sep 2002 11:22:23 -0400

(not sure if this got thru, it was not plain text)

 
-----Original Message-----
 
All,

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 13 Sep 2002 11:42:55 -0400

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.

-----Original Message-----

All,

---

From: "David Margulis" <[email-masked]>
Date: Tue, 17 Sep 2002 09:40:09 +0300

-----Original Message-----
From: Mathew Richardson [mailto:[email-masked]]
Sent: Friday, September 13, 2002 5:08 PM
To: [email-masked]
Cc: BGP mailing list
Subject: Re: BGP4 draft ; section 6.2

> [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

---

From: "David Margulis" <[email-masked]>
Date: Tue, 17 Sep 2002 09:41:16 +0300

-----Original Message-----

All,

---

From: [email-masked]
Date: Tue, 17 Sep 2002 11:51:27 +0200

Hi Ben,

I am not always fully focussed to the worklist as I  guess I should
be  ;-(.   So I guess I must have missed your mail on this.
If you still have this mail I would really appreciate it if you could forward
it again.

Thanks,

Hans

"Abarbanel, Benjamin" wrote:

Hans:I
wonder why you have not responded to my previous email?Ben-----Original
Message-----

Sent: Friday, September 13,
2002 9:44 AM

To: BGP mailing list

Subject: BGP4 draft ; section
6.2

All,

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

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.