RE: update GMPLS signaling documents

["Fong Liaw" <fongliaw@yahoo.com>]

Yanguang

I am jumping in here, Lou can certainly add or
clarify further. see below.


> 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.

Since transit node of the FA-LSP does not see the RSVP
messages that use the FA, we only need to consider 
the ingress and egress node. If the egress node restarts, 
the worst case is that its upstream node sends an ERO 
consisting a unrecognized interface address. Since the 
Path message will carry RECOVERY_LABEL (replacing 
SUGGESTED_LABEL), the egress node knows that it might 
not have complete information yet, and can hold on to 
the Path message until the FA-LSP is established.  
All the information is there, so implementation 
can be completely within the egress node. It does work, 
just not specified enough.

Ingress node will have to know the dependency, so not
a problem there.

> 
> 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?
> 

We still need to resynchronize the state since the other
side might have connections that are in progress. The 
reason for resynchronization is to make sure both side
have done the same to the in-progress connections, not
just to synchronize the established states.

The value of the RESTART_CAP will set to non-zero values.

> 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.

Can you give us explicit examples as to why and what do 
you gain by giving different values for PSC, TDM ?

> 
> 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?
> 

The use of RECOVERY_LABEL address all the above questions.

> 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?
> 

The use of same src_instance is just to help speed up
the resynchronization using Srefresh message. If the
instance number is different, the resynchronization
uses Path message. Both procedure will recover to 
the same state.

> 
> 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?
> 
> 

This has been discussed in the initial restart draft
and was decided that if an ingress node wants to preserve
the LSP, it needs to remember enough information in the
configuaration file/storage. I believe any developer will
be able to figure out what to save in the configuration
store to make this happen if the vendor decides to offer
this as a feature. Not sure there is much to be specified
if we take this approach.  

If people want to allow configuration-file-less procedure,
would they care to give explicit application examples ?

Regards, 
-Fong

> 
> 
> 
> 
> 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

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com