Clearing up your misunderstanding of the Association ID

["Adrian Farrel" <adrian@olddog.co.uk>]

Hi Nic,

I think there are a bunch of issues that you are raising, and we should try 
to itemise them to make sure we close them all off.

For the issue of the use of Association ID in segment protection, I think 
you may have misread the relevant RFCs. I don't believe any new Association 
ID type is needed to achieve the function: we can simply use the 4872 
association
type.

Section 4.3 of 4872 says...
   The ASSOCIATION object, introduced in Section 16, is used to
   associate the working and protecting LSPs.

   When used for signaling the working LSP, the Association ID of the
   ASSOCIATION object (see Section 16) identifies the protecting LSP.
   When used for signaling the protecting LSP, this field  identifies the
   LSP protected by the protecting LSP.

That gives us the basis of everything we need.

Then, in Section 16...
   The ASSOCIATION object is used to associate LSPs with each
   other.  In the context of end-to-end LSP recovery, the association
   MUST only identify LSPs that support the same Tunnel ID as well
   as the same tunnel sender address and tunnel endpoint address.
   The Association Type, Association Source, and Association ID
   fields of the object together uniquely identify an association.

I suspect that this is the source of your misunderstanding. But note that in 
4873, the context is not end-to-end LSP
recovery so the restriction on the Tunnel ID does not apply.

If you follow this through now, I suspect you will discover that most of 
your issues go away.

Cheers,
Adrian