[ippm] A review of draft-zhou-ippm-enhanced-alternate-marking-08

Adrian Farrel <adrian@olddog.co.uk> Fri, 11 February 2022 13:53 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4263A0EFC; Fri, 11 Feb 2022 05:53:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 LXYkgsUX7VuX; Fri, 11 Feb 2022 05:53:53 -0800 (PST)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1963A0EB8; Fri, 11 Feb 2022 05:53:49 -0800 (PST)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21BDrleB013002; Fri, 11 Feb 2022 13:53:47 GMT
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F2D734604B; Fri, 11 Feb 2022 13:53:46 +0000 (GMT)
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E472B4604A; Fri, 11 Feb 2022 13:53:46 +0000 (GMT)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS; Fri, 11 Feb 2022 13:53:46 +0000 (GMT)
Received: from LAPTOPK7AS653V ([185.69.145.139]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.7/8.14.7) with ESMTP id 21BDrjkI012867 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Feb 2022 13:53:46 GMT
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-zhou-ippm-enhanced-alternate-marking@ietf.org
Cc: 'IETF IPPM WG' <ippm@ietf.org>
Date: Fri, 11 Feb 2022 13:53:44 -0000
Organization: Old Dog Consulting
Message-ID: <013e01d81f4e$c9f49870$5dddc950$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AdgfTqHA04mXeuu6RYeNAqWhYI87Ig==
X-Originating-IP: 185.69.145.139
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26708.007
X-TM-AS-Result: No--9.809-10.0-31-10
X-imss-scan-details: No--9.809-10.0-31-10
X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26708.007
X-TMASE-Result: 10--9.809100-10.000000
X-TMASE-MatchedRID: vTggjsizJko/9d9Rtcc0QzjNGpWCIvfTqb3/o5s+OcOzU0R+5DbDbA6W 63YXHef5s1DjnptlKr1zMoqPP9gdfsbcufj3Z2WP48SQ1JLtjzZi7WMB+JdKzhZ50KsQddqXA4e V6z+cHCezy8ybFR3tWymAx1y7V3TO9bQi0x27p1Vu2K0KSdxtGZEZHK6QPaaAsp5O052MzLpaIw ffERDGg2DYIimYuRyoJV7owmedjIX2V7leZS72wJK9FvwQx1hFTJDl9FKHbrmOsIgtFYQODW4RZ q5BvfozKw3AB667zKfjbApvORO3+6jc9XKJCqAFGUlF/M3Dxp/XJ9TQ+cQuGrobGHR5ejtrUItS uNQYAOJqc8+O2MIGuLLKHtU5vzoDPtZlIcdv/kwJWwXuYyhn/Vr2hZxjCLzqVtYy28d/67oFHa/ TMxaMW/V0k+dUwfaY7oMhxEU/K+apjpSOO6e1WW6yfYFZzrGdBXngI6jFvpfnCThanP/ghA29Ru F/Ea6vkOt2Qii5Or1STeqbcpgxams0SgWtnXgni82UiskMqcws9yCYjUR6SwRmWZt2QrlxGRoBm h+0eS1D5z4Eu8GTrO0kqSbnChsfaWPqw6Sbal4dZEkR8Y/meSyCAXe1c03kUQ+YXiZ8bitKQ+EC +8ID2Wb8oZMUwoFWxIBO056PLSqOkKYrsG6nIyyKzJY7d2nbqf/efKFN1nChpj2O74VkxL7kVdr o2lkUu+3yeZVNvjolpl5namVxtwi6D5lVGR6pc7uq4k7WFKN9LQinZ4QefL6qvLNjDYTwC+Cmxf KmwAwMyrfP9j+C1d934/rDAK3zGjFMngtLLWicA6dTiL9847TLZE5MiH7narQHZeuyYnec5KipF PC57kguqoMt3cLJeiSXZ7J6jQI=
X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/tXPO5oZFsoGhLDUW19pWuobTdck>
Subject: [ippm] A review of draft-zhou-ippm-enhanced-alternate-marking-08
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Feb 2022 13:53:56 -0000

Hi,

I've just been looking at draft-ietf-6man-ipv6-alt-mark, so I thought
I would also have a look at this draft.

Here are a few comments that the authors may find helpful.

Best,
Adrian

===

Abstract

1. Don't use references in the Abstract
2. It would be really nice to say which enhanced capabilities and
   functions are provided and allowed.
3. s/the enhanced/enhanced/

---

Requirements language

1. You should move this down into section 1.1
2. You need to use the up-to-date boilerplate

---

Section 1

1. s/an hybrid/a hybrid/
2. s/IPv6 AltMark Option/The IPv6 AltMark Option/
3. s/to the IPv6 protocol/to IPv6/
4. s/defines Extension/defines an Extension/
5. s/encode Alternate/encode the Alternate/
6. s/both Hop-by-Hop/both the Hop-by-Hop/
7. s/and Destination/and the Destination/
8. s/carried as SRH TLV/carried as a TLV in the Segment Routing Header/
9. You have...
   While the AltMark Option implements the basic alternate marking
   method, this document defines the extended data fields for the
   AltMark Option and provides the enhanced capabilities.
   ...I'm not clear, but I think, s/the extended/extended/ and
   s/the enhanced/enhanced/
   But I think that the Introduction (in more detail than the Abstract) 
   needs to give clues about those capabilities.

---

Section 2

1. s/the next figure/Figure 1/
2. s/An 8 bits/An 8-bit/
3. It is not clear from the text that two bits of the former Reserved
   field remain reserved, are shown as R in the figure, and MUST continue
   to be set to zero on transmission and ignored on receipt.
4. s/Fig. 1:/Figure 1:/   (same for all the figures)
5. Figure 1 is slightly confusing as Section 3.1 of draft-ietf-6man-ipv6
   -alt-mark shows two additional fields (Option Type and Opt Data Len)
8. Do you really need 8 bits for the NextHeader field. You have reserved 
   0-8 for special purposes, and used just one other value (9). At the 
   same time you have removed 8 out of the 10 bits available for future
   extensions. Furthermore, 8 values looks like a lot of experimentation
   space. Why not...
   - Keep zero as reserved (for backward compatibility - by the way, you 
     should say in the text why zero is reserved)
   - Reduce experimentation to the values 1, 2, 3
   - Assign just 4 bits for "NextHeader"
7. I really feel that you are going to need a registry for the values of
   the NextHeader field.
8. s/The following figure/Figure 2/
9. You have ...
   o  Flag - A 4 bits flag to indicate the special purpose usage.
   ...It's OK, but could you add "(see below)" to save me from panic.
10. s/A 4 bits flag/A 4-bit flag/
11. For Len ("It indicates the length of extension headers.") you need
   to say what is counted and in what units. Do you start at FlowMonID
   Ext or after Padding? Do you count in octets or double words?
12. s/A 16 bits Bitmap/A 16-bit bitmap/
13. To be clear, is the padding there specifically as padding, or is a 
    reserved field? What does "when not being used" mean? Looking later
    I think that you only have padding present sometimes, so it is 
    genuinely padding, but the text does not explain when it is there and
    when it isn't.
14. s/requested to set/requested to be set/
15. Similarly for MetaInfo, could you add "(see below)"?
16. s/The Flag is defined as/The Flag is defined in Figure 3 as/
17. OLD
    others - Reserved.
    NEW
    others (shown as R) - Reserved. MUST be set to zero and ignored on
    receipt.
    END
18. s/as a bit map as follows:/in Figure 4 as a bit map as follows:/
19. I read "stands for the second part" several times before I realised
    you mean "stands of the number of seconds in the timestamp" and not
    "the second part of the timestamp"!
20. I see that various pieces of information are present if a particular
    bit in the bitmap is set. But you don't talk about whether that 
    information must be ordered according to the order of the bits (of
    course it must be).
21. Figure 6 shows Control as a 6-bit field and Period as a 10-bit 
    field. If this is an error, fix the figure. If it is intentional
    please make it clear in the text.
22. How are the various fields of the control information extension 
    used? I feel you may be missing some reference pointers.
23. What is the sequence number used for?

---

Section 3.

   In particular the fundamental
   security requirement is that Alternate Marking MUST be applied in a
   specific limited domain, as also mentioned in [RFC8799].

It's subtle, but I think you don't mean that it MUST be applied in a
specific limited domain. Possibly "it MUST only be applied".