Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>

Tom Herbert <tom@herbertland.com> Wed, 05 June 2019 15:05 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 EA3C61201B0 for <ipv6@ietfa.amsl.com>; Wed, 5 Jun 2019 08:05:27 -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 P3GB4D72S6FT for <ipv6@ietfa.amsl.com>; Wed, 5 Jun 2019 08:05:24 -0700 (PDT)
Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 B7045120058 for <ipv6@ietf.org>; Wed, 5 Jun 2019 08:05:16 -0700 (PDT)
Received: by mail-qk1-x72d.google.com with SMTP id w187so5310426qkb.11 for <ipv6@ietf.org>; Wed, 05 Jun 2019 08:05:16 -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=O2IAy5yHKKHv81zZiSHQxy0RE8ECwozKcCpmQCB4QVs=; b=T59RpTSaUK3yv9zOUDCXiRo6asSoTm2OmQv74gEQbeJJL/yUjMNaSPlMno5yqEXlTs iZIPnpp5HrpNjPihy4IYKadiWO/r5oelzAbV1gXcEqq8hiJ0GZEjvdcoPyeRSNai4S3S mZsnsHvM/KMZ4KzzRP9AuQVPYqf8XVGpnRRinvmTh1FBuEoHKH8UFOYn7MDv3iRRmI0t SUXpqCZha/9fMkxg76z2w08Ixda34tmPkXwr7nfOZ7BRfxR47K0hG0EfkZnTWCC4CVd2 TVoRUFpQ9LjQFM/6tK7IFldnIxYWL0+Q6TfECWRngRj48ffyfN891Tew00qdF2NwAHul 3y6w==
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=O2IAy5yHKKHv81zZiSHQxy0RE8ECwozKcCpmQCB4QVs=; b=jZhu+tifQ7eIc9X9BJKBmC0S0yogItcVzTV5QDccpP90Hn1GZHFvMht4S1vH58n4oB PtZb1QbXRSkXlPMorUqDLD7cdrcdxD/EWZW8uq65tcjqaZRfdmxpiOXIJNwPXQaqte7c vWxx2+vnIyHIfsw8UjZlwaSxbNuXKe5zXqnt9bovKTYLK8k1Xd293akPw4V/TKBOXa2g v38YnNsC4zD1FZ0FIZX+DOODI2r2z8weAXh8oNGcS/63QRsiOkP6jQjLJZWKZO1AgVo5 SVzsCDHxuJNoljZYsuyELi5b/MaQFYvx/h+4HGmMvBlWNLtFAiV9LwG0v8lYU81nE0Nn agWw==
X-Gm-Message-State: APjAAAUO4aZCIDZyQMzOcISZpv6v8GEbmG9iKnCwXm0siLPiHmWfBUR7 mExPYDh02Z/tXb8mv3Y1hbgrh56hwsbYauNfLYVGGw==
X-Google-Smtp-Source: APXvYqwyEudPYGl5hidEmh1T6p7fwkWCh5MtiBFHDUoXr2ZHpksnkylk1sTQqI6qRL/6jfGGuqIyPorOpagPpkHNTq0=
X-Received: by 2002:ae9:f20c:: with SMTP id m12mr33608942qkg.58.1559747115489; Wed, 05 Jun 2019 08:05:15 -0700 (PDT)
MIME-Version: 1.0
References: <20160428004904.25189.43047.idtracker@ietfa.amsl.com> <588C586F-C303-418E-8D26-477C4B37CF92@gmail.com> <C7C2E1C43D652C4E9E49FE7517C236CB0260698D@dggeml529-mbx.china.huawei.com> <E5ED231C-2592-4D5F-9FA5-CA3D97994BE8@cisco.com> <C7C2E1C43D652C4E9E49FE7517C236CB0260A5F8@dggeml529-mbx.china.huawei.com>
In-Reply-To: <C7C2E1C43D652C4E9E49FE7517C236CB0260A5F8@dggeml529-mbx.china.huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 05 Jun 2019 08:05:03 -0700
Message-ID: <CALx6S34fzjWOrLGaz=VnSRAq-zYDZAEy_f51UJCs8ginTffp=w@mail.gmail.com>
Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
To: "Chengli (Cheng Li)" <chengli13@huawei.com>
Cc: "Darren Dukes (ddukes)" <ddukes@cisco.com>, IPv6 List <ipv6@ietf.org>, Bob Hinden <bob.hinden@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/u4f0telzfXxkbk9JKz9yczEWOfk>
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: Wed, 05 Jun 2019 15:05:28 -0000

On Wed, Jun 5, 2019 at 1:21 AM Chengli (Cheng Li) <chengli13@huawei.com> wrote:
>
> Hi Darren,
>
>
>
> Thanks for your reply. It seems like reasonable to pre-allocate space for IOAM. Also, PBT[1] based Telemetry can avoid this problem.
>
>
>
> However, in Stateless SFC[2], the NSH TLV can be included in SRH to carry metadata. The length of metadata may be mutable and hard to be pre-computed when the MD type is 2.
>
> Maybe we still can pre-allocate enough space for this scenarios, but I still think we should make HDR as mutable.
>
>
>
> The fields that will not be changed en route will not affect the length of the SRH.
>
> The mutable fields  will not count when compute ICV, and the changes of them are allowed, so why to limit  the change of length? There is no need to limit the length of these fields, because this does not help on Authentication but brings limitation.
>
>
>
> It is a general problem for IOAM and SFC, which need to add metadata into data packets.
>
Hi Chengli,

Please look at https://trac.ietf.org/trac/6man/ticket/69 which
describes some of the operational problems of adding/deleting TLVs.
There is also an attribution problem.

The contents of a packet are attributed to the source which is
indicated by the source address. Fundamentally, the source of the
packet owns the bits and is responsible for the content. If an
intermediate node sets alternative content in a packet then at the
destination that content is attributed to the source. This content may
not conform to host policy, or for that matter might even be illegal,
and without any proper paper trail of who set the content, the source
is held accountable.

So the source requires fine grained control over what the network is
allowed to change, and authentication is means to enforce that
intermediate nodes only change the packet in permissible ways. If a
network node wants to change more than what the source allows, it is
free to encapsulate the packet for transit across the network, thus
itself becoming the source of the packet and so can set content in the
encapsulating headers per a different policy.

Tom

>
>
> Thanks,
>
> Cheng
>
>
>
>
>
> [1] https://tools.ietf.org/html/draft-song-ippm-postcard-based-telemetry-03
>
> [2] https://tools.ietf.org/html/draft-xuclad-spring-sr-service-programming-02#section-7.2.1
>
>
>
>
>
> -----Original Message-----
>
> From: Darren Dukes (ddukes) [mailto:ddukes@cisco.com]
>
> Sent: Tuesday, May 28, 2019 1:22 AM
>
> To: Chengli (Cheng Li) <chengli13@huawei.com>
>
> Cc: Bob Hinden <bob.hinden@gmail.com>; IPv6 List <ipv6@ietf.org>
>
> Subject: Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
>
>
>
> Hi Cheng, thanks for the support, I have a couple comments inline.
>
>
>
>
>
> > On May 27, 2019, at 8:41 AM, Chengli (Cheng Li) <chengli13@huawei.com> wrote:
>
> >
>
> > Support. Many thanks to authors for their contributions! I agree that we should specify how the AH works with SRH in other drafts.
>
> >
>
> > But I can NOT find any text of describing Hdr Ext Len is not mutable in RFC8200.
>
> > Hdr Ext Len SHOULD be mutable, otherwise, use cases like incremental SRv6 IOAM[1] can not work.
>
>
>
> draft-ali-6man-spring-srv6-oam-01 actually reserves TLV at an SR Source node for use by segment endpoint nodes, so it doesn’t change the size of TLVs (see 4.4.2.1 and 4.4.2.2 of that draft).
>
>
>
> > All the use cases of inserting or deleting new TLV, or updating TLV with new length value are not allowed if Hdr Ext Len is not mutable.
>
>
>
> Use cases you’re thinking of should be able to use a method similar to that in draft-ali-6man-spring-srv6-oam, I would be interested to hear about them.
>
>
>
> Thanks
>
>   Darren
>
>
>
> >
>
> > I think it is a limitation to SRv6 that we should avoid it definitely.
>
> >
>
> >
>
> > Best Regards,
>
> > Cheng
>
> >
>
> > [1]. https://tools.ietf.org/html/draft-ali-6man-spring-srv6-oam-01#section-4.4.1
>
> >
>
> > -----Original Message-----
>
> > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Bob Hinden
>
> > Sent: Wednesday, May 22, 2019 9:40 PM
>
> > To: IPv6 List <ipv6@ietf.org>
>
> > Cc: Bob Hinden <bob.hinden@gmail.com>
>
> > Subject: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-19.txt>
>
> >
>
> > Hello,
>
> >
>
> > This message starts a new two week 6MAN Working Group Last Call on advancing:
>
> >
>
> >       Title           : IPv6 Segment Routing Header (SRH)
>
> >       Authors         : Clarence Filsfils
>
> >                         Darren Dukes
>
> >                         Stefano Previdi
>
> >                         John Leddy
>
> >                         Satoru Matsushima
>
> >                         Daniel Voyer
>
> >             Filename        : draft-ietf-6man-segment-routing-header-19.txt
>
> >             Pages           : 32
>
> >             Date            : 2019-05-21
>
> >
>
> >    https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header
>
> >
>
> > as a Proposed Standard.
>
> >
>
> > This document was in an extended last call that started in March of 2018.   An issue tracker was set up, and eight new versions of the draft were produced and discussed on the list and at face to face 6man sessions.   All of the issues in the tracker have been closed.  The chairs believe it is ready to advance, but given the number of changes and the time that elapsed, a new w.g. last call is warranted.  Please review the new document.
>
> >
>
> > Our thanks to the authors/editors and the working group for the work on this document.
>
> >
>
> > Substantive comments and statements of support for publishing this document should be directed to the mailing list. Editorial suggestions can be sent to the author.  This last call will end on 5 June 2019.
>
> >
>
> > Thanks,
>
> > Bob & Ole
>
> >
>
> >
>
> >
>
> >
>
> > --------------------------------------------------------------------
>
> > IETF IPv6 working group mailing list
>
> > ipv6@ietf.org
>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
> > --------------------------------------------------------------------
>
> >
>
> > --------------------------------------------------------------------
>
> > IETF IPv6 working group mailing list
>
> > ipv6@ietf.org
>
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>
> > --------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------