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

zhang.fei3@zte.com.cn Fri, 15 April 2011 09:55 UTC

Return-Path: <zhang.fei3@zte.com.cn>
X-Original-To: ccamp@ietfc.amsl.com
Delivered-To: ccamp@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9564BE06E9; Fri, 15 Apr 2011 02:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.193
X-Spam-Level:
X-Spam-Status: No, score=-97.193 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id box5pBmI4Eg4; Fri, 15 Apr 2011 02:55:21 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by ietfc.amsl.com (Postfix) with ESMTP id 7894CE0752; Fri, 15 Apr 2011 02:55:20 -0700 (PDT)
Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101461793122; Fri, 15 Apr 2011 17:52:46 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 54394.3565597523; Fri, 15 Apr 2011 17:43:55 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p3F9t6LV011215; Fri, 15 Apr 2011 17:55:06 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <76CD132C3ADEF848BD84D028D243C927AFAB6E@szxeml508-mbs.china.huawei.com>
To: Jie Dong <jie.dong@huawei.com>
MIME-Version: 1.0
X-KeepSent: C183F9D8:B87117E2-48257873:00342902; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OFC183F9D8.B87117E2-ON48257873.00342902-48257873.00367C2C@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Fri, 15 Apr 2011 17:55:09 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-15 17:55:08, Serialize complete at 2011-04-15 17:55:08
Content-Type: multipart/alternative; boundary="=_alternative 00367C2B48257873_="
X-MAIL: mse02.zte.com.cn p3F9t6LV011215
Cc: "ccamp@ietf.org" <ccamp@ietf.org>, "ccamp-bounces@ietf.org" <ccamp-bounces@ietf.org>
Subject: Re: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 09:55:23 -0000

Hi Jie

You are right, I neglected that LSP1 ID can be reused.

What about the revision below?

1.       LSP1 and LSP2 form associated bidirectional LSP, the extended 
ASSOCIATION object uses Tunnel-ID1 and LSP-ID1.
2.       TE make-before-break happens for recovery. LSP3 is established 
and LSP1 is tore down.  Then LSP3 and LSP2 form associated bidirectional 
LSP, and according to specification 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." it will use Tunnel-ID and 
LSP-ID of LSP2 in the extended ASSOCIATION object.  LSP3 is refreshed with 
the additional inserted  Extended Association Object.

3.       Later a new LSP is established using Tunnel-ID1 and LSP-ID1, and 
it may also need to associate with another reverse LSP4. Thus it may use 
Tunnel-ID1 and LSP-ID1 in the extended ASSOCIATION object for this new 
associated LSP. In this case, there are no two different associated LSPs 
using the same extended ASSOCIATION object. 

So the current description in recovery section will be revised.

Thank you again for your comments and scenarios.

Best regards

Fei



Jie Dong <jie.dong@huawei.com> 
2011-04-15 17:00

收件人
"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,
 
Please consider the following scenario: 
 
1.       LSP1 and LSP2 form associated bidirectional LSP, the extended 
ASSOCIATION object uses Tunnel-ID1 and LSP-ID1.
2.       TE make-before-break happens for recovery. LSP3 is established 
and LSP1 is tore down.  Then LSP3 and LSP2 form associated bidirectional 
LSP, and according to specification in this draft,  it will still use 
Tunnel-ID and LSP-ID of LSP1 in the extended ASSOCIATION object. 
3.       Later a new LSP is established using Tunnel-ID1 and LSP-ID1, and 
it may also need to associate with another reverse LSP4. Thus it may use 
Tunnel-ID1 and LSP-ID1 in the extended ASSOCIATION object for this new 
associated LSP. In this case, there may be two different associated LSPs 
using the same extended ASSOCIATION object. 
 
This means in some cases the extended ASSOCIATION object may not be global 
unique. Is this acceptable?
 
Regards,
Jie
 
From: zhang.fei3@zte.com.cn [mailto:zhang.fei3@zte.com.cn] 
Sent: Friday, April 15, 2011 2:04 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 

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