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

[Huaimo Chen <[e-mail]>]

Hi Job,

    Thank you for your comments.

> 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_

In fact, large parts of the draft are implemented. The container structure
is the big and core part, and is implemented.
* RouterAttr is supported in target TLV.
The others you mentioned above seem small.
*T/C bits are just two bits, No R bits.
*no targets is a corner case, where target TLV does not contain any sub-TLV.
*atoms (both 4.4.1 + 4.4.2). The key parts of these are generalized and
implemented in RouterAttr from functions' point of view.

Best Regards,
Huaimo
________________________________
From: Idr <[e-mail]> on behalf of Job Snijders <job=[e-mail]>
Sent: Monday, February 7, 2022 9:28 AM
To: Keyur Patel <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-wide-bgp-communities-06.txt (2/4/2022 to 2/18/2022)

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-wide-bgp-communities%2F&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C50fb90d944c84707a7ad08d9ea462d54%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637798409450407938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=P4FuUp7LztEycz1Mp57LmHlRj2mLYQN6N21J%2FsKHJ7s%3D&amp;reserved=0.
> The implementation report for the draft can be found at:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fwiki%2Fdraft-ietf-idr-wide-bgp-communities&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C50fb90d944c84707a7ad08d9ea462d54%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637798409450407938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4IbMmOGntVIS%2BKciDnjjSGRBK1io7HivFuWb%2F6%2FXmN0%3D&amp;reserved=0.

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&amp;data=04%7C01%7Chuaimo.chen%40futurewei.com%7C50fb90d944c84707a7ad08d9ea462d54%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637798409450407938%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=GbUJjgACwnki8CUSfbpavFI1mm4HuiF4zjKGqzDGbKA%3D&amp;reserved=0