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

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

<in line>
----- Original Message -----
From: "Job Snijders" <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, October 03, 2016 10:59 AM
>
> On Mon, Oct 03, 2016 at 10:13:02AM +0100, t.petch wrote:
> > The changes are not quite what I had in mind.
>
> Luckily we can try to get it right in -02! :)
>
> > 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 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."

Yes

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

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

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

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.

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

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

 > > 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)
>
> 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."

Yes, that would allay my concern.

> > 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)?
>
> 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.

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

> Kind regards,
>
> Job