Re: Last Call: draft-ietf-mpls-number-0-bw-te-lsps (A Link-Type sub-TLV to convey the number of Traffic Engineering Label Switched Paths signalled with zero reserved bandwidth across a link) to Proposed Standard

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@ietf.org mailing lists by 2008-04-25. Exceptionally,
> comments may be sent to iesg@ietf.org 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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf