Subject: [Idr] draft-heitz-idr-large-community-04.txt

From: Randy Bush <[email-masked]>
Date: Wed, 21 Sep 2016 12:22:27 -0700

grammar could use a bit of work

>   A new type of BGP community attribute that contains communities that
>   each hold a 4-octet AS number and a 8-octet opaque field is defined.

i thought folk did not want to force it to be an AS number

the intro is more of an example.  nothing against examples, but maybe
start with a bit of a problem statement, existing communities are too
small for four-byte asns and hacks are not really good.  no big text
needed; just saying that we are not ignoring existing, it did not work
well.

then the example works in context

> 2.  Large BGP Community Attribute

why separate the two local parts?  the intro says "8 octets of locally
significant opaque data."

are the last 64 octets two fields or one.  decide and be consistent.

> The attribute consists of a set of Large Communities.

a bgp update may contain a large community attribute which is composed
of zero or more large communities.  or one or more if you insist.

> 3.  Textual Representation

maybe motivate the need for standardizing this

the regexp is getting you into trouble.  ^[0-9]+:[0-9]+:[0-9]+$ matches
leading zeros.  yes, you can complicate it [1-9][0-9]*: but do you
really think the doc benefits from this?

> 4.  Error Handling
...
>    o  The Large Community attribute SHALL be considered malformed if its
>       length is not a non-zero multiple of 12 bytes.

i might allow zero.  one less test if removing LCs from the attribute.

randy

---

From: Job Snijders <[email-masked]>
Date: Wed, 21 Sep 2016 22:52:45 +0300

> grammar could use a bit of work

Thanks, Heas offered to send a patch. Being a native Dutch speaker,
English grammar always remains a challenge. :)

> i thought folk did not want to force it to be an AS number

In a different thread Jeff Haas suggested to continue to call it the
"Global Administrator" Field. Initially I wasnt sure about it, but I
think it makes a lot of sense to just name Global Administrator instead
of AS number. 

In a separate draft (draft-snijders-grow-large-communities-usage) we'll
cover the implications of using a private vs public ASN there.

> needed; just saying that we are not ignoring existing, it did not work

Feedback from Joel M. Halpern was to start with an
example/justification. Do you have suggested sentences to improve the
introduction?

> are the last 64 octets two fields or one.  decide and be consistent.

My preference would be to talk about two fields, and indeed we should be
consistent. Thanks.

> of zero or more large communities.  or one or more if you insist.

ack.

> really think the doc benefits from this?

we'll remove the regex.

The 'Textual Representation' section came to be because we want to
prevent a 'asdot vs asplain' style time waste. It should be clear that
each Large Community is composed of three fields, separated by
something. If you read network documentation from another party and they
reference "111:333:555" it should be clear it is a Large community (even
if your router makes you type in "(111, 333, 555)").

> i might allow zero.  one less test if removing LCs from the attribute.

ok.

Kind regards,

Job

---

From: Michael H Lambert <[email-masked]>
Date: Wed, 21 Sep 2016 16:10:56 -0400

> On 21 Sep 2016, at 15:52, Job Snijders <[email-masked]> wrote:
> 

The introduction refers to a 96-bit opaque field.  Why not just leave it that way for normative purposes and call out internal structure only in potential use cases?

> if your router makes you type in "(111, 333, 555)").

I think the Textual Representation is important not because it reflects the internal structure in a common use case (which may or may not be the only use case), but because it precludes (or at least strongly dissuades) a vendor from making their default rendering the decimal representation of a 96-bit unsigned integer (as was done with four-octet communities).

Michael

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Sep 2016 13:31:24 -0700

> Thanks, Heas offered to send a patch.

patch or beer?  i can do a grammar pass when it is stable.

> think it makes a lot of sense to just name Global Administrator instead

i am not particulatly interested in how we got here.  i am interested in
where we should be.  the document says AS; i thought i heard that it
should not.  call it dogfood for all i care; just be consistent and what
folk agreed.

> example/justification. Do you have suggested sentences to improve the

the expansion, from 16 octets to 32, in the size of an AS number has
made the current comunity [rfc] inconveniently tight, leading to bad
creative work-arounds.  extended communities [rfc] have led to similar
issues.  large communities are the simplest and most expedient expansion
of the space, and add no complexity or new semantics.

> My preference would be to talk about two fields, and indeed we should be

i have a small mind, and hobgoblins will soon be in season.

>> of zero or more large communities.  or one or more if you insist.

zero or one?

> prevent a 'asdot vs asplain' style time waste.

the asdot vs asplain discussion for the 32 bit asns taught us that
explicit specification of the texttual representation is the prudent
path.

>> really think the doc benefits from this?

it has it's good side.  if you do it, do it rigorously.  and cite the
regexp syntax you are using.

>> i might allow zero.  one less test if removing LCs from the attribute.

again, just decide

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 21 Sep 2016 13:46:05 -0700

