RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown

["AISSAOUI Mustapha" <Mustapha.Aissaoui@alcatel-lucent.com>]

Dear all,
below are my comments on this draft. I apologize if some of these have
already been raised.

Mustapha.

1. Second paragraph in the introduction states:
   "Graceful shutdown of a resource may require several steps. These 
   steps can be broadly divided into two sets: disabling the 
   resource in the control plane and removing the resource for 
   forwarding."
I do not believe that this document achieves the disabling of the
resource in the control plane. What it provides is a way to facilitate
diverting LSPs away from the resource by making it a last resort
resource. After IGP advertized the max TE metric of 0xFFFFFF for a link,
a CSPF LSP with zero bandwidth can still have its path go over this
link.

2. Second paragraph of Section 3 reads:
"- 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."
I do not believe this draft achieves this requirement. There is no
mechanism specified for a node to reject a new session reservation with
zero bandwidth over the resource being gracefully shutdown.

3. Second paragraph of Section 4 states:
"A node where a link or the whole node is being shutdown SHOULD 
   first trigger the IGP updates as described in Section 4.1, 
   introduce a delay to allow network convergence and only then use 
   the signaling mechanism described in Section 4.2. "
I propose to remove this altohgether. This does not guarantee that an
LSP for which a PathErr was sent will not be re-signaled over the
resource being shutdown. The reason being that most implementation
provide configurable delays between consecutive floodings of LSAs/LSPs.
It is up to the implementation at the headend node to decide how long to
hold for the list of interface address in the PathErr message to allow
for the flooding of the IGP TE information.

4. Last paragraph of Section 4.1.1 reads:
"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."
This is not exactly correct. If you wanted to have both outgoing LSPs
and incoming LSPs over the interface to be diverted, you will need to
enable the graceful shutdown procedures on both sides of the interface.
This means the procedures should be applied to the neigbour of a p2p
interface.

5. Section 4.2 states the following:
"The Graceful Shutdown 
   mechanism outlined in the following section, uses PathErr and 
   where available, Notify message, in order to achieve this 
   requirement. These mechanisms apply to both existing and new 
   LSPs."
As explained above, the mechanisms described in this document do not
prevent the establishment of new LSP over the resource being flagged for
graceful shutdown. Only existing LSPs at the time the user enables
graceful shutdown on a link are affected.

6. Second paragraph of Section 4.2.1 reads:
"When a graceful shutdown operation is performed along the path of 
   a protected LSP, based on a local decision, the PLR or branch 
   node MAY redirect the traffic onto the local detour or protecting 
   segment. In all cases, the PLR or branch node MUST forward the 
   PathErr to the head-end node, border node, or PCE."
This does not make sense. A PLR node will only take action on receipt of
the PathErr message for LSPs **it originates**. FRR procedures do not
react to PathErr messages unless you are proposing to change RFC 4379.

7. Last paragraph of Section 4.2.1 reads:
"When a head-end node, border node, or PCE receives a PathErr (or 
   Notify) message with error value of " Local link maintenance 
   required", it MAY trigger a make-before-break procedure. When 
   performing path computation for the new LSP, the head-end node, 
   border node, or PCE SHOULD avoid using the TE resources 
   identified by the IP address contained in the PathErr (or Notify 
   message)"
It should be clarified that the head-end node will exclude the use of TE
resource in path computation for a period of time only. The head-end
node has no way of knowing in the future if a link in a downstream node
is still flagged for graceful shutdown and thus cannot hold to the
information in PathErr forever. The fact that a metric of a link remains
set to 0xffffff in the TE database cannot be taken to mean that the link
is still in graceful shutdown. It just means that this link will
contibute to a high cost for a CSPF path using it. 
---------------------------------------------------------
> > >
> > > At 06:06 AM 2/13/2008, Adrian Farrel wrote:
> > >>Hi,
> > >>
> > >>The authors of this draft have been indicating that they
> > thought it was
> > >>complete for some time. They have now updated the document
> > to fix various
> > >>formatting nits and minor issues raised in the working group.
> > >>
> > >>Therefore, this email marks the start of a working group
> > last call on
> > >>http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gr
> aceful-shutdown-05.txt 
> > >>This is positioned to be an Informational RFC.
> > >>
> > >>The last call will end on Wednesday 5th March at 12 noon
> > GMT. Please send
> > >>your comments to the list.
> > >>
> > >>Thanks,
> > >>Adrian