[quagga-dev 10534] Re: bgp and Multiprotocol Extension Capability

'Chris Hall' chris.hall.list at highwayman.com
Tue May 14 15:36:52 BST 2013


Balaji G wrote (on Tue 14-May-2013 at 04:46 +0100):
....
> >If a neighbour sends no Multiprotocol Extension Capability (MP-Ext)
> >at all, Quagga will happily assume that the neighbour supports all
> >the afi/safi it is configured for.

> Do you mean to say if we don't enable the neighbor in the specific
> SAFI mode (multicast/mpls-vpn) quagga assumes that the neghbor is
> enabled for all SAFIs and gives all the capabilities to the bgp
> speaker ? Have i understood your question ?

Not sure :-(

By afi/safi I mean the tuple <AFI, SAFI> (as in RFC4760).  Although AFI and SAFI are defined separately, it seems to me that only an afi/safi pair has any real meaning.

Suppose Quagga has a neighbour with IPv4/Unicast, IPv4/Multicast and IPv6/Unicast configured at its end (and will therefore send an MP-Ext for each of those afi/safi).  Suppose further that the neighbour only has IPv4/Unicast configured, and does not send any MP-Ext capability at all.  Quagga will notice that there are *no* MP-Ext, and proceed as if the neighbour can handle all the afi/safi it is configured for (at the Quagga end) -- and in this case will send updates for all three afi/safi.

Note: if the neighbour sends one or more MP-Ext, then Quagga does what you would expect and only sends updates for the afi/safi which both ends have announced to each other.  Also, Quagga always sends an MP-Ext for IPv4 Unicast, even if that is the only afi/safi it is configured for, for that neighbour -- unless the sending of all capabilities is suppressed by "neighbor nn dont-capability-negotiate". 

> >Does anyone think it is unreasonable to treat current behaviour as
> >a bug ?

> If the above behavior is what you observe then this is a bug because
> by default the unicast SAFI is alone enabled and the other SAFIs are
> capabilities which are negotiated in the open message.

I think I agree with you that "by default" -- that is, if *no* MP-Ext capabilities are received from a neighbour -- the receiver should, "by default", assume the neighbour supports only IPv4 Unicast.  

What this is saying is that Quagga's default action should assume that neighbours:

 (A) comply with at least RFC2858 "Multiprotocol Extensions for
     BGP-4" (Jun-2000), if anything other than IPv4 Unicast is
     supported.

 (B) and will, if any afi/safi other than IPv4 Unicast is active,
     send an MP-Ext capability for every active afi/safi.

     Where by "active" we mean that the neighbour wishes to send,
     and/or is prepared to receive, updates for the afi/safi.

I think these are reasonable things to assume, ...
---------------------------------------------------------------------
... but it's by no means straightforward.

The history is:

  Mar-1995: RFC1771 A Border Gateway Protocol 4 (BGP-4)
  Feb-1998: RFC2283 Multiprotocol Extensions for BGP-4
  May-2000: RFC2842 Capabilities Advertisement with BGP-4
  Jun-2000: RFC2858 Multiprotocol Extensions for BGP-4

    which introduced the MP-Ext Capability.

  Jan-2007: RFC4760 Multiprotocol Extensions for BGP-4

Quagga's current behaviour is consistent with the RFC2283 world, in which there was no MP-Ext Capability and hence no choice: you had to assume that the neighbour (at the far end) supports the afi/safi it is configured for (at this end).

Clearly it is better to avoid sending updates for afi/safi which the other end is not set up for -- hence the MP-Ext Capability.  The more afi/safi there are, the more reason there is to ensure that a given BGP session only carries the afi/safi that both ends agree on.

So, the rationale for assumption (A) is: (i) that 13 years on, there is no good reason for a Multiprotocol BGP speaker to not comply with RFC2858 (at least), and (ii) only sending updates for agreed afi/safi is safer (and increasingly so). 

The rationale for assumption (B) is: the obvious thing for any BGP speaker to do is to advertise all the afi/safi it is set up for.  All sessions then carry only the afi/safi for which both ends are set up for.  Job done.

But, it's not quite that straightforward.  Assumption (B) actually has two parts:

  (1) if no MP-Ext capability is sent, that that implies
      Multiprotocol Extensions are not supported, and hence
      IPv4 Unicast *is* supported -- as the status quo ante.

  (2) if one or more MP-Ext capabilities are sent, then only
      the afi/safi mentioned are active.

However, RFC2858 and RFC4760 say:

  (a) "A BGP speaker that uses Multiprotocol Extensions SHOULD use the
       Capability Advertisement procedures [BGP-CAP] to determine
       whether the speaker could use Multiprotocol Extensions with a
       particular peer."

  (b) "To have a bi-directional exchange of routing information for a
       particular <AFI, SAFI> between a pair of BGP speakers, each
       such speaker MUST advertise to the other (via the Capability
       Advertisement mechanism) the capability to support that
       particular <AFI, SAFI> route."

It seems to me that para (b) is consistent with (2), but is stronger -- all active afi/safi MUST be advertised.

I take the SHOULD in para (a) to mean that in the absence of any good reason to the contrary (i.e. by default) only the afi/safi advertised by a neighbour should be exchanged with that neighbour.  There is some wiggle room here to allow other means to decide what afi/safi to exchange -- though that doesn't appear consistent with (b).

The RFC does not suggest an interpretation for no MP-Ext capabilities, and does not appear to support (1) above.  But that seems to be a "well known" interpretation.  [And is arguably being "liberal in what you accept" -- given the assumption of RFC2858 as a minimum for any Multiprotocol stuff.]

In short, I think there is a case for both assumptions (A) and (B) -- but it takes more pencil than seems at all reasonable !

Chris





More information about the Quagga-dev mailing list