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

[Eric Rosen <[e-mail]>]

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.