[CCAMP] 答复: ODUflex resize question in RFC7139 (3924)

Fatai Zhang <zhangfatai@huawei.com> Tue, 25 March 2014 11:27 UTC

Return-Path: <zhangfatai@huawei.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id D4F141A0196 for <ccamp@ietfa.amsl.com>; Tue, 25 Mar 2014 04:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.078
X-Spam-Level: **
X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vJIL1si4RbUb for <ccamp@ietfa.amsl.com>; Tue, 25 Mar 2014 04:27:05 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) by ietfa.amsl.com (Postfix) with ESMTP id A99E21A03AA for <ccamp@ietf.org>; Tue, 25 Mar 2014 04:27:04 -0700 (PDT)
Received: from (EHLO lhreml203-edg.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCK41624; Tue, 25 Mar 2014 11:27:02 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com ( by lhreml203-edg.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 25 Mar 2014 11:26:31 +0000
Received: from SZXEMA407-HUB.china.huawei.com ( by lhreml401-hub.china.huawei.com ( with Microsoft SMTP Server (TLS) id; Tue, 25 Mar 2014 11:27:01 +0000
Received: from SZXEMA504-MBS.china.huawei.com ([]) by SZXEMA407-HUB.china.huawei.com ([]) with mapi id 14.03.0158.001; Tue, 25 Mar 2014 19:26:59 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: "Gruman, Fred" <fred.gruman@us.fujitsu.com>, Lou Berger <lberger@labn.net>
Thread-Topic: ODUflex resize question in RFC7139 (3924)
Thread-Index: AQHPR5LnuM3V7GwWEEecoIQRtod3b5rxqa+w
Date: Tue, 25 Mar 2014 11:26:58 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF85CADAFFE@SZXEMA504-MBS.china.huawei.com>
References: <20140321030515.3EF087FC387@rfc-editor.org> <0a6b01cf45dc$60228370$20678a50$@olddog.co.uk> <F82A4B6D50F9464B8EBA55651F541CF85CADA265@SZXEMA504-MBS.china.huawei.com> <E3FC9FA3-2FF3-451B-98AB-1E6DF9F8F876@gmail.com> <532F8162.2020201@labn.net> <5DF87403A81B0C43AF3EB1626511B292D3D0EB44@RCHEXMBP2.fnc.net.local>
In-Reply-To: <5DF87403A81B0C43AF3EB1626511B292D3D0EB44@RCHEXMBP2.fnc.net.local>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/8kJsfMCZGzA6-F6LskmmISRHMyU
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [CCAMP] =?gb2312?b?tPC4tDogT0RVZmxleCByZXNpemUgcXVlc3Rpb24gaW4g?= =?gb2312?b?UkZDNzEzOSAoMzkyNCk=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 25 Mar 2014 11:27:07 -0000

Hi Fred,

I think you are right because of the typos after I checked RFC7139 and my memory, since "PathTear" and "MUST" should be used consistently for these two cases.



发件人: Gruman, Fred [mailto:fred.gruman@us.fujitsu.com] 
发送时间: 2014年3月25日 2:57
收件人: Lou Berger; Fatai Zhang
抄送: ccamp@ietf.org
主题: ODUflex resize question in RFC7139 (3924)

Hi Fatai,

I'm reviewing the published OTNv3 RFCs to see if I need to update any of the work in OIF to remain aligned with these documents. As part of this review, I noticed the following regarding ODUflex resize (Section 7):

1. ODUflex resize - teardown of original connection

- For bandwidth increase, the PathTear message is used to delete the original connection
- For bandwidth decrease, the ResvErr message is used to delete the original connection

Is this really what we wanted?  If so, can you let me know why different procedures are required for the two cases?  (Or why not PathTear for both cases?)

I don't think that we've traditionally used ResvErr to teardown an LSP in GMPLS. We've used PathTear (or Path D&R followed by PathErr with path-state-removed). ResvErr is confusing to me, at least the specs in RFC 2205 that gets into discussions of blockage states, etc. Is this even appropriate to use ResvErr to tear down a connection, as my reading of RFC 2205 (although I'm not 100% certain on this) is that a ResvErr does not delete the Path or Resv states.

2. ODUflex resize setup with SE style.

Section 7 states: "Note that the SE style MUST be used at the beginning when creating a resizable ODuflex connection". For the bandwidth decreasing section, it states that "For the ingress node, a Path message with SE style SHOULD also be sent for decreasing the ODUflex bandwidth".  I would think that the "SHOULD" should be changed to "MUST".

Per RFC 2205 (Section 1.3), it is not possible to merge flowspecs when LSPs are signaled with different styles.  I think it would not be legal to have two LSPs with different signaling styles to share the same resource. 

I apologize for getting this question in now. I had thought I had kept up with the changes within the draft but I missed these details.

Lou, once these discussions are complete, I'll submit an errata to cover my issues.