Subject: Re: BGP-4 changes
From: [email-masked]
To: [email-masked], [email-masked]
Date: Sat, 31 Aug 96 19:25:39 EDT

*** Resending note of 08/30/96 10:11
Subject: Re: BGP-4 changes
Yakov,

>> I agree with your intent, but this is too easy to misinterpret.  For
>> example, suppose a router has three routes for a prefix, with the same
>> local preference: one from AS X w/MED 5, one from AS X w/MED 10, and one
>> from AS Y w/MED 15.  I think the consensus is that the router should not
>> compare the MED values 5 and 10 from AS X with the MED value 15 from
>> AS Y.  On the other hand, we should also make it clear that as part of
>> MED comparison, the route from AS Y w/MED 15 should be preferred over
>> the route from AS X w/MED 10 -- otherwise, you can get routing loops.

> Comparing MEDs on routes coming from different ASs is not very
> meaningful, as MED is intended to reflect IGP distance within a
> particular neighboring AS, and one shouldn't expect that IGP distances
> would be comparable across all neighboring ASs.

If I *did* compare MED values on routes from different ASs, I wouldn't
have chosen the route from AS Y w/MED 15 over the route from AS X
w/MED 10 -- instead, I would have chosen the route from X since 10 < 15.

When I say to choose the route from AS Y w/MED 15 over the route from
AS X w/MED 10 at MED comparison time, you may re-interpret this using
John Scudder's text as: at MED comparison time, keep the route to AS Y
w/MED 15, and eliminate the route from AS X w/MED 10 (it's inferior
MED-wise to the route from AS X w/MED 5).

> Thus while I certainly agree with your statement that "the router
> should not compare the MED values 5 and 10 from AS X with the MED value
> 15 from AS Y", I don't think that "the route from AS Y w/MED 15 should
> be preferred over the route from AS X w/MED 10" (as it compares
> uncomparable things).

Hmmm. I thought John and I were saying essentially the same things
(in different ways)... John wins the clarity contest -- and I'm quite
satisfied.

> Yakov.

-- Rich

- - - - - - - - - - - - - - - - -

Date: Sat, 31 Aug 1996 14:56:49 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP-4 changes
Sender: [email-masked]

At 2:01 PM -0400 8/30/96, Curtis Villamizar wrote:
>In message <[email-masked]>, Yakov Rekhter writes:
>>   When a route with the MULTI_EXIT_DISC attribute is received over an
>>   external link it must be possible (based on local configuration) to
>>   remove or override the value of the attribute. This shall be done
>>   prior to determining the degree of preference of the route.
>
>This is fine.  It actually makes sense to be able to add an offset if
>MED is being used to load balance the other AS but some control over
>load in the local AS is also desirable.  I would put that in the spec
>as a protocol requirement though.

I don't follow the last sentence (about "protocol requirement") but I'm not
too worked up about it.

I still prefer the wording "must be possible (based on local configuration)
to remove the attribute or override its value".  The way Yakov has it can
be parsed at least two ways, one of which makes no sense.  (It depends on
if you associate "remove" with "value" or "attribute".)

>In private mail John mentioned he wanted to be able to disable MED to
>accomodate existing implementations that do the selection differently.
>It might actually be worth mentioning this.

As far as I'm concerned, being able to strip the attribute at the border
achieves this goal fine.  Either or both is OK with me.

In private email Curtis mentioned a case (which in retrospect I should have
seen) where we should be able to strip MED after route selection but before
export into IBGP.  The case applies when I have a router facing two
neighbors across a DMZ.  I want to consider the MED to get the next hop
"right" across the DMZ, but I want to use shortest-path inside my AS.  I
believe that this stays loop-free since we only consider MED once we have
already decided to choose an external route.

Discussion of interoperation with existing (wrong) implementations would be
good for an appendix (perhaps Appendix 6.9 which I mention below but don't
volunteer to write :-).

...
>You forgot the statement that any algorithm that produces an
>equivalent result is acceptable.  You might mention that this
>particular algorithm is inefficient.

I agree.  Here is some proposed text [which presumes that Curtis or someone
is going to write Appendix 6, section 6.9 -- if no one does, then remove
the parenthetical sentence].

Insert between prefatory text and item (a):

    Several of the criteria are described using pseudo-code.  Note that
    the pseudo-code shown was chosen for clarity, not efficiency.  It
    is not intended to specify any particular implementation.  BGP
    implementations may use any algorithm which produces the same
    results as those described here.  (See Appendix 6, section 6.9 for
    a description of a more efficient algorithm for MULTI_EXIT_DISC
    treatment.)

>Regardless of what description is used, I'd like to see a description
>of the loop problems and the reasons for some of these rules in the
>selection process, to prevent someone from mistakenly thinks that
>comparing the current best route to the new route is an equivalent
>algorithm.  Would you prefer this in the route selection section, in
>an appendix, or a separate informational RFC.

IMO this would be good to add to the now-famous Appendix 6.9, possibly with
a forward reference from 9.1.2.1.  A discussion of a more efficient MED
implementation would fit in too.

BTW while I'm talking about Appendix 6, 6.2 has a "shall" in it.  This is
inappropriate for something called "Implementation *Recommendations*."  If
anyone thinks this is really a "shall" it should be moved out of the
appendix and into the spec proper.  Or, change the "shall" to "should."

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

From: [email-masked]
Posted-Date: Fri, 30 Aug 1996 16:24:35 -0700 (PDT)
Subject: Re: draft-manning-bgpattrib-type-00.txt as Informational RFC
To: [email-masked] (Tony Bates)
Date: Fri, 30 Aug 1996 16:24:35 -0700 (PDT)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

 done and done.   any other comment before draft-01?

> 
> 
>  Yakov Rekhter <[email-masked]> writes:
>   * Joel,
>   * 
>   * The IDR WG would like to ask the IESG to publish 
>   * draft-manning-bgpattrib-type-00.txt as an Informational RFC.
>   * 
>   * Yakov.
> 
> Actually....I think it might be useful to at least clarify the doument
> with a few references and also use the actual names of the
> attributes. This is just an editorial nit but we may as well do it.
> Here's the patch for the text.
> 
> 	--Tony
> 
> *** draft-manning-bgpattrib-type-00.txt	Fri Aug 30 12:59:15 1996
> --- draft-manning-bgpattrib-type-00.txt.new	Fri Aug 30 15:51:05 1996
> ***************
> *** 53,71 ****
>      Currently in use attribute type codes are listed below:
>   
>   
> ! 		1       origin
> ! 		2       as path
> ! 		3       next hop
> ! 		4       multi exit disc.
> ! 		5       local preference
> ! 		6       atomic aggregate
> ! 		7       aggregator
> ! 		8       community                               cisco ID
> ! 		9       originator                              cisco ID
> ! 		10      cluster list                            cisco ID
> ! 		11      destination preference                  MCI ID
> ! 		12	advertiser				Bay ID
> ! 		13	rcid_path (cluster id) 			Bay ID
>   		...
>   		255	reserved for development
>   
> --- 53,73 ----
>      Currently in use attribute type codes are listed below:
>   
>   
> !              Value      Code                                  Reference
> ! 
> ! 		1       ORIGIN                                  [1]
> ! 		2       AS_PATH                                 [1]
> ! 		3       NEXT_HOP                                [1] 
> ! 		4       MULTI_EXIT_DISC                         [1]
> ! 		5       LOCAL_PREF                              [1]
> ! 		6       ATOMIC_AGGREGATE                        [1]
> ! 		7       AGGREGATOR                              [1]
> ! 		8       COMMUNITY                               [2]
> ! 		9       ORIGINATOR_ID                           [3]
> ! 		10      CLUSTER_LIST                            [3]
> ! 		11      DPA                                     [4]
> ! 		12	ADVERTISER                              [5]
> ! 		13	RCID_PATH / CLUSTER_ID 			[5]
>   		...
>   		255	reserved for development
>   
> ***************
> *** 73,78 ****
> --- 75,99 ----
>   Security considerations of this memo
>   
>      None.
> + 
> + 
> + References
> + 
> +    [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
> +        RFC 1771, March 1995.
> + 
> +    [2] Chandra, R., Traina, P., and T. Li, "BGP Communities
> +        Attribute", RFC 1997, August 1996.
> + 
> +    [3] Bates, T., Chandra, R, "BGP Route Reflection An alternative 
> +        to full mesh IBGP", RFC 1998, June 1996.
> + 
> +    [4] Chen, E., Bates, T., "Destination Preference Attribute for BGP", 
> +        Work in progress, March 1996.
> + 
> +    [5] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
> +        routing", RFC 1863, October 1995.
> + 
>   
>   Authors' Addresses
>   
> 
> 

-- 
--bill
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-manning-bgpattrib-type-00.txt as Informational RFC 
From: Tony Bates <[email-masked]>
Date: Fri, 30 Aug 1996 15:54:48 -0700
Sender: [email-masked]

 Yakov Rekhter <[email-masked]> writes:
  * Joel,
  * 
  * The IDR WG would like to ask the IESG to publish 
  * draft-manning-bgpattrib-type-00.txt as an Informational RFC.
  * 
  * Yakov.

Actually....I think it might be useful to at least clarify the doument
with a few references and also use the actual names of the
attributes. This is just an editorial nit but we may as well do it.
Here's the patch for the text.

	--Tony

*** draft-manning-bgpattrib-type-00.txt	Fri Aug 30 12:59:15 1996
--- draft-manning-bgpattrib-type-00.txt.new	Fri Aug 30 15:51:05 1996
***************
*** 53,71 ****
     Currently in use attribute type codes are listed below:

! 		1       origin
! 		2       as path
! 		3       next hop
! 		4       multi exit disc.
! 		5       local preference
! 		6       atomic aggregate
! 		7       aggregator
! 		8       community                               cisco ID
! 		9       originator                              cisco ID
! 		10      cluster list                            cisco ID
! 		11      destination preference                  MCI ID
! 		12	advertiser				Bay ID
! 		13	rcid_path (cluster id) 			Bay ID
  		...
  		255	reserved for development
  
--- 53,73 ----
     Currently in use attribute type codes are listed below:

!              Value      Code                                  Reference
! 
! 		1       ORIGIN                                  [1]
! 		2       AS_PATH                                 [1]
! 		3       NEXT_HOP                                [1] 
! 		4       MULTI_EXIT_DISC                         [1]
! 		5       LOCAL_PREF                              [1]
! 		6       ATOMIC_AGGREGATE                        [1]
! 		7       AGGREGATOR                              [1]
! 		8       COMMUNITY                               [2]
! 		9       ORIGINATOR_ID                           [3]
! 		10      CLUSTER_LIST                            [3]
! 		11      DPA                                     [4]
! 		12	ADVERTISER                              [5]
! 		13	RCID_PATH / CLUSTER_ID 			[5]
  		...
  		255	reserved for development
  
***************
*** 73,78 ****
--- 75,99 ----
  Security considerations of this memo
  
     None.
+ 
+ 
+ References
+ 
+    [1] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)",
+        RFC 1771, March 1995.
+ 
+    [2] Chandra, R., Traina, P., and T. Li, "BGP Communities
+        Attribute", RFC 1997, August 1996.
+ 
+    [3] Bates, T., Chandra, R, "BGP Route Reflection An alternative 
+        to full mesh IBGP", RFC 1998, June 1996.
+ 
+    [4] Chen, E., Bates, T., "Destination Preference Attribute for BGP", 
+        Work in progress, March 1996.
+ 
+    [5] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
+        routing", RFC 1863, October 1995.
+ 
  
  Authors' Addresses

- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], "John G. Scudder" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: BGP-4 changes 
Date: Fri, 30 Aug 1996 14:01:54 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> Folks,
> 
> How about if we'll use John's text (with some minor editorial
> changes) ?
> 
> Add to 5.1.4:
> 
>   When a route with the MULTI_EXIT_DISC attribute is received over an
>   external link it must be possible (based on local configuration) to
>   remove or override the value of the attribute. This shall be done
>   prior to determining the degree of preference of the route.

This is fine.  It actually makes sense to be able to add an offset if
MED is being used to load balance the other AS but some control over
load in the local AS is also desirable.  I would put that in the spec
as a protocol requirement though.

In private mail John mentioned he wanted to be able to disable MED to
accomodate existing implementations that do the selection differently.
It might actually be worth mentioning this.

> Replace 9.1.2.1 with the following:
> 
> 
>    In its Adj-RIBs-In a BGP speaker may have several routes to the same
>    destination that have the same degree of preference. The local
>    speaker can select only one of these routes for inclusion in the
>    associated Loc-RIB. The local speaker considers all routes
>    with the same degress of preference, both those received from 
>    internal peers, and those received from external peers.
> 
>    The following tie-breaking procedure assumes that for each candidate
>    route all the BGP speakers within an autonomous system can ascertain
>    the cost of a path (interior distance) to the address depicted by the
>    NEXT_HOP attribute of the route.
> 
>    The tie-breaking algorithm begins by considering all equally
>    preferable routes and then selects routes to be removed from
>    consideration.  The algorithm terminates as soon as only one
>    route  remains in consideration.  The criteria must be applied
>    in the order specified.
> 
>       a) Remove from consideration routes with less-preferred
>       MULTI_EXIT_DISC attributes, according to the following
>       procedure:
> 
>       for m = all routes still under consideration
>           for n = all routes still under consideration
>               if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
>                   remove route m from consideration
> 
>       In the pseudo-code above, MED(n) is a function which returns
>       the value of route n's MULTI_EXIT_DISC attribute.  If route n
>       has no MULTI_EXIT_DISC attribute, the function returns the
>       highest possible MULTI_EXIT_DISC value, i.e. 2^32-1.
> 
>       Similarly, neighborAS(n) is a function which returns the
>       neighbor AS from which the route was received.
> 
>       b) Remove from consideration any routes with less-preferred
>       interior cost, according to the following procedure.  If the
>       BGP speaker has no notion of the cost of a path, skip this
>       step (equivalently, consider all routes to have equal costs).
> 
>       for m = all routes still under consideration
>           for n = all routes in still under consideration
>               if (cost(n) is better than cost(m))
>                   remove m from consideration
> 
>       In the pseudo-code above, cost(n) is a function which returns
>       the cost of the path (interior distance) to the address
>       depicted by the NEXT_HOP attribute of the route.
> 
>       c) If at least one of the candidate routes was received from
>       an external peer from a neighboring autonomous system, remove from
>       consideration all routes which were received from internal
>       peers.
> 
>       d) Remove from consideration all routes other than the route
>       that was advertised by the BGP speaker whose BGP Identifier
>       has the lowest value.
> 
> Yakov.

You forgot the statement that any algorithm that produces an
equivalent result is acceptable.  You might mention that this
particular algorithm is inefficient.

This wording is clear and it is excellent if it a goal to word the
spec using such that it describes the most inefficient algorithm
possible, even if a very efficient algorithm exists that is easy to
explain and understand.  If that is not a goal, then the wording is
adequate since it is clear enough that loops will be avoided by anyone
who reads attentively and dutifully implements what they read.

Regardless of what description is used, I'd like to see a description
of the loop problems and the reasons for some of these rules in the
selection process, to prevent someone from mistakenly thinks that
comparing the current best route to the new route is an equivalent
algorithm.  Would you prefer this in the route selection section, in
an appendix, or a separate informational RFC.

Curtis

- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: "John G. Scudder" <[email-masked]>
Subject: Re: BGP-4 changes 
Date: Fri, 30 Aug 96 07:33:59 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

How about if we'll use John's text (with some minor editorial
changes) ?

Add to 5.1.4:

  When a route with the MULTI_EXIT_DISC attribute is received over an
  external link it must be possible (based on local configuration) to
  remove or override the value of the attribute. This shall be done
  prior to determining the degree of preference of the route.

Replace 9.1.2.1 with the following:

   In its Adj-RIBs-In a BGP speaker may have several routes to the same
   destination that have the same degree of preference. The local
   speaker can select only one of these routes for inclusion in the
   associated Loc-RIB. The local speaker considers all routes
   with the same degress of preference, both those received from 
   internal peers, and those received from external peers.

   The following tie-breaking procedure assumes that for each candidate
   route all the BGP speakers within an autonomous system can ascertain
   the cost of a path (interior distance) to the address depicted by the
   NEXT_HOP attribute of the route.

   The tie-breaking algorithm begins by considering all equally
   preferable routes and then selects routes to be removed from
   consideration.  The algorithm terminates as soon as only one
   route  remains in consideration.  The criteria must be applied
   in the order specified.

      a) Remove from consideration routes with less-preferred
      MULTI_EXIT_DISC attributes, according to the following
      procedure:

      for m = all routes still under consideration
          for n = all routes still under consideration
              if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                  remove route m from consideration

      In the pseudo-code above, MED(n) is a function which returns
      the value of route n's MULTI_EXIT_DISC attribute.  If route n
      has no MULTI_EXIT_DISC attribute, the function returns the
      highest possible MULTI_EXIT_DISC value, i.e. 2^32-1.

      Similarly, neighborAS(n) is a function which returns the
      neighbor AS from which the route was received.

      b) Remove from consideration any routes with less-preferred
      interior cost, according to the following procedure.  If the
      BGP speaker has no notion of the cost of a path, skip this
      step (equivalently, consider all routes to have equal costs).

      for m = all routes still under consideration
          for n = all routes in still under consideration
              if (cost(n) is better than cost(m))
                  remove m from consideration

      In the pseudo-code above, cost(n) is a function which returns
      the cost of the path (interior distance) to the address
      depicted by the NEXT_HOP attribute of the route.

      c) If at least one of the candidate routes was received from
      an external peer from a neighboring autonomous system, remove from
      consideration all routes which were received from internal
      peers.

      d) Remove from consideration all routes other than the route
      that was advertised by the BGP speaker whose BGP Identifier
      has the lowest value.

Yakov.
- - - - - - - - - - - - - - - - -

To: "Rich Woundy" <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-4 changes 
Date: Fri, 30 Aug 96 07:11:11 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Rich,

>  >1. Add to 5.1.4 the following:
> 
>  >  MULTI_EXIT_DISC shall not be considered when comparing routes received fr
om
>  >  different neighboring ASs.
> 
>  I agree with your intent, but this is too easy to misinterpret.  For
>  example, suppose a router has three routes for a prefix, with the same
>  local preference: one from AS X w/MED 5, one from AS X w/MED 10, and one
>  from AS Y w/MED 15.  I think the consensus is that the router should not
>  compare the MED values 5 and 10 from AS X with the MED value 15 from
>  AS Y.  On the other hand, we should also make it clear that as part of
>  MED comparison, the route from AS Y w/MED 15 should be preferred over
>  the route from AS X w/MED 10 -- otherwise, you can get routing loops.

Comparing MEDs on routes coming from different ASs is not very
meaningful, as MED is intended to reflect IGP distance within a
particular neighboring AS, and one shouldn't expect that IGP distances
would be comparable across all neighboring ASs.

Thus while I certainly agree with your statement that "the router
should not compare the MED values 5 and 10 from AS X with the MED value
15 from AS Y", I don't think that "the route from AS Y w/MED 15 should
be preferred over the route from AS X w/MED 10" (as it compares
uncomparable things).

Yakov.
- - - - - - - - - - - - - - - - -

Date: Thu, 29 Aug 1996 17:01:11 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

   The algorithm is very simple.

     get a new route in a BGP update

     if the [r]oute passes policy filter criteria, compare to the current
     best route for the AS using all criteria - local-pref, med, igp,
     advertiser IP address

Ok, so what do I do after comparing?  I _assume_ you mean that if the new
route is NOT better than the current best route from that neighboring AS,
then no further testing need be done.  Otherwise, the new route is the best
route via the neighboring AS.

     if the best route for the AS changed, compare it to the overall best
     route using all the criteria except MED - local-pref, igp,
     advertiser IP address

     if the new route is better you have a new best route.

   Simple to explain.  Simple to implement.  No loop.

Agreed.  Now there are two problems: a) wordsmithing b) explaining the
functionality rather than the implementation.

I think we are in violent agreement on semantics.

Tony
- - - - - - - - - - - - - - - - -

Date: Thu, 29 Aug 1996 17:28:28 -0700
To: "Rich Woundy" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP-4 changes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I think this is good.  It basically trades terseness for clarity.  Clarity
is good.

However, if we're going to do this, why not go whole hog and write a little
pseudo-code?  For example, when considering routes to destination D:

    for m = all Adj-RIB-In routes for destination D
        mark route m as MED-Superior
        for n = all Adj-RIB-In routes for destination D
            if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                mark route m as MED-Inferior

This is inefficient and I hope no one would actually implement this way,
but I believe it specifies the same thing and is rather unambiguous IMO.
There would probably be a disclaimer somewhere that emphasizes that any
implementation of route selection which has the same outputs is acceptable.

This would allow 9.1.2.1.a to be written as:

    a) Remove from consideration any routes marked as MED-Inferior
    following the procedure given in 5.1.4.

Below the copy of Rich's message, I'll append a 9.1.2.1 that incorporates
the above in a somewhat more compact form, and treats route selection as a
process of deleting non-preferred routes rather than a process of looking
for the preferred route.

Regards,

--John

---
At 4:03 PM -0400 8/29/96, Rich Woundy wrote:
> (Hi folks, I'm finally back)
>
> Yakov,
> I have some comments about your proposed text.
>
> >To: [email-masked]
> >Subject: BGP-4 changes
> >Date: Thu, 29 Aug 96 08:03:22 PDT
> >From: Yakov Rekhter <[email-masked]>
>
> >Folks,
>
> >Let me propose that we'll make the following changes to the
> >spec:
>
> >1. Add to 5.1.4 the following:
>
> >  MULTI_EXIT_DISC shall not be considered when comparing routes received
>from
> >  different neighboring ASs.
>
> I agree with your intent, but this is too easy to misinterpret.  For
> example, suppose a router has three routes for a prefix, with the same
> local preference: one from AS X w/MED 5, one from AS X w/MED 10, and one
> from AS Y w/MED 15.  I think the consensus is that the router should not
> compare the MED values 5 and 10 from AS X with the MED value 15 from
> AS Y.  On the other hand, we should also make it clear that as part of
> MED comparison, the route from AS Y w/MED 15 should be preferred over
> the route from AS X w/MED 10 -- otherwise, you can get routing loops.
>
> How about the following text?
>
>  MULTI_EXIT_DISC values of routes received from different neighboring
>  ASs shall not be directly compared.  However, to ensure consistent
>  route selection, the ranking of MULTI_EXIT_DISC values of routes
>  must be compared, where the MULTI_EXIT_DISC ranking is computed over
>  all routes for the same IP prefix from the same neighbor AS.
>
>  In particular, a route with the best MULTI_EXIT_DISC value from its
>  neighbor AS must be preferred over a route with an inferior
>  MULTI_EXIT_DISC value from its (possibly different) neighbor AS.
>  If two routes have the best MULTI_EXIT_DISC values from their
>  respective neighboring ASs, they must be considered equivalent with
>  respect to MULTI_EXIT_DISC comparisons.
>
>  In the ranking computation, the lower MULTI_EXIT_DISC values are
>  preferred, and a route without the MULTI_EXIT_DISC attribute
>  shall be treated as equivalent to a route with the highest
>  possible MULTI_EXIT_DISC value.
>
> >  When a route with the MULTI_EXIT_DISC attribute is received over an
> >  external link it must be possible (based on local configuration) to
> >  remove or override the value of the attribute. This shall be done
> >  prior to determining the degree of preference of the route.
>
> I agree totally with this text.
>
> >2. Replace 9.1.2.1 clause (a) with the following:
>
> >     a) If the local system is configured to take into account
> >      MULTI_EXIT_DISC, and the candidate routes differ in their
> >      MULTI_EXIT_DISC attribute but were received from the same
> >      neighboring AS, select the route that has the lowest
> >      value of the MULTI_EXIT_DISC attribute.  A route with
> >      MULTI_EXIT_DISC shall be preferred to a route without
> >      MULTI_EXIT_DISC.
>
> Can we assume that the local system must take into account MEDs?
> I think the answer is yes.  The new text you propose back in 5.1.4
> explicitly permits the removal or override of MEDs.  If an
> ISP wants to ignore MEDs in the route selection process, it is
> safer to remove MEDs from all routes at the borders (as is
> commonly done today), than to set a configuration option on all
> routers in the AS to change the route selection algorithm.
>
> How about the following text (which also refers to ranking)?
>
>  a) If the candidate routes differ in their MULTI_EXIT_DISC
>  attribute, select the route(s) that have the best MULTI_EXIT_DISC
>  values from their respective neighboring ASs.  The ranking of
>  MULTI_EXIT_DISC values per neighboring AS is described in 5.1.4.
>
> >Comments ?
>
> Yes, one more comment.  Notice how I put the missing MED case
> in the ranking discussion, not in the tie-breaking discussion.
> To see the subtle point I am making here, consider two routes
> from AS X w/MED 10 and from AS Y w/no MED.  I don't think we
> should penalize the route from AS Y; after all, does any provider have
> a problem with a peer provider that *encourages* shortest exit???
> (There may be other legitimate reasons why MEDs are not sent.)
> If we compare routes from AS X w/MED 10 and from AS X w/no MED,
> *then* we should discourage use of the missing MED route.
> The first comparison is a tie-breaking consideration, and the
> second comparison is a ranking consideration.
>
> >Yakov.
>
> -- Richard Woundy, IBM

----
This version of section 9.1.2.1 treats route selection as a process of
deleting non-preferred routes rather than a process of looking for the
preferred route.  I like some things about it (like the fact that I think
it's pretty clear) and dislike others (I'm not sure I like this use of
pseudo-code in the spec).  Note that the way I've written (a) allows 5.1.4
to mostly be left as it is currently.  We would NOT need this in 5.1.4:

  MULTI_EXIT_DISC shall not be considered when comparing routes received
  from different neighboring ASs.

I like getting rid of this, since it's better for all text relating to
route selection to go in the route selection section.

I would still like to have this, though:

  When a route with the MULTI_EXIT_DISC attribute is received over an
  external link it must be possible (based on local configuration) to
  remove or override the value of the attribute. This shall be done
  prior to determining the degree of preference of the route.

9.1.2.1 Breaking Ties (Phase 2)

   In its Adj-RIBs-In a BGP speaker may have several routes to the same
   destination that have the same degree of preference. The local
   speaker can select only one of these routes for inclusion in the
   associated Loc-RIB. The local speaker considers all equally
   preferable routes, both those received from BGP speakers located in
   neighboring autonomous systems, and those received from other BGP
   speakers located in the local speaker's autonomous system.

   The following tie-breaking procedure assumes that for each candidate
   route all the BGP speakers within an autonomous system can ascertain
   the cost of a path (interior distance) to the address depicted by the
   NEXT_HOP attribute of the route.

   The tie-breaking algorithm begins by considering all equally
   preferable routes and then selects routes to be removed from
   consideration.  The algorithm terminates as soon as only one
   route  remains in consideration.  The criteria must be applied
   in the order specified.

      a) Remove from consideration routes with less-preferred
      MULTI_EXIT_DISC attributes, according to the following
      procedure:

      for m = all routes still under consideration
          for n = all routes still under consideration
              if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                  remove route m from consideration

      In the pseudo-code above, MED(n) is a function which returns
      the value of route n's MULTI_EXIT_DISC attribute.  If route n
      has no MULTI_EXIT_DISC attribute, the function returns the
      highest possible MULTI_EXIT_DISC value, i.e. 2^32-1.

      Similarly, neighborAS(n) is a function which returns the
      neighbor AS from which the route was received.

      b) Remove from consideration any routes with less-preferred
      interior cost, according to the following procedure.  If the
      BGP speaker has no notion of the cost of a path, skip this
      step (equivalently, consider all routes to have equal costs).

      for m = all routes still under consideration
          for n = all routes in still under consideration
              if (cost(n) is better than cost(m))
                  remove m from consideration

      In the pseudo-code above, cost(n) is a function which returns
      the cost of the path (interior distance) to the address
      depicted by the NEXT_HOP attribute of the route.

      c) If at least one of the candidate routes was advertised by a
      BGP speaker in a neighboring autonomous system, remove from
      consideration all routes which were not advertised by a BGP
      speaker in a neighboring autonomous system.

      d) Remove from consideration all routes other than the route
      that was advertised by the BGP speaker whose BGP Identifier
      has the lowest value.

      [Alternately, this could be written as follows.  I guess I wrote
      the above out of some mania to preserve the purity of the
      "always delete from the set" idea.  The inverse formulation is
      less wordy:]

      d) Select the route which was advertised by the BGP speaker whose
      BGP Identifier has the lowest value.

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: route comparisons - BGP-4 - revised I-D
Date: Thu, 29 Aug 1996 19:41:55 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

The route comparison algorithm can be very simple.

  get a new route in a BGP update

  if the route passes policy filter criteria, compare to the current
  best route for the AS using all criteria - local-pref, med, igp,
  advertiser IP address

  if the best route for the AS changed, compare it to the overall best
  route using all the criteria except MED - local-pref, igp,
  advertiser IP address

  if the new route is better you have a new best route.

Simple to explain.  Simple to implement.  No loop.

Curtis
- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Thu, 29 Aug 1996 18:49:50 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
>    > - group the routes by neighboring AS
>    > - within each group, select the routes with the best MED
>    > 
>    > which is also what I think is the intended interpretation.  Alternate
>    > interpretations include:
>    > 
>    > i)
>    > - group the routes by neighboring AS
>    > - within each group, select _a_ route with the best MED
> 
>    Interpretation i) is the same as the first.  
> 
> No, it's not.  If you follow i) verbatim, then you must select one and only
> one route.  As we have not specified which one, it's presumably left up to
> the implementor.  You and I both know that this is disaster.  ;-)
> 
>    If there are two routes
>    with the same AS and the same MED, the next criteria is IGP cost or
>    advertising router IP address.  Whether you bring one or both into the
>    next comparison, you end up with the same decision whether you
>    consider MED and they tie in the first comparison or you ignore MED in
>    the second comparison.
> 
> Did you really mean to say this?  Suppose I have routes A, B, C, ... and
> that A & B are the same MED.  Without loss of generality, suppose that A
> has a better IGP metric.  
> 
> If we bring A into the next comparison, then it will be selected.  If we do
> NOT bring A into the next comparison, then B may be selected.  Loop.
> 
> Tony

Tony,

A & B are the same MED.  A has the lower IGP cost.  Bring A into the
next level of selection.

The algorithm is very simple.

  get a new route in a BGP update

  if the oute passes policy filter criteria, compare to the current
  best route for the AS using all criteria - local-pref, med, igp,
  advertiser IP address

  if the best route for the AS changed, compare it to the overall best
  route using all the criteria except MED - local-pref, igp,
  advertiser IP address

  if the new route is better you have a new best route.

Simple to explain.  Simple to implement.  No loop.

Curtis
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4 changes 
Date: Thu, 29 Aug 1996 18:41:29 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> Folks,
> 
> Let me propose that we'll make the following changes to the
> spec:
> 
> 1. Add to 5.1.4 the following:
> 
>   MULTI_EXIT_DISC shall not be considered when comparing routes received from
>   different neighboring ASs.
> 
>   When a route with the MULTI_EXIT_DISC attribute is received over an
>   external link it must be possible (based on local configuration) to 
>   remove or override the value of the attribute. This shall be done 
>   prior to determining the degree of preference of the route.
> 
> 2. Replace 9.1.2.1 clause (a) with the following:
> 
>      a) If the local system is configured to take into account
>       MULTI_EXIT_DISC, and the candidate routes differ in their
>       MULTI_EXIT_DISC attribute but were received from the same
>       neighboring AS, select the route that has the lowest
>       value of the MULTI_EXIT_DISC attribute.  A route with
>       MULTI_EXIT_DISC shall be preferred to a route without
>       MULTI_EXIT_DISC.
> 
> Comments ?
> 
> Yakov.

This is insufficient for the reasons that were cited in numerous
threads on this list.

I suggested text to correct the looping problem and so did Rich
Woundy.

Curtis
- - - - - - - - - - - - - - - - -

Date: Thu, 29 Aug 1996 13:47:51 -0700
To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP-4 changes
Cc: [email-masked]
Sender: [email-masked]

At 8:03 AM -0700 8/29/96, Yakov Rekhter wrote:
>
>  external link it must be possible (based on local configuration) to
>  remove or override the value of the attribute. This shall be done
             ^^^^^^^^
The meaning of "override" is not clear to me.  Furthermore, you can't
remove the value of the attribute since there is no distinguished "no
value" value.  You have to remove the whole attribute.  Try:

When a route with the MULTI_EXIT_DISC attribute is received over an
external link it must be possible (based on local configuration) to remove
the attribute or alter its value.  This shall be done prior to determining
the degree of preference of the route.

>  prior to determining the degree of preference of the route.
>
>2. Replace 9.1.2.1 clause (a) with the following:
>
>     a) If the local system is configured to take into account
>      MULTI_EXIT_DISC, and the candidate routes differ in their
>      MULTI_EXIT_DISC attribute but were received from the same
>      neighboring AS, select the route that has the lowest
                      ^
                       select the route or routes with the lowest

>      value of the MULTI_EXIT_DISC attribute.  A route with
>      MULTI_EXIT_DISC shall be preferred to a route without
>      MULTI_EXIT_DISC.

Some of this stuff might be slightly easier to be precise about if the
sense were inverted from a process of selecting one best route to that of
removing all non-best routes.  For example that last paragraph would be
something like

       ...remove from consideration all routes which do not have the
       lowest value of the MED attribute.

But, I don't think it's that important.

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Thu, 29 Aug 1996 13:20:12 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

   > - group the routes by neighboring AS
   > - within each group, select the routes with the best MED
   > 
   > which is also what I think is the intended interpretation.  Alternate
   > interpretations include:
   > 
   > i)
   > - group the routes by neighboring AS
   > - within each group, select _a_ route with the best MED

   Interpretation i) is the same as the first.  

No, it's not.  If you follow i) verbatim, then you must select one and only
one route.  As we have not specified which one, it's presumably left up to
the implementor.  You and I both know that this is disaster.  ;-)

   If there are two routes
   with the same AS and the same MED, the next criteria is IGP cost or
   advertising router IP address.  Whether you bring one or both into the
   next comparison, you end up with the same decision whether you
   consider MED and they tie in the first comparison or you ignore MED in
   the second comparison.

Did you really mean to say this?  Suppose I have routes A, B, C, ... and
that A & B are the same MED.  Without loss of generality, suppose that A
has a better IGP metric.  

If we bring A into the next comparison, then it will be selected.  If we do
NOT bring A into the next comparison, then B may be selected.  Loop.

Tony

- - - - - - - - - - - - - - - - -

Date: Thu, 29 Aug 96 16:03:39 EDT
From: "Rich Woundy" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: BGP-4 changes
Sender: [email-masked]

 (Hi folks, I'm finally back)

 Yakov,
 I have some comments about your proposed text.

 >To: [email-masked]
 >Subject: BGP-4 changes
 >Date: Thu, 29 Aug 96 08:03:22 PDT
 >From: Yakov Rekhter <[email-masked]>

 >Folks,

 >Let me propose that we'll make the following changes to the
 >spec:

 >1. Add to 5.1.4 the following:

 >  MULTI_EXIT_DISC shall not be considered when comparing routes received from
 >  different neighboring ASs.

 I agree with your intent, but this is too easy to misinterpret.  For
 example, suppose a router has three routes for a prefix, with the same
 local preference: one from AS X w/MED 5, one from AS X w/MED 10, and one
 from AS Y w/MED 15.  I think the consensus is that the router should not
 compare the MED values 5 and 10 from AS X with the MED value 15 from
 AS Y.  On the other hand, we should also make it clear that as part of
 MED comparison, the route from AS Y w/MED 15 should be preferred over
 the route from AS X w/MED 10 -- otherwise, you can get routing loops.

 How about the following text?

  MULTI_EXIT_DISC values of routes received from different neighboring
  ASs shall not be directly compared.  However, to ensure consistent
  route selection, the ranking of MULTI_EXIT_DISC values of routes
  must be compared, where the MULTI_EXIT_DISC ranking is computed over
  all routes for the same IP prefix from the same neighbor AS.

  In particular, a route with the best MULTI_EXIT_DISC value from its
  neighbor AS must be preferred over a route with an inferior
  MULTI_EXIT_DISC value from its (possibly different) neighbor AS.
  If two routes have the best MULTI_EXIT_DISC values from their
  respective neighboring ASs, they must be considered equivalent with
  respect to MULTI_EXIT_DISC comparisons.

  In the ranking computation, the lower MULTI_EXIT_DISC values are
  preferred, and a route without the MULTI_EXIT_DISC attribute
  shall be treated as equivalent to a route with the highest
  possible MULTI_EXIT_DISC value.

 >  When a route with the MULTI_EXIT_DISC attribute is received over an
 >  external link it must be possible (based on local configuration) to
 >  remove or override the value of the attribute. This shall be done
 >  prior to determining the degree of preference of the route.

 I agree totally with this text.

 >2. Replace 9.1.2.1 clause (a) with the following:

 >     a) If the local system is configured to take into account
 >      MULTI_EXIT_DISC, and the candidate routes differ in their
 >      MULTI_EXIT_DISC attribute but were received from the same
 >      neighboring AS, select the route that has the lowest
 >      value of the MULTI_EXIT_DISC attribute.  A route with
 >      MULTI_EXIT_DISC shall be preferred to a route without
 >      MULTI_EXIT_DISC.

 Can we assume that the local system must take into account MEDs?
 I think the answer is yes.  The new text you propose back in 5.1.4
 explicitly permits the removal or override of MEDs.  If an
 ISP wants to ignore MEDs in the route selection process, it is
 safer to remove MEDs from all routes at the borders (as is
 commonly done today), than to set a configuration option on all
 routers in the AS to change the route selection algorithm.

 How about the following text (which also refers to ranking)?

  a) If the candidate routes differ in their MULTI_EXIT_DISC
  attribute, select the route(s) that have the best MULTI_EXIT_DISC
  values from their respective neighboring ASs.  The ranking of
  MULTI_EXIT_DISC values per neighboring AS is described in 5.1.4.

 >Comments ?

 Yes, one more comment.  Notice how I put the missing MED case
 in the ranking discussion, not in the tie-breaking discussion.
 To see the subtle point I am making here, consider two routes
 from AS X w/MED 10 and from AS Y w/no MED.  I don't think we
 should penalize the route from AS Y; after all, does any provider have
 a problem with a peer provider that *encourages* shortest exit???
 (There may be other legitimate reasons why MEDs are not sent.)
 If we compare routes from AS X w/MED 10 and from AS X w/no MED,
 *then* we should discourage use of the missing MED route.
 The first comparison is a tie-breaking consideration, and the
 second comparison is a ranking consideration.

 >Yakov.

 -- Richard Woundy, IBM

- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Thu, 29 Aug 1996 15:41:49 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> If I understand what Curtis is getting at (50% chance, max), there is some
> ambiguity (or at least possibility of misinterpretation) in the MED
> comparison step.  One interpretation is:

Yep.

> - group the routes by neighboring AS
> - within each group, select the routes with the best MED
> 
> which is also what I think is the intended interpretation.  Alternate
> interpretations include:
> 
> i)
> - group the routes by neighboring AS
> - within each group, select _a_ route with the best MED

Interpretation i) is the same as the first.  If there are two routes
with the same AS and the same MED, the next criteria is IGP cost or
advertising router IP address.  Whether you bring one or both into the
next comparison, you end up with the same decision whether you
consider MED and they tie in the first comparison or you ignore MED in
the second comparison.

Did I miss something.  i) is the algorithm I suggested for the draft
based on my understanding of what Rich Woundy has suggesting.

Curtis

- - - - - - - - - - - - - - - - -

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Thu, 29 Aug 1996 15:22:32 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v0300781dae4a5559835d@[36.141.0.30]>, "John G. Scudder" writes:
> Curtis,
> 
> [regarding need for specification of a particular MED election algorithm]
> At 1:36 PM -0400 8/28/96, Curtis Villamizar wrote:
> >Yes it is absolutely neccesary.  The order in which routes are
> >compared impacts the outcome of the comparison.
> 
> How is the text already in RFC 1771 section 9.1 not sufficient to clearly
> specify the order?  To summarize, it says that when selecting a route you
> should consider, *in this order*:
> 
> - Local_Pref
> - MED (adding the note that you can only compare MED between like ASes)
> - IGP distance
> - EBGP better than IBGP
> - Router ID
> 
> As far as I can tell this specifies everything which is needed for
> loop-free operation (I do understand the issue and agree with you).  I
> think that this:
> 
> >   One route from the neighboring
> >   AS is selected as best.  The best routes from each of these
> >   neighboring AS are then compared.
> 
> goes from specifying the algorithm (necessary) to specifying implementation
> (unneccessary).  Perhaps 9.1.2.1 could be made even more explicit as to the
> order in which the tie-breaking criteria must be applied, and there could
> be a forward reference from 5.1.4 to make sure people don't miss this.
> 
> Regards,
> 
> --John

John,

We need to go back quite a few messages on another recent thread.

  Refer to the diagram below where R{1-5} are routers and the numbers on
  the lines are IGP link costs.

    R1  --6--  R4  --1--  R5  --4--  R3
    R2  --2-/

	...

            AS  MED     IGP             
        R3   x   1      4-5             R2 is better than R3 (lower IGP)
        R2   y   2      2-3             R1 is better than R2 (lower MED)
        R1   y   3      6-7             R3 is better than R1 (lower IGP)

        R4 learns R1, R2, R3.  It prefers R3.  (R3 announcement delayed)
        R5 learns R3, R1, R2.  It prefers R2.
        R4 and R5 point next hop at each other.

This loop occurs if the comparison algorithm is:

  take the recently learned route and compare it with the current best
  route.

Two astute vendors might decide to fix this by insuring a fixed order
of comparison so that a loop could never form in a network of only
their routers.

One might decide to compare all routes from the same AS first, then
compare the best from each AS.

Another might decide to run the comparison from lowest advertising
router IP address to highest so the comparison order was constant
regardless of the order they came in.

The would be no loops due to MED in single vendor networks.  In a
multivendor network there would be loops.

I just want to fix BGP4 so multivendor networks will not form routing
loops.

Curtis

ps- I think we're now converging on a loop free route to concensus.  ;-)
[I know - corny as it gets!]

> P.S.:  Please do re-read 9.1.2.1 if you haven't already.  A few comments on
> your full text below, just in case I haven't been clear enough above:
> 
> At 1:36 PM -0400 8/28/96, Curtis Villamizar wrote:
> >In message <v03007820ae49140b08b4@[36.141.0.30]>, "John G. Scudder" writes:
> >>
> >> I don't know if folks think it is also necessary to specify an algorithm t
> o
> >> do this, e.g. the election Rich has written about.  I tend to think of thi
> s
> >> as an implementation detail, but if people are complaining that MED is too
> >> hard to implement, I guess an existence proof to the contrary might be
> >> useful.  Perhaps as an appendix?
> >
> >
> >Yes it is absolutely neccesary.  The order in which routes are
> >compared impacts the outcome of the comparison.
> >
> >Lets say we don't.
> >
> >Most readers will not notice that there is the possibility of a
> >routing loop.  Routing loops will form.
> >
> >The very astute reader will notice that there is the possibility of a
> >routing loop if the order of comparison is not constrained to be the
> >same on all routers.
> 
> But 9.1.2.1 does constrain the order.
> 
> >Said reader picks an algorithm.
> 
> Which is non-compliant if it doesn't match 9.1.2.1.
> 
> >The algorithm
> >chosen is to compare all routes in order of lowest advertising router
> >first.  These routers work fine in a network of like routers.
> 
> Which won't be talking BGP4 but some similar thing instead.
> 
> >Put in
> >a router using Rich's algorithm and a routing loop forms since those
> >routers evaluate in a different order and come to a different
> >conclusion about which route is best.
> >
> >This will form routing loops.  Its been proven in real networks.
> >
> >The text could be as simple as:
> >
> >> 5.1.4   MULTI_EXIT_DISC
> >>
> >>    The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
> >>    links to discriminate among multiple exit or entry points to the same
> >>    neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
> >>    octet unsigned number which is called a metric.  All other factors
> >>    being equal, the exit or entry point with lower metric should be
> >>    preferred.  If received over external links, the MULTI_EXIT_DISC
> >>    attribute may be propagated over internal links to other BGP speakers
> >>    within the same AS.  The MULTI_EXIT_DISC attribute is never
> >>    propagated to other BGP speakers in neighboring AS's.
> >
> >   Due to the MED rules, route comparisons among all of the available
> >   routes may not have the transitive property.  Under some circumstances
> >   routing loops can form if routes are not evaluated in the same or a
> >   similar order on all routers.  The following order of comparison must
> >   be implemented:
> >
> >   All routes from the same neighboring AS are compared.  The MED value
> >   and the presence or absence of MED must be considered when comparing
> >   routes from the same neighboring AS.  One route from the neighboring
> >   AS is selected as best.  The best routes from each of these
> >   neighboring AS are then compared.  The MED value or the presence or
> >   absence of MED must be ignored when comparing the best route from each
> >   neighboring AS.
> >
> >This text assures that all implementors that carefully read an follow
> >the BGP4 spec will end up with implementations that 1) are loop free,
> >2) interoperate in a loop free manner with other implementations, 3)
> >don't require that MED be completely disabled to remain loop free in
> >the presence of other implementations.
> 
> BTW my notes about being able to disable MED really relate to (1) needing
> to interoperate with current routers, and (2) making any (hypothetical)
> people happy who are afraid of the CPU overhead of electing the best route
> per AS.
> 
> >Curtis
> 
> 
> --
> John Scudder                        email:  [email-masked]
> 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
> 
> 
- - - - - - - - - - - - - - - - -

To: "NITTMANN Michael (MSMail)" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: FW: Addr: Re: BGP-4 - revised I-D 
Date: Thu, 29 Aug 1996 14:55:10 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <c=US%a=_%p=SHL%l=SHL/CANADAW/[email-masked]>, "NITT
MANN Michael (MSMail)" writes:
> 
> AS A has multiple meetpoints with AS B. 
> AS A would like to drain traffic to a set of networks to AS B preferably 
> through a meetpoint M.
> As A sets parameters to result in an MED favouring meetpoint M for the set 
> of routes that is announced by AS B there (can be a subset of all announced 
> ones, most of the times some people like to have shorter, i.e. low latency 
> paths, between themselves, e.g. people working together but being behind 
> different Ass).
> 
> In the current scheme, there is no feedback to AS B that this kind of 
> preference had been sent. This leads to a routing loop in most cases. AS A 
> can call up AS B to negotiate routing with preference. But, since this would 
> require real work, i.e. typing and changing router configs, on the side of 
> AS B, guess what: they say 'we waited exactly for this request of yours and 
> will do it immediately'.
>
> If there were a mechanism that the routing engines would exchange this MED 
> and install the corresponding routes to AS A for the subset of networks in 
> AS B via meetpoint M, this would work without loops.

AS path loop supression already prevents a loop from forming in this
case.

This sounds a bit like setting MED based on IGP cost.  Are you aware
of that option?

> Such requests are always founded on a shortest desired path, whatever 
> 'shortest' means: latency, hops, uptime, or packet loss. In most of the 
> cases, AS B has an interest to follow the MED suggestion of AS A.
> In cases where AS B would not like to do this, e.g. the administrator finds 
> that path and would not like to agree to it, there should be a mechanism of 
> programmed dissent, which is exchanged too. 
> Now the admin of AS A sees that AS B did reject the request, and the routing 
> engines in AS A can either chose an offered alternative, or the admin can 
> try another one, or call AS B up and talk it out. But the cases where such 
> an intervention is necessary, are really rare I would say.
> 
> This negotiation piece had been missing, which makes it not very useful to 
> define MEDs on an island (my AS).

If setting MED based on IGP cost does not do what you want, try
looking at PDA.  I think that is close to what you are suggesting.

If not you may be able to set BGP communities and translate to an
admninistratively chosen MED or do an admninistratively chosen MED
based on AS path.

It's not entirely clear what you want to do, plus your loop argument
is flawed.

> All this can then be steered via the snmp tables of course, so it is 
> possible to integrate it into an NMS or EMS system, and point/click out 
> preferred paths and watch results. 

You must not have a whole lot of experience configuring routers or
have a very small network if you like SNMP and point and click as a
way to do this.

We process a few thousand lines of diffs in many config runs.  I'd
really hate to paste these changes in with a mouse or retype them into
dialog boxes.  Much easier to derive this from a database and just
move out new configuration files.

Of course this is not a protocol issue.

> Mike

