RE: INFORM proposal and MP-BGP (RFC 2858)

["Abarbanel, Benjamin" <[e-mail]>]

> Also:
> "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. --draft-ietf-idr-rfc2842bis-02.txt,
> "Capabilities Advertisement with BGP-4"
> 
> Seems harsh, I would think that the preferred behavior is to 
> re-open w/o the
> offending capability.  A major vendor does not and they have 
> a back door cmd
> to work around it.  They also have a bug on it but based on history
> (AS_CONFED_SET <-> AS_CONFED_SEQUENCE, deterministic med, etc...) the
> rfc/draft seem to follow them NOT the other way around. Any 
> thoughts???

For network deployment phasing reasons and backward compatibility reasons.
We should not drop a peer just because we recieved a message that contained
unrecognized capability(s). I vote the spec be changed to accomodate an
evolving network. The lesser capable BGP router should silently ignore the
unrecognized capability(s) or the entire message if there is nothing else
recognizable in it. The more advanced BGP capable router upon detecting a
peer that does not understand certain advanced capability(s) should merely
not send any more advanced capability(s) to this peer. The two routers
should also log the event for their operators to review.

Also, if we drop peers do to unrecognized messages or capabilities, we make
it easier for hacker attacks causing network outages, or the topology to get
unstable.  

Right?

Ben