> The introduction refers to a 96-bit opaque field.  Why not just leave
> it that way for normative purposes and call out internal structure
> only in potential use cases?

fine, but then in very clearly separate sections: definition and
examples of use.  have one example be 16 octets of old AS plus 80 bits
of gloop. :)

but consistency is key.  e.g. need to make clear that textual rep is not
indicating semantics any more than, for example, 2001:418:1::0 is.

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 21 Sep 2016 17:04:30 -0400

> On Sep 21, 2016, at 4:31 PM, Randy Bush <[email-masked]> wrote:
> 
>>>> 

1 or more.

Implementations may prune empty path attributes (and probably should) when the contents are lists.  However, I don't believe we should standardize sending 0 of these communities as a form of signaling.

That said, in the error handling section, it should note that a length of zero shall not be treated as a malformed route.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 21 Sep 2016 23:34:50 +0100

Michael H Lambert wrote:
> I think the Textual Representation is important not because it
> reflects the internal structure in a common use case (which may or
> may not be the only use case), but because it precludes (or at least
> strongly dissuades) a vendor from making their default rendering the
> decimal representation of a 96-bit unsigned integer (as was done with
> four-octet communities).

bird uses (xxx, yyy) to represent rfc1997 communities, which allows it
to treat the elements as integers.  Bird syntax provides a rich set of
integer handling operators and expressions which means that there's no
requirement to use traditional regexp hacks if you want to do
comparisons, ranges or equality matches.  So if there is a proposal for
a textual representation, it should be a recommendation rather than a
requirement.

Nick

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 21 Sep 2016 23:12:37 +0000

I'll state that the textual representation is the default and other
representations may be offered. I'll state the reason.

All implementations must provide a consistent textual representation,
otherwise it becomes impossible for ISPs to specify to customers
how to set the communities.

If you have alternative representations, please share.

Thanks,
Jakob.

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of Nick Hilliard
> Sent: Wednesday, September 21, 2016 3:35 PM
> To: Michael H Lambert <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Idr] draft-heitz-idr-large-community-04.txt
> 
> Michael H Lambert wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Job Snijders <[email-masked]>
Date: Thu, 22 Sep 2016 03:01:45 +0300

> a textual representation, it should be a recommendation rather than a

The currently queued up text should make it clear that it is a
recommendation:

    Textual Representation

    To allow for smooth communication of community settings between ISPs
    and their customers, support for the following textual
    representation is RECOMMENDED. Equipment vendors MAY provide other
    textual representations.

    The textual representation of the Large Community is A:B:C, where A
    is the Autonomous System number, B is the Local Data part 1 and C is
    the Local Data part 2. A ranges from 0 to 4294967295. B ranges from
    0 to 4294967295. C ranges from 0 to 4294967295. A, B and C are plain
    decimal non-negative integers without leading zeroes. Each number
    must appear, even if it is 0. For example, "0:1:2" cannot be written
    as ":1:2".

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Sep 2016 05:31:12 -0700

>     representation is RECOMMENDED. Equipment vendors MAY provide other

is it mti or is it not?  "may provide other" looks pretty mti to me.
in either case be explicit.

randy

---

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

Sorry, what's mti?

Thanks,
Jakob.

---

From: Jared Mauch <[email-masked]>
Date: Thu, 22 Sep 2016 10:43:06 -0400

> On Sep 22, 2016, at 9:38 AM, Jakob Heitz (jheitz) <[email-masked]> wrote:
> 
> Sorry, what's mti?

I believe he means a moving target (indicator).

I agree we need to have a standard display.  If some other customer requests alternate matching, then you can look at that.

eg: IOS without "ip bgp community new-format" configured prints it as unsigned long integer vs 2:2

Sometimes too many options itself is a catastrophic defect.

- Jared

---

From: Brian Dickson <[email-masked]>
Date: Thu, 22 Sep 2016 08:50:06 -0700

MTI == Mandatory To Implement.

I think the question is, how should the "MAY provide" be interpreted by the
vendors?

There are two possibilities: (a) in addition to; (b) instead of.

MTI (on the RECOMMENDED) means (a).

Also, I think it is fine to have vendors' "other textual representations"
be the default, as long as they provide a knob to switch the representation
to the RECOMMENDED one.

So, the two things are:
- What is the intent of the ID
- Can we tighten up the wording to remove any ambiguity and make it match
the intent.

Brian

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 22 Sep 2016 12:01:03 -0400

"Mandatory to implement"

And no, it's not at all obvious. Not just you.

--John

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Sep 2016 09:20:24 -0700

> Sorry, what's mti?

ietf speak for mandatory to implement

---

From: Job Snijders <[email-masked]>
Date: Thu, 22 Sep 2016 18:30:50 +0200

> MTI == Mandatory To Implement.

TIL

> I think the question is, how should the "MAY provide" be interpreted
> by the vendors? There are two possibilities: (a) in addition to; (b)
> instead of.
> 
> Also, I think it is fine to have vendors' "other textual
> representations" be the default, as long as they provide a knob to
> switch the representation to the RECOMMENDED one.
> 
> So, the two things are:

