Re: [Idr] WG LC on draft-ietf-idr-wide-bgp-communities-06.txt (2/4/2022 to 2/18/2022)

[Robert Raszuk <[e-mail]>]

Hi Job,

>   * support for T/C/R bits (section 3.1)

Where do you see R bit in the latest version as per subject line ?

>       * no targets
>       * atoms (both 4.4.1 + 4.4.2)

Implementations can clarify that,.

>      * RouterAttr_

Can you point to the text ?

- - -

In general I think if we start cutting any spec into N different documents
each progressing only when there are two documented implementations of its
optional parameters or fields it is going to be a huge mess both
implementation wise as well as

What I think matters is if not implementing optional capabilities in any
negative way affects the core purpose of the spec. If yes I agree such
elements should be removed before publication. But if not I see no harm to
leave them in the WG document/RFC.

Thx,
Robert,.


On Mon, Feb 7, 2022 at 3:28 PM Job Snijders <job=[e-mail]>
wrote:

> Dear IDR chairs & working group,
>
> On Fri, Feb 04, 2022 at 04:27:57PM +0000, Keyur Patel wrote:
> > The working group last call has been issued for
> > draft-ietf-idr-wide-bgp-communities-06.txt, “BGP Community Container
> > Attribute”.  Please reply to the list with your comments. This
> > adoption call will conclude on February 18th, 2022.
> >
> > The draft can be found at:
> > https://datatracker.ietf.org/doc/draft-ietf-idr-wide-bgp-communities/.
> > The implementation report for the draft can be found at:
> > https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-wide-bgp-communities.
>
> IDR tradition is to demand multiple interopable implementations exist
> before a document can progress towards the RFC publication status. I
> noticed that large parts of the draft are NOT implemented by either of
> the two implementations; such as:
>
>         * support for T/C/R bits (section 3.1)
>         * no targets
>         * atoms (both 4.4.1 + 4.4.2)
>         * RouterAttr_
>
> While the implementation report available to us indicates that some of
> the features are "optional", this does not relief us from the burden of
> demonstrating that the "optional" feature can actually be implemented in
> an interoperable way. As such, the path forward is either to implement
> the optional features, or to remove the text from the Internet-Draft and
> spin it off into a separate Internet-Draft (which in turn could proceed
> if implementations ever show up).
>
> I strongly believe that IDR, SIDROPS, and other inter-domain working
> groups should not ship any text (as part of large docs) which is not
> directly or indirectly covered in an interopability matrix. E.g. I don't
> see an issue if there are 3 features, and implementation A covers
> features 1+2, B covers 2+3, and C covers 3+1 - in such scenarios the
> full feature set has multiple implementations. Unfortunately this does
> not appear to be the case for the 'wide communities' document.
>
> Many in this working group will probably remember that flexible/wide
> communities were somewhat contentious because of perceived complexity -
> the lack of full coverage in implementation reports, and the presence of
> merely 2 half implementations does not increase confidence that
> publication of this document will benefit operators in the long term.
>
> It is also entirely possible I am misreading the implementation report!
>
> I look forward to hear other people's thoughts on this matter.
>
> Kind regards,
>
> Job
>
> ps. I do not mind the two implementations coming from the same vendor
> house; I trust the two product lines to be sufficiently distinct to
> be viewed as independently developed implementations.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>