Re: update GMPLS signaling documents

[Yangguang Xu <xuyg@lucent.com>]

Lou,

There were two emails (see below) raising some good questions about the re-start
procedure for RSVP-TE. I haven't seen any open discussion on these two emails,
nor changes in the new drafts. Are those issues solved? Would you please update
us?

Thanks,

Yangguang

This one was sent to MPLS WG.

///////////////////////////////////////////////////////////
I have some questions/concerns on the restart mechanism as
specified in draft-ietf-mpls-generalized-rsvp-te-04.txt.  I
have listed them below.

If a node that is terminating hierarchical LSPs restarts,
there is an ordering issue during resynchronization, since
the LSPs would depend on other FA-LSPs the interface IDs for
which would have been generated dynamically. So the
mechanism as described will not work, unless this
information is preserved across restarts - in which case we
might as well preserve other information as well, and avoid
resynchronization.

Also, let us consider a node that can preserve state across
restarts, and hence does not need its state to be synced by
its peer.  How will it advertise this in the RESTART_CAP
object?

If a node supports PSC as well as TDM or LSC interfaces, it
might want to advertise different set of parameters in the
RESTART_CAP object for data LSPs as opposed to SONET/WDM
LSPs which form bearer channels in transport networks.
Currently this is not possible.

According to 9.5.1. (procedures for restarting LSR): "When
sending the corresponding outgoing Path message the node
SHOULD include a SUGGESTED_LABEL object with a label value
^^^^^^
matching the outgoing label from the now restored forwarding
entry."

This has a conflict with 9.5.2.  Consider the case where
adjacent nodes B and C restart, and B has another adjacent
node A, and C has another adjacent node D.  B and C will get
resynced by A and D, and during this process, they will
resync. each other. While resyncing each other, they act as
neighbors of a restarting LSR, and hence according to 9.5.2,
MUST include the SUGGESTED_LABEL.

Also according to 9.5.2: "During the recovery period, new
Path state being advertised to the restarted neighbor SHOULD
not include the SUGGESTED_LABEL object in the corresponding
outgoing Path message.  This will prevent the restarting
node from erroneously reusing a saved forwarding entry."

I guess this would mean that if suggested labels are used
during new LSP setup (as they are likely to be while
provisioning lightpaths - to reduce latency), then new LSP
setup will not be allowed during resyncing?

In section 9.3: "When a new Hello message is received from
the neighbor, the LSR must determine if the fault was
limited to the control channel or was a nodal fault.  This
determination is based on the Src_Instance received from the
neighbor.  If the value is different than the value that was
received from the neighbor prior to the fault, then the
neighbor should be treated as if it has restarted.
Otherwise, the the fault was limited control channel."

If two adjacent nodes restart, how can each of them
determine that the other also just restarted?  This would
need that the src_instance received from the neighbor is
preserved across restarts - was that the intent?


Another one

///////////////////////////////////////////////////////
I think I've found a problem with the nodal fault recovery mechanism
in draft-ietf-mpls-generalized-rsvp-te-04.txt, section 9.5.

If the node that fails is the ingress node (i.e., an LER), then the LSP
won't recover since there is no upstream neighbor from which this
restarting LER will receive a PATH message.  Therefore, the LER
won't send a PATH message to its downstream neighbor, and the
LSP recovery fails.

In other words, recovery only seems to work if an LSR or an Egress
LER experiences nodal failure.

Perhaps this could be fixed by having neighbors of the restarting
node send a RESV for any Resv state held?






Lou Berger wrote:
> 
> FYI -
> 
> Updated versions of the signaling and RSVP-TE documents have been
> submitted. The CR-LDP version is forthcoming.  The updates address comments
> received during the August meeting and comment period.
> 
> Here's a summary of changes:
> 
> draft-ietf-mpls-generalized-signaling-06.txt
> Changes from previous version:
> o Removed redundant encoding type
> o Revised Admin Status Usage (per comments and also removed potential race
> condition) o Clarified text related to interface bundling (To be consistent
> with updated bundling draft.)
> o Minor editorial changes and clarifications
> o Revised G-PID (per comments on list)
> 
> draft-ietf-mpls-generalized-rsvp-te-05.txt
> Changes from previous version:
> o Revised Admin Status Usage (per comments and also removed potential race
> condition)
> o Clarified text related to interface bundling (To be consistent with
> updated bundling draft.)
> o Added IF_ID ERROR_SPEC Object (Per comments, supports Control Channel
> Separation by allowing identification of errored interface.)
> o Added U bit to Label RRO subobject (Per comment, to match defined ERO.)
> o Clarified usage of Restart_Cap o Replaced use of Suggested_Label during
> recovery with new Recovery_Label (Per last WG session)
> o Added IANA Considerations
> o Minor editorial changes and clarifications
> 
> For those who don't want to wait, the drafts are available from:
> http://www.labn.net/docs/draft-ietf-mpls-generalized-signaling-06.txt
> http://www.labn.net/docs/draft-ietf-mpls-generalized-rsvp-te-05.txt
> 
> Lou