I mean what does traffic engineering has to do with wide-metric style for IS-IS? What extra information wide-metric starts to carry when enabled , which is required by TE and not supported by narrow metric style of IS-IS.
In order for IS-IS to support traffic engineering, the "old-style" link-state PDU TLVs (Type-2 IS-Reachability and Type-128 IP-Reachability) were extended to what we call "new-style" (Type-22 Extended IS Reachability and Type-135 Extended IP Reachability). These extensions allow IS-IS to convey information related to traffic engineering (bandwidth, link protection, etc.) These new-style TLVs are defined in RFC5305 and RFC5307.
By default, Juniper will advertise both old-style and new-style TLVs (wide-metrics is on by default). By in large, this default was made for networks that were in the middle of transitioning to the new-style functionality.
Enabling wide-metrics-only
simply tells IS-IS to suppress old-style TLVs.
To address your comment:
Please correct me If I am wrong. You mean that wide metric is required to populate the traffic engineering database in case of IS-IS?
Don't confuse wide-metrics with wide-metrics-only
, as I stated before wide-metrics are enabled on Juniper by default, so if a device receives IS-IS PDUs with TE TLVs, it will populate the TED.
Though if you had a device that did not support wide-metrics and it received TE TLVs, it would ignore them, per IS-IS standard requirements.