Re: [ippm] John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)

[[e-mail]]

Hi John,






Thank you for the review and thoughtful comments, very detailed and helpful.


Please check inline my responses.





Best Regards,


Xiao Min







Original



From: JohnScudderviaDatatracker <[e-mail]>
To: The IESG <[e-mail]>;
Cc: [e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;[e-mail] <[e-mail]>;
Date: 2022年10月27日 04:34
Subject: John Scudder's Discuss on draft-ietf-ippm-ioam-conf-state-07: (with DISCUSS and COMMENT)


John Scudder has entered the following ballot position for
draft-ietf-ippm-ioam-conf-state-07: Discuss
 
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
 
 
Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/  
for more information about how to handle DISCUSS and COMMENT positions.
 
 
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-ioam-conf-state/
 
 
 
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
 
### Clarity about scope of the document
 
As I understand it, this document isn't intended to be an implementable
protocol specification on its own; rather, "specification details for these
different echo request/reply protocols are outside the scope of this document".

[XM]>>> Yes, absolutely correct.


If this approach is to be followed there are some changes needed. Below I
provide some suggested text -- please know that I'm just supplying this as a
straw man to illustrate my thinking; while you're welcome to use the text I've
provided, I don't necessarily expect that.

[XM]>>> Understood.


The Abstract says that "This document describes an extension to the echo
request/reply mechanisms". It does not. Here's an example of how it might be
changed to be clearer.
 
OLD:
   This document describes an extension to the echo request/reply
   mechanisms used in IPv6 (including Segment Routing with IPv6 data
   plane (SRv6)), MPLS (including Segment Routing with MPLS data plane
   (SR-MPLS)), Service Function Chain (SFC) and Bit Index Explicit
   Replication (BIER) environments, which can be used within the In situ
   Operations, Administration, and Maintenance (IOAM) domain, allowing
   the IOAM encapsulating node to discover the enabled IOAM capabilities
   of each IOAM transit and IOAM decapsulating node.
 
NEW:
   There is a need to extend echo request/reply mechanisms used in IPv6
   (including Segment Routing with IPv6 data plane (SRv6)), MPLS
   (including Segment Routing with MPLS data plane (SR-MPLS)), Service
   Function Chain (SFC) and Bit Index Explicit Replication (BIER)
   environments, for use within the In situ Operations, Administration,
   and Maintenance (IOAM) domain, allowing the IOAM encapsulating node
   to discover the enabled IOAM capabilities of each IOAM transit and
   IOAM decapsulating node.
 
   Although this document does not itself specify the necessary
   extensions, it specifies formats and objects that can be used in such
   specifications, and provides guidelines and requirements for their
   development.

[XM]>>> It seems this comment is similar to that one made by Alvaro Retana. Does the abstract proposed by Alvaro work for you?

NEW Abstract:

   This document describes a generic format for use in echorequest/reply mechanisms, which can be used within an In situOperations, Administration, and Maintenance (IOAM) domain, allowingthe IOAM encapsulating node to discover the enabled IOAM capabilitiesof each IOAM transit and IOAM decapsulating node.  The generic formatis intended to be used with a variety of data planes such as IPv6,MPLS, Service Function Chain (SFC)   and Bit Index Explicit Replication (BIER).


I think the Introduction also needs to be cleaned up. Saying that
"specification details... are outside the scope" undersells the scope of what's
needed. For example, maybe these changes would work in the Introduction:
 
OLD:
   This document describes an extension to the echo request/reply
   mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS),
   SFC and BIER environments, which can be used within the IOAM domain,
   allowing the IOAM encapsulating node to discover the enabled IOAM
   capabilities of each IOAM transit and IOAM decapsulating node.
 
NEW:
   This document specifies formats and objects that can be used in the
   extension of echo request/reply mechanisms used in IPv6 (including
   SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can
   be used within the IOAM domain, allowing the IOAM encapsulating node
   to discover the enabled IOAM capabilities of each IOAM transit and
   IOAM decapsulating node.

[XM]>>> The new text you provided looks good to me. Tend to use it.


OLD:
   Note that specification details for these different echo request/
   reply protocols are outside the scope of this document.  It is
   expected that each such protocol extension would be specified by an
   RFC and jointly designed by the working group that develops or
   maintains the echo request/reply protocol and the IETF IP Performance
   Measurement (IPPM) Working Group.
 
NEW:
   It is expected that the specification of the instantiation of each of
   these extensions will be done in the form of an RFC jointly designed
   by the working group that develops or maintains the echo
   request/reply protocol and the IETF IP Performance Measurement (IPPM)
   Working Group.

[XM]>>> The new text you provided looks good to me. Tend to use it.


### Clarity of formats
 
Because this document is specifying things (or trying to) in absence of any
concrete instantiation, it's difficult for me to evaluate if the formats as
specified are complete and unambiguous. For now I've left my detailed
discussion of this in my COMMENT section, and am optimistic that we can sort it
out. However, I'm putting a placeholder here in case that problem turns out to
be thornier than hoped.
 [XM]>>> Understood. Hope my responses can make your evaluation easier.
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
 
# John Scudder, RTG AD, comments for draft-ietf-ippm-ioam-conf-state-07
CC @jgscudder
 
## COMMENTS
 
### Section 1
 
```
   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.
```
 
Explicit path, yes, but it's known that you can't simply expect to "apply same
ECMP processing" to two quite distinct packets, without carefully arranging for
that to happen. If this is a requirement (and the paragraph says it is) then I
think it's necessary to be clearer about how it's to be achieved.

[XM]>>> OK. Propose to add some new text on "apply same ECMP processing" as below.

NEW

   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.


### Section 3.1, Default-Namespace-ID
 
```
               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
   begining of the list of IOAM Namespace-IDs.  The IOAM encapsulating
   node requests only the enabled IOAM capabilities that match one of
   the Namespace-IDs.  The Namespace-ID has the same definition as
   what's specified in Section 4.3 of [RFC9197].
```
 
- You specify that if present 0x0000 must be placed at the beginning of the
list. Is there any other sorting requirement on the list, or is that the only
mandated ordering?

[XM]>>> That's the only mandated ordering.


- It wasn't clear to me from a quick perusal of RFC 9197 §4.3 whether a request
carrying 0x0000 would elicit replies for all Namespace-IDs (since 0x0000
matches everything) or if it would elicit replies only for capabilities that
have no configured non-default namespace, or are explicitly configured with
namespace 0x0000. Can you either clarify this in the text, or if you think it's
clear from the reference, help me understand what makes it clear?

[XM]>>> As I understand it, a request carrying 0x0000 would elicit replies only for capabilities that are explicitly configured with namespace 0x0000. Also note that namespace 0x0000 is the default one, so if there is no any other namespace configured, then all capabilities configured are for namespace 0x0000 by default. Propose to add some text as below.

NEW

   An IOAM Capabilities Query carrying only the Default-Namespace-ID 0x0000 would elicit replies only for capabilities that are explicitly configured with the Default-Namespace-ID 0x0000.


- If the first guess above is correct (0x0000 elicits replies for all
Namespace-IDs) then it would seem that if the list contains 0x0000, it's
pointless to include anything else in the list, and that might be worth
pointing out in the text.

[XM]>>> Pls see above my explanation.


- If the first guess above is correct, that would also prompt comments on the
use of Namespace-ID field in Sections 3.2.x, but we can address that if needed.

[XM]>>> Pls see above my explanation.


### Section 3.1, container format, padding
 
```
   The IOAM Capabilities Query Container has a container header that is
   used to identify the type and optionally length of the container
   payload, and the container payload (List of IOAM Namespace-IDs) is
   zero-padded to align to a 4-octet boundary.
 
   The length, structure, and definition of the IOAM Capabilities Query
   Container Header depends on the specific environment it is applied
   at.
```
 
I regret I'm not sufficiently familiar with all the different bearer protocols
you're envisioning embedding this container in. So I'll just ask,
 
- Why is the length of the payload said to be optional, when it's a (presumably
variable-length) list? Does this relate to a bearer protocol where the length
of the list is inferred some other way, or what?

[XM]>>> Yes, this relates to ICMPv6 which has no length field in its header, and the length field in the IPv6 header would be used otherwise.


- The specification that the payload is zero-padded to 4-octet alignment
carries some implications. Let's explore these with an example. Suppose we want
to signal a single Namespace-ID, 0x0001. Then presumably the payload has to be
0x0001 0x0000, once the mandated pad bytes are added. Is the receiver supposed
to know that it ignores the 0x0000 value (which is otherwise the
Default-Namespace-ID) because it comes at the end of the list, not the
beginning as the previous paragraph required? If so, this seems worth calling
out. If not, how is the receiver supposed to know where payload ends and
padding begins?

[XM]>>> In your example, I believe the last 0x0000 should be treated as padding by the receiver. Do you see a need for some new text?


### Section 3.2, container format, padding
 
Similar questions to those above apply to:
 
```
   The IOAM Capabilities Response Container has a container header that
   is used to identify the type and optionally length of the container
   payload, and the container payload (List of IOAM Capabilities
   Objects) is zero-padded to align to a 4-octet boundary.
```
 
That is, considering you've disclaimed defining specifics about the semantics
of the header, how is the recipient of one of these things supposed to know how
to ignore the zero-padding?




I do see that all the objects you've defined in this document are a multiple of
four bytes long (if we assume their unspecified headers are a multiple of four
byte long, that is!) so no padding would ever be required for a payload
consisting only of these objects, and thus my question wouldn't apply. But if
that's the answer to my question, then the final clause I quote above (about
zero-padding) should just be removed.

[XM]>>> Will remove the final clause you quoted above (about zero-padding).


### Section 3.2, object format, padding
 
```
   Similar to the container, each object has an object header that is
   used to identify the type and length of the object payload, and the
   object payload is zero-padded to align to a 4-octet boundary.
```
 
Similar to the above, in some cases there will be a need to know how to
separate payload from padding. In all the objects you defined in Sections 3.2.x
this is unnecessary (*if* you assume the unspecified header is 4-octet aligned
itself) since you've carefully specified them so that they don't require
padding.
 
It might be more straightforward to just mandate that future object
specifications have a length that is a multiple of four octets, as all of your
current ones do. That defers the question of what to do about variable payloads
to the specification of the -- notional? -- object that has such a payload.

[XM]>>> Will remove the final clause you quoted above (about zero-padding). Do you see a need for some new text?


### Section 4
 
You talk about TTL in the first paragraph. Do you mean "TTL or Hop Limit"?

[XM]>>> You're right. Eric Vyncke has made the similar comment. Propose to change the TTL definition in the abbreviations section as below.


OLD

TTL: Time to Live
NEW

TTL: Time to Live, this is also the Hop Limit field in the IPv6 header.


### Section 6, integrity protection
 
You talk about integrity protection in passing. Let's assume a deployment
hasn't enabled any kind of integrity protection. Have you done any analysis of
what kind of mischief an attacker could cause by inserting incorrect
capabilities in a forged response?

[XM]>>> Before I read your question, no :-) I think one possible mischief is that the IOAM encapsulated data packet could be dropped due to its size exceeds the path MTU, another one is that the added IOAM header could not be processed by the nodes along the path.


### Section 6, MBZ fields
 
You suggest checking the must-be-zero reserved fields and reporting an
exception if they aren't zero. Often, such reserved fields are expected to be
extended in future, and indeed this is what you indicate in this spec too.. I
guess since the packets terminate at the recipient of the reply, it's not
terribly harmful to police that these be zero, but it would likely create an
awfully noisy set of exceptions in the case of a partially rolled-out
extension. Is this really a good recommendation? The more usual practice is of
the form "must be zero on Tx, must be ignored on Rx".

[XM]>>> Make sense. Will remove "whether all the reserved fields are set to zero" from the penultimate paragraph of the security section, and add "and MUST be ignored when non-zero" as suggested by Paul Wouters and you.





## Notes
 
This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.
 
[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments