Dear WG, I support adoption.
Besides, I have a little more comment on the vendor specific implementation behaviors. Besides from the WKC, there may be other default configurations that are vendor specific, such as the Next Hop (NH) attribute. For example, when importing an IGP route into BGP and then distributing to an iBGP neighbor, Vendor A router does not change the NH attribute by default, while Vendor B router revises the NH to the iBGP peer address by default (by configuring "peer nexthop-invariable", the NH attribute would not be changed). The lack of such information sharing among vendors in the multi-vendor environment could either cause interoperation issues, or, if accidentally passing the interoperation test, cause routing issues like route flapping or blackhole any time after. Thus, it's beneficial for both network planning and network OAM to have an approach to share such information. BR, Yunan -----Original Message----- From: GROW [mailto:[email protected]] On Behalf Of Job Snijders Sent: Tuesday, June 12, 2018 5:13 AM To: [email protected] Subject: Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26 Hi all, On Mon, Jun 11, 2018 at 08:59:39PM +0000, Job Snijders wrote: > The authors of draft-ymbk-grow-wkc-behavior [1] requested the chairs > to consider issuing a call for working group adoption. Here is the > abstract: > > "Well-Known BGP Communities are manipulated inconsistently by > current implementations. This results in difficulties for > operators. It is recommended that removal policies be applied > consistently to Well-Known Communities." > > [1]: https://tools.ietf.org/html/draft-ymbk-grow-wkc-behavior-01 > > Please take a moment to read and evaluate the document and let the > working group know whether you'd like to continue work on this > document as working group or not. > > We'll close the call on 2018-06-26 Speaking with no hats: I support adoption of this document. Commenting specifically on the draft content, I'd maybe like to see Section 6 "Action items" be along the lines of "Operators are recommened not to use "set community" or "community set" and just explicitly remove/add what needs to be done. Getting the vendors to align may be very challenging, but we can at least inform operators in such a way they are aware of the risks and encouraged to write more portable, readable routing policies. Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
