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

[t.petch <[e-mail]>]

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

----- Original Message -----
From: "Job Snijders" <[e-mail]>
To: <[e-mail]>
Sent: Saturday, October 01, 2016 9:54 AM

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