Re: draft-aruns-ccamp-rsvp-restart-ext-01.txt

[Arun Satyanarayana <aruns@movaz.com>]

Hi Adrian,

My apologies for the delayed response. Thanks for going through the draft.

Please see responses inline.

Thanks,
_arun_
============================================================
On Tue, 27 Jul 2004, Adrian Farrel wrote:

> Hi,
>
> Thanks for coalescing your ideas into a single draft.
>
> Here are some random thoughts and questions for you to parse and then discard :-)
>
> Cheers,
> Adrian
>
>
> What if restarted node was doing PHP? Does egress (i.e. downstream node)
> have any record of the LSP? Presume so, and will be able to send back
> Resv saying implicit null.

Yes.

> Need to describe procedures for multiple node restart?

I hope some of this was covered during the meeting - will wait for
responses on the mailing list for this. This intent is to cover this with
compatibility to RFC3209 and RFC3473 in focus.

> Although the procedures build on RFC3473, I detect some pressures to integrate this work
> into MPLS implementations. That is: RFC3209-based implementations intend to take the Hello
> processing and nodal restart function from RFC3473 and also the new processing described
> in this draft. How do we feel about this? Is this pick-and-mix approach OK or should we
> say that it is time for packet-based solutions to cut over to GMPLS PSC?

I'm not sure if I understand this completely. The presented solution
builds on the existing Hello and Nodal Restart mechanisms in RFC3209 and
RFC3473. If the implication is that some LSPs are recovered using the
RFC3473 approach and some with the enhanced approach in this draft, such
a "mixed" implementation is not precluded by this draft. It is upto the
implementations to decide on doing this.

> Section 2.3
>       In the sender descriptor, the Recovery Label object MUST be
>       included, with the label value copied from the label value in the
>       Label object in the most recent associated Resv message sent to
>       the restarted node, for the LSP being recovered.
> Arguably you are trying to carry this single piece of Resv state on the RecoveryPath
> message.
> I guess you might that this is information that will be added to the first Path message
> sent by the restarted node, but this is not true. You must make a clear case for needing
> this information in advance of the Resv that you will receive in due course. I don't think
> that section 2.4.2 does this.

The solution does not modify Resv holdoff and subsequent transmit as
defined in RFC3473. It is possible (although not probable) that the
RecoveryTime is smaller than the Resv refresh interval, in which case, a
Resv may not be received within the Recovery Period. Hence, the restarting
node may not know if the label can be freed (as post-Recovery garbage
collection) or not. Including the Label as Recovery Label in the Sender
Descriptor covers this situation.

Will add some text to this effect.

> Section 2.3
> I think you need to exclude <MESSAGE_ID_ACK> and <MESSAGE_ID_NACK> as copied objects and
> allow them as defined by RFC2961.

Thanks for catching this! Will do.

> Section 2.3
>    All other objects from the most recent received Path message MUST be
>    included in the RecoveryPath message.
> I think you need to future-proof this by saying that the definition of new objects MAY
> specify that those objects MUST be omitted from the RecoveryPath
> message.

Ok.

> Section 2.3
>    After sending a RecoveryPath message and during the Recovery Period,
>    the node SHOULD periodically re-send the RecoveryPath message until
>    it receives a corresponding response.  A corresponding response is a
>    Message ID acknowledgment or a Path message matching the RecoveryPath
>    message.
> - Need to define whether it should continue to re-send for the whole period.
>   Compare with the relatively short duration implied in MsgID
> retransmission

The first sentence was intended to cover this (including the case when
Message IDs are not supported). Will clarify text.

> - Need to define "periodically"
>   Compare with the relatively rapid retransmission in MsgID
retransmission

See above - will clarify.

> - Need to define "matching". Is it enough that the received Path is for the
>    same LSP, or does it need to match the RecoveryPath in more detail?

It is sufficient that the received Path is for the same LSP - the Path
state may change since it has been updated by either the restarting node
or some node upstream when the restarting node was down. The restarting
should not have to transmit two Path messages - one matching the
RecoveryPath and one with the updated Path state in this case.

Will add text clarifying this.

> 2.4. Procedures for the Restarting Node
>    These procedures apply during the "state recovery process" and
>    "Recovery Period" as defined in Section 9.5.2 in [RFC3473].  Any
>    RecoveryPath message received after the Recovery Period has expired
>    MUST be discarded.  A node MAY send a PathTear message downstream
>    matching the discarded message.
> This is somewhat ambiguous. After all, a node MAY send a PathTear
> downstream at any time.
> If you are trying to say something more specific, please say it (e.g. "if
> there is no matching local LSP state").

The restarting node may choose to send a PathTear since it has all the
information to build a PathTear from the received RecoveryPath. The
statement is only intended as a hint to implementations - the decision is
left to the implementation.

> 2.4.2. Re-Synchronization Procedures
>    After receipt of the RecoveryPath message and, for non-ingress LSPs,
>    the corresponding Path message with a Recovery Label object, the
>    restarting node SHOULD
> Although it may be obvious, you should say how a node determines that it is the ingress
> for this LSP.

Ok.

> 2.4.2 needs to describe what to do if the RecoveryPath (and/or recovery Path) can be
> matched to a LSP for which state is known, but does not completely match the record that
> the restarting node has. The most pressing example is what to do when the control plane
> state recovered through RFC3473 and these extensions does not match the data plane state
> in the restarting node. There may be a judgment call here since the upstream and
> downstream neighbors clearly know what they are talking about, yet the data plane may be
> carrying active traffic.

Nodal restarts during signaling state transients (like re-routing?)
effectively only "delay" the signaling state transition itself. The
processing of the state transition on and around the restarting node
continues after the node restarts. Hence, a mismatch between the signaling
state and data plane state should be treated as if the data plane state is
following up to the change in the signaling state. The restart itself and
the subsequent RecoveryPath processing should not have an impact on this -
i.e., the judgement call is the same call as applicable to processing of
change in Path and Resv state regardless of a restart during such change.

> Is it worth noting that when moving from 3473 to include these extensions, it may be
> necessary to increase the recovery period as there is more processing to
> be done?

This mileage of this statement may vary on different forwarding
architectures and control plane implementations - would rather leave this
out.

> 2.4.3
> Is it the case that we may receive a Path message with Recovery_Label from upstream and
> not match state. If so, we wait to receive a RecoveryPath message. If we do not receive
> one in the Recovery Period, we treat the Path message as if we were processing according
> to RFC3473.
> BUT, if we are processing according to RFC3473 and we have not responded to a Path message
> received with Recovery_Label in the Recovery Period, isn't the LSP abandoned?

Per RFC3473 (section 9.5.2), the restarting node should process the Path
as a new setup.

> In other words, we will not send Resv for such an LSP until after the end of the Recovery
> Period.
> This is worse in section 2.5 if the downstream node does not support these extensions,
> when we will send no Resv for any recovered LSPs until after the Recovery Period.
>
> Would like to be able to globally de-select recovery path messages (if I have retained
> full state). Ideally this would be the default position so that RecoveryPath messages are
> not sent to a legacy node. I think Hello Capabilities should be used to select the
> willingness to receive RecoveryPath. (This would also ease the previous
> issue).

We did debate this one. Will consider this alternative (makes it easier to
introduce this now with the Capability object) - anybody having opinions
(either way) about this, please do respond.

> Section 3
> I think you have one more message exchange than you need.
> Imagine you have just one LSP.
> In the normal case you have just one message sent (RecoverySrefresh).
> In the non-recovered case you have three messages (RecoverySrefreh, Ack[Nack],
> RecoveryPath).
> *However* if the RecoverySrefresh was sent by the restarting node you would still have one
> message on the main case, and could drop to two messages in the non-recovered case
> (RecoverySrefresh, RecoveryPath).
> This would also make the RecoverySrefresh identical to the Srefresh,
> Further, since we know that this is used when only some of the state has been retained, it
> cuts down on the size of the RecoverySrefresh.

The current solution allows arbitrary grouping of Message ID's (from
previously received Path msgs) into multiple RecoveryPath SRefresh's -
this also implicitly provides scalability by allowing the staggering of
transmission of such RecoveryPath SRefresh's across some part of the
Recovery Period by the downstream neighbor. With the solution above, such
breakup may not be possible, since it is unclear as to when the downstream
neighbor decides to start sending RecoveryPath messages - i.e., how does
the downstream neighbor know when the "last" SRefresh has been transmitted
by restarted node.

> Section 3
> There is a slight issue with the Nack. We need to distinguish a Nack to an Srefresh (uses
> Message ID from a previous Resv) and a Nack to a RecoverySrefresh (uses Message ID from a
> previous Path). This is admittedly only a rare problem, but might occur with clashes of
> epoch and Message ID. This may be what you are trying to resolve using the new bit in the
> various Message ID objects (see below) but the reasoning is not clear from the text.
> Hint: if you use my proposal immediately above, this issue goes away and the new flag
> simplifies as below...
>
> 3.1. MESSAGE_ID ACK/NACK and MESSAGE_ID LIST Objects
> The trouble with defining an additional bit like this is we have to define the meaning of
> the bit on *any* Message_ID.
> Since (presumably) ordinary Srefresh messages may (might?) be interspersed with
> RecoverySrefresh why don't we have a way of distinguishing the messages rather than the
> contents of the object?
> Actually, I would argue that it is only the List Object that needs to be distinguished
> (with the caveat of the previous point).
>
> 3.2. Capability Object
> One of the lessons of the Restart_Cap Object is that we should be careful with the
> specification of capabilities objects.
> So, I am concerned that your new object is defined as a fixed length object with space for
> another 31 bits of information.
> How about TLVs?

We did debate this one as well. It would good to get some responses on
this one as well.

> 3.2.2. Compatibility
> You missed forwards compatibility. That is: reserved bits MUST be set to zero on
> transmission and MUST be ignored on receipt.

Thanks for catching this one. Will add the text.

> Nits
> ===
>
> Need to expand citations in the Abstract.

Ok.

> The Abstract could probably be usefully made shorter.

Ok.

> Section 3, second para. I don't think we need the description of Srefresh in normal
> processing.

Helps clarify the difference between normal SRefreshes and RecoveryPath
SRefreshes.

> Section 9. IANA
> Could you beef up this section please.
> The ideal is to show the names and characteristics of new messages/objects in this section
> so that IANA does not have to ask any further questions.
> You might like to reference draft-kompella-zinin-early-allocation-02.txt and
> draft-kompella-rsvp-change-02.txt to sort out values to use for pre-RFC work.

Ok.