Re: [Gen-art] Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07

"Yemin (Amy)" <> Mon, 24 October 2016 05:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 321A51293EC; Sun, 23 Oct 2016 22:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.652
X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sUEG8P6NHENl; Sun, 23 Oct 2016 22:16:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02AD3128B38; Sun, 23 Oct 2016 22:16:41 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id CYW12567; Mon, 24 Oct 2016 05:16:39 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 24 Oct 2016 06:16:38 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 24 Oct 2016 13:16:35 +0800
From: "Yemin (Amy)" <>
To: "jouni.nospam" <>, Daniele Ceccarelli <>
Thread-Topic: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07
Date: Mon, 24 Oct 2016 05:16:34 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.580D9938.0027, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 7f0f0f06e7a007b29e3cab7d809c85dd
Archived-At: <>
Cc: "" <>, Lou Berger <>, "" <>
Subject: Re: [Gen-art] Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Oct 2016 05:16:45 -0000

Hi all,

After discussing with Jouni, authors, chairs, Lou and our AD, we will update the draft with the following changes to clarify Jouni's concern:

In the Abstract and Introduction, add:
"It is intended that technology-specific documents will reference this document to describe specific uses."

Section 3.2 is updated as the following:
"A node advertising an interface with a Switching Capability which supports variable bandwidth attached SHOULD contain one or more ISCD Availability sub-TLVs in its OSPF TE LSA messages. Each ISCD Availability sub-TLV provides the information about how much bandwidth a link can support for a specified availability. This information MAY be used for path calculation by the node(s).

The ISCD Availability sub-TLV MUST NOT be sent in ISCDs with Switching Capability field values that have not been defined to support the ISCD Availability sub-TLV. Non-supporting nodes would see such as a malformed ISCD/LSA.

Absence of the ISCD Availability sub-TLV in an ISCD containing Switching Capability field values that have been defined to support the ISCD Availability sub-TLV, SHALL be interpreted as representing fixed-bandwidth link with the highest availability value. 

Only one ISCD Availability sub-TLVs for the specific availability level SHOULD be sent. If multiple are present, only the first ISCD Availability sub-TLV for an availability level carried in the same ISCD SHALL be processed."

In the IANA considerations, add:
"Technology-specific documents will reference this document to describe specific use of this Availability sub-TLV."

The draft will be revised by a new version. 

-----Original Message-----
From: jouni.nospam [] 
Sent: Wednesday, October 19, 2016 5:26 AM
To: Daniele Ceccarelli
Cc: Yemin (Amy);;
Subject: Re: Gen-ATR review of draft-ietf-ccamp-ospf-availability-extension-07

Hi Daniele,

> On Oct 17, 2016, at 11:28 PM, Daniele Ceccarelli <> wrote:
> Hi Jouni,
> Thanks a lot for your review and your thoughts. I tend to agree with you, publishing a document referencing a future one doesn't make much sense.
> We had a long discussion inside the WG on how to progress this draft with many alternative options and this one happened to be the less painful one. 
> What I would suggest to do is to ask Amy to publish that document ASAP, reference it and then progress the two drafts as a cluster (i.e. this one needs to wait for the other one to become an RFC).
> Would this work for you? Deborah, Fatai, what's your opinion?

I assume “that document” above refers to a new draft that would amend RFC4203 to handle generic TLVs in scsi field. If this is the case it would be a preferable outcome to me.

I know having a normative reference in draft-ietf-ccamp-ospf-availability-extension to a new work is a bit of pain but I guess there’s no harm as you were already fine publishing an extension without describing how to implement it in the first place.

- Jouni

> BR
> Daniele
>> -----Original Message-----
>> From: jouni.nospam []
>> Sent: martedì 18 ottobre 2016 08:23
>> To: Yemin (Amy) <>
>> Cc:; draft-ietf-ccamp-ospf-availability-
>> Subject: Re: Gen-ATR review of 
>> draft-ietf-ccamp-ospf-availability-extension-
>> 07
>> Hi,
>>> On Oct 17, 2016, at 8:16 PM, Yemin (Amy) <>
>> wrote:
>>> Hi Jouni,
>>> You're right that the current draft text doesn't provide any 
>>> information
>> about the discussion.
>>> So how about add the following text at the end of section 3.1:
>>> This document only defines the Availability TLV, how the existing 
>>> Switching
>> Capability makes use of the Availability TLV will be addressed in a 
>> different document. An example is to define a new type code for the 
>> Availability TLV, if the Switching Capability-specific information (SCSI) supports TLV format.
>> With some rewording I could be OK.. I am not going to be stubborn 
>> trying to block this document. Just add that the “different document” 
>> is “different future document” or something like that.
>> Anyway, I am still somewhat surprised there is now a document (this 
>> draft under review) defining a new extension to RFC4203 before there 
>> is a document that actually describes how to do that in a proper way, 
>> specifically if this draft does not want to do that. The order is imho wrong.. just saying..
>> - Jouni
>>> Section 3 of RFC7688 provides clear definition for new SC and SCSI. 
>>> But
>> since the conclusion is to use another different document, other than 
>> this document to explain the technology specific usage(including the 
>> SC/SCSI allocation), it’s preferred not to include the such text in this document.
>>> BR,
>>> Amy
>>> -----Original Message-----
>>> From: jouni.nospam []
>>> Sent: Monday, October 17, 2016 11:21 PM
>>> To: Yemin (Amy)
>>> Cc:;
>>> Subject: Re: Gen-ATR review of
>>> draft-ietf-ccamp-ospf-availability-extension-07
>>> Hi,
>>>> On Oct 17, 2016, at 1:06 AM, Yemin (Amy) <>
>> wrote:
>>>> Hi Jouni,
>>>> Thanks very much for the comments. I fixed the nits in the draft.
>>>> Regarding the Switching Capability-specific information field, we 
>>>> had the
>> discussion in WG, and here's the summary/conclusion:
>>>> It's decided that this document will just define the availability 
>>>> TLV, and a
>> new draft will define its technology specific usage.
>>> Ok, thanks for sharing this. This document had no mention or 
>>> guidance of
>> this kind of decision. I would have assumed some text since the 
>> extension defined in this document is seemingly backwards 
>> incompatible without some glue. As the text is now, is not sufficient.
>>> I would appreciate text along lines that can be found in Section 3 
>>> of
>> RFC7688 with an addition of the details you point out below regarding 
>> the allocation of new Switching-capability types. Also, it would not 
>> hurt describing (with the Switching-capability types text) how the 
>> situation where an existing non-TLV Switching Capability-specific 
>> information and the new TLV-based information have to coexist.. or 
>> whether that kind format is not supported.
>>> - Jouni
>>>> For example, for the SCSI which supports TLV(e.g., OTN/WSON), a new
>> type code is needed to make use of availability TLV.
>>>> For the SCSI who doesn’t support TLV(e.g., PSC), a new SC types is
>> needed.
>>>> BR,
>>>> Amy
>>>> -----Original Message-----
>>>> From: jouni.nospam []
>>>> Sent: Monday, October 17, 2016 5:50 AM
>>>> To:
>>>> Cc:
>>>> Subject: Gen-ATR review of
>>>> draft-ietf-ccamp-ospf-availability-extension-07
>>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by 
>> the IESG for the IETF Chair.  Please treat these comments just like 
>> any other last call comments.
>>>> For more information, please see the FAQ at
>>>> <>.
>>>> Document: draft-ietf-ccamp-ospf-availability-extension-07
>>>> Reviewer: Jouni Korhonen
>>>> Review Date:        2016-10-16
>>>> IETF LC End Date:   2016-10-24
>>>> IESG Telechat date: 2016-11-03
>>>> Summary:
>>>> Document is ready with nits.
>>>> Major issues:
>>>> None.
>>>> Minor issues:
>>>> It is not clear to me how the ISCD Availability sub-TLV is encoded 
>>>> into RFC4203 Switching Capability-specific information field. This 
>>>> is because RFC4203 lists specific encodings depending on “Switching Cap”
>>>> field and those encoded information fields seem not to be TLVs. I 
>>>> would like to see some text that deals with switching cap, its 
>>>> relation to the TLV described in this document and the coexistence 
>>>> with existing capability specific information fields described in 
>>>> RFC4203. If I did not understand something regarding the encoding 
>>>> that is supposed to be trivial I am happy to told that ;)
>>>> Nits/editorial comments:
>>>> o Line 21: ISCD is not expanded.
>>>> o Line 142: unnecessary extra space in "a < availability”.
>>>> o Line 150: Space needed before the reference "protocol[ETPAI].”
>>>> o Line 142-.. TE is never expanded or part of the list acronyms.
>>>> o Lines 176-178: formatting issue with indentation, line spacing 
>>>> and line endings (not a fullstop but ‘;’).
>>>> o Line 162: TLV is never expanded or  part of the list acronyms.
>>>> __________________________________________