Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document

From: Yakov Rekhter <[email-masked]>
Date: Fri, 16 Apr 2004 14:22:50 -0700

Folks,

It would be greatly appreciated if folks would read the document and 
comment on it to the IDR mailing list. In other words, we need 
"yes, looks good" or "should fix this and that", not just silence.

Thanks in advance.

Yakov.
------- Forwarded Message

Date:    Wed, 14 Apr 2004 08:09:52 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
cc:      [email-masked]
Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG documen
	  t

Folks,

We receive a request to accept draft-lange-flexible-bgp-communities-02.txt
as an IDR WG document. Please send comments to the list. The deadline
for comments is April 28, 2004. 

Yakov.

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

------- End of Forwarded Message

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

---

From: Andrew Lange <[email-masked]>
Date: Mon, 26 Apr 2004 12:13:50 -0700

Hi Pedro,

Replies are inline.

> my recollection is that this draft has been discussed before and that
> the majority of the WG requested that encoding and applications of
> communities be kept separate.

This suggestion was brought up at the SF IETF meeting.  There was no action
taken to access if this was a majority opinion or not.  If we look at the
former communities documents (1997 or the ext-comms draft) an initial set
of applications is also specified in those documents.  The applications
specified in this draft parallel the ones specified in 1997 and ext-comms,
with a couple of additions (neighbor classes, prepend, announce_with).

> reclying the comments: it does appear that the propossed applications
> are possible w/ existing protocol support. The author recognises that
> some of those applications may or may not be a good idea given that
> they seem to impose on an ISP a set of policies which the ISP may or
> may not wish to provide...
>
> reading the document, it seems that the original comments are still
> relevant.

Could you expand on this a little?  As an operator at the time I wrote
this, I included a proviso that says that operators MUST be able to turn
things off that they do not wish to honor.

The application that I think SPs will be cautious with is the ANNOUNCE_WITH
option.  Some providers will want to allow their customers to do this, but
some may not.

The basis for this proposal was community policies that providers were
already painstakingly using in their networks.  The policy actions in the
flex comms draft makes those policies easier to express, implement and
maintain in SP's networks.  Examples would include easy sending of lists of
ASNs for NO_EXPORT, neighbor-class functionality, etc.

> i also believe that embeding ipv4 and ipv6 addresses into communities is
> not a feature... addresses don't make for very good identifiers given
> that they may change.

Changing addresses can be an operational concern.  However, this extends
the options that exist for extended communities. You cannot send a IPv6
route-target without the ability to encode an IP address.  There are also
some tactical situations where a BGP-savvy customer would want to encode an
IP address.  For example one could wish to prepend to an east-coast peer
for its routes to avoid a perceived problem on that peering link.  So

                AS 100 ----   AS 200    ---- AS 100
                                |
                              AS 5000

AS 5000 would announce to 200 a community where it would ask that a
specific prefix or set of prefixes be prepended to AS 100's east-coast peer
IP (or neighbor class, if those are configured).  AS 200 would prepend, and
some of the traffic would move over to the AS100-AS200 west coast link.

Andrew

---

From: Andrew Lange <[email-masked]>
Date: Mon, 26 Apr 2004 12:13:50 -0700

Hi Pedro,

Replies are inline.

Andrew

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 30 Apr 2004 10:26:49 -0700

Folks

> for comments is April 28, 2004. 

The draft didn't generate enough support to justify its acceptance
as an IDR WG document.

Sue & Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 30 Apr 2004 10:26:49 -0700

Folks

Sue & Yakov.