Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

From: "Susan Hares" <[email-masked]>
Date: Mon, 17 Oct 2016 16:27:31 -0400

This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt.  (10/17
to 10/31).   Please comment if draft-ietf-idr-large-community-03.txt  is
ready for publication.   

If you have concerns with the text,  please be very specific about what is
wrong and what needs to change.  If you have concerns about operational
aspects, please give a complete description of the problem and why this
draft does not solve it. 

This WG LC is not a place to debate whether we should have adopted this
technology.  

The focus of WG LC is whether this technology has implementations (see IDR
wiki for examples),  and whether these implementation inter-operate.  It is
also important to consider deployment issue or problems on currently.  

Sue Hares and John Scudder

---

From: Peter Hessler <[email-masked]>
Date: Mon, 17 Oct 2016 22:59:52 +0200

On 2016 Oct 17 (Mon) at 16:27:31 -0400 (-0400), Susan Hares wrote:
:This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt.  (10/17
:to 10/31).   Please comment if draft-ietf-idr-large-community-03.txt  is
:ready for publication.   
:
: 
:
:If you have concerns with the text,  please be very specific about what is
:wrong and what needs to change.  If you have concerns about operational
:aspects, please give a complete description of the problem and why this
:draft does not solve it. 
:
: 
:
:This WG LC is not a place to debate whether we should have adopted this
:technology.  
:
: 
:
:The focus of WG LC is whether this technology has implementations (see IDR
:wiki for examples),  and whether these implementation inter-operate.  It is
:also important to consider deployment issue or problems on currently.  
:
: 
:
:Sue Hares and John Scudder 
:

In my opinion, draft-ietf-idr-large-community-03 is ready for publication.

Additionally, I have tested inter-operation of OpenBGPD with exabgp and
bird.  I am also advertising a prefix with large-communities attached to
it on the DFZ, 2a02:1698:179::/48.

(Disclosure: I wrote the wire-protocol part of the OpenBGPD
implementation, and committed it to the OpenBSD tree)

-- 
All I ask is a chance to prove that money can't make me happy.

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 17 Oct 2016 17:38:42 -0400

This draft looks good to me. please publish.

On Mon, Oct 17, 2016 at 4:27 PM, Susan Hares <[email-masked]> wrote:

> This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt.
> (10/17 to 10/31).   Please comment if draft-ietf-idr-large-community-03.txt
> is ready for publication.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>
>

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 17 Oct 2016 17:51:34 -0400

> to 10/31).   Please comment if draft-ietf-idr-large-community-03.txt  is

As of version -03, I think the document is clear and largely ready to ship.

My one remaining concern is the reserved communities in section 5.  Given
the remaining text in the document saying "you MUST let people put whatever
they want in here", the reservation seems superfluous.

I'd suggest outright removing the reservations.  Failing that, they need to
be better justified.

-- Jeff

---

From: "Dickinson, Ian" <[email-masked]>
Date: Tue, 18 Oct 2016 11:01:22 +0000

I support publication of this draft.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: 17 October 2016 21:28
To: 'IETF IDR WG' <[email-masked]>
Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

This begins a 2 week WG LC on draft-ietf-idr-large-community-03.txt.  (10/17 to 10/31).   Please comment if draft-ietf-idr-large-community-03.txt  is ready for publication.

If you have concerns with the text,  please be very specific about what is wrong and what needs to change.  If you have concerns about operational aspects, please give a complete description of the problem and why this draft does not solve it.

This WG LC is not a place to debate whether we should have adopted this technology.

The focus of WG LC is whether this technology has implementations (see IDR wiki for examples),  and whether these implementation inter-operate.  It is also important to consider deployment issue or problems on currently.

Sue Hares and John Scudder
Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD.

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 Oct 2016 04:27:32 -0700

Hi Sue,

03 is ready for publication.

Thanks!

Cheers,

Jeff

From: Idr <[email-masked]> on behalf of Susan Hares <[email-masked]>
Date: Monday, October 17, 2016 at 13:27
To: 'IETF IDR WG' <[email-masked]>
Subject: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

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

---

From: heasley <[email-masked]>
Date: Tue, 18 Oct 2016 19:08:51 +0000

> I'd suggest outright removing the reservations.  Failing that, they need to

Part of the idea behind reserving 65535:*:* was to reserve a space that
could later be used for well-knowns, if that was desired - but to not
spend time now arguing about details of what well-knowns are necessary.

0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.

---

From: Job Snijders <[email-masked]>
Date: Tue, 18 Oct 2016 14:15:21 -0500

> 0:*:* and 4294967295:*:* mimics rfc1997 and the reserved ASNs.

Jeff argues that a justification should be added. Maybe someone can
pitch in one or two sentences that explain why these are reserved?

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Oct 2016 16:38:00 -0400

> On Oct 18, 2016, at 3:15 PM, Job Snijders <[email-masked]> wrote:
> 
>> 

That's certainly part of it.  While I think many people can see the reason why you might want to do such a reservation, to do so you should have a practical reason in the document.

For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want to note that if it's used for that symmetry that either the existing well known community registry is used at IANA or that a new one would need to be created.  Alternatively, you just say the work is expected and defer to a future document.

Note by doing this, you're setting up some expectations about translation of communities from one space to another.  FWIW, I don't recommend this and simply suggest that you recommend *not* using these for common use in case someone decides that they want to do so.  I know your organization and others such as Deutsche Telecom have some thoughts about what translation infrastructure might look like, and such mechanisms would have impact.

With regard to the 0: and max-uint32: cases, after dealing with the headaches associated with helping with documents such as the as0 and RFC 7300 and putting in some restrictions in the configuration... followed by having to take them away, I'm very reluctant to put in anything beyond "we think it's a bad idea to use these, so pretty please don't"

-- Jeff (ask me about my RFC 7300 hate mail over beer...)

---

From: t.petch <[email-masked]>
Date: Wed, 19 Oct 2016 11:47:05 +0100

I remain unhappy with this I-D.

I find it ironic that the messages for this Last Call should be
interspersed with those relating to what goes wrong when someone
somewhere else in the world uses a field in an unexpected way.  This
reinforces my belief that this I-D should be more forceful in calling
out the dangers (eg MUST instead of SHOULD).

I think that this I-D is factually incorrect, or at least open to
misinterpretation,  when it says
'[RFC1997] BGP Communities attributes are four-octet values split into
   two two-octet words.  The most significant word is usually
   interpreted as an Autonomous System Number (ASN) '

RFC1997 says
'The community attribute values ranging from 0x0000000 through
   0x0000FFFF and 0xFFFF0000 through 0xFFFFFFFF are hereby reserved.

   The rest of the community attribute values shall be encoded using an
   autonomous system number in the first two octets.  '

Note the use of 'shall'.  Had that been written after RFC2119 then it
would have been IMO 'MUST' or 'SHALL' not the weasily 'SHOULD' so this
I-D is weakening the meaning compared to RFC1997.

If this I-D were to say that RFC1997 specified a 'MUST' (in effect) but
that 20 years of experience showed that it need not be that strong, that
ambiguities of interpretation have never been a problem for routing,
pehaps by adding a note in the Security Considerations, then I would
accept that.  As it stands, I think that this I-D is risky (and would be
even if everyone who reads it knows what the IETF means by 'SHOULD' - I
think that this is not the case and that those outside the IETF will
read 'SHOULD' as a stronger enforcement than it is).

So, interspersed with those e-mails about other fields that have
unexpected values, I oppose this going forward just yet.

The question of reserved values is another can of worms.  If they are
not reserved, then clearly they are an example of 'SHOULD' not meaning
'MUST' so they need reserving, but then, as Jeff is pointing out, you
open up the question of translation (something I flagged earlier as an
open issue).

Tom Petch

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
Sent: Tuesday, October 18, 2016 9:38 PM

> pitch in one or two sentences that explain why these are reserved?

That's certainly part of it.  While I think many people can see the
reason why you might want to do such a reservation, to do so you should
have a practical reason in the document.

For the 65535:*:* case, for symmetry with RFC 1997, you'd probably want
to note that if it's used for that symmetry that either the existing
well known community registry is used at IANA or that a new one would
need to be created.  Alternatively, you just say the work is expected
and defer to a future document.

Note by doing this, you're setting up some expectations about
translation of communities from one space to another.  FWIW, I don't
recommend this and simply suggest that you recommend *not* using these
for common use in case someone decides that they want to do so.  I know
your organization and others such as Deutsche Telecom have some thoughts
about what translation infrastructure might look like, and such
mechanisms would have impact.

With regard to the 0: and max-uint32: cases, after dealing with the
headaches associated with helping with documents such as the as0 and RFC
7300 and putting in some restrictions in the configuration... followed
by having to take them away, I'm very reluctant to put in anything
beyond "we think it's a bad idea to use these, so pretty please don't"

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Oct 2016 11:02:27 -0400

Tom,

> I-D is weakening the meaning compared to RFC1997.

It's also worth recognizing, good or not (there's definitely room for value
judgment in here), that practice has evolved.

As part of working through RFCs to basically say "don't use AS 0" and "don't
use AS 65535", the general consensus here and in grow was "yeah, that seems
like a good idea".  It probably still is.

But when code started going into place to enforce that (cli restrictions),
the weird edge cases started coming out.  People using AS 0 as a "wildcard"
in their community policy.  People using AS 65535 for BGP peering, etc.

Is it a bad idea?  Probably.  Historically AS 0 type things triggered all
sorts of entertaining buggy issues for reasons I've previously written
about.  AS 65535 is ugly simply because it clutters semantic space for
things like the well known communities.  And thankfully the issues
surrounding 0 as uninitialized variable and UINT16_MAX as being common
issues in BGP bugs seem to largely be behind us.

> read 'SHOULD' as a stronger enforcement than it is).

And yet, I think this is a case where the SHOULDs get enough "yeah, but..."
exceptions that it weakens even the arguments for that.

The one case I still find somewhat compelling deals with the strong
likelihood that some providers will port their RFC 1997 features into large
format via either script or implementation feature.  In such cases, porting
the well known communities into and out of large format present potential
issues.

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 19 Oct 2016 17:37:37 +0000

1. Router software cannot check whether a number is an ASN.

2. Any numbers should be allowed between consenting adults. That is within an AS or between adjacent ASes.

3. "Reserved" means reserved for use. So router software cannot disallow these either.

I can see how the existing text is a little terse:
   The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.

The best we can do is explain the situation:

A Large Community that
is intended to be sent to multiple ASes SHOULD contain an ASN
in the Global Administrator field. The ASN SHOULD be one that
is assigned to the entity
that defines the meaning of the rest of the Large Community.
This allows a route to carry multiple Large Communities, the meaning
of each being defined by different independent entities.

Tom, will this text satisfy you?

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Wednesday, October 19, 2016 3:47 AM
> To: Jeffrey Haas <[email-masked]>
> Cc: IETF IDR WG <[email-masked]>; Sue Hares <[email-masked]>
> Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
>

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Oct 2016 13:12:18 -0500

I believe this is ready to go and support it's publication as-is.  However,
I believe it would be improved with the addition of something like the
following paragraph;

   While from a BGP protocol perspective it is necessary for large
communities to be
   transitive, as there are many plausible situation where large
communities need to
   be used to signal beyond a singles or even directly adjacent Autonomous
Systems.
   On other other hand, large communities are not necessarily intended to
be passed
   unimpeded across the entirety of the Internet either. Therefore,
implementations
   SHOULD provide a rich set of policy capabilities to allow operators to
decide which
   large communities are received from or propagated to peers.

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: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Oct 2016 14:20:52 -0400

> On Oct 19, 2016, at 2:12 PM, David Farmer <[email-masked]> wrote:
> 
> I believe this is ready to go and support it's publication as-is.  However, I believe it would be improved with the addition of something like the following paragraph;
> 
>    While from a BGP protocol perspective it is necessary for large communities to be 
>    transitive, as there are many plausible situation where large communities need to 
>    be used to signal beyond a singles or even directly adjacent Autonomous Systems.  
>    On other other hand, large communities are not necessarily intended to be passed 
>    unimpeded across the entirety of the Internet either. Therefore, implementations 
>    SHOULD provide a rich set of policy capabilities to allow operators to decide which 

FWIW, I'd rather see such a thing as part of a grow document for good community practices.

I had thought that a BCOP document on communities was out there for BGP communities in general, but "community" clutters the search engines quite a bit and I'm not finding such a thing.

-- Jeff

---

From: Jared Mauch <[email-masked]>
Date: Wed, 19 Oct 2016 14:54:05 -0400

>    interpreted as an Autonomous System Number (ASN) '

	rfc1998: section 4 gives you the slice + dice bits:

-- snip -- rfc 1998 -- 
   To make use of the BGP community attribute, several community values
   (MCI's AS number: 3561 = 0x0DE9) have been defined that can be used
   by customers to tag routes so that the appropriate "LOCAL_PREF"
   values are configured. Table 2 lists the appropriate community
   attribute values (and the mappings of community to LOCAL_PREF):
-- snip -- rfc 1998 --

	This is the segmenting, and most customers have
"ip bgp community new-format" configured.

	If your issue is about printf %ull vs %d:%d:%d we operators
can solve this by ensuring our vendors do the right thing, which
we have already done 20 years ago via rfc1998.

	This nit is imo not worth picking.

	- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Oct 2016 12:46:27 -0700

>         This nit is imo not worth picking.
I think Tom was concerned about the usage of "usually", not the 16:16
format. I agree, and I am also concerned.

Per Susan Hare's WGLC instructions, here are my specific concerns, and
suggested text for correcting those concerns:

Concern #1:

>From my reading of RFC1997, and from a couple of decades of operational
experience,
I believe the wording in Section 1 should be as follows:

"The most significant word is always an ASN. Private ASN values MAY be used
when agreed upon by adjacent BGP peers."
(Insert reference to IANA private 32-bit ASN table.)

Rationale:

The second sentence was not explicitly part of RFC1997, but definitely has
been operational practice, and is implied by the meaning of ASN, and tables
of 16-bit ASN values (reserved, private, and available/assigned.)

Concern #2:

And, IMNSHO, the request/demand for parity with RFC1997, calls for similar
language when describing the 32-bit first field's interpretation:

In Section 2:

"Global Administrator:  A four-octet namespace identifier.  This MUST be an
Autonomous System Number. Private ASN values MAY be used when agreed upon
by adjacent BGP peers. Private ASN values SHOULD NOT be advertised to peers
where their use has not been agreed upon."

Rationale:

Trying to separate out the "best practice" into a separate,
non-Standards-Track document, significantly weakens the practical ability
BY OPERATORS to enforce the requirement of exclusive control of the
meanings assigned by them, of the number space within communities (regular
and wide).

The draft, as currently worded, gives third parties "wiggle room" to use
non-ASN values as the first 32-bit field. Their argument will be that this
document does not say "MUST", and for whatever choice of argument they
pick, they are justified in squatting on someone's ASN as the first 32-bit
value.

Since Section 1 of this document give exclusive semantic control of that
portion of the Large Community space -- " a four-octet ASN and two
four-octet operator-defined values, each of which can be used to denote
properties or actions significant to that ASN." -- squatting needs to be
explicitly prohibited via use of "MUST" instead of "SHOULD" in specifying
Global Administrator as meaning, exclusively, ASN.

Concern #3:

In addition, to address concerns the co-authors have expressed, the
non-intent of "MUST", to implementers, should be explicitly called out. The
proposed wording would be:
"The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.
   Implementations MUST allow the operator to specify any value for the
   Global Administrator field. Implementors MUST NOT restrict permitted
values
   of ASN, including non-reserved 16-bit ASN values and non-reserved 32-bit
ASN
   values, which includes all Private Use ASN ranges. Use of third-party
ASN values
   is an explicitly permitted use of Large Communities."

Rationale: Avoid any ambiguity for implementation of Large Communities.
Interoperation demands compatible interpretation of values of ASN permitted
by implementors.

Of course, if the above changes are adopted, I approve publication,
whole-heartedly.

Brian Dickson

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Oct 2016 15:05:34 -0500

My intent for this was to motivate why it's necessary for implementations
to include filtering policies in order to be complete, which I think is in
scope for this document. It's not intended to supplant a BCOP document,
which would talk about how to use the policies and need way more details
and examples.

On Wed, Oct 19, 2016 at 1:20 PM, Jeffrey Haas <[email-masked]> wrote:

> I believe this is ready to go and support it's publication as-is.
> However, I believe it would be improved with the addition of something like
> the following paragraph;
>
> I had thought that a BCOP document on communities was out there for BGP
> communities in general, but "community" clutters the search engines quite a
> bit and I'm not finding such a thing.
>
> -- Jeff
>
>

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Oct 2016 23:01:20 +0100

Jeffrey Haas wrote:
> communities in general, but "community" clutters the search engines
> quite a bit and I'm not finding such a thing.

are you thinking of rfc7454?

Dave's suggestion is definitely an operational- rather than a
protocol-level issue.  draft-ietf-idr-large-community is a protocol
definition, so it would be better to see this in a GROW document.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Oct 2016 18:25:15 -0400

> On Oct 19, 2016, at 6:01 PM, Nick Hilliard <[email-masked]> wrote:
> 
> Jeffrey Haas wrote:

Something more complete than that.  An old NANOG output, if I recall correctly.

> definition, so it would be better to see this in a GROW document.

That's the point I was trying to make.  Although a "operational considerations" section is considered reasonable for IETF RFCs these days. (https://tools.ietf.org/html/rfc5706 <https://tools.ietf.org/html/rfc5706>)

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 19 Oct 2016 23:29:03 +0100

Brian Dickson wrote:
> "Global Administrator:  A four-octet namespace identifier.  This MUST be
> an Autonomous System Number.
[...]
>    Global Administrator field. Implementors MUST NOT restrict permitted values
>    of ASN

so summarising:

- operators: you MUST use an ASN
- implementers: you MUST allow any value

I'm really not convinced that it's good protocol definition practice to
state one set of rules for implementers and another for operators, where
the two sets of rules are not actually compatible with each other.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 19 Oct 2016 18:31:33 -0400

> On Oct 19, 2016, at 6:29 PM, Nick Hilliard <[email-masked]> wrote:
> 
> Brian Dickson wrote:

I think this is nicely stated.

As recently noted, the operator proscription is an operational consideration.  In that context, it's fine.  And simply moving it to an operational considerations section may close this discussion.

-- Jeff

---

From: David Farmer <[email-masked]>
Date: Wed, 19 Oct 2016 17:34:37 -0500

> definition, so it would be better to see this in a GROW document.

So it's slightly more than just the wire-protocol issues, it defines a
Canonical Representation.  I think that's important, but I think it's
equally important that to interoperability that implementations include
policy tools.  I included some motivation for why the tools need to be
included, but if you'd prefer to strip that out, I'd be fine with that. So
that leaves something like this;

   Implementations SHOULD provide a rich set of policy capabilities to
allow operators
   to decide which large communities are received from or propagated to
peers.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 20 Oct 2016 00:36:59 +0200

> - implementers: you MUST allow any value

​IMHO this is too coarse simplification.

For operators if we are getting into this here vs in companion GROW doc
draft/rfc must define what sending vs receiving operator is expected to do.

​For implementation allowing any value unless policy is in place. And as
such policy must be able to validate against BGP Origin Validation database
if present and enabled on the router.

Again .. I assume we are all talking about first 4 octets only right ? Or
also second 4 octets too ?

Best,
R.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Oct 2016 16:21:35 -0700

> if present and enabled on the router.

You've lost me here. If I am sending prefix X, and I am ASN A, and the
community is B:C:V, the BGP OV will show A is allowed to originate X. There
are no other restrictions applicable from OV.
Also, the meaning of B:C:V is exclusively defined by ASN B, who may or may
not be a directly connected peer.

Nobody except B is expected to "do" anything.
What B does, is a combination of:
- What B tells the world
- What B tells some subset of the world (e.g. via a customer portal which
has restricted access)
- What B uses to decide for whom each set of actions is permitted
- Any internal policies and procedures known only to B

E.g. B may allow B:C:V from customers of B (including customers of
customers, etc.)
E.g. B may allow B:D:V from anyone for some set of values V and some
specific values of "D"
E.g. B may allow arbitrary automated functionality associated with
B:*:{V1,V2,V3,... VN}, where the second parameter is a BGP peer of B, and
VN is a trigger for some particular behavior (filter, prepend, change MED)

Every ASN "B" can choose whatever it wants as the methods, mechanisms,
values, etc., and those do not need to have any bearing on any other ASN's
choices.

Some ASNs will choose not to use their own ASN:X:Y, but rather use
PRIVATE_ASN:X:Y and only do those on a per-peer basis (with distinct
choices of PRIVATE_ASN, X, and Y, which can literally vary by peer, with no
global meaning.)

So, I think the "unless policy is in place" is a red herring; whether
policy is there or not, and regardless of what policy there is, it is
ALWAYS "allow any value".

> also second 4 octets too ?
First 4 octets only.

Brian

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 20 Oct 2016 01:28:10 +0200

Brian,

Regarding BGP OV I meant to use it as a database of valid ASNs - where it
is present.. Nothing to do with actual prefixes in MP_REACH here.

> So, I think the "unless policy is in place" is a red herring; whether
policy is there or not,
> and regardless of what policy there is, it is ALWAYS "allow any value".

Well if my policy says drop junk it can not ALWAYS act as "allow any
value".

Thx,
R.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Oct 2016 16:56:54 -0700

> Well if my policy says drop junk it can not ALWAYS act as "allow any

Yes, the implementation should still "allow any value".

Given that BGP OV is not guaranteed to be the complete universe of ASNs,
and certainly excludes private use ASNs, then NO, use of such a database is
an unwise idea.

Even using a bogon list or other source of "up to date" ASNs, is not a good
idea, at least for on-router enforcement. The timeliness aspect of updates
to those has been shown to be a problem.
One need only look at any number of mailing lists, where "Please update
your bogon filter" messages are common.

The real problem is asymmetry. The entity that ends up on the bogon list is
harmed, while the action needed to remedy that harm is vast and
decentralized (operators), with no guaranteed, reliable speed of resolution
of problems.

It would be fine to have a configuration management system do mild
enforcement or alerting, to limit operator error; but there should always
be the ability to over-ride or ignore those protections.

Something similar to "re-type your email address" should be about the level
of enforcement of ASN values, to avoid fat-fingering things, IMHO.

At some point in the future, presuming some kind of better managed peering
DB and routing policy language, including publication of "locally well
known wide communities", protection mechanisms related to communities would
make sense.
But not until the preconditions are there (the bits after "presuming").

Brian

>> Also, the meaning of B:C:V is exclusively defined by ASN B, who may or
>> may not be a directly connected peer.
>>
>>> Again .. I assume we are all talking about first 4 octets only right ?
>>> Or also second 4 octets too ?
>>>
>>>
>> First 4 octets only.
>>
>> Brian
>>
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Oct 2016 08:03:25 +0200 (CEST)

> Yes, the implementation should still "allow any value".

When I have created BGP route policies, I've several times asked myself 
the question "what will the vendor implementation do itself, and what do I 
need to do in my policy".

So for instance, do I need to implement the well-knowns myself, or is that 
something that I need to do in my policy? If I for operational reasons 
want the router to not do something (for instance I do want NO-EXPORT to 
traverse AS boundary), how do I do that?

I think here in the IETF we should always consider to have separate 
documents for what goes on the wire (compatibility reasons), and what the 
implementation should do with this information by default in case the user 
also can set policy.

The contents of the -large- fields and whether the implementation should 
check if this is true is a typical thing that the "wire" document should 
not over-specify. That should instead be an operational document, and that 
should involve GROW as well.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: t.petch <[email-masked]>
Date: Thu, 20 Oct 2016 09:37:59 +0100

Jared

As Brian has pointed out, it was the use of 'usually' that I was
concerned with, as watering down the recommended use of an ASN by
RFC1997.  Excise 'usually' and that part of my concern goes away.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Thu, 20 Oct 2016 09:55:27 +0100

----- Original Message -----
From: "Jakob Heitz (jheitz)" <[email-masked]>
Sent: Wednesday, October 19, 2016 6:37 PM

2. Any numbers should be allowed between consenting adults. That is
within an AS or between adjacent ASes.

3. "Reserved" means reserved for use. So router software cannot disallow
these either.

A Large Community that

<tp>

Jakob

I struggle to find any form of words that will satisfy me that includes
the word 'SHOULD'.  Ironically, if the sentence were to use 'MAY', then
that would probably be ok, since it accurately conveys the meaning that
you may find anything here so you cannot know what it means and so must
have other means of authenticating the community before use.

Or change it to 'MUST' which I think gives a clear sense of what to
expect.  That this cannot be enforced I find a red herring - lack of
enforcement is a fact of life in BGP as currently defined (as the recent
squat on an attribute number shows).  'MUST' would tell any misusers
that they are in the wrong so giving peer pressure a better chance of
getting things fixed.

Also, I had forgotten RFC7454 (until Nick mentioned it) and that
prescribes the stripping of communities, which intersects with this
issue.  RFC7454 addresses some of the security holes in BGP and expects
the high order bits of a community to be an ASN so that is another can
of worms that needs addresssing in this I-D.

Tom Petch

Thanks,
Jakob.

---

From: t.petch <[email-masked]>
Date: Thu, 20 Oct 2016 10:08:17 +0100

----- Original Message -----
From: "Mikael Abrahamsson" <[email-masked]>
Sent: Thursday, October 20, 2016 7:03 AM

> should involve GROW as well.

Mikael

In theory, I agree with you but in practice, I expect it will be at
least a year or two before GROW produces such a document.  In the
meantime, I would go with Jeff's suggestion to include an 'Operational
Considerations' section in this I-D (and that then could refer to
RFC7454 and clarify the meaning of 'high order bits').

But I think that we have yet to agree what such a section would say.

Tom Petch

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 20 Oct 2016 12:13:48 +0200 (CEST)

> But I think that we have yet to agree what such a section would say.

Exactly. So do you still want to delay the progress of this document until 
we (perhaps never) reach consensus on what the fields should be?

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 11:59:26 +0000

May be one suggestion, trying to address Tom's comment, and inspired by RFC 4360:
https://tools.ietf.org/html/rfc4360#section-3.1

OLD:
   Local Data Part 1:  A four-octet operator-defined value.
   Local Data Part 2:  A four-octet operator-defined value

NEW:
   Local Data Part 1:  A four-octet value. The format and meaning is defined by the Autonomous System set in the Global Administrator field.
   Local Data Part 2:  A four-octet value. The format and meaning is defined by the Autonomous System set in the Global Administrator field.

Or some other wording, but I think the point is that "operator-defined" means the operator of the AS set in the Global Administrator field.

--Bruno

 > Sent: Thursday, October 20, 2016 10:38 AM
 > To: Jared Mauch
 > Cc: IETF IDR WG; Sue Hares

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 08:13:49 -0500

Hi Bruno,

Do you feel it is not already clear enough from the introduction?

"""
   To address these shortcomings, this document defines a Large BGP
   Communities attribute encoded as one or more twelve-octet values,
   each consisting of a four-octet ASN and two four-octet operator-
   defined values, each of which can be used to denote properties or
   actions significant to that ASN.
                          ^^^^^^^^
"""

Kind regards,

Job

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 13:34:41 +0000

Hi Job,

> From: Job Snijders [mailto:[email-masked]]  > Sent: Thursday, October 20, 2016 3:14 PM
> 
 > Hi Bruno,
 > 

I'm personally fine with the text, but I think that the concern expressed is about having his community space squatted by somebody else. i.e. making it clear in the document that the community space starting with NNNN: "belongs" or is "assigned" by AS NNNN.
Looking at the definition of "significant" I don't feel that this fully address the point. e.g. a well-known community may be significant to AS NNNN, yet this space is not assigned by AS NNNN.

King regards,
-- Bruno

 > >    Local Data Part 1:  A four-octet value. The format and meaning is defined by the
 > Autonomous System set in the Global Administrator field.
 > >    Local Data Part 2:  A four-octet value. The format and meaning is defined by the
 > Autonomous System set in the Global Administrator field.
 > >
 > > Or some other wording, but I think the point is that "operator-defined" means the
 > operator of the AS set in the Global Administrator field.
 > >
 > > --Bruno
 > >
 > _________________________________________________________________________
 > ________________________________________________
 > >

---

From: <[email-masked]>
Date: Thu, 20 Oct 2016 13:38:45 +0000

Correction (sorry for the spam)

> making it clear in the document that
 > the community space starting with NNNN: "belongs" or is "assigned" by AS NNNN.

that AS NNNN, owns/control the assignment of the community space starting with NNNN:

(Such correction is expected to handle cases where NNNN is not an assigned AS number. e.g. 0000. )

--Bruno

 > From: Idr [mailto:[email-masked]] On Behalf Of [email-masked]
 > Sent: Thursday, October 20, 2016 3:35 PM
 > To: Job Snijders
 > I'm personally fine with the text, but I think that the concern expressed is about having his
 > community space squatted by somebody else. i.e. making it clear in the document that
 > the community space starting with NNNN: "belongs" or is "assigned" by AS NNNN.
 > Looking at the definition of "significant" I don't feel that this fully address the point. e.g. a
 > well-known community may be significant to AS NNNN, yet this space is not assigned by
 > AS NNNN.
 > 
 > King regards,
 > -- Bruno
 > 
 >  > Kind regards,
 >  >
 >  > Job
 >  >

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 08:38:57 -0500

On Thu, Oct 20, 2016 at 01:34:41PM +0000, [email-masked]
wrote:
>  > """ To address these shortcomings, this document defines a Large
>  > BGP Communities attribute encoded as one or more twelve-octet
>  > values, each consisting of a four-octet ASN and two four-octet
>  > operator- defined values, each of which can be used to denote
>  > properties or actions significant to that ASN.  ^^^^^^^^ """
> 
> I'm personally fine with the text, but I think that the concern
> expressed is about having his community space squatted by somebody
> else. i.e. making it clear in the document that the community space
> starting with NNNN: "belongs" or is "assigned" by AS NNNN.
> Looking at the definition of "significant" I don't feel that this
> fully address the point. e.g. a well-known community may be
> significant to AS NNNN, yet this space is not assigned by AS NNNN.

That is easy to solve: there are no well-known large communities.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 20 Oct 2016 10:04:52 -0400

> On Oct 20, 2016, at 9:38 AM, [email-masked] wrote:
> 

For some very light definition of "own".  

For example, if I really like Job's 2914 community road-show, and just copied and pasted his community configs directly, 2914:* would work fine for me.  But I certainly shouldn't expect that the communities would survive getting to me through 2914.

The above comments aren't intended to recommend any specific change of text, but merely to point out that getting too hung up on RFC 2119 semantics is probably counter productive.

-- Jeff

---

From: t.petch <[email-masked]>
Date: Thu, 20 Oct 2016 15:53:36 +0100

----- Original Message -----
From: "Mikael Abrahamsson" <[email-masked]>
Sent: Thursday, October 20, 2016 11:13 AM

> we (perhaps never) reach consensus on what the fields should be?

It comes back to the same point.  If we have no consensus on what the
fields should be (and it is the first field that is an ASN which allows
the others to be interpreted which is the field that concerns me) and
the fields are part of a transitive attribute that goes who knows where
in the Internet, then how can they be safely used to influence routing?
Specify that and the problem is solved.

MUST be an ASN works for me, or, paradoxically, MAY be an ASN (since
then it should be obvious the fields cannot be relied on); the idea of
stripping them so that they are not transitive has been floated (or make
the attribute non-transitive) and I think rejected.

It all seems unattractive but then so does routing based on fields that
you do not know how to interpret.  When the first field is 2914, it may
be ASN 2914 but it may be someone else using this big new community for
something completely different and claiming that it is only a SHOULD in
the RFC so that gives them licence to put something other than an ASN in
there - well, something along those lines.

To state the obvious, this progresses to the next stage when there is
rough consensus to progress it:-)

Tom Petch

---

From: Peter Hessler <[email-masked]>
Date: Thu, 20 Oct 2016 17:11:18 +0200

On 2016 Oct 20 (Thu) at 15:53:36 +0100 (+0100), t.petch wrote:
:MUST be an ASN works for me, or, paradoxically, MAY be an ASN (since
:then it should be obvious the fields cannot be relied on); the idea of
:stripping them so that they are not transitive has been floated (or make
:the attribute non-transitive) and I think rejected.

I am very happy with MAY instead of SHOULD.

   Global Administrator:  A four-octet namespace identifier.  This
      MAY be an Autonomous System Number.

Is this acceptable to you?

-peter

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 10:24:18 -0500

> Is this acceptable to you?

No. If some network squats on 2914: because they put 0.0.11.98: in the
global administrator, good for them. Just like with rfc1997, we know to
deal with that.  

SHOULD aligns with reality. This topic should be closed, perhaps we can
agree to disagree.

We seem to be suffering from Parkinson's law of triviality.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 10:32:02 -0500

On Thu, Oct 20, 2016 at 10:04:52AM -0400, Jeffrey Haas wrote:
> For example, if I really like Job's 2914 community road-show

For the others on the list: At this week's NANOG in Dallas, Greg Hankins
gave a presentation on Large BGP Communities. The recording can be
accessed here: 

    https://www.youtube.com/watch?v=6Z7dzEzMgHk

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 10:38:58 -0500

> But I think that we have yet to agree what such a section would say.

We are certainly not putting in sections for which we have no content.

I've mentioned this before: a small group of operators is working on
usage guidelines for large bgp communities in the spirit of rfc1998. The
document is not ready yet to be published. The target working group will
be GROW and its intended status Informational.

I think a 12 to 24 month timeframe for the document to mature is
reasonable and not a problem.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 10:41:53 -0500

Hi Tom,

I've removed the word 'usually'. Thank you for the suggestion. 

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 10:48:47 -0500

On Wed, Oct 19, 2016 at 05:34:37PM -0500, David Farmer wrote:
>    allow operators to decide which large communities are received from
>    or propagated to peers.

This would be a statement without teeth. There are BGP implementations
where policy capabilities are not so relevant. I also consider it the
operator's job to negotiate with their vendors on what features are
available on a box.

The market self-corrects. Such text belongs in a commercial request for
proposal, not nessecarily in protocol specification.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 11:01:37 -0500

Dear Brian,

Thank you for your time and detailed review. I'll go over the concerns
one by one.

> (Insert reference to IANA private 32-bit ASN table.)

We've discussed this separately in the thread. The reality is that it is
a 32-bit field, and it is not possible with today's standards to enforce
any semantics on the contents of that 32-bit field. However, operators
have a rich experience in scrubbing bgp communities and sanitizing the
input.

> where their use has not been agreed upon."

This strikes me as superfluous. The current text accomodates this
practise. But to be honest I expect the practise to die out. Given the
spaciousness of Large BGP Communities, I doubt we'll see a lot of
private ASN usage in the global administrator field because there is no
need to do so anymore. 

I'm making a note for the "Usage" document, where we can maybe describe
that if private ASNs are used in the Global Administrator field the
the propagationi characteristics might differ from globally unique ASNs.

>   values of ASN, including non-reserved 16-bit ASN values and
>   non-reserved 32-bit ASN values, which includes all Private Use ASN
>   ranges. Use of third-party ASN values is an explicitly permitted use
>   of Large Communities."
> 

All ASNs are 32-bit values as per 4893/6793 etc. I'm sorry to say, but
the added sentences are redundant. "any value" is a the superset of the
things you mention. 

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 16:59:38 -0500

Hi working group,

On Tue, Oct 18, 2016 at 04:38:00PM -0400, Jeffrey Haas wrote:
> reason why you might want to do such a reservation, to do so you
> should have a practical reason in the document.
> 
> For the 65535:*:* case, for symmetry with RFC 1997, you'd probably
> want to note that if it's used for that symmetry that either the
> existing well known community registry is used at IANA or that a new
> one would need to be created.  Alternatively, you just say the work is
> expected and defer to a future document.
> 
> for common use in case someone decides that they want to do so.  I
> know your organization and others such as Deutsche Telecom have some
> thoughts about what translation infrastructure might look like, and
> such mechanisms would have impact.
> 
> headaches associated with helping with documents such as the as0 and
> RFC 7300 and putting in some restrictions in the configuration...
> followed by having to take them away, I'm very reluctant to put in
> anything beyond "we think it's a bad idea to use these, so pretty
> please don't"

After some off-list back and forth with John Heasley, Adam Chappell,
Jeff Haas and the authors, we came up with the following text to address
the above raised concern.

This will be part of -04.

""""
5.  Reserved Large BGP Community values

   The following Global Administrator values are reserved: 0 (the first
   ASN) [RFC7607], 65535 (UINT_MAX) and 4294967295 (the last ASN)
   [RFC7300].  Operators SHOULD NOT use these Global Administrator
   values.

   Although this document does not define any Special-Use Large BGP
   Communities, the Global Administrator values specified above could be
   used if there is a future need for them.
"""

A preview of the -03 / -04 diff is available here:

https://htmlpreview.github.io/?https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community-04-from-3.diff.html

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 20 Oct 2016 22:13:41 +0000

In addition, to deal with the values for the GA field, we will replace

with

  A Large Community that

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of Job Snijders
> Sent: Thursday, October 20, 2016 3:00 PM
> Cc: heasley <[email-masked]>; IETF IDR WG <[email-masked]>; Sue Hares <[email-masked]>
> https://htmlpreview.github.io/?https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-
> ietf-idr-large-community-04-from-3.diff.html
> 
> Kind regards,
> 
> Job
>

---

From: Job Snijders <[email-masked]>
Date: Thu, 20 Oct 2016 17:50:04 -0500

Hi Jakob,

I am not sure what issue this replacement resolves. With the replacement
text in the document I feel I have more questions than answers.

Usually a community is intended to be sent to one AS to trigger an
action, and to multiple ASes if the community is of informative nature.
We know we can attach multiple Large BGP Communities to a route, because
of the variable length of the attribute.

In an earlier response I pointed at text that addresses this specific
feature already in the current text: https://mailarchive.ietf.org/arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw

Kind regards,

Job

On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote:
>   A Large Community that is intended to be sent to multiple ASes
>   SHOULD contain an ASN in the Global Administrator field. The ASN
>   SHOULD be one that is assigned to the entity that defines the
>   meaning of the rest of the Large Community.  This allows a route to
>   carry multiple Large Communities, the meaning of each being defined
>   by different independent entities.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 20 Oct 2016 23:06:20 +0000

Evidently, it wasn't clear. Now it is.

Thanks,
Jakob.

> From: Job Snijders [mailto:[email-masked]]
> Sent: Thursday, October 20, 2016 3:50 PM
> To: Jakob Heitz (jheitz) <[email-masked]>
> Cc: Jeffrey Haas <[email-masked]>; heasley <[email-masked]>; IETF IDR WG <[email-masked]>; Sue Hares
> <[email-masked]>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 20 Oct 2016 23:46:04 +0000

Perhaps, we should add in an operations section that we should not and will not go any further.
In particular, within an AS and between adjacent BGP neighbors, ANY values will be allowed.
The only requirement is that sender and receiver have the same understanding of the contents,
but no RFC is required to say this.

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of Jakob Heitz (jheitz)
> Sent: Thursday, October 20, 2016 4:06 PM
> To: Job Snijders <[email-masked]>
> Cc: heasley <[email-masked]>; Sue Hares <[email-masked]>; IETF IDR WG <[email-masked]>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 20 Oct 2016 17:28:24 -0700

> but no RFC is required to say this.
Jakob,

I think you still don't understand the purpose or the mechanics of
communities, as what you say makes almost no sense.

The reason "large" needs to be an optional, transitive attribute, is that
the intended party, whose ASN
is in the Global Administrator field, is not necessarily the first or
second party (the one setting the community,
or the one that is the BGP peer of the first party).

The community may travel an arbitrary number of AS hops before it is
received by the ASN in question (global admin).
That ASN is the one who is the (ultimate) intended recipient (of the
community), and whose interprets the latter 8 octets
of the community, using whatever logic he/she wishes. (The prefix will
probably propagate much further, but we
are only concerned about the ASN that is the global administrator of the
community.)

This is NOT limited to within an AS, nor to adjacent BGP peers.

As such, the intermediate AS hops will receive the prefix with the attached
Large Community, but will
not have any understanding of the contents. They are expected to pass them
along, as this is the
necessary part of communities' functioning.

A -> X -> Y -> Z -> B are the Autonomous Systems passing the prefix.
A sets the community. The community is B:something:something.
B interprets the community.
X, Y, and Z, pass it along without acting on it.

I'm sorry to raise a fuss, but since you are involved in editing the I-D,
it would put my mind at ease to hear you say
that you understand the above.

Putting text into this document, if you don't understand the above, may be
harmful to the document,
and to operator folks who are trying to get the bugs out of the document
before it advances.

Sincerely,
Brian

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 21 Oct 2016 00:46:49 +0000

I do understand that the community may travel several AS hops.
That's why I wrote

  A Large Community that

I also understand that this is not the only case and that communities
are often used within an AS only. We MUST NOT restrict that use.

Also, even though AS B defines the community that has GA=B, AS B
is not always the intended recipient. Many ISPs use communities
to signal properties of routes that they send to their customers.
In that case, AS B is the sender, not the recipient.

I wrote "entity" and not "AS", because someone may create only a
single BGP AS, but be assigned many ASNs. That someone is entitled
to use any of her assigned ASNs, not just the one in use by her AS.

Thanks,
Jakob.

From: Brian Dickson [mailto:[email-masked]]
Sent: Thursday, October 20, 2016 5:28 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: Job Snijders <[email-masked]>; heasley <[email-masked]>; IETF IDR WG <[email-masked]>; Sue Hares <[email-masked]>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:

Jakob,

I think you still don't understand the purpose or the mechanics of communities, as what you say makes almost no sense.

The reason "large" needs to be an optional, transitive attribute, is that the intended party, whose ASN
is in the Global Administrator field, is not necessarily the first or second party (the one setting the community,
or the one that is the BGP peer of the first party).

The community may travel an arbitrary number of AS hops before it is received by the ASN in question (global admin).
That ASN is the one who is the (ultimate) intended recipient (of the community), and whose interprets the latter 8 octets
of the community, using whatever logic he/she wishes. (The prefix will probably propagate much further, but we
are only concerned about the ASN that is the global administrator of the community.)

As such, the intermediate AS hops will receive the prefix with the attached Large Community, but will
not have any understanding of the contents. They are expected to pass them along, as this is the
necessary part of communities' functioning.

I'm sorry to raise a fuss, but since you are involved in editing the I-D, it would put my mind at ease to hear you say
that you understand the above.

Putting text into this document, if you don't understand the above, may be harmful to the document,
and to operator folks who are trying to get the bugs out of the document before it advances.

Sincerely,
Brian

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Jakob Heitz (jheitz)
> To: Job Snijders <[email-masked]<mailto:[email-masked]>>
> Cc: heasley <[email-masked]<mailto:[email-masked]>>; Sue Hares <[email-masked]<mailto:[email-masked]>>; IETF IDR WG <[email-masked]<mailto:[email-masked]>>
> > From: Job Snijders [mailto:[email-masked]<mailto:[email-masked]>]
> > To: Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>>
> > Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>; heasley <[email-masked]<mailto:[email-masked]>>; IETF IDR WG <[email-masked]<mailto:[email-masked]>>; Sue Hares
> > <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 20 Oct 2016 18:48:41 -0700

On Thu, Oct 20, 2016 at 5:46 PM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

>   is *intended to be sent to multiple ASes* SHOULD contain an ASN
>

Agreed.

I think the tweak to your wording along the lines of:
"...within an AS and across AS boundaries, ANY values will be allowed."
That removes the notion of adjacent, as well as whether B is sender or
recipient.

Entity is fine.

Thanks,
Brian

> *From:* Brian Dickson [mailto:[email-masked]]
> *Sent:* Thursday, October 20, 2016 5:28 PM
> *To:* Jakob Heitz (jheitz) <[email-masked]>
> *Cc:* Job Snijders <[email-masked]>; heasley <[email-masked]>; IETF IDR
> WG <[email-masked]>; Sue Hares <[email-masked]>
>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt
> (10/17/2016 to 10/31/2016)
>
>
>
>
>
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 21 Oct 2016 05:23:40 +0000

This is a matter for your vendor documentation.
In the case of IOS-XR, the router software acts upon the well-known communities. For example, no-export is acted upon before the neighbor outbound policy is run.

Thanks,
Jakob.

> On Oct 19, 2016, at 11:03 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> When I have created BGP route policies, I've several times asked myself the question "what will the vendor implementation do itself, and what do I need to do in my policy".
> 
> So for instance, do I need to implement the well-knowns myself, or is that something that I need to do in my policy? If I for operational reasons want the router to not do something (for instance I do want NO-EXPORT to traverse AS boundary), how do I do that?
> 
> I think here in the IETF we should always consider to have separate documents for what goes on the wire (compatibility reasons), and what the implementation should do with this information by default in case the user also can set policy.
> 
> The contents of the -large- fields and whether the implementation should check if this is true is a typical thing that the "wire" document should not over-specify. That should instead be an operational document, and that should involve GROW as well.
> 
> --

---

From: t.petch <[email-masked]>
Date: Fri, 21 Oct 2016 11:54:18 +0100

----- Original Message -----
From: "Jakob Heitz (jheitz)" <[email-masked]>
Sent: Friday, October 21, 2016 1:46 AM

Jakob

I read the words and share some of Brian's uncertainties.

" A Large Community that  is intended to be sent to multiple ASes SHOULD
contain an ASN  in the Global Administrator field. "

For me, that is not the BGP protocol we have. Rather,

" A Large Community is sent as a BGP transitive attribute which means
that it will be sent to and received by a large number of ASes of which
only one, or a small number, will be expected to understand and act upon
the community.  Thes ASes may or may not be adjacent to the AS
originating the community.  So that a recipient can tell whether or not
the community is intended for it, the Global Administrator contains an
ASN  ..."

except of course some want the freedom to put any value in the Global
Administrator field in which case the recipients cannot tell (which is
where I keep on coming from:-(

BGP as specified does not have a mechanism to limit the distribution of
a transitive attribute.

I wonder if part of this disconnect is that in practice, a lot of
stripping goes on so that attributes such as these are not really
transitive at all.  The impression I get is that the current attribute
works despite being intended to be transitive when in practice it may
not be so that replacing like for like, with just an increase in size,
is not expected to create any routing issues.

Perhaps we should have two communities, one transitive which MUST have
an ASN and one not, although as Jeff pointed out, that would probably
fail in the face of Route Reflectors and  so is  a non-starter.

Tom Petch

> Cc: Job Snijders <[email-masked]>; heasley <[email-masked]>; IETF IDR
> On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz)
> I'm sorry to raise a fuss, but since you are involved in editing the
I-D, it would put my mind at ease to hear you say
> > Cc: heasley <[email-masked]<mailto:[email-masked]>>; Sue
Hares <[email-masked]<mailto:[email-masked]>>; IETF IDR WG
<[email-masked]<mailto:[email-masked]>>
> > > To: Jakob Heitz (jheitz)
<[email-masked]<mailto:[email-masked]>>
> > > Cc: Jeffrey Haas <[email-masked]<mailto:[email-masked]>>; heasley
<[email-masked]<mailto:[email-masked]>>; IETF IDR WG
<[email-masked]<mailto:[email-masked]>>; Sue Hares
> > > feature already in the current text:
https://mailarchive.ietf.org/arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw
> > > >   by different independent entities.

------------------------------------------------------------------------
--------

---

From: Adam Chappell <[email-masked]>
Date: Fri, 21 Oct 2016 14:36:38 +0200

Hi Jakob.

I must confess I find the original text slightly simpler, and I can't read
obvious benefit from the replacement text, because:

- Large Community attributes are tags on routes. They are going to go
exactly where advertisement policy says they should go, so not much point
calling out the case where they are received by multiple ASes or otherwise.

- If we think it's rude to use private ASNs or steal Job's ASN, it's an
operational matter identical to the one faced today.

- Propagation zone of LC attributes is influenceable by any peers in the
path; but any savvy operator is unwise to rely on behaviour associated with
unfettered or un-manipulated attributes. (Already covered with adequate
wording in sec. 7 I think).

I think the new statement might actually be back-to-front in what it says.
It seems to say that we should use the ASN that defined the LD1 and LD2
parts that we wish to make use of, which isn't helpful. We probably agree
that the ASN referenced in the GA field has ultimate authority on the
definition of semantics and is probably the only AS one can practically
rely on to effect such semantics. So if it helps, perhaps state that?

-- Adam.

On 21 October 2016 at 00:13, Jakob Heitz (jheitz) <[email-masked]> wrote:

> > https://htmlpreview.github.io/?https://github.com/large-bgp-
> communities/large-bgp-communities/blob/master/draft-

-- 

-- Adam.

---

From: Jared Mauch <[email-masked]>
Date: Fri, 21 Oct 2016 08:59:31 -0400

I share others concerns here as well. I see no clarity from this change. 

Jared Mauch

> On Oct 21, 2016, at 8:36 AM, Adam Chappell <[email-masked]> wrote:
> 
> I must confess I find the original text slightly simpler, and I can't read obvious benefit from the replacement text, because:

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Fri, 21 Oct 2016 17:19:40 +0200

Hello Jakob,

I think we need to ask ourselves whether the new wording is really
relevant to implementors. The answer here appears to be that it's not,
because the draft states "Implementations MUST allow the operator to
specify any value for the Global Administrator field." and no amount of
SHOULD will override the MUST.

Secondly, there's literally no way for the vendor to check whether an
ASN belongs to "the entity that defines the meaning of the rest of the
Large Community" so it's completely unenforceable and therefore doesn't
belong in a protocol specification / IDR draft.

If we want to instruct operators to do something, it SHOULD be done in a
RFC1998-like BCP/GROW document and I'd be happy to contribute some
wording which seeks to make that happen when the draft is submitted to
GROW for adoption as a WG subject.

Best regards,
Martijn Schmidt

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Oct 2016 17:42:37 +0200

Hi Martijn,

> Large Community"

Why not ?

If you do not make those 4 octets configurable by spec and always fill it
with AS number defined in your BGP instance you will have assurance it
is ASN of the entity that defines the rest 8 octets of the LC as otherwise
you will likely not establish any EBGP sessions to your peers.

So there is very easy way to enforce it today in any BGP implementation.

However the question is should it be enforced at all ?

Best,
R.

---

From: Peter Hessler <[email-masked]>
Date: Fri, 21 Oct 2016 17:49:58 +0200

On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote:
:Hi Martijn,
:
:> Secondly, there's literally no way for the vendor to check whether an
:> ASN belongs to "the entity that defines the meaning of the rest of the
:> Large Community"
:
:Why not ?
:
:If you do not make those 4 octets configurable by spec and always fill it
:with AS number defined in your BGP instance you will have assurance it
:is ASN of the entity that defines the rest 8 octets of the LC as otherwise
:you will likely not establish any EBGP sessions to your peers.
:
:So there is very easy way to enforce it today in any BGP implementation.

Say I am AS 1234, and I want to control AS 5678.  My transit ISP is AS
9876.

If I set

local-as 1234
peer-as 9876
set large-community 5678:666:1

How is the implementation supposed to know to allow it?

Limitations in the implementation completely defeat the purpose of this
spec.

:However the question is should it be enforced at all ?
:

MUST NOT is a very important part of this spec, and is enforced a few
times in the document.

:Best,
:R.
:

-- 
The moving cursor writes, and having written, blinks on.

---

From: heasley <[email-masked]>
Date: Fri, 21 Oct 2016 16:02:11 +0000

> > ASN belongs to "the entity that defines the meaning of the rest of the

Because to determine if the contents is really something defined by the
GA in the community, the device would need a list of communities that the
GA uses, that list would need a signature and all the infrastructure to
verify that signature....and ultimately, what would the point be anyway?

> you will likely not establish any EBGP sessions to your peers.

BECAUSE IT IS NOT A ONE-WAY OR ONLY ONE-HOP THING.  THE AUTONOMOUS SYSTEM
ITSELF MIGHT SET THE COMMUNITY AS A TAG OR ANOTHER AUTONOMOUS SYSTEM MIGHT
SET IT TO SIGNAL ANOTHER AUTONOMOUS SYSTEM TO DO SOMETHING AND THAT
AUTONOMOUS SYSTEM MAY BE 1 OR MORE AUTONOMOUS SYSTEM HOPS AWAY.  Eg:

	2914:1001 	Ashburn, VA | set by ntt
	2914:450 	96 	customer fallback | received from a customer

a customer might use 2914:450, or a customer of a customer, or a customer
of a customer of a customer ....

Utimately, the so-called Global Administrator field has the same storage
size as an 4-octet ASN, operators will likely use it as such, but as far
as the protocol, it need not be.  It can be any 4-octet value as far as
the protocol is concerned.  Just as BGP RID is 4-octets and is just a
number as far as the protocol is concerned, but operators typically use
an IP address on the device as the RID.

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Oct 2016 18:03:09 +0200

Peter,

Who you control (who is the target of LC - can be expressed in the second 4
octets). And as such at least original discussions were about it.

So if you inject a large community it would have format:
SRC_ASN:DST_ASN:ACTION

In your specific case it would be: 1234:5678:ACTION

The comment was made that there is no way for implementation to insert
valid SRC_ASN .. well it clearly is.

But I am not suggesting spec should enforce it as it does limit use cases
for LC by not allowing to overload first 4 octets. On the other hand it
does provide more responsibility to whoever is injecting LCs so does
improve on BGP clarity and stability from protocol point of view.

Fixing on meaning on first 4 octets also provides very good tool to policy
filtering rules as you know what to expect there. For example you may have
policy allowing to pass any LC where first 4 octets contain any ASN also
listed in your AS_PATH - otherwise drop it. That may effectively help to
support LC global deployment much easier including the N-hops away
destinations.

Thx,
r.

---

From: Peter Hessler <[email-masked]>
Date: Fri, 21 Oct 2016 18:20:16 +0200

Hi Robert

On 2016 Oct 21 (Fri) at 18:03:09 +0200 (+0200), Robert Raszuk wrote:
:Peter,
:
:Who you control (who is the target of LC - can be expressed in the second 4
:octets). And as such at least original discussions were about it.
:
:So if you inject a large community it would have format:
:SRC_ASN:DST_ASN:ACTION
:

Ahh, I see the misunderstanding.

The GA field is normally the ASN of the _entity defining that
namespace_. aka, DEFINING_ASN:ACTION:DST_ASN.

Sec 1

Sec 2:
   Global Administrator:  A four-octet namespace identifier.  This
      SHOULD be an Autonomous System Number.
...
   The Global Administrator field is intended to allow different
   Autonomous Systems to define Large BGP Communities without collision.

To me, that means that 5678 has defined some values that they want me to
use.  The LD1 and LD2 values of them are opaque, and are defined by the
operator who defined them.  Critically, not by the one who sent it.

:In your specific case it would be: 1234:5678:ACTION
:
:The comment was made that there is no way for implementation to insert
:valid SRC_ASN .. well it clearly is.
:
:But I am not suggesting spec should enforce it as it does limit use cases
:for LC by not allowing to overload first 4 octets. On the other hand it
:does provide more responsibility to whoever is injecting LCs so does
:improve on BGP clarity and stability from protocol point of view.
:
:Fixing on meaning on first 4 octets also provides very good tool to policy
:filtering rules as you know what to expect there. For example you may have
:policy allowing to pass any LC where first 4 octets contain any ASN also
:listed in your AS_PATH - otherwise drop it. That may effectively help to
:support LC global deployment much easier including the N-hops away
:destinations.
:
:Thx,
:r.
:
:
:On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <[email-masked]> wrote:
:
:> On 2016 Oct 21 (Fri) at 17:42:37 +0200 (+0200), Robert Raszuk wrote:
:> :Hi Martijn,
:> :
:> :> Secondly, there's literally no way for the vendor to check whether an
:> :> ASN belongs to "the entity that defines the meaning of the rest of the
:> :> Large Community"
:> :
:> :Why not ?
:> :
:> :If you do not make those 4 octets configurable by spec and always fill it
:> :with AS number defined in your BGP instance you will have assurance it
:> :is ASN of the entity that defines the rest 8 octets of the LC as otherwise
:> :you will likely not establish any EBGP sessions to your peers.
:> :
:> :So there is very easy way to enforce it today in any BGP implementation.
:>
:> Say I am AS 1234, and I want to control AS 5678.  My transit ISP is AS
:> 9876.
:>
:> If I set
:>
:> local-as 1234
:> peer-as 9876
:> set large-community 5678:666:1
:>
:> How is the implementation supposed to know to allow it?
:>
:> Limitations in the implementation completely defeat the purpose of this
:> spec.
:>
:>
:> :However the question is should it be enforced at all ?
:> :
:>
:> MUST NOT is a very important part of this spec, and is enforced a few
:> times in the document.
:>
:>
:> :Best,
:> :R.
:> :
:>
:>
:>
:>
:> --
:> The moving cursor writes, and having written, blinks on.
:>

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

-- 
Rules:
	(1)  The boss is always right.
	(2)  When the boss is wrong, refer to rule 1.

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Fri, 21 Oct 2016 18:21:48 +0200

Hi Robert,

I think you're missing the point. Peter already explained that not every
ASN we're trying to signal is necessarily a direct neighbor. So you've
suggested to take a look at the BGP table instead to see if the ASN
appears in any AS_PATH which is in the table. But many routers
participating in the DFZ don't carry a full table, only a default route,
so that information is not available to them. Nevertheless operators of
those default-only networks frequently send communities to their
upstream for inbound routing manipulation (prepends, localpref, RTBH,
etc) to achieve a variety of goals; your suggestion would severely limit
the draft's usefulness.

Summarizing, any restrictions which can not be enforced don't belong in
the IDR document because they're irrelevant to implementors. Arguing
about it doesn't change the fact that such recommendations belong in a
BCP/GROW document. It is that simple.

Best regards,
Martijn

On 10/21/2016 06:03 PM, Robert Raszuk wrote:
> Peter,
>
> Who you control (who is the target of LC - can be expressed in the
> second 4 octets). And as such at least original discussions were about
> it. 
>
> But I am not suggesting spec should enforce it as it does limit use
> cases for LC by not allowing to overload first 4 octets. On the other
> hand it does provide more responsibility to whoever is injecting LCs
> so does improve on BGP clarity and stability from protocol point of view.
>
> Fixing on meaning on first 4 octets also provides very good tool to
> policy filtering rules as you know what to expect there. For example
> you may have policy allowing to pass any LC where first 4 octets
> contain any ASN also listed in your AS_PATH - otherwise drop it. That
> may effectively help to support LC global deployment much easier
> including the N-hops away destinations. 
>
> Thx,
> r.
>
>
> On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler <[email-masked]
> <mailto:[email-masked]>> wrote:
>

-- 
Met vriendelijke groet / Kindest regards,
Martijn Schmidt

i3D.net performance hosting 	
*Martijn Schmidt | Network Architect*
Email: [email-masked] <mailto://[email-masked]> | Tel:
+31 10 8900070

*i3D.net B.V. | Global Backbone AS49544*
Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
VAT: NL 8202.63.886.B01

Website
<http://www.i3d.net/?utm_source=emailsignature&utm_medium=email&utm_campaign=home>
| Case Studies
<http://www.i3d.net/partners/?utm_source=emailsignature&utm_medium=email&utm_campaign=case-studies>
| LinkedIn <https://www.linkedin.com/company/i3d-net>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Oct 2016 18:29:46 +0200

Martijn,

> I think you're missing the point.

I don't think it's me :)

> Peter already explained that not every ASN we're trying to signal is
necessarily a direct neighbor.

I never made any such assumption.

> So you've suggested to take a look at the BGP table instead to see if the
ASN appears in any AS_PATH which is in the table.

Nope ... not at all.

The policy example was nothing to do with BGP table. If I am receiving
BGP_UPDATE it comes with AS_PATH and may contain LC. So if I want very
simple policy to filter trash of LCs I can set it to match first 4 octets
to any ASN present in the same UPDATE MSG AS_PATH attribute. If it there I
do not drop LC.

For stub ASes we could treat their AS_NUMBERS in LCs exactly in the same
way we treat them in AS_PATH today.

Cheers,
R.

On Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt <
[email-masked]> wrote:

> suggested to take a look at the BGP table instead to see if the ASN appears
> in any AS_PATH which is in the table. But many routers participating in the
> DFZ don't carry a full table, only a default route, so that information is
> not available to them. Nevertheless operators of those default-only
> networks frequently send communities to their upstream for inbound routing
> manipulation (prepends, localpref, RTBH, etc) to achieve a variety of
> goals; your suggestion would severely limit the draft's usefulness.
>
> the IDR document because they're irrelevant to implementors. Arguing about
> it doesn't change the fact that such recommendations belong in a BCP/GROW
> document. It is that simple.
>
> Best regards,
> Martijn
>
>
> Who you control (who is the target of LC - can be expressed in the second
> 4 octets). And as such at least original discussions were about it.
>
> Idr mailing [email-masked]://www.ietf.org/mailman/listinfo/idr
>
>
> --
> Email: [email-masked] <//[email-masked]> | Tel: +31 10
> 8900070
>

---

From: Job Snijders <[email-masked]>
Date: Fri, 21 Oct 2016 18:42:41 +0200

On Fri, Oct 21, 2016 at 06:29:46PM +0200, Robert Raszuk wrote:
> simple policy to filter trash of LCs I can set it to match first 4
> octets to any ASN present in the same UPDATE MSG AS_PATH attribute. If
> it there I do not drop LC.

A clever trick, but not a good fit for Large BGP Communities. Large BGP
Communities are opaque, by definition and design.

We want routing policy in which networks can send 2914:X:Y to us, and we
can send 2914:A:B to them - very much like RFC 1997 communities. The
Global Administator field does not necessarily contain the ASN of the
sending party.

Kind regards,

Job

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Oct 2016 18:49:49 +0200

Hey Job,

That's what I thought ... but if so I do not get why there are so many
discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow on
in the fields LCs provides.

