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

[t.petch <[e-mail]>]

----- Original Message -----
From: "Jakob Heitz (jheitz)" <[e-mail]>
Sent: Friday, October 21, 2016 1:46 AM

> 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.

Jakob

I read the words and share some of Brian's uncertainties.

" A Large Community that  is intended to be sent to multiple ASes SHOULD
contain an ASN  in the Global Administrator field. "

For me, that is not the BGP protocol we have. Rather,

" A Large Community is sent as a BGP transitive attribute which means
that it will be sent to and received by a large number of ASes of which
only one, or a small number, will be expected to understand and act upon
the community.  Thes ASes may or may not be adjacent to the AS
originating the community.  So that a recipient can tell whether or not
the community is intended for it, the Global Administrator contains an
ASN  ..."

except of course some want the freedom to put any value in the Global
Administrator field in which case the recipients cannot tell (which is
where I keep on coming from:-(

BGP as specified does not have a mechanism to limit the distribution of
a transitive attribute.

I wonder if part of this disconnect is that in practice, a lot of
stripping goes on so that attributes such as these are not really
transitive at all.  The impression I get is that the current attribute
works despite being intended to be transitive when in practice it may
not be so that replacing like for like, with just an increase in size,
is not expected to create any routing issues.

Perhaps we should have two communities, one transitive which MUST have
an ASN and one not, although as Jeff pointed out, that would probably
fail in the face of Route Reflectors and  so is  a non-starter.

Tom Petch

>
> 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
>
>


------------------------------------------------------------------------
--------


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