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

From: "Don Fedyk" <[email-masked]>
Date: Sun, 10 Oct 1999 09:29:53 -0400

Tony,

> -----Original Message-----
> From: Tony Li [mailto:[email-masked]]
> Sent: Saturday, October 09, 1999 6:17 PM
> To: Fedyk, Don [BL3:2001-I:EXCH]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] draft-ietf-isis-traffic-01.txt
> 
> 
> 
> Don,
> 
> 
> |  I have read the draft and the scanned the working group to 
> understand what 
> |  is happening to the metric(s).  While it makes sense that 
> the metrics for
> |  IS-IS
> |  were made larger and the 3 not commonly used metrics 
> eliminated, I do not 
> |  understand the proposal of a single Traffic Engineering Metric. 
> 
> 
> Well, it's what we felt was needed.  Note that the existing 
> metrics can
> continue to be used if the network 
> administrator/implementation allows it.
> There's no reason that you can't run the traffic engineering TLVs in
> parallel with the existing TLVs.
It is an either/or situation though for the new 24 bit metric and the old 6
bit
metrics, correct? 
The new connectionless metric does not have a specific traffic 
qualifier (such as delay, throughput etc) but I would assume its 
a combination of throughput and delay. Is this ever specified ?

We implemented thoughput and delay based routing on both a connectionless
and a path oriented system. 
The result for the connectionless system was that the delay based routing 
occupies forwarding table space for all possible destinations. 
We ended up implementing only two metrics. But with MPLS it is only 
a path minimization criteria during LSP selection.

> 
> 
> |  In my 
> |  experience multiple traffic engineering metrics for path 
> selection allow 
> |  better traffic engineering capabilities. 
> 
> 
> Please say more.  The customer base didn't request this flexibility
We are defining TE beyond just ISIS. In general it depends on the size 
of the network and the diversity of the links. The bandwidth allocation
records are a type of metric in a sense since they take the place of the
typical throughput based metric in a connectionless system. Of course
not all MPLS connections will specify traffic parameters.
I would be quite willing to elaborate on what metrics I think are useful 
and why in a small draft for the next IETF.

> 
> 
> |  Has any thought been given to multiple TE metrics? Can the 
> current proposal
> |  be expanded in the future ?
> 
> 
> One of the great glories of TLV encoding is the flexibility for future
> extensions.  ;-)

Agreed, but can also be one of its curses if we don't do it right.

> Tony

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Li <[email-masked]>
Date: Sun, 10 Oct 1999 10:45:20 -0700

Don,

|  > There's no reason that you can't run the traffic engineering TLVs in
|  > parallel with the existing TLVs.
|  It is an either/or situation though for the new 24 bit metric and the old 6
|  bit metrics, correct? 

Not strictly.  You can run both.  If you do, you probably want to advertise
the same value in the 24 bit metric as you do in the default 6 bit metric.
You still get to append all of the TE subTLVs that we've specified, you
just lose out on the dynamic range of the metric.

|  The new connectionless metric does not have a specific traffic 
|  qualifier (such as delay, throughput etc) but I would assume its 
|  a combination of throughput and delay. Is this ever specified ?

It is the default metric, with identical semantics to the default 6 bit
metric, except for the range.  This is to say that it's an administrative
value, which may or may not have any bearing on reality, on a per-network
basis. 

|  We implemented thoughput and delay based routing on both a connectionless
|  and a path oriented system. 
|  The result for the connectionless system was that the delay based routing 
|  occupies forwarding table space for all possible destinations. 
|  We ended up implementing only two metrics. But with MPLS it is only 
|  a path minimization criteria during LSP selection.

Are you thinking of modeling the static delay or dynamic delay?  I'll
assume the latter.

One of the significant concerns with this type of approach is the stability
of the routing system when you impart dynamic metric information into it.
This has been discussed within the WG before.  Previous experiments from
the QoSR WG have demonstrated that we haven't been able to apply sufficient
control theory to the protocols to achieve stability.

|  > |  In my 
|  > |  experience multiple traffic engineering metrics for path 
|  > selection allow 
|  > |  better traffic engineering capabilities. 
|  > 
|  > Please say more.  The customer base didn't request this flexibility
|  We are defining TE beyond just ISIS. In general it depends on the size 
|  of the network and the diversity of the links. The bandwidth allocation
|  records are a type of metric in a sense since they take the place of the
|  typical throughput based metric in a connectionless system. Of course
|  not all MPLS connections will specify traffic parameters.
|  I would be quite willing to elaborate on what metrics I think are useful 
|  and why in a small draft for the next IETF.

Thanks, we'll take you up on that.  Also, if you'd like to lead a
discussion and argue your case with the entire WG, we can do that.

|  > One of the great glories of TLV encoding is the flexibility for future
|  > extensions.  ;-)
|  
|  Agreed, but can also be one of its curses if we don't do it right.

History has shown that we never get it perfectly right, so we do our best
and move on.  ;-)

Tony

---

From: Jeff Learman <[email-masked]>
Date: Tue, 26 Oct 1999 17:24:27 -0400

>just lose out on the dynamic range of the metric.

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?

Thanks,
Jeff

____________________________________________________________________

  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
____________________________________________________________________

---

From: Tony Li <[email-masked]>
Date: Tue, 26 Oct 1999 15:51:54 -0700

|  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

---

From: Jeff Learman <[email-masked]>
Date: Tue, 26 Oct 1999 19:17:31 -0400

Tony,

Right: black holes, not loops.

Never mind,
Roseanna Roseannadanna