Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt

[Lou Berger <[e-mail]>]

On 2/19/2018 6:44 AM, Rick Taylor wrote:
> Hi Lou,
>
> AB raises a good point about behaviour when one peer does not support
> the extension.

I think I missed his point on this.  But there is no issue here, per 
standard 8179 processing, if one peer doesn't support the extension it 
isn't used.  What else needs to be said?

> In the LID extension draft, I have tried to add normative text that
> describes how an implementation supports core DLEP when it does layer-3
> routing.  I think a quick sentence describing how the core Latency
> metric should be used when this extension is in use, and not in use
> might be beneficial.
in this extension 8179 behavior continues even when the extension is 
used, so I'm not sure what the concern is for this draft.

Cheers,
Lou

>
> Cheers,
>
> Rick
>
> On Mon, 2018-02-19 at 01:23 +0200, Abdussalam Baryun wrote:
>> Hi Lou,
>>
>> Thanks for your updates. I am sorry that I did not comment on the
>> draft before, however, this is my thought,
>>
>> in section 3:
>>
>>   draft>The Latency Range Data Item serves much the same purpose as
>> the
>>     Latency Data Item defined in [RFC8175] with the addition of being
>>     able to communicate the latency range that may be experienced by
>>     traffic on a link.
>>
>> AB> IMO, or understanding,  latency range is not one value, but two
>> values, so how can two values be same in the purpose of one value of
>> latency? maybe the draft should discuss that for clarification,
>> because I did not understand.
>>
>>
>> AB> this draft does not say what will happen to the data item latency
>> of RFC8175 (type code 16), because in RFC8175 says such messages MUST
>> contain one value of .... and states the latency item, not the
>> latency-range. Some sections after 12.6 does not mention the
>> dlep support of such extension what will happen, so IMO this darft
>> should say how the replacement of Latency item,
>>
>> AB> as this draft may need to say that if the extension is supported
>> then latency range item replaces the latency item, or it may say that
>> the maximum latency value is used into the latency item value. Not
>> sure which approach is better.
>>
>> AB>  My problem in understanding the draft, is that if this draft is
>> supported as mentioned in section-12.6 in the RFC8175 then it MUST be
>> contained in that message. So this needs to be said again I think in
>> this draft (because the draft now says: MAY be carry).
>>
>> draft>  The Latency Range Data Item MAY be carried in the
>>     same messages and MUST be processed according to the same rules as
>>     the Latency Data Item defined in [RFC8175].
>>
>> AB> same rules, but we have two values, one max-latency and one min-
>> latency, please clarify,
>>
>> AB> as mentioned above ''same rules as latency'' but what will happen
>> to this latency item while it is a MUST in many messages, what will
>> be the value, but Latency range is a MAY.
>>
>> AB> so I may suggest the value of the range for the draft's item and
>> that the latecy iten in rfc8175 contains the max-latency, or any you
>> suggest to clarify it.
>>
>> AB> furthermore, the RFC8175 mentions change in metrics what kind of
>> reaction, so within this draft cases, if the latency was the metric
>> what value will be used (max, avg, min,...) may need to be specified
>> in the draft.
>>
>>
>> Best Regards
>> AB
>>
>>
>>
>> On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger <[e-mail]> wrote:
>>> Hi,
>>>
>>> This version addresses all comments received (to date) during WG LC
>>> with one exception.  The one exception was a private
>>> question/comment on how to handle latency that may be queue
>>> specific.  As this extension is independent of queue definition
>>> (which introduced in pause and credit extensions) and the same
>>> question applies to other link metrics, it was my opinion that
>>> queue specific metrics are beyond the scope of this draft and
>>> really warrants a new extension in its own rights.  Given this was
>>> raised privately during LC and not specifically addressed in this
>>> version, I thought it important to mention  on list.
>>>
>>> All other comments were discussed on list. See below for a link to
>>> see these diffs.
>>>
>>> Lou
>>>
>>>
>>> On 2/14/2018 6:27 PM, [e-mail] wrote:
>>>> A New Internet-Draft is available from the on-line Internet-
>>>> Drafts directories.
>>>> This draft is a work item of the Mobile Ad-hoc Networks WG of the
>>>> IETF.
>>>>
>>>>           Title           : DLEP Latency Range Extension
>>>>           Authors         : Bow-Nan Cheng
>>>>                             Lou Berger
>>>>          Filename        : draft-ietf-manet-dlep-latency-
>>>> extension-02.txt
>>>>          Pages           : 5
>>>>          Date            : 2018-02-14
>>>>
>>>> Abstract:
>>>>      This document defines an extension to the DLEP protocol to
>>>> provide
>>>>      the range of latency that may be experienced on a link.
>>>>
>>>>
>>>> The IETF datatracker status page for this draft is:
>>>> https://datatracker.ietf.org/doc/draft-ietf-manet-dlep-latency-ex
>>>> tension/
>>>>
>>>> There are also htmlized versions available at:
>>>> https://tools.ietf.org/html/draft-ietf-manet-dlep-latency-extensi
>>>> on-02
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-manet-dlep-laten
>>>> cy-extension-02
>>>>
>>>> A diff from the previous version is available at:
>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-dlep-latency-e
>>>> xtension-02
>>>>
>>>>
>>>> Please note that it may take a couple of minutes from the time of
>>>> submission
>>>> until the htmlized version and diff are available at
>>>> tools.ietf.org.
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> _______________________________________________
>>>> manet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/manet
>>>>
>>>>
>>>   
>>> _______________________________________________
>>> manet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/manet
>> _______________________________________________
>> manet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/manet