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

[Robert Raszuk <[e-mail]>]

Hi Jakob,

To me what you proposed here below is sufficient and covers second sentence:

"
​
The meaning of all octets in the large community is to be defined by mutual
agreement between the originating and terminating ASes."

- - -

However while we do not talk about this often in IDR and just leave freedom
of implementation let me risk a question what filtering capabilities should
be or are expected to be implemented for large communities at the ASBRs ?

Q1: In your current implementation can I selectively accept communities
only with my AS listed in the first 4 octets and drop everything else ?

Q2: If as you say large community is intended to "transit an AS" how do I
know the destination/terminating AS will get what real sender sent or
intended to sent in the remaining 4:4 ?

Q3: Assume the terminating AS as agreed with with originating AS did the
job. Should spec enforce (MUST) to strip such community before propagating
the route any other EBGP speaker ? Why do we want to trash the Internet
with something which by AS-PATH rules should never be needed again (leave
alone allowas-in tricks or as-overwrite) ?

Thx,
R.



On Thu, Sep 8, 2016 at 12:39 AM, Jakob Heitz (jheitz) <[e-mail]>
wrote:

> Here is how I would treat the first 4 octet so of the large community.
> The community is normally used by an ISP to allow a directly connected
> customer to express its wishes about how to process the route. In that
> case, the first four octets and all octets are totally in control of the
> ISP. The ISP has total control of the definition of the octets. If an ISP
> is willing to carry communities that are destined to another AS, then it
> makes sense for everyone to agree on the encoding of the target ASN in the
> community.
> I would phrase it like this:
>
> ​​
> The meaning of all octets in the large community is to be defined by
> mutual agreement between the originating and terminating ASes. However, if
> a large community is intended to transit an AS, then the ASN of the
> terminating AS SHOULD be encoded in the first 4 octets of the large
> community.
>
> For example, there is no reason that an invalid ASN (say 0 or 23456)
> should be disallowed as long as the intended recipients of the community
> understand the meaning.
>
> Thanks,
> Jakob.
>
>
> On Sep 7, 2016, at 1:57 PM, Robert Raszuk <[e-mail]> wrote:
>
> 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.
>>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>