If they are opaque that means there is zero structure in place and everyone
is free to put whatever he/she likes in it .. even hex encoded Morse (
https://goo.gl/rHcGeV)

We either allow all opaque and free style or we structure fields such that
for example they may be used in simple parametrized BGP in/out policy
example I provided.

And the excuses type "oh we can not structure it as there is no way to
insert valid ASN" are wrong as there is a way as proven :)

Cheers,
R.

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Fri, 21 Oct 2016 19:03:22 +0200

Hey Robert,

I see that you stated the first field would be filled in automatically
by the "local-as" value defined in your BGP config. That means we'll be
back to two user-customizable fields, so action communities sent between
ASN's are effectively going to collide again and we're back to the same
old RFC1997 problem. It's not an option.

I'll get back to the other part of your message in a minute, so I can
include the discussion you've already had with Job.

Best regards,
Martijn

On 10/21/2016 06:29 PM, Robert Raszuk wrote:
> > So you've suggested to take a look at the BGP table instead to see if
> the ASN appears in any AS_PATH which is in the table. 
>
>
> Nope ... not at all. 
>
> For stub ASes we could treat their AS_NUMBERS in LCs exactly in the
> same way we treat them in AS_PATH today. 
>
> Cheers,
> R.
>
>
>
>
>
> On Fri, Oct 21, 2016 at 6:21 PM, i3D.net - Martijn Schmidt
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Robert,
>
>     I think you're missing the point. Peter already explained that not
>     every ASN we're trying to signal is necessarily a direct neighbor.
>     So you've suggested to take a look at the BGP table instead to see
>     if the ASN appears in any AS_PATH which is in the table. But many
>     routers participating in the DFZ don't carry a full table, only a
>     default route, so that information is not available to them.
>     Nevertheless operators of those default-only networks frequently
>     send communities to their upstream for inbound routing
>     manipulation (prepends, localpref, RTBH, etc) to achieve a variety
>     of goals; your suggestion would severely limit the draft's usefulness.
>
>     Summarizing, any restrictions which can not be enforced don't
>     belong in the IDR document because they're irrelevant to
>     implementors. Arguing about it doesn't change the fact that such
>     recommendations belong in a BCP/GROW document. It is that simple.
>
>     Best regards,
>     Martijn
>
>
>>     Who you control (who is the target of LC - can be expressed in
>>     the second 4 octets). And as such at least original discussions
>>     were about it. 
>>
>>     The comment was made that there is no way for implementation to
>>     insert valid SRC_ASN .. well it clearly is.
>>
>>     But I am not suggesting spec should enforce it as it does limit
>>     use cases for LC by not allowing to overload first 4 octets. On
>>     the other hand it does provide more responsibility to whoever is
>>     injecting LCs so does improve on BGP clarity and stability from
>>     protocol point of view.
>>
>>     Fixing on meaning on first 4 octets also provides very good tool
>>     to policy filtering rules as you know what to expect there. For
>>     example you may have policy allowing to pass any LC where first 4
>>     octets contain any ASN also listed in your AS_PATH - otherwise
>>     drop it. That may effectively help to support LC global
>>     deployment much easier including the N-hops away destinations. 
>>
>>     Thx,
>>     r.
>>
>>
>>     On Fri, Oct 21, 2016 at 5:49 PM, Peter Hessler
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/idr>
>     -- 
>     Met vriendelijke groet / Kindest regards, Martijn Schmidt
>     *Martijn Schmidt | Network Architect* Email:
>     [email-masked] <mailto://[email-masked]> | Tel:
>     +31 10 8900070 <tel:%2B31%2010%208900070> *i3D.net B.V. | Global
>     Backbone AS49544* Van Nelleweg 1, 3044 BC Rotterdam, The
>     Netherlands VAT: NL 8202.63.886.B01 Website
>     _______________________________________________ Idr mailing list
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/idr> 
>

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Fri, 21 Oct 2016 20:01:25 +0200

Hi Robert,

Briefly continuing the earlier discussion for originating routers - stub
networks which exclusively receive a default route from my full table
router don't have complete AS_PATH information. That means the device
won't be able to determine whether or not the configured GA field
corresponds to an ASN in the DFZ.

If we decide (on a protocol level) to filter the LC information on the
receiving LC-speaking BGP router instead of the originating router you'd
limit the transitivity and therefore the usefulness of the Large
Community feature. Let's say that AS65500 wants to send a community via
AS49544 to AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router
will check the Large Community attribute and notice that 2914:x:y is
attached while AS2914 is not in the AS_PATH. It would then have to strip
the Large Community and AS2914 would never receive the Large Community
attribute.

Simply stating that "implementations MUST allow the operator to specify
any value for the Global Administrator field" is the correct way
forward, the suggested SHOULD wording either can't be enforced by
vendor-side checks (and therefore belongs in a BCP/GROW document), or is
- in the way you've suggested it - in direct conflict with the intended
use of the Global Administrator field.

Best regards,
Martijn

On 10/21/2016 06:49 PM, Robert Raszuk wrote:

> discussions of any MUSTs/SHOULDs/MAYs operators are expected to follow
> on in the fields LCs provides. 
>
> If they are opaque that means there is zero structure in place and
> everyone is free to put whatever he/she likes in it .. even hex
> encoded Morse (https://goo.gl/rHcGeV)
>
> We either allow all opaque and free style or we structure fields such
> that for example they may be used in simple parametrized BGP in/out
> policy example I provided. 
>
> On Fri, Oct 21, 2016 at 6:42 PM, Job Snijders <[email-masked]
> <mailto:[email-masked]>> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Oct 2016 20:55:15 +0200

Martijn,

First I think you need to know that all original authors of LC agreed that
the proposal does not solve the community values overload issue. If you and
others were sold on something different then perhaps there is some
disconnect. That is also why some time back I proposed for LCs to have
4x4octets such that today's necessity to overload 1997 can be relaxed.

For stub networks if they get only default route there is no issue as they
will not be getting any LCs.

For ASes which use private_ASes as I already mentioned it is trivial to
treat it in the same way as it is treated in the AS_PATH today. Basically
you would replace your customer private AS with your public AS both in the
AS_PATH and in the first 4 octets of LC.

To conclude ...

There is simply two ways

-A- your 3x4 octets are completely unstructured and you use them as it
seems fit

or

-B- It is structured and draft/rfc specifies what goes into first 4 octets
(say SRC_ASN) and what goes into second 4 octets (say TARGET-ASN) leaving
rest for ACTION+PARAMETERS

Rgs,
r.

On Fri, Oct 21, 2016 at 8:01 PM, i3D.net - Martijn Schmidt <
[email-masked]> wrote:

> router don't have complete AS_PATH information. That means the device won't
> be able to determine whether or not the configured GA field corresponds to
> an ASN in the DFZ.
>
> limit the transitivity and therefore the usefulness of the Large Community
> feature. Let's say that AS65500 wants to send a community via AS49544 to
> AS2914. Upon receipt of the BGP_UPDATE, the AS49544 router will check the
> Large Community attribute and notice that 2914:x:y is attached while AS2914
> is not in the AS_PATH. It would then have to strip the Large Community and
> AS2914 would never receive the Large Community attribute.
>
> any value for the Global Administrator field" is the correct way forward,
> the suggested SHOULD wording either can't be enforced by vendor-side checks
> (and therefore belongs in a BCP/GROW document), or is - in the way you've
> suggested it - in direct conflict with the intended use of the Global
> Administrator field.
>
> Best regards,
> Martijn
>
> everyone is free to put whatever he/she likes in it .. even hex encoded
> Morse (https://goo.gl/rHcGeV)
>

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Fri, 21 Oct 2016 21:29:51 +0200

Hi Robert,

I haven't been "sold" on anything, I'm perfectly aware of the collision
issues I encountered while implementing RFC1997-based communities in our
real-world network and the protocol outlined in this draft alleviates them.

Of course stub networks can't *receive* LC's, but they can still
*transmit* them on the prefixes which they announce to the DFZ via
non-stub networks. The private AS which I mentioned in my previous
message was just an example so I wouldn't have to name a random
real-world network, but please feel free to replace every mention of
AS65500 with AS3333 if that makes it easier to understand the argument.
The same principle applies.

What operators want from their vendors are three completely opaque
4-octet fields, which is exactly what this draft specifies. Please let
operators worry about their own filtering policies (or lack thereof) and
leave such recommendations to the BCP/GROW document.

Best regards,
Martijn

On 10/21/2016 08:55 PM, Robert Raszuk wrote:
> Martijn,
>
> First I think you need to know that all original authors of LC agreed
> that the proposal does not solve the community values overload issue.
> If you and others were sold on something different then perhaps there
> is some disconnect. That is also why some time back I proposed for LCs
> to have 4x4octets such that today's necessity to overload 1997 can be
> relaxed. 
>
> For stub networks if they get only default route there is no issue as
> they will not be getting any LCs. 
>
> For ASes which use private_ASes as I already mentioned it is trivial
> to treat it in the same way as it is treated in the AS_PATH today.
> Basically you would replace your customer private AS with your public
> AS both in the AS_PATH and in the first 4 octets of LC.
>
> To conclude ...
>
> There is simply two ways 
>
> -B- It is structured and draft/rfc specifies what goes into first 4
> octets (say SRC_ASN) and what goes into second 4 octets (say
> TARGET-ASN) leaving rest for ACTION+PARAMETERS
>
> Rgs,
> r. 
>
>
> On Fri, Oct 21, 2016 at 8:01 PM, i3D.net - Martijn Schmidt
>     Briefly continuing the earlier discussion for originating routers
>     - stub networks which exclusively receive a default route from my
>     full table router don't have complete AS_PATH information. That
>     means the device won't be able to determine whether or not the
>     configured GA field corresponds to an ASN in the DFZ.
>
>     If we decide (on a protocol level) to filter the LC information on
>     the receiving LC-speaking BGP router instead of the originating
>     router you'd limit the transitivity and therefore the usefulness
>     of the Large Community feature. Let's say that AS65500 wants to
>     send a community via AS49544 to AS2914. Upon receipt of the
>     BGP_UPDATE, the AS49544 router will check the Large Community
>     attribute and notice that 2914:x:y is attached while AS2914 is not
>     in the AS_PATH. It would then have to strip the Large Community
>     and AS2914 would never receive the Large Community attribute.
>
>     Simply stating that "implementations MUST allow the operator to
>     specify any value for the Global Administrator field" is the
>     correct way forward, the suggested SHOULD wording either can't be
>     enforced by vendor-side checks (and therefore belongs in a
>     BCP/GROW document), or is - in the way you've suggested it - in
>     direct conflict with the intended use of the Global Administrator
>     field.
>
>     Best regards,
>     Martijn
>
>>     That's what I thought ... but if so I do not get why there are so
>>     many discussions of any MUSTs/SHOULDs/MAYs operators are expected
>>     to follow on in the fields LCs provides. 
>>
>>     If they are opaque that means there is zero structure in place
>>     and everyone is free to put whatever he/she likes in it .. even
>>     hex encoded Morse (https://goo.gl/rHcGeV)
>>
>>     We either allow all opaque and free style or we structure fields
>>     such that for example they may be used in simple parametrized BGP
>>     in/out policy example I provided. 
>>
>>     And the excuses type "oh we can not structure it as there is no
>>     way to insert valid ASN" are wrong as there is a way as proven :)
>>
>>     Cheers,
>>     R.
>>
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 21 Oct 2016 21:51:07 +0200

> Please let operators worry about their own filtering policies (or lack
> thereof) and leave such recommendations to the BCP/GROW document.
>
​This is IETF WG and I find such comment inappropriate. This discussion is
about extending BGP protocol and we all should be worried how to apply
effective policy on something which is being defined here.

So triggered by the above let me ask a very simple question. You and others
expressed very clearly that LCs should traverse N-ASes and be executed
somewhere remotely. Great.

Let's also assume that you talk to everyone in the path and convince them
to let your LC go through.

Question:

If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER based
on what field is anyone in the BGP propagation path supposed to let's your
LCs go and stop all other 1000s of LCs injected by anyone else ?

Today RFC1997 don't go far as they have no way to apply per their
originator permit or deny statements.

Thx,
R.

​

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Oct 2016 13:32:06 -0700

On Fri, Oct 21, 2016 at 12:51 PM, Robert Raszuk <[email-masked]> wrote:

> So triggered by the above let me ask a very simple question. You and
> others expressed very clearly that LCs should traverse N-ASes and be
> executed somewhere remotely. Great.
>

This is not how communities (large or RFC1997) work, generally.

The general flow of BGP announcements is;
originator -> (0 or more transit hops "upward" toward the DFZ) -> (across 0
or 1 peering connections) -> (0 or more hops "downward" from provider to
customer, away from the DFZ)

When flowing "upward", if communities are sent, the are generally
propagated. AS hops in the middle may add additional communities (large or
RFC1997 or both).

When crossing a "peer" connection, some filtering and/or evaluation may
occur, on either the sending side or the receiving side, or both.

When flowing "downward", whether communities are sent AT ALL is typically a
local configuration thing, but if they are sent, typically they are sent
unmodified.

Other than local agreements between peers, or between transit providers and
their customers, NO TALKING OCCURS, and it is unreasonable and unscalable
to assume or require that activity.

> LCs go and stop all other 1000s of LCs injected by anyone else ?

(I assume you meant "stomp" not stop.)

Based on no field. Everyone in the BGP propagation path is expected to pass
it or not, based only on local policy for the incoming or outgoing peering
session, and NOT BASED ON THE LC.
The exception is when the local ASN of the particular BGP hop, is the
TARGET_ASN.

The decision by any ASN will generally be one of:
- I don't send communities to neighbor X (where X can be upstream transit,
downstream client, or peer), so I strip ALL communities (or more correctly,
don't send the communities)
- I do send communities to neighbor Y (and pass the communities untouched,
or with an injection of my own set of configured communities per local
policies)
- I am TARGET_ASN, and do something special to the specific LC that starts
with TARGET_ASN, but DO NOT touch any other LC's attached to the prefix

LC are transitive, opaque, and additive; injecting an LC does not "stomp"
on any other LC in the sequence of LCs.

There is a possibility that the number of LCs exceed the capacity of the
UPDATE, in which case something has to happen according to the general RFCs
dictating error handling for this prefix.

The AS_PATH or AS4_PATH observed on the internet (excluding AS-path padding
via AS prepends) is typically on the order of 4-10, including the up, peer,
and down hops. This does not reach "1000s", as those are per-prefix counts.

> originator permit or deny statements.

Correct, and that is all that is being asked here - parity with RFC1997.

There is no requirement or demand for originator -anything-.

Brian

---

From: Paul Jakma <[email-masked]>
Date: Fri, 21 Oct 2016 22:44:02 +0100 (BST)

On Fri, 21 Oct 2016, i3D.net - Martijn Schmidt wrote:

> Summarizing, any restrictions which can not be enforced don't belong 
> in the IDR document because they're irrelevant to implementors. 
> Arguing about it doesn't change the fact that such recommendations 
> belong in a BCP/GROW document. It is that simple.

Syntax can be in the protocol, without per se strictly enforcing the 
semantics - which could be defined elsewhere. A protocol document can 
say some 4-byte data is of type "IPv4 address" and another "ASN" without 
having to get into what that means - specifying how the type and data 
are encoded, while leaving the higher level semantics of the type(s) to 
other documents.

If we're going to encode a bunch of different typed things into a field, 
we might as well as provide a syntax for encoding type information into 
the field - at least for the obvious types of data we are _certain_ will 
be put in there. One of the types might well be "opaque data". ;)

m.v.g / regards,
-- 
Paul Jakma | [email-masked] | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
No wonder you're tired!  You understood so much today.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 21 Oct 2016 15:15:04 -0700

> document. It is that simple.

I'd like to pick a nit with the argument here, as a counter-point to what I
think needs to be in the document.

There are plenty of IDR-specified things that are not enforced or
enforceable, which are nonetheless necessary to define or specify.

Those include things such as:

   - next-hop
   - router-id
   - cluster-id
   - AS-path component(s) [injecting ASNs via prepend mechanisms]
   - MED

Including Global Administrator (with a definition of it as _being_ an ASN),
is all that is required -- if necessary, rewording it to not use RFC 2119
language.

Like all of those other things, they can be set by operators, and are not
able to be enforced without severely restricting operators' activities.

Implementors who apply restrictions on those, may encounter resistance from
their customers, their sales folks and potential customers, and their
customers' peers.

Brian

---

From: Julian Seifert <[email-masked]>
Date: Fri, 21 Oct 2016 22:35:52 +0000

Hi Robert,

I think there is no need to complicate this, in my opinion, simple issue.

We need <THING> to encode information in an easy way that we can append to a route.

The LC allows us to encode information using 12 Octets which allows us a lot of encoding.

It's separated into 3 fields which should(!) be used in a certain way but must be allowed to

be configured to any* value. Why? Because that's what communities are being used for already

and we simply need a bigger space for that.

(*any except those that might be defined as reserved)

There might be migration or other scenarios where enforcing the values of some of the fields might make things more complicated than they need to be. For example when one merged and changed AS-number but doesn't want to change the communities he send or

still wants to be able to receive the "old" as-value communities.

We currently do not check/enforce values of rfc1997 communities. That is only being done

by operator defined policies on the routers and this should stay this way.

We want to continue to do that and simply need larger communities so we can continue doing

what we do with 4-Byte AS-Numbers. So there should be 3 fields of 4 Octets that can be set to any value

and can be used on routers in policy definitions - quite simple.

There is nothing won by enforcing anything it's only making the issue more complex than it needs to be.

Let me ask, what do we gain by enforcing the restrictions on the values?

I think the idea of the draft was to have a tool like we have with rfc1997 but

with larger/more fields to accommodate for 32byte as-numbers.

kind regards,

 Julian

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Sat, 22 Oct 2016 12:39:42 +0200

Hi Brian,

Doesn't the existing wording "The Global Administrator field is intended
to allow different Autonomous Systems to define Large BGP Communities
without collision." already achieve what you want, if you feel that
RFC2119 language is not necessary?

Best regards,
Martijn

On 10/22/2016 12:15 AM, Brian Dickson wrote:
>
>
> On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt
> I'd like to pick a nit with the argument here, as a counter-point to
> what I think needs to be in the document.
>
>   * next-hop
>   * router-id
>   * cluster-id
>   * AS-path component(s) [injecting ASNs via prepend mechanisms]
>   * MED
>
> Including Global Administrator (with a definition of it as _being_ an
> ASN), is all that is required -- if necessary, rewording it to not use
> RFC 2119 language. 
>
> Like all of those other things, they can be set by operators, and are
> not able to be enforced without severely restricting operators'
> activities.
>
> Implementors who apply restrictions on those, may encounter resistance
> from their customers, their sales folks and potential customers, and
> their customers' peers.
>
> Brian

Website

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Sat, 22 Oct 2016 12:57:52 +0200

Hi Robert,

I completely agree that one should be able to filter LC's, but please
treat that filtering the way RFC1997 already does today and leave the
policy of what (not) to filter up to the operators instead of trying to
hard-code policy into the protocol. That is what I said, nothing more,
nothing less.

Brian has provided an excellent answer to your question, so please
consider this as my +1 for his message.

Best regards,
Martijn

On 10/21/2016 09:51 PM, Robert Raszuk wrote:
>
>     Please let operators worry about their own filtering policies (or
>     lack thereof) and leave such recommendations to the BCP/GROW document.
>
> ​This is IETF WG and I find such comment inappropriate. This
> discussion is about extending BGP protocol and we all should be
> worried how to apply effective policy on something which is being
> defined here. 
>
> Let's also assume that you talk to everyone in the path and convince
> them to let your LC go through. 
>
> Question: 
>
> If you choose to inject LC in the format TARGET_ASN:ACTION:PARAMETER
> based on what field is anyone in the BGP propagation path supposed to
> let's your LCs go and stop all other 1000s of LCs injected by anyone
> else ? 
>

---

From: Gert Doering <[email-masked]>
Date: Sat, 22 Oct 2016 14:27:35 +0200

Hi,

> you will likely not establish any EBGP sessions to your peers.

But that is only half the intended usage of communities - one is
"I tag it with <myas>:<some meaning>" to signal something to my own
routers or my customers.

The other one is "I tag it with <jobs as>:<some meaning>", and there is
no way for my router to validate that "<jobs as>" is indeed the one
who defined "<some meaning>".

So, how exactly is the vendor to check variant B?

(And if you do not understand what people use communities for, today,
maybe you should not be argueing these points, sorry)

> So there is very easy way to enforce it today in any BGP implementation.

No.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Sat, 22 Oct 2016 14:34:23 +0200

Hi,

> Global Administator field does not necessarily contain the ASN of the

And this is, just to repeat the obvious, *intentional* and *very useful*.

Gert Doering
        -- Operator who understands BGP
-- 
have you enabled IPv6 on something today...?

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 22 Oct 2016 15:53:05 +0200

You are mixing SRC_ASN with TARGET_ASN in the same field.

Yes RFC1997 works like that but here we have opportunity to improve it.

Thx
R.

---

From: John Scudder <[email-masked]>
Date: Sat, 22 Oct 2016 14:11:19 +0000

Robert,

"Yes RFC1997 works like that but here we have opportunity to improve it."

When the working group accepted the draft as a work item, I think it was pretty clear from the extensive conversation at that time, that the intent was to replicate RFC 1997, not to improve it. In fact, improving it was an explicit nongoal if I remember right. One might argue that was a bad goal have, and I think you did make that argument at the time, but the working group consensus was otherwise.

Of course, consensus can shift over time, and WGLC is a good time to test whether such a shift has occurred, so I don't think it's inappropriate for you to have raised the question again. However, at this point it appears to me that consensus has not changed.

If you feel further conversation would be productive, I don't mean to foreclose on that, but I thought it might be helpful to provide an update about where it appears to me the consensus is trending at present.

--John

On Oct 22, 2016, at 9:53 AM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Thx
R.

On Oct 22, 2016 2:27 PM, "Gert Doering" <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

No.

Gert Doering
        -- NetMaster

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 22 Oct 2016 18:07:48 +0200

Hi John,

Thank you for your message.

As I have indicated in one of the resent emails I also was under complete
impression that Large Communites are to be completely unstructured with
full freedom given to those who are to use them. And that is regardless if
I would agree with that or not.

However recently there was number of emails exchanged (excluding any of my
own messages) enforcing use of ASN within one of the fields of LCs (without
even defining which field would that be or what that ASN is meant to
indicate). Moreover authors of LC took number of actions to accomodate such
requests in the text of the draft.

That was the reason why within last few days I brought back suggestion to
specify meaning of first 4 octets to indicate the src asn. In addition I
also replied to claims that technically it is impossible to make sure that
LC is send with valid src ASN.

And while GROW may define BCP of any sort unless the protocol spec mandates
so no implementation will support it nor policy can be delivered which
automates such validation/filtering.

RFC1997 was defined 20 years ago and via those two decades internet has
changed significantly. In my opinion today BGP protocol should not allow
anonymous injection of free style messages into BGP UPDATE MSG without
having built in mechanism to determine who is the original author of it nor
without having structured fields to simplify creation and maintenance of
eBGP policies.

So for the reasons stated above (as well as those discussed before) I do
not support progressing this draft to RFC in the current form.

(And I completely realize that my opinion is just for the record here and
folks used to RFC1997 style of communities will push it through as well as
vendors who like to have customers will support it :).

Best regards,
Robert.

On Sat, Oct 22, 2016 at 4:11 PM, John Scudder <[email-masked]> wrote:

> When the working group accepted the draft as a work item, I think it was
> pretty clear from the extensive conversation at that time, that the intent
> was to replicate RFC 1997, not to improve it. In fact, improving it was an
> explicit nongoal if I remember right. One might argue that was a bad goal
> have, and I think you did make that argument at the time, but the working
> group consensus was otherwise.
>
> Of course, consensus can shift over time, and WGLC is a good time to test
> whether such a shift has occurred, so I don't think it's inappropriate for
> you to have raised the question again. However, at this point it appears to
> me that consensus has not changed.
>
> If you feel further conversation would be productive, I don't mean to
> foreclose on that, but I thought it might be helpful to provide an update
> about where it appears to me the consensus is trending at present.
>
> --John
>
> On Oct 22, 2016, at 9:53 AM, Robert Raszuk <[email-masked]> wrote:
>

---

From: Richard Hartmann <[email-masked]>
Date: Sat, 22 Oct 2016 20:58:50 +0200

> to 10/31).   Please comment if draft-ietf-idr-large-community-03.txt  is

Looks good to me, +1.

Richard

---

From: Brian Dickson <[email-masked]>
Date: Sat, 22 Oct 2016 14:48:16 -0700

Hi, Martin,

My concern is that there are differences between the language in the introduction, in the main body, and in the additional text.

Similar to the difference between a newspaper headline and the article content, if there is any disconnect, which takes precedence?

I'd like every place it's used, for the GA==ASN to be crystal clear.

If it were the other way around (intro wrong or unclear, main definition right), I would be fine with it.

IMHO the only place it actually needs to be fixed is where I initially indicated.
Either works: no 2119 language and "is an ASN", or use of "MUST".

Brian

Sent from my iPhone

> On Oct 22, 2016, at 3:39 AM, i3D.net - Martijn Schmidt <[email-masked]> wrote:
> 
> Hi Brian,
> 
> Doesn't the existing wording "The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision." already achieve what you want, if you feel that RFC2119 language is not necessary?
> 
> Best regards,
> Martijn
> 
>>> On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt <[email-masked]> wrote:
>>> 
>>> Summarizing, any restrictions which can not be enforced don't belong in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.
>> 
>> I'd like to pick a nit with the argument here, as a counter-point to what I think needs to be in the document.
>> 
>> There are plenty of IDR-specified things that are not enforced or enforceable, which are nonetheless necessary to define or specify.
>> 
>> next-hop
>> router-id
>> cluster-id
>> AS-path component(s) [injecting ASNs via prepend mechanisms]
>> MED
>> Including Global Administrator (with a definition of it as _being_ an ASN), is all that is required -- if necessary, rewording it to not use RFC 2119 language. 
>> 
>> Like all of those other things, they can be set by operators, and are not able to be enforced without severely restricting operators' activities.
>> 
>> Implementors who apply restrictions on those, may encounter resistance from their customers, their sales folks and potential customers, and their customers' peers.
>> 
>> Brian
> 
> -- 
> Martijn Schmidt | Network Architect
> Email: [email-masked] | Tel: +31 10 8900070
> 
> i3D.net B.V. | Global Backbone AS49544
> Website | Case Studies | LinkedIn
>

---

From: Joe Provo <[email-masked]>
Date: Sun, 23 Oct 2016 19:34:31 -0400

>         -- Operator who understands BGP

I'm just Yet Another Operator, but this, a thousand times.

Parity for the poor devils stuck with 32b ASNs is all we need - no
"enforcement" nor mandatory values. That can and should be the work
of other, more comprehensive drafts for structured signalling methods.

Cheers!

Joe

-- 
        RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 24 Oct 2016 13:10:52 -0400

Hi Everybody,

There has been a fair amount of debate about this sentence in the draft:

"   Global Administrator:  A four-octet namespace identifier.  This
     SHOULD be an Autonomous System Number."

Many of the objections can be summed up by saying "I can't program a router to enforce this rule". This is true, but as Brian has pointed out, it's hardly the first example of such a thing in a BGP spec. (Indeed, RFC 1997 says the equivalent community field "shall be encoded using an autonomous system number" but of course provides no enforcement mechanism.)

Other objections seem to be pursuing the question of whether it might be possible to revise the proposal to make the rule enforceable. Whether or not this is possible in principle seems beside the point since it would violate the "small and simple" 1997-equivalent goal of the proposal that was part of the consensus when the WG accepted it. 

After reviewing the mailing list discussion to date, it's the chairs' sense that consensus is trending towards keeping the text as written. As always, if you disagree with that consensus and feel you have something new to add to the discussion, please do.

Thanks,

--John and Sue

---

From: [email-masked]
Date: Mon, 24 Oct 2016 17:50:40 +0000

October 24, 2016 7:11 PM, "John G. Scudder" <[email-masked]> wrote:
> Many of the objections can be summed up by saying "I can't program a router to enforce this rule".
> This is true, but as Brian has pointed out, it's hardly the first example of such a thing in a BGP
> spec. (Indeed, RFC 1997 says the equivalent community field "shall be encoded using an autonomous
> system number" but of course provides no enforcement mechanism.)
> 
> Other objections seem to be pursuing the question of whether it might be possible to revise the
> proposal to make the rule enforceable. Whether or not this is possible in principle seems beside
> the point since it would violate the "small and simple" 1997-equivalent goal of the proposal that
> was part of the consensus when the WG accepted it. 
> 
> After reviewing the mailing list discussion to date, it's the chairs' sense that consensus is
> trending towards keeping the text as written. As always, if you disagree with that consensus and
> feel you have something new to add to the discussion, please do.
> 
> Thanks,

Hello John,

I have to admit that there is a tendency to put on paper rules that have relied on common sense for ages.
Thing that, most of the times, clashes with the goals to be as flexible and as "small and simple" as possible.

I agree with you that we should keep the text as written and *if needed* discuss the operational details on GROW.

Regards

---

From: heasley <[email-masked]>
Date: Mon, 24 Oct 2016 18:08:18 +0000

> You are mixing SRC_ASN with TARGET_ASN in the same field.

I want to point-out that by forcing the first field to be "src_asn" as
you are suggesting, would make one intended use of -large- not possible,
for ASN1 to tell ASN2 to do something with a route as it applies to ASN3.
eg: ASN2:ASN3:action, ie: apply "action" (such as prepend) defined by ASN2
to ASN1's route when advertised to ASN3.

> Yes RFC1997 works like that but here we have opportunity to improve it.

We have improved it.

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 24 Oct 2016 20:17:48 +0200

You still could do that.

You overload last octet with exact action you need just like you do today
with 1997.

Three sets of 4 octets with no semantics still requires curret way to
advertise what action given community means at any target ASN.

Best,
R

Ps. Besides adding 4 more octets to leave current LC as is just to be able
to avoid anonymous injections seems to me like very little price as
compared with befit. But I guess am alone with that point of view here.

---

From: heasley <[email-masked]>
Date: Mon, 24 Oct 2016 18:19:24 +0000

> You overload last octet with exact action you need just like you do today

Please review the threads associated with -large- to re-discover why that
is not acceptable.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 24 Oct 2016 19:11:28 +0000

This draft provides a 12 byte community.
The meaning of the 12 bytes is to be defined by mutual agreement between the sender and the receiver.
In many cases, a community is confined to within a single AS or between two ASes.
In that case, no further specification from the IETF is necessary.
In the case that a community stays attached to a route while it is propagated to multiple ASes,
we need to specify a little more.
For this case, we recommend that the first 4 bytes contain the ASN that is assigned to the entity that defines the meaning of the other 8 bytes.
In this way, multiple entities can attach communities to the same route without conflict.

There is no source ASN and no target ASN, just the namespace ASN.
I say "entity" and not AS, because an entity that is assigned an ASN does not necessarily use the ASN to construct an AS.

Thanks,
Jakob.

> From: Idr [mailto:[email-masked]] On Behalf Of heasley
> Sent: Monday, October 24, 2016 11:19 AM
> To: Robert Raszuk <[email-masked]>
> Cc: heasley <[email-masked]>; IETF IDR WG <[email-masked]>; Susan Hares <[email-masked]>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 24 Oct 2016 12:47:07 -0700

On Mon, Oct 24, 2016 at 10:10 AM, John G. Scudder <[email-masked]> wrote:

> [...] if you disagree with that consensus and feel you have something new
> to add to the discussion, please do.
>

I agree with the consensus sentiment, and only have suggestions for making
that sentiment clearer.

I think some recent discussion here has helped identify the corner
cases/nuances, which I think can inform that wording.

Here's a first cut at a suggested changes, and rationale:

[Replace all instances of "Global Administrator" with "Global Administrator
ASN" and/or GA_ASN.]

"Global Administrator ASN: a four-octet namespace identifier.  The
namespace is under exclusive control of the Global Administrator of the
ASN. There is no requirement that this namespace be used only within this
ASN."

Feel free to remove words or rephrase to shorten or improve clarity.

Brian

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 25 Oct 2016 13:10:12 +0200

Brian Dickson wrote:
> I agree with the consensus sentiment, and only have suggestions for
> making that sentiment clearer.
> 
> [Replace all instances of "Global Administrator" with "Global 
> Administrator ASN" and/or GA_ASN.]
> 
> namespace is under exclusive control of the Global Administrator of
> the ASN. There is no requirement that this namespace be used only
> within this ASN."

The sentiment in your suggestion is to harden the association between
the term "Global Administrator" and "ASN".  This isn't making things
clearer: it's proposing to change the meaning of what's currently in the
draft, in a direction which has already been discussed.

Nick

---

From: Richard A Steenbergen <[email-masked]>
Date: Tue, 25 Oct 2016 10:00:44 -0500

Hello,

As a network operator, and a listed author on the "competing" wide BGP 
communities draft, I'd like to make a few comments.

At the time I originally got involved in helping to create a "better" BGP 
community implementation (around 2010, IIRC), we were facing the rather 
serious problem that when 16-bit ASNs ran out, there was no good mechanism 
for 32-bit speakers to use BGP communities in the way we've all come to 
know and love on the Internet. 

Quite frankly, my involvement with that draft wasn't because I in any way 
considered it to be the best solution, but because I thought we needed to 
do SOMETHING, and I didn't want to see something that had zero ACTUAL 
operator vetting get rolled out. I got very busy with other things in life 
(being the CTO of a Tier 1, launching a new startup, etc), so admittedly 
this issue fell off my radar (and as an owner of many 16-bit ASNs, it was 
never really something that affected me personally anyways :P), but I am 
absolutely appalled to see that the state of affairs has not changed since 
then. This is disgraceful in a way that only the IETF is capable of 
delivering, and I feel very sorry for the poor networks who are trying to 
get off the ground today in a 32-bit ASN world with issues like this still 
outstanding.

Having reviewed the current state of both proposals, I am now a firm 
supporter of the large communities draft, and wish to remove my support 
and authorship from the wide communities draft. This is the simple, 
effective, and not overly convoluted solution we need, and I'm glad that 
someone is actually taking the time and energy to get it fixed once and 
for all.

-- 
Richard A Steenbergen <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

---

From: t.petch <[email-masked]>
Date: Tue, 25 Oct 2016 17:54:23 +0100

----- Original Message -----
From: "Nick Hilliard" <[email-masked]>
Sent: Tuesday, October 25, 2016 12:10 PM

> draft, in a direction which has already been discussed.

Which in turn is seems to be taking us away from the aim of this work,
as stated recently by John, namely,

"When the working group accepted the draft as a work item, I think it
was pretty clear from the extensive conversation at that time, that the
intent was to replicate RFC 1997, not to improve it. "

The freedom to put anything you feel like putting in the first field is
not replicating RFC 1997, it is a significant (IMHO) change and the
sense I get is that many here want that as an 'improvement'.  For me, it
is a hazard to the Internet, not an improvement (which is why I oppose
it).  I am with Brian on this.

Tom Petch

---

From: Brian Dickson <[email-masked]>
Date: Tue, 25 Oct 2016 12:41:50 -0700

> draft, in a direction which has already been discussed.

Actually, no.

What I am proposing, is to make the document internally consistent.

The last paragraph of section 1 (Introduction) reads as follows:

   actions significant to that ASN

 Making the field descriptions and wording in section 2 agree with this, is
the intent.

Since there has been no disagreement on the introduction, and in fact that
the
introduction was offered as proof that there was no need to change
the wording (to which I disagree), I was suggesting the changes that move
toward
the general understanding conveyed in the introduction.

I have also asked if anyone can come up with a specific counter-example,
where a value
other than an ASN would be legitimately be used in the first 4 octets.

Is it the case that any ASN owner gets to exclusively define the LC for
their ASN?

If not, then this is not accurately documented in the proposed standard,
and it also
fails to achieve parity with RFC1997.

If it is the case (exclusive ASN->LC definitions), it would behoove us to
say so.

None of the above implies any need to enforce anything, on the part of
implementations.

It does not need to be any stronger than making the definitions consistent
with the Introduction.
IMHO, that is what my wording accomplishes, and is the reason for proposing
wording changes.

Brian

P.S. In case it isn't clear:

ASN->Global Administrator is 1:1

Global Administrator -> ASN is 1:many (where "many" includes "1" as the
degenerate case).

Which GA_ASN value is actively used by GA, is entirely up to GA.

Who can use the LCs defined by GA is "anyone".

Whose LC announcements are honored by GA (and/or third parties) is up to GA
(or those third parties).

Example of hypothetical use case:
A group of GAs agree to define amongst themselves, a special-purpose LC.
In order to simplify the situation, they agree to use GA_ASN_1:X:Y as the
LC.
(X and Y are a single set of fixed values.)

This avoids replicating the same functionality with different values
GA_ASN_N:X:Y,
and simplifies the operator's processing of the LC.

The LC may be common knowledge, but is likely only accepted by the ASNs
within
the group of GAs, when received from each other.

The LC is used by multiple ASNs, but is only defined by the owner of
GA_ASN_1.

So, the binding of "exclusive" is on "definition of LC value->semantic
mappings",
but is not exclusive in the use by sending or receiving ASNs.

All of this detail is stuff that will (I expect) end up in the GROW
document.

However, the IDR document needs to have support in its definitions, for
those nuances.

Simply weakening the definition to "SHOULD", IMHO places undue restrictions
on the intended
GROW document.

I have yet to see anyone give a single use case that requires "SHOULD"
rather than "MUST".

Brian

---

From: David Farmer <[email-masked]>
Date: Thu, 27 Oct 2016 00:10:32 -0500

On Mon, Oct 24, 2016 at 12:10 PM, John G. Scudder <[email-masked]> wrote:

> Many of the objections can be summed up by saying "I can't program a
> router to enforce this rule". This is true, but as Brian has pointed out,
> it's hardly the first example of such a thing in a BGP spec. (Indeed, RFC
> 1997 says the equivalent community field "shall be encoded using an
> autonomous system number" but of course provides no enforcement mechanism.)
>
> Other objections seem to be pursuing the question of whether it might be
> possible to revise the proposal to make the rule enforceable. Whether or
> not this is possible in principle seems beside the point since it would
> violate the "small and simple" 1997-equivalent goal of the proposal that
> After reviewing the mailing list discussion to date, it's the chairs'
> sense that consensus is trending towards keeping the text as written. As
> always, if you disagree with that consensus and feel you have something new

I support the consensus as described. However, maybe an alternative to at
least partially address some of the concerns is to discuss the consequences
of the Global Administrator and Local Data Part fields being used
differently than intended. How about something like the following;

   The Global Administrator field SHOULD be an Autonomous System Number
   and is intended to allow different Autonomous Systems to define Large
BGP
   Communities without collision. The meaning associated with the Local
Data
   Part fields are locally defined by each Autonomous System.  Operational
use
   of Large BGP Communities inconstant with this intent could result in
   undesired routing behavior. Implementations MUST allow the operator to
   specify any value for the Global Administrator and Local Data Part
fields.

Thanks.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 29 Oct 2016 15:47:25 +0100

Brian Dickson wrote:
>  Making the field descriptions and wording in section 2 agree with this,
> is the intent.

Brian,

hmm yes, I agree this is a problem that needs to be fixed.

> Since there has been no disagreement on the introduction, and in
> fact that the introduction was offered as proof that there was no
> need to change the wording (to which I disagree), I was suggesting
> the changes that move toward the general understanding conveyed in
> the introduction.

The spec for the first 4 octets in the document is "Global
Administrator" and this is located in section 2.  The introduction is an
introduction, not a definition.  The text for this has been cleaned up
to make it consistent with section 2 and Job plans to post -07 later
today (see https://git.io/vXLO7 for diffs).  I've also gone through the
rest of the document to ensure that there are no other inconsistencies
in this area.

The other issues you raised in your email were all raised prior to
John's email of oct 24, and I don't really want to get bogged down in
another round of arguments about them.

Nick