On Fri, 11 Apr 2008, The IESG wrote:
> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
>
> - 'A Link-Type sub-TLV to convey the number of Traffic Engineering Label
> Switched Paths signalled with zero reserved bandwidth across a link '
> <draft-ietf-mpls-number-0-bw-te-lsps-09.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@xxxxxxxx mailing lists by 2008-04-25. Exceptionally,
> comments may be sent to iesg@xxxxxxxx instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
I've reviewed this document for OPS-DIR.
My general observation is that trying TE bandwidth signalling to IGP
advertisements seems somewhat dubious. For example, when a TE
signalling protocol adjusts reservations on a link, IGP information
gets outdated and needs to be refreshed, causing churn in the local
routing system. But this concept is not introduced by this document
and as a result I do not see significant operational issues with this
document.
With regards to the management aspects, the document says:
"Unconstrained TE LSPs that are configured and provisioned through a
management system MAY be omitted from the count that is reported."
Which is interesting because document doesn't specify what would set
this information in the first place. My assumption during the reading
was that the TE signalling protocol would notify the IGP of changes
using implementation's internal API. But aren't TE signalling
protocols usually just applying policies configured at a management
system, so the message above might also also apply? How does the IGP
know how TE LSP was provisioned and if it should be included in the
calculation or not?
FWIW, I'd expect that the value need not be configured manually or
adjusted using network management such NETCONF or SNMP write. The
value should be readable using SNMP but I don't know if TE signalling
protocol MIB modules provide this information to network managers.
procedural and editorial issues
-------------------------------
I'll note that the normative reference (and I believe it needs to stay
normative) I-D.ietf-ospf-ospfv3-traffic is marked "Dead" in the I-D
tracker, having been expired some time ago. This document is going to
wait for the publication of I-D.ietf-ospf-ospfv3-traffic and I'd hope
the latter would get done soon.
This document makes a normative reference to IS-IS TE RFC 3784 which
is currently informational. This causes a procedural down-ref
problem. RFC 3784 is being revised on standards track and I guess the
reference could be updated to point to draft-ietf-isis-te-bis which is
currently in Publication Requested - External review.
Reference to RFC2470 (IPv6 over token ring!) should be to RFC2740 :-)
(or upcoming draft-ietf-ospf-ospfv3-update)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf