[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
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.
===
----- Original Message -----
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Cc: <ccamp@ops.ietf.org>
Sent: Friday, June 08, 2007 8:50 PM
Subject: I-D ACTION:draft-ietf-ccamp-mpls-graceful-shutdown-03.txt
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