Subject: [Idr] I-D Action:draft-ietf-idr-as4octet-extcomm-generic-subtype-02.txt

From: [email-masked]
Date: Mon, 26 Jul 2010 10:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Generic Subtype for BGP Four-octet AS specific extended community
	Author(s)       : D. Rao, et al.
	Filename        : draft-ietf-idr-as4octet-extcomm-generic-subtype-02.txt
	Pages           : 6
	Date            : 2010-07-26

Maintaining the current best practices with communities, ISPs and
enterprises that are assigned a 4-octet AS number may want the BGP
UPDATE messages they receive from their customers or peers to include
a 4-octet AS specific extended community.  This document defines a
new sub-type within the four-octet AS specific extended community to
facilitate this practice.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-as4octet-extcomm-generic-subtype-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 27 Jul 2010 20:51:23 +0200

Hi,

As it has been correctly suggested by Hannes Gredler from Juniper 
Networks and Steve Padgett from Google it seems that it is very 
practical to have a way to limit propagation scope of the injected BGP 
communities even for customer assigned values only to his/her/it's 
direct provider AS.

In Wide BGP Communities that can *and will be in the next rev* achieved 
by new explicit action field flag.

I would like to see how this can be achieved in the below extended type 
of extended communities encoding.

The point to note is that by itself addresses many concerns of wider 
then customer-provider propagation boundary of any BGP community 
propagation.

Many thx,
R.

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

---

From: "Dhananjaya Rao (dhrao)" <[email-masked]>
Date: Tue, 27 Jul 2010 13:46:05 -0700

Hi Robert,

As has been discussed, this draft simply provides parity for
RFC1997 style communities for 4-byte ASes so that operators
can use it as they have been using regular communities; it doesn't
aim to add any more extensive tools.

However, your specific question does resurrect a basic question I
had about the interpretation of the extended community type. IIRC,
this had come up on the list a year or so back, but didn't result
in much discussion.

How is the non-transitive extended community type supposed to be used ?
Is it strictly applicable only within the AS where it was originated ?

I had interpreted it to be similar to the MED, in that, it could be
originated on an AS boundary and sent to an eBGP peer, which would
honor the extended community (if a matching policy was configured),
but that peer's AS would not propogate the extended community to
other ASes. This, I had thought, would be how a provider AS could use
the non-transitive generic extcomm defined in this draft to strictly
scope communities used with customer ASes.

This could just be a misinterpretation on my part, but I would
be interested in hearing your and others' views on it.

Thanks,
-Dhananjaya

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Robert Raszuk (raszuk)
>Sent: Tuesday, July 27, 2010 11:51 AM
>To: [email-masked]
>Subject: Re: [Idr] 
>I-DAction:draft-ietf-idr-as4octet-extcomm-generic-subtype-02.txt
>
>Hi,
>
>> 	Filename        : 
>draft-ietf-idr-as4octet-extcomm-generic-subtype-02.txt
>> 	Pages           : 6
>> 	Date            : 2010-07-26
>>

---

From: <[email-masked]>
Date: Wed, 28 Jul 2010 02:59:13 +0200

Hi Dhananjaya, all

> this had come up on the list a year or so back, but didn't result

You're right. This point has been discussed in 
http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00

> scope communities used with customer ASes.

We had interpreted it the same way.
Yet the RFC wording could be subject to different interpretation; so
real behaviour is difficult to predict, which limit the ability to use
it.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 Jul 2010 07:37:49 +0000

> communities even for customer assigned values only to his/her/it's  
[...]

> http://tools.ietf.org/html/draft-decraene-idr-rfc4360-clarification-00

FWIW, my interpretation of extended community transitivity has always
matched the view expressed by the above clarification draft.  I was unaware
that other vendors had interpreted it differently.

Given that opinion, I had already believed that non-transitivity was already
covered on the community as an option.  Flexible communities also has a
similar option.

While I agree that vendor implementations may not show the behavior covered
in the above clarification draft, I would consider those behaviors a bug.

-- Jeff

P.S.:

As an aside, similar "within an AS" issues seem to come up in many other
drafts and older RFCs.  For purposes of "within an AS", confederation
implementations tend to treat internal confederation ASes as "within an AS".
Confederation internal AS behaviors tend to be covered specifically if
otherwise important.