Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt

Brian Carpenter <brian.e.carpenter@gmail.com> Thu, 29 July 2021 10:32 UTC

Return-Path: <brian.e.carpenter@gmail.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 E44203A1D0A; Thu, 29 Jul 2021 03:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.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 W4nVJ4w7LGZC; Thu, 29 Jul 2021 03:32:25 -0700 (PDT)
Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 94FEE3A171E; Thu, 29 Jul 2021 03:32:24 -0700 (PDT)
Received: by mail-lj1-x231.google.com with SMTP id q2so6916659ljq.5; Thu, 29 Jul 2021 03:32:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fFOz3DNShjnPldXhSaLefm8SOMheWackRCJtejhfeak=; b=LVMzblZ6e8/QLw+KpS5F0v+JZVaZDi14XhEIrovTXA+GbD3NvyNKfLUdjhbK+ZNG61 32bxiys/g6nRxys5WtW/X0mC9+ZJDANFPTz3QW+SxZxHWREmyU1abRGSeeOmTnF39tUk ohQDEZul2mZFsMszYJW+HywNFBC6Ra60TKHLIzPJb+1jQGax//pTtpjf5+W+Wi+p32YO iHKDcbinr1WL2zEA7hx1G62ZzcRSw1yA1xSkYDNMmuFUuh+dsf48fl1EcabIQ0Xlwy02 J89NTUZfu9yohwA/QyJJEC9zKj1wbgiXv12JqNKqAHSChO/dQS+bIRFVQ/UGVNUnxCFy AUjg==
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=fFOz3DNShjnPldXhSaLefm8SOMheWackRCJtejhfeak=; b=HjDM2O6xYZyt+FD9aTF1BWI+0aQuI9Q3NA4MG1YI6S6GW68cogkPhV/4i3A3cmuhcR r73k41pImb76APektU44323Zqr8J/pxZMtYHf5Z6Z54wqjIABfj6LagYxcc80KQk6yuK isshLkLbgOti67jwynk118EAMM3PI059n5hhHOV2JHACv4b0v+KWnkL41ibhoupHlEmW pfDZrE1dxt/pwneO6XvkwvoOaliAZaGALIzO1nrvHkxkseMH9a9O3RkDJAXkzkySNcDE ySF6nQ98kw9EN9kmLwqEHSrHPJFvrsAboJ+aNmvBe2Qe1gSOGbt/6+tfa7V0q+AFvhBB rb4Q==
X-Gm-Message-State: AOAM532yuk0mUjC8N/8Yb0KQWi+auKC6zQuNPXpGhS3dspy+XLNpJl3/ /NX/var9s++qtUISsXmFXJOEQUfh+HOG64LjT3o=
X-Google-Smtp-Source: ABdhPJyDSB8lZXOXx6woP0EcZgzuBOivjlwuVCFGvjfudBWg9MkkJQW7rqHrSDHtqUJlkpWJg/DDd8YT5eUMFVg9mlo=
X-Received: by 2002:a05:651c:211:: with SMTP id y17mr2512195ljn.45.1627554741823; Thu, 29 Jul 2021 03:32:21 -0700 (PDT)
MIME-Version: 1.0
References: <ea7246fe81b140fba42e6d202c2afc8b@huawei.com> <B2749D3A-FF51-47ED-9D25-D973BF9A4309@gmail.com> <5cd00f25326146619c699160d671a4f2@huawei.com> <CAO42Z2zUcK_k=VO4b+wxJWDWxA=TR5w9W7oAufMZ9Ufiks6-Tw@mail.gmail.com> <CD3C5416-44A7-42A8-9F7A-3E14820A38C7@gmail.com> <CAO42Z2xuJ7k1MpfRvjup-+jKcM_BdWLHJUEc3WeUq0ME0t-rJg@mail.gmail.com>
In-Reply-To: <CAO42Z2xuJ7k1MpfRvjup-+jKcM_BdWLHJUEc3WeUq0ME0t-rJg@mail.gmail.com>
From: Brian Carpenter <brian.e.carpenter@gmail.com>
Date: Thu, 29 Jul 2021 22:32:10 +1200
Message-ID: <CANMZLAaxnZ8cRQ2B0+RvxWZDOBCezHWbdOnfX=e4zhoXBhAsGQ@mail.gmail.com>
Subject: Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Yoshifumi Nishida <nsd.ietf@gmail.com>, 6MAN <6man@ietf.org>, Christopher Wood <caw@heapingbits.net>, draft-ietf-6man-ipv6-alt-mark.all@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003d2fdd05c8409ec5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/C-Kg5s6T47WFIrozIuEsHhdFJEc>
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: Thu, 29 Jul 2021 10:32:30 -0000

