Hi Donald,






Thank you for the review and thoughtful comments.


I'll attempt to address your comments, although the relevant document is already in RFC Editor's Queue.


Please see inline my responses...





Best Regards,


Xiao Min



Original



From: DonaldEastlake <d3e3e3@gmail.com>
To: <rtg-ads@ietf.org> <rtg-ads@ietf.org>;
Cc: rtg-dir@ietf.org <rtg-dir@ietf.org>;draft-ietf-ippm-ioam-conf-state.all@ietf.org <draft-ietf-ippm-ioam-conf-state.all@ietf.org>;ippm@ietf.org <ippm@ietf.org>;Last Call <last-call@ietf.org>;
Date: 2022年12月14日 02:50
Subject: [ippm] RtgDir Last Call review: draft-ietf-ippm-ioam-conf-state-10 (really, this time)


_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm


Hello,

I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or
routing-related drafts as they pass through IETF last call and IESG
review, and sometimes on special request. The purpose of the review is
to provide assistance to the Routing ADs. For more information about
the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.


Document: draft-ietf-ippm-ioam-conf-state-10
Reviewer: Donald Eastlake 3rd
Review Date: 13 December 2022
IETF LC End Date: 
Intended Status: Standards Track


Summary:

I have some minor concerns about this document that I think should be
resolved before publication.


Comments:

This document is reasonably well written but has some minor issues and
occasionally scattered grammatical slips.


Major Issues:

No major issues found.


Minor Issues:

Section 3.1: Concerning the list of IOAM Namespace-IDs, it states that
Namespace-ID 0x000 MUST be first, any other occurrences of 0x000 MUST
be disregarded. This naturally leads me to the following:
   If there are multiple occurrences of other Namespace-IDs, are all but
the first ignored?

[XM]>>> As stated in section 6, duplicate IOAM Namespace-IDs is an error.

   Is there any ordering requirement on any Namespace-IDs after the
0x0000 and, if so, how are out-of-order Namespace IDs handled?

[XM]>>> No.


Section 4: There is some unstated assumption here that IOAM capability
information is wanted for a specific known unicast path. I think this
assumption should be made explicit.

[XM]>>> For IPv6, IOAM Capabilities Query would be sent to the known IOAM transit/decap nodes. For MPLS, IOAM Capabilities Query would be sent to the egress node and intercepted by the transit node through TTL expiration.


SoP / TSF:
- Either these need to be spelled out in the registry names for the
registries being created in Section 5 or each registry with such an
abbreviation in its registry name needs a note that includes the
abbreviation expansion.

[XM]>>> In section 5.1, it says "SoP: size of POT"; In section 5.2, it says "TSF: timestamp format". Do you see a need for some new text?

- Suggest adding these to Section 2.2 Abbreviations.

[XM]>>> OK.


Section 6, Page 16:
- There are two paragraphs in Section 6 where the first talks about
IOAM Capability information being carried across the network and the
second talks about collected IOAM Capability information. The first
paragraph reasonably gives example security methods for data in
transit. The second paragraph, however, does not mention or give an
example of how to protect collected information, which is presumably
data at rest. As it is, the paragraphs are mostly redundant except for
the first sentence of the 2nd paragraph. Suggest changing the 2nd
paragraph by replacing the existing material after the first sentence
with something like "Care should therefore be taken to limit access to
such collected IOAM Capabilities information."
- In the next to the last paragraph of Section 6, we first learn that
duplicate IAOM Namespace-IDs is an error. This should be mentioned
earlier where Namespace-IDs in messages is first discussed. This
paragraph also lists "whether the received Namespace-ID is an
operator-assigned or IANA-assigned one" as if that was an error
condition, which I don't understand.
[XM]>>> At this point, I prefer not to change section 6 in any way. As to the text "whether the received Namespace-ID is an operator-assigned or IANA-assigned one", it's from RFC 9197 which says "
The Namespace-ID value is divided into two subranges:

an operator-assigned range from 0x0001 to 0x7FFF and

an IANA-assigned range from 0x8000 to 0xFFFF.

"

Nits:

Section 1, page 3:
OLD
   Furthermore, each IOAM encapsulating node needs to establish
   NETCONF Connection with each IOAM transit and IOAM decapsulating
   node, the scalability can be an issue.
NEW
   Furthermore, each IOAM encapsulating node needs to establish a
   NETCONF Connection with each IOAM transit and IOAM decapsulating
   node, so scalability can be an issue.

Section 1, Page 4/5:
OLD
   Fate sharing is a common requirement for all kinds of active OAM
   packets, echo request is among them, in this document that means echo
   request is required to traverse a path of IOAM data packet.  This
   requirement can be achieved by, e.g., applying same explicit path or
   ECMP processing to both echo request and IOAM data packet.  Specific
   to apply same ECMP processing to both echo request and IOAM data
   packet, one possible way is to populate the same value(s) of ECMP
   affecting field(s) in the echo request.
NEW
   Fate sharing is a common requirement for all kinds of active OAM
   packets including echo request. In this document that means echo
   request is required to traverse the path of an IOAM data packet.
   This requirement can be achieved by, e.g., applying the same
   explicit path or ECMP processing to both echo request and IOAM data
   packets.  Specifically, the same ECMP processing can be applied to
   both echo request and IOAM data packets, by populating the same
   value(s) in ECMP affecting field(s) of the packets.

Section 3.2, Page 7:
"reply except the" -> "reply unless the"

Section 3.2.6, Page 13:
OLD
   it's
   RECOMMENDED to include only the IOAM Edge-to-Edge Capabilities Object
   but not the IOAM End-of-Domain Object.
NEW
   including only the IOAM Edge-to-Edge Capabilities Object
   but not the IOAM End-of-Domain Object is RECOMMENDED.

Multiple sections: It is just a tiny bit confusing that many fields
that are to be sent as zero and ignored on receipt are labeled with
the ordinary capitalized word "Reserved". Suggest that you consider
using "MBZ" or "RES" or even "RESERVED" so you don't end up
duplicating the word when you say "Reserved field is reserved ..."
In Section 3.2.6, however, there is a "Must Be Zero" field and,
although all the fields are explained in other cases, there is no
explanation below for that field.



[XM]>>> Thank you for catching the Nits. Will work with RFC Editor to address them.


Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com