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

[<[e-mail]>]

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.