Curtis
- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Thu, 29 Aug 1996 13:51:13 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
>    I'm not saying I want to compare MEDs across AS, just that if
>    local-pref ends up the same I don't want a routing loop.
> 
> Ah.  But then the real request is that there needs to be a consistent
> tie-breaker after equal local pref's.  Agreed.

Exactly.  wrt MED I've consistently said there were two options.
Compare MED across AS.  Or mandate a specific algorithm that insures
an order of comparison that will be look free.

>    If you want to finess it with Rich Woundy's MED election rather than
>    comparing MED across AS to avoid loops, then fine.  The group seems to
>    have come to consensus so please don't get pissed and start proposing
>    new attributes.
> 
> Me?  Get pissed? ;-)
> 
>    We seemed to have already reached consensus on the list for Rich's MED
>    election.  We still don't have a proposed change in the BGP4 text.  If
>    Rich is busy I'll write something.
> 
> Cool.  Then at least we'll really have something solid to argue about.  Me,
> I liked John's changes...  ;-)
> 
> Tony

Johns changes just said "you should be able to turn off MED
completely".  I don't find the option to "turn off MED if it loops" to
be very useful.

I proposed text that will insure we have useful MED, loop free, and
loop free across vendor implementations since there is not room for
creative and incompatible order of evaluation algorithms.

I think we're on the same page now.

Curtis
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Subject: draft-manning-bgpattrib-type-00.txt as Informational RFC
Date: Thu, 29 Aug 96 09:33:52 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Joel,

The IDR WG would like to ask the IESG to publish 
draft-manning-bgpattrib-type-00.txt as an Informational RFC.

Yakov.
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: BGP-4 changes
Date: Thu, 29 Aug 96 08:03:22 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Let me propose that we'll make the following changes to the
spec:

1. Add to 5.1.4 the following:

  MULTI_EXIT_DISC shall not be considered when comparing routes received from
  different neighboring ASs.

  When a route with the MULTI_EXIT_DISC attribute is received over an
  external link it must be possible (based on local configuration) to 
  remove or override the value of the attribute. This shall be done 
  prior to determining the degree of preference of the route.

2. Replace 9.1.2.1 clause (a) with the following:

     a) If the local system is configured to take into account
      MULTI_EXIT_DISC, and the candidate routes differ in their
      MULTI_EXIT_DISC attribute but were received from the same
      neighboring AS, select the route that has the lowest
      value of the MULTI_EXIT_DISC attribute.  A route with
      MULTI_EXIT_DISC shall be preferred to a route without
      MULTI_EXIT_DISC.

Comments ?

Yakov.
- - - - - - - - - - - - - - - - -

Date: Wed, 28 Aug 1996 15:01:48 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

   >Yes it is absolutely neccesary.  The order in which routes are
   >compared impacts the outcome of the comparison.

   How is the text already in RFC 1771 section 9.1 not sufficient to clearly
   specify the order?  To summarize, it says that when selecting a route you
   should consider, *in this order*:

   - Local_Pref
   - MED (adding the note that you can only compare MED between like ASes)
   - IGP distance
   - EBGP better than IBGP
   - Router ID

If I understand what Curtis is getting at (50% chance, max), there is some
ambiguity (or at least possibility of misinterpretation) in the MED
comparison step.  One interpretation is:

- group the routes by neighboring AS
- within each group, select the routes with the best MED

which is also what I think is the intended interpretation.  Alternate
interpretations include:

i)
- group the routes by neighboring AS
- within each group, select _a_ route with the best MED

ii)
- across all routes, select the routes with the best MED
[yes, this violates the comparison]

iii) - if route A has a better MED than route B, but both are incomparable
to route C, and route B has a better IGP distance than C, while A has a
worse IGP distance than C, select route B.  [I believe that cisco's
implementation had this bug for a while and that this is now fixed.]

   As far as I can tell this specifies everything which is needed for
   loop-free operation (I do understand the issue and agree with you).  I
   think that this:

   >   One route from the neighboring
   >   AS is selected as best.  The best routes from each of these
   >   neighboring AS are then compared.

   goes from specifying the algorithm (necessary) to specifying implementation
   (unneccessary).  Perhaps 9.1.2.1 could be made even more explicit as to the
   order in which the tie-breaking criteria must be applied, and there could
   be a forward reference from 5.1.4 to make sure people don't miss this.

I would suggest that while it is more specific, it possibly introduces more
bugs (do you select ONE route? what happens if there are multiple routes
with identical best MED?).  Yes, I think that this all boils down to
wordsmithing some more explicit text...  I look forward to the concrete
proposals.

Tony

- - - - - - - - - - - - - - - - -

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: Addr: Re: BGP-4 - revised I-D
Date: Wed, 28 Aug 1996 13:50:01 -0600
Encoding: 95 TEXT
Sender: [email-masked]

... resent

----------
From:  NITTMANN Michael
Sent:  Wednesday, August 28, 1996 9:42 AM
To:  [email-masked]; Tony Li
Cc:  [email-masked]; [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject:  RE: Addr: Re: BGP-4 - revised I-D

To me an MED scheme would be very useful, without having a global static 
metric.

How about this:

AS A has multiple meetpoints with AS B. 
AS A would like to drain traffic to a set of networks to AS B preferably 
through a meetpoint M.
As A sets parameters to result in an MED favouring meetpoint M for the set 
of routes that is announced by AS B there (can be a subset of all announced 
ones, most of the times some people like to have shorter, i.e. low latency 
paths, between themselves, e.g. people working together but being behind 
different Ass).

In the current scheme, there is no feedback to AS B that this kind of 
preference had been sent. This leads to a routing loop in most cases. AS A 
can call up AS B to negotiate routing with preference. But, since this would 
require real work, i.e. typing and changing router configs, on the side of 
AS B, guess what: they say 'we waited exactly for this request of yours and 
will do it immediately'.

If there were a mechanism that the routing engines would exchange this MED 
and install the corresponding routes to AS A for the subset of networks in 
AS B via meetpoint M, this would work without loops.

Such requests are always founded on a shortest desired path, whatever 
'shortest' means: latency, hops, uptime, or packet loss. In most of the 
cases, AS B has an interest to follow the MED suggestion of AS A.
In cases where AS B would not like to do this, e.g. the administrator finds 
that path and would not like to agree to it, there should be a mechanism of 
programmed dissent, which is exchanged too. 
Now the admin of AS A sees that AS B did reject the request, and the routing 
engines in AS A can either chose an offered alternative, or the admin can 
try another one, or call AS B up and talk it out. But the cases where such 
an intervention is necessary, are really rare I would say.

This negotiation piece had been missing, which makes it not very useful to 
define MEDs on an island (my AS).

All this can then be steered via the snmp tables of course, so it is 
possible to integrate it into an NMS or EMS system, and point/click out 
preferred paths and watch results. 

Mike

----------
From:  Tony Li[SMTP:[email-masked]]
Sent:  Tuesday, August 27, 1996 3:48 PM
To:  [email-masked]
Cc:  [email-masked]; [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject:  Re: Addr: Re: BGP-4 - revised I-D

Curtis,

   MEDs are useful and are still useful if compared across AS.  

Why?  There are clearly some semantics that you have in mind, but you're
not expressing the need at all.  Given a global administrative metric
(hmmm...  and I guess calling it the GAM attribute would lead us to be
politically incorrect... ;-), what information are you trying to convey?  

I suppose that I can still see _some_ utility in expressing a local
preference for an entry point where there are truly multiple interconnects,
but I fail to see the need for global semantics.  Moreover, I can see that
having two interacting metrics with global semantics is just another way to
increase the complexity of the current (ridiculous) situation.

   The way
   we use BGP, no two AS should be announcing the same prefix at the same
   local-pref under normal circumstances.  If the local-pref were the
   same I'd rather have something that didn't form a routing loop.

I'm confused.  How did local-pref enter the discussion?

   Getting rid of MED is not a constructive suggestion.

I'm very sorry you feel that way.  Perfection is only attained when you
have removed everything that can be removed, and no more.  Perhaps you
would care to make some simple, concrete, and constructive suggestions?

Tony

- - - - - - - - - - - - - - - - -

Date: Wed, 28 Aug 1996 13:12:44 -0700
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: Addr: Re: BGP-4 - revised I-D
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Curtis,

[regarding need for specification of a particular MED election algorithm]
At 1:36 PM -0400 8/28/96, Curtis Villamizar wrote:
>Yes it is absolutely neccesary.  The order in which routes are
>compared impacts the outcome of the comparison.

How is the text already in RFC 1771 section 9.1 not sufficient to clearly
specify the order?  To summarize, it says that when selecting a route you
should consider, *in this order*:

- Local_Pref
- MED (adding the note that you can only compare MED between like ASes)
- IGP distance
- EBGP better than IBGP
- Router ID

As far as I can tell this specifies everything which is needed for
loop-free operation (I do understand the issue and agree with you).  I
think that this:

>   One route from the neighboring
>   AS is selected as best.  The best routes from each of these
>   neighboring AS are then compared.

goes from specifying the algorithm (necessary) to specifying implementation
(unneccessary).  Perhaps 9.1.2.1 could be made even more explicit as to the
order in which the tie-breaking criteria must be applied, and there could
be a forward reference from 5.1.4 to make sure people don't miss this.

Regards,

--John

P.S.:  Please do re-read 9.1.2.1 if you haven't already.  A few comments on
your full text below, just in case I haven't been clear enough above:

At 1:36 PM -0400 8/28/96, Curtis Villamizar wrote:
>In message <v03007820ae49140b08b4@[36.141.0.30]>, "John G. Scudder" writes:
>>
>> I don't know if folks think it is also necessary to specify an algorithm to
>> do this, e.g. the election Rich has written about.  I tend to think of this
>> as an implementation detail, but if people are complaining that MED is too
>> hard to implement, I guess an existence proof to the contrary might be
>> useful.  Perhaps as an appendix?
>
>
>Yes it is absolutely neccesary.  The order in which routes are
>compared impacts the outcome of the comparison.
>
>Lets say we don't.
>
>Most readers will not notice that there is the possibility of a
>routing loop.  Routing loops will form.
>
>The very astute reader will notice that there is the possibility of a
>routing loop if the order of comparison is not constrained to be the
>same on all routers.

But 9.1.2.1 does constrain the order.

>Said reader picks an algorithm.

Which is non-compliant if it doesn't match 9.1.2.1.

>The algorithm
>chosen is to compare all routes in order of lowest advertising router
>first.  These routers work fine in a network of like routers.

Which won't be talking BGP4 but some similar thing instead.

>Put in
>a router using Rich's algorithm and a routing loop forms since those
>routers evaluate in a different order and come to a different
>conclusion about which route is best.
>
>This will form routing loops.  Its been proven in real networks.
>
>The text could be as simple as:
>
>> 5.1.4   MULTI_EXIT_DISC
>>
>>    The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>>    links to discriminate among multiple exit or entry points to the same
>>    neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
>>    octet unsigned number which is called a metric.  All other factors
>>    being equal, the exit or entry point with lower metric should be
>>    preferred.  If received over external links, the MULTI_EXIT_DISC
>>    attribute may be propagated over internal links to other BGP speakers
>>    within the same AS.  The MULTI_EXIT_DISC attribute is never
>>    propagated to other BGP speakers in neighboring AS's.
>
>   Due to the MED rules, route comparisons among all of the available
>   routes may not have the transitive property.  Under some circumstances
>   routing loops can form if routes are not evaluated in the same or a
>   similar order on all routers.  The following order of comparison must
>   be implemented:
>
>   All routes from the same neighboring AS are compared.  The MED value
>   and the presence or absence of MED must be considered when comparing
>   routes from the same neighboring AS.  One route from the neighboring
>   AS is selected as best.  The best routes from each of these
>   neighboring AS are then compared.  The MED value or the presence or
>   absence of MED must be ignored when comparing the best route from each
>   neighboring AS.
>
>This text assures that all implementors that carefully read an follow
>the BGP4 spec will end up with implementations that 1) are loop free,
>2) interoperate in a loop free manner with other implementations, 3)
>don't require that MED be completely disabled to remain loop free in
>the presence of other implementations.

BTW my notes about being able to disable MED really relate to (1) needing
to interoperate with current routers, and (2) making any (hypothetical)
people happy who are afraid of the CPU overhead of electing the best route
per AS.

>Curtis

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Wed, 28 Aug 1996 10:44:02 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

   I'm not saying I want to compare MEDs across AS, just that if
   local-pref ends up the same I don't want a routing loop.

Ah.  But then the real request is that there needs to be a consistent
tie-breaker after equal local pref's.  Agreed.

   If you want to finess it with Rich Woundy's MED election rather than
   comparing MED across AS to avoid loops, then fine.  The group seems to
   have come to consensus so please don't get pissed and start proposing
   new attributes.

Me?  Get pissed? ;-)

   We seemed to have already reached consensus on the list for Rich's MED
   election.  We still don't have a proposed change in the BGP4 text.  If
   Rich is busy I'll write something.

Cool.  Then at least we'll really have something solid to argue about.  Me,
I liked John's changes...  ;-)

Tony

- - - - - - - - - - - - - - - - -

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Wed, 28 Aug 1996 13:36:19 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v03007820ae49140b08b4@[36.141.0.30]>, "John G. Scudder" writes:
> 
> I don't know if folks think it is also necessary to specify an algorithm to
> do this, e.g. the election Rich has written about.  I tend to think of this
> as an implementation detail, but if people are complaining that MED is too
> hard to implement, I guess an existence proof to the contrary might be
> useful.  Perhaps as an appendix?

Yes it is absolutely neccesary.  The order in which routes are
compared impacts the outcome of the comparison.

Lets say we don't.

Most readers will not notice that there is the possibility of a
routing loop.  Routing loops will form.

The very astute reader will notice that there is the possibility of a
routing loop if the order of comparison is not constrained to be the
same on all routers.  Said reader picks an algorithm.  The algorithm
chosen is to compare all routes in order of lowest advertising router
first.  These routers work fine in a network of like routers.  Put in
a router using Rich's algorithm and a routing loop forms since those
routers evaluate in a different order and come to a different
conclusion about which route is best.

This will form routing loops.  Its been proven in real networks.

The text could be as simple as:

> 5.1.4   MULTI_EXIT_DISC
> 
>    The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>    links to discriminate among multiple exit or entry points to the same
>    neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
>    octet unsigned number which is called a metric.  All other factors
>    being equal, the exit or entry point with lower metric should be
>    preferred.  If received over external links, the MULTI_EXIT_DISC
>    attribute may be propagated over internal links to other BGP speakers
>    within the same AS.  The MULTI_EXIT_DISC attribute is never
>    propagated to other BGP speakers in neighboring AS's.

   Due to the MED rules, route comparisons among all of the available
   routes may not have the transitive property.  Under some circumstances
   routing loops can form if routes are not evaluated in the same or a
   similar order on all routers.  The following order of comparison must
   be implemented:

   All routes from the same neighboring AS are compared.  The MED value
   and the presence or absence of MED must be considered when comparing
   routes from the same neighboring AS.  One route from the neighboring
   AS is selected as best.  The best routes from each of these
   neighboring AS are then compared.  The MED value or the presence or
   absence of MED must be ignored when comparing the best route from each
   neighboring AS.

This text assures that all implementors that carefully read an follow
the BGP4 spec will end up with implementations that 1) are loop free,
2) interoperate in a loop free manner with other implementations, 3)
don't require that MED be completely disabled to remain loop free in
the presence of other implementations.

Curtis
- - - - - - - - - - - - - - - - -

From: Mark A Gebert <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: Re: unsubscribe [email-masked] 
Date: Wed, 28 Aug 1996 07:38:07 -0400
Sender: [email-masked]

Done.

--geeb

------- Your Message ------

  Date:    Tue, 27 Aug 1996 13:48:22 PDT
  To:      [email-masked], [email-masked]
  cc:      [email-masked]
  From:    [email-masked]

  Subject: unsubscribe [email-masked]

  unsubscribe [email-masked]
  
  REPEATED ATTEMPTS HAVE BEEN MADE TO SO UNSUBSCRIBE THIS USER ... THE
  SYSTEM IS NO LONGER A "PUBLIC ACCESS SYSTEM" AND NO LONGER HAS A LOGNAME
  FOR THIS USER!

------- End of Your Message ------

- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Wed, 28 Aug 1996 03:14:33 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> Curtis,
> 
>    MEDs are useful and are still useful if compared across AS.  
> 
> Why?  There are clearly some semantics that you have in mind, but you're
> not expressing the need at all.  Given a global administrative metric
> (hmmm...  and I guess calling it the GAM attribute would lead us to be
> politically incorrect... ;-), what information are you trying to convey?  

No.  I'm saying that the normal case, at least for us, is to set
local-pref based on the border AS and then only resolve using MED if
the prefixes came from the same AS at two different places and it was
same router or different routers and cold potatoe.

The case where two border AS are announcing the same prefix at the
same local-pref is an odd case and the policy indication is "we don't
care - pick either one".  So I don't care which one gets picked as
long as the traffic goes out and doesn't go around in circles.

I'm not saying I want to compare MEDs across AS, just that if
local-pref ends up the same I don't want a routing loop.

If you want to finess it with Rich Woundy's MED election rather than
comparing MED across AS to avoid loops, then fine.  The group seems to
have come to consensus so please don't get pissed and start proposing
new attributes.

> I suppose that I can still see _some_ utility in expressing a local
> preference for an entry point where there are truly multiple interconnects,
> but I fail to see the need for global semantics.  Moreover, I can see that
> having two interacting metrics with global semantics is just another way to
> increase the complexity of the current (ridiculous) situation.

Thanks for the analysis.  We'll stick with best exit AS indicated by
local-pref, then either IGP cost or MED in the same AS.

>    The way
>    we use BGP, no two AS should be announcing the same prefix at the same
>    local-pref under normal circumstances.  If the local-pref were the
>    same I'd rather have something that didn't form a routing loop.
> 
> I'm confused.  How did local-pref enter the discussion?

See above.  If you still don't get it I'll explain a third time.

>    Getting rid of MED is not a constructive suggestion.
> 
> I'm very sorry you feel that way.  Perfection is only attained when you
> have removed everything that can be removed, and no more.  Perhaps you
> would care to make some simple, concrete, and constructive suggestions?
> 
> Tony

We seemed to have already reached consensus on the list for Rich's MED
election.  We still don't have a proposed change in the BGP4 text.  If
Rich is busy I'll write something.

Curtis
- - - - - - - - - - - - - - - - -

Date: Tue, 27 Aug 1996 16:28:39 -0700
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: decision process
Sender: [email-masked]

At 3:15 PM -0700 8/27/96, John G. Scudder wrote:
>If someone *has* actually implemented the "best external route" thing *in
>BGP* it would be interesting to know about that.

It was just pointed out to me that rcp_routed used to do this.  As far as I
know, rcp_routed is defunct, though.  Any current implementations?  And any
quantitative analysis?

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Tue, 27 Aug 1996 15:14:54 -0700
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: Addr: Re: BGP-4 - revised I-D
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Allow me to suggest that we have consensus regarding MED, and that said
consensus is (a) that it's useful and (b) should only be comparable between
like ASes.

Let me further suggest that this is already what RFC 1771 specifies, as
does draft-ietf-idr-bgp4-03.txt, but that the text in question is so vague
as to allow, nay, encourage differing interpretations.  Here it is:

5.1.4   MULTI_EXIT_DISC

   The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
   neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
   octet unsigned number which is called a metric.  All other factors
   being equal, the exit or entry point with lower metric should be
   preferred.  If received over external links, the MULTI_EXIT_DISC
   attribute may be propagated over internal links to other BGP speakers
   within the same AS.  The MULTI_EXIT_DISC attribute is never
   propagated to other BGP speakers in neighboring AS's.

This could be fixed by adding something like the following:

"MULTI_EXIT_DISC must not be considered when comparing routes received from
different neighboring ASes."

and I further think that at least one of the following is needed too:

a. "It must be possible to disable the consideration of MULTI_EXIT_DISC
when evaluating routes."

b. "It must be possible to remove the MULTI_EXIT_DISC attribute when it is
received from a neighboring AS.  This removal should be done prior to
propagating the route or determining its preference."

c. "It must be possible to enable the consideration of MULTI_EXIT_DISC when
evaluating routes."

Either (a) or (b) would allow interoperability between differing
implementations.  I like (b) better, because removing the attribute
entirely seems safer than having to twist a knob that says "ignore this
attribute" (and make sure you've twisted it into the same position on all
your routers).

(c) doesn't help with the transition case, but if (a) or (b) isn't chosen,
(c) had better be, otherwise the 5.1.4 text leaves it up to the discretion
of the implementor whether or not to implement MED at all ("...*may* be
used...").  (I hope everyone understands by now that IBGP interoperability
demands that it be possible to coerce all IBGP speakers to use the same
process for route selection.)

9.1.2.1.a should also be changed from:

      a) If the local system is configured to take into account
      MULTI_EXIT_DISC, and the candidate routes differ in their
      MULTI_EXIT_DISC attribute, select the route that has the lowest
      value of the MULTI_EXIT_DISC attribute.  A route with
      MULTI_EXIT_DISC shall be preferred to a route without
      MULTI_EXIT_DIST.

to something like:

      a) If the local system is configured to take into account
      MULTI_EXIT_DISC, and the candidate routes differ in their
      MULTI_EXIT_DISC attribute but were received from the same
      neighboring AS, select the route that has the lowest
      value of the MULTI_EXIT_DISC attribute.  A route with
      MULTI_EXIT_DISC shall be preferred to a route without
      MULTI_EXIT_DISC.

I don't know if folks think it is also necessary to specify an algorithm to
do this, e.g. the election Rich has written about.  I tend to think of this
as an implementation detail, but if people are complaining that MED is too
hard to implement, I guess an existence proof to the contrary might be
useful.  Perhaps as an appendix?

Maybe we can hum or rub our navels or something, adopt this text or
similar, and then anyone who wants to discuss GAMs or the like can do so
secure in the knowledge that MEDs work the way they ought.

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Tue, 27 Aug 1996 15:15:00 -0700
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: decision process
Cc: [email-masked], [email-masked]
Sender: [email-masked]

While perusing draft-ietf-idr-bgp4-03.txt for my last note, I noticed that
this is still in the draft (section 9.1):

      a) Phase 1 is responsible for calculating the degree of preference
      for each route received from a BGP speaker located in a
      neighboring autonomous system, and for advertising to the other
      BGP speakers in the local autonomous system the routes that have
      the highest degree of preference for each distinct destination.

I submit that as far as I know, no one actually disseminates routes which
they don't use via IBGP (or at all).  However, this text calls for what's
sometimes called "best external route" distribution.  The best external
route is not necessarily the selected route.

Given that this is not implemented anywhere as far as I know, I suggest
that the text be trimmed to read

      a) Phase 1 is responsible for calculating the degree of preference
      for each route received from a BGP speaker located in a
      neighboring autonomous system.

and part c should also be modified:

      c) Phase 3 is invoked after the Loc-RIB has been modified. It is
      responsible for disseminating routes in the Loc-RIB to each peer,
      according to the policies contained in the PIB. Route aggregation
      and information reduction can optionally be performed within this
      phase.

(this deletes the "located in a neighboring autonomous system" part)

If someone *has* actually implemented the "best external route" thing *in
BGP* it would be interesting to know about that.  Experience from IDRP
implementations which do this would also be interesting.  I know it was a
lot of work to do in gated IDRP -- it would be interesting to know what, if
any, measured real-world benefit it provides.

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Tue, 27 Aug 1996 13:48:22 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

Curtis,

   MEDs are useful and are still useful if compared across AS.  

Why?  There are clearly some semantics that you have in mind, but you're
not expressing the need at all.  Given a global administrative metric
(hmmm...  and I guess calling it the GAM attribute would lead us to be
politically incorrect... ;-), what information are you trying to convey?  

I suppose that I can still see _some_ utility in expressing a local
preference for an entry point where there are truly multiple interconnects,
but I fail to see the need for global semantics.  Moreover, I can see that
having two interacting metrics with global semantics is just another way to
increase the complexity of the current (ridiculous) situation.

   The way
   we use BGP, no two AS should be announcing the same prefix at the same
   local-pref under normal circumstances.  If the local-pref were the
   same I'd rather have something that didn't form a routing loop.

I'm confused.  How did local-pref enter the discussion?

   Getting rid of MED is not a constructive suggestion.

I'm very sorry you feel that way.  Perfection is only attained when you
have removed everything that can be removed, and no more.  Perhaps you
would care to make some simple, concrete, and constructive suggestions?

