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

[John Scudder <[e-mail]>]

Robert,

Briefly put, I don't think this is necessary.  While RFC 4360 could be Even Clearer regarding the semantics of extended community transitivity, there isn't any fundamental disagreement I'm aware of.  Furthermore, as I indicated in my previous message, we would like to separate questions of mechanics (draft-decraene-idr-reserved-extended-communities-00) from applications (gshut).

Given that transitive/non-transitive registries already exist, there seems to be no difficulty in allocating a code point from each, regardless of the observations made in draft-decraene-idr-rfc4360-clarification-00.  Any clarifications that might be made would indeed apply to such code points, and that's fine.

If you or the authors would like to further pursue draft-decraene-idr-rfc4360-clarification-00 in addition, that is fine.

--John

On Nov 13, 2010, at 7:56 AM, Robert Raszuk wrote:

> Hi John,
> 
> 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.
> 
> 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 [e-mail] https://www.ietf.org/mailman/listinfo/idr
>> 
>