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

[Pierre Francois <[e-mail]>]

Robert,

On 13/11/10 16:56, 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 ?

 From the discussions we had after the 
draft-decraene-idr-rfc4360-clarification-00 talk, I had the feeling 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


That is: You can send non transitive communities out of your AS, and your 
neighbor will accept them. When propagating a path over eBGP, you're not allowed 
to leave a community that was tagged by the neighboring AS which propagated that 
path to you.

This is basically doing on communities what you do on paths tagged with NO_EXPORT.

We were expecting this when we were testing g-shut based on these communities. 
We found 2 implementations which were not.

This was the whole point of the clarification draft. I let it die because I 
thought it was made clear that what we found were bugs. If this is not the case, 
I'm okay to refresh the draft that would lead to an addendum to 4360 or whatever 
the IETF process recommends for such small contributions.

Pierre.


> 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
>>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>