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

[Robert Raszuk <[e-mail]>]

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