Subject: grow: draft-meyer-collection-communities-00.txt updated

From: David Meyer <[email-masked]>
Date: Tue, 28 Oct 2003 15:48:33 -0800

http://www.1-4-5.net/~dmm/draft-meyer-collection-communities-00.txt

 Comments greatly appreciated.

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

---

From: Geoff Huston <[email-masked]>
Date: Wed, 29 Oct 2003 11:52:30 +1100

>  Comments greatly appreciated.

Thanks for adding the extended community section!

   Geoff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 29 Oct 2003 10:24:25 -0500

>  Comments greatly appreciated.

Very cleanly written.

I'm somewhat concerned that normal operational practices may make
these communities a bit less useful.  Mostly I'm speaking of
the practice several ISP's take in stripping all communities
that aren't theirs on ingress or deleting everything they're
not attaching themselves on egress.

I don't have a list of people who do this, but this seems to have
been mentioned more than a few times on NANOG.  Some people are
also under the impression that having no or fewer communities
helps their routers scale better.

-- 
Jeff Haas 
NextHop Technologies

---

From: David Meyer <[email-masked]>
Date: Wed, 29 Oct 2003 09:02:23 -0800

>> Thanks for adding the extended community section!

	My pleasure. Thanks for the comments.

	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 29 Oct 2003 09:18:14 -0800

>> >  Comments greatly appreciated.

        Thanks.

>> not attaching themselves on egress.

        Very true. The objective, however, is to get a standardized 
        set that folks can use in the event they want to provide
        that information for operational or research purposes. I
        know that several service providers already send
        communities with similar semantics, although in many
        cases those semantics are not documented.

>> helps their routers scale better.

        Also true. Originally, my idea was that these would
        be used on egress (outbound) only, and only for route
	collectors. However (and to your point and somewhat
	surprisingly), more than a few folks contacted me and
	said that this may be that this set is a useful set for
	their internal ops as well. 

	FWIW, there are a few communities that seem to be (are)
	de-facto standard, ignoring for the moment the
	definitions of transit, non-transit, and peer, e.g.,  

         Transit:       <AS>:999
         Non-transit:   <AS>:666
         Paid peer:     <AS>:666 + <AS>:667

        The folk wisdom here is that these originated at UUnet
        some years ago. 

        Thanks for the comments,

        Dave

        [BTW, does anyone have an authoritative reference for the
        International Country Calling Codes that is better than
        the one I used (just the ITU web site)? Thanks -- Dave]
____________________________________________________________
Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/

---

From: john heasley <[email-masked]>
Date: Wed, 29 Oct 2003 09:37:55 -0800

> helps their routers scale better.

I did this at verio.  I question what implementations do if/when
enough communities are added to exceed the packet size limit.
anyone?

---

From: Pekka Savola <[email-masked]>
Date: Wed, 29 Oct 2003 20:09:14 +0200 (EET)

> not attaching themselves on egress.

We certainly do this (well, we only strip out everything at egress), and
see nothing wrong in it.  Just a standard route advertisement cleanup
procedure, like applying ingress/egress filtering at the borders.

The reason we do it is because we zero need for those communities 
propagating.  Typically nobody is interested in them wherever they're sent 
-- they've already exceeded their "domain of applicability".

But then again, we aren't a real backbone transit ISP, just a NREN, so the
practices and applicability is certainly quite different in some other
networks.

-- 
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: Jeffrey Haas <[email-masked]>
Date: Wed, 29 Oct 2003 13:47:11 -0500

> enough communities are added to exceed the packet size limit.

One of the major hazards of adding in-transit things like this is
it reduces the ability of BGP to pack packets well.  This means
that more packets need to be created for essentially related
reachability.  

Parsing of a packet is a costly operation in BGP.  Among other
things, for each additional packet you need to parse, you incur
additional policy overhead.  The BGP spec goes out of its way
to encourage people to pack stuff as tightly as possible.

I would make the general assertion (but it will vary based on
implementation) that parsing of community-like attributes is one of
the more costly bits of parsing the packet.  Policy on communities
certainly is pretty expensive compare to, say, policy on a prefix
or a scalar value like a MED.  It should be comprable to policy
on an AS Path.

As to what an implementation does when some attribute may cause 
the PDU to exceed 4K - that is implementation specific.  AS Paths
could cause this just as easily due to set-based aggregation.
Communities just ask for this to happen more.

What you're forcing is for your implementation to make a choice.
As long as you include all required things, anything that is optional
would be a good candidate to toss.  Thus, if you have more path
attributes than would allow for even a single NLRI, you could (e.g.)
1. Not send that PDU.
2. Toss something that is optional in the path attributes
3. Crash. :-)

3 is all too popular.  I've sometimes wondered if this is part of
the reason people clean up after themselves.

I would love to see a vendor knob that allows you to implement:
1. Strip all not-your communities on AS ingress.
2. Strip all of your internal communities on AS egress.

---

From: john heasley <[email-masked]>
Date: Wed, 29 Oct 2003 10:55:15 -0800

> that more packets need to be created for essentially related

right, concern #3.

> or a scalar value like a MED.  It should be comprable to policy

esp. ext communities.

> Communities just ask for this to happen more.

right, concern #1 & 2.  1) malicious or accidental community (or aspath)
bloat over 4k from customer/peer, what happens?  is the route sent?  and
2) community bloat approaching 4k, what happens when I try to add new
communities?

> 2. Toss something that is optional in the path attributes

uh, i dont want some route floating around my ibgp that lacks tags
on which i base my routing policy.  artificial "dampening" (or otherwise
not usable) would be a better solution.

> 2. Strip all of your internal communities on AS egress.

community regex!

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 29 Oct 2003 14:02:05 -0500

> bloat over 4k from customer/peer, what happens?  is the route sent?  and

Well, who cares?  If you're getting crap from a neighbor, trash it.

My favorite "attack" that I haven't actually heard of happening
(I'm not in operations these days) is artificially
putting an AS into the path to make sure that the remote AS never
gets that route.  I've often thought it would be a good way to
remotely disconnect someone who is sending you "bad stuff", like
a DoS attack.  This presumes no default though.  :-)

> 2) community bloat approaching 4k, what happens when I try to add new

1, 2 or 3. :-)

> not usable) would be a better solution.

Then you have a strong need to make sure you have room.  The simplest
way to guarantee that is to toss communities that you learn
externally that aren't internal control communities.

> community regex!

As I mentioned, about as complex as aspath-regex.

---

From: Joe Abley <[email-masked]>
Date: Wed, 29 Oct 2003 14:27:59 -0500

> (I'm not in operations these days) is artificially

I did this as a customer of 1221, to prevent a prefix propagating 
towards particular transit providers of 1221, whilst still otherwise 
propagating to adjacent ASes (the intention, if I remember correctly, 
was to try and provide "Australian transit" to a customer in New 
Zealand.

There were no mechanisms in place within 1221 at the time to let 
customers specify such policy, and getting mechanisms added would have 
taken a long time.

The prepend hack worked very nicely in this case. I would be amazed if 
I am the only person who ever did that.

> a DoS attack.  This presumes no default though.  :-)

It also presumes that the attack won't re-route if you poison a single 
path (although maybe even if it does, there are circumstances where 
this could be useful).

Joe

---

From: john heasley <[email-masked]>
Date: Wed, 29 Oct 2003 12:20:04 -0800

> > 2) community bloat approaching 4k, what happens when I try to add new

door #1, monte.

> externally that aren't internal control communities.

without knowing what implementations do in these cases, I'm forced to
protect myself by dropping communities that I do not recognize (ie:
accept from customers to affect my routing policy, like local-pref
adjustment).

---

From: Geoff Huston <[email-masked]>
Date: Thu, 30 Oct 2003 08:44:33 +1100

>         the one I used (just the ITU web site)? Thanks -- Dave]

The ITU web site is, as I understand it, authoritative for most things. The 
exception I'm
aware of is the code used by international gateways to access Taiwan.

    Geoff

---

From: "Henk Uijterwaal (RIPE-NCC)" <[email-masked]>
Date: Fri, 31 Oct 2003 12:58:52 +0100 (CET)

>         the one I used (just the ITU web site)? Thanks -- Dave]

