[quagga-dev 10534] Re: bgp and Multiprotocol Extension Capability
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
(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
(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 !
More information about the Quagga-dev