Subject: Re: Additional language for UPDATE processing?
From: "Benjamin Black" <[email-masked]>
To: "Abha Ahuja" <[email-masked]>, "Benjamin Black" <[email-masked]>
Cc: <[email-masked]>
Date: Sun, 26 Dec 1999 13:14:57 -0800

The MinRouteAdvertisementInterval definition includes the following:

   To avoid long-lived black holes, the procedure does not apply
   to the explicit withdrawal of unfeasible routes (that is, routes
   whose destinations (expressed as IP prefixes) are listed in the
   WITHDRAWN ROUTES field of an UPDATE message).

This specifically allows ordering problems to occur.  If there were either a
strict ordering requirement for evaluation of the components of an UPDATE or
the withdrawal procedures were more specific (specifying that *exactly* one
of the allowed withdrawal mechanisms be used), then the problem is avoided.

Ben

>
> I believe that issues that arise from "ordering of events" are handled
> through the use of the MinRouteAdvr timer.
>
> -abha ;)
>
>
> On Sat, 25 Dec 1999, Benjamin Black wrote:
>
> > In section 9 of draft-ietf-idr-bgp4-09.txt, there is no indication that
the
> > order of the processing events is relevant (at the very least, withdrawn
> > routes should be processed before new routes).  Is this simply too
obvious,
> > or would some additional language indicating the ordering requirements
help?
> >
> >
> > Ben
> >
> >
> >
> >
>
> __________________________________________________________________________
> --------------------------------------------------------------------------
> abha ahuja [email-masked]
> Merit Network, Inc. 734.764.0294
>
>

Date: Sun, 26 Dec 1999 03:42:00 -0500 (EST)
From: Abha Ahuja <[email-masked]>
To: Benjamin Black <[email-masked]>
Cc: [email-masked]
Subject: Re: Additional language for UPDATE processing?
Sender: [email-masked]

I believe that issues that arise from "ordering of events" are handled 
through the use of the MinRouteAdvr timer. 

-abha ;)

On Sat, 25 Dec 1999, Benjamin Black wrote:

> In section 9 of draft-ietf-idr-bgp4-09.txt, there is no indication that the
> order of the processing events is relevant (at the very least, withdrawn
> routes should be processed before new routes).  Is this simply too obvious,
> or would some additional language indicating the ordering requirements help?
> 
> 
> Ben
> 
> 
> 
> 

__________________________________________________________________________
--------------------------------------------------------------------------
abha ahuja						[email-masked]
Merit Network, Inc.					734.764.0294

Reply-To: "Benjamin Black" <[email-masked]>
From: "Benjamin Black" <[email-masked]>
To: <[email-masked]>
Subject: Additional language for UPDATE processing?
Date: Sat, 25 Dec 1999 20:17:11 -0800
Sender: [email-masked]

In section 9 of draft-ietf-idr-bgp4-09.txt, there is no indication that the
order of the processing events is relevant (at the very least, withdrawn
routes should be processed before new routes).  Is this simply too obvious,
or would some additional language indicating the ordering requirements help?

Ben

Date: Fri, 24 Dec 1999 22:26:32 +0530
From: Anand Kumar Goenka <[email-masked]>
Organization: Motorola India Electronics Ltd.
To: [email-masked]
Cc: Anand Goenka <[email-masked]>
Subject: BGP Usage..
Sender: [email-masked]

I have a question regarding BGP Usage...
What are the most common scenarios (network topologies) in which BGP-4
is used today for inter AS routing ??
Any reference to document mentioning the same will be helpfull..

Thanks,
Anand Goenka.
Motorola India Electronics Ltd. (MIEL),
Bangalore.

Date: Tue, 21 Dec 1999 13:44:56 -0800
From: Manoj Goyal <[email-masked]>
To: Ping Pan <[email-masked]>, idr <[email-masked]>
Subject: Re: BGP protocol analysis
Sender: [email-masked]

can u please explain what is meant by 'BGP peer/per net'.
And please throw some light on the way these nubers are
calculated so that we can calculate new numbers based on
some assumptions.
thanks
- Manoj
Ping Pan wrote:
> 
> >
> >    The following table illustrates typical memory requirements of a
> >    router running BGP. It is assumed that each network is encoded as 4
> >    bytes, each AS is encoded as 2 bytes, and each networks is reachable
> >    via some fraction of all of the peers (# BGP peers/per net).
> >    # Networks  Mean AS Distance # AS's # BGP peers/per net Memory Req
> >    ----------  ---------------- ------ ------------------- ----------
> >    2,100       5                59     3                   27,000
> >    4,000       10               100    6                   108,000
> >    10,000      15               300    10                  490,000
> >    100,000     20               3,000  20                  1,040,000
> >
> 
> By the way, this RFC had used the network data before 1995. Since then,
> the AS's has increased linearly
> (http://www.employees.org:80/~tbates/cidr.as.plot.html). Just wondering,
> has anybody collected data on the mean AS distance and BGP peer/per net
> for the current network? These two parameters may have significant
> impact on protocol design and implementation.
> 
> Many thanks in advance!
> 
> - Ping Pan

Date: Mon, 20 Dec 1999 18:10:32 -0800
From: Manoj Goyal <[email-masked]>
To: [email-masked]
Subject: BGP protocol analysis
Sender: [email-masked]

Hi,
following is a paragraph from the rfc 1774 - 
BGP protocol analysis.
section 'Memory requirement' Page 6-7

--------
   To quantify the worst case memory requirements for BGP, denote the
   total number of networks in the Internet by N, the mean AS distance
   of the Internet by M (distance at the level of an autonomous system,
   expressed in terms of the number of autonomous systems), the total
   number of autonomous systems in the Internet by A, and the total
   number of BGP speakers that a system is peering with by K (note that
   K will usually be dominated by the total number of the BGP speakers
   within a single autonomous system). Then the worst case memory
   requirements (MR) can be expressed as

                    MR = O((N + M * A) * K)

                   ......
                   ......

   The following table illustrates typical memory requirements of a
   router running BGP. It is assumed that each network is encoded as 4
   bytes, each AS is encoded as 2 bytes, and each networks is reachable
   via some fraction of all of the peers (# BGP peers/per net).
   # Networks  Mean AS Distance # AS's # BGP peers/per net Memory Req
   ----------  ---------------- ------ ------------------- ----------
   2,100       5                59     3                   27,000
   4,000       10               100    6                   108,000
   10,000      15               300    10                  490,000
   100,000     20               3,000  20                  1,040,000

--------

I could not understand how the figure 'Mem Req' is derived.
as according to the formula ((N + M * A) * K)

for the last entry:
  (100,000 + 20 * 3,000) * 20 = 3,200,000
but the figure shown is 1,040,000.

please tell me whether I am doing some mistake in calculation.
thanks
- Manoj

To: [email-masked]
Subject: Route Refresh to Proposed Standard
Date: Thu, 16 Dec 1999 09:12:50 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,
 
I'd like to start WG Last Call on advancing 
draft-ietf-idr-bgp-route-refresh-00.txt 
to Proposed Standard.

The Last Call ends Dec 30, 1999.

Yakov.     

Date: Thu, 16 Dec 1999 10:19:20 -0500
From: "Ian Duncan" <[email-masked]>
Reply-To: "Ian Duncan" <[email-masked]>
Organization: Nortel Networks
To: Hank Nussbacher <[email-masked]>
Cc: [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

Hank Nussbacher wrote:

> But before investing more work on it - we still need a rough consensus
> whether to accept it as an IDR draft or not.  So far, I would say the
> voting is split.  Need to hear more of the silent voices here.

I support the adoption of your draft as an IDR working group activity.

-- 
_____________________________________________________
 Ian Duncan             <[email-masked]>
 Nortel Networks         +613.765-7945

Date: Thu, 16 Dec 1999 06:59:40 +0200
To: "Alex Zinin" <[email-masked]>, Tony Li <[email-masked]>
From: Hank Nussbacher <[email-masked]>
Subject: Re: Global community values
Cc: [email-masked]
Sender: [email-masked]

At 12:30 14/12/99 +0300, Alex Zinin wrote:
>Tony Li <[email-masked]> wrote:
>
>[snip]
>
>> I have some obvious concerns about how this new item will affect the entire
>> path selection algorithm if there is some scheme for applying these
>> communities that is not the application of explicit policy as you outline
>> in section 5.  In particular, if implementations insert this into path
>> selection at different points, it might lead to inconsistencies.
>
>I also pointed this out in my comments to the draft,
>but somehow that note was left unaddressed.
>Hope Tony's voice will change the situation :)

I would be more than glad to work in inserting text to clear up the matter.
 But before investing more work on it - we still need a rough consensus
whether to accept it as an IDR draft or not.  So far, I would say the
voting is split.  Need to hear more of the silent voices here.

-Hank

>
>-------
>Alex Zinin
>
>

Date: Wed, 15 Dec 1999 22:37:51 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: bradley reynolds <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Global community values 
Organization: Relcom Corp.
Sender: [email-masked]

Moreover, even if 10% of the ISP realize this, the number of existing
_trigger-effect_ problems with the back-ups (when routing by back-up refuse to
return to the normal state after main link restored) decreases a lot.

On Tue, 14 Dec 1999, bradley reynolds wrote:

> Date: Tue, 14 Dec 1999 10:49:11 -0500 (EST)
> From: bradley reynolds <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Global community values 
> 
> > Fortunately, most (all?) deployed implementations allow the operator
> > to simply do_nothing based on the attribute value.
> > 
> > If these are to be new global default communities then a reasonable 
> > implementation might require that one specify whether to enable/disable 
> > honoring these community values, and perhaps configurable parameters for 
> > "avoid/prefer attribute value(s)"
> > 
> to rehash a previous point, if we have random deployment/acceptance of
> this proposal, where is the benefit over current mechanisms?
> 
> BR
> 
> 
> 

Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/

To: "Benjamin Black" <[email-masked]>
Cc: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Global community values 
Date: Wed, 15 Dec 1999 08:59:46 -0700
Sender: [email-masked]

Ideally, MEDs are based on IGP metrics or the like.  Manual manipulation 
doesn't scale.  Most BGP implementations also don't allow the operator to 
simply ignore MEDs.  MEDs are also not effective when considering multi-AS 
path selection.

Worth noting is that no one expects everyone to implement this tomorrow.  If 
you don't like the idea, don't implement it.

I am in agreement that protocol extensions with a more scalable [you define] 
solution would be idea.  But then again, how long until the extensions are in 
code, and how long until folks actually use them?  We can do this today.
 
-danny

> Then why would they be any more willing to implement a new mechanism with
> even less support than MEDs and no additional functionality?

Date: Tue, 14 Dec 1999 10:24:23 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

|  to rehash a previous point, if we have random deployment/acceptance of
|  this proposal, where is the benefit over current mechanisms?

All new mechanisms start off with random deployment and acceptance.  Only
if they prove their worth do they become widely adopted.

It's fairly clear that people are NOT willing to run around and tweak their
MEDs for the sake of the destination domain.  This is to say that the
'current' mechanisms have failed to be useful to provide the requested
functionality.

Tony

Date: Tue, 14 Dec 1999 10:49:11 -0500 (EST)
From: bradley reynolds <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Global community values 
Sender: [email-masked]

> Fortunately, most (all?) deployed implementations allow the operator
> to simply do_nothing based on the attribute value.
> 
> If these are to be new global default communities then a reasonable 
> implementation might require that one specify whether to enable/disable 
> honoring these community values, and perhaps configurable parameters for 
> "avoid/prefer attribute value(s)"
> 
to rehash a previous point, if we have random deployment/acceptance of
this proposal, where is the benefit over current mechanisms?

BR

Date: Tue, 14 Dec 1999 06:54:04 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: D <[email-masked]>
Cc: Tony Li <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: Global community values
Organization: Relcom Corp.
Sender: [email-masked]

We have used different communities (when I worked in Relcom), and usially they
was propogated in order (Relcom - TELIA - UUnet-Euro - UUnet, for example). I
know the networks restricting community propagation, but ot's mo often do not
set such restrictions.

On Mon, 13 Dec 1999, D wrote:

> Date: Mon, 13 Dec 1999 14:24:00 -0500
> From: D <[email-masked]>
> To: Tony Li <[email-masked]>, [email-masked]
> Cc: [email-masked], [email-masked], [email-masked]
> Subject: Re: Global community values
> 
> None of the networks I'm working with (a few tier 1s and multiple regional
> networks) delete communitites by default.  Quite the opposite, in fact.
> 
> -D
> 
> Darrel Lewis
> [email-masked]
> 
> ----- Original Message -----
> From: Tony Li <[email-masked]>
> <snip>
> >
> > If folks out there are deleting communities by default, I agree that would
> > be an issue.  Operational folks, any comments?
> >
> > Tony
> >
> 
> 
> 

Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/

Date: Tue, 14 Dec 1999 07:00:32 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: Benjamin Black <[email-masked]>
Cc: Tony Li <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Global community values
Organization: Relcom Corp.
Sender: [email-masked]

Sorry, I mean 'command'.

> Now try to use MED in the MATCH commend of the Cisco Route-Map. or in the
				  ^^^^^^^

Date: Tue, 14 Dec 1999 06:58:52 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Global community values 
Organization: Relcom Corp.
Sender: [email-masked]

This is just because we proposed this - the whole world tends to began use
community in this manner, but if there is not any (at least, minimal) set of the
standard, well known transitive communities, this mechanisms could not be used.
And it seemd to be just in time - such, very simple, very first step toward the
better network control via the communities, and the first steps in the normal,
filtering mechanisms implemented on the routers.

If we have not any transitive communities _well known_, then we can see a dosen
of different communities doing the same thing (as we have today). We ought to
make the first step, if we want to move forward.

On Mon, 13 Dec 1999, Danny McPherson wrote:

> Date: Mon, 13 Dec 1999 14:21:31 -0700
> From: Danny McPherson <[email-masked]>
> Reply-To: [email-masked]
> To: [email-masked]
> Subject: Re: Global community values 
> 
> 
> > as common routers do not allow one to remove communities in a useful
> > fashion, e.g. one can not
> > 
> >     delete 666:3?? 666:4??
> > 
> > from a peer who one does not wish to have control one's internals,
> > communities are often/usually stripped at the border.
> 
> Fortunately, most (all?) deployed implementations allow the operator to simply 
> do_nothing based on the attribute value.
> 
> If these are to be new global default communities then a reasonable 
> implementation might require that one specify whether to enable/disable 
> honoring these community values, and perhaps configurable parameters for 
> "avoid/prefer attribute value(s)"
> 
> -danny
> 
> 
> 
> 
> 

Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/

Date: Tue, 14 Dec 1999 06:44:42 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: Benjamin Black <[email-masked]>
Cc: Tony Li <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Global community values
Organization: Relcom Corp.
Sender: [email-masked]

Yes.

Now try to use MED in the MATCH commend of the Cisco Route-Map. or in the
gated.conf.

-:)

On Mon, 13 Dec 1999, Benjamin Black wrote:

> Date: Mon, 13 Dec 1999 01:23:59 -0800
> From: Benjamin Black <[email-masked]>
> To: Alex P. Rudnev <[email-masked]>, Tony Li <[email-masked]>
> Cc: [email-masked], [email-masked]
> Subject: Re: Global community values
> 
> 
> > And then, MED's are usially compared after AS-PATH length comparation
> (through
> > it was changed in some versions, if I am not mistaken). Anyway, MED's are
> not
> > transit attributes; if they was, we never propose this draft.
> >
> 
> MEDs can also be used as part of a local policy to set LOCAL_PREF.  As to
> your second assertion, communities are not reliable as transitive attributes
> either.
> 
> >
> >
> > On Sun, 12 Dec 1999, Tony Li wrote:
> >
> > > Date: Sun, 12 Dec 1999 16:25:32 -0800
> > > From: Tony Li <[email-masked]>
> > > To: [email-masked]
> > > Cc: [email-masked], [email-masked]
> > > Subject: Re: Global community values
> > >
> > >
> > > |  I disagree.  In its current form the document does not provide
> functionality
> > > |  beyond that currently provided with MEDs.  Many providers strip
> communities,
> > > |  making the delivery of these global communities values entirely
> random; why
> > > |  not just always compare MED values and be done with it?
> > >
> > >
> > > MED values are only a single AS hop.
> > >
> > >
> > > |  A more useful approach might be to simply use communities for IGP
> cost
> > > |  signalling between ASes.  ASes who wished to participate in the
> process
> > > |  would add their own (normalized) IGP cost to the value signaled by
> the peer.
> > > |  This cost to the next-hop would be announced to external peers.  If
> the cost
> > > |  community is not supported by an AS, it is not propogated.  This can
> be
> > > |  implemented by using local AS communities (rather than global
> communities).
> > > |  The result is similar to DPA, but without the requirement for changes
> to the
> > > |  decision algorithm (how the signaled IGP cost influences path
> selection is
> > > |  entirely based on local policy).
> > >
> > >
> > > And we end up back in the swamp of trying to figure out what the global
> > > metric system should be.
> > >
> > > Tony
> > >
> > >
> >
> > Aleksei Roudnev,
> > (+1 415) 585-3489 /San Francisco CA/
> >
> >
> 
> 

Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/

Date: Mon, 13 Dec 1999 18:11:41 -0500 (EST)
From: Vijay Gill <[email-masked]>
To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

On Mon, 13 Dec 1999, Tony Li wrote:

> If folks out there are deleting communities by default, I agree that would
> be an issue.  Operational folks, any comments?

We do not propogate communities by default.

/vijay

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Global community values 
Date: Mon, 13 Dec 1999 14:21:31 -0700
Sender: [email-masked]

> as common routers do not allow one to remove communities in a useful
> fashion, e.g. one can not
> 
>     delete 666:3?? 666:4??
> 
> from a peer who one does not wish to have control one's internals,
> communities are often/usually stripped at the border.

Fortunately, most (all?) deployed implementations allow the operator to simply 
do_nothing based on the attribute value.

If these are to be new global default communities then a reasonable 
implementation might require that one specify whether to enable/disable 
honoring these community values, and perhaps configurable parameters for 
"avoid/prefer attribute value(s)"

-danny

Date: Mon, 13 Dec 1999 12:12:20 -0800
From: john heasley <[email-masked]>
To: Randy Bush <[email-masked]>
Cc: Tony Li <[email-masked]>, [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

On Mon, Dec 13, 1999 at 12:07:16PM -0800, Randy Bush wrote:
> > If folks out there are deleting communities by default, I agree that would
> > be an issue.  Operational folks, any comments?
> 
> as common routers do not allow one to remove communities in a useful
> fashion, e.g. one can not
> 
>     delete 666:3?? 666:4??
> 
> from a peer who one does not wish to have control one's internals,
> communities are often/usually stripped at the border.
> 
> randy

exactly what i was thinking.  recent 12.0 ios has this support (though
i have not tested) and juniper has this ability.  

From: Randy Bush <[email-masked]>
To: Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: Global community values
Date: Mon, 13 Dec 1999 12:07:16 -0800
Sender: [email-masked]

> If folks out there are deleting communities by default, I agree that would
> be an issue.  Operational folks, any comments?

as common routers do not allow one to remove communities in a useful
fashion, e.g. one can not

    delete 666:3?? 666:4??

from a peer who one does not wish to have control one's internals,
communities are often/usually stripped at the border.

randy

From: "D" <[email-masked]>
To: "Tony Li" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: Global community values
Date: Mon, 13 Dec 1999 14:24:00 -0500
Sender: [email-masked]

None of the networks I'm working with (a few tier 1s and multiple regional
networks) delete communitites by default.  Quite the opposite, in fact.

-D

Darrel Lewis
[email-masked]

----- Original Message -----
From: Tony Li <[email-masked]>
<snip>
>
> If folks out there are deleting communities by default, I agree that would
> be an issue.  Operational folks, any comments?
>
> Tony
>

Date: Mon, 13 Dec 1999 11:12:32 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

|  Agreed, the term is not well defined.  What I mean is "likely to propogate
|  end to end in the network".  Stripping prefixes and as-paths from routes
|  would be obviously detrimental to the network.  Stripping communities is
|  extremely unlikely to cause loops, persistent divergence, or other network
|  problems.  It is common to do so, and so any mechanism which relies on
|  communities to transit preference information  beyond a direct neighbor AS
|  will function in unreliable ways.  MEDs suffer from the same problem, but
|  are only defined in the context of adjacent ASes.
|  
|  Again, I am still not clear what value the proposal adds without
|  requirements that the communities it specifies never be stripped.  In the
|  best case, the proposal provides a mechanism similar to MEDs, but with scope
|  beyond adjacent ASes.  Why not just define it as such?

That's what we're trying to do, but someone keeps objecting.  ;-)

The improvement here is that it becomes a transitive attribute, and thus,
by default, should propagate.  

If folks out there are deleting communities by default, I agree that would
be an issue.  Operational folks, any comments?

Tony

Date: Mon, 13 Dec 1999 01:42:46 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

|  MEDs can also be used as part of a local policy to set LOCAL_PREF.  As to
|  your second assertion, communities are not reliable as transitive attributes
|  either.

A problem with this 'discussion' (and I use the term loosely) is that your
point hinges on the definition of the word 'reliable'.  Please elucidate
your terms so that we can understand your position more fully.

In BGP, there is no such things as a 'reliable' attribute.  And it is not
unreasonable to filter out or ignore _any_ attribute.  You'll note that
even the prefix itself can be filtered out.  Ergo, this proposal is no
less 'reliable' than any other mechanism for transmitting this semantics.

Tony

Date: Mon, 13 Dec 1999 10:42:48 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Global community values
Organization: Relcom Corp.
Sender: [email-masked]

And then, MED's are usially compared after AS-PATH length comparation (through
it was changed in some versions, if I am not mistaken). Anyway, MED's are not
transit attributes; if they was, we never propose this draft.

On Sun, 12 Dec 1999, Tony Li wrote:

> Date: Sun, 12 Dec 1999 16:25:32 -0800
> From: Tony Li <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Re: Global community values
> 
> 
> |  I disagree.  In its current form the document does not provide functionality
> |  beyond that currently provided with MEDs.  Many providers strip communities,
> |  making the delivery of these global communities values entirely random; why
> |  not just always compare MED values and be done with it?
> 
> 
> MED values are only a single AS hop.
> 
> 
> |  A more useful approach might be to simply use communities for IGP cost
> |  signalling between ASes.  ASes who wished to participate in the process
> |  would add their own (normalized) IGP cost to the value signaled by the peer.
> |  This cost to the next-hop would be announced to external peers.  If the cost
> |  community is not supported by an AS, it is not propogated.  This can be
> |  implemented by using local AS communities (rather than global communities).
> |  The result is similar to DPA, but without the requirement for changes to the
> |  decision algorithm (how the signaled IGP cost influences path selection is
> |  entirely based on local policy).
> 
> 
> And we end up back in the swamp of trying to figure out what the global
> metric system should be.
> 
> Tony
> 
> 

Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/

Date: Mon, 13 Dec 1999 10:39:55 +0300 (MSK)
From: "Alex P. Rudnev" <[email-masked]>
To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Global community values
Organization: Relcom Corp.
Sender: [email-masked]

Tony. It was me who choose this names, and no doubt I could not get the best
choise because english is not my native language. Be absolutely free changing
this names.

Alex R.

On Sun, 12 Dec 1999, Tony Li wrote:

> Date: Sun, 12 Dec 1999 15:41:39 -0800
> From: Tony Li <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Global community values
> 
> 
> Hank,
> 
> I support the acceptance of this document as a working group draft.
> 
> I have two further comments:
> 
> - The formatting is clearly the result of some heinous word mangaling
>   processor, such as Word.  This really needs to be cleaned.
> 
> - Since the names for these communities is likely to become widely known,
>   to the point of appearing in router configurations, it might be best if
>   we selected some alternate names that sounded a little bit more
>   professional.  Note that I'm not suggesting any semantic changes.
> 
> I have some obvious concerns about how this new item will affect the entire
> path selection algorithm if there is some scheme for applying these
> communities that is not the application of explicit policy as you outline
> in section 5.  In particular, if implementations insert this into path
> selection at different points, it might lead to inconsistencies.
> 
> Regards,
> Tony
> 
> 

Aleksei Roudnev,
(+1 415) 585-3489 /San Francisco CA/

Date: Sun, 12 Dec 1999 16:43:23 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

|  Communities aren't guaranteed to get beyond a single AS hop, and often
|  don't.  Without a reliable signalling mechanism, what benefit does this
|  proposal offer?

