[quagga-dev 10537] Re: bgp and Multiprotocol Extension Capability
pmohapat at cumulusnetworks.com
Sun May 19 16:09:15 BST 2013
>> - this rule, however, does not apply to <ipv4 unicast>, as per the
>> original RFC. Quagga BGP can thus send <ipv4 unicast> routes to
>> a speaker in the absence of an mp_ext listing <ipv4 unicast>
>> (even if the neighbor has announced an mp_ext capability, for
>> other <afi, safi> pairs for example).
> I don't think that's quite right. If the neighbour sends one or more
> MP-Ext, then if they want IPv4/Unicast to be "enabled" for the
> session, then they have to announce that as well... otherwise there is
> no mechanism to "enable" this and/or that afi/safi, but NOT
> 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.
>> Strange that I don't see this behavior in Quagga (based on a minimal
>> test). Also, from a cursory glance at the code, I see that it does
>> the right thing by checking peer->afc_nego[afi][safi] while
>> announcing the routes.
> Well... towards the end of bgp_open_receive(): if (!mp_capability ...)
> it copies
> peer->afc to peer->afc_nego... which I believe has the effect
Thanks, saw that. 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.
> My conclusion is that the behaviour should be:
> * if one or more MP-Ext are received, then:
> (a) they specify what the neighbor wishes to "enable"
> (b) all other afi/safi combinations are denied.
> And, if any other afi/safi are mentioned (for
> example in a Graceful Restart capability) any
> settings for those afi/safi are ignored.
> * if no MP-Ext are received, then:
> (c) an MP-Ext IPv4/Unicast is assumed to be implied.
> In particular... any setting for IPv4/Unicast in
> any other capability is accepted.
> This allows for a (theoretical) BGP implementation
> which does not support RFC4760, but does support
> (say) RFC4724 Graceful Restart.
> (d) all other afi/safi combinations are denied,
> UNLESS "neighbor nn override-capability" is set,
> in which case all afi/safi configured (for the
> session) at the receiving end are assumed to
> be "enabled". BUT NOT any Graceful Restart etc
> for anything other than IPv4/Unicast.
> So... "neighbor nn override-capability" covers the (now pretty
> theoretical) case of an RFC2283 (pre-MP-Ext) neighbour -- and only
> that case.
> Note that (b) and (d) are strict about settings for anything other
> than IPv4/Unicast -- declaring (say) support for Graceful Restart for
> (say) IPv6/Unicast is meaningless unless that address family is also
> declared in an MP-Ext. (And that means it MUST also declare
> IPv4/Unicast in an MP-Ext, if it wants to "enable" that afi/safi along
> with others.) I believe this is consistent with RFC4760, and the
> rationale is: absence of MP-Ext (i.e. none at all) implies absence of
> Multiprotocol support (which implies support for IPv4/Unicast *only*,
> for all purposes).
> BUT, the RFCs are silent on this. RFC4724 Graceful Restart does not
> say that if a neighbour declares the ability to preserve forwarding
> state for a given afi/safi, then that neighbour is implicitly
> declaring it wishes to send updates for that afi/safi and is willing
> to receive same. Nor does it say otherwise. You have to ask why a
> neighbour would say something about an afi/safi it did NOT want
From RFC4724 (and this seems to imply what you are asking for):
Address Family Identifier (AFI), Subsequent Address Family
The AFI and SAFI, taken in combination, indicate that Graceful
Restart is supported for routes that are advertised with the
same AFI and SAFI. Routes may be explicitly associated with a
particular AFI and SAFI using the encoding of [BGP-MP] or
implicitly associated with <AFI=IPv4, SAFI=Unicast> if using
the encoding of [BGP-4].
> ...so, perhaps any mention of a given afi/safi should be treated as if
> an MP-Ext had been received ? I'm worried about what it then means if
> IPv4/Unicast is not mentioned anywhere: what does it mean if there are
> no MP-Ext at all, and IPv4/Unicast is not mentioned anywhere, but
> (say) IPv6/Multicast is mentioned in a Graceful Restart capability --
> is IPv4/Unicast "enabled" or not ? <yuck>
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'
Now if the peer restarts, the speaker has a way to execute the GR procedure.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Quagga-dev