Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

On Thu, Oct 20, 2016 at 5:46 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>
wrote:

> I do understand that the community may travel several AS hops.
>
> That's why I wrote
>
>
>
>   A Large Community that
>
>   is *intended to be sent to multiple ASes* SHOULD contain an ASN
>
>   in the Global Administrator field. The ASN SHOULD be one that
>
>   is assigned to the entity
>
>   that defines the meaning of the rest of the Large Community.
>
>
>
> I also understand that this is not the only case and that communities
>
> are often used within an AS only. We MUST NOT restrict that use.
>
>
>

Agreed.

I think the tweak to your wording along the lines of:
"...within an AS and across AS boundaries, ANY values will be allowed."
That removes the notion of adjacent, as well as whether B is sender or
recipient.

Entity is fine.

Thanks,
Brian

> Also, even though AS B defines the community that has GA=B, AS B
>
> is not always the intended recipient. Many ISPs use communities
>
> to signal properties of routes that they send to their customers.
>
> In that case, AS B is the sender, not the recipient.
>
>
>
> I wrote "entity" and not "AS", because someone may create only a
>
> single BGP AS, but be assigned many ASNs. That someone is entitled
>
> to use any of her assigned ASNs, not just the one in use by her AS.
>
>
>
>
>
> Thanks,
>
> Jakob.
>
>
>
> *From:* Brian Dickson [mailto:brian.peter.dickson@gmail.com]
> *Sent:* Thursday, October 20, 2016 5:28 PM
> *To:* Jakob Heitz (jheitz) <jheitz@cisco.com>
> *Cc:* Job Snijders <job@ntt.net>; heasley <heas@shrubbery.net>; IETF IDR
> WG <idr@ietf.org>; Sue Hares <shares@ndzh.com>
>
> *Subject:* Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt
> (10/17/2016 to 10/31/2016)
>
>
>
>
>
>
>
> On Thu, Oct 20, 2016 at 4:46 PM, Jakob Heitz (jheitz) <jheitz@cisco.com>
> wrote:
>
> Perhaps, we should add in an operations section that we should not and
> will not go any further.
> In particular, within an AS and between adjacent BGP neighbors, ANY values
> will be allowed.
> The only requirement is that sender and receiver have the same
> understanding of the contents,
> but no RFC is required to say this.
>
>
>
> Jakob,
>
>
>
> I think you still don't understand the purpose or the mechanics of
> communities, as what you say makes almost no sense.
>
>
>
> The reason "large" needs to be an optional, transitive attribute, is that
> the intended party, whose ASN
>
> is in the Global Administrator field, is not necessarily the first or
> second party (the one setting the community,
>
> or the one that is the BGP peer of the first party).
>
>
>
> The community may travel an arbitrary number of AS hops before it is
> received by the ASN in question (global admin).
>
> That ASN is the one who is the (ultimate) intended recipient (of the
> community), and whose interprets the latter 8 octets
>
> of the community, using whatever logic he/she wishes. (The prefix will
> probably propagate much further, but we
>
> are only concerned about the ASN that is the global administrator of the
> community.)
>
>
>
> This is NOT limited to within an AS, nor to adjacent BGP peers.
>
>
>
> As such, the intermediate AS hops will receive the prefix with the
> attached Large Community, but will
>
> not have any understanding of the contents. They are expected to pass them
> along, as this is the
>
> necessary part of communities' functioning.
>
>
>
> A -> X -> Y -> Z -> B are the Autonomous Systems passing the prefix.
>
> A sets the community. The community is B:something:something.
>
> B interprets the community.
>
> X, Y, and Z, pass it along without acting on it.
>
>
>
> I'm sorry to raise a fuss, but since you are involved in editing the I-D,
> it would put my mind at ease to hear you say
>
> that you understand the above.
>
>
>
> Putting text into this document, if you don't understand the above, may be
> harmful to the document,
>
> and to operator folks who are trying to get the bugs out of the document
> before it advances.
>
>
>
> Sincerely,
>
> Brian
>
>
>
>
>
> Thanks,
> Jakob.
>
>
>
> > -----Original Message-----
> > From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Jakob Heitz
> (jheitz)
> > Sent: Thursday, October 20, 2016 4:06 PM
> > To: Job Snijders <job@ntt.net>
> > Cc: heasley <heas@shrubbery.net>; Sue Hares <shares@ndzh.com>; IETF IDR
> WG <idr@ietf.org>
> > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt
> (10/17/2016 to 10/31/2016)
> >
> > Evidently, it wasn't clear. Now it is.
> >
> > Thanks,
> > Jakob.
> >
> >
> > > -----Original Message-----
> > > From: Job Snijders [mailto:job@ntt.net]
> > > Sent: Thursday, October 20, 2016 3:50 PM
> > > To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> > > Cc: Jeffrey Haas <jhaas@pfrc.org>; heasley <heas@shrubbery.net>; IETF
> IDR WG <idr@ietf.org>; Sue Hares
> > > <shares@ndzh.com>
> > > Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt
> (10/17/2016 to 10/31/2016)
> > >
> > > Hi Jakob,
> > >
> > > I am not sure what issue this replacement resolves. With the
> replacement
> > > text in the document I feel I have more questions than answers.
> > >
> > > Usually a community is intended to be sent to one AS to trigger an
> > > action, and to multiple ASes if the community is of informative nature.
> > > We know we can attach multiple Large BGP Communities to a route,
> because
> > > of the variable length of the attribute.
> > >
> > > In an earlier response I pointed at text that addresses this specific
> > > feature already in the current text: https://mailarchive.ietf.org/
> arch/msg/idr/_QULjIUDaBB4JqDR8IXuIYkAVJw
> > >
> > > Kind regards,
> > >
> > > Job
> > >
> > >
> > > On Thu, Oct 20, 2016 at 10:13:41PM +0000, Jakob Heitz (jheitz) wrote:
> > > > In addition, to deal with the values for the GA field, we will
> replace
> > > >
> > > >    The Global Administrator field is intended to allow different
> > > >    Autonomous Systems to define Large BGP Communities without
> collision.
> > > >
> > > > with
> > > >
> > > >   A Large Community that is intended to be sent to multiple ASes
> > > >   SHOULD contain an ASN in the Global Administrator field. The ASN
> > > >   SHOULD be one that is assigned to the entity that defines the
> > > >   meaning of the rest of the Large Community.  This allows a route to
> > > >   carry multiple Large Communities, the meaning of each being defined
> > > >   by different independent entities.
> >
> > _______________________________________________
> > Idr mailing list
> > Idr@ietf.org
> > https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>
>