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

[Job Snijders <[e-mail]>]

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

This has been incorporated for -02.

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

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

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

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.

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

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

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

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