Subject: RE: diffs to draft-ietf-idr-bgp4-03.txt
From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 24 Sep 1996 13:45:12 -0600

I did a nice BB with ospf , and bgp only at the corners. 30k routes with
4500s and 7000s (is some time since then).

This was the fastest converging engine I ever was allowed to build.

Why others don't do it? Yes, you need both halves running.

Please keep it in. I would even recommend that instead of IBGP over a
whole ISP.

Mike

>----------
>From: 	Yakov Rekhter[SMTP:[email-masked]]
>Sent: 	Tuesday, September 17, 1996 8:33 AM
>To: 	[email-masked]
>Cc: 	[email-masked]
>Subject: 	Re: diffs to draft-ietf-idr-bgp4-03.txt 
>
>Curtis,
>
>>      If a particular AS has multiple BGP speakers and is providing transit
>>      service for other ASs, then care must be taken to ensure a consistent
>>      view of routing within the AS.  A consistent view of the interior
>>      routes of the AS is provided by the interior routing protocol.  A
>>      consistent view of the routes exterior to the AS can be provided by
>> !    having all BGP speakers within the AS maintain direct IBGP connections
>> !    with each other.  Alternately the interior routing protocol can
>> !    pass BGP information among routers within an AS, taking care not to
>> !    lose BGP attributes that will be needed by EBGP speakers if transit
>> !    connectivity is being providided.  For the purpose of discussion,
>> !    it is assumed that BGP information is passed within an AS using
>> !    IBGP.  Care must be taken to ensure that the interior routers have
>> !    all been updated with transit information before the EBGP speakers
>> !    announce to other ASs that transit service is being provided.
>
>Despite the fact that the notion of using IGP to carry BGP information
>within an AS isn't new, and had been discussed within the IDR WG on
>more than one occassion, we've yet to see any progress in this area.
>So, why should the BGP spec describe something that doesn't exist ?
>
>Yakov.
>
- - - - - - - - - - - - - - - - -

To: Eric Hollander <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: joining the mailing list? 
Date: Thu, 19 Sep 1996 11:01:33 -0400
From: Susan Hares <[email-masked]>
Sender: [email-masked]

[email-masked] is location.

Sue
- - - - - - - - - - - - - - - - -

To: "David J. LeRoy" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt 
Date: Tue, 17 Sep 1996 23:11:51 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "David J. LeRoy" writes:
> 
> Also, while we are trying to clear up the wording about IBGP and EBGP, I
> believe it should be used consistantly and so "external peers" should
> replace
> all occurences of "BGP speakers in neighboring autonomous systems"

YES!!  :-)

> ***************
> *** 1385,1397 ****
>      as a NEXT_HOP, for a route that the speaker is originating.  A BGP
>      speaker must never install a route with itself as the next hop.
>   
> !    When a BGP speaker advertises the route to a BGP speaker located in
> !    its own autonomous system, the advertising speaker shall not modify
> !    the NEXT_HOP attribute associated with the route.  When a BGP speaker
> !    receives the route via an internal link, it may forward packets to
> !    the NEXT_HOP address if the address contained in the attribute is on
> !    a common subnet with the local and remote BGP speakers.
> ! 
>   
>   5.1.4   MULTI_EXIT_DISC
>   
> --- 1385,1399 ----
>      as a NEXT_HOP, for a route that the speaker is originating.  A BGP
>      speaker must never install a route with itself as the next hop.
>   
> !    When a BGP speaker advertises a route to internal peers received
> !    via an external link, the advertising internal speaker shall not
> !    modify the NEXT_HOP attribute associated with the route. When a BGP
> !    speaker receives the route via an internal link, it may directly
> !    forward packets to the NEXT_HOP address if the peer shares a common
> !    subnet with the address contained in the NEXT_HOP attribute. If the
> !    address is not on a common subnet, the receiving internal peer must
> !    consult its IGP routing table for a viable nexthop towards the
> !    address contained in the NEXT_HOP attribute. 
>   
>   5.1.4   MULTI_EXIT_DISC

This is an improvement.

The first paragraph is still a jumble (I see Dave wasn't brave enough
to try to unscramble that one :).

First of all, the paragraph described third party next hop, but
doesn't describe first party next hop.  The text below assumes the
introductory text defining IBGP, EBGP, IBGP peer, and EBGP peer is
accepted.  See if this one is an improvement.

Curtis

***************
*** 1292,1311 ****
  
     The NEXT_HOP path attribute defines the IP address of the border
     router that should be used as the next hop to the destinations listed
!    in the UPDATE message.  If a border router belongs to the same AS as
!    its peer, then the peer is an internal border router. Otherwise, it
!    is an external border router.  A BGP speaker can advertise any
!    internal border router as the next hop provided that the interface
!    associated with the IP address of this border router (as specified in
!    the NEXT_HOP path attribute) shares a common subnet with both the
!    local and remote BGP speakers. A BGP speaker can advertise any
!    external border router as the next hop, provided that the IP address
!    of this border router was learned from one of the BGP speaker's
!    peers, and the interface associated with the IP address of this
!    border router (as specified in the NEXT_HOP path attribute) shares a
!    common subnet with the local and remote BGP speakers.  A BGP speaker
!    needs to be able to support disabling advertisement of external
!    border routers.
  
     A BGP speaker must never advertise an address of a peer to that peer
  
--- 1354,1378 ----
  
     The NEXT_HOP path attribute defines the IP address of the border
     router that should be used as the next hop to the destinations listed
!    in the UPDATE message.  When advertising a NEXT_HOP attribute to an
!    EBGP peer, a router may use one of its own interface addresses in the
!    NEXT_HOP attribute provided the EBGP peer to which the route is being
!    advertised shares a common subnet with the NEXT_HOP address.  This is
!    known as a "first party" NEXT_HOP attribute.  An EBGP speaker can
!    advertise an interface of any IBGP peer router in the NEXT_HOP
!    attribute provided the EBGP peer to which the route is being
!    advertised shares a common subnet with the NEXT_HOP address.  This is
!    known as a "third party" NEXT_HOP attribute.  An EBGP speaker can
!    advertise any EBGP peer router in the NEXT_HOP attribute provided that
!    the IP address of this border router was learned from an EBGP peer and
!    the EBGP peer to which the route is being advertised shares a common
!    subnet with the NEXT_HOP address.  This is a second form of "third
!    party" NEXT_HOP attribute.
! 
!    Normally the NEXT_HOP attribute is choosen such that the shortest
!    available path will be taken.  A BGP speaker must be able to
!    support disabling advertisement of third party NEXT_HOP attributes
!    to handle imperfectly bridged media.
  
     A BGP speaker must never advertise an address of a peer to that peer
  
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt 
Date: Tue, 17 Sep 1996 22:10:18 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> Curtis,
> 
> >      If a particular AS has multiple BGP speakers and is providing transit
> >      service for other ASs, then care must be taken to ensure a consistent
> >      view of routing within the AS.  A consistent view of the interior
> >      routes of the AS is provided by the interior routing protocol.  A
> >      consistent view of the routes exterior to the AS can be provided by
> > !    having all BGP speakers within the AS maintain direct IBGP connections
> > !    with each other.  Alternately the interior routing protocol can
> > !    pass BGP information among routers within an AS, taking care not to
> > !    lose BGP attributes that will be needed by EBGP speakers if transit
> > !    connectivity is being providided.  For the purpose of discussion,
> > !    it is assumed that BGP information is passed within an AS using
> > !    IBGP.  Care must be taken to ensure that the interior routers have
> > !    all been updated with transit information before the EBGP speakers
> > !    announce to other ASs that transit service is being provided.
> 
> Despite the fact that the notion of using IGP to carry BGP information
> within an AS isn't new, and had been discussed within the IDR WG on
> more than one occassion, we've yet to see any progress in this area.
> So, why should the BGP spec describe something that doesn't exist ?
> 
> Yakov.

Because "Alternately the interior routing protocol can [in principle]
pass BGP information among routers within an AS, taking care not to
lose BGP attributes".

BGP info *is* carried by IGPs and it *does* lose information.  That is
why we have to mention how it would be done right in order to point
out where it is being done wrong.

IMO Doing BGP injection with full attributes into a flooding IGP is a
better design that IBGP, whether you use reflectors, or BGP
communities, or whatever.  For some OSPF implementations it is a very
bad idea but that is a weakness of a specific implementation.
Regardless of whether it is better it is a valid design and this
statement is needed to distinguish between that vaild design and
injection into an IGP and losing the AS path.

Curtis

ps-  Geez - you want to leave deaggregation in and drop this?  :-)
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt 
Date: Tue, 17 Sep 1996 22:03:17 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> Curtis,
> 
> I have some problems with your proposed replacement text
> for the overlapping routes.
> 
> Current text:
> 
>    If a BGP speaker receives overlapping routes, the Decision Process
>    shall take into account the semantics of the overlapping routes. In
>    particular, if a BGP speaker accepts the less specific route while
>    rejecting the more specific route from the same peer, then the
>    destinations represented by the overlap may not forward along the ASs
>    listed in the AS_PATH attribute of that route. Therefore, a BGP
>    speaker has the following choices:
>    
>          a)   Install both the less and the more specific routes
>    
>          b)   Install the more specific route only
>    
>          c)   Install the non-overlapping part of the less specific
>               route only (that implies de-aggregation)
>    
>          d)   Aggregate the two routes and install the aggregated route
>    
>          e)   Install the less specific route only
>    
>          f)   Install neither route
>    
>    If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
>    attribute to the route. A route that carries ATOMIC_AGGREGATE
>    attribute can not be de-aggregated. That is, the NLRI of this route
>    can not be made more specific.  Forwarding along such a route does
>    not guarantee that IP packets will actually traverse only ASs listed
>    in the AS_PATH attribute of the route.  If a BGP speaker chooses a),
>    it must not advertise the more general route without the more
>    specific route.
>    
>    
> Proposed replacement:
> 
>    If a BGP speaker receives overlapping routes, the Decision Process
>    shall consider both routes based on configured acceptance policy.
>    If both are accepted the Decision Process will install both the
>    less and the more specific routes or aggregate the two routes and
>    install the aggregated route.
             ^^^^^^^^^^^^^^^^^^^^

Should be "both the more specific route and the aggregated route".

>    If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE
>    attribute to the route. A route that carries ATOMIC_AGGREGATE
>    attribute can not be de-aggregated. That is, the NLRI of this route
>    can not be made more specific.  Forwarding along such a route does
>    not guarantee that IP packets will actually traverse only ASs listed
>    in the AS_PATH attribute of the route.  If a BGP speaker chooses to
>    install both routes it must not advertise the more general route
>    without the more specific route.
> 
> 
> The proposed replacement text is incomplete, as it only covers cases
> (a) and (d).
> 
> Moreover, while the original text requires to add ATOMIC_AGGREGATE only
> when only the less specific route is installed, the new text requires
> to add ATOMIC_AGGREGATE when the two routes (more specific and less
> specific) are aggregated. What is the reason for that change ?
> 
> Yakov.

The proposed text contains the phrase

   If a BGP speaker receives overlapping routes, the Decision Process
   shall consider both routes based on configured acceptance policy.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   If both are accepted ...
   ^^^^^^^^^^^^^^^^^^^^

Now look at cases b, c, e, f, the ones omitted.

  >      b)   Install the more specific route only

  Wrong.  You've accepted both routes.

  >      c)   Install the non-overlapping part of the less specific
  >           route only (that implies de-aggregation)

  Deaggrgation is dead.

  >      e)   Install the less specific route only

  Wrong.  You've accepted both routes.

  >      f)   Install neither route

  Wrong.  You've accepted both routes.

This leaves only a, and d.

  >      a)   Install both the less and the more specific routes

  >      d)   Aggregate the two routes and install the aggregated route

Actually, d) should be changed to "aggregate the two routes and
install both routes".

Since deaggregation is dead, ATOMIC_AGGREGATE doesn't matter very
much.  Some routers put ATOMIC_AGGREGATE on by default.

Curtis

ps- Here is an interesting question wrt e):

If router A receives a more specific and rejects it (ie: filters on
prefixes being too long) and router B in the same AS receives a less
specific route, is router B non-conformant to BGP is it advertises the
less specific route without adding ATOMIC_AGGREGATE?

This would mean a route learned from router A would have
ATOMIC_AGGREGATE and could not be deaggregated but the same route from
router B with the same AS path could be deaggregated?  What purpose
does this serve?

Are Sprint's Cisco routers not conforming to BGP by not setting
ATOMIC_AGGREGATE in cases where they did not generate an aggregate but
blocked the more specific of a prefix they received?
- - - - - - - - - - - - - - - - -

To: Eric Hollander <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: joining the mailing list? 
Date: Tue, 17 Sep 1996 15:46:09 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Eric Hollander writes
:
> is this where there is a bgp mailing list?
> i sent mail to bgp-request, and it bounced.
> 
> thanks,
> 
> e

Its a secret.  It keeps newbies off the list.  ;-)

The old mailing list was [email-masked] but it just forwards to
[email-masked].  The -request is not forwarded because [email-masked] was
supposed to go away but people keep using it (I do too).

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

Date: Tue, 17 Sep 1996 12:28:18 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 12:20 AM -0400 9/14/96, Curtis Villamizar wrote:
>Yakov et al.
>
>Here are some suggested changes to the BGP4 draft.  Briefly, there are
>a few separable issues:
>
>  1.  Some wording changes (ie: hunk 1, 6, 7, 8, 14)

Comments on these interspersed with your text below.  Note that I don't
think that hunk 8 is just a wording change (see comment below).

>  2.  Proposing "BGP resynchronization".  See below.

I'm inclined to agree with Yakov wrt resynchronization.  I'll comment on
this in a later message.

--John

P.S.: I assume that the spelling will be fixed up on any changes which are
incorporated...

>***************
>*** 1208,1213 ****
>--- 1256,1275 ----
>     The same attribute cannot appear more than once within the Path
>     Attributes field of a particular UPDATE message.
>
>+    The manditory category refers to a field which must be present in
>+    both IBGP and EBGP exchanges.  Attributes classified as optional
>+    for the purpose of the protocol extension mechanism may be purely
>+    discresionary, or discresionary, required, or disallowed in certain
>+    contexts.
>+
>+       attribute           EBGP                    IBGP
>+        ORIGIN             manditory               manditory
>+        AS_PATH            manditory               manditory
>+        NEXT_HOP           discresionary           discresionary

No.  NEXT_HOP is mandatory.  It's too late to change this even if we wanted
to; other things like route reflection rely on NEXT_HOP.

>+        MULTI_EXIT_DISC    discresionary           discresionary
>+        LOCAL_PREF         disallowed              required
>+        ATOMIC_AGGREGATE   discresionary           discresionary

I've said in earlier messages that ATOMIC_AGGREGATE is not discretionary.
I now see that this is ambiguous.  5.1.6 says "shall":

   "the local system shall attach the ATOMIC_AGGREGATE attribute to
   the route"

but 9.1.4 says "should":

   "it should add ATOMIC_AGGREGATE attribute to the route"

Clearly either 5.1.6 or 9.1.4 needs to be fixed.

If we decide on "shall" (my vote is for this) then this table entry is
wrong, since ATOMIC_AGGREGATE is mandatory under certain circumstances,
which don't relate to EBGP/IBGP.  Unless you can think of a way to fix the
table, I suggest just explaining in the attribute's 5.1.x section exactly
when it is mandatory, forbidden or discretionary.  The table could be left
and ATOMIC_AGGREGATE could be flagged with "see below", or the table could
be removed.

If we decide on "should" then the table is fine.

>+        AGGREGATOR         discresionary           discresionary
>
>
>  5.1 Path Attribute Usage
>***************
>*** 1342,1348 ****
>     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.
>
>
>  5.1.5   LOCAL_PREF
>--- 1404,1410 ----
>     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 from IBGP to other BGP speakers in neighboring AS's.

Personally, I think this is more confusing, not clearer.  I think I finally
figured out what you are trying to do here.  If the point is to make it
clear that the MED may be *originated* in EBGP updates (but not propagated
from EBGP to EBGP), the proposed text is also not quite complete since it
doesn't cover the case in which my border router is propagating routes
between two external peers in two different neighbor ASes, without the
routes passing into IBGP and out again.  (Strictly speaking, it also
doesn't cover the hypothetical case where we use IGP flooding instead of
IBGP.)

How about this:

	The MULTI_EXIT_DISC attribute received from a neighboring AS
	is never propagated to BGP speakers in other neighboring ASes.

[...]
>***************
>*** 2199,2213 ****
>     operating on all new or unfeasible routes contained within it.
>
>     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. If
>!    the route is learned from a BGP speaker in a neighboring autonomous
>!    system, then the degree of preference shall be computed based on
>!    preconfigured policy information.  The exact nature of this policy
>!    information and the computation involved is a local matter.  The
>
>
>
>--- 2313,2327 ----
>     operating on all new or unfeasible routes contained within it.
>
>     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, the
>     value of the LOCAL_PREF attribute shall be taken as the degree of
>!    preference.  If the route is learned from a BGP speaker in a
>!    neighboring autonomous system, then the degree of preference shall
>!    be computed based on preconfigured policy information and used as
>!    the LOCAL_PREF value in any IBGP readvertisement.  The exact nature
>!    of this policy information and the computation involved is a local
>!    matter.  The

I like this.  I want to point out though, that this is more than an
editorial change.  It's actually more restrictive than the text it replaces
since it makes it illegal to apply policy to IBGP routes.  Insofar as it's
probably a bad idea to apply policy to IBGP routes, this is good.  But, I
don't know that this will make a difference to anyone's implementation -- I
suspect that this will just be ignored.  A compromise would allow local
policy to be applied to IBGP, but to make it mandatory to respect
LOCAL_PREF by default (local policy for IBGP could be optional).

>***************
>*** 2243,2259 ****
>     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
>     route SHOULD be excluded from the Phase 2 decision function.
>
>!    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 to the same set
>!       of destinations, or
>!
>!       b) is the only route to that destination, or
>!
>!       c) is selected as a result of the Phase 2 tie breaking rules
>!       specified in 9.1.2.1.
>!
>
>     The local speaker SHALL then install that route in the Loc-RIB,
>     replacing any route to the same destination that is currently being
>--- 2357,2416 ----
>     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
>     route SHOULD be excluded from the Phase 2 decision function.
>
>!   It is critical that routers within an AS do not make conflicting
>!   decisions regarding route selection that would cause forwarding
>!   loops to occur (routers pointing traffic as each other or in a
>!   cycle).  BGP speakers will consider the following attributes in

