Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
Dear Working Group, Authors, draft-ymbk-grow-wkc-behavior was accepted as working group document. Please resubmit to the datatracker as draft-ietf-grow-wkc-behavior-00 Kind regards, Job On Mon, Jun 11, 2018 at 08:59:39PM +, Job Snijders wrote: > Dear working group, > > 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 > > Kind regards, > > Job > > GROW Personnel ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
I support adoption (as author) and I like the idea of adding an “Action Items” section perhaps with some of the examples discussed. Serpil From: GROW on behalf of Job Snijders Date: Monday, June 11, 2018 at 2:13 PM To: Grow Mailing List 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 +, 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 GROW@ietf.org<mailto:GROW@ietf.org> https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
On Wed, Jun 13, 2018 at 08:18:00AM -0700, Randy Bush wrote: it strikes me as being a latter day "Go To Statement Considered Harmful" sort of thing. goto is harmful! I don't disagree as a general principal, but also admit to secretly using "set" to remove pre-existing communities from time to time, as we all probably do, even if we don't like to admit it in public. i use 'set' very deliberately, and with no shame. i expect(ed) it to replace any existing communities. it's akin to using = as contrasted with +=. i seemed a perfectly reasonable construct with clear and useful semantics. until we found out its semantics were not so clear to some implementor(s). am i supposed to replace set 666:42 with remove *:* add 666:42 like that's not gonna be error prone. and please do not tell me that the remove *:* leaves a few special well-known communities some implementor thought should be special snowflakes. there is/was an IOS-XR bug related to exactly this scenario. https://bst.cloudapps.cisco.com/bugsearch/bug/CSCve61393 Symptom: Well-known BGP communities are declined using new format, but accepted using name EG: 65535:65283 value is not accepted but the name "local-as" is accepted. randy, under-caffeinated and clearly grumpy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
Randy Bush wrote on 13/06/2018 16:18: it strikes me as being a latter day "Go To Statement Considered Harmful" sort of thing. goto is harmful! just like many of the best things in life. am i supposed to replace set 666:42 with remove *:* add 666:42 like that's not gonna be error prone. and please do not tell me that the remove *:* leaves a few special well-known communities some implementor thought should be special snowflakes. We probably ought to document that Remove means Remove rather than kinda-remove-bits-here-and-there. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
> it strikes me as being a latter day "Go To Statement Considered > Harmful" sort of thing. goto is harmful! > I don't disagree as a general principal, but also admit to secretly > using "set" to remove pre-existing communities from time to time, as > we all probably do, even if we don't like to admit it in public. i use 'set' very deliberately, and with no shame. i expect(ed) it to replace any existing communities. it's akin to using = as contrasted with +=. i seemed a perfectly reasonable construct with clear and useful semantics. until we found out its semantics were not so clear to some implementor(s). am i supposed to replace set 666:42 with remove *:* add 666:42 like that's not gonna be error prone. and please do not tell me that the remove *:* leaves a few special well-known communities some implementor thought should be special snowflakes. randy, under-caffeinated and clearly grumpy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
Randy Bush wrote on 12/06/2018 19:12: job sugggested to add a clause recommending that operators not use 'set' at all to remove communities, but do it explicitly. the authors would appreciate comments on that. it strikes me as being a latter day "Go To Statement Considered Harmful" sort of thing. I don't disagree as a general principal, but also admit to secretly using "set" to remove pre-existing communities from time to time, as we all probably do, even if we don't like to admit it in public. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
I support. Thanks, Jakob -Original Message- From: GROW On Behalf Of Job Snijders Sent: Monday, June 11, 2018 2:00 PM To: grow@ietf.org Subject: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26 Dear working group, 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 Kind regards, Job GROW Personnel ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
Mon, Jun 11, 2018 at 08:59:39PM +, Job Snijders: > Dear working group, > > 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. i support adoption, preferring prescription of the process rather than platform nuances. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
>> 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. > yep, sounds good, but what will this do to the vendors' two main > weapons, fear and surprise? there are so many knobs, that they do not lack targets. job sugggested to add a clause recommending that operators not use 'set' at all to remove communities, but do it explicitly. the authors would appreciate comments on that. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
Job Snijders wrote on 11/06/2018 21:59: 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. yep, sounds good, but what will this do to the vendors' two main weapons, fear and surprise? Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
>>> "Operators are recommened not to use "set community" or "community >>> set" and just explicitly remove/add what needs to be done. >> >> do all vendors support wildcards? > > Yes, I think so. Of the top of my head you can wilcard on Junos, Cisco > Classic/XE/XR, OpenBGPD, BIRD, Brocade Ironware/SLX-OS and Quagga/frr. then let's see what others, particularly authors, have to say. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
On Mon, Jun 11, 2018 at 04:59:49PM -0700, Randy Bush wrote: > > "Operators are recommened not to use "set community" or "community > > set" and just explicitly remove/add what needs to be done. > > do all vendors support wildcards? Yes, I think so. Of the top of my head you can wilcard on Junos, Cisco Classic/XE/XR, OpenBGPD, BIRD, Brocade Ironware/SLX-OS and Quagga/frr. Kind regards, Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
> "Operators are recommened not to use "set community" or "community > set" and just explicitly remove/add what needs to be done. do all vendors support wildcards? randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
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 +, 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 GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26
Dear working group, 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 Kind regards, Job GROW Personnel ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
