Re: [CCAMP] FW: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt

Fatai Zhang <zhangfatai@huawei.com> Wed, 16 March 2011 10:05 UTC

Return-Path: <zhangfatai@huawei.com>
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 120653A6925 for <ccamp@core3.amsl.com>; Wed, 16 Mar 2011 03:05:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.606
X-Spam-Level:
X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=2.288, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vY0K+9QO0Fan for <ccamp@core3.amsl.com>; Wed, 16 Mar 2011 03:05:57 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6A45D3A6922 for <ccamp@ietf.org>; Wed, 16 Mar 2011 03:05:57 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI500D7NANHU9@szxga04-in.huawei.com> for ccamp@ietf.org; Wed, 16 Mar 2011 18:04:30 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI500FMFANHJ6@szxga04-in.huawei.com> for ccamp@ietf.org; Wed, 16 Mar 2011 18:04:29 +0800 (CST)
Received: from z41162a ([10.70.76.157]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI500FOJANHN0@szxml04-in.huawei.com> for ccamp@ietf.org; Wed, 16 Mar 2011 18:04:29 +0800 (CST)
Date: Wed, 16 Mar 2011 18:04:29 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Rajan Rao <rrao@infinera.com>, ccamp@ietf.org
Message-id: <F12F6887DA8C4F66AD1DE575C4AB99E8@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
Content-type: multipart/alternative; boundary="Boundary_(ID_NW0xDMetluQ/hX3jYSdqDQ)"
X-Priority: 3
X-MSMail-priority: Normal
References: <35F57DFB766CCA4FBF4F3F680FA9D2CA7D7C3C54A9@SV-EXDB1.infinera.com>
Subject: Re: [CCAMP] FW: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 16 Mar 2011 10:05:59 -0000

Hi Rajan,

I have some comments on this draft.

(1) Confused Lo ODU Terminology

I think you may have some misunderstanding on LO ODU terminology. According to the ITU-T recommendation, a LO ODUj could represent the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container. For example, 100GE over ODU4, this ODU4 is Lo ODU4, not Ho ODU4.

(2) Non-normative signal types

When [OTN-FWK] document was discussed quite long time ago, the experts from CCAMP raised that ODU1e, ODU3e1, ODU3e2 are non-normative, which should not be referenced.

(3) IMCD advertisement for link CD in Section 6.2

For link CD, it is assumed that it can support OTU2-ODU2-ODU1-ODU0, and in IMCD2, ODU2-ODU1-ODU0 is advertised, why "ODU1-ODU0" should be advertised? Actually, for the link CD, it can not support ODU1->ODU0. 

In addition, based on your approach, if link CD can support OD4-ODU3-ODU2-ODU1-ODU0 capability, how to advertise this information?

(4) In section 5.1, 5.2 and 5.3

There is some text to describe "Maximum Bandwidth", however, this parameter is not used in RFC4201. 

In Section 5.3, it says "Implementations may choose to ignore this attribute and consider per ODU-rate Unreserved Bandwidth defined in Interface Switch Capability Descriptor for "G.709 ODUk" encoding type. " . How about "Maximum Reservable Bandwidth"? 

(5) In Section 3

In this section, OTU, ODUk, ODUj links are listed, but I don't see much difference between from the descrition in your draft. Could you clarify this?
In addtion, could you clarify how these types of links are advertised based on the protocol defined in the next sections of your draft.




Thanks
 
Fatai
 
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972912
Fax: +86-755-28972935

----- Original Message ----- 
From: "Rajan Rao" <rrao@infinera.com>
To: <ccamp@ietf.org>
Sent: Tuesday, March 15, 2011 9:14 AM
Subject: [CCAMP] FW: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt


Hi,

We have submitted updates to the following draft. Please review & comment.

http://tools.ietf.org/html/draft-ashok-ccamp-gmpls-ospf-g709-03

Thanks
Authors 

 
-----Original Message-----
From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Monday, March 14, 2011 4:15 PM
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ashok-ccamp-gmpls-ospf-g709-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

Title           : OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks
Author(s)       : A. Kunjidhapatham, et al.
Filename        : draft-ashok-ccamp-gmpls-ospf-g709-03.txt
Pages           : 30
Date            : 2011-03-14

As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328].

The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and
flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation.  

This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ashok-ccamp-gmpls-ospf-g709-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.



--------------------------------------------------------------------------------


> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>