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

[Jeffrey Haas <[e-mail]>]

IDR,

RFC 4684 (Constrained Route Target Distribution) is obviously a useful tool.
At work, we've run into an interesting case and I thought I'd share some of
the internal debate on it.

In RFC 6037 ("draft-rosen" multicast VPNs), the MDT SAFI has the 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.

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.

Quite frankly, we have a bug in that MDT's are not getting propagated when
RT-C is in use because we're treating it as a "VPN NLRI".  Simple fix, but
one that leaves me wondering if the issue is more general - and perhaps
worthy of an errata for RFC 4684.

For the MDT case, one can make the argument that since it may be distributed
without RTs, it's only a "VPN NLRI" if it contains RTs.

The broader question I'd put to the working group is whether any NLRI not
having RTs isn't really a "VPN NLRI" for purposes of RT-C filtering.  This
really leaves two simple schools of thought:
1. No RT, no RT-C filtering.
2. MDT SAFI is an odd-ball case, just deal with that.  (And perhaps warn in
future BGP documents that may use RT-C about how to deal with no RTs when
they're optional.)

-- Jeff