Subject: Route Dampening: How is a "route" defined?

From: "Ken Rosenfeld" <[email-masked]>
Date: Thu, 11 Dec 1997 16:32:41 -0500

In the context of route dampening, how is a "route" defined?

<draft-ietf-idr-route-damp-00> states (p. 13):
  "A route here is considered to be a tuple containing at least
   NLRI prefix, next hop, and AS path."

I think the cisco IOS 11.2 implementation has a different view.

I did the following test:

bgp simulator   <------------>      cisco router
-------------                       ------------

announce 178.0.0.0
         next-hop=192.1.1.3
         AS_PATH={2 51 78 34 89}

withdraw route                      penalty assigned
announce route                      penalty incremented
withdraw route                      penalty > suppress limit
announce route                      route suppressed
withdraw route

announce 178.0.0.0                  this new route inherits
         next-hop=192.1.1.2         penalty of previous route and
         AS_PATH={2 102 10 101}     is suppressed

Thanks,

Ken

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 11 Dec 1997 21:44:13 -0500

In message <[email-masked]>, "Ken Rosenfeld" write
> bgp simulator   <------------>      cisco router

You are probably correct in pointing out that the definition or route
or lack of needs to be more clearly stated in the route flap damping
draft.

In the beginning of section 4.4.3 the draft states (mid page 11 in the
PS version, page 13 in the text version)

  The following information must be maintained per route.  A route here
  is considered to be a tuple containing at least NLRI prefix, next hop,
  and AS path.  The tuple may also contain other BGP attributes such as
  MULTI_EXIT_DISCRIMINATOR (MED).

This might almost be better conspicuously defined in a separate
subsection with:

   A route is defined as:

     NLRI
       prefix		required
       length		required
     AS path		required
     next hop		optional
     MED                optional

I'm not sure what other BPG attributes you might consider damping on.
If someone can't keep a constant MED or next hop it is a likely an
indication of instability in their IGP.  OTOH you may prefer to not
damp on next hop because you don't have to propogate the change
further and you amy want to not damp on MED because you either don't
have to propagate further if you use MED for only next hop resolution
or at worst don't have to propagate the change beyond your own IGP.

The draft is clear about only penalizing the down transition and not
the up transition.  I view Cisco's penalizing the up transition as a
bug.  I'll forward a message from the IEPG list that supports that
assertion.

Curtis

---

From: Paul Traina <[email-masked]>
Date: Thu, 11 Dec 1997 23:51:03 -0800

From: Curtis Villamizar <[email-masked]>
  Subject: Re: Route Dampening: How is a "route" defined? 
  
  In message <[email-masked]>, "Ken Rosenfeld" wri
>>te

  

I like your current definition in the draft, and have no objections with
clarifying it.

I'm glad you made the MED and NEXT_HOP optional -- there are good reasons
for including them,  but there are some intuitively obvious concerns too.

---

From: Enke Chen <[email-masked]>
Date: Tue, 16 Dec 1997 10:43:56 -0800

Ken, 

> Date:    Thu, 11 Dec 1997 16:32:41 -0500
> From:    "Ken Rosenfeld" <[email-masked]>
> To:      [email-masked]

> I think the cisco IOS 11.2 implementation has a different view.
[deleted]

It was a bug - a penalty was charged when a withdrawn prefix was
re-announced.  It has been fixed in 011.002(009.001) and many 
other versions. The related ddts's are: CSCdj45833 / CSCdj39433. 

-- Enke

---

From: Reinaldo Penno Filho <[email-masked]>
Date: Wed, 7 Jan 1998 11:14:18 -0200 (EDT)

On Thu, 11 Dec 1997, Ken Rosenfeld wrote:

vc>In the context of route dampening, how is a "route" defined?
vc>
vc><draft-ietf-idr-route-damp-00> states (p. 13):
vc>  "A route here is considered to be a tuple containing at least
vc>   NLRI prefix, next hop, and AS path."
vc>

Hi, 

Sorry if this is a newbie question but I´m having a hard time
understanding the difference between a Route, NLRI and their relation
to UPDATE messages.

In the <draft-ietf-idr-bgp4-06.txt> is said:

-->   For purposes of this protocol a route is defined as a unit of
   information that pairs **a** destination with the attributes of a path
   that destination:   <--

-->An UPDATE message is used to advertise a *single* feasible route<--

Does "a destination" means one AS or NLRI<->path attribute information?

Cause if a destination is one NLRI seems to me that a UPDATE message
can advertise several routes..

Or..

Does this mean that a collection of NLRIs and their path attributes 
is a *single* route, even tough some NLRI<-> path attributes tuples
advertise different destinations (networks)? 

Something like this...

NLRI 1 --\
          \
NLRI 2 ---- Path Attributes
          /
NLRI 3 --/

(NLRI 1, Path At.)
(NLRI 2, Path At.)
(NLRI 3, Path At.)

A many to one relationship. 

So another update message to the same AS with the same NLRI but other path
attribute is another route? 

Sorry for the long and possible intricate message...

Best Regards,

Reinaldo
      
----------------------------------------------------------------------------
Brazilian Reserch Network
http://www.rnp.br
[email-masked]
----------------------------------------------------------------------------