Subject: [Idr] Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00

From: "John G. Scudder" <[email-masked]>
Date: Thu, 25 Jun 2009 14:36:01 -0400

FYI.

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: June 25, 2009 2:30:20 PM GMT-04:00
> To: John Scudder <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked] 
> >
> Subject: New Version Notification for draft-scudder-idr-rt-constrain- 
> lite-00
>
>
> A new version of I-D, draft-scudder-idr-rt-constrain-lite-00.txt has  
> been successfuly submitted by John Scudder and posted to the IETF  
> repository.
>
> Filename:	 draft-scudder-idr-rt-constrain-lite
> Revision:	 00
> Title:		 RT-Constrain Lite for Provider Edge Routers
> Creation_date:	 2009-06-25
> WG ID:		 Independent Submission
> Number_of_pages: 5
>
> Abstract:
> RFC 4684, "Constrained Route Distribution for Border Gateway
> Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol
> (IP) Virtual Private Networks (VPNs)" provides a powerful and general
> means for BGP speakers to exchange and propagate Route Target
> reachability information which is used for cooperative route
> filtering.  However, the complexity of implementing the entire
> specification may have impeded its widespread deployment.  This
> document specifies the subset of functionality which is required for
> a provider edge router ("PE") to originate Route Target NLRI.  Such
> PEs need not implement any filtering functionality.
>
>
>
> The IETF Secretariat.
>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Jun 2009 08:29:30 -0700

Hello John,

Let me share with you two observations:

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.

Cheers,
R.

>> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" 
>> <[email-masked]>
>> Subject: New Version Notification for 
>> draft-scudder-idr-rt-constrain-lite-00
>>
>>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "John G. Scudder" <[email-masked]>
Date: Sat, 27 Jun 2009 14:17:10 -0400

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- 

>    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

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 27 Jun 2009 13:32:29 -0700

Hi John,

I am completely not convinced that what is proposed in RTC-lite draft is 
not already covered and can be implemented by supporting mandatory 
protocol extension contained in the main RFC4684 specification without 
violating it.

WFIW I can easily see the full RFC4684 implementation allowing to drop 
incoming filters (with exceptions or not) on inbound reducing it's 
further processing and storing by BGP. Such exceptions may include 
allowing to accept default filter in order not to be subject of delayed 
advertisement of VPN routes due to a required otherwise timeout mechanism.

My quote provided below seems to be proving my point of view.

Perhaps others co-authors of RFC4684 as well as implementors can comment 
  on it.

On the practical note I seriously doubt that any commercial 
implementation of L3VPN would choose to only support RTC-lite and not 
full RFC4684 in it's operating system.

Would you agree that this draft should be progressed only if we would be 
able to find an implementation that supports it and not full RFC4684 ?

And as soon as such implementation would gain full RFC4684 support we 
either find another one supporting only RTC-lite or move RTC-lite to 
historical ?

Cheers,
R.

> Your main question is essentially what the contribution of 
> rt-constrain-lite is.  Fair enough.  There are two contributions, to my 
> 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).
> 
> 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:
> 
> 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 
> 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
>

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 29 Jun 2009 12:21:28 -0400

Robert,

I agree that this is a supportable point:

On Jun 27, 2009, at 4:32 PM, Robert Raszuk wrote:
> incoming filters (with exceptions or not) on inbound

But it's at odds with your previous comment:

On Jun 27, 2009, at 11:29 AM, Robert Raszuk wrote:
> That directly violates RFC4684 as quoted above.

Since the text you objected to pertains exactly to the dropping of  
incoming filters, I guess you have changed your mind on this point.   
That is fine with me.

> able to find an implementation that supports it and not full RFC4684 ?

I generally don't think protocol specifications should be progressed  
without implementation, so sure.

> either find another one supporting only RTC-lite or move RTC-lite to

Seems generally reasonable.

Thanks,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 29 Jun 2009 10:08:43 -0700

Hi John,

> I agree that this is a supportable point:

Thank you.

But I don't think I have changed my mind. The difference is that an 
implementation may _allow_ to configure incoming filter, but for example 
always permit to get the default filter in.

If the implementation does not have an ability to even receive a filter 
as RTC-lite allows (regardless if the sender is aware of it or not) it 
in my view violates the RFC4684 or for that matter creates an 
interesting precedence for BGP4 itself.

Thx,
R.