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 Target
information without using the learned information for purposes of VPN
NLRI 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 the
extended 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 Target
information without using the learned information for purposes of VPN
NLRI 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 the
extended 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 one
before 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 that
reception and parsing of at least default rt-filter by RT-Constrain lite
is required.
But I am more interested to find out what is missing today in RFC4684 in
the light of the first observation.