Re: [CCAMP] 答复: WG Last Call on draft-ietf-ccamp-flexible-grid-ospf-ext-04

Dieter Beller <Dieter.Beller@nokia.com> Mon, 04 July 2016 11:23 UTC

Return-Path: <dieter.beller@nokia.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6083712D095 for <ccamp@ietfa.amsl.com>; Mon, 4 Jul 2016 04:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.168
X-Spam-Level:
X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvXTSM5yDgBA for <ccamp@ietfa.amsl.com>; Mon, 4 Jul 2016 04:23:14 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A058212B068 for <ccamp@ietf.org>; Mon, 4 Jul 2016 04:23:13 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 0BAA133D5AB7D; Mon, 4 Jul 2016 11:23:09 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u64BNBHL003049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Jul 2016 11:23:11 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u64BN9VP008021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Jul 2016 13:23:10 +0200
Received: from [149.204.106.226] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 4 Jul 2016 13:23:09 +0200
To: Zhenghaomian <zhenghaomian@huawei.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
References: <F82A4B6D50F9464B8EBA55651F541CF85CDBA104@SZXEMA504-MBS.china.huawei.com> <be6989bb-6327-9795-8501-f6ba1340e90a@nokia.com> <E0C26CAA2504C84093A49B2CAC3261A438D3EF8E@SZXEMA504-MBX.china.huawei.com>
From: Dieter Beller <Dieter.Beller@nokia.com>
Organization: Nokia
Message-ID: <bb37c3f5-5f87-37c4-53d0-7884af6a2e56@nokia.com>
Date: Mon, 04 Jul 2016 13:23:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <E0C26CAA2504C84093A49B2CAC3261A438D3EF8E@SZXEMA504-MBX.china.huawei.com>
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.239.27.39]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ccamp/C_pi5Vz-MsKM5iPuTQZusUryJbI>
Subject: Re: [CCAMP] 答复: WG Last Call on draft-ietf-ccamp-flexible-grid-ospf-ext-04
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 04 Jul 2016 11:23:16 -0000

Hi Haomian,

thanks for you swift reply.

Here is my suggestion: add the following 2 sentences at the end of the last paragraph in section 4.1:

As  the "Max LSP Bandwidth at priority x" fields in the generic part of the Interface Switching Capability
Descriptor [RFC4203] are not meaningful for flex-grid DWDM links, the values of these fields MUST be set
to zero and MUST be ignored. The Switching Capability Specific Information as defined below provides the corresponding information for flex-grid DWDM links.



Thanks,
Dieter


On 01.07.2016 09:03, Zhenghaomian wrote:

Hi, Dieter,

 

Thanks for your comments, please see my reply inline:

 

 

 

发件人: CCAMP [mailto:ccamp-bounces@ietf.org] 代表 Dieter Beller
发送时间: 2016630 16:50
收件人: Fatai Zhang; CCAMP (ccamp@ietf.org)
主题: Re: [CCAMP] WG Last Call on draft-ietf-ccamp-flexible-grid-ospf-ext-04

 

Hi Fatai, CCAMPers,

I've reviewed this document and I have the following comment:

Section 4.1:

4.1. ISCD Extensions for Flexi-grid
 
         Value                       Type
 
         -----                       ----
 
      152 (TBA by IANA)           Flexi-Grid-LSC capable
 
   Switching Capability and Encoding values MUST be used as follows:
 
              Switching Capability = Flexi-Grid-LSC
 
              Encoding Type = lambda [as defined in https://tools.ietf.org/html/rfc3471" rel="nofollow">RFC3471]
 
   When Switching Capability and Encoding fields are set to values as
   stated above, the Interface Switching Capability Descriptor MUST be
   interpreted as in [https://tools.ietf.org/html/rfc4203" rel="nofollow">RFC4203] with the optional inclusion of one or
   more Switching Capability Specific Information sub-TLVs.


draft-ietf-ccamp-flexible-grid-ospf-ext-04 defines the Switching Capability Specific Information sub-TLVs, but the ISCD as defined
in RFC4203 contains "Max LSP Bandwidth at priority x" fields in the  generic ISCD part and these fields do IMHO not make
sense for flex grid (see below). The draft does not say how these fields shall be filled.
[Haomian] I agree with what you said, the ‘Max LSP Bandwidth at priority x’ don’t make sense for flexi-grid, so we need to skip this in ISCD section. You are right we need to specify how to fill in even if we skip this section. How about we add the following statement in the end of section 4.1?

Given the Switching Capability set to Flexi-Grid-LSC, the ‘Max LSP Bandwidth at priority x (x from 0 to 7)’ defined in [RFC4203] MUST be fulfilled with 0 and ignored.

Do you think it’s clear enough?

Excerpt from RFC4203:

1.4.  Interface Switching Capability Descriptor
 
   The Interface Switching Capability Descriptor is a sub-TLV (of type
   15) of the Link TLV.  The length is the length of value field in
   octets.  The format of the value field is as shown below:
 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Switching Cap |   Encoding    |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 0              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 2              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 3              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 4              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 5              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 6              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Max LSP Bandwidth at priority 7              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Switching Capability-specific information              |
   |                  (variable)                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 
   The Switching Capability (Switching Cap) field contains one of the
   following values:
 
      1     Packet-Switch Capable-1 (PSC-1)
      2     Packet-Switch Capable-2 (PSC-2)
      3     Packet-Switch Capable-3 (PSC-3)
      4     Packet-Switch Capable-4 (PSC-4)
      51    Layer-2 Switch Capable  (L2SC)
      100   Time-Division-Multiplex Capable (TDM)
      150   Lambda-Switch Capable   (LSC)
      200   Fiber-Switch Capable    (FSC)
 
   The Encoding field contains one of the values specified in https://tools.ietf.org/html/rfc4203#section-3.1.1" rel="nofollow">Section
   https://tools.ietf.org/html/rfc4203#section-3.1.1" rel="nofollow">3.1.1 of [https://tools.ietf.org/html/rfc4203#ref-GMPLS-SIG" title='"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description"' rel="nofollow">GMPLS-SIG].
 
   Maximum LSP Bandwidth is encoded as a list of eight 4 octet fields in
   the IEEE floating point format [https://tools.ietf.org/html/rfc4203#ref-IEEE" title='"IEEE Standard for Binary Floating-Point Arithmetic"' rel="nofollow">IEEE], with priority 0 first and
   priority 7 last.  The units are bytes (not bits!) per second.
 
   The content of the Switching Capability specific information field
   depends on the value of the Switching Capability field.



Minor nits:


page 5 typo:
'Chanel Spacing' instead of 'Chan
nel Spacing'

[Haomian] Thanks, will update in the next version.



page 7 editorial:
'Flexi-Grid-LSC capable': capable should be removed (already included in the LSC abbreviation).

[Haomian] Thanks, will use ‘Flexi-Grid-LSC’ instead of ‘Flexi-Grid-LSC capable’, the replacement will also be applied in other a few places in the draft.


Thanks,
Dieter

On 25.06.2016 04:35, Fatai Zhang wrote:

Hi all,

 

This starts a two week working group last call on [draft-ietf-ccamp-flexible-grid-ospf-ext-04].

 

The working group last call ends on Friday, July 8th. Please send your comments to the CCAMP mailing list.

 

As is always the case, positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome. This is useful and important, even from authors.

 

Since the WG chairs and secretary are co-authors/co-contributor of this draft, if anyone is willing to be the shepherd of the document, please volunteer.

 

Note that no IPR was disclosed against this document.

 

 

 

Thanks

 

Fatai and Daniele

 




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