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

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 13 March 2017 21:07 UTC

Return-Path: <adrian@olddog.co.uk>
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 C1F7E129B99 for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 14:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.588
X-Spam-Level:
X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_KAM_HTML_FONT_INVALID=0.01, 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 GewQQm5lYwjC for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 14:07:23 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A28129B7F for <teas@ietf.org>; Mon, 13 Mar 2017 14:07:20 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2DL78qH021146; Mon, 13 Mar 2017 21:07:08 GMT
Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2DL6q1E021013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2017 21:06:58 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Lou Berger' <lberger@labn.net>, 'Fatai Zhang' <zhangfatai@huawei.com>, 'Daniele Ceccarelli' <daniele.ceccarelli@ericsson.com>, 'Vishnu Pavan Beeram' <vishnupavan@gmail.com>, 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> <afe3e9cc-3aff-6589-eba4-afc470f601e0@labn.net>
In-Reply-To: <afe3e9cc-3aff-6589-eba4-afc470f601e0@labn.net>
Date: Mon, 13 Mar 2017 21:06:55 -0000
Message-ID: <02cf01d29c3d$c43ce930$4cb6bb90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D0_01D29C3D.C43F5A30"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGHyPwTRIKL8gU+TkrqkWJ1+diZfwNNqZWPApk6j7QCiGRYZgJFKc9aAw+coKwB9h6D96GrF6uw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22940.002
X-TM-AS-Result: No--27.474-10.0-31-10
X-imss-scan-details: No--27.474-10.0-31-10
X-TMASE-MatchedRID: pS5owHKhBO0DJrf2+hNOhZNd1m5RlE+KIM86Aeo6sYIAhmnHHeGnvcKi gQM2uK1bp306fUThb1+buxUhFVKXH1Fej9EwCdZzws9cphnKwlFQCOsAlaxN77NTRH7kNsNs48f E6PIFskDg/+i1q78XIKJf3qR6TqU0DsB+KQ9eA7DsEjYqO+DyaCOjxzQ2Rhgiu/jTz8Y/kerBXz PRSjofjvfGrPPhhZrtwRGoXpwCCUQol39hmeEcdwPZZctd3P4BC/ExpXrHizzjsTquy0JRi3BZf 6ES4x20QUOmmfxRyAesaZdo6QjY7qj51DoCJeXuHOEZV7E5RxwcVY4wxvgKp9qqof+gfD6RMjab a+FVVAvU1O68dJT01mhZ/1SerWje4MG9jJywnBWpuD25aEtgt/aS52LUPfcSsneuamRRT5Mnwf3 kfmsrQzba6gSbbjl+gVo1o+4QhtJpZtsObgt0hne8jMDtfIiIIQXVF2qsdV213HaVceMXUiL8Ha C6OsQfMHoR0KY0MZVVsQM/S7OiNfJMF6pylZNWVF7yOiu4q2kgVvZV3BB2QNE6Er5EVajmW2E6A 0VjBlqQ0Ir9EHtCMQJIccaMDcUCF/JN69C1+RCR1ykkpfknCvwGVtfL479acq4vxILn2XdgKjAp K+kj762ZXwyH9Nib8+nPEznfQJOEWG4fxKPlxUOZWaJBszmqEsPHM6iHL3Y93acSBBsAmjApi0h Tr2bdn9fPWsL/WDRpvaTqRsHaZNoCk6MGCiGt+KUzuemidPxfohHCqSnabhUZTfM00s4+9pGDO2 ct0sJ/+1gtIpwO/w6a8aO+TUqR+ybY5Ha5C8meAiCmPx4NwGmRqNBHmBve1kTfEkyaZdxFGCd0S 0NCsqdTfciq0kfjs6UPbISI0k3uBGluqYV/qk+kCnR/SVUWvuvB6gAgryg=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/2FpSP8DlsFD-yJVKVs1kSbz1vGs>
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
Reply-To: adrian@olddog.co.uk
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 21:07:27 -0000

Sorry all. My post crossed with Lou's.
 
What he says.
 
Adrian
 
From: Lou Berger [mailto:lberger@labn.net] 
Sent: 13 March 2017 18:23
To: Fatai Zhang; adrian@olddog.co.uk; 'Daniele Ceccarelli'; 'Vishnu Pavan Beeram'; teas@ietf.org
Subject: 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
https://www.ietf.org/mailman/listinfo/teas