Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG
draft-ietf-ippm-stamp-on-lag-06

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-ippm-stamp-on-lag and RFC 9534, changed IESG state to RFC Published)

[Ballot comment]
- I support Zahed's DISCUSS position.

- Thanks in particular for the clearly explained use case in the introduction of both this and its companion document.

[Ballot comment]
Hi,

  This document extends Simple Two-Way Active Measurement Protocol
  (STAMP) to implement performance measurement on every member link of
  a Link Aggregation Group (LAG).  Knowing the measured metrics of each
  member link of a LAG enables operators to enforce a performance based
  traffic steering policy across the member links.

I have to confess that this whole approach feels somewhat like a layer violation to me.  I perceive that the benefit of LAG is to increase link bandwidth and add some level of redundancy without the higher layers needing to be aware that the LAG interface is composed of separate physical Ethernet interfaces (in the same way, that most protocols don't need to know that a 400G Ethernet interface may be spread over multiple lambdas at the physical layer because that abstraction is hidden to the layers above).  I would argue that at the point that we are starting to steer traffic onto particular LAG members (beyond a local passive load-balancing operation) and to monitor and report the performance characteristics of individual members then perhaps the LAG abstraction is somewhat breaking down, and perhaps a cleaner solution would be to not have the interfaces in a LAG and to rely on something like ECMP instead.

However, I appreciate that my previous comment is not directly actionable by the authors and arguably this ship has already sailed with RFC 8668.  Hence, a potentially more actionable suggestion would be:

Should the document have any text regarding how these measurements should be used when individual LAG members fail, and I presume that the pinned member traffic is hashed to different LAG members instead?  Or to phrase this in an alternative way, are their operational deployment considerations about when and how this technology should be deployed and what other LAG configuration should or should not be used at the same time to result in a sane robust solution.

Regards,
Rob

[Ballot comment]
# GEN AD review of draft-ietf-ippm-stamp-on-lag-05

CC @larseggert

## Comments

### Section 3.2, paragraph 2
```
    The micro STAMP Session-Sender MUST send the micro STAMP-Test packets
    over the member link with which the session is associated.  The
    configuration and management of the mapping between a micro STAMP
    session and the Sender/Reflector member link identifiers are outside
    the scope of this document.
```
This is a pretty critical piece to the process though. At the very
least, I would have expected to see some text requiring at least one
session needing to be established per member link to utilize the LAG
fully. Are there other such considerations?

### Boilerplate

This document uses the RFC2119 keywords "SHALL", "NOT RECOMMENDED", "SHALL
NOT", "SHOULD NOT", "MUST", "RECOMMENDED", "OPTIONAL", "MAY", "SHOULD",
"REQUIRED", and "MUST NOT", but does not contain the recommended RFC8174
boilerplate. (It contains some text with a similar beginning.)

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 2, paragraph 4
```
-    in fact STAMP sessions estabilished on member links of a LAG, test
-                                -
```

#### Section 3, paragraph 1
```
-    Micro-session ID TLV introdued in this section for validation check.
+    Micro-session ID TLV introduced in this section for validation check.
+                                +
```

#### Section 3, paragraph 1
```
-    reveived from the expected member link.  It can also verify whether
-      ^
+    received from the expected member link.  It can also verify whether
+      ^
```

#### Section 6, paragraph 1
```
-    are directly connnected.  As such, it's assumed that a node involved
-                  -
```

### Grammar/style

#### Section 1, paragraph 1
```
rics of each member link of a LAG. Hence the measured performance metrics ca
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

#### Section 3.2, paragraph 6
```
ket, the micro Session-Sender uses the the Sender Micro-session ID to check w
                                  ^^^^^^^
```
Possible typo: you repeated a word.

## 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. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

[Ballot comment]

        This document intends to address

"Do, there is no try" :)  eg you "This documents addresses ....".

        Test packets MAY carry the member link information for validation check, which is RECOMMENDED.

MAY RECOMMENDED is novel invention :) I recommend to use "test packets are RECOMMENDED to carry ..."


Section 3.1: Should it state the two octet fields are in network order?

Operational Considerations: The text does not mention if the testing may occur on a production
link (with non-test data), or whether the link is seperated from the production link to obtain
more accurate measurements? That is, should there be an Operational Considerations section that
talks about how/when to run these tests?

[Ballot comment]
Thank you for writing this - this seems like a very useful document, solving a real issue.

I have have a number of comments and suggestions to try and make the document even better / clearer:

1: "Usually, when forwarding traffic over LAG, the hash-based mechanism is used to load balance the traffic across the LAG member links."
I suggest "when forwarding traffic over LAG, a hash-based mechanism is used" or "hash-based mechanisms are used" -- everyone has their own hash based mechanism...

2: "Link delay of each member link varies because of different transport paths." -- "The link delay might vary between member links because..." -- the majority of LAGs (citation needed!) are single hop Ethernets between switches/routers, and have (for all intents and purposes) identical delay. 

3: "OWAMP [RFC4656] and TWAMP [RFC5357] are two active measurement methods according to the classification given in [RFC7799], which can complement passive and hybrid methods." I found this sentence hard to parse. Perhaps something like "According to the classifications in [RFC7799], OWAMP [RFC4656] and TWAMP [RFC5357] are active measurement methods, and they can complement passive and hybrid methods."

4: "This document intends to address the scenario (e.g., Figure 1) where a LAG (e.g., the LAG includes four member links) directly connects two nodes (A and B)."
This was another tricky (for me) to parse sentence. Perhaps "This document intends to address the scenario directly connects two nodes (A and B). An example of this is in Figure 1, where the LAG consisting of four links connects nodes A and B." would be clearer?

Again, I think that this is a useful document, these are just readability suggestions...

[Ballot discuss]
Thanks for working on this specification.

I would like to discuss one point - it appears that micro link validation is very important in this context, however, the STAMP test packet to carry the validation link information is RECOMMENDED not MUST and this specification does not mention what are the other ways to share those information. What does happen when the recommendation is not fulfilled? the active measurement session fails? I would expect this specification to be more clear on those aspects.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ippm-stamp-on-lag-05

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Marcus Ihlar for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Haoyu Song , the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ippm-stamp-on-lag-05-intdir-telechat-song-2023-11-16/ (minor nits but both Haoyu and myself will appreciate a reply to the review -- it is optional though)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 1

Suggest using "may vary" in `Link delay of each member link varies because of different transport paths`, i.e., in most deployment that I know, the links are strictly on the same physical path.

`we need to explicitly steer the traffic across the LAG member links based on the link delay, loss and so on`, beside the use of "we" (ambiguous in the context as it is not the authors doing the steering) I also wonder whether there are really use cases for specific steering within a LAG group. This I-D has value outside the steering.

While I agree that ECMP use case is similar and *should* have been a formal part of this I-D, is there any added value for the reference to RFC 9256?

## Section 2

Please expand "PM" at first use (legend of Fig 1).

Same for "SSID" (especially as it is overloaded by Wi-Fi), suggest to also add a section in the reference to RFC 8972.

`But from the operational point of view, the former is simpler and is RECOMMENDED.`, AFAIK, the LAG load balancing is also spread by the IP addresses and layer-4 ports, so, how can the traffic be load balanced correctly among the links ? I.e., it is clearly easier for operation but what about the implementation ?

## Section 3.2

In `whether the reflected test packet is correctly transmitted over the expected member link` is it 'transmitted' (== sent) or 'received' ?

# NITS (non-blocking / cosmetic)

## Section 2

s/estabilished/established/

## Section 3

s/introdued/introduced/

I.e., running a spell checker before submitting a revised I-D could be useful ;-)

[Ballot comment]
** Section 2.
  All micro sessions of a LAG share the same Sender IP Address and
  Receiver IP Address of the LAG.  As for the UDP Port, the micro
  sessions may share the same Sender Port and Receiver Port pair, or
  each micro session is configured with a different Sender Port and
  Receiver Port pair.  But from the operational point of view, the
  former is simpler and is RECOMMENDED.

I made the same comment for draft-ietf-ippm-otwamp-on-lag-07.  Is there a reason to provide both options?  Why would one not choose the RECOMMENDED approach?  Could the reason for choosing one configuration over the other be documented?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ippm-stamp-on-lag-05. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there is a single action which we must complete.

In the STAMP TLV Types registry in the Simple Two-way Active Measurement Protocol (STAMP) TLV Types registry group located at:

https://www.iana.org/assignments/stamp-tlv-types/

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Description: Micro-session ID TLV
Reference: [ RFC-to-be ]

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2023-11-01):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ippm-stamp-on-lag@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, martin.h.duke@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Simple Two-Way Active Measurement Protocol Extensions for Performance Measurement on LAG) to Proposed Standard


The IESG has received a request from the IP Performance Measurement WG (ippm)
to consider the following document: - 'Simple Two-Way Active Measurement
Protocol Extensions for Performance
  Measurement on LAG'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-11-01. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document extends Simple Two-Way Active Measurement Protocol
  (STAMP) to implement performance measurement on every member link of
  a Link Aggregation Group (LAG).  Knowing the measured metrics of each
  member link of a LAG enables operators to enforce a performance based
  traffic steering policy across the member links.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-on-lag/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/6115/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a fairly broad agreement among working group members that this
work is good and needed.

Note that this document is strongly related to  draft-ietf-ippm-otwamp-on-lag and
a lot of the discussion related to both documents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The one point of controversy was around the applicability or rather the wording of
this draft. Micro-sessions could be useful in more cases than measuring LAG groups
and to be able to measure LAG groups you need a very specific deployment.  There
were suggestions to remove all mentions of LAG from the document and generalize
the concept.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementations of the sister specification (draft-ietf-ippm-otwamp-on-lag)
have been announced. But non of this specification so far.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document proposes small changes to protocols defined in the IPPM WG.
No need for external reviews has been identified.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

There is a real need for being able to perform active measurements of
individual LAG members for improved traffic steering.

The text is clear and concise except for a few nits outlined below.

The document covers most of what is needed to be considered complete: a clear
introduction, explanation of the concept of Micro Sessions on LAG and the necessary
extensions to STAMP to support micro sessions.  Just like for the sister document
(draft-ietf-ippm-otwamp-on-lag) a somewhat more comprehensive applicability
discussion could be useful.

Since the first iteration of this check the authors have updated the document with an
applicability section. The section describes the setup procedures in a bit more detail.

The technical solution looks technically sound. It introduces new TLVs for identifying
Micro Sessions.

With some small improvements I think the document is ready to be handed off to the
responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues are identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is a small extension to an existing standards track
protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Through email exchange with the authors the shepherd has been made aware
of one IPR that relates to this draft that has not yet been declared. The author
in question indicated that they will promptly submit a formal IPR declaration.

A formal IPR declaration has now been made:
https://datatracker.ietf.org/ipr/6115/
Since the declaration was made after the WGLC had finished the WG was
given a chance to provide new feedback on the document. No concerns
with progressing the document were raised.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None found except for the reference issue described below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

One issue fixed since first version of this writeup.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No RFCs will change status by publishing this document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The section looks good.  A  new STAMP TLV Type is requested from the
STAMP TLV Types registry. It's clearly referenced.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a fairly broad agreement among working group members that this
work is good and needed.

Note that this document is strongly related to  draft-ietf-ippm-otwamp-on-lag and
a lot of the discussion related to both documents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The one point of controversy was around the applicability or rather the wording of
this draft. Micro-sessions could be useful in more cases than measuring LAG groups
and to be able to measure LAG groups you need a very specific deployment.  There
were suggestions to remove all mentions of LAG from the document and generalize
the concept.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementations of the sister specification (draft-ietf-ippm-otwamp-on-lag)
have been announced. But non of this specification so far.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document proposes small changes to protocols defined in the IPPM WG.
No need for external reviews has been identified.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

There is a real need for being able to perform active measurements of
individual LAG members for improved traffic steering.

The text is clear and concise except for a few nits outlined below.

The document covers most of what is needed to be considered complete: a clear
introduction, explanation of the concept of Micro Sessions on LAG and the necessary
extensions to STAMP to support micro sessions.  Just like for the sister document
(draft-ietf-ippm-otwamp-on-lag) a somewhat more comprehensive applicability
discussion could be useful.

Since the first iteration of this check the authors have updated the document with an
applicability section. The section describes the setup procedures in a bit more detail.

The technical solution looks technically sound. It introduces new TLVs for identifying
Micro Sessions.

With some small improvements I think the document is ready to be handed off to the
responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues are identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is a small extension to an existing standards track
protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Through email exchange with the authors the shepherd has been made aware
of one IPR that relates to this draft that has not yet been declared. The author
in question indicated that they will promptly submit a formal IPR declaration.

A formal IPR declaration has now been made:
https://datatracker.ietf.org/ipr/6115/
Since the declaration was made after the WGLC had finished the WG was
given a chance to provide new feedback on the document. No concerns
with progressing the document were raised.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None found except for the reference issue described below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

One issue fixed since first version of this writeup.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No RFCs will change status by publishing this document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The section looks good.  A  new STAMP TLV Type is requested from the
STAMP TLV Types registry. It's clearly referenced.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a fairly broad agreement among working group members that this
work is good and needed.

Note that this document is strongly related to  draft-ietf-ippm-otwamp-on-lag and
a lot of the discussion related to both documents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The one point of controversy was around the applicability or rather the wording of
this draft. Micro-sessions could be useful in more cases than measuring LAG groups
and to be able to measure LAG groups you need a very specific deployment.  There
were suggestions to remove all mentions of LAG from the document and generalize
the concept.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementations of the sister specification (draft-ietf-ippm-otwamp-on-lag)
have been announced. But non of this specification so far.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document proposes small changes to protocols defined in the IPPM WG.
No need for external reviews has been identified.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

There is a real need for being able to perform active measurements of
individual LAG members for improved traffic steering.

The text is clear and concise except for a few nits outlined below.

The document covers most of what is needed to be considered complete: a clear
introduction, explanation of the concept of Micro Sessions on LAG and the necessary
extensions to STAMP to support micro sessions.  Just like for the sister document
(draft-ietf-ippm-otwamp-on-lag) a somewhat more comprehensive applicability
discussion could be useful.

Since the first iteration of this check the authors have updated the document with an
applicability section. The section describes the setup procedures in a bit more detail.

The technical solution looks technically sound. It introduces new TLVs for identifying
Micro Sessions.

With some small improvements I think the document is ready to be handed off to the
responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues are identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is a small extension to an existing standards track
protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Through email exchange with the authors the shepherd has been made aware
of one IPR that relates to this draft that has not yet been declared. The author
in question indicated that they will promptly submit a formal IPR declaration.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None found except for the reference issue described below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

One issue fixed since first version of this writeup.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No RFCs will change status by publishing this document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The section looks good.  A  new STAMP TLV Type is requested from the
STAMP TLV Types registry. It's clearly referenced.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

It represents a fairly broad agreement among working group members that this
work is good and needed.

Note that this document is strongly related to  draft-ietf-ippm-otwamp-on-lag and
a lot of the discussion related to both documents.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

The one point of controversy was around the applicability or rather the wording of
this draft. Micro-sessions could be useful in more cases than measuring LAG groups
and to be able to measure LAG groups you need a very specific deployment.  There
were suggestions to remove all mentions of LAG from the document and generalize
the concept.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

Several implementations of the sister specification (draft-ietf-ippm-otwamp-on-lag)
have been announced. But non of this specification so far.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

This document proposes small changes to protocols defined in the IPPM WG.
No need for external reviews has been identified.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

There is a real need for being able to perform active measurements of
individual LAG members for improved traffic steering.

The text is clear and concise except for a few nits outlined below.

The document covers most of what is needed to be considered complete: a clear
introduction, explanation of the concept of Micro Sessions on LAG and the necessary
extensions to STAMP to support micro sessions.  Just like for the sister document
(draft-ietf-ippm-otwamp-on-lag) a somewhat more comprehensive applicability
discussion could be useful.

The technical solution looks technically sound. It introduces new TLVs for identifying
Micro Sessions.

With some small improvements I think the document is ready to be handed off to the
responsible AD.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

No such issues are identified.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. This is a small extension to an existing standards track
protocol.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

Through email exchange with the authors the shepherd has been made aware
of one IPR that relates to this draft that has not yet been declared. The author
in question indicated that they will promptly submit a formal IPR declaration.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

None found except for the reference issue described below.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

Section 1 has a reference to RFC 7799 that is currently listed as normative. It's
better suited as an informative reference as it provides useful background
information to the interested reader but is in no means necessary for being able
to implement the protocol defined in this document. This is also a downward
reference.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

Yes, the reference to RFC 7799 as described above. The solution, in the view of
the shepherd, is to change the reference type to informative.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

N/A

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

No RFCs will change status by publishing this document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

The section looks good.  A  new STAMP TLV Type is requested from the
STAMP TLV Types registry. It's clearly referenced.


21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/