RE: BGP-4 changes

"John G. Scudder" <jgs@ieng.com> Wed, 04 September 1996 16:26 UTC

Received: from ietf.org by ietf.org id aa28576; 4 Sep 96 12:26 EDT
Received: from cnri by ietf.org id aa28572; 4 Sep 96 12:26 EDT
Received: from merit.edu by CNRI.Reston.VA.US id aa11724; 4 Sep 96 12:26 EDT
Received: (from daemon@localhost) by merit.edu (8.7.5/merit-2.0) id LAA26596 for idr-outgoing; Wed, 4 Sep 1996 11:14:16 -0400 (EDT)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by merit.edu (8.7.5/merit-2.0) with SMTP id LAA26589 for <bgp@merit.edu>; Wed, 4 Sep 1996 11:14:12 -0400 (EDT)
Received: by interlock.ans.net id AA08099 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Wed, 4 Sep 1996 11:14:07 -0400
Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 4 Sep 1996 11:14:07 -0400
Message-Id: <v03007807ae534a42bd10@[204.38.8.78]>
In-Reply-To: <c=US%a=_%p=SHL%l=SHL/CANADAW/001AE5D1@cocms1.calwdc.shl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 4 Sep 1996 11:14:08 -0400
To: "NITTMANN Michael (MSMail)" <MNittmann@shl.com>
Sender: ietf-archive-request@ietf.org
From: "John G. Scudder" <jgs@ieng.com>
Subject: RE: BGP-4 changes
Cc: Curtis Villamizar <curtis@ans.net>, "rwoundy@VNET.IBM.COM" <rwoundy@vnet.ibm.com>, "bgp@ans.net" <bgp@ans.net>
X-Orig-Sender: owner-idr@merit.edu
Precedence: bulk

At 8:20 AM -0600 9/4/96, NITTMANN Michael (MSMail) wrote:
>I would not treat MED = -1 as a value, but as a flag for 'no MED present',
>which I need to identify candidates where either I cannot successfully work
>with an MED since the other side has set none, or where the other side does
>not want to tell me the MED value.

I suppose this could be done by implementors agreement (everyone agree not
to originate the all-ones MED), or by mandating it in the spec, or simply
by configuring your routers not to originate such a huge MED.  Alternately,
the spec could change to say that no MED is *worse* than the all-ones MED
(instead of what it says now, which is that no MED is equally as bad).
This latter option might be more of a pain for some implementations which
aren't already able to store distinguished values for things like "there is
no MED here."

Of course, as long as the other guy never sends you an all-ones MED, the
current proposed text does this already.

Are you worried about getting all-ones MEDs and not preferring them over
empty MEDs?  Or do you have something else on your mind?

>Therefore I would suggest a modifying option, in addition to the removal.
>This gives also the possibility to add an MED 'penalty' for a meetpoint to
>all MEDs gotten from there (again to resolve the mae-e problem where
>everybody and his dog wants to go through).

I don't get how this is linked to the previous paragraph.  (The "therefore"
suggests that you think it's connected, but to me they look like two
unrelated thoughts.)

So you want to (e.g.) be able to say something like "For all MAE-E routes,
increment MED by 100"?

I think that the proposed text already allows this, and the details of
how/when/if to do it should be left to implementors.

But, I kinda agree with Rich that localpref and policy may be a cleaner way
to reflect stuff like this.

--John

--
John Scudder                        email:  jgs@ieng.com
Internet Engineering Group, LLC     phone:  (313) 669-8800
122 S. Main, Suite 280              fax:    (313) 669-8661
Ann Arbor, MI  41804                www:    http://www.ieng.com