Re: [Idr] draft-heitz-idr-large-community

[Robert Raszuk <[e-mail]>]

Jakob,

Unless you show me the official IETF rule which says so I will treat it as
your personal opinion.

Meanwhile I will follow advice from chairs and area directors as well
historical facts of other RFCs which progressed via WGLC with optional
parts never implemented.

Ideally I may agree with you ... practically that has never been a
requirement, If it was we would see tons of -bis RFCs adding types one
after another.

Kind regards,
R.

On Thu, Sep 8, 2016 at 9:57 PM, Jakob Heitz (jheitz) <[e-mail]>
wrote:

> You cannot progress a draft to RFC without interoperable implementations
> of ALL of the features in it.
>
> It does not matter that some of the features are optional. Optional just
> means that some implementations may not include it. It does not mean that
> you can sneak a feature in with zero implementations.
>
> Optional means that implementations MUST work and interoperate with AND
> without the optional parts. For that reason, optional is harder than
> mandatory.
>
> Thanks,
> Jakob.
>
>
> On Sep 8, 2016, at 9:27 AM, Robert Raszuk <[e-mail]> wrote:
>
> Gert, All,
>
> The wide-communities draft per IDR recommendation got splitted into
> encoding and registered types quite some time back.
>
> Originally the idea was to list and keep by IANA most operationally needed
> communites as registered yet as mentioned to Jared allowing also local
> communities without having to go via any IETF process.
>
> For quite a long time authors of wide communities were discussing adding
> more flexibility to it including quite involved agebra, but this was
> thought as hard to use so we went back to only propose in type 1 few other
> then integer fields and define those as "atoms".
>
> After discussions during last IETF in Berlin it was obvious that encoding
> of more flexibility of type 1 scares folks even without any build in
> algebra.
>
> Wih that authors of wide community rewrote the document into version -03
> took three specific registered communities and defined it under separate
> types to separate it from need to encode rest of type 1 elements:
>
> Current version is here: https://tools.ietf.org/
> html/draft-ietf-idr-wide-bgp-communities-03
>
> Today it has:
>
> type 1 - original proposal without any algebra
> type 2 - AS:4:4 (exactly the same as large) with the exception of flags in
> the header
> type 3 - Nx4
> type 4 - 16+ Nx4 (as some folks asked to be able to stuff v6 address there
>
> So type 2 is effectively equivalent of large communities, and type 3 and 4
> provide flexible size - no extra policy community containers.
>
> All types are optional by definition.
>
> Some folks expressed the worry that if we implement type 2 the draft will
> not progress.  Authors of large and wide comms discussed this with IDR WG
> chairs and AD and it is in fact a grey area in IETF. Looking at Extended
> Community RFC4360 as example only subset of defined community types ever
> got implemented and the draft moved forward to RFC without any issues.
>
> So now it seems we have in the area of communities number of options on
> the table:
>
> *A* Proceed with each type as separate draft and call for separate BGP
> attribute
>
> *B* Define common single attribute, define common header as separate
> document and then cut all needed types including large into separate drafts.
>
> /* Note option *B* was tried among authors of large and wide communities
> for a month before this adoption request. However Jakob did not agree on
> structure of universal common community header which would be useful to all
> types. The disagreement was mainly about having registered vs local flag as
> well as size of type and flag fields - we were close .... */
>
> *C* Achieve WG consensus that demonstrating implementation of say 2 out of
> current 4 optional types of wide communities is enough to progress the
> single and consistent document.
>
> *D* Merge large with wide types 2, 3, and 4 leaving type 1 as a separate
> document ...
>
> etc ....
>
> For me personally really does not matter which option WG decides to go
> with. Currently it looks like *A*. But what matters is that everyone is
> aware about full story behind this topic.
>
> Many thx,
> Robert.
>
>
> On Thu, Sep 8, 2016 at 2:46 PM, Gert Doering <[e-mail]> wrote:
>
>> Hi,
>>
>> On Thu, Sep 08, 2016 at 02:45:40PM +0200, Robert Raszuk wrote:
>> > That is very true Gert - thx for feedback.
>> >
>> > But how complex is to have a community not fixed 4:4:4, but of flexible
>> > size Nx4 ?
>> >
>> > Is this so hard indeed that implementors can't manage and that operators
>> > can't use ?
>>
>> Dunno.  Why are there two implementations of this, and no implementations
>> of the other draft?
>>
>> Gert Doering
>>         -- NetMaster
>> --
>> have you enabled IPv6 on something today...?
>>
>> SpaceNet AG                        Vorstand: Sebastian v. Bomhard
>> Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
>> Grundner-Culemann
>> D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
>> Tel: [phone]           USt-IdNr.: DE813185279
>>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>