This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF219A.3AECE6AC Content-Type: text/plain; charset="iso-8859-1" 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:prz@siara.com] > > > Sent: Tuesday, October 26, 1999 8:48 PM > > > To: Jeff Learman > > > Cc: Tony Li; Fedyk, Don [BL3:2001-I:EXCH]; > > > isis-wg@external.juniper.net; > > > te-wg@UU.NET > > > 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: > jjl@one.com > > > > 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 - Isis-wg@external.juniper.net > > > > http://external.juniper.net/mailman/listinfo/isis-wg > > > > ------_=_NextPart_001_01BF219A.3AECE6AC Content-Type: text/html; charset="iso-8859-1" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">RE: [Isis-wg] draft-ietf-isis-traffic-01.txt 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
>
> -- tonyO.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
>
------_=_NextPart_001_01BF219A.3AECE6AC--
> >
> > Don
> >
> > > -----Original Message-----
> > > From: Tony Przygienda [mailto:prz@siara.com]
> > > Sent: Tuesday, October 26, 1999 8:48 PM
> > > To: Jeff Learman
> > > Cc: Tony Li; Fedyk, Don [BL3:2001-I:EXCH];
> > > isis-wg@external.juniper.net;
> > > te-wg@UU.NET
> > > 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:
> jjl@one.com
> > > > 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 - Isis-wg@external.juniper.net
> > > > http://external.juniper.net/mailman/listinfo/isis-wg
> > >
>