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

Lou Berger <lberger@labn.net> Mon, 13 March 2017 18:22 UTC

Return-Path: <lberger@labn.net>
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 1843A1294ED for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 11:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] 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 bi_PChlL6GDs for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 11:22:40 -0700 (PDT)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB52012948F for <teas@ietf.org>; Mon, 13 Mar 2017 11:22:39 -0700 (PDT)
Received: from [::1] (port=55736) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from <lberger@labn.net>) id 1cnUcA-0000Pj-UH; Mon, 13 Mar 2017 21:22:39 +0300
To: Fatai Zhang <zhangfatai@huawei.com>, "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>
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>
From: Lou Berger <lberger@labn.net>
Message-ID: <afe3e9cc-3aff-6589-eba4-afc470f601e0@labn.net>
Date: Mon, 13 Mar 2017 14:22:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF8AAB46294@SZXEMA504-MBS.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------F70DF245C450004079D658F7"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/77Ds2tmgyP-XRlGH3cI-PzUaoeI>
Subject: Re: [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: Mon, 13 Mar 2017 18:22:42 -0000

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
> https://www.ietf.org/mailman/listinfo/teas