[quagga-dev 10539] FW: bgp and Multiprotocol Extension Capability
chris.hall.list at highwayman.com
Tue May 21 19:25:12 BST 2013
Pradosh Mohapatra wrote (on Sun 19-May-2013 at 16:09 +0100):
> Chris Hall wrote:
>> If the neighbor does not send any MP-Ext at all -- I suspect
>> this case is as rare as hens' teeth, but the code needs to do
>> something -- then I think IPv4/Unicast, only, should be
>> assumed (in this day and age), by default.
> I realize this is open to interpretations in this day and age ;-)
> But strictly speaking, any protocol extension is done in a
> backward-compatible way. Use of MP_EXT capability is limited to
> advertisement of prefixes in MP_REACH and MP_UNREACH attributes
> (IOW, they go hand-in-hand). The speaker is free to send 'ipv4
> unicast' prefixes the old way in the 'network layer reachability
> information' part of the UPDATE message.
Ah. This is an interpretation I had not considered :-)
So, by this interpretation, the presence of an MP-Ext for a given
afi/safi says that the peer supports the sending/receiving of
MP_REACH/MP_UNREACH attributes for that afi/safi, and nothing more.
* for IPv4/Unicast, an MP-Ext signals only that MP_REACH/
MP_UNREACH may be used for IPv4/Unicast...
...but, says nothing at all about the exchange of
IPv4/Unicast in the "ordinary" or "old" way,
which is implicitly enabled at all times.
* however, for other afi/safi: MP_REACH/MP_UNREACH are
essential for the exchange of routes, so the MP-Ext
implicitly enables that exchange.
OK. If I have understood the interpretation, then now I understand
assertions elsewhere that sending an MP-Ext for IPv4/Unicast is not
"strictly required" by RFC4760. But that's not to say that I agree
with the interpretation :-)
> .... So the discussion is for the case when the peer didn't
> send any multi protocol capabilities. I think we agree that
> this should be fixed to limit it to ipv4-unicast.
Yup: if no MP-Ext at all are received, treat as if MP-Ext for
IPv4/Unicast has been received .
> I think the implementation should identify the meaning
> of an <afi, safi> pair in the context of the capability
> being parsed. For example:
> if (GR cap contains <afi1, safi1>), mark 'peer can
> preserve fwding for <afi1, safi1>'
> if (MP_EXT cap contains <afi1, safi1>), mark 'peer can
> exchange <afi1, safi1> routes (thus start accepting
> those routes)'
I agree that this is the most straightforward approach.
If the peer sends 'peer can preserve forwarding' for (say)
IPv6/Unicast, that does NOT imply 'peer can exchange IPv6/Unicast' --
the capabilities are independent. And, similarly for all other
afi/safi related capabilities.
I think the horse is now quite dead, but I will flog it one last
time... the presence of MP-Ext for a given afi/safi may be treated as
a "gate" for other capabilities related to that afi/safi...
...*EXCEPT* when no MP-Ext at all are received. A capability which
applies to named afi/safi may be applied to IPv4/Unicast, *without*
requiring support for Multiprotocol BGP. Hence the rule "if no MP-Ext
at all are received, treat as if MP-Ext for IPv4/Unicast has been
Goodness... what a lot of pencil for such a small issue !
 i.e. using the "Withdawn Routes" and/or "Network Layer
Reachability Information" fields of the UPDATE message -- and not
using MP_REACH and/or MP_UNREACH attributes.
 Amongst the difficulties I have with this interpretation is that
it does not allow a peer to "disable" the exchange of IPv4/Unicast
Further, I think the interpretation is incompatible with Section 7,
"Use of BGP Capability Advertisement", in RFC2858, and the same
section (Section 8) in RFC4760.
The first paragraph of the RF2858 section says:
"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."
and in Section 8 of RFC4760 the same text appears, but with a
"SHOULD". I read this as allowing just enough wiggle room to allow
for the support of an RFC2283 peer, for whom the MP-Ext capability
does not exist. (But it may also be intended to allow for
configuration to override or ignore whatever capabilities are
The last paragraph of the section says (RFC2858):
"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> routes."
the same text appears in RFC4760, but with a "MUST". I read this to
say that, if both ends advertise the "capability to support" a given
afi/safi, then "bi-directional exchange" for that afi/safi is enabled.
Further, the "MUST" means that under *any* other circumstances,
exchange of routes is disabled.
Clearly, if one of the two BGP speakers only supports RFC2283 (and
cannot therefore send any MP-Ext Capability), then this requirement
cannot be met. There is an apparent dissonance between the first
paragraph's SHOULD and the last paragraph's MUST. However, supporting
the RFC in one BGP speaker cannot magically cause the software in
another BGP speaker to upgrade itself. So, we might reasonably read
"between a pair of BGP speakers" as "between a pair of BGP speakers
which both support the Multiprotocol Extensions Capability" -- and the
dissonance goes away. (Or, you might argue that the last paragraph
ought to say SHOULD and not MUST -- to allow for configuration to
override or ignore whatever capabilities are advertised.)
There is no suggestion that IPv4/Unicast is an exception to these
rules. Nor does the text specify exchange of routeing information
specifically by MP_REACH/MP_UNREACH attribute. But, hey, nor does it
say otherwise !
The term "capability to support" is arguably a bit of a distraction.
If both ends advertise it, then this nominal "capability to support"
enables bidirectional exchange. So, "support" in this case doesn't
just mean the peer can (in principle) support the afi/safi, but also
means that it is now ready to receive UPDATEs for that afi/safi and
may send UPDATEs (if both ends "support"). It's not possible for a
peer to advertise that it could handle an afi/safi, but at present
does not care to... perhaps that is not thought to be of any use !
 Noting that the possibilities when a peer doesn't send any MP-Ext
Capability at all are:
a) it does not support Multiprotocol stuff at all...
...so, implicitly enabled for IPv4/Unicast, sending
NLRI the "ordinary" or "old" way.
b) it supports only RFC2283 (now 15 years old).
c) it supports at least RFC2858 (which introduced the
MP-Ext Capability, 13 years ago), but does not
believe it is necessary to send MP-Ext in order
to exchange IPv4/Unicast the "ordinary" or "old"
So, what we are agreeing is: by default we assume either (a) or (c),
but not (b); and cover (b) by the "override-capability" configuration
option. In effect, "in this day and age" we expect any BGP
implementation which supports Multiprotocol BGP to support at least
[IMHO (c) is based on an incorrect interpretation of RFC2858 and/or
RFC4760... but allowing for (a) means allowing for (c), so correctness
of interpretation is moot.]
 actually, Quagga only supports RFC4760 Multiprotocol BGP peers,
not RFC2283 or RFC2858 ones. The earlier RFCs both allow for SNPA.
Current Quagga will whimper (WARNING level logging) if it sees a
non-zero count of SNPA, but does not attempt to step over any SNPA...
so will interpret any SNPA detritus as part of the NLRI !! This is as
required by RFC4760... Go Figure(tm).
 It may be perfectly enchanting to learn that 'peer can preserve
forwarding for IPv6/Unicast' (say), but it is of absolutely no
consequence unless 'peer can exchange IPv6/Unicast' as well !
 I suppose a capability could be invented which means something for
an afi/safi even though no routes for that afi/safi can/will be
exchanged (!). Hence MP-Ext *may* be a gate for other afi/safi
capabilities -- but not, necessarily, for all such capabilities.
More information about the Quagga-dev