[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Working group last call: draft-ietf-ccamp-pc-spc-rsvpte-ext-02
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.