Re: draft-ietf-idr-deprecate-as-sets-00

From the lack of slings and arrows, I'm going to have to assume that this document is just *perfect* and
cannot be improved at all....

Go, prove me wrong (please?)

W

On Nov 19, 2010, at 11:26 AM, Warren Kumari wrote:

> Hi all,
> 
> Now that the submission window has reopened, I have posted draft-ietf-idr-deprecate-as-sets-00 (nee draft-wkumari-deprecate-as_sets).
> 
> This draft already has comment from multiple folk incorporated, but could still do with some work, and
hopefully a bit of strengthening of the language / recommendation.
> 
> Anyway, please take another look (because I'm sure that, having just gotten back from Beijing, reading
yet another draft sounds like a barrel of fun) and send comments, or better yet, text :-p
> 
> W
> 
> 
> ------
> A new version of I-D, draft-ietf-idr-deprecate-as-sets-00.txt has been successfully submitted by
Warren Kumari and posted to the IETF repository.
> 
> Filename:	 draft-ietf-idr-deprecate-as-sets
> Revision:	 00
> Title:		 Deprecation of BGP AS_SET, AS_CONFED_SET.
> Creation_date:	 2010-11-18

Re: "Show of hands" on non transitive extended communities handling

Pierre,

In short I agree with your interpretation.

--John

On Nov 16, 2010, at 5:57 AM, Pierre Francois wrote:

> 
> Hi,
> 
> Could I "see show of hands" on the ML on who does not consider the handling
> of non transitive extended communities described below as the right one ?
> 
> I've been told that there is a third BGP implementation that is not handling 
> them this way, so I'm asking myself whether
> 
> - RFC 4360 is unclear and draft-decraene-idr-rfc4360-clarification should be 
> refreshed.
> 
> or
> 
> - I'm the only one understanding 4360 this way and the behaviors we saw when 
> testing are the compliant ones. (In which case I'm asking myself about the 
> usability of non transitive extended communities in SP networks.)
> 
> I had understood that an implementation of 4360 would have to
> 
> - Accept non transitive communities received over an eBGP session
> - Remove such communities when propagating paths from iBGP to eBGP (of course 

Re: "Show of hands" on non transitive extendedcommunities handling

+1 

>-----Original Message-----
>From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On 
>Behalf Of John Scudder
>Sent: Tuesday, December 07, 2010 1:26 PM
>To: pierre.francois <at> uclouvain.be
>Cc: idr
>Subject: Re: [Idr] "Show of hands" on non transitive 
>extendedcommunities handling
>
>Pierre,
>
>In short I agree with your interpretation.
>
>--John
>
>On Nov 16, 2010, at 5:57 AM, Pierre Francois wrote:
>
>> 
>> Hi,
>> 
>> Could I "see show of hands" on the ML on who does not 
>consider the handling
>> of non transitive extended communities described below as 
>the right one ?
>> 
>> I've been told that there is a third BGP implementation that 
>is not handling 
>> them this way, so I'm asking myself whether

Re: draft-ietf-idr-deprecate-as-sets-00

----- Original Message -----
From: "Warren Kumari" <warren <at> kumari.net>
To: "Warren Kumari" <warren <at> kumari.net>
Cc: <idr <at> ietf.org>
Sent: Tuesday, December 07, 2010 6:10 PM
Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00

> From the lack of slings and arrows, I'm going to have to assume that this
document is just *perfect* and cannot be improved at all....
>
> Go, prove me wrong (please?)

Easy peasy

"The reductions  ...  is outweighed "

"Deprecate:  To mark ...  as obsolete"
**disagree obsolete and deprecate are quite different and I think deprecate
correct here (but see below).

"RPKI"
** not expanded, explained or referenced, nor mentioned in the introduction.
For me, RPKI is the driving force for this I-D - I know of no other reason for
it to exist so more is needed here.

"simplified..  "

Is there an exposure from systems that will refuse to process AS-SET when
receiving one, eg a black hole?  I don't know, but think it needs exploring.

Re: "Show of hands" on non transitive extended communitieshandling

Pierre,
Pls see inline...

thanks--shyam

>-----Original Message-----
>From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of
Pierre Francois
>Sent: Tuesday, November 16, 2010 2:58 AM
>To: idr
>Subject: [Idr] "Show of hands" on non transitive extended
communitieshandling
>
>
>Hi,
>
>Could I "see show of hands" on the ML on who does not consider the
handling
>of non transitive extended communities described below as the right one
?
>
>I've been told that there is a third BGP implementation that is not
handling
>them this way, so I'm asking myself whether
>
>- RFC 4360 is unclear and draft-decraene-idr-rfc4360-clarification
should be
>refreshed.
>
>or

Re: "Show of hands" on non transitive extended communitieshandling

Shyam,

If the behavior of re-attaching that community has been explicitly configured by 
the operator, I don't see a problem w.r.t. RFC 4360.

"draft-decraene-idr-rfc4360-clarification" indeed talks about 
attaching/originating non-transitive communities on the outbound policy.

As the ASBR is supposed to strip off non transitive communities that are not 
locally originated, before propagating over eBGP, doing this at the outbound 
filters ensures that they will actually make it over the session.

Other origination methods are fine if they can provide this same behavior.

Regards,

Pierre.

On 09/12/10 09:34, Shyam Sethuram (shsethur) wrote:
> Pierre,
> Pls see inline...
>
> thanks--shyam
>
>> -----Original Message-----
>> From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On Behalf Of
> Pierre Francois
>> Sent: Tuesday, November 16, 2010 2:58 AM
>> To: idr

I-D Action:draft-ietf-idr-add-paths-guidelines-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Best Practices for Advertisement of Multiple Paths in BGP
	Author(s)       : J. Uttaro, et al.
	Filename        : draft-ietf-idr-add-paths-guidelines-00.txt
	Pages           : 20
	Date            : 2010-11-26

Add-Paths is a BGP enhancement that allows a BGP router to advertise
multiple distinct paths for the same prefix/NLRI. This provides a
number of potential benefits, including reduced routing churn, faster
convergence and better loadsharing.

This document provides recommendations to implementers of Add-Paths
so that network operators have the tools needed to address their
specific applications and to manage the scalability impact of Add-
Paths. A router implementing Add-Paths may learn many paths for a
prefix and must decide which of these to advertise to peers. This
document analyses different algorithms for making this selection and
provides recommendations based on the target application.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-add-paths-guidelines-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the

Re: [GROW] I-D Action:draft-ietf-grow-bmp-05.txt

John at all,

> 	Title           : BGP Monitoring Protocol
> 	Author(s)       : J. Scudder, et al.
> 	Filename        : draft-ietf-grow-bmp-05.txt
> 	Pages           : 16
> 	Date            : 2010-12-15

If I remember correctly the fundamental reason for bmp was to provide a 
very simple mechanism for replaying content of received updates from the 
peers as well as provide some form of signaling reg their state 
transition. That goal was great.

Unfortunately version -01 and above moved away from this and simplified 
the requirement to reply/send content of Adj_RIB_In instead of those 
coming updates from the peers.

So we are effectively loosing the most crucial part of the original 
proposal as we no longer be able to pass to some observatory linux 
station those prefixes which were dropped on inbound or worse any 
potential malformed updates or attributes if they were not stored in the 
RIB_In.

I think it defeats a lot of use cases. Perhaps this subtle difference 
should be discussed more before we proceed any further with this document.

Many thx,
R.
_______________________________________________
Idr mailing list

I-D Action:draft-ietf-idr-deprecate-as-sets-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Deprecation of BGP AS_SET, AS_CONFED_SET.
	Author(s)       : W. Kumari
	Filename        : draft-ietf-idr-deprecate-as-sets-01.txt
	Pages           : 5
	Date            : 2010-12-29

This document deprecates the use of the AS_SET and AS_CONFED_SET
types of the AS_PATH in BGPv4.  This is done to simplify the design
and implementation of the BGP protocol and to make the semantics of
the originator of a route more clear.  This will also simpify the
design, implementation and deployment of onging work in the Secure
Inter-Domain Routing Working Group.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-deprecate-as-sets-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Idr mailing list

Re: draft-ietf-idr-deprecate-as-sets-00

On Dec 8, 2010, at 4:16 AM, t.petch wrote:

> ----- Original Message -----
> From: "Warren Kumari" <warren <at> kumari.net>
> To: "Warren Kumari" <warren <at> kumari.net>
> Cc: <idr <at> ietf.org>
> Sent: Tuesday, December 07, 2010 6:10 PM
> Subject: Re: [Idr] draft-ietf-idr-deprecate-as-sets-00
> 
> 
>> From the lack of slings and arrows, I'm going to have to assume that this
> document is just *perfect* and cannot be improved at all....
>> 
>> Go, prove me wrong (please?)
> 
> Easy peasy

Doh. I said that I'd get to soon, but, well, I didn't.... Sorry.

> 
> "The reductions  ...  is outweighed "

Good catch. Done.

> 
> "Deprecate:  To mark ...  as obsolete"
> **disagree obsolete and deprecate are quite different and I think deprecate
> correct here (but see below).
>