Subject: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

From: Job Snijders <[email-masked]>
Date: Mon, 11 Jun 2018 20:59:39 +0000

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

---

From: Job Snijders <[email-masked]>
Date: Mon, 11 Jun 2018 21:13:15 +0000

Hi all,

> 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

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Jun 2018 16:59:49 -0700

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

---

From: Job Snijders <[email-masked]>
Date: Tue, 12 Jun 2018 00:04:10 +0000

> 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

---

From: Randy Bush <[email-masked]>
Date: Mon, 11 Jun 2018 18:10:39 -0700

> Classic/XE/XR, OpenBGPD, BIRD, Brocade Ironware/SLX-OS and Quagga/frr.

then let's see what others, particularly authors, have to say.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 12 Jun 2018 09:26:51 +0100

> working group know whether you'd like to continue work on this document

yep, sounds good, but what will this do to the vendors' two main 
weapons, fear and surprise?

Nick

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Jun 2018 11:12:58 -0700

>> working group know whether you'd like to continue work on this
>> document as working group or not.

there are sooooo 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

---

From: heasley <[email-masked]>
Date: Tue, 12 Jun 2018 21:19:08 +0000

> working group know whether you'd like to continue work on this document

i support adoption, preferring prescription of the process rather than
platform nuances.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 12 Jun 2018 23:04:40 +0000

I support.

Thanks,
Jakob

-----Original Message-----
From: GROW <[email-masked]> On Behalf Of Job Snijders
Sent: Monday, June 11, 2018 2:00 PM
To: [email-masked]
Subject: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

Dear working group,

Kind regards,

Job

GROW Personnel

_______________________________________________
GROW mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/grow

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Wed, 13 Jun 2018 08:09:53 +0000

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-masked]] On Behalf Of Job Snijders
Sent: Tuesday, June 12, 2018 5:13 AM
To: [email-masked]
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:
> 

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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Jun 2018 12:29:10 +0100

> 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

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Jun 2018 08:18:00 -0700

> 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

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 13 Jun 2018 16:35:17 +0100

>> it strikes me as being a latter day "Go To Statement Considered

just like many of the best things in life.

> implementor thought should be special snowflakes.

We probably ought to document that Remove means Remove rather than 
kinda-remove-bits-here-and-there.

Nick

---

From: brad dreisbach <[email-masked]>
Date: Wed, 13 Jun 2018 11:40:57 -0400

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

---

From: "Serpil Bayraktar (serpil)" <[email-masked]>
Date: Wed, 13 Jun 2018 19:09:34 +0000

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 <[email-masked]> on behalf of Job Snijders <[email-masked]>
Date: Monday, June 11, 2018 at 2:13 PM
To: Grow Mailing List <[email-masked]>
Subject: Re: [GROW] WG Adoption Call: draft-ymbk-grow-wkc-behavior-01 2018.06.11-2018.06.26

Hi all,

Kind regards,

Job

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow