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

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

Makes sense. Merci Bruno.

Jakob.

> On Sep 8, 2016, at 8:25 AM, "[e-mail]" <[e-mail]> wrote:
> 
> Hi Jakob,
> 
>> From: Jakob Heitz
>> Sent: Thursday, September 08, 2016 12:51 PM
>> 
>> 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.
> 
> Although I'd prefer RFC 4360 (extended community) formulation ("This sub-field contains an Autonomous System number assigned by IANA."), if the goal is to keep RFC 1997 communities usages as-is, I would be fine re-using RFC 1997 text:
> 
> "The rest of the community attribute values shall be encoded using an
>   autonomous system number in the first two octets.  The semantics of
>   the final two octets may be defined by the autonomous system."
> 
> but updated with a 2119 keyword. i.e. :s/shall/SHALL
> 
> I'm not asking for any enforcement in the code. (and I don't see how the code could enforce it).
> I'm asking for the document to make it clear, that AS X owns the community space starting with X. Such that if there is a conflicting usage, it's clear which AS/actor needs to renumber.
> 
> Note that I can live with current wording in the draft. It's your proposed change that I am commenting on.
> 
> 
> As another comment, I think section 3 ("Textual Representation") could normatively reference RFC5396 ("Textual Representation of Autonomous System (AS) Numbers").
> 
> 
> Thanks,
> --Bruno
> 
>> 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.
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>