The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segment- recovery-00

[Nic Neate <Nic.Neate@dataconnection.com>]

Hi folks,

I have a question concerning the usage of the new ASSOCIATION object in
draft-berger-ccamp-gmpls-segment-recovery-00.

This object is defined in draft-ietf-ccamp-gmpls-recovery-e2e-signaling-00,
which only uses it to associate two LSPs in the same session.  Consequently,
it is defined with a 16 bit Association ID to identify the LSP it is
associating with (filled in as the LSP ID of that LSP).

The object is then used in draft-berger-ccamp-gmpls-segment-recovery-00 to
associate LSPs in different sessions - the segment recovery LSPs and the LSP
they are protecting.  See the following quote from section 2.

                                   ... Each segment recovery LSP is
   signaled as an independent LSP.  Specifically, the Sender_Template
   object uses the IP address of the node originating the recovery path,
   e.g., node C in the topology shown above, and the Session object
   contains the IP address of the node terminating the recovery path ...

   When [FRR] isn't being used, the association between segment recovery
   LSPs with other LSPs is indicated using the Association object
   defined in [E2E-RECOVERY].  The Association object is used to
   associate recovery LSPs with the LSP they are protecting.         

Clearly 16 bits is not enough to identify the associated LSP unless we know
which session it's in.

My question, then, is is it really necessary for the recovery LSPs to be in
different sessions from the LSP they are protecting?  Would it not be
possible to do this in a more similar way to Fast Reroute, where the backup
LSPs are in the same session as the protected LSP?

The reason this concerns me is that historically (as far as I am aware) LSPs
in different sessions have always operated independently of each other.
This draft takes protocol messages from an LSP in one session and propagates
them along an LSP in a different session, removing that independence.  While
I can't see a reason why this can't work, I do see it as a significant
complication to the protocol which we would do well to avoid.

If it really is necessary for the recovery LSPs to be in different sessions
then I think we need some text in the draft explaining exactly how the
Association ID is used in this scenario.

Please let me know what you think.  Thanks,

Nic