RE: The ASSOCIATION object usage in draft-berger-ccamp-gmpls-segm ent-recovery-00

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

That's clarified the ASSOCIATION usage for me, thanks (I was thinking the
Association ID had to identify an LSP, not just another ASSOCIATION object).
I'm willing to conceed that 64k associations is probably enough.

To reiterate my primary question though, is there a strong reason that the
recovery LSPs have to be in a different session to the protected LSP?  If
you simply disagree that there's any issue, or believe the solution you've
presented to be the simplest, then fine.

Thanks,

Nic

-----Original Message-----
From: Movaz Networks - Louis Berger 
Sent: Friday, April 23, 2004 1:32 PM
To: Nic Neate
Cc: Movaz Networks - Louis Berger; Movaz Networks - Igor Bryskin;
adrian@olddog.co.uk; dimitri.papadimitriou@alcatel.be;
ccamp@ops.ietf.org; jplang@ieee.org; yakov@juniper.net
Subject: Re: The ASSOCIATION object usage in
draft-berger-ccamp-gmpls-segment-recovery-00


Nic,
         Note that the 16 bits are scoped within the association source (IP 
address).  So there is really 48 bits in the association ID.  Do you belive 
that 64K associations per IP address is insufficient???

Lou

At 08:10 AM 4/23/2004 -0400, Nic Neate wrote:
>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.