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: Pedro Roque Marques <[email-masked]>
Date: Wed, 21 Apr 2004 11:33:35 -0700 (PDT)

Yakov Rekhter writes:

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

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.

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.

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.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 21 Apr 2004 11:33:35 -0700 (PDT)

Pedro.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Apr 2004 12:17:53 +0300 (EEST)

Hi,

For what it's worth, it seems to me that this memo is a solution
looking for the problem.

Why do we need this in the first place?  To "standardize" commonly 
used communities?  To give the users more tools to mess up their 
routing, or to allow the users to make the ISP's policy more complex?

I'm skeptical about the usefulness of this approach.

A few nits:
 - if EX-COMM doesn't support IPv6 addresses, and that is important 
enough, the support MUST be added.
 - it might make sense to switch the order of Length and "ASN" fields 
for better alignment.  Length could also include the ASN field. (Maybe 
this would be a more typical TLV encoding?)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Thu, 22 Apr 2004 12:17:53 +0300 (EEST)

Hi,

A few nits:

---

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

Hi Pekka,

> routing, or to allow the users to make the ISP's policy more complex?

Here is some additional text for the introduction which, I hope, will 
answer your questions.

There is a clear demand by BGP-savvy customers to have enhanced control 
over their route announcements.  Today this demand is addressed by custom, 
complex and difficult to manage community policies.  There is no 
consistency across providers, except for the NO_EXPORT well known community 
specified in RFC1997.  There are more well-known communities for common 
policies specified in this document to help provide commonality and ease of 
maintenance.  The current route policies required to provide enhanced BGP 
services are very cumbersome.  The larger space provided in flexible 
communities, and the introduction of neighbor classes significantly ease 
the implementation and maintenance burdens for service providers.

Service providers also often tag their data based on where and from whom 
they learned it (peer, customer, geographic origin).  The flexible 
community, and the neighbor class application especially, make both 
assigning inbound communities and matching on outbound peers significantly 
easier and less error prone.

In addition, community values today are simply too small and too rigidly 
defined to allow for the growth of the Internet.  For example, encoding 
IPv6 address and an action to take on them is simply impossible.

> enough, the support MUST be added.

EX-COMM is 8 octets.  An IPv6 address is 16.  As IPv6 deployments progress 
there will be a demand for encoding IPv6 addresses.

> this would be a more typical TLV encoding?)

This would be pretty simple to do.  I had structured things the way they 
are to allow for a larger DATA Field to encode values.  We would max out at 
251 octets of data with the ASN field second.  251 is probably enough, and 
we would gain a slightly simpler header and more alignment with existing 
communities.  Okay, I'll reorder those two fields.

Andrew

---

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

Hi Pekka,

Andrew

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 18:52:14 +0300 (EEST)

> IPv6 address and an action to take on them is simply impossible.

This is clearer.

However, there are still many things I find disturbing, based on the 
quick glance:

 - operator losing the control of the network.  For us, the #1 thing
in the network is being able to control the traffic flows etc. as we
see fit except with the tools we give to the customers.  So, this
would seem to call for a statement that acting upon these communities
should be disabled unless explicitly enabled.

 - IPv4/IPv6 addresses: these are very poor keys for communities and 
probably should not be included -- or is there a specific usage case 
for them?  If there are needed, could these be implemented as a form 
of extended communities then?

 - usability for the customer: these are only applicable to the
customer if the customer has already negotiated with the ISP that the
ISP supports these communities, and has marked each and all the BGP
sessions it has accordingly ("peer", "upstream", "transit", etc.);  
they aren't useful otherwise.  This seems like a rather big leap to
me.

So what these are is a replacement for those ISPs who already 
community-based schemes to something "standardized".  It doesn't help 
much (except a little with set-up complexity) with other ISPs, so it 
isn't a silver bullet.

 - similar to IPv4/IPv6 address applicability, the applicability of 
VPN communities seems a bit fuzzy.  In addition to those the bandwidth 
community seems particularly unnecessary.

 - this appears to be confusing:

   The Flexible Community attribute MUST NOT be used to modify the BGP
   best path selection algorithm in a way that leads to forwarding
   loops.

   ==> does this allow that to happen?  Do we want to specify anything 
that would lead to that?  On the other hand, if we allow flexibility, 
the customer always has a possibility to shoot himself in the foot, 
and the protocol should not prevent that?

(btw, the refs need to be split to normative/informative, and an IPR 
statement needs to be added.)

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 18:52:14 +0300 (EEST)

This is clearer.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 30 Apr 2004 00:16:46 -0400

> I'm skeptical about the usefulness of this approach.

FWIW, I think this was proposed for a couple of reasons:

Once upon a draft, draft-ietf-grow-bgp-redistribution-00.txt tried
to formalize some very common bgp policy that communities are
used for.  Specific examples are:

proxy as-path prepend
proxy append no-export
proxy append no-announce

filters included:
to an as
to two as's
to a cidr prefix (v4 only)
to a 4byte as

The operations are not novel as the survey that Olivier Bonaventure
and Bruno Quoitin did as part of the original GROW draft.  The 
draft was suggested as a way to take common operational procuedure
and simplify configuration.

The primary objection at the time were:
1. We can't represent ipv6 information due to the length of the 
   extended community.
2. Why don't we just make an uber community and be done with it?

Flexible communities adds this as well as adding the concept of
neighbor classes and being (well...) flexible enough to accomodate
future needs as well as deprecating existing mechanisms.

My personal suggestions:
o Is the underlying functionality useful regardless of the encoding?
o If so, is the encoding clean enough or potentially too cumbersome?
o Should we keep the encoding of things like route-target, etc. out
  of this?

> for better alignment.

I thought this had been mentioned at SF IETF. :-)

> Length could also include the ASN field. (Maybe 

Perhaps it would be better to simply strip any 4byte ASes upon export
when 4byte ASes aren't supported.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 30 Apr 2004 00:16:46 -0400

proxy as-path prepend
proxy append no-export
proxy append no-announce

filters included:
to an as
to two as's

My personal suggestions:

-- 
Jeff Haas 
NextHop Technologies