Subject: [mpls] working group last call for draft-ietf-mpls-number-0-bw-te-lsps

From: Loa Andersson <[email-masked]>
Date: Mon, 24 Sep 2007 10:31:13 +0200

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:  [email-masked]
                                           [email-masked]

This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 24 Sep 2007 11:08:21 +0100

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" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>; "David Ward" <[email-masked]>
Sent: Monday, September 24, 2007 9:31 AM
Subject: [mpls] working group last call 
fordraft-ietf-mpls-number-0-bw-te-lsps

---

From: Lou Berger <[email-masked]>
Date: Mon, 24 Sep 2007 09:18:00 -0400

JP, (co-authors),

         I have some minor questions and some feedback on the 
draft.  See below.

>    TE LSPs signalled with zero bandwidth that are configured and
>    that is reported.

Two questions WRT the above:
- Why are such LSPs excluded from reporting?
- How is the above accomplished for signalled LSPs?

section 3.1:
>    The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST
>    appear at most once within [...]
and section 3.2:
>    The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST
>    appear at most once within [...]

While your intent is pretty clear, the phrasing is a bit awkward and 
subject to misinterpretation (i.e., what does it mean for an 
"OPTIONAL" element to "MUST" appear ).  How about rephrasing along 
the lines of (change marked in asterisks):

"The Number of 0-bandwidth TE LSP(s) sub-TLV is OPTIONAL and MUST 
***NOT appear more than*** once within [...]"

>4.  Elements of procedure
>
>    An implementation MAY decide to implement a dual-thresholds mechanism
>    based on the number of unconstrained TE LSPs to govern the
>    origination of updated OSPF LSA or ISIS LSP.  [...]

Should either define or point a reference that defines "a 
dual-thresholds mechanism".

>5.  IANA Considerations
>
>    IANA will assign a new code point for the newly defined IS-IS Number
>    of 0-bandwidth TE LSP(s) sub-TLV carried within the TLV 22 (suggested
>    value =18).
>
>    IANA will assign a new code point for the newly defined OSPF Number
>    of 0-bandwidth TE LSP(s) sub-TLV carried within the Link TLV (Type 2)
>    of the Traffic Engineering LSA (suggested value=18).

Both suggested values are already assigned.

That's it!
Lou

---

From: "Attila Takacs" <[email-masked]>
Date: Tue, 25 Sep 2007 08:33:19 +0200

Hi all,

Some comments and questions on the draft. 

Best regards,
Attila

Section 1,
-remove the full stops after the expansion of acronyms

Section 2,
-paragraph 1: remove the explanation "(TE LSP signaled with zero
bandwidth)"

-paragraph 2: the text is unclear on what is referred by "such metrics"
in the last sentence. To clarify remove the parenthesis from "(other
metric...)" and change "other metric..." => "on metrics, e.g.,
percentage of reserved bandwidth or the number of hops." Maybe the last
sentence should simply state something like: "Unfortunately, in the
presence of unconstrained TE LSPs constraints on reserved bandwidth and
number of LSPs may be misleading and may lead to poorly load balanced
traffic."

-paragraph 5 ("Note that...") and 7 ("Furthermore, the...") should be
moved after paragraph 3

-paragraph 6: ("TE LSPs signaled..."): why do you exclude provisioned
LSPs? I can understand that there are cases where the information on
management plane provisioned LSPs is not needed/available, however I
think the proposed extensions should be more general and allow
collecting information on all the unconstrained LSPs in the TED.
Wouldn't it be possible to have two fields to include both the number of
unconstrained signaled and provisioned LSPs in the new TLV?

Section 3,
-maybe a figure would be appropriate showing the new TLV format.

Section 4,
-change ISIS to IS-IS 

> -----Original Message-----
> From: Loa Andersson [mailto:[email-masked]] 
> Sent: Monday, September 24, 2007 10:31 AM
> To: [email-masked]
> Cc: Ross Callon; David Ward