The parenthetical explanation of forwarding loops isn't quite right.
Routers tend to "point traffic at each other" in the course of normal
correct operation.  I would suggest removing the parenthetical altogether
-- the concept of a forwarding loop is sufficiently well-known that it
doesn't have to be spelled out.

>!   determining preference and will consider no others.
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is my favorite change.  Keep it even if no others are kept!

>!
>!        1.  NEXT_HOP.  The next hop must be reachable, or if NEXT_HOP is
>!            not provided, the advertising router must be reachable)

This should just be "the next hop must be reachable."  NEXT_HOP is
mandatory (see earlier comment) and therefore must be provided.

>!
>!        1.  LOCAL_PREF.
>!
>!        2.  MULTI_EXIT_DISC.  This comparison is applicable only when
>!            comparing MULTI_EXIT_DISC received from the same
>!            neighboring AS, including those received from the same
>!            neighboring AS and passed via IBGP.
>!
>!        3.  Internal routing protocol cost.  Lower costs are preferred.
>!            Select the route that has the lowest cost (interior
>!            distance) to the entity depicted by the NEXT_HOP attribute
>!            of the route.
>!
>!        4.  Advertising router BGP Identifier.  If at least one of the
>!            candidate routes was advertised by the BGP speaker in a
>!            neighboring autonomous system, select the route that was
>!            advertised by the BGP speaker in a neighboring autonomous
>!            system whose BGP Identifier has the lowest value among all
>!            other BGP speakers in neighboring autonomous systems.
>!            Otherwise, select the route that was advertised by the BGP
>!            speaker whose BGP Identifier has the lowest value.
>!
>!   The MULTI_EXIT_DISC may be dropped when passing a route via IBGP.
>!   To prevent routing loops a route with a MULTI_EXIT_DISC (if the
>!   routes and received from the same neighboring AS and therefore the
>!   comparison is applicable) is preferred over one without.
>!
>!   The outcome of a comparison must be independent of the order in
>!   which routes are placed in the Adj-Rib-In and Local-Rib.  Due to
>!   difference in the backlog of propogated routes among IBGP peers, the
>!   same set of routes may arrive in different orders on differnt
>!   routers.  If routes are compared in arbitrary order, under certain
>!   conditions routing loops can occur.  This is a consequence of the
>!   use of MULTI_EXIT_DISC in comparing routes received from the same
>!   neighboring AS but not considering MULTI_EXIT_DISC when comparing
>!   routes received from differing neighboring AS.
>!
>!   The comparison algorithm must insure a deterministic decision
>!   outcome.  To accomplish this, routes are compared in a constrained
>!   order.  First all routes are checked for feasibility, insuring that
>!   the NEXT_HOP is reachable.  All routes from the same neighboring AS
>!   are first compared using the criteria above, LOCAL_PREF,
>!   MULTI_EXIT_DISC, internal routing protocol cost, and Advertising
>!   router IP address.  Then the best route selected from each
>!   neighboring AS are compared using the criteria, LOCAL_PREF, internal
>!   routing protocol cost, and Advertising router BGP Identifier.

This paragraph is hard to understand.  It seems to have been cut-n-pasted a
few times -- at least two things are done "first."  Also, it seems to
reiterate the steps just described.  Is this necessary?  I think it needs
to be rewritten.

As you know, I'm also not fond of specifying the algorithm in this fashion.
Others are certainly usable to come up with the same result.  A disclaimer
that any algorithm with the same results is acceptable is called for.

As you know I submitted some other text that uses some bits of pseudo-code
to explain the same thing.  I know you don't like it.  Obviously, I do.
Mainly, I prefer to do it that way because I think that the above text kind
of obscures the desired outcome -- you have to add the "must be independent
of order" and "in a constrained order" paragraphs to fix this up.  I prefer
to make it explicit in the actual specification of the steps rather than as
a fix-up note.

That said, I have no idea what anyone else likes, I think that your text is
probably also correct (just more confusing, to me) and I'm pretty much worn
down to the point where I don't care to debate this any more.  But, I
wanted to point out to the WG that there has already been another
alternative proposed here.

I do like the fact that you eliminated the idea of tie-breaking and just
put it all in 9.1.2.

>     The local speaker SHALL then install that route in the Loc-RIB,
>     replacing any route to the same destination that is currently being

[...]
>***************
>*** 2425,2451 ****
>     the less specific route.
>
>     If a BGP speaker receives overlapping routes, the Decision Process
>!    shall take into account the semantics of the overlapping routes. In
>!    particular, if a BGP speaker accepts the less specific route while
>!    rejecting the more specific route from the same peer, then the
>!    destinations represented by the overlap may not forward along the ASs
>!    listed in the AS_PATH attribute of that route. Therefore, a BGP
>!    speaker has the following choices:
>!
>!       a)   Install both the less and the more specific routes
>!
>!       b)   Install the more specific route only
>!
>!       c)   Install the non-overlapping part of the less specific
>!                  route only (that implies de-aggregation)
>!
>!       d)   Aggregate the two routes and install the aggregated route
>!
>!       e)   Install the less specific route only
>!
>!       f)   Install neither route
>
>!    If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
>     attribute to the route. A route that carries ATOMIC_AGGREGATE
>     attribute can not be de-aggregated. That is, the NLRI of this route
>
>--- 2543,2554 ----
>     the less specific route.
>
>     If a BGP speaker receives overlapping routes, the Decision Process
>!    shall consider both routes based on configured acceptance policy.
>!    If both are accepted the Decision Process will install both the
>!    less and the more specific routes or aggregate the two routes and
>!    install the aggregated route.
>
>!    If a BGP speaker chooses to aggregate, then it should add
>ATOMIC_AGGREGATE
>     attribute to the route. A route that carries ATOMIC_AGGREGATE
>     attribute can not be de-aggregated. That is, the NLRI of this route

Note earlier comments regarding inconsistency between "shall" and "should"
for ATOMIC_AGGREGATE.  (This is a pre-existing problem with the spec and
not related to Curtis's changes.)

[...]
>***************
>*** 2500,2531 ****
>     When a BGP speaker receives a new route from a BGP speaker in a
>     neighboring autonomous system, it shall advertise that route to all
>     other BGP speakers in its autonomous system by means of an UPDATE
>!    message if any of the following conditions occur:
>!
>!       1) the degree of preference assigned to the newly received route
>!       by the local BGP speaker is higher than the degree of preference
>!       that the local speaker has assigned to other routes that have been
>!       received from BGP speakers in neighboring autonomous systems, or
>!
>!       2) there are no other routes that have been received from BGP
>!
>!
>!
>! Expiration Date February 1996                                  [Page 42]
>!
>!
>!
>!
>!
>! INTERNET DRAFT                                               August 1996
>!
>!
>!       speakers in neighboring autonomous systems, or
>!
>!       3) the newly received route is selected as a result of breaking a
>!       tie between several routes which have the highest degree of
>!       preference, and the same destination (the tie-breaking procedure
>!       is specified in 9.2.1.1).
>
>     When a BGP speaker receives an UPDATE message with a non-empty
>     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
>--- 2603,2610 ----
>     When a BGP speaker receives a new route from a BGP speaker in a
>     neighboring autonomous system, it shall advertise that route to all
>     other BGP speakers in its autonomous system by means of an UPDATE
>!    message if this route has become the best route installed in the
>!    Local-Rib according to the route selection rules in 9.1.2.
>
>     When a BGP speaker receives an UPDATE message with a non-empty
>     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all

I like this change a lot.  I think that it could be simplified even a bit
more by removing "the best route", like so:  "...if this route has been
installed in the Local-Rib according..." -- after all, it will only be
installed in the Loc-RIB if it's chosen as the best route.

--
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, 17 Sep 1996 11:53:33 -0400
To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 6:33 AM -0700 9/17/96, Yakov Rekhter wrote:
>> !    having all BGP speakers within the AS maintain direct IBGP connections
>> !    with each other.  Alternately the interior routing protocol can
>> !    pass BGP information among routers within an AS, taking care not to
>> !    lose BGP attributes that will be needed by EBGP speakers if transit
>> !    connectivity is being providided.  For the purpose of discussion,
>> !    it is assumed that BGP information is passed within an AS using
>> !    IBGP.  Care must be taken to ensure that the interior routers have
>> !    all been updated with transit information before the EBGP speakers
>> !    announce to other ASs that transit service is being provided.
>
>Despite the fact that the notion of using IGP to carry BGP information
>within an AS isn't new, and had been discussed within the IDR WG on
>more than one occassion, we've yet to see any progress in this area.
>So, why should the BGP spec describe something that doesn't exist ?

I think that the spec shouldn't preclude using the IGP.  Beyond that, I
don't care.  I think Curtis's text allows for the possibility without going
overboard.  By the way, the possibility of using the IGP is also alluded to
in section 3 of the current draft.

(By the way, there are various places where text like "care must be taken
to ensure that the interior routers have all been updated with transit
information before the EBGP speakers announce..." appears in the current
I-D (and the RFC).  Speaking of things that don't exist, can anyone point
to any implementations which *guarantee* that the IGP has converged
throughout the entire AS before propagating the route in EBGP?  If not, why
is this text present?)

--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, 17 Sep 1996 11:29:02 -0400
From: "David J. LeRoy" <[email-masked]>
Organization: FORE Systems
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt
Sender: [email-masked]

In regards to the editorial comments, one inconsistency which should be 
clarified is that the NextHop attribute used to be a manditory attribute
but is listed in the edits as discretionary and references are made in
the route selection text to that effect ("if NEXT_HOP is not provided")

>         c)   NEXT_HOP (Type Code 3):
>
>            This is a well-known mandatory attribute that defines the IP
>            address of the border router that should be used as the next
>            hop to the destinations listed in the Network Layer
>            Reachability field of the UPDATE message.

>      attribute           EBGP                    IBGP
>       ORIGIN             manditory               manditory
>       AS_PATH            manditory               manditory
>       NEXT_HOP           discresionary           discresionary
>       MULTI_EXIT_DISC    discresionary           discresionary
>       LOCAL_PREF         disallowed              required
>       ATOMIC_AGGREGATE   discresionary           discresionary
>       AGGREGATOR         discresionary           discresionary

>      1.  NEXT_HOP.  The next hop must be reachable, or if NEXT_HOP is
>           not provided, the advertising router must be reachable)

Also, while we are trying to clear up the wording about IBGP and EBGP, I
believe it should be used consistantly and so "external peers" should
replace
all occurences of "BGP speakers in neighboring autonomous systems"

Less of a nit, I'd like to see the wording in section 5.1.3 made
clearer. I
took a shot at the last paragraph, but am uncertain of the intent of the
text
in the 1st paragraph (especially dealing with internal border routers)
Is this
describing the behavior of IBGP speakers originating routes to internal
peers,
because the last paragraph is explicitely saying not to modify the
NEXT_HOP
received from internal peers? Below is the edit for the last paragraph
of 5.1.3

***************
*** 1385,1397 ****
     as a NEXT_HOP, for a route that the speaker is originating.  A BGP
     speaker must never install a route with itself as the next hop.
  
!    When a BGP speaker advertises the route to a BGP speaker located in
!    its own autonomous system, the advertising speaker shall not modify
!    the NEXT_HOP attribute associated with the route.  When a BGP
speaker
!    receives the route via an internal link, it may forward packets to
!    the NEXT_HOP address if the address contained in the attribute is
on
!    a common subnet with the local and remote BGP speakers.
! 
  
  5.1.4   MULTI_EXIT_DISC
  
--- 1385,1399 ----
     as a NEXT_HOP, for a route that the speaker is originating.  A BGP
     speaker must never install a route with itself as the next hop.
  
!    When a BGP speaker advertises a route to internal peers received
!    via an external link, the advertising internal speaker shall not
!    modify the NEXT_HOP attribute associated with the route. When a BGP
!    speaker receives the route via an internal link, it may directly
!    forward packets to the NEXT_HOP address if the peer shares a common
!    subnet with the address contained in the NEXT_HOP attribute. If the
!    address is not on a common subnet, the receiving internal peer must
!    consult its IGP routing table for a viable nexthop towards the
!    address contained in the NEXT_HOP attribute. 
  
  5.1.4   MULTI_EXIT_DISC

Dave
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt 
Date: Tue, 17 Sep 96 06:33:33 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Curtis,

>      If a particular AS has multiple BGP speakers and is providing transit
>      service for other ASs, then care must be taken to ensure a consistent
>      view of routing within the AS.  A consistent view of the interior
>      routes of the AS is provided by the interior routing protocol.  A
>      consistent view of the routes exterior to the AS can be provided by
> !    having all BGP speakers within the AS maintain direct IBGP connections
> !    with each other.  Alternately the interior routing protocol can
> !    pass BGP information among routers within an AS, taking care not to
> !    lose BGP attributes that will be needed by EBGP speakers if transit
> !    connectivity is being providided.  For the purpose of discussion,
> !    it is assumed that BGP information is passed within an AS using
> !    IBGP.  Care must be taken to ensure that the interior routers have
> !    all been updated with transit information before the EBGP speakers
> !    announce to other ASs that transit service is being provided.

Despite the fact that the notion of using IGP to carry BGP information
within an AS isn't new, and had been discussed within the IDR WG on
more than one occassion, we've yet to see any progress in this area.
So, why should the BGP spec describe something that doesn't exist ?

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt 
Date: Tue, 17 Sep 96 06:11:29 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Curtis,

I have some problems with your proposed replacement text
for the overlapping routes.

Current text:

   If a BGP speaker receives overlapping routes, the Decision Process
   shall take into account the semantics of the overlapping routes. In
   particular, if a BGP speaker accepts the less specific route while
   rejecting the more specific route from the same peer, then the
   destinations represented by the overlap may not forward along the ASs
   listed in the AS_PATH attribute of that route. Therefore, a BGP
   speaker has the following choices:
   
         a)   Install both the less and the more specific routes
   
         b)   Install the more specific route only
   
         c)   Install the non-overlapping part of the less specific
              route only (that implies de-aggregation)
   
         d)   Aggregate the two routes and install the aggregated route
   
         e)   Install the less specific route only
   
         f)   Install neither route
   
   If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
   attribute to the route. A route that carries ATOMIC_AGGREGATE
   attribute can not be de-aggregated. That is, the NLRI of this route
   can not be made more specific.  Forwarding along such a route does
   not guarantee that IP packets will actually traverse only ASs listed
   in the AS_PATH attribute of the route.  If a BGP speaker chooses a),
   it must not advertise the more general route without the more
   specific route.

Proposed replacement:

   If a BGP speaker receives overlapping routes, the Decision Process
   shall consider both routes based on configured acceptance policy.
   If both are accepted the Decision Process will install both the
   less and the more specific routes or aggregate the two routes and
   install the aggregated route.
   
   If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE
   attribute to the route. A route that carries ATOMIC_AGGREGATE
   attribute can not be de-aggregated. That is, the NLRI of this route
   can not be made more specific.  Forwarding along such a route does
   not guarantee that IP packets will actually traverse only ASs listed
   in the AS_PATH attribute of the route.  If a BGP speaker chooses to
   install both routes it must not advertise the more general route
   without the more specific route.

The proposed replacement text is incomplete, as it only covers cases
(a) and (d).

Moreover, while the original text requires to add ATOMIC_AGGREGATE only
when only the less specific route is installed, the new text requires
to add ATOMIC_AGGREGATE when the two routes (more specific and less
specific) are aggregated. What is the reason for that change ?

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

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt 
Date: Tue, 17 Sep 1996 02:38:33 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> 
> 1. I looked at your editorial comments, and they seems to be fine
>    (except for comment 3). I would suggest that we'll give folks
>    on the list 3 weeks for comments, and in the absence of objections
>    I'll incorporate your editorial comments.

OK

> 2. Wrt BGP resyncronization, I'd like to see some stong justifications for
>    introducing this message.
>    
> > The "BGP resynchronization" warents further mention.  The idea was to
> > make something 100% compatible with current BGP4 implementations that
> > addresses the following:
> > 
> >   1.  Allows a better recovery if running a hosed implementation.  No
> >       more clearing the BGP conection.
> 
> How is that going to be better ? Seems that that best way to
> recover against a hosed implementation is to terminate peering
> with this implementation and get the "hosed implementation" fixed.

What typically happens is routes that are supposed to have been added
or removed aren't, often due to the order in which routes arrived or
were withdrawn.  This would provide an non-disruptive way of clearing
the condition while people look for the bugs.

We had been seeing this sort of problem with the Bay routers.  I can
think of numerous times that we've had to do a clear ip bgp <peer> to
fix a small number of prefixes in the Cisco that were not right so it
does happen with Cisco routers too.

At this point we could do without this.  Until the next bug.

This would also help in cases where Cisco routers need a clear
connection to get next hop right after it changed or to update a MED
derived from IGP cost.  These are still outstanding bugs.

> >   2.  Allows a cheap policy reconfig (maybe less desirable than a true
> >       dynamic reconfig) that doesn't involve clearing the BGP conection.
> 
> The problem of policy reconfig is already solved (in multiple independent 
> implementations) without BGP resyncronization. 

OK.

> >   3.  Reduces the impact of occasional loss of BGP connections.  Might
> >       even allow you to squeeze in a reload if it was real fast.
> 
> Please elaborate.

I should have put a smilely on the reload part.  A while back there
was loss on MaeWest and we think this contributed to one EBGP going
down a few times a day (though we are not sure why only this
connection lost EBGP).  The flap could be avoided if this was the only
peering (if not maybe better to take the peering down).

> >   4.  Reduces the exposure to TCP RST attacks.
> 
> Please elaborate.

well known but offline anyway.

> Yakov.

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

Date: Mon, 16 Sep 1996 12:38:19 -0700
From: Eric Hollander <[email-masked]>
To: [email-masked]
Subject: joining the mailing list?
Sender: [email-masked]

is this where there is a bgp mailing list?
i sent mail to bgp-request, and it bounced.

thanks,

e
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Subject: Re: diffs to draft-ietf-idr-bgp4-03.txt 
Date: Mon, 16 Sep 96 07:09:16 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Curtis,

