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

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

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.

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:[e-mail]]
Sent: Thursday, October 20, 2016 5:28 PM
To: Jakob Heitz (jheitz) <[e-mail]>
Cc: Job Snijders <[e-mail]>; heasley <[e-mail]>; IETF IDR WG <[e-mail]>; Sue Hares <[e-mail]>
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) <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>] On Behalf Of Jakob Heitz (jheitz)
> Sent: Thursday, October 20, 2016 4:06 PM
> To: Job Snijders <[e-mail]<mailto:[e-mail]>>
> Cc: heasley <[e-mail]<mailto:[e-mail]>>; Sue Hares <[e-mail]<mailto:[e-mail]>>; IETF IDR WG <[e-mail]<mailto:[e-mail]>>
> 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:[e-mail]<mailto:[e-mail]>]
> > Sent: Thursday, October 20, 2016 3:50 PM
> > To: Jakob Heitz (jheitz) <[e-mail]<mailto:[e-mail]>>
> > Cc: Jeffrey Haas <[e-mail]<mailto:[e-mail]>>; heasley <[e-mail]<mailto:[e-mail]>>; IETF IDR WG <[e-mail]<mailto:[e-mail]>>; Sue Hares
> > <[e-mail]<mailto:[e-mail]>>
> > 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr