Subject: [GROW] International communities proposal

From: "Teplov, Matvey" <[email-masked]>
Date: Mon, 16 Jul 2007 10:00:28 +0200

Hi,

 As you know BGP works on the 8th and 9th level of the OSI model (financial
and political) and process of influencing routing decisions is not
transparent to the another party at all. For example we can start sending
traffic over the local peering and return one will come back into our
network via transatlantic (SP A routing policies) or will have equal
advertisements all over the place (SP B), etc, etc, etc. This geographic
independency severely impacts routing decisions as the traffic crosses from
ISP to ISP. There is no way for the ISP to tell where the route has been
originated as it is completely hidden in the originator environment.      
 It will be possible to make alter if necessary routing decisions if some
attribute will be applied to the prefix at the moment it is originated.
Addition of such should be harmless to the routing tables and
vendor-software as it should utilize existing install base and be completely
optional. 

 By adding one or more globally-defined community attributes to prefix we
will be simplifying traffic management decision by providing some
geographical link for the ISP's to work with. Special high-order two-byte
value can be allocated to be used universally, while two low-order bytes can
be used to provide more granular designation. In addition to this well
intra-provider defined policies will help in route oscillation as clear
intra-ISP preferences can be defined.

Following additions can be considered as well:
 - Values to describe the originator's continent (to prevent excessive use
of the community lists in order to determine the destination - will ease
implementation - can be considered as a short version of described above)
 - Values to describe preferred continent to receive the traffic via (for
example African/Oceania ISP can prefer to receive it via States rather than
Asia or Europe).

Policies itself can be purely ISP-specific and will stay beyond the scope of
this document. Impact will be zero as the values to be chosen will most
likely not be in use and if they will it will be as low as possible.

Please let me know what your thought are.

Best regards Matvey Teplov 

-------------------------------------
Senior Network Engineer
UPC Advanced Networks Support Team
Telephone: +31 (0)20 778 8608
Mobile:    +31 (0)62 705 1273
Chello broadband
Koningin Wilhelmina Plein 2-4
Amsterdam, 1062HK
The Netherlands

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

---

From: Simon Leinen <[email-masked]>
Date: Tue, 17 Jul 2007 21:48:55 +0200

There's RFC 4384, "BGP Communities for Data Collection", D. Meyer,
February 2006.  It describes BGP community conventions that encode
geographic origin, among others.

(The issue is how to convince ISPs to use this.)
-- 
Simon.

---

From: David Meyer <[email-masked]>
Date: Tue, 17 Jul 2007 13:43:20 -0700

> Please let me know what your thought are.

	Well, lets see. I wrote up a BCP on precisely this topic
	some time ago (RFC 4384, "BGP Communities for Data
	Collection"). The original idea there was to try to
	standardize the meaning(s) of the various communities we
	were getting from routeviews peers. It would also allow
	us to have some standardization across collection
	projects (e.g., RIPE/RIS).

	Now, some folks have used the 4384 for their internal
	use (generally in greenfield deployments), but AFAIK 4384
	hasn't really caught on. One obvious reason is that it
	does expose information that someone may rather not
	expose. Another is that most folks have their community
	encodings in place, so changing all of that (even if one
	wanted to) would be a serious task. 

	Dave

---

From: "Christopher Morrow" <[email-masked]>
Date: Tue, 17 Jul 2007 21:43:30 -0400

> (The issue is how to convince ISPs to use this.)

and how to convince them to pass communities across AS boundaries...