Abha,
>
> As co-chair of this group, I'd thought I'd post a message to address some
> of the concerns being expressed on the list so that everyone is on the
> same page.
>
> This group has been around and idle for some number of years, and since
> Sean and I have become co-chairs, more activity has occured than in its
> past history. But, it seems that a lot of folks are wondering "what is
> going on here?" and have a lot of concerns as to how issues such as
> scalability, convergence, routing table size and future routing protocol
> possibilties are going to be addressed...
>
> All of these are valid issues and are definitely in the priorties as I see
> them for this group.
>
> To start things moving, a smaller group has been formed to do a
> requirements/framework doc. Sean and I believe that the folks in this
> team reflect a valid cross-section of people in the community who are
> capable and willing to address these issues. Once the doc is written, it
> will be posted back to the entire group for modifications/feedback. As
> this a group process, everyone's participation is encouraged for this. No
> one should feel excluded.
I would be happy to contribute to this work, I think that the framework document
should try to separate the issues in short term problems that could be fixed
with small changes to BGP and longer term problems that need more significant
changes.
Concerning the short term problems, we should probably document all the "pathological"
usages of BGP features and explain their impact on the global Internet, e.g. :
1. prepending multiple time its own AS number to announced routes in order to
indicate a low quality route
Wouldn't it be cleaner to have a well-known preference attribute in the BGP routes ?
2. cutting a subnet into several pieces in order to perform traffic engineering works for
some AS, we should document its negative impact on the global routing tabl
3. the example cited by geoff huston showing that a short route measured in AS
hops is not necessarily a short route measured in milliseconds.
We might envisage defining some additional attributes to BGP to indicate
values like the propagation delay towards a given prefix
4. the changes in routing policies allow AS to engineer their interdomain traffic,
but have a negative impact on the stability of the interdomain routing
We should also try to identify the problems that are not solved today with existing
BGP features, e.g. :
1. I know several AS who would appreciate to control the routes followed by their
incoming traffic, not only their outgoing traffic. For example,
2. Diffserv and intserv have been defined by IETF, but routing is still essentially
only best-effort routing
Olivier
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT