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

Abdussalam Baryun <> Sun, 18 February 2018 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 06F4C126E64; Sun, 18 Feb 2018 15:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SXDQc_Xpx6Tt; Sun, 18 Feb 2018 15:23:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 94E56126BF7; Sun, 18 Feb 2018 15:23:51 -0800 (PST)
Received: by with SMTP id l124so5984079oib.0; Sun, 18 Feb 2018 15:23:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8DqTAWMzu3D83Tsy7X/Lde4ELFTvZ4SwdUboOSAhK8w=; b=IjNrqMFPKfFGRQNfdUyoGpZYT0wYUCH6A3WDfCf2uuv0HW7V5PpHlsAJc/SnH7jPdC 6wLGTCqCzgoCOGYEXzlhdKNOMgxVOuZW1qWdSihCZwHLlWox9ANaZ/Jqw1LwtYE9+MWX THc1Gx36L3kNh+jogMZNxnbRj7QfwGsMWiuWGe9tLBqAd9ecL+XzZ1WCVCrteM05t7Nf V4QuX0TjZlzxm2PiXakWKXGhlh7HNE3u9ll/w6Yd5yxUKmEJY/5vxDmtrVKGza+65TCc A9iFoN0ttaU5GWLQTgxZzvrdlYS2CIBl0amNbgzZo7H7QfLpf78jeZlAhbSc2XbH4V7S X9OA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8DqTAWMzu3D83Tsy7X/Lde4ELFTvZ4SwdUboOSAhK8w=; b=WUkjXhyLiDlJuSuSOxB3hHgpCNMVLr44S/Faslau2chzWlIX91gdWAiA3yXvm6S2y7 WebplAkS7T7y7VHKr8y53OL1U0jHXcCi0GvR7NMBnp2W0XVKik3fxpmDSIjrqrYPYuzW NDp8Kki/2uQlZ6aYCKtZ/595YxYhZwTrvK9p5qKGc2bxyVIJIVHKnTxGth3n6et7Yx+m f6X49D7HDsr//JEO27jnmre09uo4RWqYi3Hnm6msVQMqEj9Kf/8javcedZjYRYIu1nH+ vG8TcuDmX5h/gtY8Q7AomXFYLeWOuRD4PvmlZl7ozdTy7Vfv45cJNHtrbAdnbo8VWSsM 6QWw==
X-Gm-Message-State: APf1xPBM+Z4gew2RuzKiHrjc8ZkdY273FoaQ6wRTA8NmOKNQ5RaIsbbB H/ebWywwQxVoRIzQcw7/xKSYzm1c6Biiet6rlZwgZg==
X-Google-Smtp-Source: AH8x225lZL8L4ltgOn7rTxfOjsAAVz/kjJV17WTNSzSUfok710V/aWg7e4cBbcJQ4mMmC+Hj/2V3ylZ7LSYSd3H6GoU=
X-Received: by with SMTP id d63mr3944899oig.226.1518996230940; Sun, 18 Feb 2018 15:23:50 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 18 Feb 2018 15:23:50 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Abdussalam Baryun <>
Date: Mon, 19 Feb 2018 01:23:50 +0200
Message-ID: <>
To: Lou Berger <>
Cc: manet <>,
Content-Type: multipart/alternative; boundary="001a1134f8eec2aede056584de6d"
Archived-At: <>
Subject: Re: [manet] I-D Action: draft-ietf-manet-dlep-latency-extension-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Feb 2018 23:23:54 -0000

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

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

Best Regards

On Thu, Feb 15, 2018 at 1:36 AM, Lou Berger <> 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, 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:
>> There are also htmlized versions available at:
>> latency-extension-02
>> A diff from the previous version is available at:
>> ncy-extension-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
>> Internet-Drafts are also available by anonymous FTP at:
>> _______________________________________________
>> manet mailing list
> _______________________________________________
> manet mailing list