RE:

"Natale, Jonathan" <JNatale@celoxnetworks.com> Thu, 30 May 2002 16:21 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA26976 for <idr-archive@nic.merit.edu>; Thu, 30 May 2002 12:21:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 000DC91206; Thu, 30 May 2002 12:20:42 -0400 (EDT)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id C81F191284; Thu, 30 May 2002 12:20:41 -0400 (EDT)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 68BC091206 for <idr@trapdoor.merit.edu>; Thu, 30 May 2002 12:20:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id E40F75DE88; Thu, 30 May 2002 12:20:33 -0400 (EDT)
Delivered-To: idr@merit.edu
Received: from celox-ma1-ems1.celoxnetworks.com (celox-ma1-imap1.celoxnetworks.com [12.40.60.233]) by segue.merit.edu (Postfix) with ESMTP id 9C0FC5DDD3 for <idr@merit.edu>; Thu, 30 May 2002 12:20:33 -0400 (EDT)
Received: by celox-ma1-ems1.celoxnetworks.com with Internet Mail Service (5.5.2653.19) id <L9JQAS2W>; Thu, 30 May 2002 12:20:39 -0400
Message-ID: <1117F7D44159934FB116E36F4ABF221B01B14158@celox-ma1-ems1.celoxnetworks.com>
From: "Natale, Jonathan" <JNatale@celoxnetworks.com>
To: 'f b shepherd' <bshep@research.bell-labs.com>, jgs@cisco.com
Cc: idr@merit.edu
Subject: RE:
Date: Thu, 30 May 2002 12:20:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-idr@merit.edu
Precedence: bulk

If this is caused by not having the deterministic med command, then why not
roll the command's functionality into the new bgp draft?  I consider this
command to be a bug fix--where does RFC1771 say that non-deterministic med
behavior is ok anyway?  I think it does not, but obviously it (like many bgp
behaviors) needs to be clarified.  Why invent a new command and tell
everyone that they should always turn it on, instead of just putting it on
by default or just on always?

-----Original Message-----
From: f b shepherd [mailto:bshep@research.bell-labs.com] 
Sent: Thursday, May 30, 2002 11:45 AM
To: jgs@cisco.com
Cc: idr@merit.edu
Subject: 

Dear John,

Personally I agree with you. 
It is not my (I think our) view that protocol correctness
a priori outweighs any (including scalability) of the
important properties that a protocol should possess in practice.
One can take the view that our I-D and paper is meant
to help analyze the tradeoffs in achieving the different goals.

At the same time, BGP and inter-domain routing has taken on
an importance in traffic engineering (and network design) where it is
a reasonable and worthwhile endeavour to put in place
some fundamentals which would be important in understanding 
better its behaviour.  I feel such models will prove important
especially in an effort to understand the cause-and-effect of
certain 1-time events or  policy changes in a network.
For instance, my view is that similar ``fundamentals'' were already 
well-established in the 50's
and 60's  for circuit-switched and OSPF-like networks
by Ford, Bellman, Fulkerson, and even Dantzig etc.

In  this sense, it is useful to think of our work
as an exploration of the route oscillation
problem. IMO this problem  is already more complex than 
it appears on the surface. Dismissing examples as unrealistic is
fair enough although it does also beg for an understanding of the line
between real and not (Im sure the people on this
mailing list are infinitely more aware of this than I).
Also, as Anindya pointed out, our own aims were to explore possible
solutions
for all  configurations.

Regards,
Bruce





----
At 9:39 AM -0400 5/30/02, Anindya Basu wrote:
...
>Brijesh Kumar wrote:
>>2. I am curious to know if the problem is existent in real networks 
>>beyond pathological scenario depicted in the draft as to merit 
>>announcements and storage of multiple routes at the routers. I find 
>>it too drastic a proposal for a problem whose existence/severity 
>>seems to be based on a simple paper scenario (unless I see 
>>reference 5). After all, it proposes to do away the most 
>>stabilizing BGP/distance vector protocol rule that a peer will 
>>advertise only its best route to its neighbour.
>
>in case you have completely missed it (though it is in the references),
>the original problem was outlined in an ID (reference [3]) by McPherson
>et. al. and actually stems from a cisco field report called "Endless BGP
>Convergence Problem in Cisco IOS Software Releases", October 10, 2000.
>is that real enough?

The MED problem is real enough.  However, as we've been discussing in 
a different thread, your proposal is more far-reaching than just 
addressing [3].  Specifically:

At 1:26 PM -0400 5/29/02, Anindya Basu wrote:
>However, our aim was to address the elimination of any possible kind 
>of oscillation in I-BGP, MED-induced or not, persistent or not.

That's laudable in the abstract but inevitably leads to the 
requirement that you advertise more additional routes than required 
to fix specifically [3].

My take on the subject is that while theoretical protocol correctness 
is an admirable goal, it's not more important than scalability. 
Protocol scalability plus _practical_ protocol correctness is more 
important, IMO.

As you yourself point out in draft-wilfong-ibgp-oscillations-00.txt:
>Admittedly, the configuration in Figure 1 is not likely in a 
>reasonable network.

I think the IDR working group should be primarily concerned with 
reasonable networks.  Fixing problems for unreasonable (or 
hypothetical) networks seems fine as long as it doesn't conflict with 
the operation and scaling of reasonable ones.

Do you disagree?

Regards,

- --John

------- End of Forwarded Message

  • RE:  John G. Scudder
  • RE:  Natale, Jonathan
  • RE:  Pedro Roque Marques
  • RE:  Pedro Roque Marques
  • RE:  Pedro Roque Marques
  • RE:  Abarbanel, Benjamin
  • RE:  Abarbanel, Benjamin
  • RE:  Abarbanel, Benjamin
  • RE:  Abarbanel, Benjamin
  • RE:  Abarbanel, Benjamin
  • RE:  Natale, Jonathan
  • Re:  Curtis Villamizar