[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] BGP: Vendor Specific Capabilities
Well this is an RFC 4271 question really. You will find the answer in
Section 6.2, OPEN Message Error Handling:
If one of the Optional Parameters in the OPEN message is not
recognized, then the Error Subcode MUST be set to Unsupported
Optional Parameters.
So in answer to the first part of your question, that's a MUST.
Regarding what to do if the peer closes the connection without any
indication of why (no NOTIFICATION) it's really up to you, but I would
be disinclined to go through extensive gyrations trying to guess what
the peer's problem is.
--John
On Apr 29, 2008, at 6:40 PM, <sundeep.mudgal at nokia.com> wrote:
>
>
> John,
>
> I have one more more doubt which needs clarification :
>
> In response to an open message with capabilities, a peer
> that supports no capabilities
>
> 1) MUST send NOTIFICATION message with unsupported
> optional parameter.
>
> OR
>
> 2) SHOULD send NOTIFICATION message with
> unsupported optional parameter.
>
>
> Say for example, as a BGP speaker X support some capability
> and its peer Y has the basic implementation of BGP without any
> optional capabilities. So in that case:
>
> - Will the peer Y always (MUST) send NOTIFICATION
> message to the speaker X with unsupported optional parameter?
>
> - Or if a peer Y doesn't send any notification and
> closes the connection then should the speaker X send a new open
> message without any optional capabilities or should speaker X wait
> for the peer's open message and adjust accordingly?
>
>
> I don't see this defined clearly in any of the RFCs which I
> have read. Could you please clarify this or point me to the section
> of RFC which states this?
>
> thanks,
> Sundeep
>
...
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr