Subject: RE: [Isis-wg] Wide Metric

From: hemanthbs <[email-masked]>
Date: Mon, 31 Jan 2005 18:54:10 +0530

Hi Nurit,

Hi Shankar and Hemanth,
Thank you for your response.
I understand the benefits of using the Wide metric.
My doubt was why it is combined together with TE. 

The main urge for development of wide metrics was TE. Though we had the
problems of smaller metric range.

If for example I would
like to use the Wide metric over a non-TE network, then I have to use
the 'Extended IS Reachability' TLV, without the TE sub-TLVs. 

For any implementation, wide metrics and TE can be independent. Not
necessarily combined. For eg: if enable only wide metrics, then we need
not
Generate the TE sub-tlvs.We generate only the extended reachability
tlvs.
However, if TE is enabled(for which wide metrics is a pre-requiste) then

We generate the TE sub-tlvs along with the extended reachability tlvs.

In addition, it is written in the RFC that "If a link is advertised
without
this sub-TLV, 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". This mandatory requirement does not
allow advertising a non-TE link. If for example, an IS supports TE on
some links but non-TE only on other links, this mandatory requirement
causes that even the Non-TE links will be considered in the CSPF
calculation. For a TE only link we have a support in the RFC, using the
maximum value in the default metric field. However, we cannot support a
non-TE only link, because the default metric appear in the sub-TLV will
be considered for the CSPF calculations.

The above concern may be answered as below, I guess.
In an implementation where in the TE links are considered based on the
following condition. "TE should be enabled for the ISIS process and MPLS
TE should be enabled on the interface"
i.e for TE computation only those links be will be considered, for
which MPLS TE is enabled on the interface and TE is enabled for that
ISIS process running on that interface.

I hope I answered your question.

Hemanth.

I'll appreciate your response.
Thanks and best regards,
Nurit.

-----Original Message-----
From: Shankar Vemulapalli [mailto:[email-masked]] 
Sent: Monday, January 31, 2005 7:02 AM
To: Nurit Sprecher
Cc: [email-masked]
Subject: Re: [Isis-wg] Wide Metric

Hi Nurit -

At 12:14pm 01/25/05 +0200, Nurit Sprecher wrote:
> Hi all,
>
> I wonder if the wide metric defined in the TE extension for the
> integrated IS-IS is widely supported in real networks. What about the
> IS-IS default metric? I guess the default metric is widely supported.
Is
> that correct?

Wide-metric is embraced by more & more customers.  It gives them the
flexibility which is not there with the narrow (default) metric.
( for ex.:  suuport of TE, increasing the range of is-is metric & also
  improving the encoding of IP prefixes)

> Is the wide metric in use especially when leaking routes from L2 to
L1?
> Or maybe there is there another case/use?

is also used in carrying the TE extensions.

> Why is the wide metric combined with the TE extension? Is it supposed
to
> be considered by the CSPF calculations? My understanding is that it
used
> by the SPF calculations. Is that correct?

Take a look at RFC3784 - which should help answer your questions.

Thanks,

/Shankar

> Thanks in advance,
> Nurit.

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

---

From: "Nurit Sprecher" <[email-masked]>
Date: Mon, 31 Jan 2005 12:46:12 +0200

Hi Shankar and Hemanth,
My doubt was why it is combined together with TE. If for example I would

-----Original Message-----
From: Shankar Vemulapalli [mailto:[email-masked]] 
Sent: Monday, January 31, 2005 7:02 AM
To: Nurit Sprecher
Cc: [email-masked]
Subject: Re: [Isis-wg] Wide Metric

Hi Nurit -

Is

L1?

to
used

Thanks,

/Shankar

---

From: Marc Binderberger <[email-masked]>
Date: Mon, 31 Jan 2005 21:52:40 +0100

Hello,

> problems of smaller metric range.

Maybe Nurit is asking why the TE extensions have been "integrated" into 
extended IS reachability TLV type 22 instead of using a separate TLV. 
Nurit?

(in this case: at the beginning of RFC3784 the authors are counting 
octets, so I assume they tried to avoid the additional 7 octets for 
system Id and pseudonode number in a separate TLV. Beside that 
integrating it seems logical, all new per-link information are in one 
place/TLV)

>> [...] This mandatory requirement does not
>> calculation. [...]

Hemanth, but how does a distance router _know_ what interfaces are 
enabled if not IS-IS is signaling this?

How does the IS-IS process running on A know that B's interface to C 
allows TE while the interface to D doesn't ?

   A--(te)--B--(te)--C
            |        |
            |       (te)
            |        |
            D--------E

(please switch on your fixed font ;-)

Or is there the implicit condition that all routers must be "TE-aware" 
and you simply put a very high TE metric on the links you don't want?

Or trial & error? (wasn't it named "cut back"? The RSVP will tell 
finally that a link is not TE/RSVP enabled).

What am I missing? :-)

Regards, Marc
--
Marc Binderberger    <[email-masked]>