Subject: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

From: [email-masked]
Date: Sat, 01 Oct 2016 01:38:50 -0700

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

        Title           : Large BGP Communities
        Authors         : Jakob Heitz
                          Keyur Patel
                          Job Snijders
                          Ignas Bagdonas
                          Adam Simpson
	Filename        : draft-ietf-idr-large-community-01.txt
	Pages           : 8
	Date            : 2016-10-01

Abstract:
   This document describes the Large BGP Community attribute, an
   extension to BGP (RFC 4271).  This attribute provides a mechanism to
   signal opaque information within separate namespaces to aid in
   routing management.  The attribute is suitable for use in 4-byte ASNs
   (RFC 6793).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-idr-large-community/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-idr-large-community-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-large-community-01

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

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

---

From: Job Snijders <[email-masked]>
Date: Sat, 1 Oct 2016 10:54:34 +0200

Dear working group,

ChangeLog from -00 to -01:

    o Reworded abstract avoid citation (Thanks John Heasley, Tom Scholl, Tom Petch)
    o Add early IANA Allocation codepoint (Thanks Susan Hares & John Scudder)
    o Reserve 0, AS_MAX, AS4_MAX ranges (Thanks Jeff, Brian, John Heasley)
    o Use "communities" vs "community" in a consistent manner (thanks Nick)
    o Clarification that Global Administrator should usually be the ASN
    o Removed EBNF in favor of textual guidelines
    o remove hints on PDU transmission, this is implied well enough by the ASCII art (Nick)
    o remove most of the text about Global Administrator usage, this is
      better handled in the "Usage" document which will go to GROW
    o clarify duplicate handling
    o clarify re-ordering
    o reduce routing semantics to a single sentence
    o reword security section, add reference to rfc7454
    o move note about 'invalid' ASNs into the error handling section
    o worksmithing in Textual Representation and Aggregation sections (Jakob, Nick)
    o use documentation ASN 64496 as example instead of reserved 65000 (Nick)
	o spelling/grammar/style changes

Kind regards,

Job

On Sat, Oct 01, 2016 at 01:38:50AM -0700, [email-masked] wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: t.petch <[email-masked]>
Date: Mon, 3 Oct 2016 10:13:02 +0100

Um

The changes are not quite what I had in mind.

Abstract - the idea is not just to remove the formal reference but to
remove any mention thereof.   I think that 'RFC 4271' and 'RFC 6793'
should be removed in their entirety.  If people want to know more,
having read the Abstract, then they get the document and have the links.
I would only put in 'RFC4271' if the I-D was closely tied to it, e.g.
obsoleting it.

IANA Considerations; I proposed 'registry' and 'group' because that is
what draft-leiba-cotton-iana-5226bis recommends (one day, perhaps in the
coming decade, that I-D will become an RFC but in the meantime, it is
the best guidance we have:-).  That I-D says

"     When creating a registry, the group that it is a part of must be
      identified using its full name, exactly as it appears in the IANA
      registry list.
"

And the mention of value 30 should make it clear that this is an early
allocation.

I like to make IANA's work simple.

On more challenging matters, I think s.2 should specify the encoding of
a 16-bit ASN - left or right justified?

The use of 'SHOULD' implies that there are cases when this can be
ignored and I would expect the I-D to point them out, perhaps there are
occasions when reserved, not global, ASN could appear there.

I find
' There are no routing semantics implied by the Global Administrator
   field.'
a bit vague and perhaps wrong.  I see the point of communities as being
routing semantics, for some meaning of the phrase!

I think Section 3 needs qualifying; it should allow for there being no
communities in the routes being aggregated; and what happens if the
communities are a mix of large and not large?  (Something that RFC4360
s.6 addresses)

More generally, a big issue with 4 octet ASN was migration, the world
becoming a mix of boxes that supported 4 octet ASN and those that did
not.  I think that that issue needs addressing.  Will boxes convert
traditional communities to large, or should that be specifically
prohibited (I think that latter)?

Tom Petch

---

From: Job Snijders <[email-masked]>
Date: Mon, 3 Oct 2016 11:59:36 +0200

Hi Tom,

> The changes are not quite what I had in mind.

Luckily we can try to get it right in -02! :)

> I would only put in 'RFC4271' if the I-D was closely tied to it, e.g.

How about:

    "This document describes the Large BGP Community attribute, an
    extension to BGP-4. This attribute provides a mechanism to signal
    opaque information within separate namespaces to aid in routing
    management. The attribute is suitable for use in 4-octet ASNs."

> I like to make IANA's work simple.

I am not entirely clear on where you propose to use the word 'group' and
'registry', can you contribute a sentence that is aligned with
draft-leiba-cotton-iana-5226bis-18 ?

> On more challenging matters, I think s.2 should specify the encoding
> of a 16-bit ASN - left or right justified?

I am not sure that is required. Technically speaking, all ASNs are now
32-bit ASNs.

> occasions when reserved, not global, ASN could appear there.

The contents of that field are entirely at the operator's discretion.
Hence the 'SHOULD'. 

> I find ' There are no routing semantics implied by the Global
> Administrator field.' a bit vague and perhaps wrong.  I see the point
> of communities as being routing semantics, for some meaning of the
> phrase!

I am not sure I follow what isnt clear about the sentence. Would the
section benefit if the sentence is removed all together?

> communities are a mix of large and not large?  (Something that RFC4360

If we add the following, would that address your concern?

    "A route may carry both the BGP Communities attribute, as defined in
    [RFC1997]), and the Extended BGP Communities attribute, as defined
    in [RFC4360], and the Large BGP Community attribute. In this case,
    the BGP Communities attribute is handled as specified in [RFC1997],
    and the Extended BGP Communities attribute is handled as specified
    in [RFC4360], and the Large BGP Community is handed as specified in
    this document."

> prohibited (I think that latter)?

I consider the topic of 'mapping' out of scope for an IDR document. See
my earlier message here: https://mailarchive.ietf.org/arch/msg/idr/GHxOF9Y6wsdQ2e_-4jI2ejUZ2kk

Mapping is up to the operator's local routing policy and by extend, the
vendors.

Kind regards,

Job

---

From: t.petch <[email-masked]>
Date: Mon, 3 Oct 2016 12:06:53 +0100

<in line>
----- Original Message -----
From: "Job Snijders" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 03, 2016 10:59 AM
>     management. The attribute is suitable for use in 4-octet ASNs."

Yes

> draft-leiba-cotton-iana-5226bis-18 ?

   IANA has made an Early Allocation of the value 30 (LARGE_COMMUNITY )
in the "BGP
   Path Attributes" registry under the "Border Gateway Protocol
   (BGP) Parameters" group and is now asked to make that Permanent.

(I am assuming that all goes well between now and IETF Last Call:-)

> I am not sure that is required. Technically speaking, all ASNs are now

Well, not in traditional communities so if anyone 'knows' that the first
16 bit are an ASN, they will be disappointed, so I think it worth
spelling out.

> section benefit if the sentence is removed all together?

For me, yes; you say that it identifies the namespace and for me, that
is enough.

>     in [RFC4360], and the Large BGP Community is handed as specified
in

Yes, that would allay my concern.

> my earlier message here:
https://mailarchive.ietf.org/arch/msg/idr/GHxOF9Y6wsdQ2e_-4jI2ejUZ2kk
> Mapping is up to the operator's local routing policy and by extend,
the

Well, Bertrand Duvivier seemed to be proposing something along these
lines last week, and I for one would see a mapping from old protocol to
new protocol as very much is scope for the new protocol I-D, if only to
say there is none.

Tom Petch

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 03 Oct 2016 12:41:29 +0100

> new protocol as very much is scope for the new protocol I-D, if only to

creating a mapping between 1997 and large does very little in practice,
except to increase complexity.  Certainly it doesn't make 1997 community
support any more or less available.  I'd be in favour of not having any
mapping between the two

Nick

---

From: Job Snijders <[email-masked]>
Date: Mon, 3 Oct 2016 13:57:23 +0200

Dear Tom,

On Mon, Oct 03, 2016 at 12:06:53PM +0100, t.petch wrote:
> > > Abstract - the idea is not just to remove the formal reference but
> > > to remove any mention thereof.   I think that 'RFC 4271' and 'RFC
> > > 6793' should be removed in their entirety.  If people want to know
> > > more, having read the Abstract, then they get the document and
> > > have the links.  I would only put in 'RFC4271' if the I-D was
> > > closely tied to it, e.g. obsoleting it.
> >
> > How about:
> >

This has been incorporated for -02.

> > can you contribute a sentence that is aligned with
> in the "BGP Path Attributes" registry under the "Border Gateway
> Protocol (BGP) Parameters" group and is now asked to make that
> Permanent.
> 

OK, i've updated the -02 draft with this text. Thank you.

> Well, not in traditional communities so if anyone 'knows' that the
> first 16 bit are an ASN, they will be disappointed, so I think it
> worth spelling out.

I am not convinced, it does feel somewhat superfluous to me. Section 2
clearly depicts an ascii art with 32 bits for the Global Administrator.

We could add something which is akin to what rfc4893 states:

    "For Autonomous System numbers which can be encoded as a 2-octet
    value, the two high-order octets of the Global Administrator field
    are set to zero."

Do you have a better suggested sentence? The above feels like a kludge.

> > > Administrator field.' a bit vague and perhaps wrong.  I see the
> > > point of communities as being routing semantics, for some meaning
> > > of the phrase!
> >

OK, removed the sentence.

>  > > I think Section 3 needs qualifying; it should allow for there
>  > > being no communities in the routes being aggregated; and what
>  > > happens if the communities are a mix of large and not large?
>  > > (Something that RFC4360 s.6 addresses)
> >
> >     "A route may carry both the BGP Communities attribute, as
> >     defined in [RFC1997]), and the Extended BGP Communities
> >     attribute, as defined in [RFC4360], and the Large BGP Community
> >     attribute. In this case, the BGP Communities attribute is
> >     handled as specified in [RFC1997], and the Extended BGP
> >     Communities attribute is handled as specified in [RFC4360], and
> >     the Large BGP Community is handed as specified in this
> >     document."
> 

OK, I've added this in a new section called "Operations" in -02.

> > > More generally, a big issue with 4 octet ASN was migration, the
> > > world becoming a mix of boxes that supported 4 octet ASN and those
> > > that did not.  I think that that issue needs addressing.  Will
> > > boxes convert traditional communities to large, or should that be
> > > specifically prohibited (I think that latter)?
> >
> lines last week, and I for one would see a mapping from old protocol
> to new protocol as very much is scope for the new protocol I-D, if
> only to say there is none.

I am really not sure we should specify everything the document is _not_.
(Similar to your agreement to remove the sentence about 'no routing
semantics are implied') I also do not see precedent for 'there is no
mapping between 1997 and extended communities' in the rfc4360 document.

I agree that mapping in and of itself is an interesting challenge, but
the concept is probably is better served as an internet-draft targetted
to be of Informational status in the GROW working group.

Kind regards,

Job

---

From: Jared Mauch <[email-masked]>
Date: Mon, 3 Oct 2016 10:14:10 -0400

> support any more or less available.  I'd be in favour of not having any

	I don't think any mapping is a protocol-level thing, it's something
providers may decide to do internally, just like supporting any other protocol
extensions, eg: multicast nlri, flowspec, 2547-vpn, etc.

	Some may, others amy decide not to.

	- jared

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

---

From: t.petch <[email-masked]>
Date: Mon, 3 Oct 2016 15:59:52 +0100

----- Original Message -----
From: "Nick Hilliard" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: "Job Snijders" <[email-masked]>; <[email-masked]>
Sent: Monday, October 03, 2016 12:41 PM

> > lines last week, and I for one would see a mapping from old protocol
to
> support any more or less available.  I'd be in favour of not having
any

Me too and I would go so far as to put in a sentence to that effect.
Perhaps I am oversensitive to the issues of ASN conversion that arose at
the time of 4-octet ASN - except that what we are doing now is in a
sense continuing the work of 4-octet ASN which was not completed at the
time, which makes me want to dot a few more 'i's.

Long term, I wonder if old style communities will be replaced by these
new style ones as and when support and familiarity grows and so a
mapping will be wanted at some point in the future to migrate out the
old style but I would not want to try and specify that now.

Tom Petch

---

From: t.petch <[email-masked]>
Date: Mon, 3 Oct 2016 15:54:04 +0100

<snipping the agreed parts>

Tom Petch

----- Original Message -----
From: "Job Snijders" <[email-masked]>
To: "t.petch" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 03, 2016 12:57 PM

> Do you have a better suggested sentence? The above feels like a
kludge.

I think that that text is fine.

Tom Petch

<snip>

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 03 Oct 2016 16:46:07 +0100

> Do you have a better suggested sentence? The above feels like a kludge.

I don't understand why this is necessary.

This is a global administrator field, i.e. it's not guaranteed that it's
an ASN, so there can be no protocol level assumption that any number
configured to fit in there should be treated any differently to any
other number, even if that number incidentally happens to be the same as
the ASN configured on the device.

Secondly, the field is 32 bits wide, so if you have a number between 0
and 65535, there is exactly one way of fitting that number into a a 32
bit placeholder in network byte order.  This is why big endian encoding
works so well on the wire, and little-endian is terribly broken.

The text would be better if this were left out completely.

Nick

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 3 Oct 2016 16:12:05 +0000

One thing of substance that changed is the definition of 3 reserved ranges.

            0:0:0 -          0:4294967295:4294967295

65535:0:0 -      65535:4294967295:4294967295

4294967295:0:0 - 4294967295:4294967295:4294967295

 3 is messy. 1 is enough. Which one do we want?

Thanks,
Jakob.

On Oct 3, 2016, at 8:46 AM, Nick Hilliard <[email-masked]<mailto:[email-masked]>> wrote:

Job Snijders wrote:

Nick

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

---

From: Job Snijders <[email-masked]>
Date: Mon, 3 Oct 2016 18:16:08 +0200

> One thing of substance that changed is the definition of 3 reserved

My personal take is to keep all three of them reserved. I don't consider
it messy at all. More feedback from the working group is appreciated.

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 3 Oct 2016 16:53:14 +0000

I write code. I watch people write code and test code. It adds to development time. 3 ranges is not necessary. It's messy.

Thanks,
Jakob.

> On Oct 3, 2016, at 9:16 AM, Job Snijders <[email-masked]> wrote:
>

---

From: Job Snijders <[email-masked]>
Date: Mon, 3 Oct 2016 18:57:06 +0200

On Mon, Oct 03, 2016 at 04:53:14PM +0000, Jakob Heitz (jheitz) wrote:
> I write code. I watch people write code and test code. It adds to
> development time. 3 ranges is not necessary. It's messy.

As an implementor, you are not supposed to do anything with these
ranges0. They are just reserved in the sense that they belong to IANA,
not to a single operator. For the moment, operators should avoid using
values from these ranges, but implementations shouldn't prohibit them
from doing so.

This is no different than RFC1997 which reserves the following two:

    0x00000000 - 0x0000FFFF
    0xFFFF0000 - 0xFFFFFFFF

Can you elaborate on whether IOS XR treats RFC1997 values from those
ranges in a special way? (aside from the well known communities
ofcourse)

Kind regards,

Job

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 3 Oct 2016 17:12:20 +0000

An implementation may give you a match condition for reserved range. I haven't (yet). Private AS has 2 ranges. The match for that is still on my todo list. If it were one range, then it would be done.

One range please.

Thanks,
Jakob.

> On Oct 3, 2016, at 9:57 AM, Job Snijders <[email-masked]> wrote:
>

---

From: heasley <[email-masked]>
Date: Mon, 3 Oct 2016 18:42:16 +0000

> An implementation may give you a match condition for reserved range. I haven't (yet). Private AS has 2 ranges. The match for that is still on my todo list. If it were one range, then it would be do…

they aren't arbitrary ranges - they are the reserved ASNs.  Why is it
difficult to match if (field1 == (0|0xffff|0xffffffff))?

---

From: Brian Dickson <[email-masked]>
Date: Mon, 3 Oct 2016 14:25:24 -0700

On Mon, Oct 3, 2016 at 11:42 AM, heasley <[email-masked]> wrote:

> > An implementation may give you a match condition for reserved range. I
> haven't (yet). Private AS has 2 ranges. The match for that is still on my
> todo list. If it were one range, then it would be done.
> >
> > One range please.
>
The problem with *not* reserving all 3 is this: there may be, in future, a
new set of "Well-Known Large Communities".

The (best or feasible) choice(s) of WHICH of the 3 reserved values should
get used as the range containing WKLCs (and here I presume one of the three
MUST be the place for WKLCs), could depend on some number of factors not
known to us at this time.

If we attempt to make that decision now, based on zero information about
possible unseen consequences, our future selves (or our successors) might
be very unhappy.

Reserving all 3 (but not requiring any action on those reservations, per
se) costs nothing, and leaves all 3 open for future use as WKLCs.

Reserving all 3 does, however, warn off operators from using any of those,
so they don't get some later surprise when an implementation starts
interpreting WKLCs that happen to conflict with what the operator has been
using.

It is anticipatory principal of least astonishment.

> > > of course)

I think this illustrates the problem quite well.
It may not be the case that all implementations prevent some operator from
using an RFC1997 community in a non-conformist way.
But if the operator does use such a community, and unexpected (to that
operator) things happen, well, "caveat emptor".

It would be nice if implementations provided warnings, or even prevented
people from shooting themselves in <body part>.
It isn't strictly necessary, and as long as the RFCs provide enough
warnings against doing so, that's probably enough.

ICANN/IANA only provide the regulatory frameworks for the public Internet;
there are other "internets" that exist, where re-use of assigned IP
addresses (outside of RFC1918) is a non-issue.
(And only so long as the networks involved do not attempt to interconnect
with "the Internet".)

But, where the intent is that the first 32-bit value is "the public ASN" of
the operator (and this should be the case for any Internet-announced NLRIs
with this new attribute), we should warn off any "off-label" use.
E.g. advise on the "private use ASNs" available, and on the "reserved
values".

That's my $0.02.

Brian

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 Oct 2016 17:29:33 -0400

> On Oct 3, 2016, at 5:25 PM, Brian Dickson <[email-masked]> wrote:
> 
> 
> Reserving all 3 does, however, warn off operators from using any of those, so they don't get some later surprise when an implementation starts interpreting WKLCs that happen to conflict with what the operator has been using.
> 

