RE: Clearing up your misunderstanding of the Association ID

[Nic Neate <[e-mail]>]

Thanks Adrian,

I think the key source of confusion is that RFC 4873 makes no reference to changing the specific procedures defined in 4872 for setting the association ID to the LSP ID of the protecting/protected LSP.

For example, in section 5.1:

   5.1.  Identifiers

   ...

   To allow distinguishing the working LSP (from which the signal is
   taken) from the protecting LSP, the working LSP is signaled by
   setting in the PROTECTION object the S bit to 0, the P bit to 0, and
   in the ASSOCIATION object, the Association ID to the protecting
   LSP_ID.  The protecting LSP is signaled by setting in the PROTECTION
   object the S bit to 0, the P bit to 1, and in the ASSOCIATION object,
   the Association ID to the associated protected LSP_ID.

Your email and discussion with Lou has helped expain the intention of 4873.  However, I still have some concerns about interworking of end-to-end and segment recovery - see my email to Lou.

Nic


-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 14:00
To: Nic Neate
Cc: [e-mail]
Subject: Clearing up your misunderstanding of the Association ID

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