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

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 11 Feb 2022 13:53:44 -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".

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 14 Feb 2022 15:00:53 +0000

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 <[email-masked]> 
Sent: Friday, February 11, 2022 2:54 PM
To: [email-masked]
Cc: 'IETF IPPM WG' <[email-masked]>
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.

Best,
Adrian

===

Abstract

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

[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

[GF]: We will include these changes.

[GF]: We will clarify this point.

[GF]: Yes.

   -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 

[GF]: This is a good suggestion. It looks reasonable to reduce the number of bits for NextHeader.

[GF]: We will include these changes.

9. You have ...

[GF]: Sure, good suggestion.

[GF]: We will do.

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

[GF]: We will revise the text.

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

[GF]: We will further clarify this part.

[GF]: We will add further details here.

---

Section 3.

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 14 Feb 2022 15:14:27 -0000

Thanks Giuseppe,

All looks good.

Adrian

-----Original Message-----
From: Giuseppe Fioccola <[email-masked]> 
Sent: 14 February 2022 15:01
To: [email-masked]; [email-masked]
Cc: 'IETF IPPM WG' <[email-masked]>
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.

Best Regards,

Giuseppe

-----Original Message-----
From: Adrian Farrel <[email-masked]> 
Sent: Friday, February 11, 2022 2:54 PM
To: [email-masked]
Cc: 'IETF IPPM WG' <[email-masked]>
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.

Best,
Adrian

===

Abstract

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

9. You have...

[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

[GF]: Yes.

   -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 

[GF]: This is a good suggestion. It looks reasonable to reduce the number of
bits for NextHeader.

9. You have ...

[GF]: We will do.

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

---

Section 3.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 28 Feb 2022 10:30:56 +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 <[email-masked]> 
Sent: Monday, February 14, 2022 4:14 PM
To: Giuseppe Fioccola <[email-masked]>; [email-masked]
Cc: 'IETF IPPM WG' <[email-masked]>
Subject: RE: A review of draft-zhou-ippm-enhanced-alternate-marking-08

Thanks Giuseppe,

All looks good.

Adrian

-----Original Message-----
From: Giuseppe Fioccola <[email-masked]>
Sent: 14 February 2022 15:01
To: [email-masked]; [email-masked]
Cc: 'IETF IPPM WG' <[email-masked]>
Subject: RE: A review of draft-zhou-ippm-enhanced-alternate-marking-08

Hi Adrian,

Best Regards,

Giuseppe

-----Original Message-----
From: Adrian Farrel <[email-masked]>
Sent: Friday, February 11, 2022 2:54 PM
To: [email-masked]
Cc: 'IETF IPPM WG' <[email-masked]>
Subject: A review of draft-zhou-ippm-enhanced-alternate-marking-08

Hi,

Best,
Adrian

===

Abstract

---

Requirements language

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

9. You have...

Section 2

[GF]: Yes.

9. You have ...

[GF]: We will do.

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

---

Section 3.