Subject: RE: [Isis-wg] draft-ietf-isis-traffic-01.txt

From: "Don Fedyk" <[email-masked]>
Date: Thu, 28 Oct 1999 19:14:45 -0400

Tony Przygienda 
Writes

> Don Fedyk wrote:
> > 
> > This is interesting. It seems to me the current pratice
> > of limiting the metric to a maximum that is less than
> > infinity ie 63 is incompatible with a new metric beyond
> > 63. If metrics beyond 63 were infinity for old systems,
> > this would not happen.
> 
> if I'm reading you correctly, your conclusion is incorrect. 
> In the example given, it doesn't matter whether old routers
> believe that new links with metric >63 are invisible or 
> infinity (or de facto, this is the _same_ thing for a link
> state protocol). All said below holds. I recommend to familiarize
> oneself with the calculus given in the paper before further discussion
> on this topic. Things are rather counter-intuitive in 
> the problem domain that you face in such a network. 
> 
> 		thanks 
> 
> 		-- tony

O.K. I see your point. 
So how do you fix the loop?  It seems you must limit the metrics
to 63 until you have upgraded all routers.

Don

> 
> > 
> > Don
> > 
> > > -----Original Message-----
> > > From: Tony Przygienda [mailto:[email-masked]]
> > > Sent: Tuesday, October 26, 1999 8:48 PM
> > > To: Jeff Learman
> > > Cc: Tony Li; Fedyk, Don [BL3:2001-I:EXCH];
> > > [email-masked];
> > > [email-masked]
> > > Subject: Re: [Isis-wg] draft-ietf-isis-traffic-01.txt
> > >
> > >
> > > Jeff Learman wrote:
> > > >
> > > > Tony,
> > > >
> > > > Right: black holes, not loops.
> > >
> > > It's not exactly because of the MAX_PATH but
> > > loops are possible in a mixed old-TLV, new-TLV
> > > network if e.g. the same prefix is
> > > being advertised twice and if
> > > certain new link metrics are longer >63 and
> > > certain are not (assuming that we'd generate
> > > old-style TLVs for anything <64). In the figure  O denotes
> > > old-routers, N new routers and the dashed
> > > lines are links with metrics
> > >
> > >
> > >       X/Y
> > >       |
> > >       65
> > >       |
> > >        [N]
> > >       |
> > >       10
> > >       |
> > >        [O1]
> > >       |
> > >         10
> > >         |
> > >        [N1]
> > >       |
> > >       63
> > >       |
> > >        [O]
> > >       |
> > >       63
> > >       |
> > >        [O]
> > >       |
> > >       63
> > >       |
> > >       X/Y
> > >
> > > So new router N1 will see the shortest path to X/Y
> > > as 65+10+10=85 whereas O1 will believe that the
> > > shortest path is 10+63+63+63>85 since it cannot see
> > > any links with metric longer than 64 (new TLVs can
> > > carry it, old ones cannot). Observe that I introduced
> > > X/Y into the network twice to make a simple example,
> > > in reality it's enough O1 cannot compute the route
> > > to X/Y (because it cannot use the links with >64) and
> > > uses aggregated/default forming a loop.
> > >
> > > And yes, trying to make everything >64 to be just 64
> > > in old TLVs doens't help either. Examples are easily
> > > constructed.
> > >
> > > For a much more thorough (but rather formal so nothing
> > > for the faint-hearted) dealilng
> > > with this (IMHO) interesting topic look @ this year's infocom
> > > 'Hop-by-Hop Routing with Node-Dependent Topology Information'
> > >
> > >
> > >       thanks
> > >
> > >       -- tony
> > >
> > >
> > > >
> > > > Never mind,
> > > > Roseanna Roseannadanna
> > > >
> > > > At 03:51 PM 10/26/99 -0700, Tony Li wrote:
> > > > >
> > > > >|  Earlier, I pointed out what I though was a problem with
> > > the 24-bit
> > > > metrics,
> > > > >|  namely, that MAX_PATH_METRIC increased from 1024 to a
> > > much larger value.
> > > > >|
> > > > >|  If you are running traffic engineering metrics in
> > > parallel with existing
> > > > >|  TLVs, which value for MAX_PATH_METRIC should be used?
> > > Must all routers
> > > > >|  in the subdomain support the new TLVs before they are
> > > used at all,
> > > > >|  to avoid routing loops that would occur if some paths
> > > exceed the smaller
> > > > >|  MAX_PATH_METRIC?
> > > > >
> > > > >
> > > > >Would inconsistent MAX_PATH_METRICs lead to forwarding
> > > loops?  Or to
> > > > >blackholes?
> > > > >
> > > > >In any case, if you're going to run with both metrics,
> > > then in normal
> > > > >operations, the metric would have to be smaller than 1024.
> > >  If it were to
> > > > >exceed this, presumably due to an outage, then newer
> > > systems might find a
> > > > >path while older systems didn't.  This would seem like 
> a blackhole.
> > > > >
> > > > >And of course, if everything is a new system, you have a
> > > valid path.
> > > > >
> > > > >I'm not sure I see the problem.
> > > > >
> > > > >Tony
> > > > >
> > > > >
> > > > 
> ____________________________________________________________________
> > > >
> > > >   Jeff Learman                           Internet:     
> [email-masked]
> > > >   Engineering Manager                    Voice:     
> (734)-975-7323
> > > >   ONE (Open Networks Engineering, Inc)   Fax:       
> (734)-975-6940
> > > >   2725 South Industrial Pkwy, Suite 100
> > > >   Ann Arbor, MI  48104  USA
> > > > 
> ____________________________________________________________________
> > > >
> > > > _______________________________________________
> > > > Isis-wg mailing list  -  [email-masked]
> > > > http://external.juniper.net/mailman/listinfo/isis-wg
> > >
>

---

From: Tony Li <[email-masked]>
Date: Thu, 28 Oct 1999 17:22:02 -0700

|  So how do you fix the loop?  It seems you must limit the metrics
|  to 63 until you have upgraded all routers.

I'd think that it would be somewhat unreasonable to use metrics > 63 in a
hybrid environment anyhow.

While I appreciate the attention to detail, please recall that the intent
of this mechanism is to provide a migration path.

Tony