IETF Logo Mail Archive

Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt

Tom Herbert <tom@herbertland.com> Tue, 17 October 2017 15:53 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 4ADBE1332CD for <ipv6@ietfa.amsl.com>; Tue, 17 Oct 2017 08:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] 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 QEt6dUSNLXpD for <ipv6@ietfa.amsl.com>; Tue, 17 Oct 2017 08:53:54 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 87E3013303F for <ipv6@ietf.org>; Tue, 17 Oct 2017 08:53:54 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id p1so4557714qtg.2 for <ipv6@ietf.org>; Tue, 17 Oct 2017 08:53:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NH7akRP5p1Tmx+gI1Gw1JhIFZ/x94PHZJDMonT5O4To=; b=D9+EewxJkDcPQCvsqNEb0FOny1jBahuz0KVGZM/VqKbaSo1m9vGpjmwu71rWRHtYwq 0JreZjY52CMOwLC6DtJzA5CZduhck6lynEKqCsVOF/KnYrjEb90vrm4M/eylsxyrS/0p R7N5wZsLdsr38Nzr53OG9oppXH47M+mMbQC2SdUe3x31XQjp1Q6rlMl/9a0Lf3sHhIz5 5jgb8BvLvpcOzbOKLz4E/2pSlgH+H+DCJ77Z4MKbWxbD3UrLHjr7Oh5pZZo2OJFcRvqg qGs6d1LNSEsXrytI1aPzzDMeUTtBAEH4a6NMorERtC85G4JUzCGOf6saJoxfbLaPMEia Ogow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NH7akRP5p1Tmx+gI1Gw1JhIFZ/x94PHZJDMonT5O4To=; b=ftDdepcyg6+4/KUpjDXJWtFs9OHGapLmz5q3dIKkRv0r9dGP9LNk3ka41Qvf8LDk9W 4sz9gtxnhklA7hx12soAtaIJFyW2H/lfLbr3ueQIqEulN9AYCkWI+VvHJlBM+Igg4VQg NvF193c9E8a21QSwiei5Qfbpr+6d4Xiy+0wTnwkJc7MxXYIrYOMBuq+rlrPnyCJOKo58 3ifQyWMwq/2AwBsdMym9z8R7575Uq/J2+zHWw6doYHSPLExPM1sQyjbjTnwBU3EaiVW0 UICe1HAjJe4sGSy2CiZiLi0L4bVMEmKvMH3ING/TuIzkfLkyBpRhXH4JpKH9RyxLOSbC hk6Q==
X-Gm-Message-State: AMCzsaWkDr/ZbxpyePc9KXTyW06CQCXTkR5DXuy9O1ud1D3LtNEABuPw EfXaD0lbOZfYLoFqamzQiHvR+FwXtMaBQ1dfXI4P8A==
X-Google-Smtp-Source: AOwi7QCQdkXsBxfzH/XDrcRD4Pp8G6gqZl5mimrNGUHq47EXrNeBW5yxFucFjLPXToGT5gWfjgFDgfPAj13Iqxvcu0Y=
X-Received: by 10.200.38.118 with SMTP id v51mr20801620qtv.205.1508255633651; Tue, 17 Oct 2017 08:53:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Tue, 17 Oct 2017 08:53:53 -0700 (PDT)
In-Reply-To: <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org>
References: <150774513036.24791.2138264254901122467@ietfa.amsl.com> <cc11634a-b5a2-88b9-f36f-82b3fd9d8d70@gmail.com> <1D30AF33624CDD4A99E8C395069A2A162CD734B2@sjceml521-mbx.china.huawei.com> <a4da4b26-6402-ad0d-a5f5-5bddc192b8f7@gmail.com> <4E40E3EF-B0E5-490E-BFF2-0511D97E9E80@employees.org>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 17 Oct 2017 08:53:53 -0700
Message-ID: <CALx6S341v1zd2Q9bts8-zrKxU59kieJTJJ=nHQ5w4oQZg=t_cA@mail.gmail.com>
Subject: Re: I-D Action: draft-han-6man-in-band-signaling-for-transport-qos-00.txt
To: Ole Troan <otroan@employees.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man WG <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/82Wch2EYeR7bxxbwcfP_GGdqA3g>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 17 Oct 2017 15:53:56 -0000

On Tue, Oct 17, 2017 at 12:11 AM, Ole Troan <otroan@employees.org> wrote:
>>> [LH] The propose does not introduce new hop-by-hop option header, we only introduce new option carried in the existing hop-by-hop option header,
>>
>> Yes, that is exactly what the paragraph from RFC8200 means: it
>> says "New hop-by-hop options are not recommended".
>
> Blindly reciting rules without also understanding and explaining the intent leads to unintended consequences.
>
RFC8200 also relaxes the requirement that HbH has to be examined by
every host which I think mitigates some of the concerns that prompted
the recommendation against new hop-by-hop options.

> In this particular case, where every hop along the path would need to support it, then that's the exact use case for the hop by hop header.
>
I don't think that every hop in the path would necessarily need to
support this. It may be the case that traffic engineering is only
being done on one or two links in the path (backbone links for
instance) so support is needed there, but nodes at other hops could
ignore the HbH option.

Tom

>
> Ole
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

v2.23.0 | Report a Bug | By Email