Re: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Jie

In general，two unidirectional LSPs can be bound together based on the 
same global unique value under the same association type. Actually, TP' 
identifier is one kind of such global
unique value, which is defined in the Extended Association object. In 
other words, the association rule under the scenarios of recovery is still 
based on the same association type and association value. So " the IDs in 
the extended ASSOCIATION object may have nothing to do with the two 
associated LSPs" has no effect on the binding.

Of course, we can define a new object which carrys another kind of unique 
value which is irrelevant to the TP's identifier. That SHOULD works well, 
but I think the design rule is to reuse the existing object to do the same 
thing if it is possible.

Is the interpretation reasonable?

Thanks and best regards

Fei

Jie Dong <jie.dong@huawei.com> 
2011-04-15 10:07

收件人
"zhang.fei3@zte.com.cn" <zhang.fei3@zte.com.cn>
抄送
"ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-bounces@ietf.org" 
<ccamp-bounces@ietf.org>, Lou Berger <lberger@labn.net>
主题
RE: [CCAMP] poll on making 
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Fei,

Thanks for your prompt reply. 

Although the suggested statement could solve the problem of confliction, 
it still looks a little strange that the IDs in the extended ASSOCIATION 
object may have nothing to do with the two associated LSPs.

Regards,
Jie

From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn] 
Sent: Thursday, April 14, 2011 10:16 PM
To: Jie Dong
Cc: ccamp@ietf.org; ccamp-bounces@ietf.org; Lou Berger
Subject: Re: [CCAMP] poll on making 
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Hi Jie 

Thank you for the comments. :) 

According to the description in section 4 

"The Association ID MUST be set to its own signaled LSP ID (default); if 
known, it MAY be set to the LSP ID of the associated reverse LSP." 
"The first 16-bits MUST be set to its own tunnel ID (default); if known, 
it May be set to the tunnel ID of the associated reverse tunnel." 

What about the revision like this: "if known, it MAY be set to the LSP ID 
of the associated reverse LSP or inherited from the corresponding recovery 
LSP." 

I will address all the comments in the next version. 

Best regards 

Fei 

:) 

Jie Dong <jie.dong@huawei.com> 
发件人:  ccamp-bounces@ietf.org 
2011-04-14 20:22 

收件人
Lou Berger <lberger@labn.net>, "ccamp@ietf.org" <ccamp@ietf.org> 
抄送

主题
Re: [CCAMP] poll on        making 
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG        document

Hi authors,

One quick comment here.

In section 3.3 recovery considerations, it says
" LSP3... can share the same TE tunnel with LSP1 or not. ... This can be 
done by inserting the Extended ASSOCIATION object in LSP3's Path message 
with the same value as in LSP1's Path message."

This means LSP3 may use LSP1's IDs in the Extended ASSOCIATION object in 
its Path message, which may contain Tunnel_Num and LSP_ID different from 
its own and LSP2's.

However, in section 4, the specification of Association ID and Extended 
Association ID field says:
o Association ID:
  The Association ID MUST be set to its own signaled LSP ID (default); if 
known, it MAY be set to the LSP ID of the associated reverse LSP.
o Extended Association ID:
  ... the first 16-bits MUST be set to its own tunnel ID (default); if 
known, it May be set to the tunnel ID of the associated reverse tunnel.

Hence the two specifications conflict with each other.

Regards,
Jie

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Friday, April 01, 2011 5:24 PM
> To: ccamp@ietf.org
> Subject: [CCAMP] poll on making
> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document
> 
> All,
> 
> This is to start a two week poll on making
> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a ccamp working
> group document. Please send mail to the list indicating "yes/support"
> or "no/do not support".  If indicating no, please state your technical
> reservations with the document.
> 
> The poll ends Friday April 15.
> 
> Much thanks,
> Lou (and Deborah)
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp