Re: [Idr] Request to adopt draft-heitz-idr-large-community

[Robert Raszuk <[e-mail]>]

Hi Job,

Excellent.

And my only point was to add that single sentence to the spec when next rev
comes out.

Suggestion for the sentence to add into bottom of the section 3:

"The Autonomous System number used within the community field is an Autonomous
System which understands the encoded meaning of the 8 octets which follow
and which is to act on it."

... or something along those lines.

Cheers,
R.


On Wed, Sep 7, 2016 at 6:11 PM, Job Snijders <[e-mail]> wrote:

> Hi Robert,
>
> On Wed, Sep 07, 2016 at 05:47:27PM +0200, Robert Raszuk wrote:
> > I agree with all statements made by Rob S.
> >
> > Kay's email however triggered the clarification question to the
> > current -03 version.
> >
> > What is the meaning of explicit AS number listed in the first 4 octets
> > of the community. I was under impression that originally it was the AS
> > number in which given community needs to be executed however it seems
> > that this sentence is no longer in the current version of the draft.
>
> The first 4 bytes contain the ASN in which the last 8 bytes have a
> meaning. Its not about what is executed where. Consider the last 8
> bytes, the 'local opaque data', a namespace of sorts, the first 4 bytes
> indicate who owns that namespace. The owner of the namespace can
> publicly or privately document what the meaning communities are within
> his/her namespace.
>
> I welcome suggestions to improve the text on this aspect. RFC 1997 had
> language like "Global Administrator" and "Local Administrator" - but I
> think that is a somewhat archaic to explain this concept. In -04 we're
> talking about "Autonomous System Number" and "Local Data".
>
> > So it may be unclear if this is AS number inserting this community, if
> > this is target AS to execute it or perhaps like in the case of Route
> > Server is it AS acting as proxy for other ASes it peers with ?
> >
> > The answer could be none of the above - it's all local significant - but
> > then shouldn't it rather use a 4:4:4 description.
>
> What Kay described is that they today with RFC 1997 communities they are
> using a horrible kludge because there is not enough space.
>
> With Large communities, ECIX (AS 9033) could say "Dear customers, if you
> attach 9033:XXX:YYY to your prefix, our routeserver will do A", where
> XXX and YYY are values decided by ECIX. This way, there will never be
> collisions. What XXX and YYY are is up to ECIX, XXX could be the ASN of
> a peer on the route server, YYY could be an identifier which triggers an
> action, such as no-export.
>
> Given the above context and what Kay sent to the list:
>
> > > As we use 65000:XXX, where XXX is the ASN which should
> >> not receive the route, this proposal would give us the option to also
> >> extend the control-mechanisms towards 32-bit ASNs and not just 16-bit
> >> ASNs anymore.
>
> With Large Communities, the above example could be turned into:
> 9033:65000:XXX, where XXX is the ASN which should not receive the route.
> Suddenly they aren't overloading a Global Administrator field with a
> private ASN! :-)
>
> ECIX (and other Route Server operators) gain two advantages: There won't
> be a risk of collision because its in their own namespace, (in ECIX's
> case '9033'), and XXX can be a 4-byte value, meaning they can target
> 4-byte ASNs, which is something they cannot do today but clearly want to
> do for consistency.
>
> It is important to recognise that it is up to ECIX to decide how they
> use the 8 bytes of data available to them. They can put ASNs in there
> directly, or use a mapping table, or throw a dice and just publish which
> value means what on their Route Server. It is entirely opaque.
>
> Kind regards,
>
> Job
>
> ps. Large Communities' expiry date will be the moment the IETF starts
> working on 8-byte ASNs. If that ever happens, we'll hopefully remember
> this thread.
>