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 PROTECTED] > > Sent: 17 July 2007 22:43 > > To: Teplov, Matvey > > Cc: '[email protected]' > > 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 protected] > https://www1.ietf.org/mailman/listinfo/grow > > _______________________________________________ GROW mailing list [email protected] https://www1.ietf.org/mailman/listinfo/grow
