[Teas] 答复: 答复: WG Last Call on draft-ietf-teas-gmpls-scsi

Fatai Zhang <zhangfatai@huawei.com> Tue, 14 March 2017 01:20 UTC

Return-Path: <zhangfatai@huawei.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157191299BF for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 18:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 PYGWgjMwQw4I for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 18:20:09 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A659812978B for <teas@ietf.org>; Mon, 13 Mar 2017 18:20:08 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DCS90624; Tue, 14 Mar 2017 01:20:05 +0000 (GMT)
Received: from SZXEMA418-HUB.china.huawei.com (10.82.72.36) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 14 Mar 2017 01:20:04 +0000
Received: from SZXEMA504-MBS.china.huawei.com ([169.254.8.105]) by SZXEMA418-HUB.china.huawei.com ([10.82.72.36]) with mapi id 14.03.0235.001; Tue, 14 Mar 2017 09:19:58 +0800
From: Fatai Zhang <zhangfatai@huawei.com>
To: Lou Berger <lberger@labn.net>, "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>, 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>, "teas@ietf.org" <teas@ietf.org>
Thread-Topic: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi
Thread-Index: AQHSnCbRP0+LeiIOZkyWJ4oJYlOaDqGTh4lg
Date: Tue, 14 Mar 2017 01:19:58 +0000
Message-ID: <F82A4B6D50F9464B8EBA55651F541CF8AAB46A2F@SZXEMA504-MBS.china.huawei.com>
References: <CA+YzgTuw52dmJb3J6CfeA8HDZxLx2UAiU0F9VEQW4+NDAR1sjg@mail.gmail.com> <00ab01d2904a$148d7440$3da85cc0$@olddog.co.uk> <AM2PR07MB09948EB9501383DBD326C380F0280@AM2PR07MB0994.eurprd07.prod.outlook.com> <AM2PR07MB099487148537BD1D110D517BF0280@AM2PR07MB0994.eurprd07.prod.outlook.com> <00a201d293a5$717ed4b0$547c7e10$@olddog.co.uk> <F82A4B6D50F9464B8EBA55651F541CF8AAB46294@SZXEMA504-MBS.china.huawei.com> <afe3e9cc-3aff-6589-eba4-afc470f601e0@labn.net>
In-Reply-To: <afe3e9cc-3aff-6589-eba4-afc470f601e0@labn.net>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.74.162.94]
Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF8AAB46A2FSZXEMA504MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58C74546.0204, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.105, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d174e14292e44eb7b5d21c8074fa0532
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/4CYaJLoZ7wcOV27cXcHcKOjvbAM>
Subject: [Teas] 答复: 答复: WG Last Call on draft-ietf-teas-gmpls-scsi
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2017 01:20:12 -0000

Hi Lou,

I agree since it makes the world simpler, ☺




Thanks

Fatai

发件人: Lou Berger [mailto:lberger@labn.net]
发送时间: 2017年3月14日 2:23
收件人: Fatai Zhang; adrian@olddog.co.uk; 'Daniele Ceccarelli'; 'Vishnu Pavan Beeram'; teas@ietf.org
主题: Re: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi


How about we just get rid of the ranges? i.e.,
OLD


       Value       SCSI-TLV                   SwitchCap   Reference
       ---------   -------------------------- ---------   ---------
       0           Reserved                               [This ID]
-       1-32768     Unassigned, for use by    [per value]
-                   specific technology                    [This ID]
-       32768-65535 Unassigned, for others    (Any, or
-                                              value list) [This ID]

   New allocation requests to this registry SHALL indicate the value or
   values to be used in the SwitchCap column.

NEW

       Value       SCSI-TLV                  SwitchCap    Reference
       ---------   ------------------------- ---------    ---------
       0           Reserved                               [This ID]
+      1-65535     Unassigned                (value list) [This ID]


   New allocation requests to this registry SHALL indicate the value or
   values to be used in the SwitchCap column.

Lou
On 3/12/2017 11:34 PM, Fatai Zhang wrote:

Hi Adrian and Daniele,



Interesting.



I understood the purpose of split ranges is allowing technology specific ones go for the first range "1-32768", and generalized ones go for the second range "32768-65535".



But, the issue raised by Adrian is coming, i.e., one by one technology specific ones go for the first range, and people realize later on that they should be generalized by using the second range.



In addition, "'Any', or list of multiple technologies" is a little confusing, since "Any" includes technology specific.



So, should it explicitly say that technology agnostic( or generic ones) go for the second range?





> > I think Section 6 could be clearer...

>>

> > But, I don't think this is going to work!

> > Suppose I define a new TLV for the foo-switch technology. Obviously

> > it comes from the 1-32768 range.

> > But the next day someone dreams up the foo-prime (commonly known as

> > bar) technology and wants to use the same TLV.

> > Can't do it.

>

> I don't get this either (and It's only Thursday...). Foo would get

> value 1 allocated and bar value 2 if they are both specific

> technologies, otherwise Foo would get value 1 allocated and Bar would get 32768 allocated ... I don't get the issue.



> > Foo and Bar are technologies. They don't get TLVs.

> > But for Foo we want the "Fridge-temperature" TLV so we assign value 1 for that TLV. We genuinely believe that only Foo will ever care about the temperature of the fridge.

> > Now, along comes Bar. Bar also wants to know the temperature of the fridge and would like to simply use the same TLV. But it is allowed. So a new TLV must be assigned from the registry (presumably 2).

> > Oh wait, here is the Humbug switching technology, that *also* cares about fridge temperatures.



> > See my point?









Thanks



Fatai






_______________________________________________

Teas mailing list

Teas@ietf.org<mailto:Teas@ietf.org>

https://www.ietf.org/mailman/listinfo/teas