Re: [CCAMP] Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

[Lou Berger <[e-mail]>]

Amy,


On August 11, 2016 3:15:18 AM "Yemin (Amy)" <[e-mail]> wrote:

> Hi Lou,
>
> The current draft defines the availability in the way of TLV.
> Are you suggesting to progress the current draft as it is (without new SC 
> definition)?

Yes.

> And another document to explain how the existing SC types use the 
> availability TLV, e.g., by defining a new type code point?
>

I would phrase it as defining a new SC pipe in the new document. This 
document or a different document could define how the two SCs that support 
TLVs can use the tlv defined in your first document.

Lou
>
> BR,
> Amy
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: Wednesday, August 10, 2016 9:06 PM
> To: Yemin (Amy); Daniele Ceccarelli; Jonathan Hardwick; <[e-mail]> 
> ([e-mail]); BRUNGARD, DEBORAH A; 
> [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [CCAMP] Routing directorate review of 
> draft-ietf-ccamp-ospf-availability-extension
>
> Amy,
>
>     Perhaps the right way to go is have this document define just the TLV and 
>     have a new document define it's technology specific usage?  This would 
>     probably be the cleanest and allow this document to progress at a different 
>     rate (now) vs the SC-specific details that still need to be written.
>
> Lou
>
> On 8/10/2016 5:05 AM, Yemin (Amy) wrote:
>> Hi Lou,
>>
>> I'm thinking of "MW" (microwave), or "Va-Dis-BW-link"(Variable Discrete 
>> Bandwidth link).
>> But I'm open for a better name.
>>
>> Defining a generic TLV is a good approach to solve problem. It might be 
>> better to discuss in another document. Would like to hear other's opinion 
>> from WG.
>>
>> BR,
>> Amy
>> -----Original Message-----
>> From: Lou Berger [mailto:[e-mail]]
>> Sent: Tuesday, August 09, 2016 10:18 PM
>> To: Daniele Ceccarelli; Jonathan Hardwick; <[e-mail]>
>> ([e-mail]); BRUNGARD, DEBORAH A;
>> [e-mail]; Yemin (Amy)
>> Cc: [e-mail]; [e-mail]
>> Subject: Re: [CCAMP] Routing directorate review of
>> draft-ietf-ccamp-ospf-availability-extension
>>
>> Just catching up on this thread - sorry about the delayed response.
>>
>>
>> My understanding is that this was not made a specific switching capability 
>> as variable bandwidth is increasingly present across multiple technologies 
>> and therefore should be usable by any.
>>
>>
>> It seems the problem in achieving this goal is that SCSI wasn't defined as 
>> a TLV list, so only a per technology SCSI definition is possible.
>> IMO this is unfortunate.
>>
>> Now this said, two technologies do have TLVs as part of their SCSI, i.e.,  
>> OTN-TDM SCSI RFC7138 and WSON-LSC SCSI RFC7688 so it is still possible  to 
>> define a generic TLV structure and TLV code points for the SCSIs that 
>> support TLVs (OTN-TDM and WSON-LSC). of course, the question is then is it 
>> useful.  Perhaps for WSON, but I'm not sure about OTN.
>>
>> Independent of this, any new SC type should adopt the TLV approach used by 
>> the more recent SCSIs.
>>
>> What SC are you thinking about adding?  And does it make sense to do it in 
>> this document or another (derivative) document?
>>
>> Thanks,
>>
>> Lou
>>
>> On 8/5/2016 9:29 AM, Daniele Ceccarelli wrote:
>>> Thanks a lot once again Jon,
>>>
>>>
>>>
>>> Amy, please update the draft accordingly and including the other
>>> comments from Jon.
>>>
>>> The change is pretty much a major one and I see the draft has been
>>> placed in “Expert Review” state. Fatai and I will discuss with
>>> Deborah if the Expert Review will be enough or we’ll need to go for a
>>> second working group last call.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Daniele
>>>
>>>
>>>
>>> *From:*Jonathan Hardwick [mailto:[e-mail]]
>>> *Sent:* venerdì 5 agosto 2016 08:41
>>> *To:* Daniele Ceccarelli <[e-mail]>;
>>> <[e-mail]> ([e-mail]) <[e-mail]>; BRUNGARD,
>>> DEBORAH A <[e-mail]>;
>>> [e-mail]; Yemin (Amy)
>>> <[e-mail]>
>>> *Cc:* [e-mail]; [e-mail]
>>> *Subject:* RE: Routing directorate review of
>>> draft-ietf-ccamp-ospf-availability-extension
>>>
>>>
>>>
>>> Hi Daniele, Amy,
>>>
>>> If defining a new SC is acceptable to the WG then it would also
>>> address my concern.
>>>
>>> Cheers
>>> Jon
>>>
>>> Sent from my Xperia Z1 on O2
>>>
>>>
>>>
>>> ---- Yemin (Amy) wrote ----
>>>
>>> Hi Daniele,
>>>
>>>
>>>
>>> I would prefer the idea to define a new Switching
>>> Capability(e.g.,Discrete-BW ).
>>>
>>> Even with a new SC, it’s also possible to applicable to other SCs.
>>>
>>> According to RFC4202, a single interface could support multiple
>>> Switching Capabilities, see section 4 of RFC4202.
>>>
>>>
>>>
>>> BR,
>>>
>>> Amy
>>>
>>>
>>>
>>> *From:*Daniele Ceccarelli [mailto:[e-mail]]
>>> *Sent:* Monday, August 01, 2016 4:40 PM
>>> *To:* Jonathan Hardwick; Yemin (Amy); <[e-mail]
>>> <mailto:[e-mail]>> ([e-mail]
>>> <mailto:[e-mail]>); BRUNGARD, DEBORAH A;
>>> [e-mail]
>>> <mailto:[e-mail]>
>>> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>
>>> *Subject:* RE: Routing directorate review of
>>> draft-ietf-ccamp-ospf-availability-extension
>>>
>>>
>>>
>>> Hi Jon,
>>>
>>>
>>>
>>> Thanks a lot for the thorough review and raising a good point that I
>>> missed during my review.
>>>
>>>
>>>
>>> I think we could address the compatibility issue like we did in RFC7138.
>>>
>>>
>>>
>>> There we were defining a new Sub-TLV for the SCSI of the ISCD, but
>>> since the SCSI associated to the TDM Switching Capability was already
>>> defined, we introduces a new Switching Capability value (OTN-TDM).
>>>
>>> This allowed us putting a new sub-TLV into the SCSI field and solve
>>> all the compatibility issues as the new switching capability would be
>>> treated as all the other not known Switching Capabilities.
>>>
>>>
>>>
>>> Now the question, to the authors and the WG is: is it ok to have the
>>> Availability defined only against a single (newly defined) Switching
>>> capability or it is something that needs to be applicable to all the
>>> switching capabilities? If the former we can proceed ala RFC7138,
>>> otherwise we need to find an alternate solution.
>>>
>>>
>>>
>>> Jon, does this address your concern?
>>>
>>>
>>>
>>> Thanks
>>>
>>> Daniele
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *From:*CCAMP [mailto:[e-mail]] *On Behalf Of *Jonathan
>>> Hardwick
>>> *Sent:* mercoledì 27 luglio 2016 13:02
>>> *To:* Yemin (Amy) <[e-mail]
>>> <mailto:[e-mail]>>; <[e-mail]
>>> <mailto:[e-mail]>> ([e-mail]
>>> <mailto:[e-mail]>) <[e-mail]
>>> <mailto:[e-mail]>>; BRUNGARD, DEBORAH A <[e-mail]
>>> <mailto:[e-mail]>>;
>>> [e-mail]
>>> <mailto:[e-mail]>
>>> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>
>>> *Subject:* Re: [CCAMP] Routing directorate review of
>>> draft-ietf-ccamp-ospf-availability-extension
>>>
>>>
>>>
>>> Hi Amy
>>>
>>>
>>>
>>> Thanks for the quick reply.
>>>
>>>
>>>
>>> I am still concerned about the lack of backwards compatibility.
>>> Where possible, we want our protocols to be able to be deployed into
>>> a mixed environment with some non-compliant nodes.  As things stand,
>>> in a mixed environment, non-compliant nodes will disregard the ISCDs
>>> and therefore will not be able to compute paths via the compliant nodes.
>>> They are also quite likely to consider the whole LSA to be corrupted
>>> and not re-flood it.  My question (to the working group) is – are you
>>> SURE you want to publish a standard that would require a forklift
>>> upgrade of every node in order to be deployed in a running network?
>>> Particularly as there are other options available that would not
>>> require that (such as, not making Availability a sub-TLV of ISCD).
>>>
>>>
>>>
>>> Best regards
>>>
>>> Jon
>>>
>>>
>>>
>>>
>>>
>>> *From:*Yemin (Amy) [mailto:[e-mail]]
>>> *Sent:* 27 July 2016 07:53
>>> *To:* Jonathan Hardwick <[e-mail]
>>> <mailto:[e-mail]>>; <[e-mail]
>>> <mailto:[e-mail]>> ([e-mail]
>>> <mailto:[e-mail]>) <[e-mail]
>>> <mailto:[e-mail]>>; BRUNGARD, DEBORAH A <[e-mail]
>>> <mailto:[e-mail]>>;
>>> [e-mail]
>>> <mailto:[e-mail]>
>>> *Cc:* [e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>
>>> *Subject:* RE: Routing directorate review of
>>> draft-ietf-ccamp-ospf-availability-extension
>>>
>>>
>>>
>>> Hi Jon,
>>>
>>>
>>>
>>> Thanks for the review comments. Please see my reply inline.
>>>
>>>
>>>
>>> BR,
>>>
>>> Amy
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> --
>>>
>>> *发件人**:*Jonathan Hardwick [[e-mail]]
>>> *发送时间**:*2016年7月27日0:47
>>> *收件人**:*<[e-mail] <mailto:[e-mail]>>
>>> ([e-mail] <mailto:[e-mail]>); BRUNGARD, DEBORAH A;
>>> [e-mail]
>>> <mailto:[e-mail]>
>>> *抄送**:*[e-mail] <mailto:[e-mail]>; [e-mail]
>>> <mailto:[e-mail]>
>>> *主**题**:*Routing directorate review of
>>> draft-ietf-ccamp-ospf-availability-extension
>>>
>>> Hello,
>>>
>>>
>>>
>>> I have been selected as the Routing Directorate reviewer for this
>>> draft. The Routing Directorate seeks to review all routing or
>>> routing-related drafts as they pass through IETF last call and IESG
>>> review, and sometimes on special request. The purpose of the review
>>> is to provide assistance to the Routing ADs. For more information
>>> about the Routing Directorate, please see
>>> ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>>
>>>
>>>
>>> Although these comments are primarily for the use of the Routing ADs,
>>> it would be helpful if you could consider them along with any other
>>> IETF Last Call comments that you receive, and strive to resolve them
>>> through discussion or by updating the draft.
>>>
>>>
>>>
>>> Document: draft-ietf-ccamp-ospf-availability-extension
>>>
>>> Reviewer: Jon Hardwick
>>>
>>> Review Date: 26 July 2016
>>>
>>> IETF LC End Date: Not started yet
>>>
>>> Intended Status: Proposed standard
>>>
>>>
>>>
>>> == Summary ==
>>>
>>> I have significant concerns about this document and recommend that
>>> the Routing ADs discuss these issues further with the authors.
>>>
>>>
>>>
>>> == Comments ==
>>>
>>> This document addresses the situation where the maximum bandwidth of
>>> some links in the network can vary over time, for example due to
>>> radio interference.  Specifically, it addresses the path computation
>>> problem, where service placement must take these fluctuations into
>>> account.
>>>
>>>
>>>
>>> OSPF is extended to flood the “availability” of such links, which is
>>> defined as a sequence of <bandwidth, percentage> tuples.  Each tuple
>>> tells the percentage of time at which the bandwidth of the link will
>>> be at least as much as <bandwidth>, for example <100Mbps, 99.99%>.
>>> This information is added to the ISCD TLV, defined in RFC 4203.  When
>>> services are being planned, the planner specifies the service’s
>>> availability requirement (e.g. 4-nines) and the path is computed
>>> accordingly.
>>>
>>>
>>>
>>> The document is written in good English and easy enough to
>>> understand, and is commendably brief, although probably too brief – see below.
>>>
>>>
>>>
>>> == Major Issues ==
>>>
>>>
>>>
>>> 1) The specification of the protocol extensions appears incomplete.
>>> Specifically, section 1 says:
>>>
>>>
>>>
>>> The extension
>>>
>>>    reuses the reserved field in the ISCD and also introduces an
>>>
>>>    optional Availability sub-TLV.
>>>
>>>
>>>
>>> However, no further mention is made of the ISCD’s reserved field.
>>> How is it reused?
>>>
>>> [Amy] AI was defined in the ISCD rsv field in the old version, but it
>>> was removed according to discussion.
>>>
>>> The latest draft should not contain any text related with AI. Sorry
>>> for that,  I will go through the draft to remove the related text.
>>>
>>>
>>>
>>> The following description of the Availability level is difficult to
>>> understand and leaves me with several questions:
>>>
>>>            This field is a 32-bit IEEE floating point number which
>>>            describes the decimal value of availability guarantee of the
>>>            switching capacity in the ISCD object which has the AI value
>>>            equal to Index of this sub-TLV.
>>>
>>>
>>>
>>> - What is the “switching capacity” of the ISCD object?  Do you mean
>>> “switching capability” like PSC-1 etc.?
>>>
>>> [Amy] yes, it should be "switching capablity".
>>>
>>> - What is the AI value?  This term is not defined.
>>>
>>> [Amy] will update the draft to remove the AI related text
>>>
>>> - What do you mean by the index of this sub-TLV?  Do you mean the
>>> position of this sub-TLV in the list of ISCD sub-TLVs?  What if
>>> somebody defines a new ISCD sub-TLV in future – won’t that mess up
>>> the indexing?
>>>
>>> [Amy] The text "which has the AI value equal to Index of this sub-TLV"
>>> will be removed.
>>>
>>>
>>>
>>> 2) The proposed extensions are not backwards compatible, so do not
>>> support incremental deployment.  In section 3.2 it says:
>>>
>>>
>>>
>>>    A node that doesn't support ISCD Availability sub-TLV SHOULD ignore
>>>    ISCD Availability sub-TLV.
>>>
>>>
>>>
>>> However, it’s not possible for this document to specify the behaviour
>>> of nodes that do not support this document.  The issue is that the
>>> ISCD Availability TLV is defined as a sub-TLV of the ISCD TLV, but
>>> the ISCD TLV defined in RFC 4203 has no sub-TLVs.  Therefore,
>>> implementations of RFC 4203 that do not support this draft will
>>> reject the ISCD TLVs sent by implementations of this draft, because
>>> they will appear to have the wrong length.
>>>
>>> [Amy] You're right. How about this text "A node that doesn't support
>>> ISCD Availability sub-TLV will reject ISCD Availability sub-TLV."
>>>
>>> Or you perfer don't say anything?
>>>
>>>
>>>
>>> == Minor Issues ==
>>>
>>>
>>>
>>> There are a few cases I would like to see spelled out more clearly in
>>> the document.
>>>
>>> - How should a node interpret the absence of any ISCD Availability TLVs?
>>>
>>> [Amy] If a node who support ISCD Availability TLVs doesn't receive
>>> the TLV, it indicatess that the link is with fixed bandwidth, the
>>> availability can be interpreted as the highest availability value,
>>> e.g., five nines.
>>>
>>> will update draft to address this case.
>>>
>>> - How should a node interpret more than one ISCD Availability TLV for
>>> the same availability level?  Is that even legal to send?
>>>
>>> [Amy] It's legal to send. will update draft to address this case.
>>>
>>> - Let’s say a node advertises a link with 10Gbps capacity, and
>>> includes an ISCD Availability TLV saying that the link has a 99%
>>> availability level at 8Gbps .  What (if anything) are we to conclude
>>> about its availability at 10Gbps?  At 5Gbps?
>>>
>>> [Amy] The availability at 10Gbps/5Gbps cannot be concluded from 8Gbps.
>>> The <bandwidth, percentage> tuples is usually decided by the
>>> modulation and the local condition.
>>>
>>> In the appendix of the accompanied draft,
>>> "draft-ietf-ccamp-rsvp-te-bandwidth-availability"
>>> (https://datatracker.ietf.org/doc/draft-ietf-ccamp-rsvp-te-bandwidth-
>>> a
>>> vailability/?include_text=1 ), there is a example to explain. But
>>> there's an error in the table of the appendix, sorry for that. The correct 
>>> one should be:
>>>
>>> Sub-bandwidth(Mbps)    Availability
>>>
>>> ------------------     ------------
>>>
>>> 400                    99.99%
>>>
>>> 200                    99.995%
>>>
>>> 100                    99.999%
>>>
>>> Section 5 (IANA Considerations).  What allocation policy should IANA
>>> use for the new sub-registry?  See RFC 5226.
>>>
>>> [Amy] The allocation policy should be Standards Action. I will make
>>> it clear in next version.
>>>
>>>
>>>
>>> Best regards
>>>
>>> Jon
>>>
>>>
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>
>