I wish.  (Says the vendor guy dealing with people using 0:* and 65535:* and having "weirdness".)

-- Jeff

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Mon, 3 Oct 2016 21:30:36 +0000

Fine. It's not that important anyway.

Thanks,
Jakob.

From: Brian Dickson [mailto:[email-masked]]
Sent: Monday, October 03, 2016 2:25 PM
To: heasley <[email-masked]>
Cc: Jakob Heitz (jheitz) <[email-masked]>; [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

On Mon, Oct 3, 2016 at 11:42 AM, heasley <[email-masked]<mailto:[email-masked]>> wrote:

> Thanks,
> Jakob.
>
> > On Oct 3, 2016, at 9:57 AM, Job Snijders <[email-masked]<mailto:[email-masked]>> wrote:
> >

The problem with *not* reserving all 3 is this: there may be, in future, a new set of "Well-Known Large Communities".

The (best or feasible) choice(s) of WHICH of the 3 reserved values should get used as the range containing WKLCs (and here I presume one of the three MUST be the place for WKLCs), could depend on some number of factors not known to us at this time.

If we attempt to make that decision now, based on zero information about possible unseen consequences, our future selves (or our successors) might be very unhappy.

Reserving all 3 (but not requiring any action on those reservations, per se) costs nothing, and leaves all 3 open for future use as WKLCs.

I think this illustrates the problem quite well.
It may not be the case that all implementations prevent some operator from using an RFC1997 community in a non-conformist way.
But if the operator does use such a community, and unexpected (to that operator) things happen, well, "caveat emptor".

It would be nice if implementations provided warnings, or even prevented people from shooting themselves in <body part>.
It isn't strictly necessary, and as long as the RFCs provide enough warnings against doing so, that's probably enough.

ICANN/IANA only provide the regulatory frameworks for the public Internet; there are other "internets" that exist, where re-use of assigned IP addresses (outside of RFC1918) is a non-issue.
(And only so long as the networks involved do not attempt to interconnect with "the Internet".)

But, where the intent is that the first 32-bit value is "the public ASN" of the operator (and this should be the case for any Internet-announced NLRIs with this new attribute), we should warn off any "off-label" use.
E.g. advise on the "private use ASNs" available, and on the "reserved values".

That's my $0.02.

Brian

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 05 Oct 2016 16:16:07 +0100

>     in [RFC4360], and the Large BGP Community is handed as specified in

There are two germane issues when there are multiple types of
communities attached to a route: exclusivity and precedence.

For exclusivity, the issue is whether you can you attach a large bgp
community to a prefix as well as an another type of community. It would
be so bizarre an idea to suggest you couldn't do this that it doesn't
even need to be mentioned that it's legit. If the document doesn't
mention exclusivity, the only possible interpretation is that it must be
permitted.  TBH it would be rather peculiar to even mention that it's
ok, almost as if these new large bgp communities were the new cool kids
on the block and they're like totes ok co-existing with other types of
communities that have been around for ages.  It's faintly ridiculous.

Precedence must a locally defined issue because anything else would
result in an enormous bunfight about whose BGP Communities rfc was the
biggest and most important.  Again, it is better not to say anything
here, because if nothing is said, then the ietf is not making any
judgements about how to interpret community values, which is fully
consistent with how communities have always been interpreted in the past.

This paragraph should be omitted completely. It adds nothing.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Oct 2016 11:46:06 -0400

> On Oct 5, 2016, at 11:16 AM, Nick Hilliard <[email-masked]> wrote:
> 

I agree.

To the authors:
Other things I note while reading the draft:
"   Global Administrator:  A four-octet namespace identifier.  This
      SHOULD be an Autonomous System Number assigned by IANA."
delete "assigned by IANA".  That's not usually their business.

Similarly, I find the following sentence adds no value:
"   There are no routing semantics implied by the Global Administrator
   field."

I am also unclear on the semantics of why atomic aggregate impacts whether merging happens or not.
(Please don't make me break out 10+ year old points as to why AA has been broken from day one.)

I'll reiterate my objection to a mandatory representation format, but other implementations that actually are impacted will make my point for me.  Unless we're doing a yang module, IETF really has no business specifying UI.

With regard to the security considerations, I'd drop the "and BGP Extended Communities".  While the generic ext-comms draft originally passed through IETF process with its somewhat weak session, I think any practical security analysis of it would point out that the signaling information covered by ext-comms is significantly greater than the base 1997 case these days.

Similarly, I'd drop "trust in every other AS in the path" section.  If you're going to dig into that issue, you'll end up in a world of security considerations hurt.  You still will courtesy of the way our security ADs function with their odd understanding of how protocol work and operations collide, but you're almost always better off starting with too little and let them guide you into what they want to see than give them fodder for confusion early on.

-- Jeff

---

From: Job Snijders <[email-masked]>
Date: Wed, 5 Oct 2016 18:17:41 +0200

> > This paragraph should be omitted completely. It adds nothing.

Nick, Jeff, thank you for your feedback. I've deleted the section from
what will be -02.

> "Global Administrator:  A four-octet namespace identifier.  This

agreed.

> "There are no routing semantics implied by the Global Administrator
> field."

This sentence was already deleted following feedback from Tom Petch
(https://mailarchive.ietf.org/arch/msg/idr/GF4yLYbWltrj8rKNtdPk1xxexv8)

Thanks for seconding the removal.

> I am also unclear on the semantics of why atomic aggregate impacts
> whether merging happens or not.  (Please don't make me break out 10+
> year old points as to why AA has been broken from day one.)

I'll leave this for others to comment on.

> I'll reiterate my objection to a mandatory representation format, but
> other implementations that actually are impacted will make my point
> for me.  Unless we're doing a yang module, IETF really has no business
> specifying UI.

There are more examples where the IETF (for better or for worse) has
specified canonical representations. For example, I'd be disappointed if
a major implementation ends up representing Large BGP Communities as
straight uint96_t's in the UI.

A challenge here is that there might be two issues at hand: one is the
canonical way to represent a Large BGP Community in a phone call, or in
technical documentation which is provided by one operator to another
operator. The second issue is what is actually typed/inputted into
network element configurations.

The "Textual Representation" section should provide any implementor with
enough freedom to use a prefix, suffix, or a separator of their
choosing. Given the current text:
https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community.xml#L208-L232
should we change the first three "MUST" to a "SHOULD" to alleviate your
concern?

Do you consider my concern about a canonical format for inter-operator
communication valid?

> With regard to the security considerations, I'd drop the "and BGP
> Extended Communities".  While the generic ext-comms draft originally
> passed through IETF process with its somewhat weak session, I think
> any practical security analysis of it would point out that the
> signaling information covered by ext-comms is significantly greater
> than the base 1997 case these days.

You make a fair point, I have removed that string (unless someone
champions that it should remain part of the draft).

> Similarly, I'd drop "trust in every other AS in the path" section.  If
> you're going to dig into that issue, you'll end up in a world of
> security considerations hurt.  You still will courtesy of the way our
> security ADs function with their odd understanding of how protocol
> work and operations collide, but you're almost always better off
> starting with too little and let them guide you into what they want to
> see than give them fodder for confusion early on.

To confirm, you propose to change;

	"This document does not change any underlying security issues
	associated with any other BGP Communities mechanism.  Specifically,
	an AS relying on the Large BGP Community attribute carried in BGP
	must have trust in every other AS in the path, as any intermediate
	Autonomous System in the path may have added, deleted or altered
	the Large BGP Community attribute. Specifying the mechanism to
	provide such trust is beyond the scope of this document."

to

	"This document does not change any underlying security issues
    associated with any other BGP Communities mechanism."

correct?

I can agree to this simplification. The text was put in as an attempt to
preempt some security review scrutinity. It continues to be a challenge
to figure out how far one should go to scope expecations, and when to
write down something is out of scope, or not. Feedback from others on
this specific topic is most welcome, if case no further feedback offered
I'll remove that part of the section as per Jeff's recommendation.

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 05 Oct 2016 17:43:46 +0100

Jeffrey Haas wrote:
> I'd drop the "and BGP Extended Communities".

you're correct on this on the grounds stated, i.e. there is no
widespread use of extcomms for inter-as signaling.

I added that line in there, and have an item on my todo list to get a
couple of lines of text together in the next couple of days to explain
in the Introduction section why extcomms are unsuitable for solving the
problem at hand.

The plan behind this was that when this draft goes through iesg review,
the first question that's going to be asked is: "pls explain why
extcomms won't work for your use case?", so given that that is likely to
precipitate a couple of lines of explanation, the secdir review will
then ask, "why didn't you mention extcomms in the security section when
you mentioned rfc1997 both here and in the intro?".

That, at least, was the rationale.  The thing about this draft is that
the principal is so easy to understand that a lot of people in the
review process are likely to want to bikeshed it.

So there are two options open regarding this:

1. omit everything about extcomms and face a likely barrage of nits from
post-wglc review, and also don't explain to posterity why they were
considered a non-viable solution to the problem at hand, or

2. put in an honorary mention of extcomms and in no more than a tiny
number of lines, explain why they are unsuitable.

I'd appreciate your input on this though.  If you think it's unnecessary
or counterproductive, that might save me word-whacking time which could
be productively spent tilting at other windmills.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 05 Oct 2016 17:44:44 +0100

> "   There are no routing semantics implied by the Global Administrator

+1, for same reason.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Oct 2016 14:02:18 -0400

> On Oct 5, 2016, at 12:17 PM, Job Snijders <[email-masked]> wrote:
> 

Some of your operational compatriots are quite happy to do decimal string character index operations already.  It wouldn't surprise me that at some point someone asks for 4:4:4 to be 4:8 to enable trickery.

Note: It's not been asked for. Yet.  But I have faith in customers asking after weird features.

> network element configurations.

I think the critical detail is already handled under section 2 of the draft: A large community is defined as 3 contiguous four octet values.  You want structure, you have enough of the document defining structure.  More importantly, the structured components have names: Global Admin, Local Data 1, Local Data 2.

Really, I think you're done.

> should we change the first three "MUST" to a "SHOULD" to alleviate your

First, you talk about implementations.  Again, it'll depend on the implementation as to whether they find this reasonable or not.  We've already had input on-list from those who do things differently.

If your concern is really just to have a useful way to talk about these things in a portable way:

"For documentation purposes, it is RECOMMENDED that BGP Large Communities be represented as three unsigned decimal numbers separated by the colon character;  <Global Administrator>:<Local Data 1>:<Local Data 2>.  E.g. 65551:100:0."

> Do you consider my concern about a canonical format for inter-operator

For communication, yes.  Conveniently, the recommendation also covers advice for those working on things like yang models.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Oct 2016 14:09:08 -0400

> On Oct 5, 2016, at 12:43 PM, Nick Hilliard <[email-masked]> wrote:
> 
> Jeffrey Haas wrote:

That'd be useful.  I mostly restricted my comments on the -01 draft on editorial corrections rather than reworking the introduction section.  

In particular, this draft really is mixing up two distinct issues:
1. Expanding to permit 4:4.  That case is worth explaining and ties into the point about why ext-comms are insufficient.
2. Why there's another :4.  If parity with 1997 was the only goal... well,you'd be overreaching.

I'm not arguing the Local Data 2 isn't useful.  But it's a non-sequitir in the line of logic presented.

> be productively spent tilting at other windmills.

My opinion is that there will be last minute security considerations flailing regardless of what we do.  Thus, save your sanity for later.

But to clarify why a "teaser" pointer to ext-comms is problematic, you need to be very clear about the syntactic space issues for ext-comms not being sufficient (it's not big enough!) vs. the semantic ones.  Once a security AD digs into the semantics of defined ext-comms and its impact on forwarding and thinks (erroneously) that the same blanket consideration may apply to Large, you'll have lost a week of your life.  Keep it simple (syntax/PDU) and clean.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 5 Oct 2016 14:15:15 -0400

> https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community.xml#L208-L232 <https://github.com/large-bgp-communities/large-bgp-communities/blob/master/draft-ietf-idr-large-community.xml#L208-L232>

Minor nit: RFC 1997 never uses colon-format.  1998 does.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 05 Oct 2016 20:24:20 +0100

Jeffrey Haas wrote:
> Once a security AD digs into the semantics of defined ext-comms and
> its impact on forwarding and thinks (erroneously) that the same
> blanket consideration may apply to Large, you'll have lost a week of
> your life.  Keep it simple (syntax/PDU) and clean.

yeah, I had to abandon the first two attempts to get the wording right
on this one.

Nick

---

From: Job Snijders <[email-masked]>
Date: Thu, 6 Oct 2016 19:27:38 +0200

Hi Group,

Section 3 currently is as following:

	"""
    3.  Aggregation

    If a range of routes is aggregated and the resulting aggregates
    attribute section does not carry the ATOMIC_AGGREGATE attribute,
    then the resulting aggregate should have a Large Communities path
    attribute which contains all of the large communities from all of
    the aggregated routes.
    """

Jeff made the following comment:

> year old points as to why AA has been broken from day one.)

Are you asking whether the aggregate is a merge/union of the
contributors in case the ATOMIC_AGGREGATE is absent?

The text was inspired by RFC4360:

    """
    6.  Operations
    <snip>

    By default if a range of routes is to be aggregated and the
    resultant aggregates path attributes do not carry the
    ATOMIC_AGGREGATE attribute, then the resulting aggregate should have
    an Extended Communities path attribute that contains the set union
    of all the Extended Communities from all of the aggregated routes.
    The default behavior could be overridden via local configuration, in
    which case handling the Extended Communities attribute in the
    presence of route aggregation becomes a matter of the local policy
    of the BGP speaker that performs the aggregation.
    """

Should a variant of this RFC4360 text be included in the Large BGP
Communities specification? Or is ATOMIC_AGGREGATE dead and should
section 3 just be removed?

Kind regards,

Job

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 6 Oct 2016 14:52:30 -0400

> On Oct 6, 2016, at 1:27 PM, Job Snijders <[email-masked]> wrote:
> 

To be clear, the above statement is largely fine modulo the atomic_aggregate comment.

I'm even fine with a simple cut and paste with appropriate substitutions from 4360, but think that at this point atomic_aggregate is largely just a dead thing.  Considering it just complicates matters unnecessarily.

-- Jeff

---

From: t.petch <[email-masked]>
Date: Fri, 7 Oct 2016 11:26:15 +0100

----- Original Message -----
From: "Nick Hilliard" <[email-masked]>
To: "Job Snijders" <[email-masked]>
Cc: "t.petch" <[email-masked]>; <[email-masked]>
Sent: Monday, October 03, 2016 4:46 PM

Nick

It is a global administrator field:-)  That is, it defines a namespace
within which the following data can be interpreted.  If the value is not
unique, as ASN are, then the following data cannot be reliably
interpreted and we are letting loose we do not know what on the
Internet.

A case study of how not to do this is MPLS which took a very narrow view
of its namespace which has led to a lot of subsequent work in order to
get round it, for example depending on the bit patterns of IP Version
numbers, and other possible first nibbles.  If MPLS had thought further
ahead, and nailed down its namespaces, then a lot of effort would have
been obviated.

Communities are not quite as important as MPLS but I still have a
concern, that if we allow anything into that first field, then we are
creating an untenable situation some time in the future.

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

Today, I think we would /shall/MUST/

Here, I would go for 'MUST be an ASN' (or else the community should not
be transitive:-)

Tom Petch

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 07 Oct 2016 12:48:13 +0100

Tom,

> Here, I would go for 'MUST be an ASN' (or else the community should not

Every 32 bit number is an ASN, so there's an argument to say that this
is a tautology.

I don't think it's either viable or necessary to narrow down the text to
specify that the global administrator field MUST be the ASN of the
operator who assigns the community to the prefix.

The reason for this is that if large communities are used for inter-as
signaling, operators should only act at the edge router when the global
administrator field matches the peer-as, and if they need to interpret
the community tag further inside the network, they should use a
translation layer to map the semantics to a locally significant
community (i.e. the same as what we do for rfc1997 communities).  For
intra-as signaling, it doesn't matter because it's local semantics only.
 Either way, there is no compelling reason that this should be a MUST
and good reasons (e.g. operator discretion) that it shouldn't.

Nick

---

From: heasley <[email-masked]>
Date: Fri, 7 Oct 2016 16:24:12 +0000

> operator who assigns the community to the prefix.

Agreed.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 7 Oct 2016 19:12:46 +0000

I took the ATOMIC_AGGREGATE text from RFC1997. ATOMIC_AGGREGATE means that information was lost. In that case, you are free to put whatever communities you want. I can remove the ATOMIC_AGGREGATE text, such that the aggregation SHOULD be done in the specified way even when ATOMIC_AGGREGATE is present.

Any objections?

Thanks,
Jakob.

> On Oct 6, 2016, at 11:52 AM, Jeffrey Haas <[email-masked]> wrote:
> 
>

---

From: Brian Dickson <[email-masked]>
Date: Fri, 7 Oct 2016 14:37:00 -0700

Sent from my iPhone

> On Oct 7, 2016, at 4:48 AM, Nick Hilliard <[email-masked]> wrote:
> 
> Tom,
> 
> t.petch wrote:

Let us leave the straw man alone, please. :-)

> community (i.e. the same as what we do for rfc1997 communities).

No.

You are making the erroneous assertion that the way you think these communities should be used, is the only correct way or the only common way they should be (or will be) used.

For 1997 communities (both the year as well as the RFC), inter-as was not limited to adjacent ASNs.

This is why large needs to be transitive as well as globally unique for the global administrator - i.e. ASN.

>  For

Local semantics are fully supported by use of (agreed upon) private ASNs.

Those are also consistent with the strong assertion of MUST, as well as both the letter and intent of what is meant by ASN.

Is there anything you envision in use of large communities that cannot be supported by use of ASNs and private ASNs? I can't see anything that would not fit into those two use cases.

Brian

---

From: Job Snijders <[email-masked]>
Date: Sat, 8 Oct 2016 11:24:53 +0200

On Wed, Oct 05, 2016 at 02:15:15PM -0400, Jeffrey Haas wrote:
> > The "Textual Representation" section should provide any implementor
> > with enough freedom to use a prefix, suffix, or a separator of their
> > choosing. 
> 

Hi Jeff,

RFC 1997 defines BGP Communities, which is the intended reference here.

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 08 Oct 2016 17:35:15 +0100

Brian Dickson wrote:
> Is there anything you envision in use of large communities that
> cannot be supported by use of ASNs and private ASNs? I can't see
> anything that would not fit into those two use cases.

There are plenty of situations where the semantics of what you're
suggesting would be troublesome to define, for example, confederations,
asn translation or asn migration, leading to cases where there would be
multiple asns being legitimate on a single router.

And even if these cases could be cleared up easily, what happens when
someone injects a prefix tagged with a community which isn't the same as
their ASN?  You're then stuck with the situation where you're defining
one thing as a MUST in the semantic specification section of the rfc,
while down in the Security Considerations section, it's going to need to
be admitted that there's no guarantee whatsoever that the global
administrator field in the large community was actually set by the ASN
which announced the prefix.  Worse still, once it's been changed, there
is no practical way for a neighbor to detect this change, as s-bgp isn't
a thing.

Realistically, vendors are going to implement ways of modifying the
field in exactly the same way as rfc1997 communities can be set to
anything at all at any policy specification point in a bgp-enabled network.

Nick

---

From: "i3D.net - Martijn Schmidt" <[email-masked]>
Date: Sat, 8 Oct 2016 19:37:56 +0200

Let's say I am AS49544 and I need to transmit a prepend instruction to
AS2914, I would add 2914:3320:2 or 2914:2:3320 or similar on my prefix.
Why is it important to allow me to specify any value in the Global
Administrator field? Well,

1) If we did REQUIRE people to use their own ASN when adding a new
community on a prefix, we'd essentially be back to the same amount of
opaque space as in RFC1997 (e.g. two fields, not three). This also
brings back the collision problem which we were trying to tackle, both
AS2914 and AS3356 might decide to act on a community tag like 49544:2:3320.

2) The actor ASN already knows who could have set the community tag
thanks to the AS_PATH, using a field in the large community tag to make
it aware of that might be considered as redundant information.

