Geography doesn't matter very much. I don't connect to the people across
the street. Bandwidth, latency, traffic do matter, but BGP is path
oriented. Hence we analyze flow data to figure out who we are
exchanging traffic with, and reduce costs to those AS's. Maybe BGP got
it wrong on what is important in a routing decision.
Of course, politics is important, too. For example, the political layer
prevents this message from going to the GROW list, even though the
persons who blacklisted me have since been discredited, and I have since
been vindicated. This leads others to muse that the one asset that a
standards organization has is integrity, and without integrity, they
have nothing. The IETF has loyalty, rather than integrity and honesty.
However, loyalty doesn't make routers work or routing protocols route.
Loyalty also doesn't long sustain a standards organization.
--Dean
On Tue, 17 Jul 2007, David Meyer wrote:
> 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
>
>
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
GROW mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/grow
