Re: Working group last call: draft-ietf-ccamp-pc-spc-rsvpte-ext-02

[Lou Berger <[e-mail]>]

Authors,

I have some LC comments.

- First a general comment:  I think the document could be
   significantly improved by centralizing the definition of
   processing to a new "Procedures" section, rather than the
   current approach of scattering the definitions across multiple
   "illustrative" sections.  I know this is a significant editing
   change, but it would result in a extension that is easier to
   implement, subject to less misinterpretation and less likely to
   have holes.  I see this as a desirable change, but not required.

- As always, please cleanup any idnits identified issues.
   In particular note:

   == No 'Intended status' indicated for this document; assuming Proposed
      Standard

- The document needs to be run through a spell checker, there are a
   number of spelling errors.

- A general style comment, for consistency I think the document
   should use the following message names (note the lower cased
   "message"):
   OLD                       NEW
   "Path Message"            "Path message"
   "Resv Message"            "Resv message"
   "Path Tear Message"	    "PathTear message"
   "Path Error Message"      "PathErr message"

   Note if you choose to spell out PathTear message, per rfc2205,
   it's "Path Teardown".

- General comment on document, you use "data-plane" and "Data
   Plane".  Please pick one.

- Short title
  >Internet-Draft       RSVP-TE Ext for LSP adoption-ID        October 2008

   How does " RSVP-TE Ext for LSP adoption-ID" relate to the title
   "RSVP-TE Signaling Extension For The Conversion Between
   Permanent Connections And Soft Permanent Connections In A GMPLS
   Enabled Transport Network."?  Perhaps you can use an alternate
   short title?

   Also, I suggest adding some consistency in the document in how
   you refer to the overall process/function.  Among others, you
   use "handover", "adoption", "conversion".  While not a critical
   change, I think picking one and using it consistently would
   improve the document.

- Abstract
  >  Failure conductions and subsequent roll back are also illustrated
             ^^^^^^^^^^^ -- this should be "conditions", no?

- General comment
   The document uses:
  >Handover flag
  >HANDOVER flag
  >H flag
  >H-bit

   Please pick one and be consistent, perhaps "H bit"? see RFC3471
   for an example.  Also, given that the title of the document is
   "Conversion" isn't this really the "C" bit/flag?  But that's
   already taken, so I guess you could align the title by replacing
   "Conversion" with "Handover" in the tile..)

- Section 5:

  >  At the ingress node NMS
  >  initiates the transfer of LSP related information residing within
  >  Management Plane to RSVP-TE records within Control Plane.

   I can only guess what this sentence is trying to say. Can you
   rephrase?

  >  The following of the section illustrates in detail the procedure in
  >  cases in success and failures.

   I think you mean "defines" not "illustrates".  That is, unless
   you're going for an informational RFC...

- Section 5.1

  >  Upon receiving a Path Message, each node SHOULD check the consistence
  >  of the actual Data Plane status of such resource. Say the check goes
  >  OK (failure cases are illustrated in the next sections), then a
  >  RSVP-TE record for the LSP is created associating it to the
  >  corresponding Data Plane state.

    It is not clear (at least to me) at all what an implementation
    needs to do to conform to this sentence.  Perhaps you mean
    something like "Upon receiving a Path Message containing an
    Administrative Status Object with the H bit set, a node SHOULD
    check if there is local Path state matching the MP to CP
    Handover request.  When no local Path state exists, the node
    SHOULD confirm that there is existing data plane state that
    corresponds to the Path message. In the case where such data
    plane state exists (failure cases are illustrated in the next
    sections), local Path state SHOULD be installed."

    Also, why aren't the above "SHOULD"s not "MUST"s?

  >  The node accepts all the LSP
  >  information carried in the Path message (if the node is not the
  >  Ingress LER of the LSP, otherwise the information is sent from
  >  relevant MP entity) and stores it in Path State Block.

   How an implementation stores state is a local matter and outside
   the scope of a protocol spec, so this sentence should be dropped.

  >After propagating handover Path message

  you mean "After propagating a Path message with the H bit set",
  right?

  >  This means that any memory about the former MP

   does "memory about" = state?

  >If a Confirmation message was requested, then it is generated.

   Does this refer to ResvConf?  If then you can something like
   "Normal ResvConf processing occurs as normal."

   So what happens once the ingress receives the Resv message with
   the H bit set?  Does it send a Path message with the H bit
   clear?  Does the H bit stay set for the lifetime of the LSP?

- Section 5.2.1.1.

  >  case the network status MUST be immediately rollbacked to the one

   Please define "network status" (or rephrase)?

  >  the Path message or the Resv message forwarding.  In this paragraph

   can't failures occur during any stage of message processing?
   e.g., as discussed in 5.1.


- Section 5.2.1.2.

  >  consist on the unreachability of a node of the LSP.

   "unreachability", "of the LSP"??? do you mean "inability to reach a
   node along the path of the LSP""?

- Section 5.2.2.1.

  >   In case a failure occurs during the Resv Message forwarding, things
  >   are quite different, because after the handover procedure an LSR is
  >   not able to distinguish an LSP created by the Control Plane from an
  >   LSP created by the Management Plane and then moved to the Control
  >   Plane.

    Why not?  The H bit is still set in the corresponding Path
    State during almost all cases of Resv processing.

    This does highlight that the case of a "handover" Resv being
    received at a node that no longer has corresponding path state.
    I think you should add something about how this case is
    handled.

  >   Considering to have a reliable message delivery mechanism,

    I'm not sure what this clause means or adds.  Can you rephrase
    or drop it?  Maybe something along the lines of "When a failure
    occurs in the processing of a Resv message that contains an
    Administrative Status Object with the H bit set, the node MUST
    send ..."

  >   Please note that the failure occurred after the handover procedure
  >   was successfully completed in LSR B. This means that LSR B is no
  >   longer able to know if the LSP was created by the Control Plane or a
  >   handover procedure took place.

    Same point as above, it will know due to H bit being set in the
    corresponding Path (and Resv) state.

  >   Upon receiving a Path Tear message, LSR B would delete the LSP also
  >   from the Data Plane point of view.  To prevent this from happening,
  >   LSR A MUST set the handover flag in the Path Tear message.

     I see in reading section 10.2 that this is a different and new
     "handover flag" carried in the Error Spec Object.  (It would
     have been really useful if you made this clear somewhere more
     than just buried in section 10.2).  In any case this bit isn't
     really needed as , the downstream node will already have this
     information due to the H bing having been set in the
     corresponding Path message/state.  So I propose dropping the
     Error Spec Object "handover flag".

  >   The
  >   downstream node move the LSP ownership back to the Management Plane
  >   and MUST NOT modify the Data Plane.

     What happens on the upstream transit and ingress nodes?  This
     needs to be specified.

- Section 5.2.2.2.
  >   ...Path Error message (with the
  >   Path_State_Removed flag set)

   Is the setting of the flag a "MUST" or a "SHOULD" in the prior
   section it was a "SHOULD".

  >   Please note that the failure occurred after the handover procedure
  >   was successfully completed in the Egress LER.  This means that it is
  >   no longer able to know if the LSP was created by the Control Plane or
  >   a handover procedure took place.
  >
  >   Upon receiving a Path Tear message, the downstream nodes would delete
  >   the LSP also from the Data Plane point of view.  To prevent this from
  >   happening, the Path Tear message MUST include the Handover flag.
  >

    Same 2 comments as previous section. (i.e., don't need new
    error spec object H bit, as H bit set in corresponding Path
    message/state.)

  >   ... Due to this
  >   fact, a configurable timer MUST be set on the Ingress LER after
  >   sending the path and on LSR A after forwanding it.  When the timer
  >   expires, if no Resv or Path Error message is received, the handover
  >   procedure MUST be aborted and the LSP ownership returned to the
  >   Management Plane.
  >

    I understand the timer on the ingress node, but setting a timer
    on all transit nodes seems to be a pretty major departure from
    common/standard RSVP processing.  For instance, why is such a
    timer set on normal Path forwarding.  I think the timer on the
    transit nodes really must be dropped.

    Also, the document needs to specify the processing rules for
    what happens when the timer expires (on the ingress) and
    perhaps when the timer should be cleared too.

  >   After sending the path message, the ingress LER sets a timer.  If non
  >   Resv message is received before the timer expires, then the adoption
  >   procedure is aborted and the Ingress LER MAY signal it by a Path Tear
  >   message with the H bit set.

     The document needs to define how standard soft state
     processing, in particular the handling of timeouts, is
     impacted by this document.

- Section 5.2.2.3.

  >   not release the data-plane resources because in both nodes the H-bit
  >   is set in the PSB.

    I believe you mean "local Path state" rather than "PSB",
    correct?

  >   data-plane resources because the H-bit is set in the PSB.

    Same comment.

    So does this section impact existing recovery procedures in any
    way?  It seems so, at least in the "release of data-plane
    resources".  If procedures are impacted, then there needs to be
    some formal RFC2119 language defining the impacted processing.

- Section 6.1:

 >   is no more under control of RSVP-TE, which is no more able to "see"

    I suggest using the word "longer" in place of "more" in this
    sentence.

  >  This Section covers the procedure needed to manage
  >   this procedure as a dual, opposite procedure respect to the one
  >   described in previous section.

    This is really not to coherent a sentence, can you rephrase?

  >   Ingress node MUST send out a Path message, with Handover and Reflect
  >   bits in Admin Status set.  No action is taken over Data Plane and
  >   Control Plane keeps track of special handover state the LSP is in.
  >   Transit and Egress nodes, upon reception of such handover Path,
  >   propagate it without any Data Plane action, retaining the handover
  >   state information associated to the LSP.  After that, every node
  >   waits until the Handover bit is received back in the Resv.  Then a
  >   PathTear is issued and the whole LSP information record is cleared
  >   from RSVP- TE data structures.  In other words, a normal LSP tear
  >   down signaling is exchanged between nodes traversed by the LSP, but
  >   handover flag set in Path message indicates that no Data Plane action
  >   has to correspond to Control Plane signaling.  At the end of handover
  >   tear down signaling flow, the LSP is released from Control Plane
  >   point of view, but its Data Plane state is still unmodified and it is
  >   now owned and controllable by MP.

    Two points:
    1) This section really needs a full rewrite to formally state
       what are the required ("MUST") and recommended ("SHOULD")
       actions for each node type (ingress/transit/egress).

    2) I think it needs to be clear that the action described in
       this paragraph are only taken when both the H and D bits are
       set in the Admin Status Object.  (Thanks to Igor for
       clarifying this for me.)

- Section 7.

    So sections 7 and 8 provide duplicate functionality.  Section 7
    is actually a fairly major extension in its own right and could
    be used/specified as a standalone function.  The Section 7
    function is really an extension  to what is already largely
    present in RFC2745.  Rather than propose a fairly major change
    to this section (and consequently delaying the whole document)
    I propose that Section 7 be dropped from this document and that
    if the Authors want to pursue this functionality further it be
    done so in a separate / stand-alone document.

    Is this acceptable?  I'll deffer detailed comments on this
    section assuming it is.

- Section 8

  >   downstream label of this interface and the incoming interface ID of
  >   egress node.

    Why isn't egress node ID sufficient?

  >   Re-iterating this procedure for each transit node along the

    I suggest replacing "Re-iterating" with "By repeating"

 >   the consistence of resource in Data Plane down to the port level or

    I suggest replacing "consistence" with "consistency".

   It's probably worth a note to cover the case where the data
   plane path continues beyond the egress and that this can be
   reflected in signaling state using RFC4003/3473.

- Section 10.1

This section should not use RFC2119 language for the existing bits,
unless those bits are being modified by this document.  So the
definition of the existing bits, should simply refer back to the
existing documents.

keep:
  >   - Reflect (R): 1 bit - Defined in [RFC3471]

drop:
  >      When set, indicates that the edge node SHOULD reflect the object/
  >      TLV back in the appropriate message.
  >

keep:
  >
  >   - Lockout (L): 1 bit - Defined in [RFC4872]

drop:
  >      When set, forces the recovery LSP to be temporarily unavailable to
  >      transport traffic (either normal or extra traffic).
  >

keep:
  >   - Inhibit Alarm Communication (I): 1 bit - Defined in [RFC4783]

drop:
  >      When set, indicates that alarm communication is disabled for the
  >      LSP and that nodes SHOULD NOT add local alarm information.
  >

  >   - Call Control (C): 1 bit - Defined in
  >   draft-ietf-ccamp-gmpls-rsvp-te-call-04 [2]

drop:
  >      This bit is set when the message is being used to control and
  >      manage a Call.
  >

keep:
  >   - Testing (T): 1 bit - Defined in [RFC3471]

drop:
  >      When set, indicates that the local actions related to the
  >      "testing" mode should be taken.
  >

keep:
  >   - Administratively down (A): 1 bit - Defined in [RFC3471]

drop:
  >      When set, indicates that the local actions related to the
  >      "administratively down" state should be taken.
  >

keep:
  >   - Deletion in progress (D): 1 bit - Defined in [RFC3471]

drop:
  >      When set, indicates that that the local actions related to LSP
  >      teardown should be taken.
  >

  >   The H bit must be used in conjunction with the R flag when is set in
    why isn't this a "MUST"?

- Section 10.2

  >   It is possible that a failure, such as the lost of DCN connection or

    OLD "lost" --> NEW "loss"

  >   In this case the LSP adoption MUST be interrupted and the ownership
  >   of the LSP MUST be moved back to the Plane it belonged to.  It is
  >   important that the transaction failure MUST not affect the Data
  >   Plane.  The LSP MUST be kept in place and no traffic hit MUST occur.

    These directives seem to belong elsewhere in the document.  If
    you're simply restating the expected outcome of previously
    defined procedures, "must" or even "will" should be used rather
    than "MUST".

  >   messages include an Error_Spec_Object (the Path_State_Removed flag
  >   SHOUL always be set) specifying the causes of the failure, while the

    Duplicate (and misspelled) directive.

  >   This memo introduces a new Flag and a new Error Code (with different
  >   Error Values) into the Error_Spec Object, defined in [RFC2205].

    As discussed above under sections 5.2.2.1/2 I think the
    HandOverFailure flag is redundant and should be dropped. I'll
    deffer related detailed comments assuming it is.

That's it.

Lou


On 4/17/2009 12:25 PM, Lou Berger wrote:
>
> This email begins a two week working group last call on
> draft-ietf-ccamp-pc-spc-rsvpte-ext-02.txt
>
> http://tools.ietf.org/html/draft-ietf-ccamp-pc-spc-rsvpte-ext-02
>
> Please send your comments to the list or the authors before the last
> call closes on May 1, 2009.
>
>
>
>