3) Using the first field to specify the ASN which needs to take the
action makes it quite easy for an operator to ignore any large community
tags which are intended to signal something to a 3rd party. This allows
for transitive instructions in cases where one doesn't have a direct
adjacency with the target ASN; quite useful for downstream customers of
a tier-2 network which are trying to trigger an action in that network's
upstream provider.

Informational communities are another matter - that's where an operator
SHOULD use their own ASN in the Global Administrator field. However
there is no (technical) difference between an informational and an
action community - just semantics - so we can't really specify such
restrictions in the draft.

Best regards,
Martijn

---

From: Brian Dickson <[email-masked]>
Date: Sat, 8 Oct 2016 13:14:12 -0700

Sent from my iPhone

> On Oct 8, 2016, at 9:35 AM, Nick Hilliard <[email-masked]> wrote:
> 
> Brian Dickson wrote:

The operator setting the community would need to know the intended semantics. The other operator would need to establish what acceptable communities could be used and the corresponding semantics.

The operator doing anything complicated will already need to understand the ASN gymnastics; the corresponding communities follow those same gymnastics.

> their ASN?  

I said ASN. I didn't say THEIR ASN.

That is the apparent disconnect.

Nothing should enforce what ASN value is used.

> You're then stuck with the situation where you're defining
> which announced the prefix.

Correct. That is the intended behavior.

The ASN value will rarely be the ASN setting the community. The cases where the sender uses its own ASN can already be handled with extended communities.

>  Worse still, once it's been changed, there

Yes, and this is the desired state of affairs. Complete parity with 1997.

Brian

---

From: t.petch <[email-masked]>
Date: Sun, 9 Oct 2016 10:55:24 +0100

--- Original Message -----
From: "Brian Dickson" <[email-masked]>
To: "Nick Hilliard" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, October 08, 2016 9:14 PM
> The operator setting the community would need to know the intended
semantics. The other operator would need to establish what acceptable
communities could be used and the corresponding semantics.
>
> The operator doing anything complicated will already need to
understand the ASN gymnastics; the corresponding communities follow
those same gymnastics.
> I said ASN. I didn't say THEIR ASN.

That is what I intended, although it has not been construed as such.

There is nothing IMHO in
'   Global Administrator:  A four-octet namespace identifier.  This
      MUST be an Autonomous System Number assigned by IANA.'
which says whose ASN it is, just that it must be an ASN; if you allow
IPv4 addresses, Router ID, IGP Area numbers and so on, anything else
that fits into 32 bit, then it all breaks down so it MUST be an ASN.  At
a stretch, that wording includes private ASN since those values are
assigned by IANA although we might want to point that out explicitly.

And as Brian says, security is something else.  Anyone can forge anyone
else's ASN in there, but that is possible with other BGP data (in the
absence of SIDR or some such) so the security needs careful
consideration.

Tom Petch

> The ASN value will rarely be the ASN setting the community. The cases
where the sender uses its own ASN can already be handled with extended
communities.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sun, 9 Oct 2016 21:55:32 +0000

Router software will not treat an UPDATE message as malformed
if the Global Administrator field of a Large Community does not contain an ASN.
It doesn't even know that it's an ASN. It's just 32 bits.

I don't think we can or should specify anything stronger than:

A receiving BGP speaker is permitted to remove unexpected
Large Communities from received routes. 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 Commuinties, the meaning
of each being defined by different independent entities.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of t.petch
> Sent: Sunday, October 09, 2016 2:55 AM
> To: Brian Dickson <[email-masked]>; Nick Hilliard <[email-masked]>
> Cc: [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 10 Oct 2016 00:34:02 +0100

> assigned by IANA although we might want to point that out explicitly.

There's something I'm not getting here in this discussion.

Let's step back a bit and start with a principal:  "if a policy cannot
be enforced, it is bad policy".

There is no way a priori for a router to have knowledge of what ASNs
have or have not been assigned, either by IANA or any other assignment body.

If a standards track document is created which mandates that a specific
identifier field "MUST" contain a ASN assigned by IANA, there is no
practical way for another router to check this.  Because the MUST cannot
be checked or enforced in any meaningful way, a formal requirement of
this form automatically falls into the realm of bad policy.

The best option here is - as Brian noted - to align with 1997 semantics
and make a recommendation to operators that the global administrator
field should be an ASN, and to stay well clear of attempting to define
what an ASN is, or is not. Operators are adults and will do what works
for them; there's no need to be over-prescriptive.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 10 Oct 2016 08:18:30 +0200

Hi Nick,

It is not true ...

Bgp origin validation shipping for a long time does contain both assigned
AS numbers as well as mappings to the prefixes which should be originated
with such AS numbers.

So technically there is an easy way to enforce it in any place in the
network.

Now should it be enforced or not it's a different debate.

Personally I do not think so. As discussed previously any field can be
overloaded so locking any field of large comms to any specific semantics of
the value it is to carry would be limiting its flexibility.

Thx
R.

On Oct 10, 2016 01:34, "Nick Hilliard" <[email-masked]> wrote:

Nick

---

From: Gert Doering <[email-masked]>
Date: Mon, 10 Oct 2016 08:52:40 +0200

Hi,

> of each being defined by different independent entities.

This matches how I understand people's intention to use these.  

So, works for me.

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: Mon, 10 Oct 2016 08:53:17 +0200

Hi,

> AS numbers as well as mappings to the prefixes which should be originated

It could, but it doesn't.  Out there, in the real world.

Gert Doering
        -- NetMaster

---

From: Job Snijders <[email-masked]>
Date: Mon, 10 Oct 2016 14:17:48 +0200

Hi all,

On Sun, Oct 09, 2016 at 09:55:32PM +0000, Jakob Heitz (jheitz) wrote:
> Router software will not treat an UPDATE message as malformed if the
> Global Administrator field of a Large Community does not contain an
> ASN. It doesn't even know that it's an ASN. It's just 32 bits.

^^ exactly. It is just 32 bits. This discussion is taking a strange
turn.

> """A receiving BGP speaker is permitted to remove unexpected Large
> Communities from received routes. 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.
> of each being defined by different independent entities."""

I think this text introduces more problems then it solves. What defines
an 'unexpected' community? If Large communities can be deleted, does
that mean that other types of communities cannot be deleted?  We've had
20 years of communities and to me it is entirely redundant to specify
that you can delete a community.

The term "Global Administrator" is well understood through years of use
and precedent, I dont understand why this suddenly is a problem. We
should just stick with the current text.

Kind regards,

Job

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 10 Oct 2016 13:21:48 +0100

> of each being defined by different independent entities.

This is all redundant text.

Reality demands that we should be able to add or remove communities.
Common sense demands that if we intend a community value to be
interpreted by multiple external ASNs, then it should be set to an ASN
that we have some claim to because if it isn't, then it is likely to be
be stripped off at the ASN border.  The protocol specification already
states that "the attribute consists of one or more 12-octet values".

The document currently says:

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

2. "Implementations MUST allow the operator to specify any value for the
Global Administrator field"

We don't need anything more than this.  Less is more.

Nick

---

From: t.petch <[email-masked]>
Date: Tue, 11 Oct 2016 10:29:09 +0100

----- Original Message -----
From: "Nick Hilliard" <[email-masked]>
Sent: Monday, October 10, 2016 12:34 AM

Nick

I am probably still not being clear.  I think that 'assigned by IANA' is
a distraction.  My concern is with
'SHOULD be an ASN'

'SHOULD' means it need not be so some router manufacturer in response to
some customers' requests at some time in the future sees a completely
different use for it and puts in a 32-bit value from a different
namespace which may well have the same bit pattern as the ASN of one of
your peers.

You receive such a community and cannot tell, from the protocol, how to
interpret this 32 bit value, whether or not it is an ASN.  And if you
cannot do that, you cannot interpret the rest of the field safely.

The only thing you can do is see where it came from, which, being a
transitive attribute, you again cannot reliably do from the protocol.
So
you have to start ringing around your peers, who created this community,
is that an ASN or not?

Um.

I want a MUST in there so if anyone does otherwise, we can say No!, not
allowed.

I take your point about the lack of enforcement but that is true of
everything the IETF does.  We have no Internet police; if there is a bad
actor, then it is up to peer pressure to get them to change.  (And if
the bad actor dominates the market, then may be it is the IETF that
changes:-(

Tom Petch

---

From: Peter Hessler <[email-masked]>
Date: Tue, 11 Oct 2016 11:54:17 +0200

On 2016 Oct 11 (Tue) at 10:29:09 +0100 (+0100), t.petch wrote:
:----- Original Message -----
:From: "Nick Hilliard" <[email-masked]>
:Sent: Monday, October 10, 2016 12:34 AM
:
:> t.petch wrote:
:> > There is nothing IMHO in
:> > '   Global Administrator:  A four-octet namespace identifier.  This
:> >       MUST be an Autonomous System Number assigned by IANA.'
:> > which says whose ASN it is, just that it must be an ASN; if you
:allow
:> > IPv4 addresses, Router ID, IGP Area numbers and so on, anything else
:> > that fits into 32 bit, then it all breaks down so it MUST be an ASN.
:At
:> > a stretch, that wording includes private ASN since those values are
:> > assigned by IANA although we might want to point that out
:explicitly.
:>
:> There's something I'm not getting here in this discussion.
:>
:> Let's step back a bit and start with a principal:  "if a policy cannot
:> be enforced, it is bad policy".
:>
:> There is no way a priori for a router to have knowledge of what ASNs
:> have or have not been assigned, either by IANA or any other assignment
:body.
:>
:> If a standards track document is created which mandates that a
:specific
:> identifier field "MUST" contain a ASN assigned by IANA, there is no
:> practical way for another router to check this.  Because the MUST
:cannot
:> be checked or enforced in any meaningful way, a formal requirement of
:> this form automatically falls into the realm of bad policy.
:>
:> The best option here is - as Brian noted - to align with 1997
:semantics
:> and make a recommendation to operators that the global administrator
:> field should be an ASN, and to stay well clear of attempting to define
:> what an ASN is, or is not. Operators are adults and will do what works
:> for them; there's no need to be over-prescriptive.
:
:Nick
:
:I am probably still not being clear.  I think that 'assigned by IANA' is
:a distraction.  My concern is with
:'SHOULD be an ASN'
:
:'SHOULD' means it need not be so some router manufacturer in response to
:some customers' requests at some time in the future sees a completely
:different use for it and puts in a 32-bit value from a different
:namespace which may well have the same bit pattern as the ASN of one of
:your peers.
:
:You receive such a community and cannot tell, from the protocol, how to
:interpret this 32 bit value, whether or not it is an ASN.  And if you
:cannot do that, you cannot interpret the rest of the field safely.
:

That's correct!  and by design.

Section 1:

   To address these shortcomings, this document defines a Large
   Community BGP Attribute encoded as one or more 12-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.

Section 2:
   The Global Administrator field is intended to allow different
   Autonomous Systems to define Large Communities without collision.
   Implementations MUST allow the operator to specify any value for the
   Global Administrator field.

The vendor is NOT allowed to squat on the GA field.

:The only thing you can do is see where it came from, which, being a
:transitive attribute, you again cannot reliably do from the protocol.
:So
:you have to start ringing around your peers, who created this community,
:is that an ASN or not?
:

The entire large-community attribute is opaque, and only has meaning to
the entity that created it.  Inferring your own meaning from it can't
work.

:Um.
:
:I want a MUST in there so if anyone does otherwise, we can say No!, not
:allowed.
:

As an implementor, we MUST NOT use a MUST here. ;)

Putting my own ASN, or the ASN of my peer that I wish to control, will
be the main uses; I agree.  But there is a difference between SHOULD and
MUST.  Since I MUST allow users to change the value there, I am happy.

-- 
In specifications, Murphy's Law supersedes Ohm's.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 11 Oct 2016 12:09:42 +0100

> I want a MUST in there so if anyone does otherwise, we can say No!, not

If an operator in the far depths of inner Kaboodlestan uses an IPv4
address instead of an ASN, the IETF can disapprove all it wants, and it
will make no difference to anyone.

For inter-as signaling, no-one is going to accept anything other than an
ASN, but even if they do, it doesn't matter that much.  Communities are
not redistributed by default on ebgp sessions, and when they are, the
normal operation is to strip off anything not related to the next-hop
ASN.  So in practice, the distribution radius for most communities
mappings tends to be quite small.

Nick

---

From: Ben Maddison <[email-masked]>
Date: Tue, 11 Oct 2016 11:30:34 +0000

Hi all,

I'm rather struggling to see the point of this debate. There is a thing about ducks that comes to mind ("if it walks like an ASN...").

Surely what we're really concerned with is on the receiving/interpreting end, where (in the inter-AS scenario) the authority responsible of assigning meaning to a large-comm of the form 64500:X:Y is expected to be the operator of AS64500.

This is already clear to me from section 2:
	"The Global Administrator field is intended to allow different
   	Autonomous Systems to define Large Communities without collision"

Nick is entirely correct that this intention is not enforceable in any meaningful way, so I really don't think it is worth spending additional time and energy defining it more narrowly.

Cheers,

Ben Maddison

Director
Workonline Communications (Pty) Ltd

Office:     +27 (0) 21 200 9000
Mobile:   +27 (0) 82 415 5545
Email:      [email-masked]
SIP:          [email-masked]

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Tuesday, October 11, 2016 1:10 PM
To: t.petch <[email-masked]>
Cc: idr <[email-masked]>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

t.petch wrote:
> I want a MUST in there so if anyone does otherwise, we can say No!, 
> not allowed.

If an operator in the far depths of inner Kaboodlestan uses an IPv4 address instead of an ASN, the IETF can disapprove all it wants, and it will make no difference to anyone.

For inter-as signaling, no-one is going to accept anything other than an ASN, but even if they do, it doesn't matter that much.  Communities are not redistributed by default on ebgp sessions, and when they are, the normal operation is to strip off anything not related to the next-hop ASN.  So in practice, the distribution radius for most communities mappings tends to be quite small.

Nick

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 Oct 2016 10:07:51 -0400

> On Oct 11, 2016, at 7:09 AM, Nick Hilliard <[email-masked]> wrote:
> 
> t.petch wrote:

Somewhat relevant example in other extensions:
Many implementations treat an add-paths path-id as an integer and you tend to see them showing up as a int in show commands.

At least one implementation chose to use a BGP identifier/IP address in theirs.

The spec treats the value opaquely.  Both use cases make sense in their own context.

End of the day, the protocol cares that it's a 4 byte value.  Users may want a given representational syntax because it makes their life easier in their particular scenario.

Neither is solely the Right Thing.

-- Jeff

---

From: Brian Dickson <[email-masked]>
Date: Tue, 11 Oct 2016 15:02:57 -0700

Top-reply for clarity.
Apologies if doing so offends anyone.

Here's the rationale for MUST (vs SHOULD):
- there is NO difference in what implementations need to do
- there IS a difference in what operators are able to do if/when collisions occur 

What I believe Tom was trying to articulate is this:

If some sends Large communities which start with HIS_ASN, he needs this MUST to use as a clue-by-four in communicating with the offending party.

If it is only a SHOULD, it removes the only tool available with which to apply pressure. 

(Do the math on the odds of unsigned 32-bit integers above 132K from different number spaces colliding, if those number spaces are not sparsely populated, and assigned in a sequential manner. The odds are "1, eventually".)

Squatting on assigned number resources is a horrible thing to deal with. I personally have had an IPv4 prefix squatted on, and that was something where things were significantly impacted.

It is not likely to happen, and if it does, it is very likely not malicious. However, without this MUST, the usefulness of Large communities are potentially impacted.

Please, let us have the MUST.

It has no impact to implementers, and a huge benefit to operators.

Brian

Sent from my iPhone

> On Oct 11, 2016, at 7:07 AM, Jeffrey Haas <[email-masked]> wrote:
> 
>

---

From: heasley <[email-masked]>
Date: Tue, 11 Oct 2016 22:15:44 +0000

> - there IS a difference in what operators are able to do if/when collisions occur 

which is nothing.  there is no enforcement.

leave it alone.

---

From: Gert Doering <[email-masked]>
Date: Wed, 12 Oct 2016 11:05:50 +0200

Hi,

> If some sends Large communities which start with HIS_ASN, he needs this MUST to use as a clue-by-four in communicating with the offending party.

But that is easily solved today by a) commercial arrangements, and b) filters.

If someone tags a community with 5539:xxx today, which might or might not
have any meaning inside my AS, 5539, I will only accept this community from
BGP peers that have a corresponding commercial relationship (typically,
customers, that are allowed to influence "announce-here", "prepend-there",
etc.).

>From anyone else, I will not accept 5539:x communities.

Should I care if anyone else out there (40000+ networks) is using 5539:xx
for something else?  Should I act?  Why?

> Squatting on assigned number resources is a horrible thing to deal with. I personally have had an IPv4 prefix squatted on, and that was something where things were significantly impacted.

IPv4 prefixes have global significance.  Communities have not.

Gert Doering
        -- NetMaster

---

From: t.petch <[email-masked]>
Date: Wed, 12 Oct 2016 09:49:11 +0100

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
Sent: Tuesday, October 11, 2016 3:07 PM

>> I want a MUST in there so if anyone does otherwise, we can say No!,
not

Somewhat relevant example in other extensions:
Many implementations treat an add-paths path-id as an integer and you
tend to see them showing up as a int in show commands.

At least one implementation chose to use a BGP identifier/IP address in
theirs.

The spec treats the value opaquely.  Both use cases make sense in their
own context.

End of the day, the protocol cares that it's a 4 byte value.  Users may
want a given representational syntax because it makes their life easier
in their particular scenario.

<tp>
Jeff

True but not really germane to the point I keep making:-)

Your point is about representation, about how implementations may or may
not go beyond the RFC in what a user sees which is an interesting point
but not one that the relevant RFC says anything about (some RFC do
prescribe a display format).

On the other hand, the relevant RFC does contain a specific warning
about the local significance of the path identifier.  For
large-community, we are using a transitive attribute which, by
definition, has global significance, hence my concern.

Tom Petch
-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 12 Oct 2016 09:45:52 -0400

> which is nothing.  there is no enforcement.

This is one I have to agree with.  With respect, Brian, this is a point
where your desire is to encode operational (if not contractual) practice in
the protocol RFC.  I don't think that helps anyone.

Somewhat to Gert D.'s point later in-thread, part of the issue with
communities is that that are in-practice heavily scrubbed and tend not to be
transitive.  Part of this is the difficulty in determining who may have
injected something more than a single AS-hop away.

Arguably this was one of the motivations for doing scoping of attributes or
communities themselves: If the effective operational behavior is almost
always going to be AS-non-transitive, it'd be nice if the cleanup just
happens automagically.  Unfortunately people are rather enamored with their
existing cleanup mechanisms.

-- Jeff

---

From: heasley <[email-masked]>
Date: Wed, 12 Oct 2016 21:56:23 +0000

> existing cleanup mechanisms.

Please, no automatic clean-up.  A community may be 100% legitimately used
to affect a decision 2 or 3 AS-hops away and it is extremely useful.
Operators already know how to alter communities.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Oct 2016 00:08:44 +0200

I believe Jeff was talking about intelligent cleanup with sufficient
information embedded into community itself such that forwarding BGP speaker
can decide what to pass and what to drop
... not an unconditional blind drop.

However as I see the folks here - some say do not send anything over eBGP
unless explicitely permitted (and sorry but "send-community all" knob is
not at that level of granularity needed), some say send everything
everywhere.

To me this is a bit a conflict of interests which I am really not going to
be in the middle of.

Some say that standardizing, deployment, education of large communities
will take years. And in fact they are very correct. It will take that much
indeed.

That is why I believe the delta to add few more lines of code which Jakob
refused should be smashed by IDR WG in the interest of BGP as protocol and
we should all together as a WG produce a solution which scales to the
current needs as well as leaves some room for future extensions. That would
mean that the overall effort which vastly exceeds few lines of C would gain
much more value.

Acee stating that may be even wide comms could be progressed in the future
is very interesting in the light of his BGP IOS team mate stating in the
other thread that he will never implement those :)

Kind regards,
R.

---

From: heasley <[email-masked]>
Date: Wed, 12 Oct 2016 22:34:54 +0000

> ... not an unconditional blind drop.

I (we, I believe) do not want vendors to do anything automatic about
dropping/altering communities.  But, provide us all the tools to manipulate
them.

> will take years. And in fact they are very correct. It will take that much

I think you are speculating to push your drafts; you are certainly persistent.

I do not expect education to take much time at all.  I hope that standardizing
is swift - EOY.  And, I expect that we will see rapid adoption (deployment) in
some specific places; particularly exchanges with RSes.

---

From: Jay Borkenhagen <[email-masked]>
Date: Wed, 12 Oct 2016 18:45:44 -0400

> dropping/altering communities.  But, provide us all the tools to manipulate

I want the same thing that heas wants.  So yes: "we" is correct.

       	   	      	   		   Jay B.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 13 Oct 2016 00:46:28 +0200

> dropping/altering communities.  But, provide us all the tools to manipulate

​It's like asking vendors .. Dear vendor pls give me tools to unlock
rounded by design metal nut :) ​

> I think you are speculating to push your drafts; you are certainly

No .. not at all. I currently gave up on pushing wide or even common header
idea if you have not already noticed since large was accepted as WG doc. ​

> I do not expect education to take much time at all.

​Well I value your expectations however the personal experience educating
network community in Nanog, RIPE, APRICOT and many *NOGs proves me
otherwise. I think Job was right on the spot in his recent mail on the
estimate of the effort.

> I hope that standardizing
> ​ ​
> is swift - EOY.

​Sure.​

> And, I expect that we will see rapid adoption (deployment) in

​If you need large community for IXes then it is fine. To me real use of
BGP as protocol is a bit more then that.

Best,
R.

---

From: heasley <[email-masked]>
Date: Wed, 12 Oct 2016 23:34:45 +0000

> rounded by design metal nut :) ​

I do not understand that analogy.  Automatic dropping is like giving me
the toolbox full of tools but no key to unlock it. /)  btw, tools exist
to remove rounded nuts.

> idea if you have not already noticed since large was accepted as WG doc. ​

yes, you've stopped trying to block -large- for -wide-, but no operator
suggested that you stop pushing -wide- for the sake of -wide-.  I think
-wide- is a good idea.

> otherwise. I think Job was right on the spot in his recent mail on the

they know rfc1997; this is rfc1997+.  unless their vendor does something
silly with RPL features, where is the difficulty?

> BGP as protocol is a bit more then that.

I'm suggesting that there is a need there, a clear one with great benefit
to them (ie: incentive), and RSes have more flexibility to alter their
code and upgrade than others.

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 12 Oct 2016 19:43:49 -0400

> code and upgrade than others.

I think once -large- is in code from vendors it's easy to see rollout
happen where that sort of function is required... quickly. People will pick
up the code for their gear as they need this feature.

---

From: Julian Seifert <[email-masked]>
Date: Thu, 13 Oct 2016 00:10:55 +0000

Hi, 

> MUST.  Since I MUST allow users to change the value there, I am happy.

I totally agree and want to give support to the current wording in the draft.
" Global Administrator:  A four-octet namespace identifier.  This
      SHOULD be an Autonomous System Number assigned by IANA."

"Implementations MUST allow the operator to specify any value for the
   Global Administrator field."

The semantics of the value configured in the community is up to the operator and must not be 
enforced/assumed by the implementation. It makes sense to reserve certain values/prohibit their
use to prevent compatibility issues, keep special values for tests/documentation/checking and for well known communities
that might be defined later on, but don't force operators to only be allowed to configure iana assigned 
ASN values or force implementations to only allow configuration of  an ASN in the GA that is a configured ASN on
the specific router etc. 

Communities are great because of the ambiguity(sorry of not the correct term for what I want to  express)
The vast number of values I can configure with meaning only for me and parties I interact with) 
being too strict will greatly diminish the value they represent as a tool in operating networks. 
And would be contradictory to the operational need from which the draft arose. 

kind regards,

  Julian

---

From: t.petch <[email-masked]>
Date: Thu, 13 Oct 2016 09:54:33 +0100

----- Original Message -----
From: "Julian Seifert" <[email-masked]>
Sent: Thursday, October 13, 2016 1:10 AM

Hi,

> MUST.  Since I MUST allow users to change the value there, I am happy.

I totally agree and want to give support to the current wording in the
draft.
" Global Administrator:  A four-octet namespace identifier.  This
      SHOULD be an Autonomous System Number assigned by IANA."

The semantics of the value configured in the community is up to the
operator and must not be
enforced/assumed by the implementation. It makes sense to reserve
certain values/prohibit their
use to prevent compatibility issues, keep special values for
tests/documentation/checking and for well known communities
that might be defined later on, but don't force operators to only be
allowed to configure iana assigned
ASN values or force implementations to only allow configuration of  an
ASN in the GA that is a configured ASN on
the specific router etc.

Communities are great because of the ambiguity(sorry of not the correct
term for what I want to  express)
The vast number of values I can configure with meaning only for me and
parties I interact with)
being too strict will greatly diminish the value they represent as a
tool in operating networks.
And would be contradictory to the operational need from which the draft
arose.

<tp>

Julian

I believe I understand the need that you express but the BGP protocol
does not have the mechanics to express it!

You say
'configure with meaning only for me and parties I interact with'
but BGP has no such mechanism. As Jeff has already explained, an
optional attribute either gets dropped, which is unlikely to work with
route reflectors, or it gets passed on and this I-D chooses the option
that it gets passed on.  So a community that only you and your fellow
parties understand is let loose on the whole Internet where it is open
to misinterpretation by everyone else because, e.g., they are expecting
an ASN and are getting something else that is private to you.

And the remit of the IETF is to make the Internet as a whole work better
so in updating the specification of BGP, the IETF has to consider the
trade off of something that benefits you and the parties you interact
with versus the risk of causing some level of damage to the Internet.

Obviously, I hope, I am concerned about the damage; you gain, but
somewhere else across the globe, someone else's connectivity may fail.

Of course it is possible to define a more sophisticated system that
allows communities to go so far and no further but that is not the BGP
we have.

Tom Petch

kind regards,

  Julian
=

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 13 Oct 2016 10:13:43 -0400

> Operators already know how to alter communities.

Experience has shown that a lot of people are simply bad about cleaning up
their trash.  (And also how it was found that some particular bit of code
had a hash table poorly sized...)

This is really more an issue in the scope of VPN related (extended)
communities, but the analogy generally holds.

What I think is being missed in the conversation is just because something
has a scoping bit (i.e. AS-non-transitive), nothing stops you from using
policy to say "don't enforce it for *this* thing".  However, I think that
use case is a bit weaker once you move into the federated AS scoping case.

-----

I do want to make one partially orthogonal comment here:
A number of the highly opinionated operational folk that are participating
on IDR follow or set current best operational practices for dealing with
communities.  

However, you're not the only set of users of these features.

Forcing protocol feature sets to stay to your current strictures because
you've rigorously instrumented their behavior may not be the right answer.
But whether "doing better" comes via protocol changes, or getting better
common practices embedded in running (policy) code is a longer conversation.

-- Jeff

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Oct 2016 16:07:27 -0700

> > MUST.  Since I MUST allow users to change the value there, I am happy.
Close, but not quite.

The "MUST" for changing the values, IMHO, is something we all agree on,
myself included, and is directed at implementers.

The distinction is *to whom* the "MUST (be an ASN)" is directed at:
operators.

The "why" of the (global administrator) MUST is as follows:
- The Large community that the operator sets, may not involve the
operator's own ASN, nor any of the operator's peers' ASNs.
-- This is desired, allowable behavior, acknowledged by operators, and in
parity with RFC-1997
- Thus, the implementation CANNOT have enough local information to enforce
the "ASN-ness" of the 32-bit value
-- This is also as desired, acknowledged by operators, and in parity with
RFC-1997
- HOWEVER, it is not acceptable for the operator to use some other 32-bit
value in place of an ASN
-- By definition, any other 32-bit number will collide with the values of
32-bit ASNs (they are integers between 0 and 2^32-1)
-- There are plenty of private-use ASN values (between 4,000,000,000 and
2^32-2) for anyone who wants to do things "between consenting adults"

Private use ASNs are not guaranteed to be unique, so anyone using them need
to protect against collision.

Non-private-use ASNs are guaranteed to be unique, and adopting "MUST" gives
operators exactly what they need to influence those who behave badly, e.g.
out of ignorance.

Enforcement of this ASN-ness is something that needs to be exclusively
 handled in meat-space.

I don't think anyone (from an operator background) has any issues with
anything outside of "large" (in idr) doing smarter/better things.

Please let us have large, with this "MUST", without interfering in this
consensus, particularly from the operator community.

> And would be contradictory to the operational need from which the draft
Agreed (modulo "SHOULD vs MUST" language).

Maybe putting a prefacing statement to clarify the Global Administrator
definition, so that the restriction is guidance for operators, not
implementors, would get us to consensus?

Brian

---

From: Brian Dickson <[email-masked]>
Date: Thu, 13 Oct 2016 16:15:49 -0700

> had a hash table poorly sized...)

I think we actually need a straw-man here, upon which to hang the argument
(pro vs con on clean-up).

IMHO, any ASN that falls outside of the ranges that are "Reserved" or
"Private Use", should be excluded from clean-up.

The flip side to that is having "MUST" to give operators the ability to
protect their ASN-space from accidental or deliberate collisions.

However, I am willing to concede that Private ASN values should only be
propagated one AS-hop (where an entire Federation is one AS-hop).

Is it the case that the implementors in this discussion were specifically
thinking of applying the "intelligent clean-up" to ONLY the Private ASN
ranges?

(A simple Yes or No would be extremely helpful for bringing this discussion
to a close, IMNSHO.)

> common practices embedded in running (policy) code is a longer

I think articulating the specific values of "better" would help move the
conversation in a productive direction. I am as much to blame here as
anyone :-).

Brian

---

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

Tom

I understand your issue and I believe every major router vendor
does too.

What to do about it?

The router cannot check if the first word is a valid ASN
or if the ASN is the intended one. Even if the ASN is correct,
The rest of the community could still be junk.

A router vendor can provide tools to make it easier
for operators to be safe with communities, large or regular.

For example, there is a knob 'send-community' that must be
configured before a router will send communities on an ebgp
session. Therefore, an operator who is unaware of the problem
will not spray junk. Another tool is the 'peeras' keyword
that allows you to match the peer's ASN in any field of
the community. This makes it easier to write generic filters
in RPL. Excuse me if I'm tooting my own horn, but I do not
believe that this funcionality is unique to Cisco.
You can match private ASN and your own ASN too.

If anyone can suggest more tools, please do.

Thanks,
Jakob.

> Sent: Thursday, October 13, 2016 1:55 AM
> Julian
>

---

From: t.petch <[email-masked]>
Date: Sat, 15 Oct 2016 12:49:28 +0100

----- Original Message -----
From: "Jakob Heitz (jheitz)" <[email-masked]>
Sent: Friday, October 14, 2016 12:22 AM

Tom

What to do about it?

<tp>

Jakob

I think that Brian well expressed the issue in a post 15 minutes before
yours.

My concern starts with the protocol rather than the implementation,
seeing getting the protocol right as the first step, even if it does not
seem possible at present for a router to enforce the protocol rigidly.
I see BGP as a whole as somewhat weak on security, on authentication and
data integrity, and these things only getting fixed after a disaster or
two.  So I am content to specify a protocol which implementations may or
may not catch up with at a later date.

I agree the vendors can make it easier for an operator to get right and
that they should do so, and this in turn can influence the decision as
to whose products to use but do not want to see that as feeding back
into decisions as to what the protocol should be.

Tom Petch

Thanks,
Jakob.

---

From: Job Snijders <[email-masked]>
Date: Sat, 15 Oct 2016 14:45:56 +0200

Hi,

On Sat, Oct 15, 2016 at 12:49:28PM +0100, t.petch wrote:
> I think that Brian well expressed the issue in a post 15 minutes
> before yours.

No. That posting is proposing new radical ideas about propagation
behaviourisms that are not part of this specification.  A specific
design requirement for -large-, stated by member of the working group is
the simple transitive nature of the attribute. Given the very different
nature of what you and Brian propose, I suspect it might warrant its own
draft.

> seeing getting the protocol right as the first step, even if it does
> not seem possible at present for a router to enforce the protocol
> rigidly. I see BGP as a whole as somewhat weak on security, on
> authentication and data integrity, and these things only getting fixed
> after a disaster or two.  So I am content to specify a protocol which
> implementations may or may not catch up with at a later date.

I am not content with a protocol for which there are zero
implementations. Without implementations, there is no standardisation in
IDR.

Based on my experience with RFC 1997 - I feel that you may be
misrepresenting the risk surface. 

Kind regards,

Job

---

From: Brian Dickson <[email-masked]>
Date: Sun, 16 Oct 2016 13:19:25 -0700

Sent from my iPhone

> On Oct 15, 2016, at 5:45 AM, Job Snijders <[email-masked]> wrote:
> 
> Hi,
> 
> behaviourisms that are not part of this specification.

Actually, I was not proposing anything in particular. I'm not sure who it was that suggested "automatic clean-up", but I'm pretty sure it was one of the co-authors.

What I was saying, was if any change (over the current propagation mechanics) was to be implemented, it would be best to discuss the specific methods, here and now.

I am opposed to any changes to behavior as part of the protocol.

I do think all implementations need to provide operators the knobs to change, add, or remove large communities.

I will let Tom speak for himself but I expect he will concur.

>  A specific

Okay, this appears to be the perennial, gigantic disconnect.

This is the IETF, not IVTF (vendor).

The engineers specify, based on rough consensus. Vendors collaborating without the general agreement of the WG is not consensus, regardless of implementations.

The many years leading to "large" are a symptom, as was "extended" which preceded it.

I think we all agree on the meat of "large", except possibly the "must" vs "should" for ASNs. For that, I think WG consensus should be polled..

Brian

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 16 Oct 2016 22:10:49 +0100

Brian Dickson wrote:
> > rigidly.

Brian,

this is indeed one part of the problem: the lack of a protocol for
handling your suggestion.  If you have suggestions for a new protocol
which will allow a router to determine whether the global administrator
field is an ASN, along with an adequate definition of what you intend
the term "ASN" to mean in this context, then please post a separate
draft and the WG can chew it over.

Until there is a protocol in place to make this viable, demanding MUST
instead of SHOULD is creating a requirement for standards-track
mandatory compliance with a poorly-defined specification which, as you
note, cannot be enforced. This is not wise, and it has no place in a
standards-track document.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Tue, 18 Oct 2016 00:03:25 +0200

Hi,

> standards-track document.

I agree. The definition of SHOULD is strict enough as it is:

SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

The "full implications must be understood and carefully weighed" is strong enough for this situation.

Cheers,
Sander