Subject: grow: interesting idea for collection communities encoding...

From: David Meyer <[email-masked]>
Date: Fri, 5 Dec 2003 08:40:04 -0800

Folks,

	I've been trying to design a more compact (but still
	meaningful) encoding for the collection communities. 

	The idea described in this note germinated from an
	interesting conversation I had with Kato-san at
	WIDE. Now, understanding that we don't [yet?] have 
	bitwise comparisons on community strings, the idea would
	be to use the collection community values to select
	paths that would result in (hopefully) more efficient
	access to various services. For example, in the case of
	RFC3258 based DNS anycast service, BGP routers may see
	multiple paths to the same prefix, and others might be
	coming from the same origin with different paths, but
	others might be from different region/country (with the
	same origin AS).   

	The basic idea is that it might we might want to be able
	to write the "prefer-region-over-<other attribute>" or 
	"prefer-country-over-<other attribute>" route selection
	config (e.g.. route-map) at some point in the future. 

	All that being said, in the scheme below, <CC> is (binary
	representation of the) country code (0 <= CC <= 1000
	decimal), and <X> is 1 if satellite link, 0
	otherwise. That is:   

  Reserved                                 <AS>:0000000000000000
  Customer Routes                          <AS>:0000000000000001
  Peer Routes                              <AS>:0000000000000010
  Internal Routes                          <AS>:0000000000000011
  Internal More Specific Routes            <AS>:0000000000000100
  Special Purpose Routes                   <AS>:0000000000000101
  Upstream Routes                          <AS>:0000000000000110
  Reserved                                 <AS>:0000000000000110-0000111111111111
  National and Regional Routes             <AS>:0001000000000000-1111111111111111
   Africa (AF)                             <AS>:0001<X><CC>
   Oceania (OC)                            <AS>:0010<X><CC>
   Asia   (AS)                             <AS>:0011<X><CC>
   Antarctica (AQ)                         <AS>:0100<X><CC>
   Europe (EU)                             <AS>:0101<X><CC>
   Latin America/Caribbean islands (LAC)   <AS>:0110<X><CC>
   North America (NA)                      <AS>:0111<X><CC>
   Reserved                                <AS>:1000000000000000-1111111111111111

	So the basic format looks like:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            <AS>               |   <R>   |X|        <CC>       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	where 

	<AS> is the 16-bit AS
	<R>  is the 5-bit Region code
	<X>  is 1-bit satellite link indication (1 if satellite link, 0 otherwise)
	<CC> is the 10-bit ISO-3166-2 country code

	For Customer, Peer, Internal, Internal More Specific,
	Special Purpose, and Upstream Routes, <R> and <X> are
	both 0. For National and Regional routes, R and X have
	the values specified above.
	
	For example, the encoding for a national route over a terrestrial
	link in AS 10876 from the Fiji Islands would be:

	<AS>  = 10876 = 0x2A7B
	<R>   = OC = 0010
	<X>   = 0x0
	<CC>  = Fiji Islands Country Code = 242 = 0011110010

	making the low order 16 bits look like 001000011110010 = 0x10F2

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           0x2A7C              |           0x10F2              |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

	Finally, a config language might allow you to code
	something like 10876:4338 (0x1F2 == 4338 decimal) to tag
	this route.

	Thoughts/comments?

	Dave

____________________________________________________________
Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/

---

From: David Meyer <[email-masked]>
Date: Fri, 5 Dec 2003 09:09:21 -0800

s/0x1F2/0x10F2

Sorry about that.

Dave

---

From: Vijay Gill <[email-masked]>
Date: Fri, 5 Dec 2003 12:45:10 -0500

> 	RFC3258 based DNS anycast service, BGP routers may see

Dave, the problem is that a lot of the community tagging is encoded using
policy (router policy like route-maps etc) and changing huge amounts of
policy is a very hard job.  I have been at places where we have done
wholesale policy rewrites and they are the equivalent of changing the
tires on a fast-moving car.

I am not saying that the idea is bad, but I am saying that this may not be
a feasible to deploy one and the resources in this may best be directed
elsewhere, where there is more chance of seeing deployment.

/vijay

---

From: Vijay Gill <[email-masked]>
Date: Fri, 5 Dec 2003 13:11:16 -0500

On Fri, 5 Dec 2003, Jeffrey Haas wrote:

> Vijay,
>
> On Fri, Dec 05, 2003 at 12:45:10PM -0500, Vijay Gill wrote:
> Not that I'm disagreeing with you, but this really argues that our
> policy mechanisms could be better.

Our policy mechanisms encode our business models, and no matter how
flexible the policy mechanisms are, the fact that they have to scale, be
easy to understand and maintain, and troubleshoot really limits what can
be done.  Eg, no matter how easy our policy mechanisms are or how
flexible, changing ~500 peering policies across a network is just not
going to be very easy, esp when you have to coordinate changing 100k
customer maps as well.  There are maybe 2 large NSPs who have this
automated, most are still doing this by hand/ custom scripts.

To really make this work would require a groundup change in router policy,
because currently all we have are hammers, so everytyhing looks like a
nail.

/vijay

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 5 Dec 2003 13:05:37 -0500

Vijay,

-- 
Jeff Haas 
NextHop Technologies

---

From: David Meyer <[email-masked]>
Date: Fri, 5 Dec 2003 10:18:25 -0800

>> because currently all we have are hammers, so everytyhing looks like a

	Does all of that that argue that a standarized way of
	describing these kind of properties isn't feasible in
	general? 

	Dave

---

From: Vijay Gill <[email-masked]>
Date: Fri, 5 Dec 2003 13:22:09 -0500

> 	describing these kind of properties isn't feasible in

Not at all. The point is that the cost/benefit tradeoff on spending time
on something that will probably see very limited deployment vs spending
the same time somewhere else like reworking policy mechanisms and an
encoding/extension to automagically push out rulesets ;)

/vijay

---

From: David Meyer <[email-masked]>
Date: Fri, 5 Dec 2003 10:14:34 -0800

>> tires on a fast-moving car.

	Been there. Completely agree.

>> elsewhere, where there is more chance of seeing deployment.

	No argument with any of the above. The interesting thing
	to me is that:

	(i).	The encodingn is more or less arbitrary (just
		like any of the internal communities that one
		might use), and so this is just one such scheme.

	(ii).	I orginally envisioned this (more or less) for
		export only, so that in the future people could
		have a standardized way of interpreting this
		information in the various routing data
		repositories. This would not necessarily require
		that you change your internal community use (or
		do you disagree).

	(iii).  Many people have asked for a more general scheme
		(like the one I proposed) so the that they could
		use it internally. That is exactly what Kato-san
		asked for (and what resulted in the proposal I
		made). 

	Dave

---

From: "Martin J. Levy" <[email-masked]>
Date: Fri, 05 Dec 2003 10:50:05 -0800

VJ, David,

I would be happy with a two step approach to this (but only if both steps were executed).

1) Provide a repository for bit-pattern definitions of how a specific ASN signals it's routes to the outside world.

2) Provide a programmatic method (and tools?) to generate a route-map (or whatever is needed on whatever platform) that does external-to-internal translation of communities flowing over the wire.

You could claim that #1 is already there because a random query into a RADB will show, in text form, how a specific signals it's routes.  It also shows how a customer controls it's routes, but that's outside of the scope of this thread.  The issue is that the format and consistency is just not there!

You could claim that #2 is not needed if we all worked with one standard (i.e. What David has laid out) and hence we could all have one "default" set of configs.  Alas... I agree with VJ it's beyond painful trying to make changes at this point.

What's interesting about this is that there is a lot of value to having routes "tagged" with this information, but nearly always for customers outside of the core high-bandwidth arenas.  In those cases, deciding which route to use from which provide is a cost-conscious choice.  For places like that, it's more than useful to have both a defined format and have it implemented.

BTW:  AS-6762 (Telecom Italia SEABONE) uses country codes, but they really are a pain to use within a 32 bit community element.  Variable length decimal strings just don't seems to match into bit-wise setups. :-(  (Not that I have a better idea).

Martin

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

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 5 Dec 2003 14:04:55 -0500

> 	describing these kind of properties isn't feasible in

Having not been an operator for a big network, I might be off base here.
However, having the standard description is less of an issue as your
way of configuring your policy.

Take the simple example of "this route matches property foo, take this
action".

In cases where the action can be described in if then else terms,
it can be very awkward to take existing routemap structures and
wedge something in, especially in a non-disruptive fashion.
It would be better if you could simply do:

if (match property) 
   then
      do action;
      continue next policy element;

This way, something like adding the additional community is non-disruptive.

This isn't to say that changing your policy logic will always be 
non-disruptive, but it is pretty annoying to do right now.

---

From: David Meyer <[email-masked]>
Date: Fri, 5 Dec 2003 11:10:56 -0800

>> non-disruptive, but it is pretty annoying to do right now.

	I think we agree that large-scale config changes of
	almost any kind are, in most cases, prohibitively painful
	(for some value of large-scale). But all of that is
	independent of the scheme presented here, as converting
	to any scheme which isn't the one you're using (and no
	one or at least very few folks are using the same one)
	triggers your argument, wouldn't you say?   

	Dave

---

From: Vijay Gill <[email-masked]>
Date: Fri, 5 Dec 2003 15:04:24 -0500

> non-disruptive, but it is pretty annoying to do right now.

the devil is in the details.  How do you do (match property) and to be
specific, fill in "property." Hard to do across various route sets, esp.
as exception policy is fairly common, if nothing else, for traffic
engineering. Eg. this link with provider X is overloaded, randomly take a
set of prefixes and localpref them to 99 and see if the outgoing traffic
migrates to another presumably less loaded link with the same isp. Or
selectively prepend our AS to certain prefixes we announce to direct
incoming traffic to other links.

These sort of things make a generic policy mapping very hard to implement.

/vijay