The document is called "Complement to ITU-T recommendation E.164".

Minor detail: Since the registries tend to use ISO 3166-2 country codes
for almost everything, wouldn't it make more sense to use those instead of
E.164 ICCC's? ISO3166-2 can be mapped onto small integers by substracting
64 from the ASCII code of the 2 letters, then do 27*first+second.  The
community value would be:

 <AS>: (27*first)+(second)

I'm afraid that otherwise we all end up coding E.164-ICCC to ISO-3166-2 CC
and back translation routines.

Henk

------------------------------------------------------------------------------
Henk Uijterwaal                             Email: [email-masked]
RIPE Network Coordination Centre            WWW: http://www.ripe.net/home/henk
P.O.Box 10096          Singel 258           Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam    Fax: +31.20.5354445
The Netherlands        The Netherlands      Mobile: +31.6.55861746
------------------------------------------------------------------------------

That problem that we weren't having yesterday, is it better? (Big ISP NOC)
____________________________________________________________
Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/

---

From: David Meyer <[email-masked]>
Date: Fri, 31 Oct 2003 07:37:14 -0800

>> and back translation routines.

	Good suggestion. I'll change that.

	Thanks, 

	Dave

---

From: David Meyer <[email-masked]>
Date: Fri, 31 Oct 2003 08:14:30 -0800

On Fri, Oct 31, 2003 at 11:01:07AM -0500, Joe Abley wrote:
>> 
>> On 31 Oct 2003, at 10:37, David Meyer wrote:
>> 
>> There is some redundancy ISO-3166, and hence there is not always a 
>> unique choice of country identifier for any particular country.
>> 
>> For example, a route learnt in London, England could be encoded using 
>> the iso-3166-2 scheme above as N:191 (GB) or N:578 (UK). If EU gets 
>> assigned for Europe, this would provide another opportunity for 
>> overlap.
>> 
>> This doesn't seem like a big problem, but it's worth noting in the 
>> fraft for the benefit of people who want to decode these communities, I 
>> think.

	Thanks. Will note. BTW, is there a reason not to just use
	the 3 digit the numeric code, e.g. as listed 
	ftp://ftp.ripe.net/iso3166-countrycodes.txt?

>> Incidentally, the E164 addressing plan also has the disadvantage that 
>> it does not accommodate Taiwan nor any of the different countries who 
>> participate in the NANPA (+1).

	Yep, I noticed that too.

	Dave

---

From: Joe Abley <[email-masked]>
Date: Fri, 31 Oct 2003 11:19:12 -0500

On 31 Oct 2003, at 11:14, David Meyer wrote:

>          BTW, is there a reason not to just use

Ah! I didn't even know the numeric code existed. That looks like a much 
better solution than deconstructing the two-character code into 
something numeric.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 31 Oct 2003 11:01:07 -0500

Joe

---

From: [email-masked]
Date: Fri, 31 Oct 2003 17:42:42 +0100

>         ftp://ftp.ripe.net/iso3166-countrycodes.txt?

As far as I know (please correct me if I'm wrong) the 3 digits numeric code
identifies a physical territory, and the letters a country name.
Should'nt be better to be country name independant and to use numeric values.

Regards

--
Olivier Marce

---

From: Sean Donelan <[email-masked]>
Date: Fri, 31 Oct 2003 12:24:51 -0500 (EST)

> Should'nt be better to be country name independant and to use numeric values.

The ISO two character, three character and numeric country codes have the
same maintenance process and all identify the same thing.  They are intended
to be used interchangebly by applications which need an all numeric code
or alphabetic code.

When politics gets involved, things always get strange.  The Internet has
more history using the ISO country codes, so I suggest using it.  It will
make it easier to map between DNS TLDs and BGP country communities.  On a
practical level, it doesn't really matter because all the identification
standards have quirks.

---

From: David Meyer <[email-masked]>
Date: Fri, 31 Oct 2003 09:39:55 -0800

>> practical level, it doesn't really matter because all the identification

Seems like we need to just choose one. Let's stay with the ISO
country codes, as Sean (and Henk) suggest. Dave
____________________________________________________________
Web Archive:     http://darkwing.uoregon.edu/~llynch/grow/