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

From: "Newton, Jonathan" <[email-masked]>
Date: Wed, 5 Mar 2008 16:11:58 -0000

Hi Adrian / Lou,

With respect to the comments on the mechanism to trigger the ingress LSP
to perform a make-before-break, the draft already references 4736 for
definition of the required pathErr codes.

I have only had a quick look over 4920, but I would suggest that there
should not be overlap with crankback for a couple of reasons:
1/To me, crankback is targeted at LSP setup time rather than in-service
LSPs (stand to be corrected here!).
2/The ingress LSR seems to need to request the crankback information,
making this a much more involved implementation and requiring advanced
configuration at the ingress node.

With respect to Soft-preemption: Whilst I can clearly see the overlap,
to me there are some reasons why it may not be appropriate to combine
these in any way:
1/ We would want the ingress element to be aware of, in order to log,
the reason for the MBB request and soft-preemption only has a single
'soft preemption desired' flag.
2/ In the case of graceful shutdown, the actual removal of the resource
has not yet occurred and it may be up to operator discretion whether to
continue with the resource removal in the case that LSPs remain.  In the
case of soft-preemption, the event has already occurred (the pre-empting
LSP is already admitted).   

Cheers,
~Jon. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 27 February 2008 12:10
> To: Lou Berger
> Cc: [email-masked]
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> 
> Lou,
> 
> What you say about "triggered make-before-break" is interesting.
> We should also look at the overlap between this work and RFC 
> 4736 and RFC 4920.
> 
> Adrian
> ----- Original Message -----
> From: "Lou Berger" <[email-masked]>
> To: "Adrian Farrel" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, February 26, 2008 9:13 PM
> Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> 
> 
> > Here are some last call comments on this draft:
> >
> > - Opening/general comment:
> >   "Category: Informational" and
> >   "Conventions used in this document
> >
> >    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
> >    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> >    "OPTIONAL" in this document are to be interpreted as described in
> >    RFC-2119 [RFC2119]"
> >
> >    Given this is NOT a standards track document, the use of RFC2119
> >    style directives is misleading and should not be used.
> >
> > - Section 2, a nit:
> >   "temporarily or definitely".
> >
> >   I think you mean indefinitely.
> >
> > - Section 3:
> >   "- If the resource being shutdown is a last resort, it can be
> >    used. Time or decision for removal of the resource being shutdown
> >    is based on a local decision at the node initiating the graceful
> >    shutdown procedure. "
> >
> >   "Last resort" should be defined in technical terms.  Also it's not
> >   clear how this requirement is being met by the draft.
> >
> > - Section 4.2:
> >   "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."
> >
> >    This comment really applies to the whole section.  This section
> >    seems to be quite a bit more than what you'd expect to find in
> >    an informational document.  I think this comment given the next
> >    comment:
> >
> >    From a high-level perspective, it seems to me what's trying to
> >    accomplish in this section is to trigger MBB based on a
> >    management plane directive to gracefully shutdown a
> >    resource/link/node.  Given this, it seems that this objective
> >    is the same as that which soft-preemption provides, and that it
> >    doesn't really make sense to have two documents (which just so
> >    happen to be going through last call at the same time) that
> >    provide the identical functionality.  As this document is
> >    targeted as an informational document, perhaps it would be best
> >    to replace all of 4.2 with a recommendation to use soft
> >    preemption signaling procedures to support graceful shutdown.
> >
> >    Given this comment - I'll skip detailed comments on 4.2...
> >
> > Lou
> >
> > 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
> >>
> >>
> >>
> >
> >
> > 
> 
> 
> 
> 

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 7th Floor, The Point, 37 North Wharf Road, London W2 1LA

---

From: "AISSAOUI Mustapha" <[email-masked]>
Date: Thu, 6 Mar 2008 03:27:02 -0600

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. 
---------------------------------------------------------