IETF 75

Folks,

Its about time to start thinking about agenda items for the next
IETF. Please forward any IDR agenda items you might have to Sue and
myself. The deadline is July 17, 2009.

And if you plan to make a presentation, please also keep in mind
the rule "no Internet Draft - no time slot".

Sue & Yakov.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

MRAI revision implementation survey

Hi,

I have attached a really quick survey, to help determine the current 
state of MRAI values and so help draft-ietf-idr-mrai-dep-00.txt to 
progress. I would be very grateful to anyone who could take a few 
minutes to fill it in and reply!

thanks,
-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
You worry too much about your job.  Stop it.  You are not paid enough to worry.

	Implementation Survey on the BGP Minimum Readvertisement Interval
	-----------------------------------------------------------------
	
Organisation:	
Implementation:	

QUESTIONS
---------

1. What are the default values for your implementation's MRAI, for iBGP and
eBGP, and for any/all AFI/SAFIs (if defaults vary between them):

iBGP: 
eBGP:


2. Can the MRAI value be configured:

Fwd: New Version Notification for draft-chen-bgp-ext-opt-param-01

FYI.  This version uses a simpler method of encoding the extended  
length than -00 did.

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: June 25, 2009 12:03:23 PM GMT-04:00
> To: John Scudder <jgs <at> juniper.net>
> Cc: "enkechen <at> cisco.com" <enkechen <at> cisco.com>
> Subject: New Version Notification for draft-chen-bgp-ext-opt-param-01
>
>
> A new version of I-D, draft-chen-bgp-ext-opt-param-01.txt has been  
> successfuly submitted by John Scudder and posted to the IETF  
> repository.
>
> Filename:	 draft-chen-bgp-ext-opt-param
> Revision:	 01
> Title:		 Extended Optional Parameters Length for BGP OPEN Message
> Creation_date:	 2009-06-25
> WG ID:		 Independent Submission
> Number_of_pages: 5
>
> Abstract:
> The Optional Parameters in the BGP OPEN message as defined in the
> base BGP specification are limited to 255 octets due to a one-octet
> length field.  BGP Capabilities are carried in this field and may
> foreseeably exceed 255 octets in the future, leading to concern about

Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00

FYI.

--John

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission <at> ietf.org>
> Date: June 25, 2009 2:30:20 PM GMT-04:00
> To: John Scudder <jgs <at> juniper.net>
> Cc: "uttaro <at> att.com" <uttaro <at> att.com>, "pmohapat <at> cisco.com" <pmohapat <at> cisco.com 
> >
> 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

Re: Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00

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,

Re: Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00

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  

Re: Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00

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,

Re: Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00

Robert,

I agree that this is a supportable point:

On Jun 27, 2009, at 4:32 PM, Robert Raszuk wrote:
> WFIW I can easily see the full RFC4684 implementation allowing to drop
> 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:
> 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.

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.

On Jun 27, 2009, at 4:32 PM, Robert Raszuk wrote:
> 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 ?

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

Re: Fwd: New Version Notification for draft-scudder-idr-rt-constrain-lite-00

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.

> On Jun 27, 2009, at 4:32 PM, Robert Raszuk wrote:
>> WFIW I can easily see the full RFC4684 implementation allowing to drop
>> 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:
>> 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."

draft-scholl-idr-advisory

Folks,

Last month, Tom Scholl presented draft-scholl-idr-advisory to NANOG's
general meeting in Philadelphia. The operator community demonstrated
strong support for the draft.

In light of strong operator support, I would like to encourage the WG to
consider adopting this draft as a WG item.

                                    Ron Bonica

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr