Hi Donald,






Thank you for the reply.


Please see inline...






Best Regards,



Xiao Min



Original



From: DonaldEastlake <d3e3e3@gmail.com>
To: 肖敏10093570;
Cc: rtg-ads@ietf.org <rtg-ads@ietf.org>;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@ietf.org <last-call@ietf.org>;
Date: 2022年12月15日 05:00
Subject: Re: [ippm] RtgDir Last Call review: draft-ietf-ippm-ioam-conf-state-10 (really, this time)




Thanks for your quick response.
See below at <de>.




On Wed, Dec 14, 2022 at 4:49 AM <xiao.min2@zte.com.cn> wrote:


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.



<de> You're welcome. For some reason I was asked to review your draft after it was in the RFC Editor's Queue so I'm not sure what will happen to comment resolutions.

[XM-2]>>> I see.



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.









<de> OK. If it is convenient to modify the document, I think it would be good to mention earlier in the document, where Namespace-IDs are first mentioned, that duplicates are an error and that, except for the requirement that 0x0000 be first, the Namespace-IDs can be in any order.

[XM-2]>>> OK. Do the changes as below satisfy you?

OLD


A list of IOAM Namespace-IDs (one or more Namespace-IDs)
 MUST be included in this container in the echo request, and if
 present, the Default-Namespace-ID 0x0000 MUST be placed at the
 beginning of the list of IOAM Namespace-IDs. The IOAM encapsulating
 node requests only the enabled IOAM capabilities that match one of
 the Namespace-IDs. NEW

A list of IOAM Namespace-IDs (one or more Namespace-IDs)
 MUST be included in this container in the echo request, and if
 present, the Default-Namespace-ID 0x0000 MUST be placed at the
 beginning of the list of IOAM Namespace-IDs, except which the Namespace-IDs can be in any order. The IOAM encapsulating
 node requests only the enabled IOAM capabilities that match one of
 the Namespace-IDs. Any duplicates of Namespace-ID are an error and MUST be ignored by the receiving node.


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.









<de> I was primarily wondering about multicast.

[XM-2]>>> It seems to me nothing prevents this mechanism to be used for multicast. Considering RFC 9197 doesn't mention unicast or multicast, I prefer to remain the current text as is.

 


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?









<de> I think that text just in this draft is not sufficient. Someone looking at the Registries on the IANA web pages needs a bit more explanation. Of course, I suppose the RFC this draft is published as will be listed as a Reference from the IANA Registries which helps a lot. And maybe IANA will spontaneously put a little of this text into a Note at the beginning of each registry...

[XM-2]>>> I checked IOAM registries (https://www.iana.org/assignments/ioam), there is no such a note. Considering the current text was produced during the IESG review, I prefer to remain it as is.




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









<de> Yes, I understand there are two ranges of IDs but they are mentioned here in the Security Considerations section in a paragraph about checking that "the fields in received echo requests and replies strictly conform to the specifications". I wasn't sure what being operator-assigned or IANA-assigned had to do with strictly conforming to the specifications.

[XM-2]>>> This document reuses the Namespace-ID defined in RFC 9197. The idea is that the receiving node may know all the operator-assigned and IANA-assigned Namespace-IDs, at this time if a Namespace-ID outside which is received then it's seen as an error. Does that make sense?

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


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