Subject: issue 44

From: Yakov Rekhter <[email-masked]>
Date: Wed, 25 Sep 2002 07:17:35 -0700

44) Section 6.2: OPEN message error handling
  ----------------------------------------------------------------------------
  Status: No Consensus
  Change: Potentially
  Summary: One commentor observed that the spec seems to specify behavior
    that doesn't seem to be observed by extant implementations, and suggested
    modifications to the spec.  There is no consensus as to if this observation
    holds across implementations, or if it does, if we should change the spec.
  
  Discussion:   
  
  The "BGP4 draft ; section 6.2" thread began with a discussion of
  section 6.2: OPEN message error handling.  Specifically:
  
  "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.
  
  The response to this quoted RFC2842, Capabilities Advertisement with BGP-4:
  
     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.
  
RFC2842 assumes that a router (that doesn't implement RFC2842)
would close the BGP session when the router receives an OPEN message
with an unrecognized Optional Parameter. Therefore the text in the
spec should be left unmodified.

Yakov.