[CCAMP] ODUflex resize question in RFC7139 (3924)

"Gruman, Fred" <fred.gruman@us.fujitsu.com> Mon, 24 March 2014 18:57 UTC

Return-Path: <fred.gruman@us.fujitsu.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 E35451A026C for <ccamp@ietfa.amsl.com>; Mon, 24 Mar 2014 11:57:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.011
X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, 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 pZO2OMuaOcI7 for <ccamp@ietfa.amsl.com>; Mon, 24 Mar 2014 11:57:17 -0700 (PDT)
Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com []) by ietfa.amsl.com (Postfix) with ESMTP id 4491F1A02B6 for <ccamp@ietf.org>; Mon, 24 Mar 2014 11:57:14 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.97,722,1389765600"; d="scan'208";a="47889596"
Received: from rchexhcp2.fnc.net.local ([]) by fncnmp01.fnc.fujitsu.com with ESMTP/TLS/AES128-SHA; 24 Mar 2014 13:57:13 -0500
Received: from RCHEXMBP2.fnc.net.local ([]) by RCHEXHCP2.fnc.net.local ([]) with mapi id 14.02.0347.000; Mon, 24 Mar 2014 13:57:13 -0500
From: "Gruman, Fred" <fred.gruman@us.fujitsu.com>
To: Lou Berger <lberger@labn.net>, Fatai Zhang <zhangfatai@huawei.com>
Thread-Topic: ODUflex resize question in RFC7139 (3924)
Thread-Index: AQHPR5Ld227JZCRnzUS4fKeHpohJ3Q==
Date: Mon, 24 Mar 2014 18:57:13 +0000
Message-ID: <5DF87403A81B0C43AF3EB1626511B292D3D0EB44@RCHEXMBP2.fnc.net.local>
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>
In-Reply-To: <532F8162.2020201@labn.net>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--46.946600-0.000000-31
x-tm-as-user-approved-sender: Yes
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/f5Bs7uvv9n4BEPWSwJLK9jsfeyA
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [CCAMP] ODUflex resize question in RFC7139 (3924)
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: Mon, 24 Mar 2014 18:57:21 -0000

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.