Re: [Idr] draft-decraene-idr-reserved-extended-communities-00

<bruno.decraene@orange-ftgroup.com> Mon, 15 November 2010 09:26 UTC

Return-Path: <bruno.decraene@orange-ftgroup.com>
X-Original-To: idr@core3.amsl.com
Delivered-To: idr@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 651203A6860 for <idr@core3.amsl.com>; Mon, 15 Nov 2010 01:26:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8TKXSg+PX9E for <idr@core3.amsl.com>; Mon, 15 Nov 2010 01:26:23 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 4FFAF3A6C5C for <idr@ietf.org>; Mon, 15 Nov 2010 01:26:19 -0800 (PST)
Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5C3B4FC4004; Mon, 15 Nov 2010 10:26:58 +0100 (CET)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4FECEFC4001; Mon, 15 Nov 2010 10:26:58 +0100 (CET)
Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 15 Nov 2010 10:26:58 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 15 Nov 2010 10:27:01 +0100
Message-ID: <FE8F6A65A433A744964C65B6EDFDC24001A98DCD@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <DA7969C3-2F4D-45BF-B3A2-7450BDD93E63@tony.li>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Idr] draft-decraene-idr-reserved-extended-communities-00
Thread-Index: AcuDjQG13I0XFxWbQR6nRrNLkRKrnABF0pSg
References: <D1EDF6F2-230D-4194-B78F-A5C7F2671ADC@juniper.net> <DA7969C3-2F4D-45BF-B3A2-7450BDD93E63@tony.li>
From: bruno.decraene@orange-ftgroup.com
To: tony.li@tony.li
X-OriginalArrivalTime: 15 Nov 2010 09:26:58.0290 (UTC) FILETIME=[40459D20:01CB84A7]
Cc: idr@ietf.org, draft-decraene-idr-reserved-extended-communities@tools.ietf.org
Subject: Re: [Idr] draft-decraene-idr-reserved-extended-communities-00
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2010 09:26:30 -0000

Tony,

> I have no problem allocating code points and new registries once we
have
> consensus on the draft.

I assume you mean draft-ietf-grow-bgp-gshut-02 (i.e. not
draft-decraene-idr-reserved-extended-communities-00)

> However, I think reversing the process creates a suboptimal situation,
wherein
> we could end up allocating code points and registries for drafts that
we then
> decide to abandon.  This seems like a dangerous precedent.

- Regarding the code point (extended community type), allocating it is
not the issue here. They are FCFS. This point can be removed from the
draft if this is the point you have an issue with.

- Regarding registry, if people can't get a community, they will get a
full type instead. This seems much more suboptimal to me.

- Regarding the draft draft-ietf-grow-bgp-gshut-02 that people could
"decide to abandon":

	- I see a circular reference here:
		- draft-ietf-grow-bgp-gshut cannot progress because it
cannot allocate a non transitive extended community (i.e. waiting for
draft-decraene-idr-reserved-extended-communities)
		- you propose that
draft-decraene-idr-reserved-extended-communities should not progress
while there is no consensus on draft-ietf-grow-bgp-gshut.
	How do you propose that we break that circle? And what do you
mean by "consensus" on draft-ietf-grow-bgp-gshut which is already a WG
doc?

	- even if draft-ietf-grow-bgp-gshut-02 were abandoned, what
exactly would be the issue? Remember that the alternative for
draft-decraene-idr-reserved-extended-communities is that anyone needing
a community will get a full type. (and you won't have the opportunity to
give your opinion on that since its FCFS)


> I would propose that we discuss the draft first.

You're very welcomed to discuss draft-ietf-grow-bgp-gshut-02 in GROW. 

Bruno

> Tony
> 
> 
> On Nov 14, 2010, at 12:36 AM, John Scudder wrote:
> 
> > Folks,
> >
> > There was a certain lack of clarity during the discussion of
draft-decraene-
> idr-reserved-extended-communities-00 at the wg meeting -- we got
sidetracked
> into a tangential discussion of draft-ietf-grow-bgp-gshut-02 instead.
So
> instead of simply asking about wg adoption of the draft, I would like
to
> remind people of the request the draft makes, and then ask.
> >
> > Simply put, the draft asks for the following:
> >
> > - to allocate a code point from the registry "BGP Extended
Communities Type
> - extended, transitive"
> > - to allocate a code point from the registry "BGP Extended
Communities Type
> - extended, non-transitive"
> > - to establish a pair of registries for values to be carried in the
data
> portion of extended communities using respectively, either of those
two code
> points.
> >
> > This seems to Sue and me to be a modest and reasonable request to
the WG.
> The debate in our limited Q&A time revolved around the related gshut
draft.
> Much as with other recent drafts, we think the conversation should be
divided
> into two pieces:
> >
> > - mechanics, in this case extended community allocation and registry
> establishment. That is what the draft and this message relate to.
> > - details of related applications. There seems to be a healthy
conversation
> already taking place related to gshut, within GROW and in hallway
> conversations.
> >
> > The proposal on the table is that the extended community type codes
be
> allocated and the requested registry established. If folks have
objections to
> those specific work items please send them to the list. If adopted,
we're
> basically done by the way -- there is really no further work for the
WG, just
> a little for the chairs.
> >
> > In closing I will point out that although
draft-decraene-idr-reserved-
> extended-communities-00 makes its request from the Standards Action
portion of
> the two registries, it need not -- the authors could have requested an
FCFS
> code point instead in which case this discussion would have been moot.
They
> could still do this.
> >
> > Please send any objections to allocating the type codes and
establishing the
> registry before November 29. If you do object, please provide
justification
> for your position.
> >
> > Thanks,
> >
> > --John and Sue
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr