Comments on draft-fz-6man-ipv6-alt-mark-09
Tom Herbert <tom@herbertland.com> Mon, 18 May 2020 21:47 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 C382C3A0E40 for <ipv6@ietfa.amsl.com>; Mon, 18 May 2020 14:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 cr5OuKkFFLoQ for <ipv6@ietfa.amsl.com>; Mon, 18 May 2020 14:47:23 -0700 (PDT)
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 DF91C3A0E3D for <6man@ietf.org>; Mon, 18 May 2020 14:47:22 -0700 (PDT)
Received: by mail-ed1-x531.google.com with SMTP id i16so5396242edv.1 for <6man@ietf.org>; Mon, 18 May 2020 14:47:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=WwekwYbEGgorJk2RsrihNFm+pMzBFlXiAOzyz4ooFq4=; b=f+19PXKaHY9yJMbwhBFhn6hNnv6yDM9ucmPVZaMc//b+JB5V7OqJvvmVYhJHUSObCO lNe/ukacf4+uAyE7PJYwqn3T27OnrJUFHew7z13wbVKcp8i1h3bM5jj8brXD6x14naFy 0y+Gmtd0IaBDH7V2mVzy86cYBKgYwd3FYifBjQGwc9v0TPPTvntiTBT29AALwrskS/LO DYWt3N8uuSQXSsA25JroANf9IHYuUZtcVrVnMmGZ7DSj7SjyHsWLeyAoAZ6H0bngpjsk MmUyF+lc78hqLg5n3bIR8oSjvf6vWRa0T3bitUWwX9JL7QqpqLnfyFJ5C1Rofzc0wGrc F2uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WwekwYbEGgorJk2RsrihNFm+pMzBFlXiAOzyz4ooFq4=; b=UN7Pq7KzvOBs92EH+eNjK3WE2fgk7PjsnxYB2WLksDy1R9lqR2rTBPE+imNHPxQSMq m/DNjvuSGJ0aBKnfUHbHVNxeKTn+z/DC3/pDiSeX9qUvNyBUAmhwQsFCD3aER2O0eekS 0ZCm0p1GpGqevzYUCQg7i/zaNuWK2WtfM+roBU/BXY5MvSE6QhNk2uXrNnGddewC7ejp rpz+Q6c77EhhJFaXhvpbVmyBNp1q7rfGvXP+AqH/UnoMm3TpYRaIxCPypewf0MlDypFS SIIJixvXeNP4XzHIvhOI2MK2CAifYRgqZjhDUZoG+9+X6eMsky7Jr7Y3ob2DPNYJnv9C oNVg==
X-Gm-Message-State: AOAM53357nayFKWuHrk3/8PCqjbX6Bdgf5tQpUxtdamsS271qsb+9F3a v+FxnzomqfD6RPU9TIDcPR63UzTbNu4zGXmCL5GodAsJWAU=
X-Google-Smtp-Source: ABdhPJx384UO2LCOY7npz/2xqV+BI3MHUG8ZxXRRonRZjkuFqRZeLKAVWuC/PZintcvAMfXMOPnBFKKiGfJQ8gv1UCk=
X-Received: by 2002:aa7:cd69:: with SMTP id ca9mr1999855edb.370.1589838440650; Mon, 18 May 2020 14:47:20 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 18 May 2020 14:47:09 -0700
Message-ID: <CALx6S35bWVkTWcbdOt-HA-9XbH4WwRsTyaUdDA5q4rUNJvNNiw@mail.gmail.com>
Subject: Comments on draft-fz-6man-ipv6-alt-mark-09
To: 6MAN <6man@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/_UOfbUqIfmtBWHI6yH835RhbIu0>
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: Mon, 18 May 2020 21:47:25 -0000
>From the draft: "In case of Destination Option Header carrying Alternate Marking bits, it is not processed, inserted, or deleted by any node along the path until the packet reaches the destination node." The term "destination node" is a bit ambiguous wrt Destination Options before the routing header (I realize this wording is probably from RFC8200). In that case, any visited destination in the route list can process the option. Might make sense to clarify since the proper use of the Destination Option that are inspected by intermediate nodes is mentioned in the context of routing headers. >From the draft; "The only motivation for the hop by hop usage of Destination Options can be for compatibility reasons but in general it is not recommended." That also would be a nonconformant with RFC8200. IMO this doesn't need to be suggested. >From the draft: "Another application that can be mentioned is SRv6..." This is true of any routing header type, not just SRH. I don't see the need to explicitly focus on SRv6 or SRH here. It's unclear to me how the FlowMonID is set, how it's used, and why the Flow Label isn't sufficient for this purpose. For instance, from the draft: "The FlowMon identifier field is to uniquely identify a monitored flow within the measurement domain." That would seem to mean that monitored flow needs a unique ID assignment. How does this work? It seems like this will require a pretty complex and stateful control plane protocol. Also, 20 bit identifiers would seem to be on the light side for scaling in even moderately large networks. Why not just identify a measured flow by the tuple of (SrcAddr, DstAddr, Flow Label). This guarantees a unique tuple per measured flow. The 3-tuple can easily be hashed 32 or 64 bits to generate a single, relatively unique identifier. The draft raises the concern that flow labels might change, however I believe that argument has been overblown as a concern. Note per RFC 6437: "A forwarding node MUST either leave a non-zero flow label value unchanged or change it only for compelling operational security reasons as described in Section 6.1." So flow labels really aren't supposed to change in flight. We also learned the lesson at the source host not to change flow labels during the lifetime of a flow as that can cause problems especially when the flow label is used for ECMP and there is a stateful firewall in the path (there was a bug in Linux we fixed where the flow label was not retained when a TCP connection entered CLOSE_WAIT and so firewalls were missing the sent FIN since it was being routed different). AFAIK, Linux servers will not send consistent flow labels for the like of the connection (at least by default). I would note, that if the FlowMonID could be eliminated that the option data would just be a single byte. Tom
- Comments on draft-fz-6man-ipv6-alt-mark-09 Tom Herbert
- RE: Comments on draft-fz-6man-ipv6-alt-mark-09 Tianran Zhou
- Re: Comments on draft-fz-6man-ipv6-alt-mark-09 Brian E Carpenter
- Re: Comments on draft-fz-6man-ipv6-alt-mark-09 Tom Herbert
- RE: Comments on draft-fz-6man-ipv6-alt-mark-09 Giuseppe Fioccola
- Re: Comments on draft-fz-6man-ipv6-alt-mark-09 Tom Herbert
- RE: Comments on draft-fz-6man-ipv6-alt-mark-09 Giuseppe Fioccola
- Re: Comments on draft-fz-6man-ipv6-alt-mark-09 Tom Herbert
- RE: Comments on draft-fz-6man-ipv6-alt-mark-09 Giuseppe Fioccola