1) if a vendor is in a position to accept 32b:32b:32b notation in their
configs, the 'show commands', the manuals, etc, they should do so. 

2) ensure that when humans email each other or publish lists of
communities through sites like these:
www.us.ntt.net/support/policy/routing.cfm#communities , we don't end up
with part of the world writing it down as 16b.16b:16b.16b:16b.16b, or
hex, or as one gigantic integer, but that everyone tries to stick to
32b:32b:32b.

> - Can we tighten up the wording to remove any ambiguity and make it
> match the intent.

suggestions welcome

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Sep 2016 09:36:07 -0700

> - Can we tighten up the wording to remove any ambiguity and make it match

the intent is negotiable.  the last point is the critical one.  in
general, this document is pretty loose and leaves too much open to
interpretation.

what we're really talking about here are configs and the result of show
blah blah commands, yes?  my personal preference would be to make the
standard representation a MUST, i.e. mti, and default.  pola (for the
acronym challenged (and i am often), Principle Of Least Astonishment).
after all, operator interoperability is also important.

randy

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Thu, 22 Sep 2016 16:48:27 +0000

Jeff wanted to prepend something to make it work in Junos.
Nick wanted (X, Y, Z) to fit in with Bird.

We should be able to accommodate such variations.

Did I remember that correctly? Anything else?

Thanks,
Jakob.

On Sep 22, 2016, at 8:50 AM, Brian Dickson <[email-masked]<mailto:[email-masked]>> wrote:

I think the question is, how should the "MAY provide" be interpreted by the vendors?

Also, I think it is fine to have vendors' "other textual representations" be the default, as long as they provide a knob to switch the representation to the RECOMMENDED one.

So, the two things are:
- What is the intent of the ID
- Can we tighten up the wording to remove any ambiguity and make it match the intent.

Brian

On Thu, Sep 22, 2016 at 6:38 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Sorry, what's mti?

Thanks,
Jakob.

On Sep 22, 2016, at 5:41 AM, Randy Bush <[email-masked]<mailto:[email-masked]>> wrote:

> [email-masked]<mailto:[email-masked]>

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 22 Sep 2016 09:59:12 -0700

> We should be able to accommodate such variations.

indeed.  and i want octal.  but there is no need to specify them; that
is an endless trail and the food sucks.  specify the 32:32:32 as mti and
default and simply say that other, vendor specific, formats MAY be
provided.

randy

---

From: t.petch <[email-masked]>
Date: Thu, 22 Sep 2016 17:25:03 +0100

----- Original Message -----
From: "Brian Dickson" <[email-masked]>
Sent: Thursday, September 22, 2016 4:50 PM

> I think the question is, how should the "MAY provide" be interpreted
by the
> Also, I think it is fine to have vendors' "other textual
representations"
> - Can we tighten up the wording to remove any ambiguity and make it
match
> the intent.

The view I have seen some Area Directors express, and it makes sense to
me, is  that 'MAY' has the same force as 'MAY NOT', i.e. none at all,
which makes the case for
' ... may in addition ...'
in this case.

Tom Petch

---

From: Jared Mauch <[email-masked]>
Date: Thu, 22 Sep 2016 13:10:39 -0400

> On Sep 22, 2016, at 12:59 PM, Randy Bush <[email-masked]> wrote:
> 

I certainly agree here, 32:32:32 then if people put parens, square
brackets or whatever around it that’s up to them.

I don’t want to end up with u_int32_t:u_int64_t  or the 16.16:16.16:16.16
mentioned previously as MUST.

- Jared

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 23 Sep 2016 12:00:35 -0400

> Jeff wanted to prepend something to make it work in Junos.

Junos is very likely to end up with a string in front of the colon-separated
uint32 triplet.  This deals with the fact that we have already got semantic
meaning to an three integer colon separated triplet.

> Did I remember that correctly? Anything else?

Pretty much at the end of the day, a portion of the discussion could simply
be framed using existence proof from other implementations: For RFC 1997 and
extended communities, is there consistency in textual representation?

Not really.  There are some similar trends.  And most of the variations
focus around niceties of people's CLIs or policy engines.

If you want to specify a yang mapping for this, that's within general IETF
charter.  But as you might be aware from other threads across a number of
BGP related IETF lists, there has been no convergence for even the
representation of extended communities in yang.  For exactly the reasons
above.

IMO, it's a mistake to try to force some MTI textual convention in the
document.  Leave it at recommended, then the operators can work with their
various vendors within the constraints of that implementations UI and
routing policy ecosystem.

-- Jeff

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 23 Sep 2016 17:41:37 +0100

Jeffrey Haas wrote:
> Leave it at recommended, then the operators can work with their

this is a more sensible approach.  x:y is widely but not universally
used - bird is not the only example of this.

Nick