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

Pradosh Mohapatra 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
> IPv4/Unicast.
> 
> 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
> described.


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
> used…


From RFC4724 (and this seems to imply what you are asking for):

      Address Family Identifier (AFI), Subsequent Address Family
         Identifier (SAFI):

         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.

- Pradosh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20130519/ed4be059/attachment-0001.html>


More information about the Quagga-dev mailing list