> Here are some suggested changes to the BGP4 draft.  Briefly, there are
> a few separable issues:
> 
>   1.  Some wording changes (ie: hunk 1, 6, 7, 8, 14)
> 
>   2.  Proposing "BGP resynchronization".  See below.
> 
>   3.  Replace descriptions of route selection with something more
>       clear and accurate.
> 
>   4.  Replace some text about route overlap that is wrong and reflects
>       earlier indecision on the part of the WG.

I think that we need to decouple the editorial changes from
the technical changes, especially at the point where the WG
is in the process of advancing the document to a Full Standard.

With this in mind here is my response:

1. I looked at your editorial comments, and they seems to be fine
   (except for comment 3). I would suggest that we'll give folks
   on the list 3 weeks for comments, and in the absence of objections
   I'll incorporate your editorial comments.

2. Wrt BGP resyncronization, I'd like to see some stong justifications for
   introducing this message.
   
> The "BGP resynchronization" warents further mention.  The idea was to
> make something 100% compatible with current BGP4 implementations that
> addresses the following:
> 
>   1.  Allows a better recovery if running a hosed implementation.  No
>       more clearing the BGP conection.

How is that going to be better ? Seems that that best way to
recover against a hosed implementation is to terminate peering
with this implementation and get the "hosed implementation" fixed.
  
>   2.  Allows a cheap policy reconfig (maybe less desirable than a true
>       dynamic reconfig) that doesn't involve clearing the BGP conection.

The problem of policy reconfig is already solved (in multiple independent 
implementations) without BGP resyncronization. 
  
>   3.  Reduces the impact of occasional loss of BGP connections.  Might
>       even allow you to squeeze in a reload if it was real fast.

Please elaborate.
  
>   4.  Reduces the exposure to TCP RST attacks.

Please elaborate.

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

To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: diffs to draft-ietf-idr-bgp4-03.txt
Date: Sat, 14 Sep 1996 00:20:09 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

Yakov et al.

Here are some suggested changes to the BGP4 draft.  Briefly, there are
a few separable issues:

  1.  Some wording changes (ie: hunk 1, 6, 7, 8, 14)

  2.  Proposing "BGP resynchronization".  See below.

  3.  Replace descriptions of route selection with something more
      clear and accurate.

  4.  Replace some text about route overlap that is wrong and reflects
      earlier indecision on the part of the WG.

The "BGP resynchronization" warents further mention.  The idea was to
make something 100% compatible with current BGP4 implementations that
addresses the following:

  1.  Allows a better recovery if running a hosed implementation.  No
      more clearing the BGP conection.

  2.  Allows a cheap policy reconfig (maybe less desirable than a true
      dynamic reconfig) that doesn't involve clearing the BGP conection.

  3.  Reduces the impact of occasional loss of BGP connections.  Might
      even allow you to squeeze in a reload if it was real fast.

  4.  Reduces the exposure to TCP RST attacks.

Given some of the talk on the NANOG list, #4 might not be a bad
feature.  Fixing BGP to use UDP is a bigger job and this and a good
TCP PCB hashing and long listen queue for TCP SYN attack could prove
very valuable changes.

Curtis

Just apply the diffs to draft-ietf-idr-bgp4-03.txt to get the new
document.  The diff hunks are:

  1  an attempt to clear up wording regarding IBGP, EBGP, and IGP and
     the role of IBGP.

  2  First mention of BGP resynchronization

  3  I couldn't resist.  Might want to leave this one out.

  4  Add RESYNCHRONIZATION message type

  5  Define RESYNCHRONIZATION message format

  6  Clarifying sentence - path attributes are for the purpose
     of supporting a protocol extension mechanism.

  7  Added the table with discresionary, required, or disallowed, etc.

  8  Clarification of MULTI_EXIT_DISC usage.

  9  Add BGP resynchronization to Error Handling section.

 10  Allow marking routes for withdrawl on disconnect.

 11  BGP Resynchronization section

 12&13  Fixed overlap route jabber that was just plain wrong.

 14  Clarified setting LOCAL_PREF.

 16  Replaced description of route slection with one that is much more
     concise and clear and covers the route loop avoidance, including
     a brief description of the reasons loops can form.

 17  Got rid of unclear tie breaker section.

 18&19  Replaced the route overlap section with one that reflects
     reality now that we have plenty of experience with BGP4.

 20&21  Eliminated a great deal of repitition and referred back to 9.1.2.
     btw- why can't 9.2.1 be as simple as 9.2.2 - or does 9.2.2 need
     to spell things out in detail like 9.2.1?

*** draft-ietf-idr-bgp4-03.txt	Sat Aug 17 08:34:53 1996
--- draft-ietf-idr-bgp4-03.txt.new	Sat Sep 14 00:01:33 1996
***************
*** 205,230 ****
     router in another Autonomous System.  The implications and
     applications of this architecture are for further study.
  
     If a particular AS has multiple BGP speakers and is providing transit
     service for other ASs, then care must be taken to ensure a consistent
     view of routing within the AS.  A consistent view of the interior
     routes of the AS is provided by the interior routing protocol.  A
     consistent view of the routes exterior to the AS can be provided by
!    having all BGP speakers within the AS maintain direct BGP connections
!    with each other.  Using a common set of policies, the BGP speakers
!    arrive at an agreement as to which border routers will serve as
!    exit/entry points for particular destinations outside the AS.  This
!    information is communicated to the AS's internal routers, possibly
!    via the interior routing protocol.  Care must be taken to ensure that
!    the interior routers have all been updated with transit information
!    before the BGP speakers announce to other ASs that transit service is
!    being provided.
! 
!    Connections between BGP speakers of different ASs are referred to as
!    "external" links.  BGP connections between BGP speakers within the
!    same AS are referred to as "internal" links.  Similarly, a peer in a
!    different AS is referred to as an external peer, while a peer in the
!    same AS may be described as an internal peer.

  
--- 205,231 ----
     router in another Autonomous System.  The implications and
     applications of this architecture are for further study.
  
+    Connections between BGP speakers of different ASs are referred to as
+    "external" links.  BGP connections between BGP speakers within the
+    same AS are referred to as "internal" links.  Similarly, a peer in a
+    different AS is referred to as an external peer, while a peer in the
+    same AS may be described as an internal peer.  Internal BGP and
+    external BGP are commonly abbreviated IBGP and EBGP.
+ 
     If a particular AS has multiple BGP speakers and is providing transit
     service for other ASs, then care must be taken to ensure a consistent
     view of routing within the AS.  A consistent view of the interior
     routes of the AS is provided by the interior routing protocol.  A
     consistent view of the routes exterior to the AS can be provided by
!    having all BGP speakers within the AS maintain direct IBGP connections
!    with each other.  Alternately the interior routing protocol can
!    pass BGP information among routers within an AS, taking care not to
!    lose BGP attributes that will be needed by EBGP speakers if transit
!    connectivity is being providided.  For the purpose of discussion,
!    it is assumed that BGP information is passed within an AS using
!    IBGP.  Care must be taken to ensure that the interior routers have
!    all been updated with transit information before the EBGP speakers
!    announce to other ASs that transit service is being provided.

  
***************
*** 282,291 ****
        Information can be advertised, or
  
        c) the BGP speaker - BGP speaker connection can be closed, which
!       implicitly removes from service all routes which the pair of
!       speakers had advertised to each other.
! 
! 

  
--- 283,297 ----
        Information can be advertised, or
  
        c) the BGP speaker - BGP speaker connection can be closed, which
!       implicitly marks all routes hte pair of speakers had advertised
!       to each other for removal from service if a connection is not
!       reestablished and the routes readvertised before a resynchronization
!       completed message or before a configured expiration timer elapses.
! 
!       d) the BGP speaker or listenner may request a resynchronization
!       which explicitly marks all routes for removal from service if not
!       readvertised before a resynchronization completed message or before
!       a configured expiration timer elapses.

  
***************
*** 333,339 ****
     implementation must maintain three separate copies of the routing
     information. The choice of implementation (for example, 3 copies of
     the information vs 1 copy with pointers) is not constrained by the
!    protocol.
  
  4.  Message Formats
  
--- 339,346 ----
     implementation must maintain three separate copies of the routing
     information. The choice of implementation (for example, 3 copies of
     the information vs 1 copy with pointers) is not constrained by the
!    protocol.  And in fact you'd be pretty stupid to maintain separate
!    copies though it has been tried.
  
  4.  Message Formats
  
***************
*** 435,440 ****
--- 442,448 ----
                                      2 - UPDATE
                                      3 - NOTIFICATION
                                      4 - KEEPALIVE
+ 				    5 - RESYNCHRONIZATION

  4.2 OPEN Message Format
***************
*** 1127,1135 ****
--- 1135,1182 ----

  
+ 4.5 RESYNCHRONIZATION Message Format
+ 
+ 
+    A RESYNCHRONIZATION message is sent when there is reason to believe
+    that routing information in either the speaker of the listenner is
+    not correct or routing policy has been changed and the speaker is
+    unable to process the routing policy change without readvertising
+    the full set of routes.  A RESYNCHRONIZATION message should never
+    be required except where a policy change has occurred or unless
+    either the speaker of listenner implementation is in error.
+ 
+ 
+    In addition to the fixed-size BGP header, the RESYNCHRONIZATION
+    message contains the following fields:
+ 
+ 
+         0                   1                   2                   3
+         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+        | Request Type  | Reserved      |
+        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  
+       Request Type:
+ 
+          This 1-octet unsigned integer indicates the type of
+          RESYNCHRONIZATION request.  The following Request Codes have
+          been defined:
+ 
+             Request Code     Symbolic Name               Reference
+ 
+               1         Sender Resynchronizing Request   Section 6.9
+ 
+               2         Receiver Resynchronize Request   Section 6.9
+ 
+               3         Resynchronizion Completed        Section 6.9
+ 
+ The length of the RESYNCHRONIZATION message is 21 octets (including
+ message header).
+ 
+ 
  
  Expiration Date February 1996                                  [Page 19]
  
***************
*** 1145,1151 ****
  
     This section discusses the path attributes of the UPDATE message.
  
!    Path attributes fall into four separate categories:
  
                 1. Well-known mandatory.
                 2. Well-known discretionary.
--- 1192,1199 ----
  
     This section discusses the path attributes of the UPDATE message.
  
!    Path attributes fall into four separate categories for the purpose
!    of supporting a protocol extension mechanism:
  
                 1. Well-known mandatory.
                 2. Well-known discretionary.
***************
*** 1208,1213 ****
--- 1256,1275 ----
     The same attribute cannot appear more than once within the Path
     Attributes field of a particular UPDATE message.
  
+    The manditory category refers to a field which must be present in
+    both IBGP and EBGP exchanges.  Attributes classified as optional
+    for the purpose of the protocol extension mechanism may be purely
+    discresionary, or discresionary, required, or disallowed in certain
+    contexts.
+ 
+       attribute           EBGP                    IBGP
+        ORIGIN             manditory               manditory
+        AS_PATH            manditory               manditory
+        NEXT_HOP           discresionary           discresionary
+        MULTI_EXIT_DISC    discresionary           discresionary
+        LOCAL_PREF         disallowed              required
+        ATOMIC_AGGREGATE   discresionary           discresionary
+        AGGREGATOR         discresionary           discresionary

  5.1 Path Attribute Usage
***************
*** 1342,1348 ****
     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.

  5.1.5   LOCAL_PREF
--- 1404,1410 ----
     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 from IBGP to other BGP speakers in neighboring AS's.

  5.1.5   LOCAL_PREF
***************
*** 1411,1423 ****
     attribute which shall contain its own AS number and IP address.

! 6.  BGP Error Handling.

     This section describes actions to be taken when errors are detected
!    while processing BGP messages.
  
!    When any of the conditions described here are detected, a
     NOTIFICATION message with the indicated Error Code, Error Subcode,
     and Data fields is sent, and the BGP connection is closed.  If no
     Error Subcode is specified, then a zero must be used.
--- 1473,1485 ----
     attribute which shall contain its own AS number and IP address.

! 6.  BGP Error and Resynchronization Handling.

     This section describes actions to be taken when errors are detected
!    while processing BGP messages or during resynchronization.
  
!    When any erro conditions described here are detected, a
     NOTIFICATION message with the indicated Error Code, Error Subcode,
     and Data fields is sent, and the BGP connection is closed.  If no
     Error Subcode is specified, then a zero must be used.
***************
*** 1425,1431 ****
     The phrase "the BGP connection is closed" means that the transport
     protocol connection has been closed and that all resources for that
     BGP connection have been deallocated.  Routing table entries
!    associated with the remote peer are marked as invalid.  The fact that
     the routes have become invalid is passed to other BGP peers before
     the routes are deleted from the system.
  
--- 1487,1494 ----
     The phrase "the BGP connection is closed" means that the transport
     protocol connection has been closed and that all resources for that
     BGP connection have been deallocated.  Routing table entries
!    associated with the remote peer are either marked as invalid or
!    optionally marked as if a resynchronization had occurred.  The fact that
     the routes have become invalid is passed to other BGP peers before
     the routes are deleted from the system.
  
***************
*** 1754,1759 ****
--- 1817,1888 ----
        message with the Error Code Cease.

+ 6.9 BGP Resynchronization
+ 
+ 
+    BGP implementation may optionally support a form of graceful
+    resynchronization rather than closing the BGP connection in certain
+    conditions and may optionally allow resynchronization rather than
+    immediate route withdrawl when a BGP connection is closed.  BGP
+    implementation which support resynchronization must be prepared to
+    detect and interoperate with implementations which do not.
+ 
+    A resynchronization request will generally be made in response to
+    operator intervention.  A resynchronization request can also be
+    made when conditions indicate internal inconsistency, such as
+    failure of a coded assertion.  Implementations which require
+    resynchronization should be considered in error, however the BGP
+    protocol accomodates the possibility that errant implementation may
+    exist (transiently) and provides resynchronization as a means to
+    restore operational integrity with minimal disruption.
+ 
+    After sending a RESYNCHRONIZATION message with a Sender
+    Resynchronizing Request (Request Code 1) or receiving a
+    RESYNCHRONIZATION message with a Receiver Resynchronize Request
+    (Request Code 2), the sender must empty the associated Adj-RIBs-Out
+    and readvertise all route in its Loc-RIB to its peer as described
+    in section 9.1.3, as if no routes had ever been advertised to that
+    peer.
+ 
+    After receiving a RESYNCHRONIZATION message with a Sender
+    Resynchronizing Request (Request Code 1) or sending a
+    RESYNCHRONIZATION message with a Receiver Resynchronize Request
+    (Request Code 2), the receiver must mark all entries in the Loc-RIB
+    for removal and empty the Adj-RIBs-In.  As the Adj-RIBs-In is
+    repopulated the marks in the associated Loc-RIB entires are
+    removed.  After a configured expiration timer has elapsed or a
+    RESYNCHRONIZATION message with a Resynchronizion Completed (Request
+    Code 3) is received, all entries in the Loc-RIB still marked are
+    removed as it they had been withdrawn.
+ 
+    Optionally when a BGP connection is closed the Loc-RIB entries may
+    be treated in the same way they would be when receiving a
+    RESYNCHRONIZATION message with a Sender Resynchronizing Request.
+    It should be possible to configure a different expiration timer
+    value for this condition or disable it entirely.
+ 
+    Optionally a BGP speaker may send a RESYNCHRONIZATION message with
+    a Resynchronizion Completed after a connection has been
+    established, in effect treating the entry to the established state
+    as an implied RESYNCHRONIZATION message with a Receiver Resynchronize 
+    Request from the peer.
+ 
+    An implementation which does not support BGP Resynchronization must
+    send a NOTIFICATION with a Message Header Error (Error Code 1) and a
+    Bad Message Type (Error subcode 3).  
+ 
+    An implementation which does support BGP Resynchronization must
+    have the ability to configure a peer as not supporting BGP
+    Resynchronization and not send any form of RESYNCHRONIZATION
+    message to such a peer.  It must also be able to record the fact
+    that a peer has sent a NOTIFICATION in response to a
+    RESYNCHRONIZATION message and disable sending any further
+    RESYNCHRONIZATION messages to that peer, even after the BGP
+    connection if broken and reestablished, unless that peer later
+    sends a RESYNCHRONIZATION message (which would be interpretted as a
+    code update adding support for BGP Resynchronization).
+ 
+ 
  7.  BGP Version Negotiation.

***************
*** 2085,2095 ****
     shall run its Decision Process since the older route is no longer
     available for use.
  
-    ii) If the new route is an overlapping route that is included (see
-    9.1.4) in an earlier route contained in the Adj-RIB-In, the BGP
-    speaker shall run its Decision Process since the more specific route
- 
- 
  
  Expiration Date February 1996                                  [Page 35]
  
--- 2214,2219 ----
***************
*** 2100,2121 ****
  INTERNET DRAFT                                               August 1996

!    has implicitly made a portion of the less specific route unavailable
!    for use.
! 
!    iii) If the new route has identical path attributes to an earlier
!    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
!    than the earlier route, no further actions are necessary.
! 
!    iv) If the new route has NLRI that is not present in any of the
!    routes currently stored in the Adj-RIB-In, then the new route shall
!    be placed in the Adj-RIB-In. The BGP speaker shall run its Decision
!    Process.
! 
!    v) If the new route is an overlapping route that is less specific
!    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
!    BGP speaker shall run its Decision Process on the set of destinations
!    described only by the less specific route.

  9.1 Decision Process
--- 2224,2235 ----
  INTERNET DRAFT                                               August 1996

!    ii) If the new route has NLRI that is not present in any of the
!    routes currently stored in the Adj-RIB-In, regardless of whether
!    the new route overlaps an earlier route contained in the Adj-RIB-In
!    that is either more specific or less specific (see 9.1.4), then the
!    new route shall be placed in the Adj-RIB-In. The BGP speaker shall
!    run its Decision Process.

  9.1 Decision Process
***************
*** 2199,2213 ****
     operating on all new or unfeasible routes contained within it.
  
     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. If
!    the route is learned from a BGP speaker in a neighboring autonomous
!    system, then the degree of preference shall be computed based on
!    preconfigured policy information.  The exact nature of this policy
!    information and the computation involved is a local matter.  The

  
--- 2313,2327 ----
     operating on all new or unfeasible routes contained within it.
  
     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, the
     value of the LOCAL_PREF attribute shall be taken as the degree of
!    preference.  If the route is learned from a BGP speaker in a
!    neighboring autonomous system, then the degree of preference shall
!    be computed based on preconfigured policy information and used as
!    the LOCAL_PREF value in any IBGP readvertisement.  The exact nature
!    of this policy information and the computation involved is a local
!    matter.  The 

  
***************
*** 2243,2259 ****
     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
     route SHOULD be excluded from the Phase 2 decision function.
  
!    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 to the same set
!       of destinations, or
! 
!       b) is the only route to that destination, or
! 
!       c) is selected as a result of the Phase 2 tie breaking rules
!       specified in 9.1.2.1.
! 
  
     The local speaker SHALL then install that route in the Loc-RIB,
     replacing any route to the same destination that is currently being
--- 2357,2416 ----
     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
     route SHOULD be excluded from the Phase 2 decision function.
  
!   It is critical that routers within an AS do not make conflicting
!   decisions regarding route selection that would cause forwarding
!   loops to occur (routers pointing traffic as each other or in a
!   cycle).  BGP speakers will consider the following attributes in
!   determining preference and will consider no others.
! 
!        1.  NEXT_HOP.  The next hop must be reachable, or if NEXT_HOP is
!            not provided, the advertising router must be reachable)
! 
!        1.  LOCAL_PREF.
! 
!        2.  MULTI_EXIT_DISC.  This comparison is applicable only when
!            comparing MULTI_EXIT_DISC received from the same
!            neighboring AS, including those received from the same
!            neighboring AS and passed via IBGP.
! 
!        3.  Internal routing protocol cost.  Lower costs are preferred.
!            Select the route that has the lowest cost (interior
!            distance) to the entity depicted by the NEXT_HOP attribute
!            of the route.
! 
!        4.  Advertising router BGP Identifier.  If at least one of the
!            candidate routes was advertised by the BGP speaker in a
!            neighboring autonomous system, select the route that was
!            advertised by the BGP speaker in a neighboring autonomous
!            system whose BGP Identifier has the lowest value among all
!            other BGP speakers in neighboring autonomous systems.
!            Otherwise, select the route that was advertised by the BGP
!            speaker whose BGP Identifier has the lowest value.
! 
!   The MULTI_EXIT_DISC may be dropped when passing a route via IBGP.
!   To prevent routing loops a route with a MULTI_EXIT_DISC (if the
!   routes and received from the same neighboring AS and therefore the
!   comparison is applicable) is preferred over one without.
! 
!   The outcome of a comparison must be independent of the order in
!   which routes are placed in the Adj-Rib-In and Local-Rib.  Due to
!   difference in the backlog of propogated routes among IBGP peers, the
!   same set of routes may arrive in different orders on differnt
!   routers.  If routes are compared in arbitrary order, under certain
!   conditions routing loops can occur.  This is a consequence of the
!   use of MULTI_EXIT_DISC in comparing routes received from the same
!   neighboring AS but not considering MULTI_EXIT_DISC when comparing
!   routes received from differing neighboring AS.
! 
!   The comparison algorithm must insure a deterministic decision
!   outcome.  To accomplish this, routes are compared in a constrained
!   order.  First all routes are checked for feasibility, insuring that
!   the NEXT_HOP is reachable.  All routes from the same neighboring AS
!   are first compared using the criteria above, LOCAL_PREF,
!   MULTI_EXIT_DISC, internal routing protocol cost, and Advertising
!   router IP address.  Then the best route selected from each
!   neighboring AS are compared using the criteria, LOCAL_PREF, internal
!   routing protocol cost, and Advertising router BGP Identifier.
  
     The local speaker SHALL then install that route in the Loc-RIB,
     replacing any route to the same destination that is currently being
***************
*** 2280,2325 ****
  INTERNET DRAFT                                               August 1996

!    RIBs-In.
! 
! 
! 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.  Ties shall be broken according to
!    the following algorithm:
! 
!       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.
! 
!       b) Otherwise, select the route that has the lowest cost (interior
!       distance) to the entity depicted by the NEXT_HOP attribute of the
!       route.  If there are several routes with the same cost, then the
!       tie-breaking shall be broken as follows:
! 
!          - if at least one of the candidate routes was advertised by the
!          BGP speaker in a neighboring autonomous system, select the
!          route that was advertised by the BGP speaker in a neighboring
!          autonomous system whose BGP Identifier has the lowest value
!          among all other BGP speakers in neighboring autonomous systems;
! 
!          - otherwise, select the route that was advertised by the BGP
!          speaker whose BGP Identifier has the lowest value.

  9.1.3   Phase 3: Route Dissemination
--- 2437,2443 ----
  INTERNET DRAFT                                               August 1996

!    RIB-In.

  9.1.3   Phase 3: Route Dissemination
***************
*** 2425,2451 ****
     the less specific route.
  
     If a BGP speaker receives overlapping routes, the Decision Process
!    shall take into account the semantics of the overlapping routes. In
!    particular, if a BGP speaker accepts the less specific route while
!    rejecting the more specific route from the same peer, then the
!    destinations represented by the overlap may not forward along the ASs
!    listed in the AS_PATH attribute of that route. Therefore, a BGP
!    speaker has the following choices:
! 
!       a)   Install both the less and the more specific routes
! 
!       b)   Install the more specific route only
! 
!       c)   Install the non-overlapping part of the less specific
!                  route only (that implies de-aggregation)
! 
!       d)   Aggregate the two routes and install the aggregated route
! 
!       e)   Install the less specific route only
! 
!       f)   Install neither route
  
!    If a BGP speaker chooses e), then it should add ATOMIC_AGGREGATE
     attribute to the route. A route that carries ATOMIC_AGGREGATE
     attribute can not be de-aggregated. That is, the NLRI of this route
  
--- 2543,2554 ----
     the less specific route.
  
     If a BGP speaker receives overlapping routes, the Decision Process
!    shall consider both routes based on configured acceptance policy.
!    If both are accepted the Decision Process will install both the
!    less and the more specific routes or aggregate the two routes and
!    install the aggregated route.
  
!    If a BGP speaker chooses to aggregate, then it should add ATOMIC_AGGREGATE
     attribute to the route. A route that carries ATOMIC_AGGREGATE
     attribute can not be de-aggregated. That is, the NLRI of this route
  
***************
*** 2462,2470 ****
  
     can not be made more specific.  Forwarding along such a route does
     not guarantee that IP packets will actually traverse only ASs listed
!    in the AS_PATH attribute of the route.  If a BGP speaker chooses a),
!    it must not advertise the more general route without the more
!    specific route.

  9.2 Update-Send Process
--- 2565,2573 ----
  
     can not be made more specific.  Forwarding along such a route does
     not guarantee that IP packets will actually traverse only ASs listed
!    in the AS_PATH attribute of the route.  If a BGP speaker chooses to
!    install both routes it must not advertise the more general route
!    without the more specific route.

  9.2 Update-Send Process
***************
*** 2500,2531 ****
     When a BGP speaker receives a new route from a BGP speaker in a
     neighboring autonomous system, it shall advertise that route to all
     other BGP speakers in its autonomous system by means of an UPDATE
!    message if any of the following conditions occur:
! 
!       1) the degree of preference assigned to the newly received route
!       by the local BGP speaker is higher than the degree of preference
!       that the local speaker has assigned to other routes that have been
!       received from BGP speakers in neighboring autonomous systems, or
! 
!       2) there are no other routes that have been received from BGP
! 
! 
! 
! Expiration Date February 1996                                  [Page 42]
! 
! 
! 
! 
! 
! INTERNET DRAFT                                               August 1996
! 
! 
!       speakers in neighboring autonomous systems, or
! 
!       3) the newly received route is selected as a result of breaking a
!       tie between several routes which have the highest degree of
!       preference, and the same destination (the tie-breaking procedure
!       is specified in 9.2.1.1).
  
     When a BGP speaker receives an UPDATE message with a non-empty
     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
--- 2603,2610 ----
     When a BGP speaker receives a new route from a BGP speaker in a
     neighboring autonomous system, it shall advertise that route to all
     other BGP speakers in its autonomous system by means of an UPDATE
!    message if this route has become the best route installed in the
!    Local-Rib according to the route selection rules in 9.1.2.
  
     When a BGP speaker receives an UPDATE message with a non-empty
     WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
***************
*** 2554,2598 ****
     All feasible routes which are advertised shall be placed in the
     appropriate Adj-RIBs-Out, and all unfeasible routes which are
     advertised shall be removed from the Adj-RIBs-Out.
- 
- 
- 9.2.1.1 Breaking Ties (Internal Updates)
- 
- 
-    If a local BGP speaker has connections to several BGP speakers in
-    neighboring autonomous systems, there will be multiple Adj-RIBs-In
-    associated with these peers. These Adj-RIBs-In might contain several
-    equally preferable routes to the same destination, all of which were
-    advertised by BGP speakers located in neighboring autonomous systems.
-    The local BGP speaker shall select one of these routes according to
-    the following rules:
- 
-       a) If the candidate routes differ only in their NEXT_HOP and
- 
- 
- 
- Expiration Date February 1996                                  [Page 43]
- 
- 
- 
- 
- 
- INTERNET DRAFT                                               August 1996
- 
- 
-       MULTI_EXIT_DISC attributes, and the local system is configured to
-       take into account the MULTI_EXIT_DISC attribute, select the route
-       that has the lowest value of the MULTI_EXIT_DISC attribute. A
-       route with the MULTI_EXIT_DISC attribute shall be preferred to a
-       route without the MULTI_EXIT_DISC attribute.
- 
-       b) If the local system can ascertain the cost of a path to the
-       entity depicted by the NEXT_HOP attribute of the candidate route,
-       select the route with the lowest cost.
- 
-       c) In all other cases, select the route that was advertised by the
-       BGP speaker whose BGP Identifier has the lowest value.
- 

  9.2.2 External Updates
--- 2633,2638 ----
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: DPA replacement?
Date: Fri, 13 Sep 1996 19:16:53 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

John,

I finally got around to reading this.  This would be useful for a dual
homed site with an absolute preference for one of the connections.  I
think this is a rare case, so I'm proposing an alternative.

Unfortunately, more sites seem to be interested in pulling more than
one circuit and then getting some sort of load split across the two
providers.  This amounts to everyone else taking shortest path out.
Such a site would benefit from a cumulative metric so that the reverse
traffic took the same path.  If the cummulative metric was applied the
same in both directions traffic (and therefore load balance) would be
symetric.  Given enough range, the metric could be tweaked to balance
the load a bit better.

This brings us back to the issue of a globally recognized metric.
That always brings up the issue of whether to use bandwidth, delay,
percent loading, percent loss, weighted hop count, something else, or
some combination of factors, or just punt and use a arbitrarily
choosen unitless integer.  On this issue I suggest we declare the
metric to be "pain" and allow the value of "pain" and the rules for
accumulating pain to be defined according to TOS or QoS.  We also have
to keep in mind that this attribute needs to be relatively fixed.

The attribute should be optional and transitive.  Any router that
can't figure out what its loss rate or has not idea what the attribute
means or how to deal with a particular TOS or QOS should set the BGP
partial attribute flag.  If we set aside two attribute numbers, we can
pack complete attributes in one and partial in another if a router
knows how to deal with a subset of the TOS or QoS.  Treat a partial
BGP attribute to mean a really bad path.

Still with me?  Good.  For the default TOS/QoS, I suggest we go with a
weighted hop count with some guidelines on weighting because its
simple and anyone can do it.  I'd like to suggest that we attempt to
make measure of "pain" for the throughput TOS to be as close as we can
get to a measure of "pain" inflicted on a moderate window size TCP
preferably considering the most widely deployed TCP behaviors.  So how
much "pain" does a link or router contribute to a TCP flow?

This can't be twitchy.  For all of these metrics, lower "pain" values
are good, higher values are bad.  If the value changes the value
should tend toward the higher values in the range.  Anyone origination
or modifying a metric should dampen.  An EBGP peer that dampens should
latch at a higher value and ignore changes lowering the value only
after the value has been lower for a long while.

These values can be used to bias local-pref at so interior routers that
don't understand it don't form routing loops.

The whole idea of a globally significant metric has been one that BGP
has avoided and load sensitive routing even more so.  This has been
all with good reason.  Now that we've figured out that dampening is
not rocket science it may be time to revisit the idea of load
sensitive routing and consider making such emperically derived metrics
highly damped and globally significant.

btw- It would probably be a lot more productive to get the wording
right in the BGP4 draft so now I'll shut up and see about suggesting
some text.

Curtis

ps- further detail - how are TOS or QoS handled?  Here are some
suggestions.

Pain is inflicted to TCP in one of two ways.  Dropping a packet causes
a slow down.  Dropping multiple closely spaced packets (within the
same TCP window) can cause considerably more pain.  A good measure of
pain would then be a loss rate with a factor for biasing closely
spaced loss.  Having coded BGP route flap damping, we already know how
to efficiently do an exponential decay.  So I suggest the forwarding
engine exponentially decay a cummulative prior drop value over a short
time period (note: use time here) and add that to a loss rate metric
that is exponsitially decayed over a very long number of packets
(note: use packets here).  

If you don't want to do the first decay, you can just add a ceiling
value, approximating "don't know" to mean "closely bunched".  With
that assumption you just need to keep the packet number (from your
SNMP counter) and the prior metric and take action on a queue drop.
We you queue drop you need to decay the value (table lookup and
multiply), and add to it, then store the new packet number and value
pair.  If your forwarding engine can't deal with that treat queue drop
the way you deal with link loss.  For link loss use LQM stats if you
can get them and every so often decay the metric according to how many
packets went by and increment according to how many were dropped.  If
you can't get LQM stats use some other approximation of loss.  Use a
pessimistic estimate.  For example, for ATM if you can get cell loss
stats assume each cell represents a lost packet, for DS3 HSSI or DS1
assume each SES or UAS represents loss of all packets during that
second.  These values are link and router specific and would have to
be flooded in the IGP so the border router could make the computation
periodically.

For TCP, a loss rate of "all packets are lost" would be 2^32-1 and no
loss would be 0.  Loss is combined by multiplying two unsigned 32 bit
integers and shifting down the 64 bit unsigned integer by 32 bits.

Other QoS can be treated similarly.  Delay TOS is additive.  Bandwidth
TOS takes the lowest value of remaining unused bandwidth.  QoS metrics
could be defined as an ability to support various services and tspecs
and is left as an exercise for the reader (that means I don't think
its impoertant and don't care but see a need to accomodate the QoS
routing zealots.

------- Forwarded Message

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

------- End of Forwarded Message

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

To: "NITTMANN Michael (MSMail)" <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, Yakov Rekhter <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 12 Sep 1996 14:14:42 -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:
> >
> >What you are saying doesn't make sense to me.  MED is non-transitive.
> >It is optional for EBGP.  It MAY be passed from EBGP into IBGP.  It is
> >NEVER passed from IBGP to EBGP.  It is perfectly legitimate to not
> >pass a MED at all in either IBGP or EBGP.
> >
> >Curtis
> 
> MED should be transitive and mandatory on all ebgp connections; doesn't look 
> so difficult to me.

Transitive is used in BGP to mean continuously passed from one AS to
another, usch as an ORIGIN or AGGREGATOR.  MED is not transitive.

> BTW, if I understand this right, and I always skipped over that part because 
> it is not relevant for a BGP state machine:
> 
> these 4 bits, what's the purpose at all? Are the property bits for 
> attributes in fact part of the transmitted protocol message (transitive, 
> etc....)?
> 
> Any real use transmitting protocol definition elements in run time PEs? 

The two bits are well-known/optional and well
transitive/non-transitive.  If you don't know what a "well known"
attribute means you have a protocol incompatibility.  If you don't
know what a new optional transitive attribute means you pass it on.
If it is non-transitive, you drop it.

The other two are extended length partial/complete and extended
length.  The latter is needed to figure out how long the attribute is.
If you didn't understand an attribute and passed it along you set the
partial bit to warn the next guy.

> Mike

Please read the whole draft before commenting further.

Thanks,

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

To: [email-masked]
Subject: mandatory vs optional...
Date: Tue, 10 Sep 96 10:18:53 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

How about if we'll specify with each attribute whether this attribute is 
(a) mandatory in all cases, (b) mandatory in some case, but 
optional (or disallowed) in other cases, or (c) optional in all cases.

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

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: "John G. Scudder" <[email-masked]>, "NITTMANN Michael (MSMail)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Date: Mon, 9 Sep 1996 16:28:32 -0600
Encoding: 108 TEXT
Sender: [email-masked]

Transitive is wrong for MED, agree.
It should however be mandatory on ebgp connections. That implementations 
currently in the field will not be compliant with this is the way things 
work: standards develop, protocol implementations must follow.

With the 4 bits (only those that repeat protocol definitions): the protocol 
definition should be in the end engines. There is no need to duplicate that 
info on the network and really waste 4 bits for it. Looking at one message, 
4 bits seems few. Looking at all BGP exchanges in an AS, 4 bits less per 
route exchanged is a sizable quantity. 
Carrying an extended size flag is only useful if the same parameter exists 
in 'normal' and 'extended' size. 

What the use does as described:
only the transitive bit allows for a shade of compatibility, when an older 
implementation does not know a parameter, but it is flagged transitive: the 
implementation could treat this quantity as a blackbox and just pass it on 
together with the route. I doubt that this is really done anywhere, I 
suppose that most implementations will fail when they encounter an unknown 
attribute, and not pass it untreated on in case it were a transitive one.

The others just repeat what the programmers should have coded anyways, and 
what should be, e.g., in include files, to deliver faster and better error 
processing when parsing PEs. Since we change things, I would suggest not to 
carry superfluous information in an application layer protocol.

Carrying such info only causes more parsing overhead for unused exit 
conditions, and does also provide more possibilities for errors.

Protocol and engine relationships:

engine:                                                  protocol
  contains rules                      transmits context free data
  knows semantics                 between engines

I would agree for the necessity of a protocol to transport not only data and 
state information, but also rule and semantics information, when the engines 
are of some artificial intelligence type and can, e.g., detect a new 
attribute and insert it into the existing grammar database, including the 
rules (the 4 bits that describe the attribute as, e.g., transitive, 
sensitivity in different environments, etc.). But that's not the case here 
at all.

Summary: I would cut out the attribute description bits, leave the 
'extended' attribute in if it refers to attributes that exist in both 
formats, an extended and a 'normal' one, and I would make the exchange of 
MED mandatory on EBGP connections, with the provision that '-1' means 'none 
set', and not 'best of all', which in turn should be 0 (zero).

Mike

----------
From:  John G. Scudder[SMTP:[email-masked]]
Sent:  Monday, September 09, 1996 4:23 PM
To:  NITTMANN Michael (MSMail)
Cc:  [email-masked]
Subject:  RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]

[cc list trimmed]

At 12:43 PM -0600 9/9/96, NITTMANN Michael (MSMail) wrote:
>MED should be transitive and mandatory on all ebgp connections; doesn't 
look
>so difficult to me.

I disagree that MED should be transitive/mandatory.  That is, I agree with
Curtis.  The question is not whether it is difficult, but whether it's
useful/needed.  (Well, there's also a question of whether it's
interoperable with current implementations.)

>these 4 bits, what's the purpose at all? Are the property bits for
>attributes in fact part of the transmitted protocol message (transitive,
>etc....)?

Yes, every BGP Path Attribute has an 8-bit FLAGS field.  (Perhaps a
read-through of the RFC (or I-D) would be in order before continuing this
dialogue.)

>Any real use transmitting protocol definition elements in run time PEs?

The transitive bit tells a BGP implementation if it should propagate an
unrecognized attribute to external peers.  It's clearly useful at runtime.

The optional bit, if not set, tells a BGP implementation that there's a big
problem if it receives a non-optional attribute which it doesn't recognize.
(The need for this one is open to question, but it doesn't hurt.)

The partial bit tells a BGP implementation if the entire path supports the
given attribute.  I don't know if anyone uses this for anything, but one
can certainly see how it may be useful.

The extended length bit's utility should be obvious to the most casual 
reader.

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: Mon, 9 Sep 1996 17:22:53 -0400
To: "NITTMANN Michael (MSMail)" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Cc: [email-masked]
Sender: [email-masked]

[cc list trimmed]

At 12:43 PM -0600 9/9/96, NITTMANN Michael (MSMail) wrote:
>MED should be transitive and mandatory on all ebgp connections; doesn't look
>so difficult to me.

I disagree that MED should be transitive/mandatory.  That is, I agree with
Curtis.  The question is not whether it is difficult, but whether it's
useful/needed.  (Well, there's also a question of whether it's
interoperable with current implementations.)

>these 4 bits, what's the purpose at all? Are the property bits for
>attributes in fact part of the transmitted protocol message (transitive,
>etc....)?

Yes, every BGP Path Attribute has an 8-bit FLAGS field.  (Perhaps a
read-through of the RFC (or I-D) would be in order before continuing this
dialogue.)

>Any real use transmitting protocol definition elements in run time PEs?

The transitive bit tells a BGP implementation if it should propagate an
unrecognized attribute to external peers.  It's clearly useful at runtime.

The optional bit, if not set, tells a BGP implementation that there's a big
problem if it receives a non-optional attribute which it doesn't recognize.
(The need for this one is open to question, but it doesn't hurt.)

The partial bit tells a BGP implementation if the entire path supports the
given attribute.  I don't know if anyone uses this for anything, but one
can certainly see how it may be useful.

The extended length bit's utility should be obvious to the most casual reader.

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

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

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: Curtis Villamizar <[email-masked]>, "NITTMANN Michael (MSMail)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Mon, 9 Sep 1996 12:43:31 -0600
Encoding: 59 TEXT
Sender: [email-masked]

----------
From:  Curtis Villamizar[SMTP:[email-masked]]
Sent:  Monday, September 09, 1996 12:10 PM
To:  NITTMANN Michael (MSMail)
Cc:  John G. Scudder; Yakov Rekhter; [email-masked]
Subject:  Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 

>In message ><c=US%a=_%p=SHL%l=SHL/CANADAW/[email-masked]>, 
"NITT
>MANN Michael (MSMail)" writes:
>> I like the table, but would like to change a little detail:
>> 
>> 			   Type of Connection
>> 	Attribute	Internal	External
>> 	---------	--------	--------
>> 	ORIGIN		mandatory	mandatory
>> 	AS_PATH	mandatory	mandatory
>> 	NEXT_HOP	mandatory	mandatory
>> 	MED		optional		mandatory   <<<<<<<<
>> 	LOCAL_PREF	mandatory	forbidden
>> 	ATOMIC_AGG	*		*
>> 	AGGREGATOR	optional		optional
>> 
>> make the MED exchange for mutually set MEDs mandatory for the routes that 

>> are concerned, i.e. if I am in AS 1 and peer with AS 2, all AS 2 routes 
>> announced to me must carry the MED value assigned to them by AS 2 towards 

>> me, AS 1, or -1 if there is no MED set.
>> 
>> Mike
>
>Mike,
>
>What you are saying doesn't make sense to me.  MED is non-transitive.
>It is optional for EBGP.  It MAY be passed from EBGP into IBGP.  It is
>NEVER passed from IBGP to EBGP.  It is perfectly legitimate to not
>pass a MED at all in either IBGP or EBGP.
>
>Curtis

MED should be transitive and mandatory on all ebgp connections; doesn't look 
so difficult to me.

BTW, if I understand this right, and I always skipped over that part because 
it is not relevant for a BGP state machine:

these 4 bits, what's the purpose at all? Are the property bits for 
attributes in fact part of the transmitted protocol message (transitive, 
etc....)?

Any real use transmitting protocol definition elements in run time PEs? 

Mike

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

To: "NITTMANN Michael (MSMail)" <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>, Yakov Rekhter <[email-masked]>, "[email-masked]" <[email-masked]>
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Mon, 09 Sep 1996 13:09:58 -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:
> I like the table, but would like to change a little detail:
> 
> 			   Type of Connection
> 	Attribute	Internal	External
> 	---------	--------	--------
> 	ORIGIN		mandatory	mandatory
> 	AS_PATH	mandatory	mandatory
> 	NEXT_HOP	mandatory	mandatory
> 	MED		optional		mandatory   <<<<<<<<
> 	LOCAL_PREF	mandatory	forbidden
> 	ATOMIC_AGG	*		*
> 	AGGREGATOR	optional		optional
> 
> make the MED exchange for mutually set MEDs mandatory for the routes that 
> are concerned, i.e. if I am in AS 1 and peer with AS 2, all AS 2 routes 
> announced to me must carry the MED value assigned to them by AS 2 towards 
> me, AS 1, or -1 if there is no MED set.
> 
> Mike

Mike,

What you are saying doesn't make sense to me.  MED is non-transitive.
It is optional for EBGP.  It MAY be passed from EBGP into IBGP.  It is
NEVER passed from IBGP to EBGP.  It is perfectly legitimate to not
pass a MED at all in either IBGP or EBGP.

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

To: [email-masked]
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4 changes 
Date: Mon, 09 Sep 1996 13:04:12 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked] write
s:
> *** Resending note of 09/05/96 20:42
> Subject: Re: BGP-4 changes
> Curtis,
> 
> I agree that BGP-savvy gurus (like yourself) might find application for
> modification of MED values from neighbor ASs, so the "MAY" keyword in the
> current proposed text is OK with me.  Flexibility can be rewarding in
> unintended ways...
> 
> But we could solve the problem that you describe below by other means:
> (1) by lowering your LOCAL_PREF value for routes using the hot link(s),

Then you are back to hand configuring the load balance on a per prefix
basis.  You could look at what the MED values are and then go write
the config such that the ones that were closest to a tie between the
hot spot anbd some other point now have a lower local-pref.  In fact
thats sort of what NSFNET did by looking at the IGP costs themselves
before MED was invented.  Its a step backwards though.

> or (2) getting the neighbor AS to increase the MED values that it sends
> to you.  Neither of these methods requires knowing the semantics of
> metrics of neighboring ASs, nor modification of received MED values.

This is not quite so easy if there are multiple connections to the
peer router on their side and their router also serves some transit
within their AS.  Increasing the IGP costs would affect the relative
costs within their network.  What we would in affect be doing by
incrementing their MED is in effect adding a non-zero cost
link between their EBGP peer and ours.

> -- Richard Woundy, IBM
> 
> >I could see doing this if you are in agreement with whoever you are
> >sending MED about what the MEDs mean.  For example, some big customer
> >with more than one attachment might twiddle their OSPF metrics to get
> >traffic tuned sort of right.  If one of the provider/customer
> >attachments or provider links near it were running a bit hot and there
> >was agreement to do so, the MEDs at one attachment point might be
> >bumped up.  This could also apply to providers with multiple
> >interconnections who are willing to shuffle a bit of traffic from one
> >place to another to give both provider's customers better service.
> >This sort of cooperation is definitely not unheard of.

If you think of this as adding non-zero cost to the link between the
EBGP peers, then this is not just useful, but fits well into the
architecture as long as the immeidate peers (the pair of AS) agree on
the meaning of the metric passed by MED.

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

From: [email-masked]
Date: Fri, 06 Sep 96 12:26:25 EDT
To: [email-masked], [email-masked]
Subject: [[email-masked]: Re: [[email-masked]: Re: BGP4 stuff: Local Prefe
Sender: [email-masked]

*** Resending note of 09/06/96 11:12
Subject: Local Preference response
Cristina,

With respect to what local preference calculation should be used:

> The exact nature of this policy information and the computation
> involved is a local matter.

The implementations with which I am most familiar allow the router
operator to assign a fixed LOCAL_PREF value to BGP routes that match a
particular policy filter. These implementations (Cisco and gated) add an
explicit AS path length comparison step, because it is hard to
incorporate the AS path length into policy filters with static
LOCAL_PREF mappings, and minimizing AS path length is usually considered
to be desirable.

A notable exception is the Bay Networks implementation, that scales
LOCAL_PREF values according to AS path length and ORIGIN by default.

In my Simple LOcal Preference (SLOP) scheme, one can choosing the
relative priority of AS path length and ORIGIN, and there are explicit
details on how to change "SLOP factors" and such, to customize the route
selection (obviously, I'm biased). I would loosen its language to allow
options for vendor differentiation, based on comments from Dimitry and
Curtis -- allow AS_SETs to be counted as a single AS in the AS path
length, allow weights to be assigned to individual ASs, treat EGP and
Incomplete ORIGINs as identical, etc.

Any combination of the above local preference schemes in a single AS may
not be ideal, but it would produce loop-free BGP routing (so long as
there were no additional comparison steps -- such as AS path length --
which unfortunately are common in today's router implementations).

I would like to see a flexible local preference computation, such as
SLOP, included in as many implementations as possible. Why? I would like
ISPs to have more control of their BGP path selection priorities, rather
than their router vendors (through hard-coded defaults and the like)...

-- Richard Woundy, IBM

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

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "John G. Scudder" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Date: Fri, 6 Sep 1996 08:46:21 -0600
Encoding: 59 TEXT
Sender: [email-masked]

I would not even think of a bit for discretionary since it is not necessary. 
Basic protocol design: optional parameters may be ignored, ignoring optional 
parameters may not cause the emitting system to fail.

Mike

----------
From:  John G. Scudder[SMTP:[email-masked]]
Sent:  Donnerstag, 5. September 1996 18:04
To:  [email-masked]
Cc:  Yakov Rekhter; [email-masked]
Subject:  Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]

At 6:27 PM -0400 9/5/96, Curtis Villamizar wrote:
>It's interesting that we came up with similar suggestions, both
>involving defining mandatory and discretionary separately.
>
>Unfortunately we're stuck with these two bit in the attribute,
>well-known/optional, and mandatory/discretionary.  However we
>wordsmith this we want to end up with the same value in the two bits
>so we don't affect interoperability.

I don't follow.  There are just four flag bits:

Bit 0:  Optional/Well-Known
Bit 1:  Transitive/Non-Transitive
Bit 2:  Partial/(not)
Bit 3:  Extended Length/(not)

(Note that the def'n of bit 1 says "For well-known attributes, the
Transitive bit must be set to 1."  But, LOCAL_PREF is both well-known (per
the RFC) and clearly not transitive.  So I think that the quoted sentence
should be deleted.)

There isn't a flag for mandatory/discretionary (not even sort-of), so I'm
not worried about changing (or deleting) the term.

I think that the bits do not in fact say anything about whether an
attribute is mandatory or not.  Well-known I take to mean whether the
attribute is required to be supported.  Transitive is what it says.

So I think that textual changes can fix this problem.

By the way, the path attribute def'ns in 4.3 also cunningly don't mention
whether they are transitive or not (I guess it is supposed to be
"obvious").

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

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

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: "John G. Scudder" <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Date: Fri, 6 Sep 1996 08:38:13 -0600
Encoding: 125 TEXT
Sender: [email-masked]

I like the table, but would like to change a little detail:

			   Type of Connection
	Attribute	Internal	External
	---------	--------	--------
	ORIGIN		mandatory	mandatory
	AS_PATH	mandatory	mandatory
	NEXT_HOP	mandatory	mandatory
	MED		optional		mandatory   <<<<<<<<
	LOCAL_PREF	mandatory	forbidden
	ATOMIC_AGG	*		*
	AGGREGATOR	optional		optional

make the MED exchange for mutually set MEDs mandatory for the routes that 
are concerned, i.e. if I am in AS 1 and peer with AS 2, all AS 2 routes 
announced to me must carry the MED value assigned to them by AS 2 towards 
me, AS 1, or -1 if there is no MED set.

Mike

----------
From:  John G. Scudder[SMTP:[email-masked]]
Sent:  Donnerstag, 5. September 1996 15:08
To:  Yakov Rekhter
Cc:  [email-masked]
Subject:  Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]

At 12:40 PM -0700 9/5/96, Yakov Rekhter wrote:
>John,
>
>> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.
>
>"Mandatory" means that it *always* has to be present. LOCAL_PREF is not
>carried between external peers - just among the internal peers.
>
>> [Other than the text being just plain wrong, the other possibility is 
that
>> "discretionary" is being used to mean something like "this is only
>> mandatory in some cases".  This is a terrible misuse of the language if
>> true, and should still be fixed, if necessary by inventing some new term
>> like "well-known sometimes-mandatory" or something.  (Note that the RFC
>> nowhere defines "discretionary" so we are left with the dictionary
>> definition, e.g. "left to discretion: exercised at one's own 
discretion".)]
>
>Suggestions for better terminology area always appreciated (especially
>if accompanied by a "rough consensus").
>
>Yakov.

Well, we have ample evidence that the current terminology doesn't work, so
here are some options:

First option -- introduce a new category, "well-known
circumstantial-mandatory."  The (obvious) description is that
"circumstantial-mandatory" may be required in some circumstances (and
forbidden in others).

The real problem is in trying to use excessively terse language to capture
a relatively involved concept.  I would be OK with just getting rid of all
this terminology and having a table instead (second option):

			   Type of Connection
	Attribute	Internal	External
	---------	--------	--------
	ORIGIN		mandatory	mandatory
	AS_PATH		mandatory	mandatory
	NEXT_HOP	mandatory	mandatory
	MED		optional	optional
	LOCAL_PREF	mandatory	forbidden
	ATOMIC_AGG	*		*
	AGGREGATOR	optional	optional

[*] ATOMIC_AGGREGATE is actually mandatory in some circumstances.  Even the
table doesn't capture this correctly.  It's mandatory if you have formed an
atomic aggregate (duh).

I would be happiest with getting rid of the deceptively simple descriptive
terms for LOCAL_PREF and ATOMIC_AGGREGATE and just explaining them in
English (third option):

         e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a non-negative integer.  It is mandatory on
            internal connections and forbidden on external connections.
            It is used by a BGP speaker to inform other BGP speakers in
            its own autonomous  system of the originating speaker's
            degree of preference for  an advertised route. Usage of this
            attribute is described in 5.1.5.

         f) ATOMIC_AGGREGATE (Type Code 6)

            ATOMIC_AGGREGATE is a well-known attribute of length 0.
            It is mandatory under certain circumstances,  described
            in 5.1.6.  It is used by a BGP speaker to inform other BGP
            speakers that the local system selected a less specific
            route without selecting a more specific route which is
            included in it. Usage of this attribute is described in
            5.1.6.

The other option (fourth) I can see is to include a description of
"discretionary":

	Note that the term "discretionary" may mean that the attribute
	is truly discretionary, i.e. that it may be sent or not sent
	at the discretion of the implementor (or user).  However, it
	may also mean that the attribute is mandatory under some
	circumstances and forbidden (or optional) under others.  Caveat
	emptor!

Obviously I don't like this option one bit.

Yours for telling it like it is,

--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: "NITTMANN Michael (MSMail)" <[email-masked]>
To: Curtis Villamizar <[email-masked]>, "John G. Scudder" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Fri, 6 Sep 1996 08:41:28 -0600
Encoding: 55 TEXT
Sender: [email-masked]

For that one, how about making implementors always set a localpref, but the 
default value in the middle of the value range. That's then equal for all so 
it has no effect within the IBGP realm.

Mike

----------
From:  Curtis Villamizar[SMTP:[email-masked]]
Sent:  Donnerstag, 5. September 1996 16:58
To:  John G. Scudder
Cc:  [email-masked]; [email-masked]; [email-masked]; 
[email-masked]
Subject:  Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 

In message <v03007823ae54d65762ae@[152.160.213.42]>, "John G. Scudder" 
writes:
> At 2:55 PM -0400 9/5/96, Curtis Villamizar wrote:
> >The preconfigured policy information is then put into the LOCAL_PREF
> >attribute.  This text should be more clear.  It seems that everyone
> >who has already implemented BGP4 agrees on the interpretation but the
> >text was never very clear.
> >
> >Don't send LOCAL_PREF to an EBGP peer.  Don't accept LOCAL_PREF from
> >an EBGP peer.  Decide what your preference is based on configured
> >policy.  Then put that into LOCAL_PREF.  Then use LOCAL_PREF as the
> >first value in a comparison.
> 
> Speaking of things which aren't clear, the RFC (and draft) list LOCAL_PREF
> as a "discretionary" attribute.  It is of course *not* discretionary. 
 It's
> required on IBGP connections and forbidden on EBGP.  The implementor (or
> operator) has no discretion as to whether LOCAL_PREF is sent.
> 
> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.
> 
> [Other than the text being just plain wrong, the other possibility is that
> "discretionary" is being used to mean something like "this is only
> mandatory in some cases".  This is a terrible misuse of the language if
> true, and should still be fixed, if necessary by inventing some new term
> like "well-known sometimes-mandatory" or something.  (Note that the RFC
> nowhere defines "discretionary" so we are left with the dictionary
> definition, e.g. "left to discretion: exercised at one's own discretion".)  
]
> 
> --John

Let's just make it mandatory.  When is it not mandatory?  When there
is only one router in an AS?  Otherwise we have to define how you
compare no LOCAL_PREF to a route with LOCAL_PREF.

Curtis

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

Date: Fri, 6 Sep 1996 11:14:58 -0400
From: Cristina Radulescu-Banu <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: [[email-masked]: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]]
Reply-To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
Sender: [email-masked]

------- Start of forwarded message -------
Return-Path: <[email-masked]>
To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
In-Reply-To: Your message of "Thu, 05 Sep 1996 13:04:58 EDT."
             <[email-masked]> 
Date: Thu, 05 Sep 1996 14:55:28 -0400
From: Curtis Villamizar <[email-masked]>

In his  message Thu, 05 Sep 1996 14:55:28 -0400, Curtis Villamizar writes:

In message <[email-masked]>, Cristina Radulescu-Banu writ
es:
> ------- Start of forwarded message -------
> Return-Path: <[email-masked]>
> To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
> Cc: [email-masked], [email-masked], [email-masked]
> Reply-To: [email-masked]
> Subject: Re: BGP4 stuff: Local Preference Computation 
> In-Reply-To: Your message of "Wed, 04 Sep 1996 15:34:29 EDT."
>              <[email-masked]> 
> Date: Wed, 04 Sep 1996 18:54:46 -0400
> From: Curtis Villamizar <[email-masked]>
> 
> 	In message received from Curtis Vilamizar, he wrote:
> 
> In message <[email-masked]>, Cristina Radulescu-B
> an
> u writes:
> > 
> > 	I have some problems in implementing BGP4, and if you could
> > clarify some of them , this would be great.
> > 
> > 	I understood that LOCAL_PREF is used as degree of preference only for
> > the BGP4 speakers located in the SAME Autonomous System. The Degree of
> 
> That's MED.  LOCAL_PREF has always been compared regardless of AS.
> 
> 	At least from what I read, it doesn't seem like that.
> 	I will quote from RFC 1771:
> 
>          e) LOCAL_PREF (Type Code 5):
> 
>             LOCAL_PREF is a well-known discretionary attribute that is a
>             four octet non-negative integer. It is used by a BGP speaker
>             to inform other BGP speakers in its own autonomous system of
>                                                ~~~~~~~~~~~~~~~~~~~~~~~
>             the originating speaker's degree of preference for an
>             advertised route. Usage of this attribute is described in
>             5.1.5.
> 
> and:
> 
> 	5.1.5   LOCAL_PREF
> 
>    LOCAL_PREF is a well-known discretionary attribute that shall be
>    included in all UPDATE messages that a given BGP speaker sends to the
>    other BGP speakers located in its own autonomous system. A BGP
>                                  ~~~~~~~~~~~~~~~~~~~~~~~~~
>    speaker shall calculate the degree of preference for each external
>    route and include the degree of preference when advertising a route
>    to its internal peers. The higher degree of preference should be
>    preferred. A BGP speaker shall use the degree of preference learned
>    via LOCAL_PREF in its decision process (see section 9.1.1).
> 
>    A BGP speaker shall not include this attribute in UPDATE messages
>    that it sends to BGP speakers located in a neighboring autonomous
>    system. If it is contained in an UPDATE message that is received
>    from a BGP speaker which is not located in the same autonomous
>                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            
>         
>    system as the receiving speaker, then this attribute shall be
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    ignored by the receiving speaker.
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This means don't send LOCAL_PREF to an EBGP peer.

> 9.1.1 Phase 1: Calculation of Degree of Preference
>  
> 	   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. If
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    the route is learned from a BGP speaker in a neighboring autonomous
> 
>    system, then the degree of preference shall be computed based on
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    preconfigured policy information.  The exact nature of this policy
>    information and the computation involved is a local matter.  The
>    local speaker shall then run the internal update process of 9.2.1 to
>    select and advertise the most preferable route.

The preconfigured policy information is then put into the LOCAL_PREF
attribute.  This text should be more clear.  It seems that everyone
who has already implemented BGP4 agrees on the interpretation but the
text was never very clear.

Don't send LOCAL_PREF to an EBGP peer.  Don't accept LOCAL_PREF from
an EBGP peer.  Decide what your preference is based on configured
policy.  Then put that into LOCAL_PREF.  Then use LOCAL_PREF as the
first value in a comparison.

This is exactly what I have done; (it's pretty clear in RFC; the
confusing thing was the message about  Local Preference Computation,
which I think should be the Degree of Preference Computation )

	BTW, one of the device I tested doesn't accept ANY Update
packet if the LOCAL_PREF is not defined, even if the 2 peers are in
different AS . So, for them this LOCAL_PREF is mandatory. I think 
a good thing which should appear in RFC is  the one "John
G. Scudder" pointed out, that the LOCAL_PREF should be FORBIDDEN on 
external links. 

Curtis

------- End of forwarded message -------

-- 
			Cristina

...............................................................................
Cristina Radulescu-Banu : Midnight Networks 200 Fifth Avenue Waltham MA 02154
[email-masked]  : Vox 617/890-1001 Fax 0028 The Best in Network Software
	
   I'm trying so much to communicate my thoughts by speaking that I
		     can't move my arms anymore.

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

From: [email-masked]
Date: Fri, 06 Sep 96 10:29:45 EDT
To: [email-masked], [email-masked]
Subject: Re: BGP-4 changes
Sender: [email-masked]

*** Resending note of 09/05/96 20:42
Subject: Re: BGP-4 changes
Curtis,

I agree that BGP-savvy gurus (like yourself) might find application for
modification of MED values from neighbor ASs, so the "MAY" keyword in the
current proposed text is OK with me.  Flexibility can be rewarding in
unintended ways...

But we could solve the problem that you describe below by other means:
(1) by lowering your LOCAL_PREF value for routes using the hot link(s),
or (2) getting the neighbor AS to increase the MED values that it sends
to you.  Neither of these methods requires knowing the semantics of
metrics of neighboring ASs, nor modification of received MED values.

-- Richard Woundy, IBM

>I could see doing this if you are in agreement with whoever you are
>sending MED about what the MEDs mean.  For example, some big customer
>with more than one attachment might twiddle their OSPF metrics to get
>traffic tuned sort of right.  If one of the provider/customer
>attachments or provider links near it were running a bit hot and there
>was agreement to do so, the MEDs at one attachment point might be
>bumped up.  This could also apply to providers with multiple
>interconnections who are willing to shuffle a bit of traffic from one
>place to another to give both provider's customers better service.
>This sort of cooperation is definitely not unheard of.

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

To: [email-masked]
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4 changes 
Date: Thu, 05 Sep 1996 20:41:56 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked] write
s:
> *** Resending note of 09/04/96 11:14
> Subject: RE: BGP-4 changes
> 
> >So you want to (e.g.) be able to say something like "For all MAE-E routes,
> >increment MED by 100"?
> 
> >I think that the proposed text already allows this, and the details of
> >how/when/if to do it should be left to implementors.
> 
> >But, I kinda agree with Rich that localpref and policy may be a cleaner way
> >to reflect stuff like this.
> 
> Thanks, John.
> 
> I would be worried about what the value "100" means, with respect
> to the metrics of a neighboring AS.  Does it mean two DS-3 hops
> or one hundred hops? and what if their link metrics change? etc.
> 
> You can safely drop MED attributes, but you modify MED values
> at your own risk...
> 
> -- Richard Woundy, IBM

I could see doing this if you are in agreement with whoever you are
sending MED about what the MEDs mean.  For example, some big customer
with more than one attachment might twiddle their OSPF metrics to get
traffic tuned sort of right.  If one of the provider/customer
attachments or provider links near it were running a bit hot and there
was agreement to do so, the MEDs at one attachment point might be
bumped up.  This could also apply to providers with multiple
interconnections who are willing to shuffle a bit of traffic from one
place to another to give both provider's customers better service.
This sort of cooperation is definitely not unheard of.

Curtis

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

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 05 Sep 1996 20:31:47 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v03007834ae550683b8a7@[152.160.213.42]>, "John G. Scudder" writes:
> At 6:27 PM -0400 9/5/96, Curtis Villamizar wrote:
> >It's interesting that we came up with similar suggestions, both
> >involving defining mandatory and discretionary separately.
> >
> >Unfortunately we're stuck with these two bit in the attribute,
> >well-known/optional, and mandatory/discretionary.  However we
> >wordsmith this we want to end up with the same value in the two bits
> >so we don't affect interoperability.
> 
> I don't follow.  There are just four flag bits:
> 
> Bit 0:  Optional/Well-Known
> Bit 1:  Transitive/Non-Transitive
> Bit 2:  Partial/(not)
> Bit 3:  Extended Length/(not)

Never mind.  I was thinking of Optional/Well-Known
Transitive/Non-Transitive and confusing this with
mandatory/discretionary since I was typing from memory of the spec.

> (Note that the def'n of bit 1 says "For well-known attributes, the
> Transitive bit must be set to 1."  But, LOCAL_PREF is both well-known (per
> the RFC) and clearly not transitive.  So I think that the quoted sentence
> should be deleted.)
> 
> There isn't a flag for mandatory/discretionary (not even sort-of), so I'm
> not worried about changing (or deleting) the term.

My mistake.

Thanks John.  Next time I'll check the spec before sending.

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

To: "John G. Scudder" <[email-masked]>
Cc: Paul Ferguson <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 05 Sep 1996 20:00:45 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v03007833ae55054e6fef@[152.160.213.42]>, "John G. Scudder" writes:
> At 6:28 PM -0400 9/5/96, Paul Ferguson wrote:
> >I personally like the elaboration of iBGP and eBGP implementations here;
> >the verbiage Curtis suggest makes it much less confusing.
> 
> Again, this is good for LOCAL_PREF but doesn't cover ATOMIC_AGGREGATE since
> that depends on aggregation, not I/EBGP.

So fix that too.  We then have:

	mandatory/discresional/conditional/disallowed
	IBGP/EBGP

And the mandatory bit is set in the attribute header iff something is
mandatory for both IBGP and EBGP for compatible bit setting with
existing implementations.

Sound OK?  Are we headed toward consensus?  :-)

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

Date: Thu, 5 Sep 1996 19:03:40 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

At 6:27 PM -0400 9/5/96, Curtis Villamizar wrote:
>It's interesting that we came up with similar suggestions, both
>involving defining mandatory and discretionary separately.
>
>Unfortunately we're stuck with these two bit in the attribute,
>well-known/optional, and mandatory/discretionary.  However we
>wordsmith this we want to end up with the same value in the two bits
>so we don't affect interoperability.

I don't follow.  There are just four flag bits:

Bit 0:  Optional/Well-Known
Bit 1:  Transitive/Non-Transitive
Bit 2:  Partial/(not)
Bit 3:  Extended Length/(not)

(Note that the def'n of bit 1 says "For well-known attributes, the
Transitive bit must be set to 1."  But, LOCAL_PREF is both well-known (per
the RFC) and clearly not transitive.  So I think that the quoted sentence
should be deleted.)

There isn't a flag for mandatory/discretionary (not even sort-of), so I'm
not worried about changing (or deleting) the term.

I think that the bits do not in fact say anything about whether an
attribute is mandatory or not.  Well-known I take to mean whether the
attribute is required to be supported.  Transitive is what it says.

So I think that textual changes can fix this problem.

By the way, the path attribute def'ns in 4.3 also cunningly don't mention
whether they are transitive or not (I guess it is supposed to be
"obvious").

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: Thu, 5 Sep 1996 18:32:44 -0400
To: Paul Ferguson <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference   Computation]
Cc: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

At 6:28 PM -0400 9/5/96, Paul Ferguson wrote:
>I personally like the elaboration of iBGP and eBGP implementations here;
>the verbiage Curtis suggest makes it much less confusing.

Again, this is good for LOCAL_PREF but doesn't cover ATOMIC_AGGREGATE since
that depends on aggregation, not I/EBGP.

Hmm, I seem to be repeating myself.

Hmm, I seem to be repeating myself.

--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]
Date: Thu, 05 Sep 96 19:03:06 EDT
To: [email-masked], [email-masked]
Subject: RE: BGP-4 changes
Sender: [email-masked]

*** Resending note of 09/04/96 11:14
Subject: RE: BGP-4 changes

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

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

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

Thanks, John.

I would be worried about what the value "100" means, with respect
to the metrics of a neighboring AS.  Does it mean two DS-3 hops
or one hundred hops? and what if their link metrics change? etc.

You can safely drop MED attributes, but you modify MED values
at your own risk...

-- Richard Woundy, IBM

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

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: "John G. Scudder" <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 5 Sep 1996 16:31:19 -0600
Encoding: 50 TEXT
Sender: [email-masked]

Looks to me as if everybody agrees: I would just generalize the probably 
narrow meaning of 'mandatory': not only in exchanged parameters/variables, 
but also in IBGP, say 'internal' variables and paramers.

Or let's do classes: mandatory external, mandatory internal.

I would not need it, since localpref is by def internal, and should be 
mandatory in all implementations to assure vendor compatibility *within* an 
AS (well, now I wait for some C word people to say this is not necessary 
since router names start with C anyways  ;=]  ).

Since we all agree that localpref is not exchanged across AS boundaries, a 
tweaking based on a purely internal parameter cannot avoid loops, since the 
AS partner has no clue. It is a reactive repair.

MED, however, is exchanged or should be mandatory external, and here we have 
then an automatic adaptation mechanism that could recognize conflicting MED 
and either adjust, or override and message.

Mike

----------
From:  Yakov Rekhter[SMTP:[email-masked]]
Sent:  Donnerstag, 5. September 1996 14:41
To:  John G. Scudder
Cc:  [email-masked]
Subject:  Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 

John,

> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.

"Mandatory" means that it *always* has to be present. LOCAL_PREF is not
carried between external peers - just among the internal peers.

> [Other than the text being just plain wrong, the other possibility is that
> "discretionary" is being used to mean something like "this is only
> mandatory in some cases".  This is a terrible misuse of the language if
> true, and should still be fixed, if necessary by inventing some new term
> like "well-known sometimes-mandatory" or something.  (Note that the RFC
> nowhere defines "discretionary" so we are left with the dictionary
> definition, e.g. "left to discretion: exercised at one's own 
discretion".)]

Suggestions for better terminology area always appreciated (especially
if accompanied by a "rough consensus").

Yakov.

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

Date: Thu, 05 Sep 1996 18:28:55 -0400
To: [email-masked]
From: Paul Ferguson <[email-masked]>
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Cc: Yakov Rekhter <[email-masked]>, "John G. Scudder" <[email-masked]>, [email-masked]
Sender: [email-masked]

I personally like the elaboration of iBGP and eBGP implementations here;
the verbiage Curtis suggest makes it much less confusing.

- paul

At 06:17 PM 9/5/96 -0400, Curtis Villamizar wrote:

>
>How about in the RFC instead of
>
>	mandatory	discretionary
>
>we specify
>
>	mandatory	discretionary	disallowed
>
>and list IBGP and EBGP separately.
>
>	  attribute	  IBGP				EBGP
>	LOCAL_PREF    well-known mandatory        disallowed
>	MED           well-known discretionary    well-known discretionary
>	...
>
>This affects a key attribute so we could set mandatory attribute bit
>iff it is mandatory for both IBGP and EBGP and not change the protocol
>any, just make the spec more clear.
>

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

To: "John G. Scudder" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 05 Sep 1996 18:27:50 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v03007829ae54ddc12183@[152.160.213.42]>, "John G. Scudder" writes:
> At 12:40 PM -0700 9/5/96, Yakov Rekhter wrote:
> >John,
> >
> >> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.
> >
> >"Mandatory" means that it *always* has to be present. LOCAL_PREF is not
> >carried between external peers - just among the internal peers.
> >
> >> [Other than the text being just plain wrong, the other possibility is that
> >> "discretionary" is being used to mean something like "this is only
> >> mandatory in some cases".  This is a terrible misuse of the language if
> >> true, and should still be fixed, if necessary by inventing some new term
> >> like "well-known sometimes-mandatory" or something.  (Note that the RFC
> >> nowhere defines "discretionary" so we are left with the dictionary
> >> definition, e.g. "left to discretion: exercised at one's own discretion".)
> ]
> >
> >Suggestions for better terminology area always appreciated (especially
> >if accompanied by a "rough consensus").
> >
> >Yakov.
> 
> Well, we have ample evidence that the current terminology doesn't work, so
> here are some options:
> 
First option -- introduce a new category, "well-known
> circumstantial-mandatory."  The (obvious) description is that
> "circumstantial-mandatory" may be required in some circumstances (and
> forbidden in others).
> 
> The real problem is in trying to use excessively terse language to capture
> a relatively involved concept.  I would be OK with just getting rid of all
> this terminology and having a table instead (second option):
> 
> 			   Type of Connection
> 	Attribute	Internal	External
> 	---------	--------	--------
> 	ORIGIN		mandatory	mandatory
> 	AS_PATH		mandatory	mandatory
> 	NEXT_HOP	mandatory	mandatory
> 	MED		optional	optional
> 	LOCAL_PREF	mandatory	forbidden
> 	ATOMIC_AGG	*		*
> 	AGGREGATOR	optional	optional
> 
> [*] ATOMIC_AGGREGATE is actually mandatory in some circumstances.  Even the
> table doesn't capture this correctly.  It's mandatory if you have formed an
> atomic aggregate (duh).
> 
> I would be happiest with getting rid of the deceptively simple descriptive
> terms for LOCAL_PREF and ATOMIC_AGGREGATE and just explaining them in
> English (third option):
> 
>          e) LOCAL_PREF (Type Code 5):
> 
>             LOCAL_PREF is a non-negative integer.  It is mandatory on
>             internal connections and forbidden on external connections.
>             It is used by a BGP speaker to inform other BGP speakers in
>             its own autonomous  system of the originating speaker's
>             degree of preference for  an advertised route. Usage of this
>             attribute is described in 5.1.5.
> 
>          f) ATOMIC_AGGREGATE (Type Code 6)
> 
>             ATOMIC_AGGREGATE is a well-known attribute of length 0.
>             It is mandatory under certain circumstances,  described
>             in 5.1.6.  It is used by a BGP speaker to inform other BGP
>             speakers that the local system selected a less specific
>             route without selecting a more specific route which is
>             included in it. Usage of this attribute is described in
>             5.1.6.
> 
> The other option (fourth) I can see is to include a description of
> "discretionary":
> 
> 	Note that the term "discretionary" may mean that the attribute
> 	is truly discretionary, i.e. that it may be sent or not sent
> 	at the discretion of the implementor (or user).  However, it
> 	may also mean that the attribute is mandatory under some
> 	circumstances and forbidden (or optional) under others.  Caveat
> 	emptor!
> 
> Obviously I don't like this option one bit.
> 
> Yours for telling it like it is,
> 
> --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

It's interesting that we came up with similar suggestions, both
involving defining mandatory and discretionary separately.

Unfortunately we're stuck with these two bit in the attribute,
well-known/optional, and mandatory/discretionary.  However we
wordsmith this we want to end up with the same value in the two bits
so we don't affect interoperability.

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

To: Yakov Rekhter <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 05 Sep 1996 18:17:51 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> John,
> 
> > This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.
> 
> "Mandatory" means that it *always* has to be present. LOCAL_PREF is not
> carried between external peers - just among the internal peers.

Good point.

> > [Other than the text being just plain wrong, the other possibility is that
> > "discretionary" is being used to mean something like "this is only
> > mandatory in some cases".  This is a terrible misuse of the language if
> > true, and should still be fixed, if necessary by inventing some new term
> > like "well-known sometimes-mandatory" or something.  (Note that the RFC
> > nowhere defines "discretionary" so we are left with the dictionary
> > definition, e.g. "left to discretion: exercised at one's own discretion".)]
> 
> Suggestions for better terminology area always appreciated (especially
> if accompanied by a "rough consensus").

How about in the RFC instead of

	mandatory	discretionary

we specify

	mandatory	discretionary	disallowed

and list IBGP and EBGP separately.

	  attribute	  IBGP				EBGP
	LOCAL_PREF    well-known mandatory        disallowed
	MED           well-known discretionary    well-known discretionary
	...

This affects a key attribute so we could set mandatory attribute bit
iff it is mandatory for both IBGP and EBGP and not change the protocol
any, just make the spec more clear.

> Yakov.

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

Date: Thu, 5 Sep 1996 18:00:11 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Cc: [email-masked], [email-masked] (Cristina Radelescu-Banu 617/890-1001), [email-masked], [email-masked]
Sender: [email-masked]

At 5:57 PM -0400 9/5/96, Curtis Villamizar wrote:
[re LOCAL_PREF]
>Let's just make it mandatory.  When is it not mandatory?

On all EBGP connections.  In fact, it's forbidden.

--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], [email-masked] (Cristina Radelescu-Banu 617/890-1001), [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 05 Sep 1996 17:57:34 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <v03007823ae54d65762ae@[152.160.213.42]>, "John G. Scudder" writes:
> At 2:55 PM -0400 9/5/96, Curtis Villamizar wrote:
> >The preconfigured policy information is then put into the LOCAL_PREF
> >attribute.  This text should be more clear.  It seems that everyone
> >who has already implemented BGP4 agrees on the interpretation but the
> >text was never very clear.
> >
> >Don't send LOCAL_PREF to an EBGP peer.  Don't accept LOCAL_PREF from
> >an EBGP peer.  Decide what your preference is based on configured
> >policy.  Then put that into LOCAL_PREF.  Then use LOCAL_PREF as the
> >first value in a comparison.
> 
> Speaking of things which aren't clear, the RFC (and draft) list LOCAL_PREF
> as a "discretionary" attribute.  It is of course *not* discretionary.  It's
> required on IBGP connections and forbidden on EBGP.  The implementor (or
> operator) has no discretion as to whether LOCAL_PREF is sent.
> 
> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.
> 
> [Other than the text being just plain wrong, the other possibility is that
> "discretionary" is being used to mean something like "this is only
> mandatory in some cases".  This is a terrible misuse of the language if
> true, and should still be fixed, if necessary by inventing some new term
> like "well-known sometimes-mandatory" or something.  (Note that the RFC
> nowhere defines "discretionary" so we are left with the dictionary
> definition, e.g. "left to discretion: exercised at one's own discretion".)]
> 
> --John

Let's just make it mandatory.  When is it not mandatory?  When there
is only one router in an AS?  Otherwise we have to define how you
compare no LOCAL_PREF to a route with LOCAL_PREF.

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

Date: Thu, 5 Sep 1996 17:31:26 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 5:27 PM -0400 9/5/96, [email-masked] wrote:
>How about "Well-known non-transitive" as a new path attribute
>category in section 5 for LOCAL_PREF?
>
>Well-known non-transitive attributes must be included in every
>UPDATE message sent to internal peers, but must not be included
>in any UPDATE message sent to peers in neighboring ASs.
>
>We'll need to fix the sentence in section 5 that states:
>   All well-known attributes must be passed along (after proper
>   updating, if necessary) to other BGP peers.
>(We obviously do not want to send LOCAL_PREFs to neighbor ASs.)
>Instead, we could say:
>   All well-known mandatory and discretionary attributes must be
>   passed along (after proper updating, if necessary) to other
>   BGP peers.

This is good for LOCAL_PREF but doesn't cover ATOMIC_AGGREGATE.

>I'm only afraid that this is bordering on the obvious...

Yes, but it's a spec, isn't it?  It should be obvious, and unambiguous.

--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]
Date: Thu, 05 Sep 96 17:27:03 EDT
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation
Sender: [email-masked]

*** Resending note of 09/05/96 15:47
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation
Yakov,

How about "Well-known non-transitive" as a new path attribute
category in section 5 for LOCAL_PREF?

Well-known non-transitive attributes must be included in every
UPDATE message sent to internal peers, but must not be included
in any UPDATE message sent to peers in neighboring ASs.

We'll need to fix the sentence in section 5 that states:
   All well-known attributes must be passed along (after proper
   updating, if necessary) to other BGP peers.
(We obviously do not want to send LOCAL_PREFs to neighbor ASs.)
Instead, we could say:
   All well-known mandatory and discretionary attributes must be
   passed along (after proper updating, if necessary) to other
   BGP peers.

I'm only afraid that this is bordering on the obvious...
-- Richard Woundy, IBM

>> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.

>"Mandatory" means that it *always* has to be present. LOCAL_PREF is not
>carried between external peers - just among the internal peers.

>> [Other than the text being just plain wrong, the other possibility is that
>> "discretionary" is being used to mean something like "this is only
>> mandatory in some cases".  This is a terrible misuse of the language
>> if true, and should still be fixed, if necessary by inventing some new term
>> like "well-known sometimes-mandatory" or something.  (Note that the
>> RFC nowhere defines "discretionary" so we are left with the dictionary
>> definition, e.g. "left to discretion: exercised at one's own discretion".)]

>Suggestions for better terminology area always appreciated (especially
>if accompanied by a "rough consensus").

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

Date: Thu, 5 Sep 1996 16:07:34 -0400
To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Cc: [email-masked]
Sender: [email-masked]

At 12:40 PM -0700 9/5/96, Yakov Rekhter wrote:
>John,
>
>> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.
>
>"Mandatory" means that it *always* has to be present. LOCAL_PREF is not
>carried between external peers - just among the internal peers.
>
>> [Other than the text being just plain wrong, the other possibility is that
>> "discretionary" is being used to mean something like "this is only
>> mandatory in some cases".  This is a terrible misuse of the language if
>> true, and should still be fixed, if necessary by inventing some new term
>> like "well-known sometimes-mandatory" or something.  (Note that the RFC
>> nowhere defines "discretionary" so we are left with the dictionary
>> definition, e.g. "left to discretion: exercised at one's own discretion".)]
>
>Suggestions for better terminology area always appreciated (especially
>if accompanied by a "rough consensus").
>
>Yakov.

Well, we have ample evidence that the current terminology doesn't work, so
here are some options:

First option -- introduce a new category, "well-known
circumstantial-mandatory."  The (obvious) description is that
"circumstantial-mandatory" may be required in some circumstances (and
forbidden in others).

The real problem is in trying to use excessively terse language to capture
a relatively involved concept.  I would be OK with just getting rid of all
this terminology and having a table instead (second option):

			   Type of Connection
	Attribute	Internal	External
	---------	--------	--------
	ORIGIN		mandatory	mandatory
	AS_PATH		mandatory	mandatory
	NEXT_HOP	mandatory	mandatory
	MED		optional	optional
	LOCAL_PREF	mandatory	forbidden
	ATOMIC_AGG	*		*
	AGGREGATOR	optional	optional

[*] ATOMIC_AGGREGATE is actually mandatory in some circumstances.  Even the
table doesn't capture this correctly.  It's mandatory if you have formed an
atomic aggregate (duh).

I would be happiest with getting rid of the deceptively simple descriptive
terms for LOCAL_PREF and ATOMIC_AGGREGATE and just explaining them in
English (third option):

         e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a non-negative integer.  It is mandatory on
            internal connections and forbidden on external connections.
            It is used by a BGP speaker to inform other BGP speakers in
            its own autonomous  system of the originating speaker's
            degree of preference for  an advertised route. Usage of this
            attribute is described in 5.1.5.

         f) ATOMIC_AGGREGATE (Type Code 6)

            ATOMIC_AGGREGATE is a well-known attribute of length 0.
            It is mandatory under certain circumstances,  described
            in 5.1.6.  It is used by a BGP speaker to inform other BGP
            speakers that the local system selected a less specific
            route without selecting a more specific route which is
            included in it. Usage of this attribute is described in
            5.1.6.

The other option (fourth) I can see is to include a description of
"discretionary":

	Note that the term "discretionary" may mean that the attribute
	is truly discretionary, i.e. that it may be sent or not sent
	at the discretion of the implementor (or user).  However, it
	may also mean that the attribute is mandatory under some
	circumstances and forbidden (or optional) under others.  Caveat
	emptor!

Obviously I don't like this option one bit.

Yours for telling it like it is,

--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]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 05 Sep 96 12:40:54 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,

> This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.

"Mandatory" means that it *always* has to be present. LOCAL_PREF is not
carried between external peers - just among the internal peers.

> [Other than the text being just plain wrong, the other possibility is that
> "discretionary" is being used to mean something like "this is only
> mandatory in some cases".  This is a terrible misuse of the language if
> true, and should still be fixed, if necessary by inventing some new term
> like "well-known sometimes-mandatory" or something.  (Note that the RFC
> nowhere defines "discretionary" so we are left with the dictionary
> definition, e.g. "left to discretion: exercised at one's own discretion".)]

Suggestions for better terminology area always appreciated (especially
if accompanied by a "rough consensus").

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

Date: Thu, 5 Sep 1996 15:25:49 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Cc: [email-masked] (Cristina Radelescu-Banu 617/890-1001), [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 2:55 PM -0400 9/5/96, Curtis Villamizar wrote:
>The preconfigured policy information is then put into the LOCAL_PREF
>attribute.  This text should be more clear.  It seems that everyone
>who has already implemented BGP4 agrees on the interpretation but the
>text was never very clear.
>
>Don't send LOCAL_PREF to an EBGP peer.  Don't accept LOCAL_PREF from
>an EBGP peer.  Decide what your preference is based on configured
>policy.  Then put that into LOCAL_PREF.  Then use LOCAL_PREF as the
>first value in a comparison.

Speaking of things which aren't clear, the RFC (and draft) list LOCAL_PREF
as a "discretionary" attribute.  It is of course *not* discretionary.  It's
required on IBGP connections and forbidden on EBGP.  The implementor (or
operator) has no discretion as to whether LOCAL_PREF is sent.

This should be fixed by reclassifying LOCAL_PREF as well-known mandatory.

[Other than the text being just plain wrong, the other possibility is that
"discretionary" is being used to mean something like "this is only
mandatory in some cases".  This is a terrible misuse of the language if
true, and should still be fixed, if necessary by inventing some new term
like "well-known sometimes-mandatory" or something.  (Note that the RFC
nowhere defines "discretionary" so we are left with the dictionary
definition, e.g. "left to discretion: exercised at one's own discretion".)]

--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: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: [[email-masked]: Re: BGP4 stuff: Local Preference Computation] 
Date: Thu, 05 Sep 1996 14:55:28 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Cristina Radulescu-Banu writ
es:
> ------- Start of forwarded message -------
> Return-Path: <[email-masked]>
> To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
> Cc: [email-masked], [email-masked], [email-masked]
> Reply-To: [email-masked]
> Subject: Re: BGP4 stuff: Local Preference Computation 
> In-Reply-To: Your message of "Wed, 04 Sep 1996 15:34:29 EDT."
>              <[email-masked]> 
> Date: Wed, 04 Sep 1996 18:54:46 -0400
> From: Curtis Villamizar <[email-masked]>
> 
> 	In message received from Curtis Vilamizar, he wrote:
> 
> In message <[email-masked]>, Cristina Radulescu-B
> an
> u writes:
> > 
> > 	I have some problems in implementing BGP4, and if you could
> > clarify some of them , this would be great.
> > 
> > 	I understood that LOCAL_PREF is used as degree of preference only for
> > the BGP4 speakers located in the SAME Autonomous System. The Degree of
> 
> That's MED.  LOCAL_PREF has always been compared regardless of AS.
> 
> 	At least from what I read, it doesn't seem like that.
> 	I will quote from RFC 1771:
> 
>          e) LOCAL_PREF (Type Code 5):
> 
>             LOCAL_PREF is a well-known discretionary attribute that is a
>             four octet non-negative integer. It is used by a BGP speaker
>             to inform other BGP speakers in its own autonomous system of
>                                                ~~~~~~~~~~~~~~~~~~~~~~~
>             the originating speaker's degree of preference for an
>             advertised route. Usage of this attribute is described in
>             5.1.5.
> 
> and:
> 
> 	5.1.5   LOCAL_PREF
> 
>    LOCAL_PREF is a well-known discretionary attribute that shall be
>    included in all UPDATE messages that a given BGP speaker sends to the
>    other BGP speakers located in its own autonomous system. A BGP
>                                  ~~~~~~~~~~~~~~~~~~~~~~~~~
>    speaker shall calculate the degree of preference for each external
>    route and include the degree of preference when advertising a route
>    to its internal peers. The higher degree of preference should be
>    preferred. A BGP speaker shall use the degree of preference learned
>    via LOCAL_PREF in its decision process (see section 9.1.1).
> 
>    A BGP speaker shall not include this attribute in UPDATE messages
>    that it sends to BGP speakers located in a neighboring autonomous
>    system. If it is contained in an UPDATE message that is received
>    from a BGP speaker which is not located in the same autonomous
>                      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~            
>         
>    system as the receiving speaker, then this attribute shall be
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    ignored by the receiving speaker.
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This means don't send LOCAL_PREF to an EBGP peer.

> 9.1.1 Phase 1: Calculation of Degree of Preference
>  
> 	   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. If
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    the route is learned from a BGP speaker in a neighboring autonomous
> 
>    system, then the degree of preference shall be computed based on
>    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    preconfigured policy information.  The exact nature of this policy
>    information and the computation involved is a local matter.  The
>    local speaker shall then run the internal update process of 9.2.1 to
>    select and advertise the most preferable route.

The preconfigured policy information is then put into the LOCAL_PREF
attribute.  This text should be more clear.  It seems that everyone
who has already implemented BGP4 agrees on the interpretation but the
text was never very clear.

Don't send LOCAL_PREF to an EBGP peer.  Don't accept LOCAL_PREF from
an EBGP peer.  Decide what your preference is based on configured
policy.  Then put that into LOCAL_PREF.  Then use LOCAL_PREF as the
first value in a comparison.

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

Date: Thu, 5 Sep 96 13:04:58 EDT
From: Cristina Radulescu-Banu <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: [[email-masked]: Re: BGP4 stuff: Local Preference Computation]
Reply-To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
Sender: [email-masked]

------- Start of forwarded message -------
Return-Path: <[email-masked]>
To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP4 stuff: Local Preference Computation 
In-Reply-To: Your message of "Wed, 04 Sep 1996 15:34:29 EDT."
             <[email-masked]> 
Date: Wed, 04 Sep 1996 18:54:46 -0400
From: Curtis Villamizar <[email-masked]>

	In message received from Curtis Vilamizar, he wrote:

In message <[email-masked]>, Cristina Radulescu-Ban
u writes:
> 
> 	I have some problems in implementing BGP4, and if you could
> clarify some of them , this would be great.
> 
> 	I understood that LOCAL_PREF is used as degree of preference only for
> the BGP4 speakers located in the SAME Autonomous System. The Degree of

That's MED.  LOCAL_PREF has always been compared regardless of AS.

	At least from what I read, it doesn't seem like that.
	I will quote from RFC 1771:

         e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a well-known discretionary attribute that is a
            four octet non-negative integer. It is used by a BGP speaker
            to inform other BGP speakers in its own autonomous system of
                                               ~~~~~~~~~~~~~~~~~~~~~~~
            the originating speaker's degree of preference for an
            advertised route. Usage of this attribute is described in
            5.1.5.

and:

	5.1.5   LOCAL_PREF

   LOCAL_PREF is a well-known discretionary attribute that shall be
   included in all UPDATE messages that a given BGP speaker sends to the
   other BGP speakers located in its own autonomous system. A BGP
                                 ~~~~~~~~~~~~~~~~~~~~~~~~~
   speaker shall calculate the degree of preference for each external
   route and include the degree of preference when advertising a route
   to its internal peers. The higher degree of preference should be
   preferred. A BGP speaker shall use the degree of preference learned
   via LOCAL_PREF in its decision process (see section 9.1.1).

   A BGP speaker shall not include this attribute in UPDATE messages
   that it sends to BGP speakers located in a neighboring autonomous
   system. If it is contained in an UPDATE message that is received
   from a BGP speaker which is not located in the same autonomous
                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                    
   system as the receiving speaker, then this attribute shall be
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ignored by the receiving speaker.
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

