Subject: [GROW] RE: GROW Digest, Vol 8, Issue 6

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

Hi,

So the way I see it nobody have anything more to object. The further action
will be then from me to wrap it up into the document and, after your
approval, try to get IANA's assigned two high-order community bytes.

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: [email-masked] [mailto:[email-masked]] 
> Sent: 18 July 2007 23:08
> To: [email-masked]
> Subject: GROW Digest, Vol 8, Issue 6
> 
> Send GROW mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www1.ietf.org/mailman/listinfo/grow
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more 
> specific than "Re: Contents of GROW digest..."
> 
> 
> Today's Topics:
> 
>    1. RE:  International communities proposal (Michael Hallgren)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 18 Jul 2007 23:09:05 +0200
> From: "Michael Hallgren" <[email-masked]>
> Subject: RE: [GROW] International communities proposal
> To: "'Teplov, Matvey'" <[email-masked]>,	"'David Meyer'"
> 	<[email-masked]>
> Cc: [email-masked]
> Message-ID: <008d01c7c97f$e0438760$0300a8c0@HOME>
> Content-Type: text/plain;	charset="us-ascii"
> 
> 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:
> > 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.
> 
> >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
> 
> > -------------------------------------
> > 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
> > 
> > 
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/grow
> 
> 
> End of GROW Digest, Vol 8, Issue 6
> **********************************
> 

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