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

Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Mon, 28 February 2022 10:31 UTC

Return-Path: <giuseppe.fioccola@huawei.com>
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 A186E3A0E60; Mon, 28 Feb 2022 02:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 3XXQC03L5-sX; Mon, 28 Feb 2022 02:31:00 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2AEB3A0E5A; Mon, 28 Feb 2022 02:30:59 -0800 (PST)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4K6c822sHFz67wrC; Mon, 28 Feb 2022 18:29:54 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Mon, 28 Feb 2022 11:30:56 +0100
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2308.021; Mon, 28 Feb 2022 11:30:56 +0100
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "draft-zhou-ippm-enhanced-alternate-marking@ietf.org" <draft-zhou-ippm-enhanced-alternate-marking@ietf.org>
CC: 'IETF IPPM WG' <ippm@ietf.org>
Thread-Topic: A review of draft-zhou-ippm-enhanced-alternate-marking-08
Thread-Index: AdgfTqHA04mXeuu6RYeNAqWhYI87IgCNetXwAAon5oACuCyckA==
Date: Mon, 28 Feb 2022 10:30:56 +0000
Message-ID: <33cc90341243464ca5c495abeb90aec2@huawei.com>
References: <013e01d81f4e$c9f49870$5dddc950$@olddog.co.uk> <e1136b61ce3840e397006109bfd75ad5@huawei.com> <034a01d821b5$8fe16460$afa42d20$@olddog.co.uk>
In-Reply-To: <034a01d821b5$8fe16460$afa42d20$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.199.215]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/lJdpVXhfvd0wxmAEZ5Mv2ZHMPsk>
Subject: Re: [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: Mon, 28 Feb 2022 10:31:05 -0000

Dear Adrian, All,
Please note that we just submitted a new version of the draft to address your comments.

Feedback and comments are always welcome.

Regards,

Giuseppe


-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk> 
Sent: Monday, February 14, 2022 4:14 PM
To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; draft-zhou-ippm-enhanced-alternate-marking@ietf.org
Cc: 'IETF IPPM WG' <ippm@ietf.org>
Subject: RE: A review of draft-zhou-ippm-enhanced-alternate-marking-08

Thanks Giuseppe,

All looks good.

Adrian

-----Original Message-----
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
Sent: 14 February 2022 15:01
To: adrian@olddog.co.uk; draft-zhou-ippm-enhanced-alternate-marking@ietf.org
Cc: 'IETF IPPM WG' <ippm@ietf.org>
Subject: RE: A review of draft-zhou-ippm-enhanced-alternate-marking-08

Hi Adrian,
Thanks a lot for your thorough revision. 
It will help to improve the document and we plan to publish the new revision soon.

Please find my responses inline as [GF].

Best Regards,

Giuseppe

-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk>
Sent: Friday, February 11, 2022 2:54 PM
To: draft-zhou-ippm-enhanced-alternate-marking@ietf.org
Cc: 'IETF IPPM WG' <ippm@ietf.org>
Subject: A review of draft-zhou-ippm-enhanced-alternate-marking-08

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/

[GF]: Sure, I will apply these changes and specify what are the enhanced capabilities, for example thicker packet loss measurements and more dense delay measurements with no limitation for the number of concurrent flows under monitoring

---

Requirements language

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

[GF]: Yes, we will do.

---

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/

[GF]: We will include these changes.

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.

[GF]: We will apply the suggested changes. I agree that more detailed information about the enhanced capabilities can be included in the Introduction.
---

Section 2

1. s/the next figure/Figure 1/
2. s/An 8 bits/An 8-bit/

[GF]: We will include these changes.

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.

[GF]: We will clarify this point.

4. s/Fig. 1:/Figure 1:/   (same for all the figures)

[GF]: Yes.

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"

[GF]: This is a good suggestion. It looks reasonable to reduce the number of 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/

[GF]: We will include these changes.

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.

[GF]: Sure, good suggestion.

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/

[GF]: We will do.

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.

[GF]: We can clarify that padding is a variable length field as further specify later in the document.

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:/ 

[GF]: We will apply these changes.

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"!

[GF]: We will revise the text.

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).

[GF]: Yes, we will clarify this point.

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.

[GF]: We will further clarify this part.

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?

[GF]: We will add further details here.

---

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".

[GF]: Yes, we will revise this section as well.