Tony

- - - - - - - - - - - - - - - - -

To: [email-masked] (Joel Halpern)
Cc: [email-masked] (John G. Scudder), [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Local Preference Computation 
Date: Mon, 26 Aug 1996 11:37:34 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Joel Halpern writes:
> I have been reading the local-pref/MED discussion, and trying to tie it
> back to my understanding of the assumptions that had been made originally.
> 
> As I understood things, the point of "local-pref" was to ensure that all
> border routers of an AS made the same choice of path for a given destination.
>  
> This would then allow the appropriate BGP advertisement to be generated by
> all AS boundary routers.
> 
> If I am reading the discussion right, the routing loops occur because
> the local-pref value is not sthe only thing being used.  Therefore, 
> internal routers (who do not have the full policy of the external border
> routers) are getting confused about what is happening?
> 
> 1) I would strongly suggest that the discussion would be helped by an 
>     explicit statement in each proposal of how the fields (MED an and 
>     local-pref) are to generated and compared for route selection.
> 2) If the old assumptions are no longer applicable, I would appreciate
>     an explanation of why.  The most obvious cause would be that some
>     underlying precept turns out not to be the case.  For example, the
>     local-pref stuff is basically based on assuming similarity of policy
>     mechanisms on all border routers of an AS. Does that no longer obtain?
> 
> Yours, with apologies for not being as current on some of the thinging as
> I should be,
> Joel M. Halpern			[email-masked]
> Newbridge Networks Inc.

MED has been used for a long time to pick the exit point that leads to
the shortest path in a peer's topology.  This was done by setting
outbound MED according to IGP cost and passing the MED learned from
EBGP into IBGP.

Our normal use is to give a unique local-pref to each border AS for a
given prefix.  In the event that some of the 30,000+ prefixes have two
border AS providing the same local-pref, I'm not fussy about which way
things go out as long as a routing loop doesn't form.

Other providers routinely set a fixed local-pref per all other ISPs
and a fixed local-pref for all direct customers.  This results in a
lot of local-prefs being the same.  It was for this reason that
aspath-length was introduced to route selection in Cisco's
implementation, regardless of what the spec said.  Even so, equal
as-path lengths could lead to resolving the decision at MED or lower
with two AS providing MED.

I think Rich Woundy's "MED election" is a good way to solve this.  If
there is agreement, we simply need to clearly write this up so vendors
all use the same algorithm and end up selecting the same route and
then put the text into BGP4.

The only reason I suggested comparing MED across AS is because I knew
it was trivial to code while "MED election" takes a non-zero amount of
effort.  MED election is a cleaner way to eliminate the route loops.
(In a nutshell, "MED election" is compare all routes from the same AS
first using MED, then compare the best from each AS ignoring MED.  If
I got this wrong, all the more reason to put it in BGP4 so someone
writing BGP4 code doesn't).

Curtis
- - - - - - - - - - - - - - - - -

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked]
Subject: Re: DPA replacement? 
From: Tony Bates <[email-masked]>
Date: Sun, 25 Aug 1996 15:07:03 -0700
Sender: [email-masked]

 "John G. Scudder" <[email-masked]> writes:
  * A little while ago I was wrestling with the current DPA drafts and figured
  * out the the respective drafts and RFCs (the DPA draft, the DPA usage draft,
  * and RFC 1771) form kind of a contradiction loop.  This seems to stem from
  * the fact that the current DPA draft wants to treat DPA as a global
  * administratively defined metric (which still carries around AS numbers for
  * some reason even though there's not a reasonable way to use them) or maybe

The purpose of the AS number is just for potential debugging use as it
indicates which AS originated ther DPA value. As you state you can see
that we have been back on forth on this issue a few times within the drafts.

  * (it isn't clear) as an arbitrary tag (even though Communities does this
  * just fine).  It's quite clear in either case that the DPA should be used to
  * bias or set localpref.  The usage draft, on the other hand, keeps the
  * earlier idea of making DPA a MED-like metric which is only comparable when
  * the AS part of the DPA matches.  But, RFC 1771 says you can't do elections

Yes this is really our fault for not tidying up the usage draft after
we finalized on making DPA be an influence on LOOCAL_PREF.

  * when biasing or setting localpref.
  * 
  * This got me thinking about what DPA really wants to do and I ended up with
  * the following ideas, which are basically tricks to try to make a global
  * metric useful.  Your feedback is solicited.  Comments from network
  * operators as to the real-world usefulness of any mechanism such as this (or
  * the current DPA draft for that matter) would be particularly interesting.
  * 

This really comes down to trying to give some indication of the range
you want something like DPA to apply within the LOCAL_PREF influence
algorithm. I still need to think about your proposal but at first pass
using LOCAL_PREF as we stated seems to be equally as easy (or hard
depending on your perspective) as calculating the values in your
global metric for the tricky case below.  However, one thing I think
this type of calculation lends itself to is the notion of "scope"
which could well be of use. Need to think about this ore first though.

		--Tony

  * This is still pretty drafty; there are a number of unresolved notes in
  * [square brackets].  Also, I didn't spend any time trying to come up with a
  * clever TLA, this leads to some textual awkwardness where I refer to "the
  * attribute" or "the metric" generically.  Sorry.
  * 
  * --John
  * 
  * 
  * Introduction
  * ------------
  * 
  * The current DPA proposal <draft-ietf-idr-bgp-dpa-05.txt> differs from
  * earlier versions of the document in that it eliminates the requirement that
  * only DPAs with like source ASes be comparable.  This makes the AS# portion
  * of the DPA largely redundant; it also increases the possibility of
  * conflicts in scenarios such as that shown in section 3 of
  * <draft-ietf-idr-dpa-application-02.txt>.
  * 
  * Also, scenarios such as the aforementioned suffer from DPA's inability to
  * select between multiple branching paths.  The application document suggests
  * using Local_Pref to overcome this limitation.  This proposal outlines
  * another approach, involving a globally significant metric which is refined
  * in smaller and smaller increments as it propagates further from its
  * originator.
  * 
  * The proposed algorithm allows the preference of each AS in the path to be
  * reflected in the metric.  Total ordering is preserved in many cases, but
  * see the "Limitations" section for notable exceptions.
  * 
  * Path Attribute
  * --------------
  * 
  * This document proposes an optional transitive path attribute of fixed
  * length.  The attribute is a range of integers represented by a pair <lower,
  * upper>.  Both values are four octet, non-negative integers.  The attribute
  * may be modified by ASes other than the orginator, according to the
  * following algorithm.  The attribute must not be replaced other than
  * according to the following algorithm.  [How about removing it?]
  * 
  * [Originator's AS# could also be included if anyone can think of a good use
  * for it.]
  * 
  * Route Selection Process
  * -----------------------
  * 
  * For the purposes of route selection, <lower> should be considered to be the
  * metric.  Routes with a higher metric should be preferred to routes with a
  * lower metric.  [This could be by biasing the local_pref, or by including
  * the comparison after the local_pref comparison.]  Routes with any metric
  * should be preferred over similar routes without any metric.
  * 
  * Operation
  * ---------
  * 
  * When an AS originates routes for which it wishes to bias upstream selection
  * preference, it should set the metrics according to the following algorithm:
  * 
  * Call the received attribute <rcv_lower, rcv_upper>
  * range = rcv_upper - rcv_lower
  * n = number of distinct preferences with which the route is to be offered
  * p = ordinal preference of the route in question, with the most preferred
  * route having the highest preference, and the least preferred route having
  * preference ordinal 1.  Note that several routes could have the same
  * preference.
  * 
  * For a route with preference p,
  * 
  *         lower = rcv_lower + (p-1) * range/n
  *         upper = rcv_lower +   p   * range/n
  * 
  * When originating a route, rcv_lower is defined as 0 and rcv_upper is
  * defined as 2^32-1.  [Or rcv_lower could be defined as 1; this could be
  * convenient since 0 could be used as a magic cookie meaning "no metric"
  * which would also sort correctly per the rules above.]  Otherwise, when
  * propagating a route, rcv_lower and rcv_upper are taken from the received
  * attribute.
  * 
  * If the AS propagating the route has no wish to bias upstream selection
  * preference, it need not (and should not) modify the attribute.
  * 
  * The intent of this algorithm is to divide the original sender's preference
  * up into a set of non-overlapping ranges whose ordering reflects the
  * preferences of all transit ASes which have such preference.  [But see
  * "Limitations" for cases where ranges can overlap.]
  * 
  * [Hmm, what do we do when we work range sizes all the way down to zero?
  * This won't take long in principle, but in practice we might actually have a
  * low enough diameter to make this a non-issue?]
  * 
  * Example
  * -------
  * 
  * Here is an example, with a comparison to DPA:
  * 
  *         A-------B----------------D----+
  *         |                        |\   |
  *         +-------C--------E-------+ \  |
  *                 |\                  | |
  *                 | -------F----------+ |
  *                 |                     |
  *                 +--------G------------+
  * 
  * Consider A-G to be ASes.  Suppose that A prefers to receive packets via B.
  * Likewise, C prefers to receive packets for A via E over F and F over G.
  * 
  * Using DPAs, A could send DPA <A, 2> to B and <A, 1> to C.  C could send DPA
  * <C, 3> to E, <C, 2> to F and <C, 1> to G.  D would have no way within the
  * context of DPA of choosing between B and E.  This could be fixed using
  * Local_Pref, but the amount of coordination required seems undesirable if
  * another workable option is available.
  * 
  * Using the algorithm above, A would originate two attributes.  To B, it
  * would send <2147483648, 4294967295>.  To C it would send <0, 2147483648>.
  * C would originate three attributes.  To E it would send <1431655765,
  * 2147483648>.  To F it would send <715827883, 1431655765>.  To G it would
  * send <0, 715827883>.  D would then be able to determine the desired
  * ordering (B beats E beats F beats G).
  * 
  * Limitations
  * -----------
  * 
  * This scheme preserves a total ordering on the metric so long as each AS
  * where branching occurs has a preference and thus modifies the attribute
  * (such as in the example).  In the event that a branching occurs with no
  * modification of the preference, followed by a reconvergence of paths, some
  * of the ordering property is lost.  That is, ranges may overlap.  For
  * example:
  * 
  * 	B--------C--------E--------J
  * 	|	 |		   |
  * 	|	 +--------F--------|
  * 	|			   |
  * 	+--------D--------G--------|
  * 		 |		   |
  * 		 +--------H--------+
  * 
  * Suppose B has no preference between C or D, but C prefers E over F, and D
  * prefers G over H.  When J receives B's routes from E, F, G and H it will be
  * able to determine that it should prefer (E or G) over (F or H) but will not
  * be able to determine by examining the metric whether to prefer E or G.
  * 
  * As long as all "primary" paths are up, this behaves as desired, by allowing
  * J to choose whichever preferred path it likes.  However, if one primary
  * path (E, for example) goes down, traffic for B will be "attracted" to the
  * remaining "primary" path (G in this case).  This might not be desirable.
  * 
  * In a similar vein, consider this case, similar to the previous but with the
  * addition of AS K.  D prefers G over H over K:
  * 
  * 	B--------C--------E--------J
  * 	|	 |		   |
  * 	|	 +--------F--------|
  * 	|			   |
  * 	+--------D--------G--------|
  * 		 |		   |
  * 		 |--------H--------|
  * 		 |		   |
  * 		 +--------K--------+
  * 
  * In this case J will prefer (E or G) over (F or H or K).  However, we also
  * now have H preferred over F preferred over K.  This is just an artifact of
  * the algorithm and doesn't really reflect any particular preference of any
  * downstream AS.
  * 
  * --
  * John Scudder                        email:  [email-masked]
  * 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
  * 
  * 
- - - - - - - - - - - - - - - - -

Date: Sun, 25 Aug 1996 00:37:01 -0700
To: [email-masked] (Joel Halpern)
From: "John G. Scudder" <[email-masked]>
Subject: Re: Addr: Local Preference Computation
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Joel,

At 11:46 AM -0400 8/24/96, Joel Halpern wrote:
>I have been reading the local-pref/MED discussion, and trying to tie it
>back to my understanding of the assumptions that had been made originally.
>
>As I understood things, the point of "local-pref" was to ensure that all
>border routers of an AS made the same choice of path for a given destination.
>This would then allow the appropriate BGP advertisement to be generated by
>all AS boundary routers.

Sort of.  All the border routers don't have to make the *same* choice,
though they do have to make a *consistent* choice, where consistent means
"loop free".  Localpref allows one border router to tell all the other
routers what policy it applied to a route it imported.  This is good
because it allows each border router to only have to worry about the policy
for its direct neighbors, not all the neighbors of the whole AS.  (The
latter has obvious scaling problems on several axes.)

(As a small digression, I kind of hate the use of the word "policy" as a
forty-dollar word to mean "preference".  Saying that we use localpref to
export our "policy" is confusing because it sounds like maybe it has more
semantics than it does.  It's just an integer.  End digression.)

>If I am reading the discussion right, the routing loops occur because
>the local-pref value is not the only thing being used.  Therefore,
>internal routers (who do not have the full policy of the external border
>routers) are getting confused about what is happening?

This is not quite how I would put it.  I'd say, rather, that the problem is
that we use IBGP as a defacto IGP.  In fact it seems to have some of the
criteria of a link-state IGP insofar as external routing information is
sent AS-wide using IBGP and each router in the AS is then responsible for
independently computing its next hops based on that information.  (This is
pretty similar to link state advertisements getting flooded around, only
the mechanism for doing it is cruder than the flooding a real link state
protocol uses.)

If you think of it that way, you'll see that, like with your favorite
link-state IGP, it's critical that all the internal guys use absolutely
identical criteria for route selection.  Unfortunately this doesn't seem to
have fully sunk in until a bit late in the game.

If IBGP was really just for hauling path attributes around, and the IGP
carried the actual forwarding stuff, then we wouldn't have this problem.
(We'd have others, but that's another rathole.)

By the way, the problem is also not quite that "the local-pref value is not
the only thing being used" but rather that there are dissimilar lists of
things being used.  In fact RFC 1771 specifies a whole list of things to be
used after localpref, in the (rather likely) event of a localpref tie.
This, in itself, is good.  The two problems are (a) one of the specified
tie-breakers, MED, is underspecified, and (b) some folks add their own
nonstandard tie-breakers.

The attraction of putting stuff into localpref is that localpref *does*
work right but isn't used for enough.  If everyone agreed that their custom
knobs would just be a way to bias the localpref rather than sticking
non-interoperable lower-order tie-breakers in, then we could interoperate
happily, since localpref is a nice opaque integer which we can compare
without regard to the exact method used to compute it.

>1) I would strongly suggest that the discussion would be helped by an
>    explicit statement in each proposal of how the fields (MED an and
>    local-pref) are to generated and compared for route selection.

I kinda think that much of the point is that computation of localpref
should be an implementation-specific thing.  The stuff which has been
floated so a seems to be in the nature of (as I think Curtis said) a sample
algorithm to prove that this is reasonable.  If this is right then I don't
think that we need to focus on explicit methods for generation of localpref.

RFC 1771 and follow-ons already are quite clear on how to compare
localpref.  MED does need to be fixed.

To my way of thinking the open questions are not exactly the ones you pose
above, but rather:

- Is putting everything into localpref sufficiently flexible to provide
everything that vendors will want to offer their customers?  Or will they
again be tempted to put other stuff into the route selection process?  If
the latter, is there some generic/standard/safe way to let them do this?
(q.v. my off-the-cuff notion of extended localprefs).

- What's the right thing to do with MED?  (I think there is not too much
debate on this.)

- Do we need to have a way to introduce other MED-like things, which I
think can't be stuffed into localpref (someone please prove me wrong).  Is
there some way to do this which will guarantee loop-free interoperability
between different implementations?

>2) If the old assumptions are no longer applicable, I would appreciate
>    an explanation of why.  The most obvious cause would be that some
>    underlying precept turns out not to be the case.  For example, the
>    local-pref stuff is basically based on assuming similarity of policy
>    mechanisms on all border routers of an AS. Does that no longer obtain?

I'm not sure what you mean by "assumes similarity of policy mechanisms" but
it doesn't sound quite right to me.  Perhaps you could explain this more if
you want to pursue this train of thought.

I trust I make myself obscure?

Regards,

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Sat, 24 Aug 1996 17:50:58 -0700
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: DPA replacement?
Sender: [email-masked]

A little while ago I was wrestling with the current DPA drafts and figured
out the the respective drafts and RFCs (the DPA draft, the DPA usage draft,
and RFC 1771) form kind of a contradiction loop.  This seems to stem from
the fact that the current DPA draft wants to treat DPA as a global
administratively defined metric (which still carries around AS numbers for
some reason even though there's not a reasonable way to use them) or maybe
(it isn't clear) as an arbitrary tag (even though Communities does this
just fine).  It's quite clear in either case that the DPA should be used to
bias or set localpref.  The usage draft, on the other hand, keeps the
earlier idea of making DPA a MED-like metric which is only comparable when
the AS part of the DPA matches.  But, RFC 1771 says you can't do elections
when biasing or setting localpref.

This got me thinking about what DPA really wants to do and I ended up with
the following ideas, which are basically tricks to try to make a global
metric useful.  Your feedback is solicited.  Comments from network
operators as to the real-world usefulness of any mechanism such as this (or
the current DPA draft for that matter) would be particularly interesting.

This is still pretty drafty; there are a number of unresolved notes in
[square brackets].  Also, I didn't spend any time trying to come up with a
clever TLA, this leads to some textual awkwardness where I refer to "the
attribute" or "the metric" generically.  Sorry.

--John

Introduction
------------

The current DPA proposal <draft-ietf-idr-bgp-dpa-05.txt> differs from
earlier versions of the document in that it eliminates the requirement that
only DPAs with like source ASes be comparable.  This makes the AS# portion
of the DPA largely redundant; it also increases the possibility of
conflicts in scenarios such as that shown in section 3 of
<draft-ietf-idr-dpa-application-02.txt>.

Also, scenarios such as the aforementioned suffer from DPA's inability to
select between multiple branching paths.  The application document suggests
using Local_Pref to overcome this limitation.  This proposal outlines
another approach, involving a globally significant metric which is refined
in smaller and smaller increments as it propagates further from its
originator.

The proposed algorithm allows the preference of each AS in the path to be
reflected in the metric.  Total ordering is preserved in many cases, but
see the "Limitations" section for notable exceptions.

Path Attribute
--------------

This document proposes an optional transitive path attribute of fixed
length.  The attribute is a range of integers represented by a pair <lower,
upper>.  Both values are four octet, non-negative integers.  The attribute
may be modified by ASes other than the orginator, according to the
following algorithm.  The attribute must not be replaced other than
according to the following algorithm.  [How about removing it?]

[Originator's AS# could also be included if anyone can think of a good use
for it.]

Route Selection Process
-----------------------

For the purposes of route selection, <lower> should be considered to be the
metric.  Routes with a higher metric should be preferred to routes with a
lower metric.  [This could be by biasing the local_pref, or by including
the comparison after the local_pref comparison.]  Routes with any metric
should be preferred over similar routes without any metric.

Operation
---------

When an AS originates routes for which it wishes to bias upstream selection
preference, it should set the metrics according to the following algorithm:

Call the received attribute <rcv_lower, rcv_upper>
range = rcv_upper - rcv_lower
n = number of distinct preferences with which the route is to be offered
p = ordinal preference of the route in question, with the most preferred
route having the highest preference, and the least preferred route having
preference ordinal 1.  Note that several routes could have the same
preference.

For a route with preference p,

        lower = rcv_lower + (p-1) * range/n
        upper = rcv_lower +   p   * range/n

When originating a route, rcv_lower is defined as 0 and rcv_upper is
defined as 2^32-1.  [Or rcv_lower could be defined as 1; this could be
convenient since 0 could be used as a magic cookie meaning "no metric"
which would also sort correctly per the rules above.]  Otherwise, when
propagating a route, rcv_lower and rcv_upper are taken from the received
attribute.

If the AS propagating the route has no wish to bias upstream selection
preference, it need not (and should not) modify the attribute.

The intent of this algorithm is to divide the original sender's preference
up into a set of non-overlapping ranges whose ordering reflects the
preferences of all transit ASes which have such preference.  [But see
"Limitations" for cases where ranges can overlap.]

[Hmm, what do we do when we work range sizes all the way down to zero?
This won't take long in principle, but in practice we might actually have a
low enough diameter to make this a non-issue?]

Example
-------

Here is an example, with a comparison to DPA:

        A-------B----------------D----+
        |                        |\   |
        +-------C--------E-------+ \  |
                |\                  | |
                | -------F----------+ |
                |                     |
                +--------G------------+

Consider A-G to be ASes.  Suppose that A prefers to receive packets via B.
Likewise, C prefers to receive packets for A via E over F and F over G.

Using DPAs, A could send DPA <A, 2> to B and <A, 1> to C.  C could send DPA
<C, 3> to E, <C, 2> to F and <C, 1> to G.  D would have no way within the
context of DPA of choosing between B and E.  This could be fixed using
Local_Pref, but the amount of coordination required seems undesirable if
another workable option is available.

Using the algorithm above, A would originate two attributes.  To B, it
would send <2147483648, 4294967295>.  To C it would send <0, 2147483648>.
C would originate three attributes.  To E it would send <1431655765,
2147483648>.  To F it would send <715827883, 1431655765>.  To G it would
send <0, 715827883>.  D would then be able to determine the desired
ordering (B beats E beats F beats G).

Limitations
-----------

This scheme preserves a total ordering on the metric so long as each AS
where branching occurs has a preference and thus modifies the attribute
(such as in the example).  In the event that a branching occurs with no
modification of the preference, followed by a reconvergence of paths, some
of the ordering property is lost.  That is, ranges may overlap.  For
example:

	B--------C--------E--------J
	|	 |		   |
	|	 +--------F--------|
	|			   |
	+--------D--------G--------|
		 |		   |
		 +--------H--------+

Suppose B has no preference between C or D, but C prefers E over F, and D
prefers G over H.  When J receives B's routes from E, F, G and H it will be
able to determine that it should prefer (E or G) over (F or H) but will not
be able to determine by examining the metric whether to prefer E or G.

As long as all "primary" paths are up, this behaves as desired, by allowing
J to choose whichever preferred path it likes.  However, if one primary
path (E, for example) goes down, traffic for B will be "attracted" to the
remaining "primary" path (G in this case).  This might not be desirable.

In a similar vein, consider this case, similar to the previous but with the
addition of AS K.  D prefers G over H over K:

	B--------C--------E--------J
	|	 |		   |
	|	 +--------F--------|
	|			   |
	+--------D--------G--------|
		 |		   |
		 |--------H--------|
		 |		   |
		 +--------K--------+

In this case J will prefer (E or G) over (F or H or K).  However, we also
now have H preferred over F preferred over K.  This is just an artifact of
the algorithm and doesn't really reflect any particular preference of any
downstream AS.

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

From: [email-masked] (Joel Halpern)
Subject: Re: Addr: Local Preference Computation
To: [email-masked] (John G. Scudder)
Date: Sat, 24 Aug 1996 11:46:04 -0400 (EDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I have been reading the local-pref/MED discussion, and trying to tie it
back to my understanding of the assumptions that had been made originally.

As I understood things, the point of "local-pref" was to ensure that all
border routers of an AS made the same choice of path for a given destination. 
This would then allow the appropriate BGP advertisement to be generated by
all AS boundary routers.

If I am reading the discussion right, the routing loops occur because
the local-pref value is not sthe only thing being used.  Therefore, 
internal routers (who do not have the full policy of the external border
routers) are getting confused about what is happening?

1) I would strongly suggest that the discussion would be helped by an 
    explicit statement in each proposal of how the fields (MED an and 
    local-pref) are to generated and compared for route selection.
2) If the old assumptions are no longer applicable, I would appreciate
    an explanation of why.  The most obvious cause would be that some
    underlying precept turns out not to be the case.  For example, the
    local-pref stuff is basically based on assuming similarity of policy
    mechanisms on all border routers of an AS. Does that no longer obtain?

Yours, with apologies for not being as current on some of the thinging as
I should be,
Joel M. Halpern			[email-masked]
Newbridge Networks Inc.

- - - - - - - - - - - - - - - - -

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Sat, 24 Aug 1996 02:16:14 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v0300782aae444ba7b401@[152.160.213.42]>, "John G. Scudder" writes:
> At 1:31 AM -0400 8/24/96, Curtis Villamizar wrote:
> >Proper MED handling wouldbe loop free.  The current BGP4 RFC allows
> >loops to be formed if a prefix is announced from 3 places by 2 AS all
> >announcing MED.
> >
> >MED clearly has to be changed.  The question is which of the two
> >proposed fixes to use.  Leaving the current loopfull MED is not
> >useful.  We've seen routing loops.
> 
> Ah, sorry.  I didn't make it clear that I don't consider any MED handling
> which can result in routing loops to be "proper".  I guess I have been
> convinced that what Rich calls an "election" is the right way to do MED.
> In fact RFC 1771 kind of says this, but in a very vague way:
> 
>    The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
>    links to discriminate among multiple exit or entry points to the same
>    neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
>    octet unsigned number which is called a metric.  All other factors
>    being equal, the exit or entry point with lower metric should be
>    preferred.  If received over external links, the MULTI_EXIT_DISC
>    attribute may be propagated over internal links to other BGP speakers
>    within the same AS.  The MULTI_EXIT_DISC attribute is never
>    propagated to other BGP speakers in neighboring AS's.
> 
> Note the clauses "same neighboring AS" and "all other factors being equal."
> 
> Anyway, I think that we're in violent agreement.
> 
> --John

Consensus seems to be leaning toward Rich's solution.  That's OK with
me.  It is harder to code since you can't simply compare the route
just learned with the current best route, you have to first compare
with the best route from the same AS, then compare to the overall
best route.  Still not terible.

Curtis

- - - - - - - - - - - - - - - - -

Date: Sat, 24 Aug 1996 02:07:58 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: Addr: Re: BGP-4 - revised I-D
Cc: [email-masked]
Sender: [email-masked]

At 1:31 AM -0400 8/24/96, Curtis Villamizar wrote:
>Proper MED handling wouldbe loop free.  The current BGP4 RFC allows
>loops to be formed if a prefix is announced from 3 places by 2 AS all
>announcing MED.
>
>MED clearly has to be changed.  The question is which of the two
>proposed fixes to use.  Leaving the current loopfull MED is not
>useful.  We've seen routing loops.

Ah, sorry.  I didn't make it clear that I don't consider any MED handling
which can result in routing loops to be "proper".  I guess I have been
convinced that what Rich calls an "election" is the right way to do MED.
In fact RFC 1771 kind of says this, but in a very vague way:

   The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
   neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
   octet unsigned number which is called a metric.  All other factors
   being equal, the exit or entry point with lower metric should be
   preferred.  If received over external links, the MULTI_EXIT_DISC
   attribute may be propagated over internal links to other BGP speakers
   within the same AS.  The MULTI_EXIT_DISC attribute is never
   propagated to other BGP speakers in neighboring AS's.

Note the clauses "same neighboring AS" and "all other factors being equal."

Anyway, I think that we're in violent agreement.

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Sat, 24 Aug 1996 01:49:33 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: Addr: Local Preference Computation
Cc: BGP Working Group <[email-masked]>
Sender: [email-masked]

At 1:22 AM -0400 8/23/96, [email-masked] wrote:
>Folks,
>
>Well, here it is; your comments are solicited...
[...]

Rich,

Thanks for getting the ball rolling on this.  Here is the concern I have
with any scheme which aims to stick everything into localpref:  The dynamic
range is way too small.

The examples you've given do indeed put path length and origin nicely into
a range which is well within the 32 bits we've got to work with in
localpref.  The problem is other path attributes which influence path
selection.  Some such attributes are indeed things which divide routes
into, as you've put it, equivalence classes.  Presumably the number of
equivalence classes in such cases will be relatively small.  However, other
new attributes can be expected to be metric-like, e.g. DPA.  These
typically may each have a range which is equal to that of localpref.  To
jam all this into the 32 bit localpref, presumably you have to (a) scale
them down (potentially losing resolution you needed), (b) restrict their
range (which will not be reasonable in some cases), or (c) not use them.  I
don't find any of these options terribly appealing.

One possible solution might be to introduce the notion of an extended
localpref, analogous to preference2 (and beyond) in gated.  That is, if you
fill up the 32 bit localpref, tack on another 32 bits which are less
significant than the first 32, and so on until you have enough.  Doing this
in a network with "old" routers which don't understand extended preferences
would still invite routing loops, but at least it would define an extension
mechanism once all routers can understand extended prefs.

Another possible solution of course is to argue that in real life 32 bits
is plenty (sound familiar?).  I for one still need to be convinced.

The other point is attributes which aren't globally comparable, e.g. MEDs,
and DPAs in their first (and more reasonable, IMO) incarnation.  I think
that it is probably not reasonable to require that for ever after, all BGP
attributes must be globally comparable.  How can this be addressed in a
world where everything is based on comparison of opaque integers?  Is it
worth throwing out this baby with the interoperability bathwater?  I
suppose you could kludge around this somehow.  For example, if you allow
UserFunction() to be a function of not only the current route but also the
current RIB, you can run an election and bias the preference of the winner
high enough to beat all other routes.  (As described this sounds
suspiciously like it could result in two routers with differing notions of
"best" engaging in ballot-box stuffing for their favored candidates until
the metric overflows, though.)

Regards,

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Sat, 24 Aug 1996 01:31:24 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v03007824ae4405944243@[152.160.213.42]>, "John G. Scudder" writes:
> 
> Furthermore, if this is to be done, there's no special reason to deprecate
> MED.  Just provide a knob to allow stripping it at the border.  If you are
> running a network that includes routers which don't support proper MED
> handling, you'd best turn the "strip MED" knob.
> 
> --John

John,

Proper MED handling wouldbe loop free.  The current BGP4 RFC allows
loops to be formed if a prefix is announced from 3 places by 2 AS all
announcing MED.

MED clearly has to be changed.  The question is which of the two
proposed fixes to use.  Leaving the current loopfull MED is not
useful.  We've seen routing loops.

Curtis
- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Sat, 24 Aug 1996 01:26:46 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
>    I personally prefer NOT to compare MED values from different neighbor ASs.
>    The usage of MED is to distinguish multiple exit points to a particular
>    external AS.  If the WG decides to compare MED values from different ASs
>    then I suggest the definition of the MEDs and the reference to MEDs in
>    the bgp4 spec needs to be changed as well.
> 
> If one were to follow down this path of global MED values, we're pretty
> much all the way back to a global administratively defined metric.  We can
> go there if folks want, but global metrics have always been a rathole to be
> avoided.
> 
> I would further suggest that any such metric might as well be an entirely
> new attribute, and that we allow MED to die a quiet death.
> 
> Tony

Tony,

MEDs are useful and are still useful if compared across AS.  The way
we use BGP, no two AS should be announcing the same prefix at the same
local-pref under normal circumstances.  If the local-pref were the
same I'd rather have something that didn't form a routing loop.

I don't care if the solution is to compare MED across AS or to use
Rich Woundy's scheme of comparing allroutes on the basis of AS using
MED and then compare the best from each AS ignoring MED.  Both will
prevent route loops.  Some people find the former to be ugly but it is
much easier to code.

Getting rid of MED is not a constructive suggestion.

Curtis
- - - - - - - - - - - - - - - - -

Date: Fri, 23 Aug 1996 21:06:28 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

At 5:54 PM -0700 8/23/96, Tony Li wrote:
>If one were to follow down this path of global MED values, we're pretty
>much all the way back to a global administratively defined metric.  We can
>go there if folks want, but global metrics have always been a rathole to be
>avoided.

I agree.

>I would further suggest that any such metric might as well be an entirely
>new attribute, and that we allow MED to die a quiet death.

Furthermore, if this is to be done, there's no special reason to deprecate
MED.  Just provide a knob to allow stripping it at the border.  If you are
running a network that includes routers which don't support proper MED
handling, you'd best turn the "strip MED" knob.

--John

--
John Scudder                        email:  [email-masked]
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

- - - - - - - - - - - - - - - - -

Date: Fri, 23 Aug 1996 17:54:33 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

   I personally prefer NOT to compare MED values from different neighbor ASs.
   The usage of MED is to distinguish multiple exit points to a particular
   external AS.  If the WG decides to compare MED values from different ASs
   then I suggest the definition of the MEDs and the reference to MEDs in
   the bgp4 spec needs to be changed as well.

If one were to follow down this path of global MED values, we're pretty
much all the way back to a global administratively defined metric.  We can
go there if folks want, but global metrics have always been a rathole to be
avoided.

I would further suggest that any such metric might as well be an entirely
new attribute, and that we allow MED to die a quiet death.

Tony
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: Curtis Villamizar <[email-masked]>, BGP Working Group <[email-masked]>, Tony Li <[email-masked]>
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Fri, 23 Aug 1996 17:02:13 -0400
From: Jessica Yu <[email-masked]>
Sender: [email-masked]

>If we (as a working group) agree that we should not compare MED values
>from different neighbor ASes, then we should at least document a MED
>election algorithm somewhere.

I personally prefer NOT to compare MED values from different neighbor ASs.
The usage of MED is to distinguish multiple exit points to a particular
external AS.  If the WG decides to compare MED values from different ASs
then I suggest the definition of the MEDs and the reference to MEDs in
the bgp4 spec needs to be changed as well.

Below is one of the places in bgp4 spec refering to MEDs. 

5.1.4   MULTI_EXIT_DISC

   The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
								^^^ ^^^^
   neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
   ^^^^^^^^^^^^^^
   octet unsigned number which is called a metric.  All other factors
   being equal, the exit or entry point with lower metric should be
   preferred.  If received over external links, the MULTI_EXIT_DISC
   attribute may be propagated over internal links to other BGP speakers
   within the same AS.  The MULTI_EXIT_DISC attribute is never
   propagated to other BGP speakers in neighboring AS's.

							--Jessica
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: BGP Working Group <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Addr: Local Preference Computation 
Date: Fri, 23 Aug 1996 12:22:35 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <19960823.012218.RWOUNDY@RHQVM21>, [email-masked] writes:
> Folks,
> 
> Well, here it is; your comments are solicited...
> 
> -- Richard Woundy, IBM

Rich,

Lets treat this and the BGP4 draft together.

wrt BGP4 - we still need wording to clearly define what to do when
comparing MEDs from different AS.  One vendor just compares MED
regardless of AS.  This is loop free in a single vendor network.  You
have proposed that MEDs be compared among the same AS first, then the
best from each AS compared, ignoring MED.  That would be loop free in
a single vendor network.  The two algorithms in the same network, as
would occur in a multivendor network, would form loops.  Yakov, Tony -
please fix.  I personally don't care which way you fix it, but I know
a router vendor who would rather compares MED regardless of AS because
it is easier to do (rough translation - easy for me to say since I
don't have to write the code).

This does eliminate the need to mention aspath-length in BGP4.  I
still think BGP4 needs a clear statement that any other criteria in
the route selection is non-conformant to BGP4.

> This idea was originally suggested by Paul Traina in the IDR Working
> Group meeting at the Montreal IETF (June 1996), but the author accepts
> responsibility for all errors in this memo.

Paul should be shot.  After Vadim.  ;-)

> Two variables in the local preference calculation are based on specific
> attributes of a specific BGP route R: ASPathLength(R) and OriginCode(R)
> -- in this memo these variable names are shortened to ASPathLength and
> OriginCode. The ASPathLength is the number of ASes (including
> duplicates) in all AS path segments in the route's AS_PATH. Because the
> maximum BGP message size is 4096 octets, and AS numbers are two octets,
> the maximum ASPathLength is less than 2048. The OriginCode is the same
> as the ORIGIN data octet, with legal values 0, 1, and 2. Therefore,
>   0 <= ASPathLength < 2048, and
>   0 <= OriginCode < 3.

Vendors can do this part differently.  Maybe you should call this an
example implementation.  For example, I would prefer an ASset be
counted as one regardless of how many AS are in the set.  This will
not penalize people for aggregating carefully rather than just tossing
the ASpath.

Your example amounts to fixing Ciscos implementation to interoperate
with others with minimal change.

> The local preference calculation function becomes
>   LocalPreference = CounterBalanceWeight
>                     - (ASPathLengthFactor * ASPathLength)
>                     - (OriginCodeFactor * OriginCode)
>                     + LocalPrefMin.

Plus configured constant.

> As an example, suppose an ISP wants to favor BGP routes with shorter AS
> paths, and favor lower origin codes when routes have the same AS path
> length. In addition, the ISP wants a minimum local preference value of
> 101, because the default local preference value for its non-upgraded
> routers is 100. The ISP can configure
>   ASPathLengthFactor = 3,
>   OriginCodeFactor = 1, and
>   LocalPrefMin = 101.
> Then, CounterBalanceWeight = 6143, and 101 <= LocalPreference <= 6244.

If an ISP can hear this from two different AS and wants to
administratively prefer one set of announcements over the other adding
a constant of 8192 would do the trick.  

Imagine I want to support up to 10 administratively configured
preference values.  If I want to configure MCI backup for a BBN
customer, I'd configure:

  BBN:
  ASPathLengthFactor = 3
  OriginCodeFactor = 1
  LocalPrefMin = 101
  LocalPrefOffset = 8192 * (11-1)

  MCI:
  ASPathLengthFactor = 3
  OriginCodeFactor = 1
  LocalPrefMin = 101
  LocalPrefOffset = 8192 * (11-2)

I might do this for an entire AS-macro (and in fact I do, setting
policy for each prefix the AS macro expands to).  Now suppose in
addition to this AS-macro one of the AS has a connection to some other
provider and now falls into another AS-macro.  We'd have another set
of:

  OtherGuys:
  ASPathLengthFactor = 3
  OriginCodeFactor = 1
  LocalPrefMin = 101
  LocalPrefOffset = 8192 * (11-1)

(btw- If they tell us about this we can set policy to give them
whatever preference order they want, but this sort of thing does
happen).

There is now a tie in the LocalPrefOffset for BBN and OtherGuys.  At
this point the other criteria takes over.

> The local preference calculation function, for routes from equivalence
> class k, becomes
>   LocalPreference = CounterBalanceWeight
>                     - (ASPathLengthFactor * ASPathLength)
>                     - (OriginCodeFactor * OriginCode)
>                     + LocalPrefMin
>                     + UserFunction(k), where UserFunction(k) is a
> function with parameter k. The actual function depends on the relative
> priority of the policy feature with respect to AS path length and origin
> codes for the ISP policy. Note that the value of UserFunction(k) is the
> same for all routes that belong to equivalence class k, for ease of
> configuration. To prevent the local preference calculation result from
> wrapping its four octet value, the router should ensure that
>   CounterBalanceWeight + LocalPrefMin + max(UserFunction(k)) < 2**32.

This is interesting.  How many UserFunctions do you think your router
vendor should provide (0, 1, infinity?).  Is zero a valid choice?
Mapping attributes into UserFunctions could get tricky and would sure
make for a fun time coding dynamic reconfig (and a lot of CPU running
it).  Still its a good idea.

I can see wanting to consider a UserFunction based on BGP community
and a separate UserFunctions based on perhaps border AS, possibly
another on something else like protocol-source (EBGP, IGP, direct).
Or maybe DPA (PMED, the Bates/Enke attribute, whatever it is).  This
would imply that infinity (or a high integer) would be the best choice
for number of UserFunctions.

In gated the config syntax reads like:

  import proto bgp as xxx {
	prefix masklen len preference value ;
		-or-
	as-path path origin type preference value ;
  };

In Bays config this is (functionally):

  import {
	proto bgp;
	from-as xxx;
	local-pref value;
	prefix-list {
		prefix mask the-mask;
		...
	};
		-and-
	as-path path;
		-and-
	origin type;
  };

There is an implied AND in statements within a policy.  The advantage
is that currently local-pref is set for an entire block of addresses.
If this becomes a calculation,then there is a need for policy
statement that don't imply acceptance, but rather set a variable.  For
example:

  set-value {
	set-user-function N lisp-sexp ;
	...  whole mess of existing policy crtieria
  };

  import {
	action accept;
	...  whole mess of existing policy crtieria
  };

btw- the lisp-sexp is only half joking.  You need an expression syntax
that pulls in certain variables.  For example, you'd need AspathLength
if you want to support the example you gave setting a variable to
k*AspathLength for K different sets of border-as or origin-as or
as-path patterns or whatever.

An incoming prefix may then match any number of policy statements
(preferably a small number) and each would contribute variables that
were used when a statement that actually accepts the route is hit (or
not used if a statement is hit that rejects the route).

(btw- this is not Bay's syntax, it is closer to gated syntax and Bay
semantics).

I think this would be done somehow by modifying route-map syntax and
semantics in IOS, but I'll let Cisco worry about that.  (Or worry
together off list if they want).

> Future Work (unordered)
> -----------------------
> 
> - working group consensus
> - Cisco and gated implementations

I can't speak for Bay, but IMO they'd be interested too.

> - sample configs on real systems
> - ISP trials

What you are really asking for is standardization of config knobs.  I
don't think that's a good idea unless you are sure you have the
ultimate solution to all config problems.

This draft is really just pointing out that there can be creative
ways to set local-pref that can be quite useful and don't negatively
impact loop free interoperability the way introducing new criteria
to the route selection does.

I think this should go out as an informational RFC and provide
examples.  Its OK to make some strong recommendations (like supporting
AspathLength would be high on your list of priorities).

Curtis
- - - - - - - - - - - - - - - - -

Date: Fri, 23 Aug 96 10:50:02 EDT
From: [email-masked] (Dimitry Haskin)
To: [email-masked], [email-masked]
Subject: Re: Addr: Local Preference Computation
Sender: [email-masked]

Richard,

> To: BGP Working Group <[email-masked]>
> Subject: Addr: Local Preference Computation
> 
> Folks,
> 
> Well, here it is; your comments are solicited...
> 
> -- Richard Woundy, IBM
> 
> 
> Incorporating Multiple Policy Criteria into the Local Preference
> ================================================================
> 
> Richard Woundy
> IBM
> [email-masked]
> 8/23/96
> 
> 
> Summary
> -------
> 
> Most current BGP router implementations introduce other tie-breakers,
> besides the tie-breakers listed in (RFC-1771), to the BGP path selection
> process. These other tie-breakers usually include shortest AS path
> length and lowest origin code, and are hard-coded into the router
> software. Because the existence and the ordering of such tie-breakers
> are not standardized nor universally accepted, I-BGP route loops are
> likely when routers from different vendors are deployed in a single BGP
> autonomous system.
> 
> This memo recommends an approach in which the ISP's policies concerning
> AS path length, origin code, and other factors, are folded into the
> I-BGP local preference value. The BGP border router calculates the local
> preference using a linear function with user-configurable weighting
> factors. As an additional feature, the router operator may specify
> additional policy statements that increment or decrement (not merely
> set) the local preference value.
> 
> This idea was originally suggested by Paul Traina in the IDR Working
> Group meeting at the Montreal IETF (June 1996), but the author accepts
> responsibility for all errors in this memo.
> 

With all respect, this idia has been suggested to IDR WG a number of
times in the past.  Indirectly it is alluded to in RFC-1772 (Section 6).
Bay has been using bgp path attribute parameters to calculate LOCAL_PREF
in its BGP-4 implementation since the intial BGP-4 release a few years ago.

On a more constructive note, Bay has been using the following simple equation
to calculate LOCAL_PREF (if it is not explicitly set by a policy):

 LOCAL_PREF = 8191 - (<ORIGIN> == IGP ? 0 : 4096) - <AS path weight>

 <AS path weight> is a sum of weight values associated with AS numbers 
 listed  in the route's AS_PATH attribute.  These weight values can be 
 configured or,  if not configured,  default to 8.

Dimitry
- - - - - - - - - - - - - - - - -

From: [email-masked]
Date: 23 Aug 96 01:22:18 EDT
To: BGP Working Group <[email-masked]>
Subject: Addr: Local Preference Computation
Sender: [email-masked]

Folks,

Well, here it is; your comments are solicited...

-- Richard Woundy, IBM

Incorporating Multiple Policy Criteria into the Local Preference
================================================================

Richard Woundy
IBM
[email-masked]
8/23/96

Summary
-------

Most current BGP router implementations introduce other tie-breakers,
besides the tie-breakers listed in (RFC-1771), to the BGP path selection
process. These other tie-breakers usually include shortest AS path
length and lowest origin code, and are hard-coded into the router
software. Because the existence and the ordering of such tie-breakers
are not standardized nor universally accepted, I-BGP route loops are
likely when routers from different vendors are deployed in a single BGP
autonomous system.

This memo recommends an approach in which the ISP's policies concerning
AS path length, origin code, and other factors, are folded into the
I-BGP local preference value. The BGP border router calculates the local
preference using a linear function with user-configurable weighting
factors. As an additional feature, the router operator may specify
additional policy statements that increment or decrement (not merely
set) the local preference value.

This idea was originally suggested by Paul Traina in the IDR Working
Group meeting at the Montreal IETF (June 1996), but the author accepts
responsibility for all errors in this memo.

Advantages
----------

The approach of this memo offers two primary advantages for ISPs: a
reasonable basis for multivendor I-BGP interoperability, and an ability
to configure more flexible ISP-specific routing policies.

To promote multivendor I-BGP interoperability, router vendors should be
encouraged to remove the hard-coded explicit comparisons of AS path
lengths and origin codes. Past experience has shown that different BGP
implementations have chosen different attributes, or different
comparison orderings, that conflict with other existing BGP
implementations' choices; the result is routing loops in multivendor
router environments. Multivendor I-BGP interoperability is possible if
router implementations follow the path selection steps outlined in
(RFC-1771): lowest local preference, lowest MED, lowest interior
distance, external before internal routes, and lowest BGP ID. Router
vendors can ensure reasonable path selection with minimal user
configuration by selecting reasonable default weighting factors
(described below) for the local preference calculation.

An ISP may configure alternate weighting factors in the local preference
calculation for ISP-specific policies. For example, an ISP can ignore
the origin code in BGP path selection by setting the local preference
weighting factor for origin codes to zero. An ISP may also change the
relative priority of (virtual) attribute comparisons by selecting the
appropriate weighting factors. Assuming that all routers in the
autonomous system use the same path selection algorithm (per the
previous paragraph), then even inconsistent weighting factors within an
autonomous system will not cause I-BGP routing loops.

Note that some interim router configuration options may be needed to
transition from current BGP implementations to implementations based on
this memo, since it may not be possible to update software of all BGP
routers simultaneously in some autonomous systems. However,
implementations based on this memo will interoperate with
implementations using future local preference calculation functions, so
long as all implementations use the same path selection rules.

Local Preference Calculation Variables
--------------------------------------

The local preference is a four octet non-negative integer, for which
higher values are preferred. The local preference calculation must
ensure that its output is also a non-negative integer.

Two variables in the local preference calculation are based on specific
attributes of a specific BGP route R: ASPathLength(R) and OriginCode(R)
-- in this memo these variable names are shortened to ASPathLength and
OriginCode. The ASPathLength is the number of ASes (including
duplicates) in all AS path segments in the route's AS_PATH. Because the
maximum BGP message size is 4096 octets, and AS numbers are two octets,
the maximum ASPathLength is less than 2048. The OriginCode is the same
as the ORIGIN data octet, with legal values 0, 1, and 2. Therefore,
  0 <= ASPathLength < 2048, and
  0 <= OriginCode < 3.

An ISP can control its routing policy with the user configuration
variables ASPathLengthFactor and OriginCodeFactor, which are specified
as non-negative integers. If an ISP wishes to ignore the ORIGIN
attribute in BGP path selection, it can assign an OriginCodeFactor of
zero, for example.

Since most ISPs prefer shorter AS paths and lower origin codes (if they
have any preference at all), the ASPathLengthFactor and OriginCodeFactor
are implicitly negative in the local preference calculation. To prevent
the local preference calculation from producing negative results, this
memo defines a variable CounterBalanceWeight, where
  CounterBalanceWeight = (2047 * ASPathLengthFactor)
                          + (2 * OriginCodeFactor).

Finally, an ISP may configure the LocalPrefMin variable, which can be
useful for local preference calculation transition. To prevent the local
preference calculation result from wrapping its four octet value, the
router should ensure that
  CounterBalanceWeight + LocalPrefMin < 2**32.

The local preference calculation function becomes
  LocalPreference = CounterBalanceWeight
                    - (ASPathLengthFactor * ASPathLength)
                    - (OriginCodeFactor * OriginCode)
                    + LocalPrefMin.

