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

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 13 Feb 2008 11:06:05 -0000

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 26 Feb 2008 16:13:30 -0500

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.
>
>The last call will end on Wednesday 5th March at 12 noon GMT. Please 
>send your comments to the list.
>
>Thanks,
>Adrian
>
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 27 Feb 2008 12:09:56 -0000

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