Re: Comments on raft-fz-6man-ipv6-alt-mark-01

Tom Herbert <tom@herbertland.com> Fri, 01 November 2019 17:57 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BC6D120E1B for <ipv6@ietfa.amsl.com>; Fri, 1 Nov 2019 10:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 7gySr__GXBme for <ipv6@ietfa.amsl.com>; Fri, 1 Nov 2019 10:57:29 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 0C453120DFF for <ipv6@ietf.org>; Fri, 1 Nov 2019 10:57:02 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id d23so5462079edr.5 for <ipv6@ietf.org>; Fri, 01 Nov 2019 10:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d8QtWcfql17tomNDZP/G8jaIGOFu0FGVFkOSsb+v6W8=; b=ii+++7+sifvQqjE6/7BJ/Jy5s5J4rbLRJ7xKH7MOremxBhOWqBSwhE0Aggd6DZ3em5 yegkT+ay29o02KE96g7i+PJwnyEjKj8OtT0XwO0v2F8v2aB8dsaKPzEi4++Ls1mp2bv1 gTSQpgUMYC8HQDLN1MKNsWmX80z8mKR7AV+ItkVK1RT6TNbun/0f6ho+t3YzW6Kqsqux hg5o4CqAUriJQPqqbEb7AKFsGRthnA3ULM6AySQsYWB0xobh+Pe4KqcLVUBdxPlleGWe QaplC7BhDGa8B1H9Gb0qQWi2fREnT9xcP8E+fvDL0vyU8Hn3UNaJkkqBRHsLVYwOD6nV 4KoA==
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:content-transfer-encoding; bh=d8QtWcfql17tomNDZP/G8jaIGOFu0FGVFkOSsb+v6W8=; b=WGK/YajvDga/p8mh5lhCjf65tNoZP9kE21/NkanVjyJQaSu0aiiQiQHQQ3KzngJeSl BVG+wX+w9tIHpzt9UhF+FLevuY4ODIC3lok9sExIig+tP9Cbw/LbkpT1qkR861/2aAar LSwX0k4O/OkrrxQk//t+9TYnm+DYXUpW/YILx7CuMZl50rE8eYe/+VHkIkRpIFYhbkGD ZG0ijUlt0UzH2Rbfy8LAbR4+T8t4g+eT3u44SciJiQMjadmStoo8a+kFxOoxNzVgFdmS kcKVd1RqKmcI7H4KPP3ERjyXcVY/pgF7hAf62ODXawJBF3gz9b6TjXXg8bWVpUbrQvyy 3rnA==
X-Gm-Message-State: APjAAAWg/ecDhVW1jYq/Chz4OO87dkp9TMSHrbJYJ88XsZAvTk9kbgc6 xWaZCCS6pNLtK2+PZJtctaEwPgtzD5uiHSPwnFOxIizB
X-Google-Smtp-Source: APXvYqyyVk0LQQGhM0xQppx1f8n54ZyYF7AZlU6vwF4tTP+0t8kHQJKQ5FdyVUtirZSeOqBz1R1YW6JPgkIYTizHu1Y=
X-Received: by 2002:a17:906:6848:: with SMTP id a8mr11061462ejs.306.1572631020347; Fri, 01 Nov 2019 10:57:00 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S36a-5_OB0yKJfwY=HgArL=iXtThrw0MKfy3xT=Zek3yGg@mail.gmail.com> <EBB3105A-D6B7-4634-8742-9CF1B4E7F7EC@employees.org>
In-Reply-To: <EBB3105A-D6B7-4634-8742-9CF1B4E7F7EC@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 01 Nov 2019 10:56:49 -0700
Message-ID: <CALx6S35298CHBJsSs3LGY_0Pp2_eW-dQFCbQ6SLQneoQ5U=_yQ@mail.gmail.com>
Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01
To: Ole Troan <otroan@employees.org>
Cc: 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/VeDuDr-cJPr8xMNaBwWWmDstKxs>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2019 17:57:34 -0000

On Fri, Nov 1, 2019 at 10:46 AM Ole Troan <otroan@employees.org> wrote:
>
> DestOpt => measurement only  by node in DA
> HBH => every router on the path with feature enabled
> SRH TLV => every node along the SR path
> DestOpt + SRH => every node along the SR path
>
Ole,

So the last two have identical effects, hence we've introduced the
complexity or redundant protocol mechanisms.

Tom

> Cheers
> Ole
>
> > On 1 Nov 2019, at 18:33, Tom Herbert <tom@herbertland.com> wrote:
> >
> > Hello,
> >
> >> From the draft: "Regarding Hop-By-Hop Options Header, if we consider
> > its real deployment, it is sometimes dropped by legacy devices and not
> > so used by intermediate nodes.  Destination Options Header is
> > preferred."
> >
> > I don't think this is helpful guidance. First of all, it's not just
> > Hop-by-Hop options that can be dropped, it's pretty much packets with
> > any extension heades or atypical protocols that might be dropped by
> > legacy devices-- including packets with Destination Options or Routing
> > Headers. Neither does it make sense that Destination Options Header is
> > preferred, as correctly stated in the previous paragraph DO and HBH
> > address difference use cases (i.e. DO is end to end, and HBH is per
> > hop). Saying that DO is preferred is equivalent to saying that
> > end-to-end performance measurements are preferred which I doubt is the
> > intent. IMO, this whole paragraph could be removed without loss of
> > content.
> >
> > "SRH TLV can also be a good choice from this point of view.  The
> > intermediated nodes that are not in the SID list can consider the SRH
> > as a green field, they cannot support and bypass or support and dig
> > into the SRH TLV."
> >
> > I disagree with the conclusion that SRH TLV is a good choice. The
> > implicit assumption in this paragraph is that somehow SRH EH is less
> > likely to be dropped by intermediate nodes than other EH like DO and
> > HBH. I don't think there's any data to support that. Additionally,
> > it's not clear what use case an SRH TLV addresses that can't already
> > be addressed by Destination or HBH options.
> >
> > Tom
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------