Re: [mpls] [CCAMP] Requirement for singled ended provisioning of associated bidirectional LSPs
zhang.fei3@zte.com.cn Tue, 19 April 2011 11:12 UTC
Return-Path: <zhang.fei3@zte.com.cn>
X-Original-To: mpls@ietfc.amsl.com
Delivered-To: mpls@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2B4EAE072B; Tue, 19 Apr 2011 04:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.812
X-Spam-Level:
X-Spam-Status: No, score=-98.812 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, 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 0XtMV0n-ziGk; Tue, 19 Apr 2011 04:12:39 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfc.amsl.com (Postfix) with ESMTP id A938FE06C8; Tue, 19 Apr 2011 04:12:37 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 125203246204556; Tue, 19 Apr 2011 19:11:39 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 4886.4317891712; Tue, 19 Apr 2011 19:12:29 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p3JBCPXe047096; Tue, 19 Apr 2011 19:12:25 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn)
In-Reply-To: <6477E10CC7D76444A479B9AC31F262A9DDDB4723@ESESSCMS0365.eemea.ericsson.se>
To: Attila Takacs <Attila.Takacs@ericsson.com>
MIME-Version: 1.0
X-KeepSent: 35B01643:99EC0612-48257877:00390B84; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
Message-ID: <OF35B01643.99EC0612-ON48257877.00390B84-48257877.003D8DC6@zte.com.cn>
From: zhang.fei3@zte.com.cn
Date: Tue, 19 Apr 2011 19:12:30 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-04-19 19:12:24, Serialize complete at 2011-04-19 19:12:24
Content-Type: multipart/alternative; boundary="=_alternative 003D8DBF48257877_="
X-MAIL: mse01.zte.com.cn p3JBCPXe047096
Cc: "mpls@ietf.org" <mpls@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>, mpls-bounces@ietf.org, ccamp-bounces@ietf.org
Subject: Re: [mpls] [CCAMP] Requirement for singled ended provisioning of associated bidirectional LSPs
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2011 11:12:41 -0000
Hi Attila, see inline [Fei] Best regards Fei Attila Takacs <Attila.Takacs@ericsson.com> 发件人: ccamp-bounces@ietf.org 2011-04-19 17:38 收件人 Lou Berger <lberger@labn.net>, "ccamp@ietf.org" <ccamp@ietf.org> 抄送 主题 Re: [CCAMP] Requirement for singled ended provisioning of associated bidirectional LSPs Hi all, Please see inline [at]. -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Friday, April 15, 2011 3:50 PM To: Attila Takacs Cc: ccamp@ietf.org Subject: Requirement for singled ended provisioning of associated bidirectional LSPs [Subject: Was Re: [CCAMP] poll on making draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document] > 2) Point related to the contents of the draft. > > As this is a technical point, and independent of the poll. I'll start > a new thread on this in a separate mail. > As I (as WG member, not chair) understand it, you are questioning the requirement for the "single sided mode". I think this is a good question. As you pointed out, I believe I suggest that this question be raised, by the authors, on the TP list. [at] Fei, is/was there any conclusion on the TP list? [Fei]Although I put it on the TP list, there was no discussion on this topic. See the old link : http://www.ietf.org/mail-archive/web/mpls-tp/current/msg05277.html I forward the discussion to the MPLS list this time, hope we can get more feedback. RFC5645 seems to allow for independent provisioning of associated, but it doesn't preclude the "single sided mode". It also has requirements 11 and 12 which are certainly facilitated by "single sided mode". [at] I think requirements 11 and 12 can be fulfilled by using an association id on both LSPs with "double-sided mode" at LSP establishment or at a later point for association. [Fei] Agree, but the complexity of "double-sided mode" is almost the same as compared to "single-sided mode" at LSP establishment. Assume that the time costs for path and resv message are the same vlaue "TC" For "single-sided mode", the time costs are 3TCs(2TCs for LSP1 from west to east plus 1TC for LSP2 from east to west). As for "double-sided mode", the binding happens when the path refresh message are sent out based on the solution described in the document, so the time cost is generally the same :one path-resv circle plus one path message processing. In the case LSPs should be associated later on, after establishment, a simple "single sided" solution might be used to allow single-touch association, this is mainly an optimization not a required feature I guess. In this case besides the association id one may also send the LSP id of the reverse direction to which the association should be established, which in turn would result in the resignalling of that LSP with the association id. Doing more elaborate "single-sided" signaling, e.g, including reverse bw and qos parameters seems to me to add unnecessary complexity. [Fei] In this case, the association id is the LSP id of the reverse direction ("if known, it MAY be set to the LSP ID of the associated reverse LSP"), there is no need to carry reverse bw and qos parameters. They are only carried when the reverse LSP does not exist. I will clarify it in next version. It is more complex for double sided provisiong mode in this case that the LSPs are associated after establishment, and the cost is one path-resv refresh circle plus one path refresh message processing. Best regards, Attila I believe you also raise some valid issues with the current definition of the processing rules. I'll defer my comments on this for now. Lou BTW This isn't the first time that "single sided mode" has been suggest. I seem to remember discussing a proposal on this from Juha Heinanen at the Adelaide IETF. I also know of one vendor-specific implementation that never made it to the field or the WG. On 4/15/2011 9:42 AM, Lou Berger wrote: > Attila, > So we have two points here: > 1) WG procedure related > > So this mail is in response to a poll. As your answer is (a). I (as > chair) know how to interpret you position, i.e., "Yes/Support". > > 2) Point related to the contents of the draft. > > As this is a technical point, and independent of the poll. I'll start > a new thread on this in a separate mail. > > Thanks, > Lou > > On 4/14/2011 1:06 PM, Attila Takacs wrote: >> Hi Lou, all, >> It would be nice to clarify the scope of the proposed extension. >> I would say (a) if that does not include commitment to work on the "single sided mode". To my current understanding that operation mode is not required for associated bidirectional LSPs. There is no discussion in the document about which operation mode is really needed, if I'm not mistaken similar comments were raised in Beijing, but this is not addressed in the document. Hence my confusion. >> Thanks, >> Attila >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, April 13, 2011 2:43 PM >> To: Attila Takacs >> Cc: ccamp@ietf.org >> Subject: Re: [CCAMP] poll on making >> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document >> >> Attila, >> So I appreciate your comment, and would like to have this discussion, but I think I need some clarification from the perspective of the poll. >> I'm unsure if you're saying: >> (a) support this document becoming a WG document and would like >> discuss the point raised below in the context of a WG document or >> (b) do NOT support this document becoming a WG document until the >> point you raise becomes a WG document >> >> Can you clarify if you mean (a) or (b)? >> >> Lou >> >> On 4/12/2011 4:27 PM, Attila Takacs wrote: >>> Hi authors, >>> >>> You talk about two provisioning models: "single" and "double" sided modes. >>> >>> Double sided is clear, it uses independent signaling for the two LSPs. >>> >>> Single sided, if I understood correctly, somehow binds the two LSP signaling phases together. I have some doubts that this model is needed. It seems to complicate operation and it also begs the question why not use bidirectional LSPs instead. >>> >>> I think two independently signaled LSPs with the addition of the proposed Association object would do the job addressing the associated bidirectional LSP requirements, so that transit nodes are also aware of the binding. >>> >>> Best regards, >>> Attila >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Friday, April 01, 2011 11:24 AM >>> 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 >>> >>> >>> >>> >> >> >> >> _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp