Subject: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt

From: [email-masked]
Date: Mon, 07 Jan 2019 07:39:20 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Global Routing Operations WG of the IETF.

        Title           : Well-Known Community Policy Behavior
        Authors         : Jay Borkenhagen
                          Randy Bush
                          Ron Bonica
                          Serpil Bayraktar
	Filename        : draft-ietf-grow-wkc-behavior-01.txt
	Pages           : 6
	Date            : 2019-01-07

Abstract:
   Well-Known BGP Communities are manipulated inconsistently by current
   implementations.  This results in difficulties for operators.
   Network operators are encouraged to deploy consistent community
   handling across their networks, taking the inconsistent behaviors
   from the various bgp implementations they operate into consideration.
   Also, bgp implementors are expected to not create any further
   inconsistencies from this point forward.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-grow-wkc-behavior/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-grow-wkc-behavior-01
https://datatracker.ietf.org/doc/html/draft-ietf-grow-wkc-behavior-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Jay Borkenhagen <[email-masked]>
Date: Mon, 7 Jan 2019 17:56:09 -0500

Hello Grow,

The draft-ietf-grow-wkc-behavior-01.txt posted today makes just a few
small changes w.r.t. -00:

 https://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-01.txt

Specifically:

- the Abstract has been adjusted to indicate more clearly what things
  vendors should do and what things network operators should do.

- some loose wording in the Introduction has been tightened up.

- the Section 6 "Action Items" are clarified similarly to the
  clarifications in the Abstract.  Also, in response to WGLC comments
  from David Farmer, a paragraph was added to urge network operators
  not to depend on any assumed treatment of bgp communities by any
  neighbor networks: for example, do not assume that your transmitted
  NO_EXPORT will be honored, unless the neighbor confirms that it will
  be.

Thank you.

					Jay B.

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

---

From: Job Snijders <[email-masked]>
Date: Mon, 21 Jan 2019 13:51:50 +0100

resending to include working group

On Fri, Jan 18, 2019 at 11:26:58AM +0100, Job Snijders wrote:
> Dear Jay,
> 
> On Tue, Jan 08, 2019 at 07:01:09PM -0500, Jay Borkenhagen wrote:
> > Since Job's message of 10-December extending the WGLC by one week, I
> > have seen only two replies, both on-list, both in support of
> > publication.
> >
> > One respondent (Shunwan) recommended collecting more vendor defaults.
> > I am not opposed to that, but (i) I would expect vendors (or possibly
> > their customers) to volunteer that information, and (ii) I'm not sure
> > the document is actually improved by listing more behaviors -- I think
> > it's good enough to let people know that different behaviors exist,
> > and that vendors are unlikely to change their defaults now, so network
> > operators need to take care in this regard.
> 
> That seems reasonable.
> 
> > David Farmer also responded.  David's point that some operators have
> > been surprised by a neighbor network's handling of NO_EXPORT is valid.
> > I believe that -01 addresses it -- just not in the way that David had
> > suggested.
> > 
> > So, how do you esteemed chairs suggest we proceed now?
> 
> I think the document is mostly ready to proceed down the publication
> pipeline, but speaking as WG participant I'm not entirely sure about a
> normative term in the Action Items section:
> 
>     "Vendors MUST ensure that any well-known communities specified after
>     this document's publication are removed by the "community set"
>     action."
> 
> While I think I understand the intent, but I'm not convinced this is the
> right approach, the implications of the sentence are complex. Since
> there is no formal definition of what "community set" means in all
> contexts, we should treat it as pseudo-code, which means (lacking
> definitions of what it /is/), we shouldn't be specifying what it /is
> not/. What perhaps can be specified is that 'new WKC' should be treated
> the same as the implementation treats regular communities when it comes
> to add or remove actions, to avoid increasing the inconsistency?
> 
> On the other side, the sentence "Vendors SHOULD share the behavior of
> their implementations" perhaps can be made stronger by replacing the
> SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this
> document".
> 
> Another action item could be to suggest that operators should avoid
> using routing policy language constructs that treat some communities
> special, e.g. avoiding the use of 'community set' will result in easier
> to read and more consistent configurations across multiple platforms.
> 
> Kind regards,
> 
> Job

---

From: David Farmer <[email-masked]>
Date: Mon, 21 Jan 2019 07:54:59 -0600

See inline.

>   NO_EXPORT will be honored, unless the neighbor confirms that it will

Your statement effectively changes the three Well-Known Communities defined
in RFC1997 from "MUST NOT" to "SHOULD NOT". Basically, if you can not rely
on those communities not being stripped then "MUST NOT" is way too strong
of a statement. Maybe formally updating RFC1997 and changing the definition
of the three communities to "SHOULD NOT" is an appropriate addition to this
document.  Also, a meta-data link from RFC1997 to this document seems like
a good idea in general and by effect references in IANA Well-Known
Community Registry to this document as well.

Thanks

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: heasley <[email-masked]>
Date: Mon, 21 Jan 2019 17:03:28 +0000

> > SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this

s/share/clearly document/ is perhaps what is meant?

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Tue, 22 Jan 2019 04:28:43 +0000

Could you change "community set" to "set community" in action items please.
"community set" can also refer to a set of communities, the container kind of set.

Regards,
Jakob.