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

[Job Snijders <[e-mail]>]

Hi Tom,

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

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

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.

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

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

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

Kind regards,

Job