[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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" <lberger@labn.net> 
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <ccamp@ops.ietf.org>
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-graceful-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