Subject: RE: [Isis-wg] Wide Metric

From: Satish Dattatri <[email-masked]>
Date: Wed, 2 Feb 2005 15:59:41 -0800 (PST)

> 
> > However, the statement in the RFC should be fixed. The RFC explicitly
> > states that " If a link is advertised without this sub-TLV (i.e.
> Sub-TLV
> > 18: Traffic Engineering Default Metric), traffic engineering SPF
> > calculations MUST use the normal default metric of this link, which is
> > advertised in the fixed part of the extended IS reachability TLV".
> There
> > are no conditions regarding other sub-TLVs. This is misleading and I
> > guess that it should be clarified.
> > 
> 
> This part of the RFC is talking about which metric to use in the CSPF.
> To me all this means, if TE metric is present use that else use the
> default metric (same one used in IGP/normal SPF) as the link cost 
> during your CSPF.
> <<<Nurit: but it may be (and I guess this is the case) that if the TE
> metric sub-TLV does not exist, the link is not a TE link and we do not
> want to consider it with the CSPF calculations.>>>

Look at it this way, TE metric is specified to aid your CSPF
engine to choose a different path than your SPF path. There
very well could be links that are TE enabled, but do not have
a specific TE metric configured. Since you can avoid using
up some, need not send the TE metric. It is perfectly legal
to send the same IGP link cost in the TE metric, but not
necessary.

> 
> In order to determine if a link is TE enabled or not base it on b/w
> sub-tlvs. Remember that choosing a link in your CSPF is a *local*
> decision. However, keep in mind that a TE enabled link need not have
> the TE metric configured on it.
> <<<Nurit: If someone advertises a TE link, this link may be considered
> as a TE link. If it is advertised as a non-TE link, it should be
> considered for the SPF calculation only. Otherwise this is misleading
> and confusing.

All advertised links are considered for SPF. For CSPF consider
only those links which have TE enabled (not by TE metric presence).

> The integration between a TE and a wide metric is too strong. I can
> still want to use the wide metric in a non-TE network without using the
> TE-metric. 

Enabling wide metric usage and TE can be kept seperate in your
implementation. The RFC does not ask you to bind it together.
You do need to use the new-style of TLVs for this purpose.
If and when TE is enabled start shipping those sub-tlvs as 
required.

>If a wide metric does not appear, we do not take the TE
> metric instead.

Not sure what you mean here.. Without the wide metric
=> new-style of TLVs anyway we cannot have TE metric.

> If someone wants to advertise a TE link, it should specifically assign a
> value to the TE metric (if not configured, it can assign it with the
> value of the wide metric>>>

As mentioned above, this is upto your implementation, you certainly
can send TE metric on links that have TE enabled (wasting LSP space)
But, you cannot require other implementation to do the same.
Hence you anyway need to handle missing TE metric but link being
TE enabled in your CSPF.

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg