Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt

From: [email-masked]
Date: Fri, 08 Jun 2007 15:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Graceful Shutdown in GMPLS Traffic Engineering Networks
	Author(s)	: Z. Ali, et al.
	Filename	: draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
	Pages		: 9
	Date		: 2007-6-8
	
GMPLS-TE Graceful shutdown is a method for explicitly notifying 
   the nodes in a Traffic Engineering (TE) enabled network that the 
   TE capability on a link or on an entire Label Switching Router 
   (LSR) is going to be disabled. GMPLS-TE graceful shutdown 
   mechanisms are tailored towards addressing the planned outage in 
   the network.  
    
   This document provides requirements and protocol mechanisms so as 
   to reduce/eliminate traffic disruption in the event of a planned 
   shutdown of a network resource. These operations are equally 
   applicable for both MPLS and its GMPLS extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-ccamp-mpls-graceful-shutdown-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 11 Jun 2007 14:11:51 +0100

Hi,

The authors have indicated that this draft is complete and ready for WG last 
call.

As is now our customary ritual, the chairs have done a pre-last call review. 
In this case, I am the lucky reviewer.

Although the changes below are relatively minor in substance, they are many. 
I feel it would be helpful to reviewers in last call if you could provide an 
update with these issues fixed. As soon as I see it published we can 
initiate last call (subject to the Chicago meeting not getting in the way).

Thanks,
Adrian

===
"GMPLS" in title, abstract, and first use in main text.
Unfortunately, "GMPLS" is still not a recognised term in the wider IETF.
You must, therefore, expand the acronym where it first occurs.
===
Abstract line 1
s/shutdown/Shutdown/
===
Abstract para 1
s/towards/toward/
===
Abstract para 1
s/addressing the planned/addressing planned/
===
Abstract
"These operations are equally
   applicable for both MPLS and its GMPLS extensions."
If so, why have you named the document as you have.
Wouldn't a better name have been:
Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
===
Conventions used in this document
Section contains a reference to "[i]" that is not resolved.
===
Contents table
Formatting is scrappy
===
1. Terminology
s/LSR - Label Switching Device./LSR - Label Switching Router./
===
1. Terminology
"LSP - An MPLS Label Switched Path"
What happened to GMPLS?
===
1. Terminology
The definition for "Head-end or Ingress node:" is very hard to read and, I 
suspect, non-intuitive. Redefining "head-end" to mean "sometimes also a 
transit node" will really fry people's minds! If you need a term for a node 
that performs a specific function, I suggest that you create a new term 
rather than overloading an existing one.
===
1. Terminology
"GMPLS - The term GMPLS is used in this document to refer to both
 classic MPLS, as well as the GMPLS extensions to MPLS."
You mean LDP?
===
1. Terminology
TE Link
a. You need to provide an expansion of FA-LSP, and probably a reference
b. Your definition has not caught all of the possible uses of a TE link 
(such
   as link bundles). Perhaps you want to use a generic definition?
===
2. Introduction
"disable Traffic Engineering on a TE Link"
This begs the question: what is traffic engineering?
Are you disabling TE on the link, or are you disabling data traffic on the 
link?
I think some work throughout the document to clarify the difference between:
- the impact of disabling a link (viz. traffic cannot flow)
and
- disabling TE advertisement (viz. the link's capacity is withdrawn from the 
TED).
The latter being the way to gracefully advertise the former.
===
2. Introduction  para 1
s/graceful reroute/gracefully reroute/
===
2. Introduction
"The node initiating the graceful shutdown condition
   SHOULD delay the removal of the resources for forwarding, for
   some period determined by local policy."
The point is not the delay. The point is the delay between disabling the 
resource in the control plane and removing the resource for forwarding.
Can you clarify, please.
===
2. Introduction para 2
s/allow control/allow the control/
===
2. Introduction para 2
"Similarly, trigger for the graceful
   shutdown event is a local matter at the node initiating the
   graceful shutdown."
a. Similarly to what?
b. s/trigger/the trigger/
===
2. Introduction
"traditional shutdown operation of an interface"
I like this phrase.
My family have been shutting down interfaces for generations. We use 
traditional techniques involving spun grass and a hand axe.
===
2. Introduction
Last line
s/node/nodes/
===
Section 3.
Formatting is broken.
Indentation and bullets.
===
Section 3  2nd requirement
This reads a bit odd. Would it be better as:

- Once an operator has initiated graceful shutdown of a network
resource, no new TE LSPs may be set up that use the resource.
Any signaling message for a new LSP that explicitly specifies the
resource, or that would require the use of the resource due to
local constraints, must be rejected as if the resource were
unavailable.

- It is desirable for new LSP setup attempts that would be rejected
because of graceful shutdown of a resource (as described in the
previous requirement) to avoid any attempt to use the resource by
selecting an alternate route or other resources.
===
Section 3
"   - It is required to reduce/eliminate traffic disruption on the
   LSP(s) using the network resources which are about to be
   shutdown."
Is this the requirement, or is the requirement to give the ingress the 
opportunity to perform this function if policy and configuration require it, 
and if network resources allow?
===
Section 3
"   - In order to make rerouting effective, it is required to
   communicate information about the TE resource under graceful
   shutdown."
I know what you mean, but you have been terribly non-specific. Communicate 
what information from whom to whom?
It is probably:
- the fact that the resource is being shut down
- from the node where the resource is located
- to all other network nodes
===
Page 4 (and several other places)
Excessive page throws
===
Section 4.1
  "Setup request for new LSPs over the TE resource being gracefully
   shutdown SHOULD be rejected using the existing mechanisms that
   are applied when the TE resource is not available."
Are you sure that you don't want to reject the setup using one of your new 
error codes?
===
Section 4.1.1
   The "local
   TE link maintenance required" error code is defined in [PATH-
   REOPT].
s/local TE link/local link/
In the whole of this section, and the rest of the document, please be 
careful to distinguish Error Codes and Error Values. In this case you are 
talking about an Error Value that is associated with the "Notify" Error 
Code. It is necessary to describe both fields.
===
Section 4.1.1
Suddenly you are abbreviating to "GS". I think that is inadvisable.
===
General question.
Would it help the ingress or PLR if the PathErr reporting imminent graceful 
shutdown included additional information such as the likely time of shutdown 
in the data plane, and the likely time of restart?
We do have mechanisms for this function in RFC 4783.
===
Section 4.1.1
   When a head-end LSR receives a Path Error (or Notify) message
   with sub-code "Local Maintenance on TE Link required Flag", it
   SHOULD immediately trigger a make-before-break procedure. A head-
   end node SHOULD avoid the IP address contained in the PathErr (or
   Notify message) when performing path computation for the new LSP.
a. The name of the subcode continues to mutate :-)
b. The first SHOULD is *entirely* a matter of local policy. It is a MAY.
c. The second SHOULD is ambiguous as you haven't told us which
   IP address is contained in the PathErr. Since the Error Value is
   related to a TE Link, presumably it is the TE link IP address. But
   what if it is a node being shut down? What if it is only a lambda
   being shut down?
   Can you not use some more informative fields and reason codes
   as provided in draft-ietf-ccamp-crankback-06.txt or RFC4872?
d. Please be consistent and use "Path Error" or "PathErr". I prefer the
   second.
===
Section 4.1.1
   If the resource being gracefully shutdown is on the Path of the
   protecting LSP/ local detour, the branch node/ PLR reroutes the
   protecting LSP/ local detour just a head-end LSR would reroute
   any other LSP.
Need to tidy up the text.
But what are you saying? One LSP is the same as another, and reroute takes 
place from the head end. That is all.
===
Section 4.1.2
   RSVP error-code "Routing Problem" (24) [RSVP-TE] is
   needed:
         9 (TBA)   Local component link maintenance required
Why is this a subcode of Routing Problem, when you have used a subcode of 
Notify for the case of the whole TE link?
More importantly, the use of Routing Problem is likely to cause us to run 
into questions about whether the upstream transit nodes will panic and tear 
the LSP or not. Using the Notify Error Code is a much safer approach.
===
Section 4.1.2
   The head-end LSR MAY still use the IP address
   contained in the Path Error or Notify message in performing path
   computation for rerouting the LSP. This is because, this address
   is an IP address of the component link and the flag is an
   implicit indication that the TE link may still have capacity to
   admit new LSPs.
If the IP address is the address of the component link being shut down, then 
it cannot be used in the new path. If, however, the address is the address 
of the link bundle, then it can still be used.
===
Important
I think you are missing an element of procedure that applies at the node 
doing shut down.
please state clearly which addresses are placed in which fields when 
reporting graceful shutdown for a:
- node
- te link
- component link
- label resource
===
Section 4.1.2
   However, if the ERO is computed such that it also
   provides details of the component link selection(s) along the
   Path, the component link selection with IP address contained in
   the Path Error or Notify message SHOULD be avoided.
The use of "SHOULD" implies that there may be a good reason to continue to 
use the address. Please supply the text
"MAY continue to use it in order to ...."
===
Section 4.1.3
Doesn't give enough information to the head end to avoid the problem node in 
its reroute computations.
Perhaps you need to reorder your document to say that the IGP pieces happen 
first, and the shutdown node should wait to allow the IGP to converge before 
sending out PathErr and or Notify?
===
Section 4.2.1
Why not include also specifying Minimum LSP Bandwidth as greater than the 
available bandwidth and greater than the maximum LSP bandwidth?
This goes further than "discouraging" the use of the TE link, it makes it 
impossible to use even for zero-bandwidth LSPs.
I'm pretty sure this was discussed several times in the WG.
===
Section 4.2.1
   Neighbors of the node where graceful shutdown procedure is in
   progress SHOULD continue to advertise the actual unreserved
   bandwidth of the TE links from the neighbors to that node,
   without any routing adjacency change.
Doesn't this mean that the TE link is only shut down in one direction? So 
unidirectional LSPs would still try to use the link.
===
Section 5
I don't think you will get this past the Security ADs.
What happens if graceful shutdown is:
- spoofed
- hidden (i.e. the signaling or routing is blocked)
You have not mentioned the IGP security.
it might be a good idea to include a reference to Luyuan's draft.
===
Section 6
You need to give IANA far clearer instructions than this.
Please look at a recent RFC for an example.
I suggest RFC 4873 section 9.5
===
References
Personally, I like references to RFCs to use the RFC numbers as this is far 
quicker to look up. But you don't have to make this change.
===