Subject: RE: [GROW] International communities proposal

From: "Teplov, Matvey" <[email-masked]>
Date: Wed, 18 Jul 2007 10:52:25 +0200

David,

I saw this one, and it is great, one problem associated with it though - too
much is encoded as well as the AS number of the originator is used. Why it
posses the problem:
1) Most of the people are really bad with the regular expressions and it
takes quite a while to explain it to them
2) This encoding can (and most likely will) cross with the existing one in
any operator's network, so it will take some time to implement them -
man-hours. You will never convince business to implement them unless they
will really require to do so.
3) ISO codes are non-recognizable by most people and will require them to
have a reference - another human factor. I didn't see these numerical values
anywhere, whereas you will not be able to encode characters into the
community value neither - hence quite limited usage.

Alternative is to have separate high-order bits defined and use E.164 codes
to make sure that you covered it all. There are several ways of encoding
region:
1) Use another high-order portion
2) Ask ITU-T to reserve five values - I'm not sure wherever that will be
possible, but if somebody assist to push it through that will be highly
appreciated. Range from 693 till 699 can be used for example. To be honest
I'm surprised they didn't do it already.
3) Use most left number in last two bytes value (almost the same as you
did), so community will look like: IANA:RCCC, where IANA is an IANA assigned
part, R is a region and CCC is the E.164 identifier.

 About how to enforce "them": When the user is complaining to ISP about
receiving traffic via another sub-optimal path the ISP will be asking
another ISP why it is so, so that will result in some and some temporary
patch. More patches there are better it is because it becomes unmanageable
and, as the result, way too complex. There are two ways out of it - define
set of rules that will suit only you, but then you will be facing the same
issue, or, alternatively, define set for everybody and that will remain. 

 The thing you proposed is really close to ideal one, but during the
greenfield installations only, which almost never is the case, so if we will
update it with the numbering plan of E.164 and some reserved ASN part it
will be fine. 

Best regards Matvey Teplov 

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

> -----Original Message-----
> From: David Meyer [mailto:[email-masked]] 
> Sent: 17 July 2007 22:43
> To: Teplov, Matvey
> Cc: [email-masked]'
> Subject: Re: [GROW] International communities proposal
> 
> On Mon, Jul 16, 2007 at 10:00:28AM +0200, Teplov, Matvey wrote:
> > 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.
> 
> 
> 	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
>  
> 

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

---

From: "Michael Hallgren" <[email-masked]>
Date: Wed, 18 Jul 2007 23:09:05 +0200

Hi,

> 
> David,
> 
> 
> I saw this one, and it is great, one problem associated with 
> it though - too much is encoded as well as the AS number of 
> the originator is used.

Shared view.

> Why it posses the problem:
> 1) Most of the people are really bad with the regular 
> expressions and it takes quite a while to explain it to them

Far from rocket sci... and understanding of such likely a fair pre-req for
using
this set of buttons... Right?

> 2) This encoding can (and most likely will) cross with the 
> existing one in any operator's network, so it will take some 
> time to implement them - man-hours. You will never convince 
> business to implement them unless they will really require to do so.

Right. Some (or many) of us -- I'm rep. AS6453 -- implemented similar
schemes
quite some time ago. The main rationale of "touching" the current
implementation
would be "AS transitive use"... 

> 3) ISO codes are non-recognizable by most people and will 
> require them to have a reference - another human factor. I 
> didn't see these numerical values anywhere, whereas you will 
> not be able to encode characters into the community value 
> neither - hence quite limited usage.
> 
> Alternative is to have separate high-order bits defined and 
> use E.164 codes to make sure that you covered it all. There 
> are several ways of encoding
> region:
> 2) Ask ITU-T to reserve five values - I'm not sure wherever 
> that will be possible, but if somebody assist to push it 
> through that will be highly appreciated. Range from 693 till 
> 699 can be used for example. To be honest I'm surprised they 
> didn't do it already.
> 3) Use most left number in last two bytes value (almost the 
> same as you did), so community will look like: IANA:RCCC, 
> where IANA is an IANA assigned part, R is a region and CCC is 
> the E.164 identifier.

>From what I see around is for quite obvious reasons merely "encoding
differences", so - yes - if we define a common encoding space...

> 
>  About how to enforce "them": When the user is complaining to 
> ISP about receiving traffic via another sub-optimal path the 
> ISP will be asking another ISP why it is so, so that will 
> result in some and some temporary patch. More patches there 
> are better it is because it becomes unmanageable and, as the 
> result, way too complex. There are two ways out of it - 
> define set of rules that will suit only you, but then you 
> will be facing the same issue, or, alternatively, define set 
> for everybody and that will remain. 

... we might win the war against "temporary or private hacks". Good thing,
because the end user (downstream AS) would benefit from less complex policy
statements. Hmmm,... We (ISPs/Carriers) tend to want to have freedom (used
or 
not) about the granularity of policy influence we provide... and freedom of
choice wrt transitivity...

> 
>  The thing you proposed is really close to ideal one, but 
> during the greenfield installations only, which almost never 
> is the case, so if we will update it with the numbering plan 
> of E.164 and some reserved ASN part it will be fine. 
> 

Yes. A good basis for discussion.

> Best regards Matvey Teplov 

Cheers,

mh