Paths aren't guaranteed to get beyond a single hop either.

|  I'm afraid there is no way around that.   Better to invest the effort in a
|  framework that provides recognizable benefit than to keep adding features
|  that provide little, if any, additional flexibility.

BGP has worked fine for years without metrics.  Clearly there is a way
around that.

Tony

Date: Sun, 12 Dec 1999 16:25:32 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

|  I disagree.  In its current form the document does not provide functionality
|  beyond that currently provided with MEDs.  Many providers strip communities,
|  making the delivery of these global communities values entirely random; why
|  not just always compare MED values and be done with it?

MED values are only a single AS hop.

|  A more useful approach might be to simply use communities for IGP cost
|  signalling between ASes.  ASes who wished to participate in the process
|  would add their own (normalized) IGP cost to the value signaled by the peer.
|  This cost to the next-hop would be announced to external peers.  If the cost
|  community is not supported by an AS, it is not propogated.  This can be
|  implemented by using local AS communities (rather than global communities).
|  The result is similar to DPA, but without the requirement for changes to the
|  decision algorithm (how the signaled IGP cost influences path selection is
|  entirely based on local policy).

And we end up back in the swamp of trying to figure out what the global
metric system should be.

Tony

Date: Sun, 12 Dec 1999 15:41:39 -0800
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Global community values
Sender: [email-masked]

Hank,

I support the acceptance of this document as a working group draft.

I have two further comments:

- The formatting is clearly the result of some heinous word mangaling
  processor, such as Word.  This really needs to be cleaned.

- Since the names for these communities is likely to become widely known,
  to the point of appearing in router configurations, it might be best if
  we selected some alternate names that sounded a little bit more
  professional.  Note that I'm not suggesting any semantic changes.

I have some obvious concerns about how this new item will affect the entire
path selection algorithm if there is some scheme for applying these
communities that is not the application of explicit policy as you outline
in section 5.  In particular, if implementations insert this into path
selection at different points, it might lead to inconsistencies.

Regards,
Tony