Re: [Idr] Adoption call for draft-heitz-idr-wklc-02 (3/9 to 3/23)

[Gyan Mishra <[e-mail]>]

+1

Cheers,

Gyan

On Tue, Mar 23, 2021 at 12:02 PM Robert Raszuk <[e-mail]> wrote:

>
> I must agree with Nick point of view in 100% here.
>
> Indeed when discussions on LC were going on there was strong support from
> operators stating this is what we want and it is good enough. Let's keep it
> simple.
>
> For more advanced including well known actions let's focus on wide
> communities as they have public and private use of communities build in
> from day one.
>
> Many thx,
> R.
>
>
>
>
> On Tue, Mar 23, 2021 at 4:01 PM Nick Hilliard <[e-mail]> wrote:
>
>> Jakob Heitz (jheitz) wrote on 16/03/2021 00:03:
>> > This draft is a proposal to use large communities to make a better
>> > extended community.
>>
>> the original LC RFC specifies a global administrator field.  This draft
>> attempts to retrofit semantics into various bits in that field.  I can
>> see why it's tempting to attempt this, but it introduces a significant
>> degree of interpretation semantics and, more importantly, backwards
>> incompatibility.
>>
>> At the time when we were still discussing
>> draft-heitz-idr-large-community, the issue of future flexibility and
>> semantic interpretation was extensively discussed, and the consensus of
>> the authors + working group was that it was more important to get a
>> draft out there which implemented "deployed + simple" rather than going
>> for a slightly more complex design which would have allowed future
>> extensibility.
>>
>> The opportunity to use a more flexible structure was not taken at the
>> time, for good reasons, and we knew at the time what those long term
>> consequences of those decisions would be.
>>
>> Retrofitting this complexity into rfc8092 reopens these arguments, but
>> from the point of view of watching the ship after it's sailing past the
>> horizon.
>>
>> If we need a better asn32-compatible extended community, then we should
>> define a better, asn32-compatible extended community and do the job
>> properly.  We should not try to claim that rfc8092 provides an
>> appropriate framework for this, because it doesn't and because if we try
>> to bend LCs in this way, it will leave us with a legacy of perpetual
>> dysfunction.
>>
>> Nick
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*