I think IPv6 with smaller addresses would be a better approach, and there
have been various proposals that amount to that.

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Thu, 29 Jul 2021, 20:57 Mark Smith, <markzzzsmith@gmail.com> wrote:

> Hi Stewart,
>
> On Sat, 24 Jul 2021 at 19:39, Stewart Bryant <stewart.bryant@gmail.com>
> wrote:
> >
> > All of which is why MPLS or some evolution therefore is a better
> approach to providing a packet transport network (or other controlled
> domain). The operator of an MPLS network has complete control over the
> separation of the user traffic and their infrastructure traffic.
> >
> > It is going to be really interesting to see whether SRv6 triumphs or
> crashes out because of the difficulty of providing the degree of traffic
> separation that is intrinsic to  MPLS.
> >
>
> It has seemed to me that what is really missing is a general purpose
> local network limited protocol, "larger" than a link-layer protocol,
> yet "smaller" than a global internetworking protocol.
>
> IPv6 is really too "big" for SR. The IPv6 overhead is because of the
> 128 bit addresses, and they're that large because it is a global
> internetworking protocol that has to be able to uniquely address every
> node on the internetwork.
>
> It makes sense to try to use IPv6 for SR, since IPv6 is a future
> commodity protocol, however as it is "too large", there are then hacks
> like EH insertion or the SID compression proposals to try to get
> around the fundamental problem of using a protocol that isn't really a
> good enough fit for a local network problem and a solution like SR.
>
> MPLS is a local network protocol. Fine for use "inside the network"
> and something like SR.
>
> However I think it would be useful if we had a more general purpose
> local network protocol that is also well suited for use by hosts, and
> that, for example, transport layer protocols like UDP or TCP could be
> placed directly inside.
>
> I've idly wondered if we could repurpose IPv4 for that by giving it a
> new version number. It's now too small to be a global internetworking
> protocol, however would still be large enough to solve a local network
> problem. It just needs to be distinguished from the legacy use of IPv4
> as a global Internet protocol.
>
> It would be preferable though for a local network protocol to have
> addresses large enough to be so that there can be likely globally
> unique subnets, so that merging networks doesn't require renumbering
> or NAT. I wonder if 64 bit addresses, 32 bits Global ID (similar to
> ULA 48 bit ID), 16 bits subnets and 16 bits host addresses would be
> good enough.
>
> Regards,
> Mark.
>
> > - Stewart
> >
> >
> > On 24 Jul 2021, at 00:00, Mark Smith <markzzzsmith@gmail.com> wrote:
> >
> >
> >
> > On Fri, 23 Jul 2021, 18:20 Giuseppe Fioccola, <
> giuseppe.fioccola@huawei.com> wrote:
> >>
> >> Hi Mike,
> >>
> >> To avoid misunderstanding, the precondition of controlled domain may be
> kept as MUST. We can further specify that authentication MUST be used if,
> for specific scenarios, it is applied outside a controlled domain.
> >
> >
> > Realise that a "MUST be limited to a controlled domain" in an RFC is
> nothing more than an aspiration. It's theory rather than reality.
> >
> > Packets are encouraged to try to exit "controlled" domains attached to
> the Internet due to the domain's default route, and then can leave the
> controlled domain ("leak") due failure of the controlling boundary because
> of implementation bugs, operator configuration error or partial node
> failure.
> >
> > Authentication must be a MUST for anything that is designed for a
> controlled domain if the controlled domain may be attached to the Internet,
> which is a possibility for any of them if they use IPv6.
> >
> > Packets getting to where they shouldn't would be one of the motivations
> of Postel's "Be conservative with what you send".
> >
> >
> > Regards,
> > Mark.
> >
> >
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Giuseppe
> >>
> >>
> >>
> >>
> >>
> >> From: Mike Simpson <mikie.simpson@gmail.com>
> >> Sent: Friday, July 23, 2021 9:36 AM
> >> To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
> >> Cc: Erik Kline <ek.ietf@gmail.com>om>; Yoshifumi Nishida <
> nsd.ietf@gmail.com>gt;; 6man@ietf.org; Christopher Wood <caw@heapingbits.net>et>;
> draft-ietf-6man-ipv6-alt-mark.all@ietf.org
> >> Subject: Re: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
> >>
> >>
> >>
> >> Why not just keep it at MUST so that you don’t pollute the internets.
> >>
> >>
> >>
> >> We will end up having to filter for it anyway as always but it seems
> foolhardy and unpleasant to intentionally weaken the language.
> >>
> >>
> >>
> >> Your new hotness belongs in your controlled domain. If you are going to
> try and force it onto networks you don’t control then it’s not going to
> work and you will end up having to tunnel it anyways.
> >>
> >>
> >>
> >> Why is this so hard to understand?
> >>
> >>
> >>
> >> On 22 Jul 2021, at 15:09, Giuseppe Fioccola <
> giuseppe.fioccola@huawei.com> wrote:
> >>
> >> 
> >>
> >> Hi Erik,
> >>
> >> Thanks for the input.
> >>
> >> I tend to agree that the condition “MUST” can be changed to “SHOULD”. I
> can address your comments in the -08 version.
> >>
> >>
> >>
> >> Regards,
> >>
> >>
> >>
> >> Giuseppe
> >>
> >>
> >>
> >> From: Erik Kline <ek.ietf@gmail.com>
> >> Sent: Wednesday, July 21, 2021 11:15 PM
> >> To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
> >> Cc: Stewart Bryant <stewart.bryant@gmail.com>om>; Christopher Wood <
> caw@heapingbits.net>gt;; Yoshifumi Nishida <nsd.ietf@gmail.com>om>;
> 6man@ietf.org; draft-ietf-6man-ipv6-alt-mark.all@ietf.org
> >> Subject: Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
> >>
> >>
> >>
> >> Giuseppe,
> >>
> >>
> >>
> >> I think in S2.1 "MUST NOT" be used outside a "controlled domain" is
> perhaps a bit too strong.  Similarly in S6, "MUST be applied
> in...controlled domains" might be moderated down to "SHOULD only be
> applied...".
> >>
> >>
> >>
> >> I'll note that it is possible for an AH option to be used to ensure the
> DstOpt variant is unmodified en route, and these two in conjunction can be
> used wherever desired to send such packets outside the given domain
> (subject, of course, to all the middlebox interference any such packet
> would inevitably receive -- but that's a separate issue).
> >>
> >>
> >>
> >> On Tue, Jun 22, 2021 at 11:27 AM Giuseppe Fioccola <
> giuseppe.fioccola@huawei.com> wrote:
> >>
> >> Dear Stewart, Christopher, Yoshi, All,
> >> Please note that I just submitted a new version of the draft. It has
> been thoroughly reviewed to address the comments received during the Last
> Call.
> >>
> >> Your inputs are always welcome.
> >>
> >> Regards,
> >>
> >> Giuseppe
> >>
> >> -----Original Message-----
> >> From: ipv6 <ipv6-bounces@ietf.org> On Behalf Of
> internet-drafts@ietf.org
> >> Sent: Tuesday, June 22, 2021 8:13 PM
> >> To: i-d-announce@ietf.org
> >> Cc: ipv6@ietf.org
> >> Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-07.txt
> >>
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >> This draft is a work item of the IPv6 Maintenance WG of the IETF.
> >>
> >>         Title           : IPv6 Application of the Alternate Marking
> Method
> >>         Authors         : Giuseppe Fioccola
> >>                           Tianran Zhou
> >>                           Mauro Cociglio
> >>                           Fengwei Qin
> >>                           Ran Pang
> >>         Filename        : draft-ietf-6man-ipv6-alt-mark-07.txt
> >>         Pages           : 21
> >>         Date            : 2021-06-22
> >>
> >> Abstract:
> >>    This document describes how the Alternate Marking Method can be used
> >>    as a passive performance measurement tool in an IPv6 domain.  It
> >>    defines a new Extension Header Option to encode Alternate Marking
> >>    information in both the Hop-by-Hop Options Header and Destination
> >>    Options Header.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/
> >>
> >> There is also an htmlized version available at:
> >> https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-07
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-07
> >>
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >> --------------------------------------------------------------------
> >> 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
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > 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
> --------------------------------------------------------------------
>