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

[Rick Taylor <[e-mail]>]

Hi Lou,

AB raises a good point about behaviour when one peer does not support
the extension.

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.

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