Re: [CCAMP] [Teas] Could you check if the latest OSPF extension draft for availability address your comments?

Lou Berger <lberger@labn.net> Tue, 26 January 2016 21:36 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC311B31A7 for <ccamp@ietfa.amsl.com>; Tue, 26 Jan 2016 13:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 24hiIaKc8IGT for <ccamp@ietfa.amsl.com>; Tue, 26 Jan 2016 13:36:21 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id 2F9391B31A5 for <ccamp@ietf.org>; Tue, 26 Jan 2016 13:36:21 -0800 (PST)
Received: (qmail 14412 invoked by uid 0); 26 Jan 2016 21:36:16 -0000
Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy7.mail.unifiedlayer.com with SMTP; 26 Jan 2016 21:36:16 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Alc91s00o2SSUrH01lcCUg; Tue, 26 Jan 2016 14:36:15 -0700
X-Authority-Analysis: v=2.1 cv=dqRIVTQ4 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7aQ_Q-yQQ-AA:10 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=VIpt2mSlhu6p2Fe9CRQA:9 a=aRZuD8yvrEPnQTdr:21 a=m40MhHU8aHxdLy-c:21 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=18B5zzgMg7H65cbjTgWcgXW4wF9W2zJOL4QQaQ/5Zv4=; b=iV2lDwWUfH06dMb9FeEYbgjTDVTMKqxWHk0hNlYW9WHj3oM7PlneCKsBINffVqg61gMMQwaH9g90EujaPR9pujxpP7ETyTUZ60uXPDJGYNnFoefV95tfwq7yx0WzENhq;
Received: from box313.bluehost.com ([69.89.31.113]:56916 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.84) (envelope-from <lberger@labn.net>) id 1aOBHX-0005e3-Da; Tue, 26 Jan 2016 14:36:11 -0700
To: Gregory Mirsky <gregory.mirsky@ericsson.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Yemin (Amy)" <amy.yemin@huawei.com>, CCAMP <ccamp@ietf.org>
References: <9C5FD3EFA72E1740A3D41BADDE0B461F9CD31347@szxema506-mbs.china.huawei.com> <568FDFD1.6060505@labn.net> <9C5FD3EFA72E1740A3D41BADDE0B461F9CD3DE05@szxema506-mbs.china.huawei.com> <569961D6.9080404@labn.net> <4A1562797D64E44993C5CBF38CF1BE4812B4A42B@ESESSMB301.ericsson.se> <7347100B5761DC41A166AC17F22DF1122199484F@eusaamb103.ericsson.se>
From: Lou Berger <lberger@labn.net>
Message-ID: <56A7E6C7.1010600@labn.net>
Date: Tue, 26 Jan 2016 16:36:07 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <7347100B5761DC41A166AC17F22DF1122199484F@eusaamb103.ericsson.se>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: <http://mailarchive.ietf.org/arch/msg/ccamp/ricigY6pbBx7womEri5i4_xPGAE>
Cc: Longhao <longhao@huawei.com>, TEAS WG <teas@ietf.org>
Subject: Re: [CCAMP] [Teas] Could you check if the latest OSPF extension draft for availability address your comments?
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 26 Jan 2016 21:36:24 -0000

Seems reasonable and probably better than an ordering based solution...

Lou


On 1/26/2016 3:22 PM, Gregory Mirsky wrote:
> Dear Daniele, Lou, et. al,
> apologies for prolonged silence in the discussion.
> I agree that Option 2 offers more elegant solution but it would require change to Availability TLV for the case when Ethernet_TSPEC includes multiple Ethernet Bandwidth Profile TLVs. In such scenario, as I understand Section 4.1 of RFC 6003, each of the Ethernet Bandwidth Profile TLVs within the same Ethernet_TSPEC will have unique value in the Index field. If we add Index field to the Availability TLV, reference it to the Index field as described in the Section 4.1 and note that mapping between two types of TLVs established via the Index would that acceptable solution?
>
> 	Regards,
> 		Greg
>
> -----Original Message-----
> From: Daniele Ceccarelli 
> Sent: Monday, January 18, 2016 4:47 AM
> To: Lou Berger; Yemin (Amy); CCAMP
> Cc: Gregory Mirsky; Longhao; D'Alessandro Alessandro Gerardo; TEAS WG; Shah, Himanshu
> Subject: RE: [Teas] Could you check if the latest OSPF extension draft for availability address your comments?
>
> Lou, Amy,
>
> Let me try to rephrase the 2 options:
>
> Option 1) As actually proposed by the draft.
>
> +     Ethernet Sender T-spec Object
> 	++  EXISTING  Ethernet bandwidth profile TLV (type 2)
> 	++  NEW Extended Ethernet bandwidth profile TLV (e.g. type 4 - used instead of type 2 when availability is needed)
> 		+++ NEW availability sub-TLV of the NEW Extended Ethernet bandwidth profile TLV
>
> Option 2)
>
> +     Ethernet Sender T-spec Object
> 	++  EXISTING  Ethernet bandwidth profile TLV (type 2)
> 	++ NEW availability TLV to be used in conjunction with the type2 TLV when needed.
>
>
> Since the Ethernet Sender T-SPEC object allows for carrying multiple TLVs I tend to agree with Lou. When no availability is requested only the Ethernet BW profile TLV will be included, otherwise both it and the new availability one.
>
> BR
> Daniele
>
>> -----Original Message-----
>> From: Teas [mailto:teas-bounces@ietf.org] On Behalf Of Lou Berger
>> Sent: venerdì 15 gennaio 2016 22:17
>> To: Yemin (Amy); CCAMP
>> Cc: Gregory Mirsky; Longhao; D'Alessandro Alessandro Gerardo; TEAS WG; 
>> Shah, Himanshu
>> Subject: Re: [Teas] Could you check if the latest OSPF extension draft 
>> for availability address your comments?
>>
>> Amy,
>>     I think we're left with one substantive discussion topic:
>>
>>>> 3) Approach
>>>>
>>>>    Given that there is really no difference between 3.1.1. and
>>>> RFC6003 Section 4.1, I suggest dropping the Extended Ethernet 
>>>> Bandwidth Profile TLV (section 3.1.1) and just adding the 
>>>> Availability sub-tlv as a a new Ethernet SENDER_TSPEC object TLV 
>>>> type.  This also helps backwards compatibility.
>>> [Amy] I will reply 2) and 3) together. The availability comes with 
>>> bandwidth together, for example, the request is (bandwidth = 
>>> 200Mbps, availability = 99.99%).
>>>
>>> That’s why the Availability sub-tlv is defined as a sub-tlv under 
>>> Ethernet Bandwidth Profile TLV.
>>>
>>> As the Ethernet Bandwidth Profile TLV defined in RFC6003 is not 
>>> capable to carry sub-tlv, a new Extended Ethernet Bandwidth Profile 
>>> TLV is defined. This was presented and discussed in IETF90.
>> So we're discussing two options:
>>
>> Option 1) new TLV with new optional sub-TLV(s) + Availability sub-TLV
>> - New TLV : Extended Ethernet Bandwidth Profile TLV
>> https://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-bandwidth-availab
>> ility-
>> 03#section-3.1.1
>>
>> - NEW TLV = RFC6003 Section 4.1 + option sub-TLV(s) and  Availability 
>> sub-TLV carried in new TLV, carried  when using availability,
>>
>> Option 2) Availability TLV
>> -No change to RFC 6003 or Ethernet Bandwidth Profile TLV
>> - Optional new Availability TLV carried when using availability
>>
>>
>> It seems to me that the carried information and the semantics are 
>> equivalent.  But option 1 defines a strictly redundant information 
>> format, with both added implementation and interoperability overhead. 
>> So why not just go with option 2, i.e., drop section 3.1.1. and define
>> 3.1.2 as a tlv of the Ethernet SENDER_TSPEC object?
>>
>> Lou
>>
>>
>>
>>
>>
>>
>> On 1/13/2016 9:05 PM, Yemin (Amy) wrote:
>>> Dear all,
>>>
>>>
>>>
>>> Below is the offline discussion on
>>> “draft-ietf-ccamp-ospf-availability-extension-03” and 
>>> “draft-ietf-ccamp-rsvp-te-bandwidth-availability-03”.
>>>
>>> You are welcome to give comments.
>>>
>>>
>>>
>>> BR,
>>>
>>> Amy
>>>
>>>
>>>
>>> *From:*Yemin (Amy)
>>> *Sent:* Wednesday, January 13, 2016 3:35 PM
>>> *To:* 'Lou Berger'
>>> *Cc:* D'Alessandro Alessandro Gerardo; Shah, Himanshu; Gregory 
>>> Mirsky; Longhao
>>> *Subject:* RE: Could you check if the latest OSPF extension draft 
>>> for availability address your comments?
>>>
>>>
>>>
>>> Hi Lou,
>>>
>>>
>>>
>>> Thanks for reply. Please see my reply starting with [Amy].
>>>
>>>
>>>
>>> BR,
>>>
>>> Amy
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Saturday, January 09, 2016 12:12 AM
>>> To: Yemin (Amy)
>>> Cc: D'Alessandro Alessandro Gerardo; Shah, Himanshu; Gregory Mirsky; 
>>> Longhao
>>> Subject: Re: Could you check if the latest OSPF extension draft for 
>>> availability address your comments?
>>>
>>>
>>>
>>> Hi Amy,
>>>
>>>
>>>
>>>
>>>
>>> On 12/29/2015 1:47 AM, Yemin (Amy) wrote:
>>>
>>>> Hi Lou,
>>>> Could you kindly check if the latest OSPF extension draft for
>>>> availability address your comments?
>>>
>>>
>>> Here are my original comments and their resolution:
>>>
>>>> On 7/25/2015 12:20 PM, Lou Berger wrote:
>>>>> Abstract: > - States applies to PSC >
>>> fixed .
>>>
>>>
>>>
>>>>> Sections 1 > - (general comment) informative sections such as 
>>>>> Intro and Overview
>>>>> shouldn't contain normative (RFC2119) language. See >
>>>> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some 
>>>> suggested guidelines. >
>>> you still have a conformance statement in the abstract.  This is a 
>>> nit
>>>
>>> and can be fixed whenever you do the next rev.
>>>
>>> [Amy] Thanks for pointing it out. Will fix it.
>>>
>>>
>>>
>>>>> Section 2 > - You mention "by the PE node" (and in two other 
>>>>> places in the >
>>>> document). I have don't understand why "PE" is being introduced. >
>>>> Perhaps you mean simply "a node"? >
>>>
>>>
>>> done.
>>>
>>>
>>>
>>>>> Section 3.1 > - You duplicate a format definition from RFC4203. 
>>>>> I think this
>>>> should > be replaced with a simple sentence stating that "The
>>>> Interface Switching > Capacity Descriptor (ISCD) sub-TLV is 
>>>> defined in
>>>> Section 1.4 of [RFC 4203]". >
>>> done. as a nit comment you can get rid of section 3.1 and just move 
>>> the
>>>
>>> reference to the first time you refer to ISCD
>>>
>>>
>>>
>>>>> - More significantly you are actually changing its format, and 
>>>>> in
>>> particular taking 8 bits from the existing reserved field: > > A
>>>
>>>> new AI field is defined in this document. >
>>> AI is gone, right?
>>>
>>> [Amy] Yes, AI is removed.
>>>
>>>
>>>
>>>>> - Taking bits from the reserved field is a major change and 
>>>>> needs to be >
>>> justified. The purpose *and the use* of this new field,
>>>
>>>> Availability > Index, is unclear in the document. It needs to be, 
>>>> or
>>>> better yet, drop it. > > Section 3.2: > - Why limit Availability
>>>> information to PSC and LSC? >
>>>
>>>
>>> This limitation remains.   I thought you agreed to dropping this in your
>>>
>>> mail back in August.
>>>
>>> [Amy] Sorry, I missed this point. Will fix it.
>>>
>>>
>>>
>>>>> Section 6.1 > - A number of references listed as Normative are 
>>>>> not required to >
>>>> implement the mechanisms in the document and therefore should be >
>>>> identified as Informative.
>>>
>>>
>>> I think this needs some change, but this can be resolved 
>>> independently
>>>
>>> of LC.
>>>
>>> [Amy] OK.
>>>
>>>
>>>
>>>> The attached is the mail discussion in July and Aug.We believe 
>>>> that
>>>> the latest drafts addressed the comments in these mails, please check.
>>>> The latest drafts links
>>>> arehttps://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availabi
>>>> li
>>>> ty-extension/,
>>>> and
>>>> https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidt
>>>> h-
>> availability/.
>>>
>>>
>>> My original comments were:
>>>
>>>> On 7/25/2015 12:20 PM, Lou Berger wrote:
>>>>> Hi, > I reviewed this document from the perspective of how 
>>>>> generalized it
>>>>> is in its current form. > > I think this document's scope in 
>>>>> it's
>>>> current form is limited to > RFC6003. I think it sould retitle the
>>>> draft to something like "Ethernet > Traffic Parameters With
>>>> Availability Information" to align with RFC6003.
>>> Done.
>>>
>>>
>>>
>>>>>  The document could also use RFC6003 as a 'design pattern' for 
>>>>> some >
>>> reediting of its sections/text.
>>>
>>>
>>>
>>> So I guess this wasn't a sufficiently detailed comment.  I see 
>>> several
>>>
>>> issues with section 3. In order of least to most significant:
>>>
>>> 1) Editorial nits:
>>>
>>>     There is no section 3.1
>>>
>>> There are grammar and spelling  errors in the section
>>>
>>> [Amy] Will fix it.
>>>
>>>
>>>
>>> 2) Formatting problems in sections 3.1.x
>>>
>>>     Type and length are included, when they aren't in RFC6003 
>>> Section
>>> 4.1
>>>
>>>     Type isn't identified as needing to be assigned
>>>
>>>     Most fields lack definition
>>>
>>>     AF is defined as a redefinition of the Profile field rather than
>>>
>>> simply a definition
>>>
>>>         of a new bit in the field.  It should simply be an 
>>> assignment of
>>>
>>> a new flag, i.e.:
>>>
>>>          Flag 3 (bit 1): Availability Flag (AF)
>>>
>>>     I also don't see the value of the flag as the rfc6003 already
>>>
>>> accommodates optional tlv inclusion and no explicit indication of
>>>
>>> subsequent TLVs is required.
>>>
>>>
>>>
>>> 3) Approach
>>>
>>>     Given that there is really no difference between 3.1.1. and
>>> RFC6003
>>>
>>> Section 4.1, I suggest dropping the Extended Ethernet Bandwidth 
>>> Profile
>>>
>>> TLV (section 3.1.1) and just adding the Availability sub-tlv as a a 
>>> new
>>>
>>> Ethernet SENDER_TSPEC object TLV type.  This also helps backwards
>>>
>>> compatibility.
>>>
>>> [Amy] I will reply 2) and 3) together. The availability comes with 
>>> bandwidth together, for example, the request is (bandwidth = 
>>> 200Mbps, availability = 99.99%).
>>>
>>> That’s why the Availability sub-tlv is defined as a sub-tlv under 
>>> Ethernet Bandwidth Profile TLV.
>>>
>>> As the Ethernet Bandwidth Profile TLV defined in RFC6003 is not 
>>> capable to carry sub-tlv, a new Extended Ethernet Bandwidth Profile 
>>> TLV is defined. This was presented and discussed in IETF90.
>>>
>>>
>>>
>>> 4) Section 3.2
>>>
>>> This isn't needed, i.e., the section should be dropped,  as this is
>>>
>>> already provided for in RF6003 Section 5.
>>>
>>> [Amy] Ok.
>>>
>>>
>>>
>>> 5) Section 3.3
>>>
>>>
>>>
>>> This section should refer back to RFC6003 section 7 and  be modified 
>>> to
>>>
>>> talk about the additional processing related to the Availability TLV
>>>
>>> (which shouldn't be a big change).
>>>
>>>
>>>
>>> You can drop the last paragraph as it is sufficiently covered in 
>>> 6003,
>>>
>>> but you do need to mention what is expected to happen, as 
>>> informative
>>>
>>> text, on a  node that doesn't support the new tlv.
>>>
>>> [Amy] Will update it.
>>>
>>>
>>>
>>> 6) The IANA section will need to be updated accordingly
>>>
>>>
>>>
>>>
>>>
>>>>>> I also suggest reviewing >
>>>> http://trac.tools.ietf.org/wg/teas/trac/wiki/PSGuidelines for some 
>>>> suggested guidelines.
>>>
>>>
>>>
>>>
>>>> If the drafts addressed all the comments, could it be moved forward?
>>>> Or if you have any other comments, just let us know.
>>>
>>>
>>> So I think we're left with a minor comment + nits on the OSPF 
>>> document
>>>
>>> and some more substantive work on the RSVP draft.
>>>
>>>
>>>
>>>
>>>
>>>> BTW, take this chance to wish a happy new year!
>>>
>>>
>>> To you as well!
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Lou
>>>
>>>> BR,
>>>> Amy(on behalf of the co-authors)
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> Teas mailing list
> Teas@ietf.org
> https://www.ietf.org/mailman/listinfo/teas