Subject: Clearing up your misunderstanding of the Association ID

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Nov 2008 13:59:56 -0000

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

---

From: Nic Neate <[email-masked]>
Date: Tue, 18 Nov 2008 15:07:36 +0000

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: [email-masked]
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.

 Then, in Section 16...

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Nov 2008 22:34:14 -0000

So...

Nic and I sat down today and discussed this particluar issue: how to 
interpret the Association ID in a received Path message in order to 
associate a new LSP with some other LSP at a merge point.

There are two cases that arise. If the new LSP is part of a segment 
protection relationship, the Association ID is a unique "set identifier" in 
the context of the Association Source. If the LSP is part of an end-to-end 
protection relationship, the Association ID identifies the LSP ID of the 
protection partner.

Nic's concern (and he convinced me for a while :-) is that there is an issue 
with distinguishing this case when a segment protection LSP is, itself, 
protected along its whole path in an end-to-end manner.

Having thought about this more, I believe the following processing rules 
that can be applied to make this work. I would be interested in any use 
cases (in particular message arrival variants) that anyone believes breaks 
these rules.

For each Association Object on the received Path message...

1. Look for an existing LSP with association object that matches 
{Association Source, Association ID} from the new Path message. If found, 
this is segment protection protecting from the Association Source to this 
node. Stop.

2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID} 
and with LSP ID equal to received Association ID. The Association Source can 
(and probably should) also be checked against the sender source address on 
the matched LSP. If found, this is end-to-end protection from Association 
Source to dest.

Note that there may be multiple Association objects on a Path message. Note 
also, that 4872 requires the use of the same Session specifically to enable 
the use of the Association ID to LSP ID mapping.

As far as I can see, this addresses all cases.

Cheers,
Adrian

----- Original Message ----- 
From: "Nic Neate" <[email-masked]>
To: "Aria - Adrian Farrel Personal" <[email-masked]>
Cc: <[email-masked]>; "labn - Lou Berger" <[email-masked]>; "ALU - 
Dimitri Papadimitriou" <[email-masked]>
Sent: Tuesday, November 18, 2008 3:07 PM
Subject: RE: Clearing up your misunderstanding of the Association ID

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.

   5.1.  Identifiers

   ...

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: [email-masked]
Subject: Clearing up your misunderstanding of the Association ID

Hi Nic,

association type.

 Then, in Section 16...

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.

Cheers,
Adrian

---

From: Nic Neate <[email-masked]>
Date: Wed, 19 Nov 2008 22:00:49 +0000

Hi Adrian,

As we discussed earlier, there's also an Association ID / LSP ID space overlap issue here that's worth drawing out.

The branch node is generating ASSOCIATION objects for both end-to-end protection and segment protection, and always uses the same Association Type and Source.  The Association IDs that it chooses must therefore not clash.  In the end-to-end case, the Association ID is actually an LSP ID.  Your first rule for the merge node is to check the Association ID against other segment Association IDs.  Therefore, LSP IDs allocated to end-to-end protected LSPs must not clash with (existing or future) segment Association IDs.

LSP IDs are actually allocated by the management tool / MIB interface (mplsTunnelInstance).  I think this therefore amounts to a restriction on the MIB interface / management tool.

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 22:34
To: Nic Neate
Cc: [email-masked]
Subject: Re: Clearing up your misunderstanding of the Association ID

So...

Nic and I sat down today and discussed this particluar issue: how to interpret the Association ID in a received Path message in order to associate a new LSP with some other LSP at a merge point.

There are two cases that arise. If the new LSP is part of a segment protection relationship, the Association ID is a unique "set identifier" in the context of the Association Source. If the LSP is part of an end-to-end protection relationship, the Association ID identifies the LSP ID of the protection partner.

Nic's concern (and he convinced me for a while :-) is that there is an issue with distinguishing this case when a segment protection LSP is, itself, protected along its whole path in an end-to-end manner.

Having thought about this more, I believe the following processing rules that can be applied to make this work. I would be interested in any use cases (in particular message arrival variants) that anyone believes breaks these rules.

1. Look for an existing LSP with association object that matches {Association Source, Association ID} from the new Path message. If found, this is segment protection protecting from the Association Source to this node. Stop.

2. Look for existing LSP with matching {dest, tunnel ID, extended tunnel ID} and with LSP ID equal to received Association ID. The Association Source can (and probably should) also be checked against the sender source address on the matched LSP. If found, this is end-to-end protection from Association Source to dest.

Note that there may be multiple Association objects on a Path message. Note also, that 4872 requires the use of the same Session specifically to enable the use of the Association ID to LSP ID mapping.

Cheers,
Adrian

----- Original Message -----
From: "Nic Neate" <[email-masked]>
To: "Aria - Adrian Farrel Personal" <[email-masked]>
Cc: <[email-masked]>; "labn - Lou Berger" <[email-masked]>; "ALU - Dimitri Papadimitriou" <[email-masked]>
Sent: Tuesday, November 18, 2008 3:07 PM
Subject: RE: Clearing up your misunderstanding of the Association ID

Thanks Adrian,

   5.1.  Identifiers

   ...

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: [email-masked]
Subject: Clearing up your misunderstanding of the Association ID

Hi Nic,

 Then, in Section 16...

Cheers,
Adrian

---

From: Nic Neate <[email-masked]>
Date: Thu, 27 Nov 2008 11:41:22 +0000

Hi all,

Following up on this Association ID discussion, I think we're now in sync on the technical issues.  It is possible to signal both end-to-end and segment protection using association type 1 as defined.  However, the usage of the Association ID is different in the two cases, resulting in
-  complex processing rules for ASSOCIATION objects at merge nodes
-  an overlap in Association ID and LSP ID spaces
-  a corresponding restriction on the mplsTunnelInstance values available to branch nodes.

Our proposal (draft-rhodes-ccamp-rsvp-recovery-fix) was to avoid these issues by using a different association type for segment recovery.  That would be a non-back-compatible change, and if adopted then existing segment recovery implementations would have to be modified.  However, I think it also clarifies the protocol and could improve interoperability longer term.

Does anyone have a strong preference for one option or the other?  Or any alternatives to propose?

Thanks,

Nic

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nic Neate
Sent: 19 November 2008 22:01
To: Aria - Adrian Farrel Personal
Cc: [email-masked]
Subject: RE: Clearing up your misunderstanding of the Association ID

Hi Adrian,

Nic

-----Original Message-----
From: Aria - Adrian Farrel Personal
Sent: 18 November 2008 22:34
To: Nic Neate
Cc: [email-masked]
Subject: Re: Clearing up your misunderstanding of the Association ID

So...

Cheers,
Adrian

----- Original Message -----
From: "Nic Neate" <[email-masked]>
To: "Aria - Adrian Farrel Personal" <[email-masked]>
Cc: <[email-masked]>; "labn - Lou Berger" <[email-masked]>; "ALU - Dimitri Papadimitriou" <[email-masked]>
Sent: Tuesday, November 18, 2008 3:07 PM
Subject: RE: Clearing up your misunderstanding of the Association ID

Thanks Adrian,

   5.1.  Identifiers

   ...

Nic

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

Hi Nic,

 Then, in Section 16...

Cheers,
Adrian