As an example, suppose an ISP wants to favor BGP routes with shorter AS
paths, and favor lower origin codes when routes have the same AS path
length. In addition, the ISP wants a minimum local preference value of
101, because the default local preference value for its non-upgraded
routers is 100. The ISP can configure
  ASPathLengthFactor = 3,
  OriginCodeFactor = 1, and
  LocalPrefMin = 101.
Then, CounterBalanceWeight = 6143, and 101 <= LocalPreference <= 6244.

If the ISP wanted to favor BGP routes with lower origin codes, and favor
shorter AS paths when routes have the same origin code, then the ISP can
configure
  ASPathLengthFactor = 1,
  OriginCodeFactor = 2048, and
  LocalPrefMin = 101.
Then, CounterBalanceWeight = 6143, and 101 <= LocalPreference <= 6244.

Modifications to the Local Preference Calculation
-------------------------------------------------

The routing policy of an ISP often takes into account more than just AS
path length and the origin code. An ISP may wish to account for
characteristics such as neighbor ASes, specific AS path patterns, and/or
BGP communities when evaluating routes.

This memo defines a "policy feature" to be a means of classifying routes
into a small set of equivalence classes, over which is defined a total
ordering. In English, this means that any two routes in the same
equivalence class are equivalent with respect to the policy feature, and
that all routes from one equivalence class are uniformly either "better"
or "worse" than all the routes from another equivalence class with
respect to the policy feature. Assume that there are K equivalence
classes for a given feature, where K >= 1. Each equivalence class is
assigned an integer value k, 0 <= k < K, where equivalence classes with
larger values of k are better than classes with smaller values of k.

As a concrete example, suppose an ISP wants to configure a BGP
community-based policy feature, in which community attribute values A
and B are equivalent, attribute values A and B are better than attribute
value C, and attribute value C is better than any other attribute value
(or a missing community attribute). This policy feature contains three
equivalence classes (K = 3). Routes with community attribute values A
and/or B are labelled k = 2, routes with value C are labelled k = 1, and
all other routes are labelled k = 0.

To simplify the discussion, this memo only discusses a single policy
feature at a time, instead of multiple policy features which may have
different relative priorities within the ISP's routing policy. Further,
this memo considers policy features that add to, not subtract from, the
local preference value.

The local preference calculation function, for routes from equivalence
class k, becomes
  LocalPreference = CounterBalanceWeight
                    - (ASPathLengthFactor * ASPathLength)
                    - (OriginCodeFactor * OriginCode)
                    + LocalPrefMin
                    + UserFunction(k), where UserFunction(k) is a
function with parameter k. The actual function depends on the relative
priority of the policy feature with respect to AS path length and origin
codes for the ISP policy. Note that the value of UserFunction(k) is the
same for all routes that belong to equivalence class k, for ease of
configuration. To prevent the local preference calculation result from
wrapping its four octet value, the router should ensure that
  CounterBalanceWeight + LocalPrefMin + max(UserFunction(k)) < 2**32.

First, suppose that the ISP policy (virtually) is to consider the policy
feature first before either the AS path lengths or origin codes. This
can be configured by defining
  UserFunction(k) = k * CounterBalanceWeight,
and ensuring that
  (K * CounterBalanceWeight) + LocalPrefMin < 2**32.
This example is a primary reason that this memo distinguishes between
the CounterBalanceWeight and LocalPrefMin variables.

Now suppose that the ISP policy is to consider the policy feature as a
tie-breaker after comparing AS path lengths and origin codes. This can
be configured by multiplying ASPathLengthFactor and OriginCodeFactor by
K (the number of equivalence classes), and by setting
  UserFunction(k) = k.
For example, if the ISP policy is to consider AS path length first,
then the origin code, and finally the policy feature, then it configures
  ASPathLengthFactor = 3 * K,
  OriginCodeFactor = K, and
  UserFunction(k) = k.
Again, the 2**32 upper limit on local preference must be observed.

Modifications with Non-Unique Local Preference Values
-----------------------------------------------------

The previous local preference calculation discussions assume that
different combinations of policy feature equivalence class, AS path
length, and origin code need to map to unique local preference values.
This property is required when a rigid hierarchy of comparisons is
desired -- for example, first BGP community, then AS path length, then
origin code.

However, not all ISP policies are completely hierarchical. For example,
consider an ISP policy for which routes from certain "semi-confederate"
neighbor ASes are to be treated as if their AS path length is shorter by
one AS number (this is somewhat different from using true BGP AS
Confederations, in which the AS path is not lengthened between
confederates). An ISP can configure this policy by classifying routes
from the "semi-confederate" neighbors in class k = 1, and all other
routes into class k = 0, and setting
  UserFunction(k) = k * ASPathLengthFactor.
Of course, the 2**32 upper limit on local preference must be observed.

Future Work (unordered)
-----------------------

- working group consensus
- Cisco and gated implementations
- sample configs on real systems
- ISP trials

- - - - - - - - - - - - - - - - -

To: "NITTMANN Michael (MSMail)" <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, "[email-masked]" <[email-masked]>, BGP Working Group <[email-masked]>, Tony Li <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Thu, 22 Aug 1996 12:56:08 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <c=US%a=_%p=SHL%l=SHL/CANADAW/[email-masked]>, "NITT
MANN Michael (MSMail)" writes:
> ... just one little thing:
> 
> incorporating the AS path length into local pref calculation is reasonable 
> for boiler plate situations. But it happened to me often to chose a longer 
> path with less latency over a shorter path.
> Path length is really not a good measure. The old method I used was 
> padding,which looks ugly and gives then also skewed statistics when looking 
> at a traffic matrix.
> 
> Can we have a button then to chose how the components are weighted? I would 
> really like to get away from the AS path 'length', more to an AS wide 
> override for routes. 

Under normal circumstances, we don't use as-path length at all.  Some
providersd like it.  That's why I suggested puttring it in as an
option.  We'd enable it but set local-pref on a prefix basis (which
would make it normally a NOOP).  If somehow we had two AS listed as
primary in policies then it would make a difference.

> A gadget I would like is an rtt and packet loss measurement capability for 
> certain paths. Thus I can weigh my backbone according to meetpoint load 
> effects. Currently the only way to do this is by using Tivoli and 
> reconfiguring routers. That's ok, but if we could get this into the routing 
> engine itself this would be really nice.

This is BGP4 we are talking about.  AI capabilities are rolled into a
future version.  ;-)  Just kidding, but you get the point.

> ... most of the original article deleted ...
> 
> Regards
> 
> Mike

Regards,

Curtis
- - - - - - - - - - - - - - - - -

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: Curtis Villamizar <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: BGP Working Group <[email-masked]>, Tony Li <[email-masked]>
Subject: RE: Addr: Re: BGP-4 - revised I-D
Date: Thu, 22 Aug 1996 08:20:18 -0600
Encoding: 104 TEXT
Sender: [email-masked]

... just one little thing:

incorporating the AS path length into local pref calculation is reasonable 
for boiler plate situations. But it happened to me often to chose a longer 
path with less latency over a shorter path.
Path length is really not a good measure. The old method I used was 
padding,which looks ugly and gives then also skewed statistics when looking 
at a traffic matrix.

Can we have a button then to chose how the components are weighted? I would 
really like to get away from the AS path 'length', more to an AS wide 
override for routes. 

A gadget I would like is an rtt and packet loss measurement capability for 
certain paths. Thus I can weigh my backbone according to meetpoint load 
effects. Currently the only way to do this is by using Tivoli and 
reconfiguring routers. That's ok, but if we could get this into the routing 
engine itself this would be really nice.

... most of the original article deleted ...

Regards

Mike

----------
From:  [email-masked][SMTP:[email-masked]]
Sent:  Wednesday, August 21, 1996 1:39 PM
To:  Curtis Villamizar
Cc:  BGP Working Group; Tony Li
Subject:  Addr: Re: BGP-4 - revised I-D

>Date: Tue, 20 Aug 1996 21:24:02 -0400
>From: Curtis Villamizar <[email-masked]>

>Yakov,

>BGP4 is great stuff but for it to advance, we really should clean up
.....cut.....
>environments, but mostly when mixing implementations.

Curtis,

I agree with this 100%, but I disagree with the details below.

>First, here are conditions that can cause routing loops.  These all
>involves differences in route selection criteria or route selection
...cut...

I think Paul Traina had the best idea here: incorporate the AS path
length and origin code selection criteria into the local pref value
(therefore, leave the main BGP spec as is).

I think I now understand how the local pref computation *could* work;
maybe I can send a note about it to the mailing list today.

>   c. Differences in interpretation of a missing MED and poor choice
>      of behavior covering a missing MED.  Without going into details
>      (see below) preferring a route with no MED over one with a
>      MED can cause route loops.  Not considering MED at all in
>      comparing routes with MED to routes without can cause route
>      loops.  This is addresses by the changes you've made.

I think at least one more change is needed in the new draft: removing
the clause "if the local system is configured to take into account MEDs"
I thought we agreed in Montreal that this configuration option does
not exist in today's routers, does not provide value-add to providers,
and can result in routing loops when internal peers are misconfigured
with respect to each other.  The reason why it does not provide value
add is that providers can change MEDs in BGP updates (ala "route-map")
to a uniform value (say 0), which effectively makes the path selection
step of comparing MEDs into a perpetual tie.

Should this be revisited (i.e. did I see consensus where none existed)?

Also, I thought we agreed that a missing MED on a route would be equal
to, not worse than, a MED of -1 on a route. The reason was to avoid a
separate check of whether the MED existed, with the (trivial) penalty
of losing one out of 2**32 MED values.

...cut...

the MED:

yes, I am running into problems there allthe time. What is missing is a real 
coupling: if I set a preferred path into an As, that AS should reconfigure 
to honor that preferred path automatically. 

Currently the only way to achieve something like this is in a static way, 
calling up the peers and asking for favours. Well, most have overloaded 
staff, or not the experience at all to address such a configuration issue.

An exchange and automatic adatpation of a preferred path, need some 
optimizing negotiation of course, is also good for meetpoint load balancing 
per peer AS. This would bring us away from everyone and his dog going 
through mae-e all the time. With a good backbone it is unimportant to what 
meetpoint I go (e.g. ATM cloud as a center).

In my opinion, the MED story should be resurrected. It was a good idea in 
the first place. Only the negotiation piece between routing engines was 
missing.
Yes, this is not simple.

Mike
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4 - revised I-D 
Date: Tue, 20 Aug 1996 21:24:02 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> Folks,
> 
> Today we (Tony and myself) submitted a revised version
> of BGP-4 I-D. The only two essential changes are in
> Section 9.1.2.1 clause (a), and Section 9.2.1.1 clause (a).
> The changes reflect the agreement we reached at the
> last IDR WG meeting.
> 
> Yakov.

Yakov,

BGP4 is great stuff but for it to advance, we really should clean up
the document to make it harder to come up with implementations that
are compatible with the BGP4 RFC but don't interoperate well enough
with other implementations to insure loop free operation.

We gained a lot of experience with gated, Cisco, and Bay
implementations of BGP4.  Subtle differences in the route selection
rules of each can cause route loops, in some cases in single vendor
environments, but mostly when mixing implementations.

The changes in Section 9.1.2.1 clause (a), and Section 9.2.1.1 clause
(a) take a step toward addressing this but don't do a complete job.

Please consider the problems described below and the suggested
changes.

Regards,

Curtis

First, here are conditions that can cause routing loops.  These all
involves differences in route selection criteria or route selection
criteria that can cause routing loops if routes are evaluated in
different orders on different routers in a network.

   a. We haven't seen anyone lose the significance of local-preference
      as the primary selection criteria.  I'd like to see the spec
      absolutely clear about this.

   b. We have seen routing loops form as a result of some routers
      using AS-path length in the decision criteria.  If this is not
      standard behavior, then the spec needs to say that.  If this is
      useful (it is) but not standard behavior, the spec needs to
      allow it as an option.

   c. Differences in interpretation of a missing MED and poor choice
      of behavior covering a missing MED.  Without going into details
      (see below) preferring a route with no MED over one with a
      MED can cause route loops.  Not considering MED at all in
      comparing routes with MED to routes without can cause route
      loops.  This is addresses by the changes you've made.

   d. Without going into details (see below) not considering MED
      when comparing routes from different AS can cause routing loops.
      This is not addressed by the changes you've made.  BGP4 needs to
      explicitly require considering MED when comparing routes from
      different AS.

Details of route loops in a) and b) should be obvious.

For b), consider:

	R1  --2--  R2  --1--  R3  --4-- R4

R1 announces a route with AS path length 2, R4 announces the same
route with AS path length 1.  R2 considers AS path length and picks
R4, R3 doesn't consider AS path length and picks R1.  R2 and R3 point
next hops at each other.

Details of route loops in c) and d) are provided here.  

If there is ever a case where the comparison of three or more routes
is not a transitive operation, the order that routes appear on
interior routers will affect the outcome.  If routes arrive at
interior routers in different orders, which is common with IBGP or
with EBGP redistributed using IGP external routes, a routing loop can
form.  Examples are given below.  This has been observed in practice.

Refer to the diagram below where R{1-5} are routers and the numbers on
the lines are IGP link costs.

    R1  --6--  R4  --1--  R5  --4--  R3
    R2  --2-/

   c.	preferring a route with no MED

		MED	IGP		
	R1	 -	6-7		R2 is better than R1 (lower IGP)
	R2	 -	2-3		R3 is better than R2 (no MED)
	R3	 2	4-5		R1 is better than R3 (no MED)

	R4 learns R1, R2, R3.  It prefers R3.
	R5 learns R1, R3, R2.  It prefers R2.  (R2 announcement delayed)
	R4 and R5 point next hop at each other.

	not considering MED comparing routes with MED to routes without

		MED	IGP		
	R3	 -	4-5		R2 is better than R3 (lower IGP)
	R2	 1	2-3		R1 is better than R2 (lower MED)
	R1	 2	6-7		R3 is better than R1 (lower IGP)

	R4 learns R1, R2, R3.  It prefers R3.  (R3 announcement delayed)
	R5 learns R3, R1, R2.  It prefers R2.
	R4 and R5 point next hop at each other.

   d.	not considering MED when comparing routes from different AS

	(same as prior example)

	    AS	MED	IGP		
	R3   x	 1	4-5		R2 is better than R3 (lower IGP)
	R2   y	 2	2-3		R1 is better than R2 (lower MED)
	R1   y	 3	6-7		R3 is better than R1 (lower IGP)

	R4 learns R1, R2, R3.  It prefers R3.  (R3 announcement delayed)
	R5 learns R3, R1, R2.  It prefers R2.
	R4 and R5 point next hop at each other.

With that out of the way (hopefully), we can go about fixing BGP4 so
route loops can't form between any two implementation that adhere to
the BGP4 RFC.

In 9.1.1:

   ...

   For each newly received or replacement feasible route, the local BGP
   speaker shall determine a degree of preference. If the route is
   learned from a BGP speaker in the local autonomous system, either the
   value of the LOCAL_PREF attribute shall be taken as the degree of
   preference, or the local system shall compute the degree of
   preference of the route based on preconfigured policy information.

+  A BGP4 implementation may consider AS_PATH length after LOCAL_PREF.
+  Shorter AS_PATH length may be preferred over longer AS_PATH lengths
+  as an option.  All implementations MUST have the ability to disable
+  this option.  The length shall be considered to be the sum of the
+  number of AS in each AS_SEQUENCE plus the number of AS_SET in the
+  AS_PATH.  Note that each AS_SET contributes one to the computed
+  sum regardless of how many AS are in the AS_SET and each
+  AS_SEQUENCE contributes the number of AS in the AS_SEQUENCE to the
+  sum.

In 9.1.2 (back reference for improved clarity):

   For each set of destinations for which a feasible route exists in the
   Adj-RIBs-In, the local BGP speaker shall identify the route that has:

!  a) the highest degree of preference of any route using the criteria
!     described in 9.1.1, or

In 9.1.2.1:

      a) If the local system is configured to take into account
      MULTI_EXIT_DISC, and the candidate routes differ in their
      MULTI_EXIT_DISC attribute, select the route that has the lowest
      value of the MULTI_EXIT_DISC attribute.  A route with
      MULTI_EXIT_DISC shall be preferred to a route without
!     MULTI_EXIT_DIST.  MULTI_EXIT_DISC shall be compared regardless
+     of the AS that the candidate routes were heard from and
+     regardless of any difference in the AS_PATH.

	...

         - otherwise, select the route that was advertised by the BGP
         speaker whose BGP Identifier has the lowest value.

+  Any deviation from the selection criteria described here can be
+  implemented as long as the deviation is optional.  An example is
+  the AS_PATH length option described in 9.1.1.1.  There MUST be a
+  way to disable any supported deviation from the selection criteria.
+  Any deviation MUST be clearly indicated as such.  It SHOULD be as
+  easy as possible to select the standard BGP4 route selection.
- - - - - - - - - - - - - - - - -

From: [email-masked]
Date: 21 Aug 96 14:39:29 EDT
To: Curtis Villamizar <[email-masked]>
Cc: BGP Working Group <[email-masked]>, Tony Li          <[email-masked]>
Subject: Addr: Re: BGP-4 - revised I-D
Sender: [email-masked]

>Date: Tue, 20 Aug 1996 21:24:02 -0400
>From: Curtis Villamizar <[email-masked]>

>Yakov,

>BGP4 is great stuff but for it to advance, we really should clean up
>the document to make it harder to come up with implementations that
>are compatible with the BGP4 RFC but don't interoperate well enough
>with other implementations to insure loop free operation.

>We gained a lot of experience with gated, Cisco, and Bay
>implementations of BGP4.  Subtle differences in the route selection
>rules of each can cause route loops, in some cases in single vendor
>environments, but mostly when mixing implementations.

Curtis,

I agree with this 100%, but I disagree with the details below.

>First, here are conditions that can cause routing loops.  These all
>involves differences in route selection criteria or route selection
>criteria that can cause routing loops if routes are evaluated in
>different orders on different routers in a network.

>   a. We haven't seen anyone lose the significance of local-preference
>      as the primary selection criteria.  I'd like to see the spec
>      absolutely clear about this.

>   b. We have seen routing loops form as a result of some routers
>      using AS-path length in the decision criteria.  If this is not
>      standard behavior, then the spec needs to say that.  If this is
>      useful (it is) but not standard behavior, the spec needs to
>      allow it as an option.

I think Paul Traina had the best idea here: incorporate the AS path
length and origin code selection criteria into the local pref value
(therefore, leave the main BGP spec as is).

I think I now understand how the local pref computation *could* work;
maybe I can send a note about it to the mailing list today.

>   c. Differences in interpretation of a missing MED and poor choice
>      of behavior covering a missing MED.  Without going into details
>      (see below) preferring a route with no MED over one with a
>      MED can cause route loops.  Not considering MED at all in
>      comparing routes with MED to routes without can cause route
>      loops.  This is addresses by the changes you've made.

I think at least one more change is needed in the new draft: removing
the clause "if the local system is configured to take into account MEDs"
I thought we agreed in Montreal that this configuration option does
not exist in today's routers, does not provide value-add to providers,
and can result in routing loops when internal peers are misconfigured
with respect to each other.  The reason why it does not provide value
add is that providers can change MEDs in BGP updates (ala "route-map")
to a uniform value (say 0), which effectively makes the path selection
step of comparing MEDs into a perpetual tie.

Should this be revisited (i.e. did I see consensus where none existed)?

Also, I thought we agreed that a missing MED on a route would be equal
to, not worse than, a MED of -1 on a route. The reason was to avoid a
separate check of whether the MED existed, with the (trivial) penalty
of losing one out of 2**32 MED values.

>   d. Without going into details (see below) not considering MED
>      when comparing routes from different AS can cause routing loops.
>      This is not addressed by the changes you've made.  BGP4 needs to
>      explicitly require considering MED when comparing routes from
>      different AS.

You do not have to require comparison of MED values from different ASes
(I speak from implementation and network deployment experience here).
You need to change the path selection comparisons somewhat from the
simple binary comparisons that often exist in BGP implementations.

For example, here are three paths to the same destination prefix, where
simple sequential comparison fails:
 path 1 from neighbor AS X, MED 10, IGP distance 20
 path 2 from neighbor AS Y, MED 15, IGP distance 15
 path 3 from neighbor AS X, MED 20, IGP distance 10
Using binary comparisons (all other factors being equal), path 2 is
better than path 1, path 3 is better than path 2, and path 1 is better
than path 3.

What I implemented in gated (not necessarily the best way, but it works)
is what I have called "MED election".  When receiving a BGP update
from neighbor AS Z, I compare and mark all of the routes for the same
prefix from neighbor AS Z that have the best MED value (note that it
is easy to get ties). Then, I use binary comparisons to sort the list
of routes. At the path selection stage where MEDs are considered, I
compare "best-MED-from-its-neighbor-AS" marks instead of MED values.

In the example above, paths 1 and 2 would have the best-MED marks,
and path 3 would not (because of the existance of path 1).
I do not directly compare MEDs *values* from different neighbor ASes,
but I compare best-MED *marks* from different neighbors ASes instead.

I've heard Cisco has fixed their version of this problem recently, but I
don't know what their implementation looks like.

If we (as a working group) agree that we should not compare MED values
from different neighbor ASes, then we should at least document a MED
election algorithm somewhere.

My biggest concern about MED election is the extra effort required
(read: CPU load on non-default routers).

-- Richard Woundy, IBM, [email-masked]

P.S. The expiration date of the latest spec needs to be fixed, too.

- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: Curtis Villamizar <[email-masked]>, BGP Working Group <[email-masked]>, Tony Li <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Addr: Re: BGP-4 - revised I-D 
Date: Wed, 21 Aug 1996 16:56:22 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Hi Rich,

Good to hear from you.

In message <19960821.143930.RWOUNDY@RHQVM21>, [email-masked] writes:
> >Date: Tue, 20 Aug 1996 21:24:02 -0400
> >From: Curtis Villamizar <[email-masked]>
> 
> >Yakov,
> 
> >BGP4 is great stuff but for it to advance, we really should clean up
> >the document to make it harder to come up with implementations that
> >are compatible with the BGP4 RFC but don't interoperate well enough
> >with other implementations to insure loop free operation.
> 
> >We gained a lot of experience with gated, Cisco, and Bay
> >implementations of BGP4.  Subtle differences in the route selection
> >rules of each can cause route loops, in some cases in single vendor
> >environments, but mostly when mixing implementations.
> 
> Curtis,
> 
> I agree with this 100%, but I disagree with the details below.
> 
> >First, here are conditions that can cause routing loops.  These all
> >involves differences in route selection criteria or route selection
> >criteria that can cause routing loops if routes are evaluated in
> >different orders on different routers in a network.
> 
> >   a. We haven't seen anyone lose the significance of local-preference
> >      as the primary selection criteria.  I'd like to see the spec
> >      absolutely clear about this.
> 
> >   b. We have seen routing loops form as a result of some routers
> >      using AS-path length in the decision criteria.  If this is not
> >      standard behavior, then the spec needs to say that.  If this is
> >      useful (it is) but not standard behavior, the spec needs to
> >      allow it as an option.
> 
> I think Paul Traina had the best idea here: incorporate the AS path
> length and origin code selection criteria into the local pref value
> (therefore, leave the main BGP spec as is).
> 
> I think I now understand how the local pref computation *could* work;
> maybe I can send a note about it to the mailing list today.

We need administrative control over local-pref.  If some router vendor
wants to set local-pref according to some function based on a
configured value and the as-path length, that's OK.  If the choice is
either a configured value or based on as-path length, then for us
as-path length simply won't be considered.

I prefer keeping as-path length separate and explicitly mentioned in
BGP4.  I'd like to see both included in the decision with a given AS
given the option to consider as-path length or ignore it.

If there is consensus, then the consensus seems to be that as-path
length will never be considered by the protocol machinery but a
particular router vendor has a scheme to compute local-pref based at
least partially on as-path length.  Then you need an explicit
exclusion or a blanket exclusion of any other criteria as I had in the
last addition to the text.

> >   c. Differences in interpretation of a missing MED and poor choice
> >      of behavior covering a missing MED.  Without going into details
> >      (see below) preferring a route with no MED over one with a
> >      MED can cause route loops.  Not considering MED at all in
> >      comparing routes with MED to routes without can cause route
> >      loops.  This is addresses by the changes you've made.
> 
> I think at least one more change is needed in the new draft: removing
> the clause "if the local system is configured to take into account MEDs"
> I thought we agreed in Montreal that this configuration option does
> not exist in today's routers, does not provide value-add to providers,
> and can result in routing loops when internal peers are misconfigured
> with respect to each other.  The reason why it does not provide value
> add is that providers can change MEDs in BGP updates (ala "route-map")
> to a uniform value (say 0), which effectively makes the path selection
> step of comparing MEDs into a perpetual tie.
> 
> Should this be revisited (i.e. did I see consensus where none existed)?
> 
> Also, I thought we agreed that a missing MED on a route would be equal
> to, not worse than, a MED of -1 on a route. The reason was to avoid a
> separate check of whether the MED existed, with the (trivial) penalty
> of losing one out of 2**32 MED values.