9.1.1 Phase 1: Calculation of Degree of Preference
 
	   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. If
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   the route is learned from a BGP speaker in a neighboring autonomous

   system, then the degree of preference shall be computed based on
   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   preconfigured policy information.  The exact nature of this policy
   information and the computation involved is a local matter.  The
   local speaker shall then run the internal update process of 9.2.1 to
   select and advertise the most preferable route.

> Preference is something totally different, it is used both for the BGP
> Peers in the same and in the neighbor AS (it can use in its
> computation the LOCAL_PREF, that's true), and one of the devices I
> tested computes the Degree of Prefence with formula:
> 
> 	TotalASPolicyWeight+ PeerWeight + DefaultWeight
> 
> where DefaultWeight = the weight added to each route when computing 
> the degree of preference for the route (LOCAL_PREF)-if you have
> any-because it's an discretionary attribute-, and
> if you consider it because it was received from a peer in the
> same AS)
> 	You can assign weight to each AS in the AS_PATH => this way you have th
> e
> TotalASPolicyWeight; 
> 
> PeerWeight = the weight that is added to all routes received from the specifi
> ed peer

You can assign LOCAL_PREF any way you want.  Rich just made a
suggestion since preferring shorter AS paths if you have no other way
to decide which route is better is a popular idea in some circles.

> 	For me this is pretty clear, to take in account 
> the AS and the Peer when you compute the Deegre of Preference.
> 
> 	After the router has done the computation for this Degree of
> Preference, the Local Pref  assigned to the route take the value of
> the Degree of preference already computed. If an internal peer
> received that route, it may or may not
> take as Local Pref the LOCAL_PREF already received (it can compute
> another Degree of Pref based on this Local Pref); If an external peer
> received it, it ignores it and does the Degree of Pref computation for
> the route again, without taking in account any Local Pref.
> 
> 	Yes, sometimes the Local Pref can be computed (if the internal
> peer choose this)but the one which is computed is always the DEGREE OF
> PREFERENCE, which is different form Local Pref.
> 
> This is totally different from what I saw in the messages
> exchanged, about the Local Pref Computation, which I think should be
> the Degree of Preference Computation; what is the right thing to be?
> 
> 	Thanks in advance,
> 
> 	Cristina 

IMO Yakov has obscured the use of LOCAL_PREF by referring to degree of
local preference when "value of the LOCAL_PREF attribute" belongs in
the draft.  This might be left over from early use of BGP4 where some
people didn't set local-pref at all.

	If a LOCAL_PREF is not set, I don't see where is the problem, 
the Degree of Preference being computed without taking into account
the LOCAL_PREF. 

Curtis

------- End of forwarded message -------

-- 

	This is the same in RFC 1771, and in
draft-ietf-idr-bgp4-03.txt, isn't it?

...............................................................................
Cristina Radulescu-Banu : Midnight Networks 200 Fifth Avenue Waltham MA 02154
[email-masked]  : Vox 617/890-1001 Fax 0028 The Best in Network Software
	
   I'm trying so much to communicate my thoughts by speaking that I
		     can't move my arms anymore.

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

To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP4 stuff: Local Preference Computation 
Date: Wed, 04 Sep 1996 18:54:46 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Cristina Radulescu-Ban
u writes:
> 
> 	I have some problems in implementing BGP4, and if you could
> clarify some of them , this would be great.
> 
> 	I understood that LOCAL_PREF is used as degree of preference only for
> the BGP4 speakers located in the SAME Autonomous System. The Degree of

That's MED.  LOCAL_PREF has always been compared regardless of AS.

> Preference is something totally different, it is used both for the BGP
> Peers in the same and in the neighbor AS (it can use in its
> computation the LOCAL_PREF, that's true), and one of the devices I
> tested computes the Degree of Prefence with formula:
> 
> 	TotalASPolicyWeight+ PeerWeight + DefaultWeight
> 
> where DefaultWeight = the weight added to each route when computing 
> the degree of preference for the route (LOCAL_PREF)-if you have
> any-because it's an discretionary attribute-, and
> if you consider it because it was received from a peer in the
> same AS)
> 	You can assign weight to each AS in the AS_PATH => this way you have th
> e
> TotalASPolicyWeight; 
> 
> PeerWeight = the weight that is added to all routes received from the specifi
> ed peer

You can assign LOCAL_PREF any way you want.  Rich just made a
suggestion since preferring shorter AS paths if you have no other way
to decide which route is better is a popular idea in some circles.

> 	For me this is pretty clear, to take in account 
> the AS and the Peer when you compute the Deegre of Preference.
> 
> 	After the router has done the computation for this Degree of
> Preference, the Local Pref  assigned to the route take the value of
> the Degree of preference already computed. If an internal peer
> received that route, it may or may not
> take as Local Pref the LOCAL_PREF already received (it can compute
> another Degree of Pref based on this Local Pref); If an external peer
> received it, it ignores it and does the Degree of Pref computation for
> the route again, without taking in account any Local Pref.
> 
> 	Yes, sometimes the Local Pref can be computed (if the internal
> peer choose this)but the one which is computed is always the DEGREE OF
> PREFERENCE, which is different form Local Pref.
> 
> This is totally different from what I saw in the messages
> exchanged, about the Local Pref Computation, which I think should be
> the Degree of Preference Computation; what is the right thing to be?
> 
> 	Thanks in advance,
> 
> 	Cristina 

IMO Yakov has obscured the use of LOCAL_PREF by referring to degree of
local preference when "value of the LOCAL_PREF attribute" belongs in
the draft.  This might be left over from early use of BGP4 where some
people didn't set local-pref at all.

Curtis

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

Date: Wed, 4 Sep 1996 15:34:29 -0400
From: Cristina Radulescu-Banu <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: BGP4 stuff: Local Preference Computation
Reply-To: [email-masked] (Cristina Radelescu-Banu 617/890-1001)
Sender: [email-masked]

	I have some problems in implementing BGP4, and if you could
clarify some of them , this would be great.

	I understood that LOCAL_PREF is used as degree of preference only for
the BGP4 speakers located in the SAME Autonomous System. The Degree of
Preference is something totally different, it is used both for the BGP
Peers in the same and in the neighbor AS (it can use in its
computation the LOCAL_PREF, that's true), and one of the devices I
tested computes the Degree of Prefence with formula:

	TotalASPolicyWeight+ PeerWeight + DefaultWeight

where DefaultWeight = the weight added to each route when computing 
the degree of preference for the route (LOCAL_PREF)-if you have
any-because it's an discretionary attribute-, and
if you consider it because it was received from a peer in the
same AS)
	You can assign weight to each AS in the AS_PATH => this way you have the
TotalASPolicyWeight; 

PeerWeight = the weight that is added to all routes received from the specified peer
 
	For me this is pretty clear, to take in account 
the AS and the Peer when you compute the Deegre of Preference.

	After the router has done the computation for this Degree of
Preference, the Local Pref  assigned to the route take the value of
the Degree of preference already computed. If an internal peer
received that route, it may or may not
take as Local Pref the LOCAL_PREF already received (it can compute
another Degree of Pref based on this Local Pref); If an external peer
received it, it ignores it and does the Degree of Pref computation for
the route again, without taking in account any Local Pref.

	Yes, sometimes the Local Pref can be computed (if the internal
peer choose this)but the one which is computed is always the DEGREE OF
PREFERENCE, which is different form Local Pref.

This is totally different from what I saw in the messages
exchanged, about the Local Pref Computation, which I think should be
the Degree of Preference Computation; what is the right thing to be?

	Thanks in advance,

	Cristina 
-- 

...............................................................................
Cristina Radulescu-Banu : Midnight Networks 200 Fifth Avenue Waltham MA 02154
[email-masked]  : Vox 617/890-1001 Fax 0028 The Best in Network Software
	
	 There wouldn't be wolves if there wouldn't be sheep.

			  - Romanian proverb

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

Date: Wed, 4 Sep 1996 11:14:08 -0400
To: "NITTMANN Michael (MSMail)" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: RE: BGP-4 changes
Cc: Curtis Villamizar <[email-masked]>, "[email-masked]" 	 <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

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

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

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

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

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

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

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

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

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

--John

--
John Scudder                        email:  [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: "NITTMANN Michael (MSMail)" <[email-masked]>
To: Curtis Villamizar <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: BGP-4 changes 
Date: Wed, 4 Sep 1996 08:20:59 -0600
Encoding: 85 TEXT
Sender: [email-masked]

I would not treat MED = -1 as a value, but as a flag for 'no MED present', 
which I need to identify candidates where either I cannot successfully work 
with an MED since the other side has set none, or where the other side does 
not want to tell me the MED value.
Therefore I would suggest a modifying option, in addition to the removal. 
This gives also the possibility to add an MED 'penalty' for a meetpoint to 
all MEDs gotten from there (again to resolve the mae-e problem where 
everybody and his dog wants to go through).

Mike

----------
From:  Curtis Villamizar[SMTP:[email-masked]]
Sent:  Wednesday, September 04, 1996 1:28 AM
To:  [email-masked]
Cc:  [email-masked]; [email-masked]; [email-masked]
Subject:  Re: BGP-4 changes 

In message <[email-masked]>, [email-masked] 
write
s:
> *** Resending note of 08/31/96 15:15
> Subject: Re: BGP-4 changes
> John,
> 
> I now have second thoughts about changing the MED value; stripping the
> attribute is of course still OK.  The problem is not route loops,
> but non-deterministic routing (i.e. not predictable).
> 
> >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.
> 
> Let's assume that a router considers the original EBGP MED in the
> route selection process, but sends the modified MED in the
> IBGP export.  Further assume a provider modifies the MED to value
> 0 at two border gateways (A & B), in order to try to draw traffic to
> the nearest of these two exits.

Removed MED attribute completely, not modified.

> Suppose border A gets an external BGP route with MED X first.  With no
> competition from B, border A installs the route and exports into IBGP
> with MED 0.  Border B will see this same route only with MED 0.
> 
> Later, border B receives its route with MED Y (same prefix, same
> neighbor AS, same preference, etc.).  So long as Y > 0 (it usually
> is), then border B will reject the external in favor of the internal
> route from A.
> 
> Note that acceptance of the internal route from A over the external
> route of B is based totally on timing issues -- first come, first
> served.  It only occurs when the MED value is decreased -- that's why
> stripping the MED is OK, since missing MEDs have value -1.
> 
> To fix this, one might use the modified MED value for both route
> selection and IBGP export, but one throws away useful information
> as Curtis and John mention above (for optimizing local external
> route selection).
> 
> Do we need the ability to change the MED attribute value, or is
> it sufficient to be able to remove the MED attribute?  Can we get
> away with modifying local preference instead of changing the MED
> value?
> 
> -- Richard Woundy, IBM

If you removed MED completely, with the current rule changes (sounds
like professional sports commission) you don't get a routing loop.

John didn't write anything about changing MED and I didn't write
anything about changing MED to John.

Curtis

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

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4 changes 
Date: Wed, 04 Sep 1996 02:27:31 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked] write
s:
> *** Resending note of 08/31/96 15:15
> Subject: Re: BGP-4 changes
> John,
> 
> I now have second thoughts about changing the MED value; stripping the
> attribute is of course still OK.  The problem is not route loops,
> but non-deterministic routing (i.e. not predictable).
> 
> >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.
> 
> Let's assume that a router considers the original EBGP MED in the
> route selection process, but sends the modified MED in the
> IBGP export.  Further assume a provider modifies the MED to value
> 0 at two border gateways (A & B), in order to try to draw traffic to
> the nearest of these two exits.

Removed MED attribute completely, not modified.

> Suppose border A gets an external BGP route with MED X first.  With no
> competition from B, border A installs the route and exports into IBGP
> with MED 0.  Border B will see this same route only with MED 0.
> 
> Later, border B receives its route with MED Y (same prefix, same
> neighbor AS, same preference, etc.).  So long as Y > 0 (it usually
> is), then border B will reject the external in favor of the internal
> route from A.
> 
> Note that acceptance of the internal route from A over the external
> route of B is based totally on timing issues -- first come, first
> served.  It only occurs when the MED value is decreased -- that's why
> stripping the MED is OK, since missing MEDs have value -1.
> 
> To fix this, one might use the modified MED value for both route
> selection and IBGP export, but one throws away useful information
> as Curtis and John mention above (for optimizing local external
> route selection).
> 
> Do we need the ability to change the MED attribute value, or is
> it sufficient to be able to remove the MED attribute?  Can we get
> away with modifying local preference instead of changing the MED
> value?
> 
> -- Richard Woundy, IBM

If you removed MED completely, with the current rule changes (sounds
like professional sports commission) you don't get a routing loop.

John didn't write anything about changing MED and I didn't write
anything about changing MED to John.

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

Date: Tue, 3 Sep 1996 21:41:14 -0400
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP-4 changes
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Rich,

Now that you bring it up, I am having a somewhat hard time thinking of
*any* good reason to alter an existing MED.

However, supposing one were to do so, would this text for 5.1.4 fix the
problem?

  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.  This may be done either prior to or after
  determining the degree of preference of the route and performing
  route selection (decision process phases 1 and 2).

  An implementation may also (based on local configuration) alter the
  value of the MULTI_EXIT_DISC attribute received over an external link.
  If it does so, it MUST do so prior to determining the degree of
  preference of the route and performing route selection (decision
  process phases 1 and 2).

Note that I also added "and performing route selection."  This used to just
say "determining the degree of preference" which strictly speaking is in
phase 1 and therefore left the actual MED comparison part unspecified,
since it's in phase 2.

--John

---
At 6:34 PM -0400 9/3/96, [email-masked] wrote:
>*** Resending note of 08/31/96 15:15
>Subject: Re: BGP-4 changes
>John,
>
>I now have second thoughts about changing the MED value; stripping the
>attribute is of course still OK.  The problem is not route loops,
>but non-deterministic routing (i.e. not predictable).
>
>>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.
>
>Let's assume that a router considers the original EBGP MED in the
>route selection process, but sends the modified MED in the
>IBGP export.  Further assume a provider modifies the MED to value
>0 at two border gateways (A & B), in order to try to draw traffic to
>the nearest of these two exits.
>
>Suppose border A gets an external BGP route with MED X first.  With no
>competition from B, border A installs the route and exports into IBGP
>with MED 0.  Border B will see this same route only with MED 0.
>
>Later, border B receives its route with MED Y (same prefix, same
>neighbor AS, same preference, etc.).  So long as Y > 0 (it usually
>is), then border B will reject the external in favor of the internal
>route from A.
>
>Note that acceptance of the internal route from A over the external
>route of B is based totally on timing issues -- first come, first
>served.  It only occurs when the MED value is decreased -- that's why
>stripping the MED is OK, since missing MEDs have value -1.
>
>To fix this, one might use the modified MED value for both route
>selection and IBGP export, but one throws away useful information
>as Curtis and John mention above (for optimizing local external
>route selection).
>
>Do we need the ability to change the MED attribute value, or is
>it sufficient to be able to remove the MED attribute?  Can we get
>away with modifying local preference instead of changing the MED
>value?
>
>-- Richard Woundy, IBM

--
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]
Date: Tue, 03 Sep 96 18:34:16 EDT
To: [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4 changes
Sender: [email-masked]

*** Resending note of 08/31/96 15:15
Subject: Re: BGP-4 changes
John,

I now have second thoughts about changing the MED value; stripping the
attribute is of course still OK.  The problem is not route loops,
but non-deterministic routing (i.e. not predictable).

>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.

Let's assume that a router considers the original EBGP MED in the
route selection process, but sends the modified MED in the
IBGP export.  Further assume a provider modifies the MED to value
0 at two border gateways (A & B), in order to try to draw traffic to
the nearest of these two exits.

Suppose border A gets an external BGP route with MED X first.  With no
competition from B, border A installs the route and exports into IBGP
with MED 0.  Border B will see this same route only with MED 0.

Later, border B receives its route with MED Y (same prefix, same
neighbor AS, same preference, etc.).  So long as Y > 0 (it usually
is), then border B will reject the external in favor of the internal
route from A.

Note that acceptance of the internal route from A over the external
route of B is based totally on timing issues -- first come, first
served.  It only occurs when the MED value is decreased -- that's why
stripping the MED is OK, since missing MEDs have value -1.

To fix this, one might use the modified MED value for both route
selection and IBGP export, but one throws away useful information
as Curtis and John mention above (for optimizing local external
route selection).

Do we need the ability to change the MED attribute value, or is
it sufficient to be able to remove the MED attribute?  Can we get
away with modifying local preference instead of changing the MED
value?

-- Richard Woundy, IBM

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

From: "NITTMANN Michael (MSMail)" <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: FW: Addr: Re: BGP-4 - revised I-D 
Date: Tue, 3 Sep 1996 12:04:09 -0600
Encoding: 134 TEXT
Sender: [email-masked]

Did you write that last paragraph? 

Let me enlight you: point and click does not mean cut and paste, but point 
and click a *path*. I have ample experience of course to know that 
especially with Cisco or Bayworks gear a decoupling from syntax and 
semantics is a prime target of *modern* development. All that go by gated 
like programming languages (morningstar, e.g.) are way better to deal with.

And liking snmp is probably more a proof of mature dealing with things than 
wanting to write assembler like statements repetitively into a console 
session.

... and database driven, and of course platform independently based. No hand 
knit static routes, but traffic driven routing in an *E*MS, this is *N*MS+++ 
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked]
Subject: Re: BGP-4 changes 
Date: Sun, 01 Sep 96 08:03:48 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Curtis,

> 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.  

Would you please provide the text for "a very efficient algorithm... that
is easy to explain and understand".

> 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.

I think that putting this into an appendix would be fine. Would
you consider drafting the text ?

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

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4 changes 
Date: Sun, 01 Sep 96 07:56:33 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,

> 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".)

Ok. I'll put "remove the attribute or override its value".
  
> 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.)

Ok. I'll include the above paragraph.

> >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.

Agreed.
  
> 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."

Ok.

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: BGP-4 changes 
Date: Sun, 01 Sep 96 07:42:46 PDT
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Rich,

> 
> >> 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).

Got it.
  
> > 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.

Yes, it was just a matter of clarification.

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