Re: [mpls] working group last call fordraft-ietf-mpls-number-0-bw-te-lsps

Hi Loa,
Is this really the version that is ready for last call?

The Abstract begins with
"** UPDATE OSPFv3 **"
Neither the Abstract not the Introduction mentions OSPFv3.
There are some references in the document, but section 3.2 has a textual 
reference to "draft-ietf-ospf-ospfv3-traffic-07.txt" rather than a citation.
===
Abstract
s/assumption on/assumptions about/
s/carried onto/carried by/
s/referred to as unconstrained TE LSP/referred to as unconstrained TE LSPs/
s/unconstrained TE LSP across/unconstrained TE LSPs across/
s/This requires the knowledge/This requires knowledge/
===
Abstract and Introduction
These sections are the only place where it is mentioned that assumptions 
have to be made about the traffic carried on the zero bandwidth LSPs. Do 
these assumptions form part of the algorithms "that can be designed" or are 
they assumptions that can be described?
What would be the consequence of different devices in the network making 
different assumptions? Indeed, what would be the consequence of different 
routers using different algorithms? Can we sure that two algorithms from 
different vendors will not interact unfavorably within the network?
===
Section 2
s/(TE LSP/(TE LSPs/
s/such unconstrained TE LSP/such unconstrained TE LSPs/
s/assumption on/assumptions about/
s/carried onto/carried by/
s/signalled across a link./signalled across each link./
s/outside of the scope/outside the scope/
s/and merely listed/and is referred to/
===
Section 2
Need to be expand acronyms on first use
LSR, SRLG, IGP
===
Section 2
  "TE LSPs signalled with zero bandwidth that are configured and
   provisioned through a management system are not included in the count
   that is reported."
I think "signalled" may be wrong here.
We probably mean
  "Unconstrained TE LSPs that are configured and
   provisioned through a management system are not included in the count
   that is reported."
===
Section 2
Suggest to delete
  "As currently defined in [RFC3630] and [RFC3784] the
   information related to the number of unconstrained TE LSP(s) is not
   available."
===
Section 2
  "Furthermore, the knowledge of the number of unconstrained TE LSPs
   signalled across each link can be used for other purposes (for
   example to evaluate the number of affected TE LSPs in case of a link
   failure)."
Wouldn't this function be better if we knew the actual number of TE LSPs on 
a link rather than only the number of zero bandwidth TE LSPs? Since we don't 
propose an extension that simply counts the number of TE LSPs, perhaps it 
would be simpler to delete this paragraph.
===
Section 3
The name of the new sub-TLV is clunky with its "(s)" suffix and its compound 
noun construction. Viz. "The Number of 0-bandwidth TE LSP(s) Sub-TLV"
Can we change its name to something like the "Unconstrained TE LSP Count 
Sub-TLV"?
===
Section 3.1
The use of RFC2119 language may be taken as contradictory.
  "The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST
   appear at most once within the extended IS reachability TLV (type 22)
   specified in [RFC3784]."
Suggest...
  "The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST
   NOT appear more than once within the extended IS reachability TLV (type 
22)
   specified in [RFC3784]."
===
Section 3.2
ditto section 3.1
===
Section 4
"An implementation MAY decide to implement"
We should add...
  "In any case, the origination of Traffic
   Engineering LSAs SHOULD be rate-limited to at most one every
   MinLSInterval [RFC2328]."
And a similar reference for ISIS.
===
Section 4
I think that some description of how to handle the absence of a Number of 
0-bandwidth TE LSP(s) sub-TLV is required. Is this to be taken as implying 
that there are no unconstrained TE LSPs on the link, or that there is no 
information about the link. In the latter case, is there any guidance to be 
given?
===
Section 5
The instructions to IANA need to give more references. Which registries? 
Which sub-registries?
===
Section 6
In the current climate, I would be very surprised if we got away with this 
text.
At the least, the text needs to support the assertion that there are no new 
security issues.
Is it possible that the IGP can be attacked by setting up and tearing down 
zero bandwidth TE LSPs?
===
Section 6
Is finger really the right protocol to reference for ISIS security?
===

Cheers,
Adrian

----- Original Message ----- 
From: "Loa Andersson" <loa@pi.se>
To: <mpls@ietf.org>
Cc: "Ross Callon" <rcallon@juniper.net>; "David Ward" <dward@cisco.com>
Sent: Monday, September 24, 2007 9:31 AM
Subject: [mpls] working group last call 
fordraft-ietf-mpls-number-0-bw-te-lsps

> Working Group,
>
> this is to initiate a two week working group last call om
> draft-ietf-mpls-number-0-bw-te-lsps-06.txt.
>
> The working group last call ends eob Oct 8.
>
> Please send your comments to the working group mailing list.
>
> Loa and George
>
> -- 
> Loa Andersson
>
> Principal Networking Architect
> Acreo AB                           phone:  +46 8 632 77 14
> Isafjordsgatan 22                  mobile: +46 739 81 21 64
> Kista, Sweden                      email:  loa.andersson@acreo.se
>                                           loa@pi.se
>
> This email was Anti Virus checked by Astaro Security Gateway. 
> http://www.astaro.com
>
>
>
> _______________________________________________
> mpls mailing list
> mpls@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/mpls
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls