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

["Jakob Heitz (jheitz)" <[e-mail]>]

I fully expect people to use the first 4 octets to encode the target ASN for all the reasons mentioned. However, I will not enforce it in the code or in the spec. It is enough to RECOMMEND it in the spec, stating the reason.

Thanks,
Jakob.


> On Sep 8, 2016, at 6:31 AM, "[e-mail]" <[e-mail]> wrote:
> 
> [re-sending in ascii]
> 
> Hi Jakob,
> 
> Please see inline, [Bruno]
> 
>> -----Original Message-----
>> From: Jakob Heitz (jheitz) > Sent: Thursday, September 08, 2016 12:40 AM
>> 
>> 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.
> 
> 
> [Bruno] The problem is that in living networks, people start using a solution (e.g. large community) with a given use case in mind. Then once deployed, it's very hard to change (well, I guess it depends on how big and complex is the network).
> So people start with 2 ASes (originating and terminating), then use one VPN AS to transit, then come inter-AS VPN. And those transit AS will see name space collision, which will be a headache. (e.g. who must be forced to renumber?)
> Note that a transit AS may also be introduced between 2 peers, without VPN.
> 
> So I would strongly prefer that the first 4 octets be dedicated to the AS number defining the usage of the community, just like RFC 1997 (BGP community) (and RT for extended community and RD in VPNs)
> 
> [Bruno]
> IMHO, I would interpret your proposition as a fear that in some future, the large-community, is found not to be large enough. If this is the case, it's not too late to make it bigger. e.g. 4*32 bits.
> On a side note, I'm also a bit nervous that 3 days after the start of the WGLC, so extremely early for a solution that I would expect to be running for 20 years, we are already discussing that the numbering space may be too small. (full disclosure, I'm co-authoring draft-ietf-idr-wide-bgp-communities)
> 
> Thanks,
> Regards,
> --Bruno
> 
> 
>> 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
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>