The -1 thing is OK with me.  

I don't think a machine should ever be not "configured to take into
account MEDs".  I agree that the draft should be changed.  If some but
not all routers are configured to ignore MED route loops are almost
certain if MEDs are present.

What might need to be added is the option to pass MED into IBGP or not
pass MED into IBGP.  (I didn't look carefully - is it in there?).

> >   d. Without going into details (see below) not considering MED
> >      when comparing routes from different AS can cause routing loops.
> >      This is not addressed by the changes you've made.  BGP4 needs to
> >      explicitly require considering MED when comparing routes from
> >      different AS.
> 
> You do not have to require comparison of MED values from different ASes
> (I speak from implementation and network deployment experience here).
> You need to change the path selection comparisons somewhat from the
> simple binary comparisons that often exist in BGP implementations.
> 
> For example, here are three paths to the same destination prefix, where
> simple sequential comparison fails:
>  path 1 from neighbor AS X, MED 10, IGP distance 20
>  path 2 from neighbor AS Y, MED 15, IGP distance 15
>  path 3 from neighbor AS X, MED 20, IGP distance 10
> Using binary comparisons (all other factors being equal), path 2 is
> better than path 1, path 3 is better than path 2, and path 1 is better
> than path 3.
> 
> What I implemented in gated (not necessarily the best way, but it works)
> is what I have called "MED election".  When receiving a BGP update
> from neighbor AS Z, I compare and mark all of the routes for the same
> prefix from neighbor AS Z that have the best MED value (note that it
> is easy to get ties). Then, I use binary comparisons to sort the list
> of routes. At the path selection stage where MEDs are considered, I
> compare "best-MED-from-its-neighbor-AS" marks instead of MED values.
> 
> In the example above, paths 1 and 2 would have the best-MED marks,
> and path 3 would not (because of the existance of path 1).
> I do not directly compare MEDs *values* from different neighbor ASes,
> but I compare best-MED *marks* from different neighbors ASes instead.

This wouldwork too, but all routers in the AS must do the same thing.
If some other vendor does something else, different outcomes will
result and you'll get routing loops.

What you have described here is what I refer to as "insuring a fixed
order of comparison".  If we agree that we don't want to solve the
problem by comparing MEDs from different AS, then we might agree to
fix the problem by agreeing to use some fixed order of comparison.  We
can then agrue about what the order of comparison should be.

Either way something needs to go into BGP4 to address this or
different vendors will pick different solutions and multivendor
networks will still have route loops.

> I've heard Cisco has fixed their version of this problem recently, but I
> don't know what their implementation looks like.
> 
> If we (as a working group) agree that we should not compare MED values
> from different neighbor ASes, then we should at least document a MED
> election algorithm somewhere.

There is a problem that needs to be solved and the current draft has
not addressed it.  I favor comparing MEDs across AS for simplicity,
but I'd go along with a fixed order of comparison if that was
preferred and we don't have vendors claiming it is too hard to do.

> My biggest concern about MED election is the extra effort required
> (read: CPU load on non-default routers).

Not to mention getting the code right.

> -- Richard Woundy, IBM, [email-masked]
> 
> P.S. The expiration date of the latest spec needs to be fixed, too.

Regards,

Curtis

- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Subject: BGP-4 - revised I-D
Date: Fri, 09 Aug 96 13:29:07 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked]

Folks,

Today we (Tony and myself) submitted a revised version
of BGP-4 I-D. The only two essential changes are in
Section 9.1.2.1 clause (a), and Section 9.2.1.1 clause (a).
The changes reflect the agreement we reached at the
last IDR WG meeting.

Yakov.
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Thu, 8 Aug 1996 04:04:57 -0400
Subject: NDN(5): Re: Survey on Continuing Education for Network Computing Professionals
Path: corpeast.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,Wellfleet Cust. Service (The name was not found at the
remote site. Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Wed, 7 Aug 1996 19:50:26 -0400
Subject: NDN(4): Re: Survey on Continuing Education for Network Computing Professionals
Path: corpeast.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,Wellfleet Cust. Service (The name was not found at the
remote site. Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Wed, 7 Aug 1996 12:21:25 -0400
Subject: NDN(4): Re: Survey on Continuing Education for Network Computing Professionals
Path: corpeast.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,Wellfleet Cust. Service (The name was not found at the
remote site. Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Wed, 7 Aug 1996 12:17:14 -0400
Subject: NDN(3): Re: Survey on Continuing Education for Network Computing Professionals
Path: corpeast.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,Wellfleet Cust. Service (The name was not found at the
remote site. Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Tue, 6 Aug 1996 19:34:38 -0700
Subject: NDN(2): Re: Survey on Continuing Education for Network Computing Professionals
Path: corpwest.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,FirstClass (The name was not found at the remote site.
Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Wed, 7 Aug 1996 11:28:17 -0400
Subject: NDN(3): Re: Survey on Continuing Education for Network Computing Professionals
Path: corpeast.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,Wellfleet Cust. Service (The name was not found at the
remote site. Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Wed, 7 Aug 1996 11:08:09 -0400
Subject: NDN(2): Re: Survey on Continuing Education for Network Computing Professionals
Path: corpeast.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,Wellfleet Cust. Service (The name was not found at the
remote site. Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Tue, 6 Aug 1996 12:57:15 -0700
Subject: NDN: Re: Survey on Continuing Education for Network Computing Professionals
Path: corpwest.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,FirstClass (The name was not found at the remote site.
Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: [email-masked] (Gateway)
To: [email-masked]
Date: Tue, 6 Aug 1996 06:32:57 -0700
Subject: NDN: Re: Survey on Continuing Education for Network Computing Professionals
Path: corpwest.baynetworks.com!Gateway
Organization: Bay Networks
Sender: [email-masked]
Reply-To: [email-masked]

Sorry. Your message could not be delivered to:

Sajit Bhaskaran,FirstClass (The name was not found at the remote site.
Check that the name has been entered correctly.)
- - - - - - - - - - - - - - - - -

From: "Larry J. Plato" <[email-masked]>
Subject: Re: Survey on Continuing Education | please stop replying
To: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Tue, 6 Aug 1996 22:58:41 +0000 (GMT)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Folks,

I apologize for copying the list, but I was hoping to save us all some
spam.  The sender of this message set the reply-to field to [email-masked]
This means your replies are spamming [email-masked].  I would not presume
to tell people what to do, but I personally would be grateful if you
did not send your replies to the list,

I copied the Admin & Zone contact on this message,

septum:~> expn [email-masked]
Jamie Beverly <[email-masked]>

septum:~> expn [email-masked]
<[email-masked][@WPGATE.RDS.COM]> REFUSED TO VRFY

I suspect Jamie Beverly sent the original message, but RFC822
email does not support authentication of the sender,

Larry Plato
Speaking for myself

----- Forwarded message from Sean Shapira -----
> From [email-masked]  Tue Aug  6 21:24:48 1996
> X-Authentication-Warning: p-o.ans.net: majordom set sender to bgp-owner using -f
> Message-Id: <[email-masked]>
> From: [email-masked] (Sean Shapira)
> Subject: Re: Survey on Continuing Education for Network Computing Professionals
> To: [email-masked]
> Date: Tue, 6 Aug 1996 14:24:38 -0700 (PDT)
> In-Reply-To: <[email-masked]> from "Network Education Center" at Aug 5, 96 06:27:35 pm
> Mime-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Sender: [email-masked]
> Precedence: bulk
> Reply-To: [email-masked]
> 
> You wrote:
> > 
> > This survey is on behalf of an education center dedicated to the needs =
> > of network computing professionals. We are asking your input to help us =
> > create better education/training programs for you and your company. Your =
> > responses will be completely confidential.
> > 
- - - - - - - - - - - - - - - - -

From: [email-masked] (Sean Shapira)
Subject: Re: Survey on Continuing Education for Network Computing Professionals
To: [email-masked]
Date: Tue, 6 Aug 1996 14:24:38 -0700 (PDT)
Sender: [email-masked]
Reply-To: [email-masked]

You wrote:
> 
> This survey is on behalf of an education center dedicated to the needs =
> of network computing professionals. We are asking your input to help us =
> create better education/training programs for you and your company. Your =
> responses will be completely confidential.
> 
> If we receive your completed survey by Monday, August 12, 1996, we'll =
> automatically enter you in a contest for a prize of $1,000; one winner =
> will be chosen from among those who complete the survey.  Thank you in =
> advance for your help.=20
> 
> (Authentication marker -- ~3%e%INTCADX%8%1%159%5CTJVlfE%6345& -- do not =
> remove.)=20
> 
> To respond, create a reply e-mail message that contains the survey.  =
> Some e-mail systems require you to manually copy and paste the survey =
> into your reply.  Make sure the reply contains the *entire* =
> authentication marker, including what looks like garbage.
> 
> To answer a question, type an x between the brackets, like this:  [ x ]. =
>  For fill-in-the-blanks, type between the brackets like this:  [ your =
> response ].  Please make no other changes to this survey.
> 
>  1.  If for any reason you do NOT want to be contacted in the future via =
> e-mail, please indicate after the first question by placing an "x" =
> within the brackets. You will be omitted from future e-mail surveys.
> 
>    [ x ]   a)  Please omit me from future e-mail surveys.
> 
>  2.  What is your company's PRIMARY industry or business?
> 
>    Choose one:
> 
>    [  ]   a)  Aerospace
>    [  ]   b)  Communications carrier (telco, broadband, internet)
>    [  ]   c)  Financial services
>    [  ]   d)  Healthcare
>    [  ]   e)  Manufacturing: computer/software
>    [  ]   f)  Manufacturing: non-computer
>    [  ]   g)  Government/military
>    [  ]   h)  Publishing/media/advertising/public relations
>    [  ]   i)  Transportation/utilities
>    [  ]   j)  Wholesale/retail: non-computer
>    [  ]   k)  Education
>    [  ]   l)  Entertainment
>    [  ]   m)  Computer reseller/retailer/VAR
>    [  ]   n)  Systems integration/consulting
>    [  ]   o)  Other, please specify... [    ]
> 
>  3.  What is your job function?
> 
>    Choose one:
> 
>    [  ]   a)  IS/MIS/Data processing
>    [  ]   b)  LAN/network systems
>    [  ]   c)  Internet/Web
>    [  ]   d)  Intranet (in-TRA-net)
>    [  ]   e)  Data communications/telecommunications
>    [  ]   f)  PC/microcomputer/information center
>    [  ]   g)  Systems analyst/applications development
>    [  ]   h)  Systems engineer/integration
>    [  ]   i)  Other computer-related, please specify... [    ]
>    [  ]   j)  Executive/corporate office
>    [  ]   k)  Financial/accounting
>    [  ]   l)  Engineering/R&D
>    [  ]   m)  Sales/marketing
>    [  ]   n)  Other administrative, please specify... [    ]
>    [  ]   o)  Consulting (computer related)
>    [  ]   p)  Training/education
>    [  ]   q)  Other professional, please specify... [    ]
> 
>  4.  Please check the statements below that describe your involvement =
> with networks.
> 
>    Choose all that apply:
> 
>    [  ]   a)  I manage networks.
>    [  ]   b)  I design networks.
>    [  ]   c)  I install networks.
>    [  ]   d)  I troubleshoot/fix networks.
>    [  ]   e)  I train or support network users.
>    [  ]   f)  I initiate the evaluation of new network technologies.
>    [  ]   g)  I evaluate or specify brands of network products.
>    [  ]   h)  I ensure that networks meet specific business or =
> organizational objectives.
> 
>  5.  What is the scope of your involvement with networking in your =
> organization?
> 
>    Choose one:
> 
>    [  ]   a)  Entire organization or enterprise
>    [  ]   b)  Entire work location
>    [  ]   c)  Multiple departments at more than one location
>    [  ]   d)  For a single department only
>    [  ]   e)  Other
> 
>  6.  How many servers do you have installed in your organization?
> 
>    Choose one:
> 
>    [  ]   a)  Over 50
>    [  ]   b)  10 to 49
>    [  ]   c)  1 to 9
>    [  ]   d)  None
> 
>  7.  How many LANS do you have installed in your organization?
> 
>    Choose one:
> 
>    [  ]   a)  Over 25
>    [  ]   b)  5 to 24
>    [  ]   c)  1 to 4
>    [  ]   d)  None
> 
>  8.  How many microcomputers/workstations are connected to LANS in your =
> organization?
> 
>    Choose one:
> 
>    [  ]   a)  500 or more
>    [  ]   b)  25 to 499
>    [  ]   c)  1 to 24
>    [  ]   d)  None
> 
>  9.  How many employees do you supervise?
> 
>    Choose one:
> 
>    [  ]   a)  Up to 3 people
>    [  ]   b)  4 to 10 people
>    [  ]   c)  More than 10 people
>    [  ]   d)  None
> 
>  10.  Do you yourself have responsibility for networking =
> education/training provided to employees in your company?
> 
>    Choose one:
> 
>    [  ]   a)  Yes
>    [  ]   b)  No
>    [  ]   c)  Don't know
> 
>  11.  What is the annual budget for education/training for yourself and =
> those you supervise?
> 
>    Please enter the amount within the following brackets. [    ]
> 
>  12.  During the last 12 months, where did you or those you supervise =
> receive education/training for networking?
> 
>    Choose all that apply:
> 
>    [  ]   a)  In-house
>    [  ]   b)  University/college
>    [  ]   c)  Seminars
>    [  ]   d)  Internet
>    [  ]   e)  Other
>    [  ]   f)  No education/training on networking was received
> 
> 
> NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON =
> NETWORKING TECHNOLOGIES. For each of the following 10 course =
> descriptions, please indicate your level of interest.
> 
>  13.  A Network Technologies course covering circuits and fibers; =
> modulation and modems; LANs; WANs; frames; cell switching; wireless; =
> satellites; connection-oriented and connectionless service; =
> characteristics of each technology; addressing; media access; =
> comparisons.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  14.  A Network Interconnection and Internetworking course covering =
> interconnection technologies; repeaters, bridges, and routers; internet =
> addressing; address binding; datagram forwarding; techniques to =
> accomodate heterogeneity (e.g. encapsulation and fragmentation).
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  15.  A Network Protocols and Protocol Design course covering protocol =
> layering; problems protocols solve; loss, reordering, corruption, =
> congestion, duplication, and replay; techniques such as framing, =
> checksumming, sliding window, and retransmission; focus on the transport =
> layer, but cover other layers.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  16.  A Routing and Routing Protocols course covering packet forwarding; =
> route propagation; vector-distance and link-state algorithms; spanning =
> tree.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  17.  A Distributed Programming and Applications course covering =
> client-server paradigm; socket API; middleware (e.g. RPC and CORBA); =
> building a server; multithread server execution; protection and =
> authorization; example applications.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  18.  A Network and Protocol Performance Evaluation course covering =
> throughput and delay; measuring and tuning protocols; instrumentation of =
> protocol stacks; traffic analysis; self-similar behavior.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  19.  A Networking and Protocol Support for Multimedia Applications =
> course covering high-speed networks; resource allocation and performance =
> guarantees; protocols for audio and video; techniques such as =
> compression and delayed playback.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  20.  An Advanced Server Design and Implementation course covering =
> implementation of concurrent, parallel servers; large-scale designs; =
> proxy servers (e.g., SLIRP); techniques such as buffering, replication, =
> caching, and application gateways.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  21.  An Advanced Routing course covering policy-based routing; =
> multicast; mobility; inter- and intra-layer encapsulation; longest =
> prefix forwarding table lookup algorithms; virtual LANS.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  22.  An Advanced Network Applications course covering EDI; electronic =
> commerce; advanced Web techniques (e.g. Java).
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  23.  What would your level of interest be in taking a group of these =
> courses as a coordinated curriculum?
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
> 
> THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF =
> EDUCATION PROGRAMS that could be made available for networking =
> technologies, please indicate which of the following would be important =
> to you.
> 
>  24.  A course curriculum leads to an advanced college degree.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  25.  Each course generates a document of professional certification.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  26.  Course curriculum leads to an overall certification.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  27.  Course is available at your place of work.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  28.  Course is available at a local university or college campus.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  29.  Courses available at an industry event you already attend.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  30.  Courses conducted by an advanced educational institute staffed by =
> networking experts.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  31.  A core curriculum of a specified number of courses that would =
> follow a building educational sequence.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  32.  A concentrated face-to-face education program conducted over =
> consecutive days.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  33.  Ability to take class lessons, labs and tests over the Internet =
> from your desktop.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  34.  What other thoughts do you have concerning what could be done to =
> improve educational or training programs on networking technologies?
> 
>    Please write within the brackets. [    ]
> 
>  35.  How many years have you been professionally involved in computing?
> 
>    Choose one:
> 
>    [  ]   a)  Less than 2 years
>    [  ]   b)  2 to 4 years
>    [  ]   c)  5 to 10 years
>    [  ]   d)  More than 10 years
> 
>  36.  Which of the following ranges includes your age?
> 
>    Choose one:
> 
>    [  ]   a)  18 to 34
>    [  ]   b)  35 to 44
>    [  ]   c)  45 to 54
>    [  ]   d)  55 and older
> 
>  37.  Which of the following represents your highest level of education?
> 
>    Choose one:
> 
>    [  ]   a)  Attended high school
>    [  ]   b)  Graduated high school
>    [  ]   c)  Attended college
>    [  ]   d)  Bachelor's degree
>    [  ]   e)  Master's degree
>    [  ]   f)  Doctorate degree
> 
>  38.  What do you estimate your total household income was last year? =
> (Please estimate total income for everyone in your household, including =
> salaries, wages,  bonuses, interest, dividends, etc.)
> 
>    Choose one:
> 
>    [  ]   a)  Less than $15,000
>    [  ]   b)  $15,000 to $24,999
>    [  ]   c)  $25,000 to $34,999
>    [  ]   d)  $35,000 to $49,999
>    [  ]   e)  $50,000 to $74,999
>    [  ]   f)  $75,000 to $99,999
>    [  ]   g)  $100,000 to $149,999
>    [  ]   h)  $150,000 or more
>    [  ]   i)  Don't know
> 
> Thank you for participating in this survey.
> 
> 
> 

- - - - - - - - - - - - - - - - -

From: Yuriy Yankovski <[email-masked]>
Subject: Re: Survey on Continuing Education for Network Computing Professionals
To: [email-masked]
Date: Tue, 6 Aug 1996 09:10:32 -0400 (EDT)
Sender: [email-masked]
Reply-To: [email-masked]

> 
> To answer a question, type an x between the brackets, like this:  [ x ]. =
>  For fill-in-the-blanks, type between the brackets like this:  [ your =
> response ].  Please make no other changes to this survey.
> 
>  1.  If for any reason you do NOT want to be contacted in the future via =
> e-mail, please indicate after the first question by placing an "x" =
> within the brackets. You will be omitted from future e-mail surveys.
> 
>    [ x]   a)  Please omit me from future e-mail surveys.
> 
>  2.  What is your company's PRIMARY industry or business?
> 
>    Choose one:
> 
>    [  ]   a)  Aerospace
>    [  ]   b)  Communications carrier (telco, broadband, internet)
>    [  ]   c)  Financial services
>    [  ]   d)  Healthcare
>    [  ]   e)  Manufacturing: computer/software
>    [  ]   f)  Manufacturing: non-computer
>    [  ]   g)  Government/military
>    [  ]   h)  Publishing/media/advertising/public relations
>    [  ]   i)  Transportation/utilities
>    [  ]   j)  Wholesale/retail: non-computer
>    [ x]   k)  Education
>    [  ]   l)  Entertainment
>    [  ]   m)  Computer reseller/retailer/VAR
>    [  ]   n)  Systems integration/consulting
>    [  ]   o)  Other, please specify... [    ]
> 
>  3.  What is your job function?
> 
>    Choose one:
> 
>    [  ]   a)  IS/MIS/Data processing
>    [  ]   b)  LAN/network systems
>    [  ]   c)  Internet/Web
>    [  ]   d)  Intranet (in-TRA-net)
>    [  ]   e)  Data communications/telecommunications
>    [  ]   f)  PC/microcomputer/information center
>    [  ]   g)  Systems analyst/applications development
>    [ x]   h)  Systems engineer/integration
>    [  ]   i)  Other computer-related, please specify... [    ]
>    [  ]   j)  Executive/corporate office
>    [  ]   k)  Financial/accounting
>    [  ]   l)  Engineering/R&D
>    [  ]   m)  Sales/marketing
>    [  ]   n)  Other administrative, please specify... [    ]
>    [  ]   o)  Consulting (computer related)
>    [  ]   p)  Training/education
>    [  ]   q)  Other professional, please specify... [    ]
> 
>  4.  Please check the statements below that describe your involvement =
> with networks.
> 
>    Choose all that apply:
> 
>    [ x]   a)  I manage networks.
>    [  ]   b)  I design networks.
>    [ x]   c)  I install networks.
>    [ x]   d)  I troubleshoot/fix networks.
>    [ x]   e)  I train or support network users.
>    [ x]   f)  I initiate the evaluation of new network technologies.
>    [ x]   g)  I evaluate or specify brands of network products.
>    [  ]   h)  I ensure that networks meet specific business or =
> organizational objectives.
> 
>  5.  What is the scope of your involvement with networking in your =
> organization?
> 
>    Choose one:
> 
>    [ x]   a)  Entire organization or enterprise
>    [  ]   b)  Entire work location
>    [  ]   c)  Multiple departments at more than one location
>    [  ]   d)  For a single department only
>    [  ]   e)  Other
> 
>  6.  How many servers do you have installed in your organization?
> 
>    Choose one:
> 
>    [  ]   a)  Over 50
>    [ x]   b)  10 to 49
>    [  ]   c)  1 to 9
>    [  ]   d)  None
> 
>  7.  How many LANS do you have installed in your organization?
> 
>    Choose one:
> 
>    [  ]   a)  Over 25
>    [  ]   b)  5 to 24
>    [ x]   c)  1 to 4
>    [  ]   d)  None
> 
>  8.  How many microcomputers/workstations are connected to LANS in your =
> organization?
> 
>    Choose one:
> 
>    [  ]   a)  500 or more
>    [ x]   b)  25 to 499
>    [  ]   c)  1 to 24
>    [  ]   d)  None
> 
>  9.  How many employees do you supervise?
> 
>    Choose one:
> 
>    [  ]   a)  Up to 3 people
>    [ x]   b)  4 to 10 people
>    [  ]   c)  More than 10 people
>    [  ]   d)  None
> 
>  10.  Do you yourself have responsibility for networking =
> education/training provided to employees in your company?
> 
>    Choose one:
> 
>    [ x]   a)  Yes
>    [  ]   b)  No
>    [  ]   c)  Don't know
> 
>  11.  What is the annual budget for education/training for yourself and =
> those you supervise?
> 
>    Please enter the amount within the following brackets. [    ]
> 
>  12.  During the last 12 months, where did you or those you supervise =
> receive education/training for networking?
> 
>    Choose all that apply:
> 
>    [ x]   a)  In-house
>    [  ]   b)  University/college
>    [ x]   c)  Seminars
>    [ x]   d)  Internet
>    [  ]   e)  Other
>    [  ]   f)  No education/training on networking was received
> 
> 
> NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON =
> NETWORKING TECHNOLOGIES. For each of the following 10 course =
> descriptions, please indicate your level of interest.
> 
>  13.  A Network Technologies course covering circuits and fibers; =
> modulation and modems; LANs; WANs; frames; cell switching; wireless; =
> satellites; connection-oriented and connectionless service; =
> characteristics of each technology; addressing; media access; =
> comparisons.
> 
>    Choose one:
> 
>    [ x]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  14.  A Network Interconnection and Internetworking course covering =
> interconnection technologies; repeaters, bridges, and routers; internet =
> addressing; address binding; datagram forwarding; techniques to =
> accomodate heterogeneity (e.g. encapsulation and fragmentation).
> 
>    Choose one:
> 
>    [ x]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  15.  A Network Protocols and Protocol Design course covering protocol =
> layering; problems protocols solve; loss, reordering, corruption, =
> congestion, duplication, and replay; techniques such as framing, =
> checksumming, sliding window, and retransmission; focus on the transport =
> layer, but cover other layers.
> 
>    Choose one:
> 
>    [ x]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  16.  A Routing and Routing Protocols course covering packet forwarding; =
> route propagation; vector-distance and link-state algorithms; spanning =
> tree.
> 
>    Choose one:
> 
>    [ x]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  17.  A Distributed Programming and Applications course covering =
> client-server paradigm; socket API; middleware (e.g. RPC and CORBA); =
> building a server; multithread server execution; protection and =
> authorization; example applications.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [ x]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  18.  A Network and Protocol Performance Evaluation course covering =
> throughput and delay; measuring and tuning protocols; instrumentation of =
> protocol stacks; traffic analysis; self-similar behavior.
> 
>    Choose one:
> 
>    [ x]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  19.  A Networking and Protocol Support for Multimedia Applications =
> course covering high-speed networks; resource allocation and performance =
> guarantees; protocols for audio and video; techniques such as =
> compression and delayed playback.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [ x]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  20.  An Advanced Server Design and Implementation course covering =
> implementation of concurrent, parallel servers; large-scale designs; =
> proxy servers (e.g., SLIRP); techniques such as buffering, replication, =
> caching, and application gateways.
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [ x]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  21.  An Advanced Routing course covering policy-based routing; =
> multicast; mobility; inter- and intra-layer encapsulation; longest =
> prefix forwarding table lookup algorithms; virtual LANS.
> 
>    Choose one:
> 
>    [ x]   a)  Very interesting
>    [  ]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  22.  An Advanced Network Applications course covering EDI; electronic =
> commerce; advanced Web techniques (e.g. Java).
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [ x]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
>  23.  What would your level of interest be in taking a group of these =
> courses as a coordinated curriculum?
> 
>    Choose one:
> 
>    [  ]   a)  Very interesting
>    [ x]   b)  Moderately interesting
>    [  ]   c)  Somewhat interesting
>    [  ]   d)  Not at all interesting
> 
> 
> THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF =
> EDUCATION PROGRAMS that could be made available for networking =
> technologies, please indicate which of the following would be important =
> to you.
> 
>  24.  A course curriculum leads to an advanced college degree.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  25.  Each course generates a document of professional certification.
> 
>    Choose one:
> 
>    [ x]   a)  Very important
>    [  ]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  26.  Course curriculum leads to an overall certification.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  27.  Course is available at your place of work.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  28.  Course is available at a local university or college campus.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  29.  Courses available at an industry event you already attend.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  30.  Courses conducted by an advanced educational institute staffed by =
> networking experts.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  31.  A core curriculum of a specified number of courses that would =
> follow a building educational sequence.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  32.  A concentrated face-to-face education program conducted over =
> consecutive days.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  33.  Ability to take class lessons, labs and tests over the Internet =
> from your desktop.
> 
>    Choose one:
> 
>    [  ]   a)  Very important
>    [ x]   b)  Somewhat important
>    [  ]   c)  Not very important
>    [  ]   d)  Not at all important
>    [  ]   e)  No opinion
> 
>  34.  What other thoughts do you have concerning what could be done to =
> improve educational or training programs on networking technologies?
> 
>    Please write within the brackets. [    ]
> 
>  35.  How many years have you been professionally involved in computing?
> 
>    Choose one:
> 
>    [  ]   a)  Less than 2 years
>    [ x]   b)  2 to 4 years
>    [  ]   c)  5 to 10 years
>    [  ]   d)  More than 10 years
> 
>  36.  Which of the following ranges includes your age?
> 
>    Choose one:
> 
>    [ x]   a)  18 to 34
>    [  ]   b)  35 to 44
>    [  ]   c)  45 to 54
>    [  ]   d)  55 and older
> 
>  37.  Which of the following represents your highest level of education?
> 
>    Choose one:
> 
>    [  ]   a)  Attended high school
>    [ x]   b)  Graduated high school
>    [  ]   c)  Attended college
>    [  ]   d)  Bachelor's degree
>    [  ]   e)  Master's degree
>    [  ]   f)  Doctorate degree
> 
>  38.  What do you estimate your total household income was last year? =
> (Please estimate total income for everyone in your household, including =
> salaries, wages,  bonuses, interest, dividends, etc.)
> 
>    Choose one:
> 
>    [  ]   a)  Less than $15,000
>    [  ]   b)  $15,000 to $24,999
>    [  ]   c)  $25,000 to $34,999
>    [  ]   d)  $35,000 to $49,999
>    [  ]   e)  $50,000 to $74,999
>    [  ]   f)  $75,000 to $99,999
>    [  ]   g)  $100,000 to $149,999
>    [  ]   h)  $150,000 or more
>    [ x]   i)  Don't know
> 
> Thank you for participating in this survey.
> 

- - - - - - - - - - - - - - - - -

From: Maman Sutarman <[email-masked]>
Subject: Re: Survey on Continuing Education for Network Computing Professionals
To: [email-masked]
Date: Tue, 6 Aug 1996 11:12:11 +0700 (GMT)
Sender: [email-masked]
Reply-To: [email-masked]

To answer a question, type an x between the brackets, like this:  [ x ]. =
 For fill-in-the-blanks, type between the brackets like this:  [ your =
response ].  Please make no other changes to this survey.

 1.  If for any reason you do NOT want to be contacted in the future via =
e-mail, please indicate after the first question by placing an "x" =
within the brackets. You will be omitted from future e-mail surveys.

   [ x]   a)  Please omit me from future e-mail surveys.

 2.  What is your company's PRIMARY industry or business?

   Choose one:

   [  ]   a)  Aerospace
   [  ]   b)  Communications carrier (telco, broadband, internet)
   [  ]   c)  Financial services
   [  ]   d)  Healthcare
   [  ]   e)  Manufacturing: computer/software
   [  ]   f)  Manufacturing: non-computer
   [  ]   g)  Government/military
   [  ]   h)  Publishing/media/advertising/public relations
   [  ]   i)  Transportation/utilities
   [  ]   j)  Wholesale/retail: non-computer
   [ x]   k)  Education
   [  ]   l)  Entertainment
   [  ]   m)  Computer reseller/retailer/VAR
   [  ]   n)  Systems integration/consulting
   [  ]   o)  Other, please specify... [    ]

 3.  What is your job function?

   Choose one:

   [  ]   a)  IS/MIS/Data processing
   [  ]   b)  LAN/network systems
   [  ]   c)  Internet/Web
   [  ]   d)  Intranet (in-TRA-net)
   [  ]   e)  Data communications/telecommunications
   [  ]   f)  PC/microcomputer/information center
   [  ]   g)  Systems analyst/applications development
   [ x]   h)  Systems engineer/integration
   [  ]   i)  Other computer-related, please specify... [    ]
   [  ]   j)  Executive/corporate office
   [  ]   k)  Financial/accounting
   [  ]   l)  Engineering/R&D
   [  ]   m)  Sales/marketing
   [  ]   n)  Other administrative, please specify... [    ]
   [  ]   o)  Consulting (computer related)
   [  ]   p)  Training/education
   [  ]   q)  Other professional, please specify... [    ]

 4.  Please check the statements below that describe your involvement =
with networks.

   Choose all that apply:

   [ x]   a)  I manage networks.
   [  ]   b)  I design networks.
   [ x]   c)  I install networks.
   [ x]   d)  I troubleshoot/fix networks.
   [ x]   e)  I train or support network users.
   [ x]   f)  I initiate the evaluation of new network technologies.
   [ x]   g)  I evaluate or specify brands of network products.
   [  ]   h)  I ensure that networks meet specific business or =
organizational objectives.

 5.  What is the scope of your involvement with networking in your =
organization?

   Choose one:

   [ x]   a)  Entire organization or enterprise
   [  ]   b)  Entire work location
   [  ]   c)  Multiple departments at more than one location
   [  ]   d)  For a single department only
   [  ]   e)  Other

 6.  How many servers do you have installed in your organization?

   Choose one:

   [  ]   a)  Over 50
   [ x]   b)  10 to 49
   [  ]   c)  1 to 9
   [  ]   d)  None

 7.  How many LANS do you have installed in your organization?

   Choose one:

   [  ]   a)  Over 25
   [  ]   b)  5 to 24
   [ x]   c)  1 to 4
   [  ]   d)  None

 8.  How many microcomputers/workstations are connected to LANS in your =
organization?

   Choose one:

   [  ]   a)  500 or more
   [ x]   b)  25 to 499
   [  ]   c)  1 to 24
   [  ]   d)  None

 9.  How many employees do you supervise?

   Choose one:

   [  ]   a)  Up to 3 people
   [ x]   b)  4 to 10 people
   [  ]   c)  More than 10 people
   [  ]   d)  None

 10.  Do you yourself have responsibility for networking =
education/training provided to employees in your company?

   Choose one:

   [ x]   a)  Yes
   [  ]   b)  No
   [  ]   c)  Don't know

 11.  What is the annual budget for education/training for yourself and =
those you supervise?

   Please enter the amount within the following brackets. [    ]

 12.  During the last 12 months, where did you or those you supervise =
receive education/training for networking?

   Choose all that apply:

   [ x]   a)  In-house
   [  ]   b)  University/college
   [ x]   c)  Seminars
   [ x]   d)  Internet
   [  ]   e)  Other
   [  ]   f)  No education/training on networking was received

NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON =
NETWORKING TECHNOLOGIES. For each of the following 10 course =
descriptions, please indicate your level of interest.

 13.  A Network Technologies course covering circuits and fibers; =
modulation and modems; LANs; WANs; frames; cell switching; wireless; =
satellites; connection-oriented and connectionless service; =
characteristics of each technology; addressing; media access; =
comparisons.

   Choose one:

   [ x]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 14.  A Network Interconnection and Internetworking course covering =
interconnection technologies; repeaters, bridges, and routers; internet =
addressing; address binding; datagram forwarding; techniques to =
accomodate heterogeneity (e.g. encapsulation and fragmentation).

   Choose one:

   [ x]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 15.  A Network Protocols and Protocol Design course covering protocol =
layering; problems protocols solve; loss, reordering, corruption, =
congestion, duplication, and replay; techniques such as framing, =
checksumming, sliding window, and retransmission; focus on the transport =
layer, but cover other layers.

   Choose one:

   [ x]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 16.  A Routing and Routing Protocols course covering packet forwarding; =
route propagation; vector-distance and link-state algorithms; spanning =
tree.

   Choose one:

   [ x]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 17.  A Distributed Programming and Applications course covering =
client-server paradigm; socket API; middleware (e.g. RPC and CORBA); =
building a server; multithread server execution; protection and =
authorization; example applications.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [ x]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 18.  A Network and Protocol Performance Evaluation course covering =
throughput and delay; measuring and tuning protocols; instrumentation of =
protocol stacks; traffic analysis; self-similar behavior.

   Choose one:

   [ x]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 19.  A Networking and Protocol Support for Multimedia Applications =
course covering high-speed networks; resource allocation and performance =
guarantees; protocols for audio and video; techniques such as =
compression and delayed playback.

   Choose one:

   [  ]   a)  Very interesting
   [ x]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 20.  An Advanced Server Design and Implementation course covering =
implementation of concurrent, parallel servers; large-scale designs; =
proxy servers (e.g., SLIRP); techniques such as buffering, replication, =
caching, and application gateways.

   Choose one:

   [  ]   a)  Very interesting
   [ x]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 21.  An Advanced Routing course covering policy-based routing; =
multicast; mobility; inter- and intra-layer encapsulation; longest =
prefix forwarding table lookup algorithms; virtual LANS.

   Choose one:

   [ x]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 22.  An Advanced Network Applications course covering EDI; electronic =
commerce; advanced Web techniques (e.g. Java).

   Choose one:

   [  ]   a)  Very interesting
   [ x]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 23.  What would your level of interest be in taking a group of these =
courses as a coordinated curriculum?

   Choose one:

   [  ]   a)  Very interesting
   [ x]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF =
EDUCATION PROGRAMS that could be made available for networking =
technologies, please indicate which of the following would be important =
to you.

 24.  A course curriculum leads to an advanced college degree.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 25.  Each course generates a document of professional certification.

   Choose one:

   [ x]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 26.  Course curriculum leads to an overall certification.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 27.  Course is available at your place of work.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 28.  Course is available at a local university or college campus.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 29.  Courses available at an industry event you already attend.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 30.  Courses conducted by an advanced educational institute staffed by =
networking experts.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 31.  A core curriculum of a specified number of courses that would =
follow a building educational sequence.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 32.  A concentrated face-to-face education program conducted over =
consecutive days.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 33.  Ability to take class lessons, labs and tests over the Internet =
from your desktop.

   Choose one:

   [  ]   a)  Very important
   [ x]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 34.  What other thoughts do you have concerning what could be done to =
improve educational or training programs on networking technologies?

   Please write within the brackets. [    ]

 35.  How many years have you been professionally involved in computing?

   Choose one:

   [  ]   a)  Less than 2 years
   [ x]   b)  2 to 4 years
   [  ]   c)  5 to 10 years
   [  ]   d)  More than 10 years

 36.  Which of the following ranges includes your age?

   Choose one:

   [ x]   a)  18 to 34
   [  ]   b)  35 to 44
   [  ]   c)  45 to 54
   [  ]   d)  55 and older

 37.  Which of the following represents your highest level of education?

   Choose one:

   [  ]   a)  Attended high school
   [ x]   b)  Graduated high school
   [  ]   c)  Attended college
   [  ]   d)  Bachelor's degree
   [  ]   e)  Master's degree
   [  ]   f)  Doctorate degree

 38.  What do you estimate your total household income was last year? =
(Please estimate total income for everyone in your household, including =
salaries, wages,  bonuses, interest, dividends, etc.)

   Choose one:

   [  ]   a)  Less than $15,000
   [  ]   b)  $15,000 to $24,999
   [  ]   c)  $25,000 to $34,999
   [  ]   d)  $35,000 to $49,999
   [  ]   e)  $50,000 to $74,999
   [  ]   f)  $75,000 to $99,999
   [  ]   g)  $100,000 to $149,999
   [  ]   h)  $150,000 or more
   [ x]   i)  Don't know

Thank you for participating in this survey.
- - - - - - - - - - - - - - - - -

From: [email-masked] (Network Education Center)
To: "[email-masked]'" <[email-masked]>
Subject: Survey on Continuing Education for Network Computing Professionals
Date: Mon, 5 Aug 1996 18:27:35 -0700
Sender: [email-masked]
Reply-To: [email-masked]

This survey is on behalf of an education center dedicated to the needs =
of network computing professionals. We are asking your input to help us =
create better education/training programs for you and your company. Your =
responses will be completely confidential.

If we receive your completed survey by Monday, August 12, 1996, we'll =
automatically enter you in a contest for a prize of $1,000; one winner =
will be chosen from among those who complete the survey.  Thank you in =
advance for your help.=20

(Authentication marker -- ~3%e%INTCADX%8%1%159%5CTJVlfE%6345& -- do not =
remove.)=20

To respond, create a reply e-mail message that contains the survey.  =
Some e-mail systems require you to manually copy and paste the survey =
into your reply.  Make sure the reply contains the *entire* =
authentication marker, including what looks like garbage.

To answer a question, type an x between the brackets, like this:  [ x ]. =
 For fill-in-the-blanks, type between the brackets like this:  [ your =
response ].  Please make no other changes to this survey.

 1.  If for any reason you do NOT want to be contacted in the future via =
e-mail, please indicate after the first question by placing an "x" =
within the brackets. You will be omitted from future e-mail surveys.

   [  ]   a)  Please omit me from future e-mail surveys.

 2.  What is your company's PRIMARY industry or business?

   Choose one:

   [  ]   a)  Aerospace
   [  ]   b)  Communications carrier (telco, broadband, internet)
   [  ]   c)  Financial services
   [  ]   d)  Healthcare
   [  ]   e)  Manufacturing: computer/software
   [  ]   f)  Manufacturing: non-computer
   [  ]   g)  Government/military
   [  ]   h)  Publishing/media/advertising/public relations
   [  ]   i)  Transportation/utilities
   [  ]   j)  Wholesale/retail: non-computer
   [  ]   k)  Education
   [  ]   l)  Entertainment
   [  ]   m)  Computer reseller/retailer/VAR
   [  ]   n)  Systems integration/consulting
   [  ]   o)  Other, please specify... [    ]

 3.  What is your job function?

   Choose one:

   [  ]   a)  IS/MIS/Data processing
   [  ]   b)  LAN/network systems
   [  ]   c)  Internet/Web
   [  ]   d)  Intranet (in-TRA-net)
   [  ]   e)  Data communications/telecommunications
   [  ]   f)  PC/microcomputer/information center
   [  ]   g)  Systems analyst/applications development
   [  ]   h)  Systems engineer/integration
   [  ]   i)  Other computer-related, please specify... [    ]
   [  ]   j)  Executive/corporate office
   [  ]   k)  Financial/accounting
   [  ]   l)  Engineering/R&D
   [  ]   m)  Sales/marketing
   [  ]   n)  Other administrative, please specify... [    ]
   [  ]   o)  Consulting (computer related)
   [  ]   p)  Training/education
   [  ]   q)  Other professional, please specify... [    ]

 4.  Please check the statements below that describe your involvement =
with networks.

   Choose all that apply:

   [  ]   a)  I manage networks.
   [  ]   b)  I design networks.
   [  ]   c)  I install networks.
   [  ]   d)  I troubleshoot/fix networks.
   [  ]   e)  I train or support network users.
   [  ]   f)  I initiate the evaluation of new network technologies.
   [  ]   g)  I evaluate or specify brands of network products.
   [  ]   h)  I ensure that networks meet specific business or =
organizational objectives.

 5.  What is the scope of your involvement with networking in your =
organization?

   Choose one:

   [  ]   a)  Entire organization or enterprise
   [  ]   b)  Entire work location
   [  ]   c)  Multiple departments at more than one location
   [  ]   d)  For a single department only
   [  ]   e)  Other

 6.  How many servers do you have installed in your organization?

   Choose one:

   [  ]   a)  Over 50
   [  ]   b)  10 to 49
   [  ]   c)  1 to 9
   [  ]   d)  None

 7.  How many LANS do you have installed in your organization?

   Choose one:

   [  ]   a)  Over 25
   [  ]   b)  5 to 24
   [  ]   c)  1 to 4
   [  ]   d)  None

 8.  How many microcomputers/workstations are connected to LANS in your =
organization?

   Choose one:

   [  ]   a)  500 or more
   [  ]   b)  25 to 499
   [  ]   c)  1 to 24
   [  ]   d)  None

 9.  How many employees do you supervise?

   Choose one:

   [  ]   a)  Up to 3 people
   [  ]   b)  4 to 10 people
   [  ]   c)  More than 10 people
   [  ]   d)  None

 10.  Do you yourself have responsibility for networking =
education/training provided to employees in your company?

   Choose one:

   [  ]   a)  Yes
   [  ]   b)  No
   [  ]   c)  Don't know

 11.  What is the annual budget for education/training for yourself and =
those you supervise?

   Please enter the amount within the following brackets. [    ]

 12.  During the last 12 months, where did you or those you supervise =
receive education/training for networking?

   Choose all that apply:

   [  ]   a)  In-house
   [  ]   b)  University/college
   [  ]   c)  Seminars
   [  ]   d)  Internet
   [  ]   e)  Other
   [  ]   f)  No education/training on networking was received

NOW WE WANT YOUR OPINIONS ABOUT A POSSIBLE EDUCATION CURRICULUM ON =
NETWORKING TECHNOLOGIES. For each of the following 10 course =
descriptions, please indicate your level of interest.

 13.  A Network Technologies course covering circuits and fibers; =
modulation and modems; LANs; WANs; frames; cell switching; wireless; =
satellites; connection-oriented and connectionless service; =
characteristics of each technology; addressing; media access; =
comparisons.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 14.  A Network Interconnection and Internetworking course covering =
interconnection technologies; repeaters, bridges, and routers; internet =
addressing; address binding; datagram forwarding; techniques to =
accomodate heterogeneity (e.g. encapsulation and fragmentation).

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 15.  A Network Protocols and Protocol Design course covering protocol =
layering; problems protocols solve; loss, reordering, corruption, =
congestion, duplication, and replay; techniques such as framing, =
checksumming, sliding window, and retransmission; focus on the transport =
layer, but cover other layers.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 16.  A Routing and Routing Protocols course covering packet forwarding; =
route propagation; vector-distance and link-state algorithms; spanning =
tree.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 17.  A Distributed Programming and Applications course covering =
client-server paradigm; socket API; middleware (e.g. RPC and CORBA); =
building a server; multithread server execution; protection and =
authorization; example applications.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 18.  A Network and Protocol Performance Evaluation course covering =
throughput and delay; measuring and tuning protocols; instrumentation of =
protocol stacks; traffic analysis; self-similar behavior.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 19.  A Networking and Protocol Support for Multimedia Applications =
course covering high-speed networks; resource allocation and performance =
guarantees; protocols for audio and video; techniques such as =
compression and delayed playback.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 20.  An Advanced Server Design and Implementation course covering =
implementation of concurrent, parallel servers; large-scale designs; =
proxy servers (e.g., SLIRP); techniques such as buffering, replication, =
caching, and application gateways.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 21.  An Advanced Routing course covering policy-based routing; =
multicast; mobility; inter- and intra-layer encapsulation; longest =
prefix forwarding table lookup algorithms; virtual LANS.

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 22.  An Advanced Network Applications course covering EDI; electronic =
commerce; advanced Web techniques (e.g. Java).

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

 23.  What would your level of interest be in taking a group of these =
courses as a coordinated curriculum?

   Choose one:

   [  ]   a)  Very interesting
   [  ]   b)  Moderately interesting
   [  ]   c)  Somewhat interesting
   [  ]   d)  Not at all interesting

THINKING ABOUT THE CHARACTERISTICS AND BENEFITS OF DIFFERENT TYPES OF =
EDUCATION PROGRAMS that could be made available for networking =
technologies, please indicate which of the following would be important =
to you.

 24.  A course curriculum leads to an advanced college degree.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 25.  Each course generates a document of professional certification.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 26.  Course curriculum leads to an overall certification.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 27.  Course is available at your place of work.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 28.  Course is available at a local university or college campus.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 29.  Courses available at an industry event you already attend.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 30.  Courses conducted by an advanced educational institute staffed by =
networking experts.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 31.  A core curriculum of a specified number of courses that would =
follow a building educational sequence.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 32.  A concentrated face-to-face education program conducted over =
consecutive days.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 33.  Ability to take class lessons, labs and tests over the Internet =
from your desktop.

   Choose one:

   [  ]   a)  Very important
   [  ]   b)  Somewhat important
   [  ]   c)  Not very important
   [  ]   d)  Not at all important
   [  ]   e)  No opinion

 34.  What other thoughts do you have concerning what could be done to =
improve educational or training programs on networking technologies?

   Please write within the brackets. [    ]

 35.  How many years have you been professionally involved in computing?

   Choose one:

   [  ]   a)  Less than 2 years
   [  ]   b)  2 to 4 years
   [  ]   c)  5 to 10 years
   [  ]   d)  More than 10 years

 36.  Which of the following ranges includes your age?

   Choose one:

   [  ]   a)  18 to 34
   [  ]   b)  35 to 44
   [  ]   c)  45 to 54
   [  ]   d)  55 and older

 37.  Which of the following represents your highest level of education?

   Choose one:

   [  ]   a)  Attended high school
   [  ]   b)  Graduated high school
   [  ]   c)  Attended college
   [  ]   d)  Bachelor's degree
   [  ]   e)  Master's degree
   [  ]   f)  Doctorate degree

 38.  What do you estimate your total household income was last year? =
(Please estimate total income for everyone in your household, including =
salaries, wages,  bonuses, interest, dividends, etc.)

   Choose one:

   [  ]   a)  Less than $15,000
   [  ]   b)  $15,000 to $24,999
   [  ]   c)  $25,000 to $34,999
   [  ]   d)  $35,000 to $49,999
   [  ]   e)  $50,000 to $74,999
   [  ]   f)  $75,000 to $99,999
   [  ]   g)  $100,000 to $149,999
   [  ]   h)  $150,000 or more
   [  ]   i)  Don't know

Thank you for participating in this survey.

- - - - - - - - - - - - - - - - -