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

Robert,

> Before we start the discussion on this one should we first not
conclude
> what is the WG consensus reg
draft-decraene-idr-rfc4360-clarification-00
> document ?
> 
> Main purpose for draft-decraene-idr-reserved-extended-communities-00
is
> that standard communities where GSHUT is already registered by IANA
> (0xFFFF0000) do not have a way to limit propagation across AS
boundaries.
> 
> Therefor I think to proceed formally further WG should agree or
disagree
> on the former draft defining how implementations should handle AS
> transitiveness of extended communities.

Unless you specifically target
draft-decraene-idr-reserved-extended-communities-00 for an unstated
reason, it's seems to me that what you're asking for is that the WG
should not do any work related to non transitive community until there
is consensus on draft-decraene-idr-rfc4360-clarification-00. If the WG
were to follow your request, there could be other casualties. E.g.
draft-ietf-idr-link-bandwidth-01. And to be fully consistent, that would
mean requesting the IANA to stop allocating any non transitive community
types.

On a side note, Robert, you were at the IDR meeting when
draft-decraene-idr-rfc4360-clarification-00 was discussed. You did not
brought this above point that the draft was so much important. Quite the
contrary in fact. What made you change your mind?

Bruno

> Many thx,
> R.
> 
> 
> > 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