Robert, thanks for your comments.Your main question is essentially what the contribution of rt- constrain-lite is. Fair enough. There are two contributions, to my way of thinking. The first and more important is that (as I will explain below) there are normative changes between rt-contrain-lite and rt-constrain. The two are interoperable, but not identical. The second is that for many deployment scenarios (specifically PE routers) full-on rt-constrain is more than is needed. The rt-constrain-lite document would provide a single document that could be cited in procurements, rather than either citing full rt-constrain (even though it provides more than is required) or citing full rt-constrain with caveats (which is a messy way of doing it).
As for the normative changes: you actually identify this yourself, in your message. As you point out, rt-constrain-lite specifically exempts the PE from having to honor filtering for received rt- constrain routes. This is an interoperable difference between the two.
As an aside, you've also inadvertently pointed out a bug in the rt- constrain specification. The first paragraph you quote:
"A BGP speaker MAY participate in the distribution of Route Targetinformation without using the learned information for purposes of VPNNLRI output route filtering, although this is discouraged."
would not seem to be compatible with the second one you quote:
"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 theextended communities attribute of the VPN route in question."
although I guess you can observe that the latter paragraph is a "should" and not a "must". (If you take this point of view you would also have to agree that rt-constrain-lite does not "directly violate" RFC4684.)
Regarding your secondary question about the PE honoring, or not, rt- constrain route filtering -- if the PE were required to do this, that is the same as requiring it to do a full RFC4684 implementation, which would defeat the point of a "lite" flavor. I don't think it's reasonable to say "just parse default but nothing else" since it's perfectly permissible for the RR to never send a default, which would leave the PE stuck forever.
However, this does lead me to consider that you could ask the PE to wait until it has received any rt-constrain route at all from the RR before advertising VPN routes. This heuristic would seem to be almost the same as waiting for the default route without having the same failure mode if the default is never sent.
Regards, --John On Jun 27, 2009, at 11:29 AM, Robert Raszuk wrote:
Observation #1: Let's notice that original RFC4684 already well defines rt-constrain lite in it's published text: "A BGP speaker MAY participate in the distribution of Route Targetinformation without using the learned information for purposes of VPNNLRI output route filtering, although this is discouraged." As RT-constrain lite draft does exactly the above paragraph it is at least redundant. Observation #2: The original RFC4684 says:"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 theextended communities attribute of the VPN route in question." RT-C lite says: "Specifically, the PE need only implement the ability to send Route Target Membership NLRI; it need not have the ability to receive, store and filter upon such information."That directly violates RFC4684 as quoted above. After exchanged the 4684 capabilities the PE should wait for the default rt filter or atomic onebefore it starts any VPN route advertisement. The same for the RR side ... RR may expect after negotiating RFC4684 capability not to receive any routes from a peer until it has send default rt NLRI or an atomic one. That may be used for peer prioritization as an example. Conclusion of the observation #2 above leads me to believe thatreception and parsing of at least default rt-filter by RT-Constrain liteis required.But I am more interested to find out what is missing today in RFC4684 inthe light of the first observation.