Re: [Idr] RFC 4684 pedantry - routes with no Route Target

[Robert Raszuk <[e-mail]>]

In the situations where protocol SAFI contains a mix (tagged and not
tagged NLRIs with RTs) I would rather propose to amend the rfc to
exchange default RT + specific RTs. That would potentially allow for
reception of NLRIs with no RT attached + filtering of those against
more specific RTs received which do carry RT ext community.

Thoughts ?

r.

On Wed, May 21, 2014 at 6:20 PM, Robert Raszuk <[e-mail]> wrote:
> Hi Eric,
>
>> The problem arises because, on some NLRIs, the use of RTs is
>> optional.  What you're suggesting is that RT-C should never filter out
>> routes that don't have any RTs.  That does seem right.
>
> Well is it really ... ?
>
> Remember that RFC 4684 enforces for any SAFI it is enabled under no
> route exchange happens at all till intersecting RTs are received over
> RTC SAFI.
>
> That means that the spec is 180 degrees opposite to your above claim
> that routes with no RTs should be always exchanged.
>
> Cheers,
> R.
>
>
> On Wed, May 21, 2014 at 5:21 PM, Eric Rosen <[e-mail]> wrote:
>> Jeff> In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the
>> Jeff> following documentation in section 4.4:
>>
>> :   When a PE distributes this NLRI via BGP, it may include a Route
>> :   Target (RT) Extended Communities attribute.  This RT must be an
>> :   "Import RT" [RFC4364] of each VRF in the MD.  The ordinary BGP
>> :   distribution procedures used by [RFC4364] will then ensure that each
>> :   PE learns the MDT-SAFI "address" of each of the other PEs in the MD,
>> :   and that the learned MDT-SAFI addresses get associated with the right
>> :   VRFs.
>>
>> The next paragraph though makes it clear (well, sort of) that the MDT-SAFI
>> routes without RTs need to be distributed to all the PEs, and filtered as
>> necessary by the PEs to which they are distributed.
>>
>> Jeff> RFC 4684's procedure says in section 6:
>> :   A VPN NLRI route should be advertised to a peer that participates in
>> :   the exchange of Route Target membership information if that peer has
>> :   advertised either the default Route Target membership NLRI or a Route
>> :   Target membership NLRI containing any of the targets contained in the
>> :   extended communities attribute of the VPN route in question.
>>
>> Jeff> Quite frankly, we have a bug in that MDT's are not getting propagated
>> Jeff> when RT-C is in use because we're treating it as a "VPN NLRI".
>>
>> Yes, one might conclude that whoever decided to omit the RTs from MDT-SAFIs
>> wasn't much concerned about the use of RT-C (or any other RT-based filtering
>> mechanisms) to constrain the distribution of routes to or from intermediate
>> nodes.
>>
>> Jeff> The broader question I'd put to the working group is whether any NLRI
>> Jeff> not  having RTs isn't really a "VPN NLRI" for purposes of RT-C
>> Jeff> filtering
>>
>> I don't think RFC4684 really intends to restrict its applicability to "VPN
>> routes".  It does say in section 1: "This mechanism is applicable to any BGP
>> NLRI that controls the distribution of routing information by using Route
>> Targets".  The problem arises because, on some NLRIs, the use of RTs is
>> optional.  What you're suggesting is that RT-C should never filter out
>> routes that don't have any RTs.  That does seem right.
>>
>> You may want to look at draft-zzhang-l3vpn-mvpn-global-table-mcast-02.txt,
>> especially section 2.2 ("Route Targets").  In that draft, there are routes
>> of the MCAST-VPN SAFI that may (optionally) carry RTs, and the intention is
>> that it be possible to use RT-C to constrain the distribution of those
>> routes, if (and only if) the routes carry RTs.  However, those routes cannot
>> really be said to be VPN routes, as they are used for controlling multicasts
>> that do not occur in a VPN context.
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr