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

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 13 March 2017 19:47 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 6E531129451 for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 12:47:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level:
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 J8iRcf350p_c for <teas@ietfa.amsl.com>; Mon, 13 Mar 2017 12:47:35 -0700 (PDT)
Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47266129AC5 for <teas@ietf.org>; Mon, 13 Mar 2017 12:47:31 -0700 (PDT)
Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2DJlK29003712; Mon, 13 Mar 2017 19:47:20 GMT
Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v2DJjwZ0002308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Mar 2017 19:47:14 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: '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>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF8AAB46294@SZXEMA504-MBS.china.huawei.com>
Date: Mon, 13 Mar 2017 19:46:00 -0000
Message-ID: <028f01d29c32$a1464300$e3d2c900$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0290_01D29C32.A14D6EF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGHyPwTRIKL8gU+TkrqkWJ1+diZfwNNqZWPApk6j7QCiGRYZgJFKc9aAw+coKyhuqVLoA==
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--22.598-10.0-31-10
X-imss-scan-details: No--22.598-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkBzgDEqoQageh3EEAbn+GRbR6S0bllvD8xnnK6mXN72m1YW wxB9tw0T8SXQ3wH4DTuxSHfXR7UaynS8vP347grLBu2zRCSrLja/yN2q8U674mSWOq+2g0h2tJ4 /cXzOBJTgstsimUYlQ2GvCQX/JU9q4Seru+sa8w2VUcz8XpiS9Gih7dQ4fHJcxSZxKZrfThPNgE Rhk3O4etlRklbPHzoXT2W9qbn0ooBw08wUkhf6c39NanCUA4VezmQLQVT20DcSGnqoiHTGaNDcI u8+lHfNPy/kFMGyybP60KVA7suq5D4Pcn5OGAtGW7gz/Gbgpl4KajiKVoihqS8zQZ2rR/OpJwnY hT6c06Hppj8qRQ7QKIqA2LoxAxBYeYojpvrZ9+f0hv/rD7WVZJ6KYa03LCO2dDwP5ItpCOwcSRF 9JP5Ozi4jb1n1eNA3RHaihp8THGAxoJNALx/f4Z3bt4XlQMWjD+LwVja9M4EgOnjvjQ5gMSWdw9 Myj4ex9dMkDbqNTiWX7nDC+4gKenNQXkvyemjfXTK4OtPUfQSjuF41aTJRXZ/paSZmLhGje5bas ibx4KfyTo1GsSlyqhkigyII1PZ5MuPfXQm0MvCKC6Im4I1RF9Vj2MQh1a6nYB83633RxLcTSnsK ccEd+AI2jcyWmkkvVFcyUv+neW4eszLHPCQb9Ft8oqXrPa7ynHdKFmfbSYM93acSBBsAmjApi0h Tr2bdnFfNkmfs1AiyNm0/eGTGyosxYRAg7qHw+KUzuemidPyQF91MxEBdRhHyswgJ7SqQeKLmRI 5Hi0ZUKKv8/8eUEJ7FIsFagzgEUhIJtkjMIFmeAiCmPx4NwGmRqNBHmBve640NKxn5mzAXvQkGi 3tjz2WKAuw8W/IlPrbi/6gU1u/qB2HXO28/Sm5F7PjecpB88eSbm3GJyyM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/1SWYdrx3AWE2ESb1042Yrn31Scs>
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 19:47:39 -0000

I think "Any or a list" means that when you create the entry in the registry you
tell IANA
either
- This TLV can be used for any switching type
   (in which case IANA marks the entry as "any")
or
- This TLV can be used for switching types Foo and Bar
  (In which case IANA marks the entry as "Foo, Bar"
 
In the first case, when a new switching type (Humbug) wants to use the TLV, no
change is needed.
In the second case, when a new switching type (Humbug) wants to use the TLV,
IANA has to be requested through Standards Action, and updates the registry
entry to read "Foo, Bar, Humbug"
 
*If* you consider that there will be TLVs that can only be used for one
switching type (MUST NOT or cannot be used for another one) then you could keep
the split. For example, for switching type TDM, you might want a BSOT TLV and
think that no other switching type will ever care about BSOT.  However, I don't
see the point in separating the TLVs when 1 is a special case of n and so a list
with one entry is no harder to understand.
 
Adrian
 
From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: 13 March 2017 03:35
To: adrian@olddog.co.uk; 'Daniele Ceccarelli'; 'Vishnu Pavan Beeram'; teas@ietf.
org
Subject: [Teas] 答复: WG Last Call on draft-ietf-teas-gmpls-scsi
 
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 not 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