Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo

Robert Raszuk <robert@raszuk.net> Tue, 18 August 2020 16:22 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF193A0E95 for <lsr@ietfa.amsl.com>; Tue, 18 Aug 2020 09:22:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4HkhBK3w5p0 for <lsr@ietfa.amsl.com>; Tue, 18 Aug 2020 09:22:33 -0700 (PDT)
Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3647E3A0E96 for <lsr@ietf.org>; Tue, 18 Aug 2020 09:22:33 -0700 (PDT)
Received: by mail-ed1-x530.google.com with SMTP id i26so15733160edv.4 for <lsr@ietf.org>; Tue, 18 Aug 2020 09:22:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bfkfOS+HvYP88/AvwxBOjk5jQWYL75IWlCytfa77rA4=; b=NIeVArmycxslyoyhWw95KqIWyZAB3FUIYp8EKbDl3yyoVC9Rv6+w2TTmpMhc56GKQY Hlr1Q1fMHY0tQtIpkU8Z5gRgdtbdeEIZKa2B3fjYWCAzbfYEiY/dScfJXjyuT4aw5zyM /qX4IkekAPWUepkWCgpdubdsgJqztUblUuOIbXhv0eeMNgoVQMWn5DC8R9AYHgNETYJD VD2SGIbzBXHE9qeJppEDaWl9zP4Xl55dZpoUfN33usuO6mn23uZLKyvui1Nd1tEBEhgF W1dQ38VPd+yDisRsWcl6KNddkS/47cJ4T7BnhBwDlZYCSnb+ST9uL0iAJ0IDOvePNQWF KX/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bfkfOS+HvYP88/AvwxBOjk5jQWYL75IWlCytfa77rA4=; b=Xye1MeoB5GREO2z25Z8Oi4F+m2DGOglC3kiIPXIhA+yfhBwlJmqQKVnWRqeuqn9Khe 1L0Gt/5gJCZMBKTQwuhGzokc98CeoLkfdQXrFXNDBftKFDt6+TC7SPrkpcDi+KMt+972 ynjdKZcujQHkksghXP5/GG7zq4ljUs3WIZ2On2ihfihZvddTYUZaep10ay/d30oT8ZvP QfYTZV4e/jR0+dhf4Kl0U4u5Php/KC4s+Nyn/nU1uwf4kuafn5Uy+3/JuAok+c4QfFRd F3zfQuIXwloiPYS6cBez5jJBlvOsGhSNGmZXM+ekNaYSTyxn+dYGF3b3tP0JzRn14gwj Noaw==
X-Gm-Message-State: AOAM530+riB2YE/5Z+A9X699hr5rGznoKH3k6rgxjnJL3sAjCCrheR28 ymYokiQ0+aWV4Sn4xdsZIkE2gqWKkqUzFK6i4nKP3Q==
X-Google-Smtp-Source: ABdhPJw+bY77DIOQCN9Cg08jo2shoUzIxGT52FR3YluM4puBGSsZFWeAi3Uj2kPXHIOOfYAlC5xmdPICUG+jivKUehA=
X-Received: by 2002:aa7:d585:: with SMTP id r5mr20108896edq.30.1597767751461; Tue, 18 Aug 2020 09:22:31 -0700 (PDT)
MIME-Version: 1.0
References: <9094873B-3A03-4F48-B438-55AB0CA75396@chopps.org> <E9DF9CDA-D031-4995-BB69-7A9CEE312707@tony.li> <dff9ca08-8950-ef1c-5926-39944e94c98b@cisco.com> <E6A4AB1E-6A37-4424-8E27-2F0BFE7E3313@tony.li> <BY5PR11MB4337D97F838FFD8B250BACB1C15C0@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4337D97F838FFD8B250BACB1C15C0@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 18 Aug 2020 18:22:21 +0200
Message-ID: <CAOj+MMG9_yBK7-qWLA6Xfsq-4u4hpXz4x5FSdLA0arBw9cdc+g@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>
Cc: "tony.li@tony.li" <tony.li@tony.li>, "Peter Psenak (ppsenak)" <ppsenak@cisco.com>, "lsr@ietf.org" <lsr@ietf.org>, "lsr-ads@ietf.org" <lsr-ads@ietf.org>, Christian Hopps <chopps@chopps.org>, "Acee Lindem (acee)" <acee@cisco.com>, "draft-ietf-lsr-flex-algo.all@ietf.org" <draft-ietf-lsr-flex-algo.all@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000428f8905ad294bc5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/LaaIdy5uZP37wgqMw8aS-6-iT9c>
Subject: Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Aug 2020 16:22:36 -0000

Les,

I think this is not very obvious as Tony is pointing out.

See RFC 8570 says:

      Type    Description
      ----------------------------------------------------
       33     Unidirectional Link Delay

       34     Min/Max Unidirectional Link Delay


That means that is someone implementing it reads text in this draft
literally (meaning Minimum value of Unidirectional Link Delay) it may pick
minimum value from ULD type 33 :)

If you want to be precise this draft may say minimum value of Min/Max
Unidirectional Link Delay (34) and be done.

That's all.

Cheers,
R.



On Tue, Aug 18, 2020 at 6:04 PM Les Ginsberg (ginsberg) <ginsberg=
40cisco.com@dmarc.ietf.org> wrote:

> Tony –
>
>
>
> As an author of both RFC 8570 and I-D.ietf-isis-te-app, I am not sure why
> you are confused – nor why you got misdirected to code point 33.
>
>
>
> RFC 8570 (and its predecessor RFC 7810) define:
>
>
>
> 34           Min/Max Unidirectional Link Delay
>
>
>
> This sub-TLV contains two values:
>
>
>
> “Min Delay:  This 24-bit field carries the minimum measured link delay
>
>       value (in microseconds) over a configurable interval, encoded as
>
>       an integer value.
>
>
>
>    Max Delay:  This 24-bit field carries the maximum measured link delay
>
>       value (in microseconds) over a configurable interval, encoded as
>
>       an integer value.”
>
>
>
> It seems clear to me that the flex-draft is referring to Min
> Unidirectional Link Delay in codepoint 34.
>
>
>
> I agree it is important to be unambiguous in specifications, but I think
> Peter has been very clear.
>
> Please explain how you managed to end up at code point 33??
>
>
>
>    Les
>
>
>
>
>
>
>
> *From:* Lsr <lsr-bounces@ietf.org> *On Behalf Of * tony.li@tony.li
> *Sent:* Tuesday, August 18, 2020 7:44 AM
> *To:* Peter Psenak (ppsenak) <ppsenak@cisco.com>
> *Cc:* lsr@ietf.org; lsr-ads@ietf.org; Christian Hopps <chopps@chopps.org>;
> Acee Lindem (acee) <acee@cisco.com>; draft-ietf-lsr-flex-algo.all@ietf.org
> *Subject:* Re: [Lsr] WG Last Call for draft-ietf-lsr-flex-algo
>
>
>
>
>
> Hi Peter,
>
>
>
>
>
> section 5.1 of the draft-ietf-lsr-flex-algo says:
>
>
> Min Unidirectional Link Delay as defined in [I-D.ietf-isis-te-app].
>
> We explicitly say "Min Unidirectional Link Delay", so this cannot be mixed
> with other delay values (max, average).
>
>
>
>
>
> The problem is that that does not exactly match “Unidirectional Link
> Delay” or “Min/Max Unidirectional Link Delay”, leading to the ambiguity.
> Without a clear match, you leave things open to people guessing. Now, it’s
> a metriic, so of course, you always want to take the min.  So type 33 seems
> like a better match.
>
>
>
>
>
> section 7.3. of ietf-isis-te-app says:
>
> Type   Description                          Encoding
>                                            Reference
> ---------------------------------------------------------
> 34      Min/Max Unidirectional Link Delay    RFC8570
>
>
>
>
>
> And it also says:
>
>
>
> 33      Unidirectional Link Delay            RFC8570 <https://tools.ietf.org/html/rfc8570>
>
>
>
>
>
> This does not help.
>
>
>
>
>
> So, IMHO what we have now is correct and sufficient, but I have no issue
> adding the text you proposed below.
>
>
>
>
>
> What you have now is ambiguous. We have a responsibility, as writers of
> specifications, to be precise and clear.  We are not there yet.
>
>
>
>
>
> BTW, before I posted 09 version of flex-algo draft, I asked if you were
> fine with just referencing ietf-isis-te-app in 5.1. I thought you were, as
> you did not indicate otherwise.
>
>
>
>
>
> My bad, I should have pressed the issue.
>
>
>
>
>
> Anyway, I consider this as a pure editorial issue and hopefully not
> something that would cause you to object the WG LC of the flex-algo draft.
>
>
>
>
>
> I’m sorry, I think that this is trivially resolved, but important
> clarification.
>
>
>
> You also have an author’s email that is bouncing, so at least one more
> spin is required.
>
>
>
> Sorry,
>
> Tony
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>