Benchmarking Methodology for Segment Routing (SR) Forwarding
draft-ietf-bmwg-sr-bench-meth-10

[Ballot comment]
Thanks to the authors and the WG for their work on this important document
that specifies benchmarking methodology for SR forwarding (both SR-MPLS
and SRv6). I fully support this work.

Also, thanks to the authors for the discussions and resultant document updates to address the issues and concerns that were raised in my original ballot.

[Ballot discuss]
Thanks to the authors and the WG for their work on this important document
that specifies benchmarking methodology for SR forwarding (both SR-MPLS
and SRv6). I fully support this work.

Note: This is updated ballot for v09; I've dropped the points that I believe
have been addressed (via text changes or clarifications/responses) and only
the open items are retained.

Both the discussion points and comments are provided inline in the idnits
output of v08. Please look out for the  tag at the very end to
ensure you are seeing the full review.


Benchmarking of ECMP load-balancing that departs from the base and
does not explain the challenges involved

168   The test setup in general is compliant with Section 6 of [RFC2544]
169   but augmented by the methodology specified in Section 4 of [RFC5695]
170   using many interfaces.  It is needed to test the packet forwarding

636   The test could be done to assess more construction methods and
637   consequently report the results as specified in Section 3.  In
638   addition, it could be possible to test the Equal-Cost Multi-Path
639   (ECMP) behavior of an SR Policy.  An SR Policy with one active
640   Candidate Path (CP) but with variable Segments Left (SL), SIDs,
641   weights can be tested to check the overall performance and ECMP
642   limits.  All the related parameters must be reported as specified in
643   Section 3.

911       SIDs as baseline, each SL have the same weight (ECMP testing).  On
912       the second iteration the Segment List length is equal to MSD.  The
913       scope is to verify that traffic flows between CEs and ECMP is
914       working.  The test can be repeated with different weights per each
915       SL, testing weighted ECMP (wECMP).  The result is to find out the
916       maximum supported SLs number and ECMP/wECMP works fine on that
917       maximum SL scale, with no traffic drops.

Section 6 of RFC 5695 states that the usage of ECMP is not permitted by
that document, in order to ensure deterministic forwarding behaviour
during benchmarking, and requires that the test tool not advertise a
prefix or FEC on more than one port. This document requires ECMP and
wECMP testing, and hash-key randomisation to go with it, while declaring
the setup compliant with the base methodology -- and never says it is
reversing that exclusion.

As written, two labs benchmarking the same DUT under this methodology can
legitimately report different numbers and neither report will say why,
which goes to the whole product of a BMWG methodology.

First, please state the departure in Section 2.1, and say what preserves
reproducibility in its place -- the hash key fields (Section 3 already
has "Fields used for ECMP hashing"), the number of flows and the
randomisation method, and the measured per-egress-interface distribution
reported alongside the aggregate rate. For the wECMP steps in Section
4.7, please define the pass criterion quantitatively, as the observed
per-Segment-List share against w/Sw per Section 2.11 of RFC 9256 within
a stated tolerance, rather than "works fine" and "as expected".

Was the departure a considered WG decision, and if so was it discussed
on the list? Why is this SR specific and not applicable for IP in general
and LDP/BGP in case of MPLS? Am I missing some existing benchmarking work
related to ECMP/wECMP?

#Update for v09: This is largely addressed. There is only one remaining
aspect that I would like to discuss further. The statement ECMP/wECMP
"works" is somewhat ambiguous. I guess the objective should be to use
test traffic with sufficient entropy (based on the fields use by the
implementation) to ensure load distribution equally or according to the
relative weights? Can this be clarified?


Issues with mapping of SR forwarding operations onto node roles for
SRv6, incompleteness for SR-MPLS, and it is defined inside one test

650   This section contains a description of the tests that are related to
651   the characterization of a DUT's SR traffic forwarding throughput.

653   The list of segments for SR-MPLS is represented as a stack of MPLS
654   labels.  There are three distinct operations to be tested: PUSH, NEXT
655   and CONTINUE.  These correspond to the three forwarding operations of
656   an MPLS packet: PUSH (or LSP Ingress), POP (or LSP Egress), or SWAP.

658   The list of segments for SRv6 is represented as a list of IPv6
659   addresses, included in the SRH.  Three distinct types of nodes are
660   involved in segment routing networks that may represent four
661   different cases.

663   Note that the different operations are separately discussed only for
664   throughput tests, but they are equally applicable to the other tests
665   below.

Lines 663-665 state the problem outright: a document-wide taxonomy has
been defined inside one of the seven tests that depend on it. It is also
wrong - please see further.

First, the operation mapping. Section 4.1.2:

700 4.1.2.  Throughput of a Transit Segment Endpoint Node

702   Objective: To obtain the DUT's Throughput during the packet
703   processing of a Segment Endpoint Node, which is the CONTINUE
704   forwarding operation.  It is when the SR Segment Endpoint node
705   receives packets whose SID is locally configured as a segment.

Section 2 of RFC 8402 maps NEXT onto SRv6 as the copy of the next
segment from the SRH into the destination address of the IPv6 header,
and CONTINUE onto plain IPv6 forwarding by destination address. The node
described here is therefore performing NEXT, not CONTINUE. The SR-MPLS
half of the same section is fine -- label swap or UHP matches Section
3.1.2 of RFC 8402 -- so the two data planes put different operations at
this role, and the document should say so rather than picking one label
for both.

768 4.1.4.  Throughput of an Ordinary Transit Node

770   Objective: To obtain the DUT's Throughput during the packet
771   processing of a Transit Node.  It is when a Transit node forwards the
772   packet containing the SR header as a normal IPv6 packet because the
773   IPv6 destination address does not locally match with a segment.  This
774   test is possible only for SRv6, SR-MPLS requires all transit nodes to
775   support MPLS.

Sections 4.1.2 and 4.1.3 both describe NEXT in SRv6 terms, so the four SRv6
cases do not map onto three operations as Section 4.1 claims. And the last
sentence above removes SR-MPLS CONTINUE from the document entirely: a node
transiting the active Prefix-SID performs a label swap, and is the common
forwarding case in a deployed SR-MPLS network.

Second, the PSP flavor is excluded where it occurs and offered where it
cannot occur. Section 4.1.2, where the node receives Segments Left
greater than zero:

720       reporting.  SRH SL is assumed to be bigger than zero for this
721       test.  Moreover, it is assumed that DUT would not need to delete
722       headers (no PSP, USD, or USP).  Additionally, the router could be
723       configured for NEXT-C-SID or REPLACE-C-SID compression.

and Section 4.1.3, where it receives Segments Left equal to zero:

751       packet).  The RECOMMENDED endpoint decapsulation behavior is End
752       with the USD flavor, in case of interest for another flavor (PSP,
753       USP) it is OPTIONAL to test it with proper reporting.
754       Additionally, the router could be configured for NEXT-C-SID or

Section 4.16.1.2 of RFC 8986 pins PSP to the penultimate SR Segment
Endpoint Node and states that it does not happen at any transit node.
The node in Section 4.1.3 is the ultimate node and cannot perform PSP,
so a tester instructed to configure it there either cannot, or
configures something that never fires, and either way the reported
result does not mean what the table says. The node in Section 4.1.2 at
Segments Left = 1 is exactly where PSP does occur, and that is the one
place the document rules it out -- so the cost of the flavor, which is
different from plain End or End.X since the node removes an
extension header and rewrites the preceding Next Header and Payload
Length, is unmeasurable under this methodology. Please delete PSP from
the Section 4.1.3 list (USP and USD are correct there) and replace the
blanket exclusion in Section 4.1.2 with an explicit PSP sub-case at
Segments Left = 1, OPTIONAL if the WG prefers.

Third, the node-role terms are SRv6 terms applied to SR-MPLS, where they
have no definition. SR source node, transit node and SR segment endpoint
node are defined in RFC 8754, and all three operate on the IPv6 destination
address. "Transit Segment Endpoint Node" at line 700, applied to SR-MPLS,
is unclear. For SR-MPLS, RFC 8402 does not define a node role, and neither
does RFC 8660. So an SR-MPLS tester reading Section 4.1.2 has no defined
way to identify the node under test.

Also, note that operations when using CSID variants (both of them) are
different and are not specifically being called out in the context of the
PUSH and NEXT operations.

Suggestion: Restructure Section 4 so that a new Section 4.1 describes the
forwarding model alone (no tests): the operation, the node role performing
it per data plane, the RFC 8986 behaviour or MPLS operation involved, and
the corresponding RFC 5695 test. Then name the tests by operation rather
than by node role, as RFC 5695 does. RFC 5695 already solved the naming
problem for MPLS (e.g., using LSP Ingress and LSP Egress). Naming by
operation will catch the mapping errors. This also aligns with RFC 5695.
It allows to leverage that base for SR-MPLS. It also allows to leverage
the base RFC 5180 for the SRv6 CONTINUE which is plain IPv6 forwarding.
I'll leave it to the authors and the WG how best they want to organize
SR-MPLS and SRv6 aspects; they are not same or equal and need careful
consideration.

#Update for v09: Several points have been addressed and I will only
continue the discussion on the ones that are open.

Note: The authors have not taken up my suggestion to editorially
restructure the document and to organize the tests per operation instead
of per role. This seems to be the authors/WG's call, and I won't argue
this point any further but request (for one last time) to reconsider
as that is IMHO the root cause of the pending issues.

a) Could you explain how "Label Pop Aggregate" works for SR-MPLS? I am
missing how this state could be setup for SR-MPLS. Or, did you mean
this operation to pop the outer label and forward what is still a
labelled packet to the next hop indicated by the outer label packet?
I believe RFC 5695 covered MPLS label stack with only one entry and
here with SR-MPLS, we have a label stack with multiple labels that
perhaps needs a different and more accurate terminology?

b) The node "roles" terminology - Source Edge Node, Transit Segment
Endpoint Node, Destination Edge Node, and Ordinary Transit Node - is
newly introduced by this document. It is not defined in RFC 8402.
Somewhat equivalent terms are defined in RFC 8754 but only for SRv6.
I see two options: (i) either define these terms in the document and
map them to their equivalent (SR-)MPLS and SRv6 terms , or (ii) use
the equivalent terms from existing RFCs.

c) Section 5.1.2 is about the NEXT operation. The description is
correct for SRv6 but not for SR-MPLS. For SR-MPLS, this maps to
a Pop operation - refer Section 2 of RFC 8402.

d) Section 5.1.4 is about the CONTINUE operation. The description
is correct for SRv6 but wrong again for SR-MPLS. For SR-MPLS, this
maps to a Swap operation - refer Section 2 of RFC 8402. This is
similar to the Swap operation (same as Section 6.1.2 of RFC 5695).


Isn't it benchmarking for SR Forwarding?

12           Benchmarking Methodology for Segment Routing (SR)
13                     draft-ietf-bmwg-sr-bench-meth-08

17   This document defines a methodology for benchmarking Segment Routing
18   (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR-
19   MPLS).

"Forwarding" appears in neither the title, nor the Abstract, nor the
Introduction's statement of purpose. What the document focusses on is
forwarding-plane performance, that too underlay only, for three of
RFC 8402's operations and for SRv6 the End, End.X and H.Encaps behaviours,
with services excluded, no exception paths, no TTL handling, no protection
and no convergence. That is a perfectly reasonable scope for one document;
it is not the scope the title and Abstract promise. The base document this
one complements is titled "MPLS Forwarding Benchmarking Methodology for
IP Flows", and the precedent is a good one. This allows for future work
of benchmarking for the other SR forwarding constructs and perhaps more.
Right now, it gives an impression as "SR benchmarking is done".

On its own this would be a comment. What makes it a DISCUSS is that the
scope statements inside the document contradict one another, so there is
no authoritative statement of scope anywhere in it. Section 1 puts
End.Dxxx and End.Bxxx in scope at lines 139-141 while Section 2.1 puts
VPN services out of scope at lines 209-215 -- the same thing said two
ways. Section 1 sets a minimum of two SIDs at lines 124-127 while
Section 4.1.1 states both "longer than 1 SID" and "from 1 to N SIDs" in
the same paragraph.

Then, we have in Section 2.2:

286   It is RECOMMENDED that the top SID of the list emulates a traffic
287   engineering scenario.  For example, the top SID can be associated
288   with an emulated next hop of the SR path.  In all cases, the SID
289   stack configuration SHOULD happen before packet forwarding is
290   started.  Control plane convergence speed is not the subject of the
291   present tests.

but then Section 4.7 says:

896       1) Testing of the baseline.  Configure a single SR Policy with
897       just one CP and different Segment Lists with a number of SIDs as
898       baseline (e.g., 3 SIDs); verify that the SR Policy is installed;
899       prepare traffic flow and initiate it; then verify that traffic
900       flows successfully.  The expected result is that there is no
901       packet loss.

"Verify that the SR Policy is installed", "verify that all CPs are
configured but that only one is Active", and the
maximum-supported-SR-Policies result at line 937 measure control-plane
state capacity and conformance to RFC 9256 candidate path selection.
Convergence speed is indeed not measured, so lines 290-291 are not
literally violated, but control-plane capability is being measured, and
that is not forwarding benchmarking on any reading.

Suggestion: put "forwarding" in the title and the Abstract, state the underlay
limit and the exclusions there, update text accordingly, and resolve the
contradictions. Please consider if you really want to measure control plane
or forwarding plane scale, and if that is the case, call that out more
clearly; my suggestion would be to focus on the forwarding.

#Update for v09: Most points have been addressed. The only remaining
discussion point is about the SRv6 End.D* and End.B* behaviors that in the
text. The contradiction between VPNs being out of scope but the discussion
of End.D* remains. There is also the decapsulation in the procedures. I can
see two ways of resolving this: (i) bring basic/simple L3VPN into scope
(say End.DT46?) if only to exercise the decapsulation function and leave
the other End.D* variants for future document (I have no issue with covering
VPNs, if that is the desire)., or (ii) Use the USD variant of End to cover
the decapsulation and then End.D* and VPNs can remain out of scope.

[Ballot comment]
One the comments in the original ballot, thanks for the updates and
addressing most of them (even if done differently). I am clearing them
all as they were non-blocking in any case.

[Ballot discuss]
Thanks to the authors and the WG for their work on this important document
that specifies benchmarking methodology for SR forwarding (both SR-MPLS
and SRv6). I fully support this work.

There are several points that I would like to discuss that are mainly
related to the relationship of this document with the base work in RFC
5180 and RFC 5695 and then about the characterization of certain
SR-related terms and features.

Both the discussion points and comments are provided inline in the idnits
output of v08. Please look out for the  tag at the very end to
ensure you are seeing the full review.


Issues with relationship with the base benchmarking RFCs

152   The purpose of this document is to describe a methodology specific to
153   the benchmarking of Segment Routing.  Such methodology is a
154   complement for [RFC5180] and [RFC5695].

That is the whole of the document's account of its relationship to its
base specifications. There is no section stating what is inherited
unchanged, what is modified, what is not applicable, and what is new
here. The document makes several specific claims against RFC 2544, RFC
5180, RFC 5695 and RFC 9004  - some of these departs from or misstates
the base - there are even quotes that seem to be not accurate. I'll
pick a few examples to illustrate my point:

Section 2.6:

436   Traffic verification is following Section 10 of [RFC2544] and
437   Section 4.1.8 of [RFC5695].  The text is copied here for your
438   convenience.

440   As stated in Section 10 of [RFC2544], "the test equipment SHOULD
441   discard any frames received during a test run that are not actual
442   forwarded test frames.  For example, keep-alive and routing update
443   frames SHOULD NOT be included in the count of received frames.  In
444   all cases, sent traffic MUST be accounted for, whether it was
445   received on the wrong interface, the correct interface, or not
446   received at all.  In all cases, the test equipment SHOULD verify the
447   length of the received frames and check that they match the expected
448   length.

450   Preferably, the test equipment SHOULD include sequence numbers (or
451   signature) in the transmitted frames and check for these numbers on
452   the received frames.  If this is done, the reported results SHOULD
453   include in addition to the number of frames dropped, the number of
454   frames that were received out of order, the number of duplicated
455   frames received and the number of gaps in the received frame
456   numbering sequence".

This is presented as a verbatim quotation of those RFCs but it is not. It
is a paraphrasing and makes normative changes to the base. This is very
misleading. The justification for such changes are not described.

Then some claims about RFC 9004:

486   The test time could be much shorter than recommended in [RFC9004]
487   because typical SR DUT is hardware-based with claimed buffers between
488   30ms to 100ms.  It is better to consult with the vendor to find a
489   good starting search point.  If DUT is software-based then [RFC9004]
490   recommendation for 2-30 seconds is applied.

499   Back-to-back frame test is rather complex and expensive (50 runs for
500   every frame size).  Hence, it is OPTIONAL for SR.

795   Objective: To determine the buffer size as defined in Section 6 of
796   [RFC9004] for each of the SR forwarding operations.

On a quick check Section 6 of RFC 9004 that objective is different as
compared to this document. There are aspects such as buffer size and buffer
time that seem to have been intermixed.

Now, that said, the document does the delta from the base properly in Section 3:

507   Reporting parameter preserved from [RFC5695]:

519   Parameters changed from [RFC5695]:

527   New parameters that MUST be reported are:

Preserved, changed, new, dropped -- applied to the reporting parameters and to
nothing else.

Which of RFC 5695's five forwarding operations does this document intend
to carry forward for SR-MPLS, and what was decided about Pop-Aggregate and
Pop-PHP? Would be good to state what is being kept out of scope or dropped.

Suggestion: Add a "Relationship to [RFC2544], [RFC5180] and [RFC5695]" section
after the Introduction, applying that same treatment to the base documents
section by section, and that any departures be captured. I've tried to identify
more in comments below. Avoid quotes and instead provide section reference (the
preferred option); if quotes are necessary ensure they are verbatim. There is
more from these base documents, especially for SR-MPLS, can be leveraged.

Benchmarking of ECMP load-balancing that departs from the base and
does not explain the challenges involved

168   The test setup in general is compliant with Section 6 of [RFC2544]
169   but augmented by the methodology specified in Section 4 of [RFC5695]
170   using many interfaces.  It is needed to test the packet forwarding

636   The test could be done to assess more construction methods and
637   consequently report the results as specified in Section 3.  In
638   addition, it could be possible to test the Equal-Cost Multi-Path
639   (ECMP) behavior of an SR Policy.  An SR Policy with one active
640   Candidate Path (CP) but with variable Segments Left (SL), SIDs,
641   weights can be tested to check the overall performance and ECMP
642   limits.  All the related parameters must be reported as specified in
643   Section 3.

911       SIDs as baseline, each SL have the same weight (ECMP testing).  On
912       the second iteration the Segment List length is equal to MSD.  The
913       scope is to verify that traffic flows between CEs and ECMP is
914       working.  The test can be repeated with different weights per each
915       SL, testing weighted ECMP (wECMP).  The result is to find out the
916       maximum supported SLs number and ECMP/wECMP works fine on that
917       maximum SL scale, with no traffic drops.

Section 6 of RFC 5695 states that the usage of ECMP is not permitted by
that document, in order to ensure deterministic forwarding behaviour
during benchmarking, and requires that the test tool not advertise a
prefix or FEC on more than one port. This document requires ECMP and
wECMP testing, and hash-key randomisation to go with it, while declaring
the setup compliant with the base methodology -- and never says it is
reversing that exclusion.

As written, two labs benchmarking the same DUT under this methodology can
legitimately report different numbers and neither report will say why,
which goes to the whole product of a BMWG methodology.

First, please state the departure in Section 2.1, and say what preserves
reproducibility in its place -- the hash key fields (Section 3 already
has "Fields used for ECMP hashing"), the number of flows and the
randomisation method, and the measured per-egress-interface distribution
reported alongside the aggregate rate. For the wECMP steps in Section
4.7, please define the pass criterion quantitatively, as the observed
per-Segment-List share against w/Sw per Section 2.11 of RFC 9256 within
a stated tolerance, rather than "works fine" and "as expected".

Was the departure a considered WG decision, and if so was it discussed
on the list? Why is this SR specific and not applicable for IP in general
and LDP/BGP in case of MPLS? Am I missing some existing benchmarking work
related to ECMP/wECMP?

Issues with mapping of SR forwarding operations onto node roles for
SRv6, incompleteness for SR-MPLS, and it is defined inside one test

650   This section contains a description of the tests that are related to
651   the characterization of a DUT's SR traffic forwarding throughput.

653   The list of segments for SR-MPLS is represented as a stack of MPLS
654   labels.  There are three distinct operations to be tested: PUSH, NEXT
655   and CONTINUE.  These correspond to the three forwarding operations of
656   an MPLS packet: PUSH (or LSP Ingress), POP (or LSP Egress), or SWAP.

658   The list of segments for SRv6 is represented as a list of IPv6
659   addresses, included in the SRH.  Three distinct types of nodes are
660   involved in segment routing networks that may represent four
661   different cases.

663   Note that the different operations are separately discussed only for
664   throughput tests, but they are equally applicable to the other tests
665   below.

Lines 663-665 state the problem outright: a document-wide taxonomy has
been defined inside one of the seven tests that depend on it. It is also
wrong - please see further.

First, the operation mapping. Section 4.1.2:

700 4.1.2.  Throughput of a Transit Segment Endpoint Node

702   Objective: To obtain the DUT's Throughput during the packet
703   processing of a Segment Endpoint Node, which is the CONTINUE
704   forwarding operation.  It is when the SR Segment Endpoint node
705   receives packets whose SID is locally configured as a segment.

Section 2 of RFC 8402 maps NEXT onto SRv6 as the copy of the next
segment from the SRH into the destination address of the IPv6 header,
and CONTINUE onto plain IPv6 forwarding by destination address. The node
described here is therefore performing NEXT, not CONTINUE. The SR-MPLS
half of the same section is fine -- label swap or UHP matches Section
3.1.2 of RFC 8402 -- so the two data planes put different operations at
this role, and the document should say so rather than picking one label
for both.

768 4.1.4.  Throughput of an Ordinary Transit Node

770   Objective: To obtain the DUT's Throughput during the packet
771   processing of a Transit Node.  It is when a Transit node forwards the
772   packet containing the SR header as a normal IPv6 packet because the
773   IPv6 destination address does not locally match with a segment.  This
774   test is possible only for SRv6, SR-MPLS requires all transit nodes to
775   support MPLS.

Sections 4.1.2 and 4.1.3 both describe NEXT in SRv6 terms, so the four SRv6
cases do not map onto three operations as Section 4.1 claims. And the last
sentence above removes SR-MPLS CONTINUE from the document entirely: a node
transiting the active Prefix-SID performs a label swap, and is the common
forwarding case in a deployed SR-MPLS network.

Second, the PSP flavor is excluded where it occurs and offered where it
cannot occur. Section 4.1.2, where the node receives Segments Left
greater than zero:

720       reporting.  SRH SL is assumed to be bigger than zero for this
721       test.  Moreover, it is assumed that DUT would not need to delete
722       headers (no PSP, USD, or USP).  Additionally, the router could be
723       configured for NEXT-C-SID or REPLACE-C-SID compression.

and Section 4.1.3, where it receives Segments Left equal to zero:

751       packet).  The RECOMMENDED endpoint decapsulation behavior is End
752       with the USD flavor, in case of interest for another flavor (PSP,
753       USP) it is OPTIONAL to test it with proper reporting.
754       Additionally, the router could be configured for NEXT-C-SID or

Section 4.16.1.2 of RFC 8986 pins PSP to the penultimate SR Segment
Endpoint Node and states that it does not happen at any transit node.
The node in Section 4.1.3 is the ultimate node and cannot perform PSP,
so a tester instructed to configure it there either cannot, or
configures something that never fires, and either way the reported
result does not mean what the table says. The node in Section 4.1.2 at
Segments Left = 1 is exactly where PSP does occur, and that is the one
place the document rules it out -- so the cost of the flavor, which is
different from plain End or End.X since the node removes an
extension header and rewrites the preceding Next Header and Payload
Length, is unmeasurable under this methodology. Please delete PSP from
the Section 4.1.3 list (USP and USD are correct there) and replace the
blanket exclusion in Section 4.1.2 with an explicit PSP sub-case at
Segments Left = 1, OPTIONAL if the WG prefers.

Third, the node-role terms are SRv6 terms applied to SR-MPLS, where they
have no definition. SR source node, transit node and SR segment endpoint
node are defined in RFC 8754, and all three operate on the IPv6 destination
address. "Transit Segment Endpoint Node" at line 700, applied to SR-MPLS,
is unclear. For SR-MPLS, RFC 8402 does not define a node role, and neither
does RFC 8660. So an SR-MPLS tester reading Section 4.1.2 has no defined
way to identify the node under test.

Also, note that operations when using CSID variants (both of them) are
different and are not specifically being called out in the context of the
PUSH and NEXT operations.

Suggestion: Restructure Section 4 so that a new Section 4.1 describes the
forwarding model alone (no tests): the operation, the node role performing
it per data plane, the RFC 8986 behaviour or MPLS operation involved, and
the corresponding RFC 5695 test. Then name the tests by operation rather
than by node role, as RFC 5695 does. RFC 5695 already solved the naming
problem for MPLS (e.g., using LSP Ingress and LSP Egress). Naming by
operation will catch the mapping errors. This also aligns with RFC 5695.
It allows to leverage that base for SR-MPLS. It also allows to leverage
the base RFC 5180 for the SRv6 CONTINUE which is plain IPv6 forwarding.
I'll leave it to the authors and the WG how best they want to organize
SR-MPLS and SRv6 aspects; they are not same or equal and need careful
consideration.

Isn't it benchmarking for SR Forwarding?

12           Benchmarking Methodology for Segment Routing (SR)
13                     draft-ietf-bmwg-sr-bench-meth-08

17   This document defines a methodology for benchmarking Segment Routing
18   (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR-
19   MPLS).

"Forwarding" appears in neither the title, nor the Abstract, nor the
Introduction's statement of purpose. What the document focusses on is
forwarding-plane performance, that too underlay only, for three of
RFC 8402's operations and for SRv6 the End, End.X and H.Encaps behaviours,
with services excluded, no exception paths, no TTL handling, no protection
and no convergence. That is a perfectly reasonable scope for one document;
it is not the scope the title and Abstract promise. The base document this
one complements is titled "MPLS Forwarding Benchmarking Methodology for
IP Flows", and the precedent is a good one. This allows for future work
of benchmarking for the other SR forwarding constructs and perhaps more.
Right now, it gives an impression as "SR benchmarking is done".

On its own this would be a comment. What makes it a DISCUSS is that the
scope statements inside the document contradict one another, so there is
no authoritative statement of scope anywhere in it. Section 1 puts
End.Dxxx and End.Bxxx in scope at lines 139-141 while Section 2.1 puts
VPN services out of scope at lines 209-215 -- the same thing said two
ways. Section 1 sets a minimum of two SIDs at lines 124-127 while
Section 4.1.1 states both "longer than 1 SID" and "from 1 to N SIDs" in
the same paragraph.

Then, we have in Section 2.2:

286   It is RECOMMENDED that the top SID of the list emulates a traffic
287   engineering scenario.  For example, the top SID can be associated
288   with an emulated next hop of the SR path.  In all cases, the SID
289   stack configuration SHOULD happen before packet forwarding is
290   started.  Control plane convergence speed is not the subject of the
291   present tests.

but then Section 4.7 says:

896       1) Testing of the baseline.  Configure a single SR Policy with
897       just one CP and different Segment Lists with a number of SIDs as
898       baseline (e.g., 3 SIDs); verify that the SR Policy is installed;
899       prepare traffic flow and initiate it; then verify that traffic
900       flows successfully.  The expected result is that there is no
901       packet loss.

"Verify that the SR Policy is installed", "verify that all CPs are
configured but that only one is Active", and the
maximum-supported-SR-Policies result at line 937 measure control-plane
state capacity and conformance to RFC 9256 candidate path selection.
Convergence speed is indeed not measured, so lines 290-291 are not
literally violated, but control-plane capability is being measured, and
that is not forwarding benchmarking on any reading.

Suggestion: put "forwarding" in the title and the Abstract, state the underlay
limit and the exclusions there, update text accordingly, and resolve the
contradictions. Please consider if you really want to measure control plane
or forwarding plane scale, and if that is the case, call that out more
clearly; my suggestion would be to focus on the forwarding.

Issue with normative references

1184   [RFC9800]  Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
1185               Clad, Ed., "Compressed SRv6 Segment List Encoding",
1186               RFC 9800, DOI 10.17487/RFC9800, June 2025,
1187               .

RFC 9800 is listed as informative, but should be normative

The same ask covers the flow label references. RFC 6438 is informative
and is relied on normatively, but the other consequential half is that
RFC 6437 -- the specification that actually defines how the flow
label is set -- is not referenced anywhere in the document. Section 2.4
tells the reader to randomise the flow label and never points at the
specification that says how. Please add RFC 6437 as normative, and either
move RFC 6438 to Section 9.1 or drop the citation if text is being rewritten
to simply point to Section 5.5 of RFC 8754.

Issues with oversimplification in the Appendices

The two appendix sections on SR-MPLS and SRv6, while well-meaning, tend to
oversimplify those constructs. These are paraphrasing attempts at entire
RFCs that can be problematic. I prefer that they be removed and the
reader pointed to the relevant specs that they need to comprehend fully
before embarking on any benchmarking exercises. At the very minimum, these
sections need to precede with such a disclaimer to warn the authors.

This issue is not just in the appendix but also occurs in the main body
text where instead of referencing existing RFCs, the document attempts
to explain SR by paraphrasing and thereby introducing inaccuracies.

[Ballot comment]
Please find below some comments. The numbered general items come before
the rest that are inline.

1)  Section 2.5: the trial duration varies from the base RFCs
but there is no explanation why. Am I missing something ?

2)  Section 4.4: the frame loss test method also varies from the
base RFC but no explanation why?

3)  Section 2.2: nothing in the document requires dynamic
protocol state to be established before a trial begins.

4)  Section 2.3: "the payload is RECOMMENDED to have an IP packet
(IPv6 or IPv4 with UDP or TCP)" - why recommend IP and not mandate it?
Why not UDP and why TCP? Am I missing something for these differences
from RFC 5695?

5)  Section 2.7: the "claimed buffers between 30ms to 100ms"
figures are uncited and do not come from RFC 9004. Where is this
hardcoding of numbers coming from?

6)  Please consider adding a Terminology section. There
are several terminologies from benchmarking (e.g., SUT and DUT that are
not the same but treated as such?), and then several related to SR.
There is also the curious case of SL being Segments Left and Segment
List in different sections of this document. Map those terms to their
respective base RFCs.

7)  Data-plane applicability is unmarked in some of
the shared sections but OK in others. In some cases, each objective is
followed by "In the case of SR-MPLS..." and "In the case of SRv6..."
paragraphs; but this is not consistently followed elsewhere. It is not
clear if that implies it applies to both and I believe it does not in
all cases. I leave the way to organize this to the authors.

Note: This is not an editorial review but I could not help notice
several nits that can be caught by appropriate tooling. I've focussed
only on the technical aspects.


The remaining comments are inline in the idnits output:

124   The SID stack in the scope of this document has a minimum of two
125   entries, e.g. two SIDs.  However, it is recommended that the tests
126   described in the next sections can be applied to label stacks with
127   more than two SIDs.  The reason for having a minimum of two SIDs,

Three different minimum SID list lengths are stated in two
places. Here it is two entries; at line 690 it is "longer than 1 SID
(more than 2 are RECOMMENDED)"; and the next sentence there says "The
SID list can be from 1 to N SIDs", which contradicts both of the others
inside the same paragraph. SID list length is the independent variable
this document is built around, and Section 3 requires reporting "Number
of Segments considered in the SID list" without stating its floor.

Perhaps: "Tests in this document use a SID list of at least two SIDs.
Testing with a single SID is OPTIONAL and, where performed, MUST be
reported as such, since it does not exercise SID list processing."

And then ensure there are no contradictions in other sections.

139   This document is limited to underlay, like Headend encapsulations
140   (H.Encaps.xxx), segment Endpoints (End, End.X), Endpoints with
141   decapsulations (End.Dxxx) and Binding (End.Bxxx) for SRv6.

This puts End.Dxxx and End.Bxxx in scope, while VPN services are
out of scope. Then the steering via BSID is not really covered as that
method would require a packet to arrive with the BSID as its "active"
segment while the document seems to be about steering into SR Policy
at the headend. There are different ways to steer into SR Policy as
specified in RFC 9256; at the very least please specify which of the
steering modes are being benchmarked; they work differently.


171   engine that may have different performance levels based on the number
172   of interfaces served.  The Device Under Test (DUT), also referred to
173   as System Under Test (SUT), may have oversubscribed interfaces, then
174   traffic for such interfaces should be proportionally decreased
175   according to the specific DUT oversubscription ratio.  All interfaces
176   served by a particular packet forwarding engine should be loaded in
177   reverse proportion to the claimed oversubscription ratio.  Tests

DUT and SUT are not synonyms - I am referring to RFC 2285. It defines
the DUT as a single stand-alone or modular unit to which stimulus is
offered; Section 3.1.2 defines the SUT as a collective set of devices to
which stimulus is offered as a single entity. The distinction is
important here: an SR benchmark measuring a headend and an egress
together -- which a source edge test with a real decapsulator is -- is
an SUT measurement, and the reporting obligations differ. I am not sure of
the intention; easier option seems to just use DUT and not SUT?

"Proportionally decreased according to the ratio" and "loaded in
reverse proportion to the ratio" seem like two different instructions unless
the first is shorthand for the second. Perhaps:

"Where a forwarding engine serves interfaces whose aggregate line rate
exceeds the engine's forwarding capacity by a factor R (the
oversubscription ratio), each interface SHOULD be offered 1/R of its
line rate, so that the aggregate offered load equals the engine's capacity.
R and the resulting per-interface offered load MUST be reported."

Then delete whichever existing sentence is redundant.

201         Figure 1: Test environment for SRv6 Forwarding Benchmarking

The figure and its surrounding text at lines 168-199 apply to both
data planes, and Figure 4's caption is data-plane-neutral.

s/Test environment for SRv6 Forwarding Benchmarking/Test environment for SR
Forwarding Benchmarking

209   ratio MUST be reported.  This document is benchmarking only "source
210   routing".  Hence, SIDs represent only prefix and adjacency segments,
211   that may be carried in IGP extensions.  For the case of SRv6, SIDs
212   represent only Headend encapsulation (H.Encaps.xxx) or segment
213   Endpoint (End, End.X).  In general, services (Layer 2 or Layer 3
214   VPNs) are typically encoded by the last SID in the stack, but such
215   use is out of the scope of this document.

This is the other half of the contradiction noted at lines
139-141 above.

A SID cannot "represent" H.Encaps. RFC 8986 separates the two
deliberately: Section 4 is SR endpoint behaviours, described as a set of
well-known behaviours that can be associated with a SID, while Section 5
is SR Policy headend behaviours, and Section 5.1's worked example turns
on the target being neither a local address nor a SID of the node --
H.Encaps is invoked by steering into an SR Policy, not by a SID lookup.
Perhaps:

"For SRv6, the DUT is exercised for the headend encapsulation behaviours
(H.Encaps and its variants, Section 5 of [RFC8986]) and for the topological
endpoint behaviours End and End.X (Section 4 of [RFC8986])."

And what about the other flavors from RFC 8986 and the CSID from RFC 9800?

270   A routing protocol (OSPF or IS-IS) SHOULD be used for the
271   construction of the first SRH SID.  Another possibility can the
272   static routing, but it is not a realistic production scenario.  It is
273   RECOMMENDED to test SR policy with a SID depth between two SIDs and
274   the maximum SID depth supported by the particular DUT.

The text before this is the same section offers more options for
SID stack construction, including BGP-based. This paragraph then narrows
to OSPF or IS-IS with a SHOULD and offers only static routing as the
alternative. Either the list is over-broad or this sentence is.
Separately, "the first SRH SID" is strange: where is it defined or coming
from and what does it mean? And this sentence is data-plane-agnostic in a
section covering both. RFC 9256 is an architecture -- and PCEP (RFC 8664) and
BGP SR Policy (RFC 9830) are absent although line 549 requires reporting
"SR Policy construction method (PCEP, BGP, manual configuration)". Please
consider being more explicit or precise about what protocols are used
and for which purposes.

276   The long SID list may be needed for extensive traffic engineering or
277   other scenarios.  The data plane needs to be compliant with the SRv6
278   control plane requirements (Section 4 of [RFC9513], Section 4 of
279   [RFC9352], and Section 2 of [RFC9514]) to disclose the maximum SID
280   list supported for encapsulation, decapsulation, and SRH deletion in
281   transit.  It is not required to test the SID list for operations
282   beyond the announced capabilities of OSPF or ISIS on the DUT.

Section 4 of RFC 9352 and Section 4 of RFC 9513 are the right
citations, but Section 2 of RFC 9514 is "BGP-LS Extensions for SRv6" and
is not about MSD -- that material is in Section 3.2 (SRv6 Node MSD
Types) and Section 4.3 (SRv6 Link MSD Types) of RFC 9514. All three are
SRv6-only, and this document covers SR-MPLS equally while giving no MSD
reference for it: the SR-MPLS MSD advertisements are RFC 8491 for IS-IS,
RFC 8476 for OSPF and RFC 8814 for BGP-LS, which are the same ones
Section 3 of RFC 9256 points to. Also, "The data plane needs to be
compliant with the SRv6 control plane requirements ... to disclose the
maximum SID list supported" inverts the relationship: MSD is a
control-plane advertisement of a data-plane limit, and the operative
requirement for the test is that the DUT advertise its MSDs so the
tester can read them. Perhaps:

"Where the DUT advertises its Maximum SID Depth capabilities, the tester
can read the maximum SID list supported for encapsulation, decapsulation
and SRH deletion in transit: for SRv6 from Section 4 of [RFC9352] (IS-IS),
Section 4 of [RFC9513] (OSPFv3), or Sections 3.2 and 4.3 of [RFC9514]
(BGP-LS); for SR-MPLS from [RFC8491] (IS-IS), [RFC8476] (OSPF), or
[RFC8814] (BGP-LS)."

In general, please look at ways to clearly and unambiguously cover both
the data-plane variants for SR.

299 2.3.  Frame Formats and Sizes

This section fixes every other property of the test frame and has
nothing on TTL/HL, where Section 4.1.6 of RFC 5695 requires
the TTL to be large enough to survive a decrement and still be forwarded
through the DUT. SR-MPLS has three TTL treatments across a label stack
-- uniform, pipe and short-pipe, per RFC 3443 -- determining whether the
TTL is copied into each pushed label, decremented once, or decremented
per hop, so a PUSH test of an n-label stack behaves differently under
each. SRv6 carries two Hop Limits after H.Encaps, since Section 5.1 of
RFC 8986 decrements the inner one at encapsulation and the outer header
gets its own. Please add a subsection here, or a new section immediately
after this one, modelled on Section 4.1.6 of RFC 5695: the Hop Limit or
TTL MUST be large enough that the frame traverses the DUT without expiry
given the number of segments, and for SR-MPLS the TTL propagation model
in use ([RFC3443]) MUST be reported along with the values used. These
both belong in Section 3 as well.


373   Note that n*4 octets should be added in the previous calculations for
374   SR-MPLS tests to accommodate MPLS labels needed for respective tests.
375   While 40+8+n*16 bytes should be added for SRv6 tests, where

377       40 octets are added for the outer (tunnel) IPv6 header,

379       8 octets are added for the SRH header itself, and

381       n is the number of SIDs multiplied by 16 octets SID size, one SID
382       may have a few compressed SIDs.

Have you considered both the normal (H.Encaps) and reduced
(H.Encaps.Red) options? What about CSID?

394   IANA reserved an IPv6 address block 2001:2::/48 [RFC4773] for use
395   with IPv6 benchmark testing (see Section 8 of [RFC5180]) and block
396   198.18.0.0/15 [RFC3330] for IPv4 benchmark testing.

398   Source and destination addresses for the test streams SHOULD belong
399   to the IPv6 range assigned by IANA.  The type of infrastructure
400   protocol (IPv6 vs IPv4) that should be used for IGP and BGP in the
401   tests should be chosen according to the test purpose and
402   requirements.  It is not principal what Locator blocks would be
403   chosen for tests.  It may be /52, /56, /64, or even bigger.  It is
404   possible to test a few different Locator blocks if there is a need.

In SRv6 the destination address is a SID, drawn from the Locator
block. So "destination addresses ... SHOULD belong to the IPv6 range
assigned by IANA" and "It is not principal what Locator blocks would be
chosen" are in direct tension -- the second licenses what the first
forbids. Please revisit this against the SRv6 addressing norms. Is there
a need to use the benchmarking IPv6 prefix? How do CSIDs fit in with that?
There is a dedicated prefix for SRv6 SIDs/Locators ...


406   As it is discussed in Section 3.1, there is a need to load the whole
407   forwarding engine (on all interfaces).

Section 3 ("Reporting Format") has no subsections. Perhaps:
"As discussed in Section 2.1 and Section 4, ..."

409   [RFC4814] discusses the importance of having many flows with address
410   randomization for acceptable hash-based load balancing that is
411   implemented in all forwarding engines.  Note that IPv6 flow label
412   randomization must be used, according to [RFC6438] and [RFC8754].  In

The flow label sentence misstates both references. Neither
requires randomisation: Section 3 of RFC 6438 says the sending TEP
SHOULD set the flow label in accordance with RFC 6437, and RFC 6437 asks
for values chosen from a uniform distribution, which is not the same
thing. Section 5.5 of RFC 8754 is more nuanced than a flat "must" -- the
SR source node MUST impose a flow label for interdomain packets and
SHOULD impose one per RFC 6437 for intradomain packets, while transit
and endpoint nodes MUST use it in the ECMP hash -- and a benchmarking
setup is intradomain, so the applicable rule is the SHOULD. RFC 6437 is
the specification that defines how the flow label is set and is not
cited anywhere in this document (see my DISCUSS). And the lowercase
"must" should be a BCP 14 keyword?


689   Procedure: Similar to Section 6.1 of [RFC5695] or Section 26.1 of
690   [RFC2544] with extension to test SID list longer than 1 SID (more
691   than 2 are RECOMMENDED).  The SID list can be from 1 to N SIDs.  N
692   could be specified a priori or measured as part of the test.  The

This is related to my DISCUSS. Note the contradictions in SID list
length/size throughout the document and resolve.


712       In the case of SRv6, the SR Segment Endpoint node inspects the SR
713       header: it detects the new active segment, i.e. the next segment
714       in the Segment List, or index in the least significant bit for
715       REPLACE-C-SID, modifies the IPv6 destination address of the outer
716       IPv6 header, and forwards the packet based on the IPv6 forwarding
717       table.  The RECOMMENDED endpoint behavior is End.X, in case of

This does not accurately cover both CSID-NEXT and CSID-REPLACE.
I do not understand why this document tries to explain these SR concepts by
attempting to paraphrase things inaccurately instead or simply referencing
the base RFCs.


742       In the case of SR-MPLS, it is equivalent to MPLS Label Pop or
743       Penultimate Hop Popping (PHP), as per Section 6.1.3 of [RFC5695]
744       and Section 26.1 of [RFC2544].

PHP is performed by the penultimate node. If PHP is in use, the
DUT here receives an unlabelled packet and does plain IP forwarding --
there is no pop to measure. The cited Section 6.1.3 of RFC 5695 is
"Throughput for MPLS Label Pop (Unlabeled)", which is the right analogue
for a decapsulating egress; Section 6.1.5 is separately "Throughput for
MPLS Label Pop (PHP)", a different test on a different node. Please
strike "or Penultimate Hop Popping (PHP)". Related: RFC 5695 defines
five forwarding operations in Sections 6.1.1 to 6.1.5, and its Sections
6.2, 6.3 and 6.4 all enumerate all five. This document maps three and
does not say what became of Pop-Aggregate and Pop-PHP. One sentence
saying which are carried forward and why the others are out of scope
would close it -- Pop-Aggregate has no SR analogue, and PHP, if
benchmarked, belongs at the penultimate node and is the PSP fix
in my DISCUSS.

This is a good example where the document may have benefited by following
the base RFC 5695 more closely for SR-MPLS.


891   Objective: To check the scaling capabilities of a DUT as it is an
892   Ingress PE where an SR Policy is configured.

There is no benchmark metric in this section. Every other test
names a benchmark with units; this one says "verify that traffic flows
successfully", "works fine" and "as expected". That is functional
conformance rather than benchmarking, and it does not fit the Objective
/ Procedure / Reporting Format shape it has been given -- "Reporting
Format: A table with all parameters specified in Section 3" reports the
inputs with no output column.

Separately, "Ingress PE", "CEs" and "Egress PEs" appear nowhere else in
the document, and the topology in Figures 1 and 4 is Tester-DUT with no
CEs; please restate the roles as "the DUT acts as the SR Policy headend;
the tester emulates the endpoint(s)". Then there is also the part in my
DISCUSS on the scope related to control plane, convergence, scale, or
forwarding.


912       the second iteration the Segment List length is equal to MSD.  The
913       scope is to verify that traffic flows between CEs and ECMP is
914       working.  The test can be repeated with different weights per each

Same problem as at line 891: "the scope is to verify that
traffic flows between CEs and ECMP is working" is a pass criterion that
cannot be checked and yields no measurement. My DISCUSS on the ECMP
departure asks for a quantitative criterion here.

919       4) Testing CP scale in one SR Policy.  Y CPs are created in one SR
920       Policy where Y=10,15,20,etc. (each per different test run), set
921       higher Discriminator for one of CPs.  Verify that all CPs are
922       configured but that only one is Active (with higher
923       Discriminator).  Use the minimal SL length, then the maximum SL

This is glossing over the tie-breaker in Section 2.9 of RFC 9256
for candidate path selection. I don't know why this complication - I would
have gone primarily on Preference instead of discriminator.

945   In general, the test environment for the benchmarking of networking
946   technologies, such as SR-MPLS and SRv6, should not be considered
947   confidential.  Indeed, a detailed description of the test setup and
948   related execution is crucial to allow to reproduce and repeat the
949   tests by the different stakeholders.

Nothing in Section 5 is an operational consideration
in the usual sense: there is no guidance about operating an SR network,
and this document does not change how one is operated. The content is
reproducibility and reporting guidance, which is Section 3's subject,
and line 968 says as much itself. Note this is the reverse of the usual
placement problem -- advisory material in an advisory section -- so it
is not a case of specification hidden in Operational Considerations. My
preference would be to rename it "Test Reproducibility and
Documentation" and move it after Section 3, since it extends Section 3;
folding the list into Section 3 and deleting Section 5 would
also work. Either way lines 945-966 are general BMWG motivation rather
than SR-specific and could be cut to a sentence.

968   Also, in addition to the parameters specified in Section 3, it is
969   important to record and document in detail the tests for the
970   community and provide all the relevant information, such as:

This sentence, and the seven-item list at lines
972-991, are the part that most clearly belongs with Section 3.

995   Benchmarking methodologies are limited to technology characterization
996   in a laboratory environment, with dedicated address space and
997   constraints.  Special capabilities SHOULD NOT exist in the DUT/SUT
998   specifically for benchmarking purposes.  Any implications for network
999   security arising from the DUT/SUT SHOULD be identical in the lab and
1000   production networks.  The benchmarking network topology is an
1001   independent test setup and MUST NOT be connected to devices that may
1002   forward the test traffic into a production network or misroute
1003   traffic to the test management network.

1005   There are no specific security considerations within the scope of
1006   this document.

The second paragraph flatly contradicts the first; please delete the
second.


1036   [RFC3330]  IANA, "Special-Use IPv4 Addresses", RFC 3330,
1037               DOI 10.17487/RFC3330, October 2002,
1038               .

1040   [RFC4773]  Huston, G., "Administration of the IANA Special Purpose
1041               IPv6 Address Block", RFC 4773, DOI 10.17487/RFC4773,
1042               December 2006, .

Both of these are obsolete

[Ballot comment]
Thank you for the work that has been put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).
I hope that this review helps to improve the document,

Best wishes,

Gorry
(WIT AD)

# Non-blocking COMMENTS

## Abstract
- I understand that benchmarking activities are intended for local tests and not for testing Internet Paths, and that in these cases load control and the effects on other traffic is not in scope. That said, I would strongly recommend the abstract (or end of introduction) includes a line of text that states this, such as something like:
/Benchmarking specifications are for use in isolated test environments only and not for testing Internet paths in deployed networks./
- inspired by RFC 6815.

## Section 2.3 - Various comments:

### /it is likely not implemented for SRv6 services/
- I think IPv6 transit routers do not fragment [RFC8200]?

### I found this sentence difficult to parse:
/The minimal Ethernet payload (46B) could not accommodate the whole IPv6 stack (not enough room for TCP or UDP), hence only IPv4 is possible to use if the test for minimal Ethernet payload is needed./
- I suspect some rewording would make this clearer.

### Please explain this further in the text:
/It is possible to choose a bigger payload size for the IPv6-only environment./

### This RFC2119 requirement (i.e. the MUST) is not clear:
/For the headend nodes, the frame size of the incoming interface(s) does not include SRH, therefore the outgoing interface(s) MUST support the increased frame size due to the creation of the SRH and outer IPv6 attachment./
- I think I understand the idea, so maybe rewording would clarify what is actually required:

### /RECOMMENDED frame sizes are presented below./
- Why there is a recommendation? (please explain in the text).
- I did not see any "size values" clearly stated or explained in the text. (I suspect this frame size is to be taken from the contents of the figures?) - please clarify, and explain in the text.
- Why is the upper limit set to 9000B? I know this is common, but can you explain the reason?
- I see that later text in this section says: “or any claimed maximum” (please clarify the meaning of the claimed maximum and how this relates to these numbers).

## Section 2.4
### Addresses to be used.
/Source and destination addresses for the test streams SHOULD belong to the IPv6 range assigned by IANA./ 
- Why not /SHOULD/MUST/, at least for the RFC this would be very clear. It would also directly under that this RFC-to-be is for benchmarking of equipment, not for Internet path tests.

### I could not understand the word /principal/ in this context:
/It is not principal what Locator blocks would be chosen for tests./
- I suspect the sentence could be rephrased.

### Flow Label randomization
/Note that IPv6 flow label randomization must be used, according to [RFC6438] and [RFC8754]./
- Why is this not a /MUST/?
- What does /used/ mean here? Does it mean that the tester needs to set a randomized flow label? or does it imply more?

## AQM and Scheduling
I considered a DISCUSS on the following text, but it could be this is simply an example and would
need more explanation: /Queuing SHOULD NOT have weighted random early detection (WRED) or any
other mechanism that may start dropping packets before the buffer is filled./
- I would recommend that the text follows something like:
/For benchmarking, paths SHOULD NOT employ Active Queue Management (AQM) including the use of
Random Early Detection (RED), weighted RED or other scheduling methods that would
result in packet drop before the corresponding buffer is filled.
Any queuing or policing policy applied on the tested path MUST be specified in the test results./


## I expect the following are editorial comments, and expect these may improve reading:

NiT: /Other media is possible/Other media are possible/

NiT: /Back-to-back frame test is OPTIONAL./The back-to-back frame test is OPTIONAL./

NiT: /However, SR-MPLS Segment List typically contains more labels./However, the SR-MPLS Segment List typically contains more labels./

Nit: /In the context of this document, it may also be relevant for SIDs,/
Please clarify: /it may/randomization may/.

[Ballot discuss]

# Eric Vyncke INT AD review for draft-ietf-bmwg-sr-bench-meth-08
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

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

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 2.3

Per RFC 8200, IPv6 transit routers cannot fragment, so I wonder about teh `likely` in `it is likely not implemented for SRv6 services` as it is clearly forbidden.

Also, let's be specific and write that SRH with TLV are out of scope as well as SRH-less compressed SRv6.

### Section 2.4

Why not a "MUST" in `Source and destination addresses for the test streams SHOULD belong to the IPv6 range assigned by IANA. ` without additional guidance testers are left alone to decide. See also https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/

Per `Note that IPv6 flow label randomization must be used, according to [RFC6438] and [RFC8754].` RFC 6438 must be normative.

[Ballot comment]

## COMMENTS (non-blocking)

### Obsoleted RFC

As noted by id-nits and other ADs, RFC 4773 and RFC 3330
### Use of BCP14 SHOULD

The BCP14 uppercase terms should be reserved for interoperation, i.e., not really applicable for a benchmark, except perhaps to compare actual benchmark results.

### Section 1

Please be clear and write that `It is recommended to test a big enough SID list to fill at least one compressed SID container (i.e. all 128 bits)` only apply to compressed SRv6.

### Section 2.1

` the SRH header should be present for the test to be relevant for SRv6.` prevents the testing of SRH-less SRv6 compression though. Is there any reason why ?

### Section 2.4

While the document covers both SR-MPLS and SRv6, it often forgets to be specific, i.e., `It is not principal what Locator blocks` probably only apply to SRv6.

### Section 2.5

Thanks for providing guidance for the "SHOULD", but I fail to understand `Otherwise, there is a risk of routing convergence.` ? As an overloaded router will lose its RIB and not gain convergence.

### Section 2.7

In `it is OPTIONAL for SR` does SR mean both SR-MPLS and SRv6 ? Probably worth being clear at the expense of longer sentence.

## NITS (non-blocking / cosmetic)

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

[Ballot comment]
# IESG review of draft-ietf-bmwg-sr-bench-meth-08

CC @MikeBishop

## Comments

### Section 3, paragraph 18
```
    *  Compression method used: None, NEXT-C-SID, REPLACE-C-SID and
        compressed SID size.
```
These aren't defined in this document; they're from RFC9800, as "NEXT-CSID" and
"REPLACE-CSID" (note the hyphenation difference). But RFC9800 is only an
Informative reference in this document and not even mentioned here. Does it need
to be Normative?

### Section 4.5, paragraph 2
```
    (Timestamp B).  The system recovery time is determined by subtracting
    Timestamp B from Timestamp A.  The test MUST be repeated several
```
Which is subtracted from which depends whether you're dealing with
time-since-epoch or time-before-now, and that's implementation-internal. I'd
sidestep the question and say "The system recovery time is the difference
between the two Timestamps."

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

### Grammar/style

#### Section 2.1, paragraph 7
```
oint behavior (H.Encaps, End, End.X, etc), the latter may have a few differen
                                    ^^^
```
In American English, abbreviations like "etc." require a period.

#### Section 4.6, paragraph 1
```
ith composite SR Policy testing as sub-case, if supported). Create Z SR Polic
                                  ^^^^^^^^
```
This word is normally spelled as one.

#### Section 4.6, paragraph 6
```
d execution is crucial to allow to reproduce and repeat the tests by the dif
                                ^^^^^^^^^^^^
```
Did you mean "reproducing"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

#### Section 9.2, paragraph 5
```
each address in the list is a SID. Hence SRv6 Segment list typically contain
                                  ^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Hence".

## 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]
Thank you to Roni Even for the GENART review.

** Section 4.5
  At Timestamp A reduce the frame rate
  to 50% of the above rate and record the time of the last frame lost
  (Timestamp B).  The system recovery time is determined by subtracting
  Timestamp B from Timestamp A. 

Is there a typo in expressing this calculation?  As written:

Recover-time = A – B (i.e., subtracting B from A)

Shouldn’t it read “subtracting A from B”:

Recover-time = B – A

** Section 2.7
  The test time could be much shorter than recommended in [RFC9004]
  because typical SR DUT is hardware-based with claimed buffers between
  30ms to 100ms.  It is better to consult with the vendor to find a
  good starting search point.

I’m assuming that this uncited “30ms – 100ms” is derived from current performance claims for hardware available today.  Will this age well?

** Section 4.7.  Multiple steps in this section refer to ECMP/wECMP:

-- Step 3, “The result is to find out the maximum supported SLs number and ECMP/wECMP works fine …”

-- Step 4, “Verify that traffic flows, with no drops and correct ECMP/wECMP.  The result is that the Active CP is working correctly with any SLs,
ECMP/wECMP works as expected, …”

-- Step 5, “Create Z SR Policies, …  correct ECMP/wECMP”

Where is the correct, baseline behavior of ECMP/wECMP documented?

Thanks for taking care of the LC reviews. I noted that few changes were agreed with some of the reviewers.

Unless I'm mistaken, there was no follow-up to the TSVART review. Please reply to that review as well. Thank you.

The following Last Call announcement was sent out (ends 2026-08-03):

From: The IESG
To: IETF-Announce
CC: bmwg-chairs@ietf.org, bmwg@ietf.org, draft-ietf-bmwg-sr-bench-meth@ietf.org, mohamed.boucadair@orange.com, sbanks@encrypted.net, spring@ietf.org, srv6ops@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Benchmarking Methodology for Segment Routing (SR)) to Informational RFC


The IESG has received a request from the Benchmarking Methodology WG (bmwg)
to consider the following document: - 'Benchmarking Methodology for Segment
Routing (SR)'
  as Informational RFC

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 2026-08-03. 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 defines a methodology for benchmarking Segment Routing
  (SR) performance for Segment Routing over IPv6 (SRv6) and MPLS (SR-
  MPLS).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bmwg-sr-bench-meth/



No IPR declarations have been submitted directly on this I-D.

# 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?

The document reached broad consensus.

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

There were no controversial discussions during the life cycle of the document.

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 one has threatened an appeal or otherwise indicated extreme discontent.

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)?

This is not a protocol document.

## 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 draft was reviewed  by srv6ops, and a liaison sent to ITU. Given the breadth of reviewers and comments received, no additional reviews would be necessary.

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.

This is not applicable for this raft.

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]?

This draft does not contain a YANG model.

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.

These checks do not apply to this draft.

## 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?

Yes.

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?

BMWG doesn’t do this; we don’t typically have lists of issues identified and addressed because they don’t come up that often. This section is NA.

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?

BMWG drafts become Informational RFCs; yes all the necessary bits reflect this.

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.

Yes

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

There are nits contained; 2 errors. I’ll reach out to the authors to address those 2 errors (obsoleted RFCs), and update the template to match the current year.

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

The document is fine as is.

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

NA

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.

None

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?

NA

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, it will not change the status of any existing RFCs.

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

This draft complies.


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.

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

No new IANA requirements contained within the draft.

# 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?

The document reached broad consensus.

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

There were no controversial discussions during the life cycle of the document.

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 one has threatened an appeal or otherwise indicated extreme discontent.

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)?

This is not a protocol document.

## 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 draft was reviewed  by srv6ops, and a liaison sent to ITU. Given the breadth of reviewers and comments received, no additional reviews would be necessary.

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.

This is not applicable for this raft.

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]?

This draft does not contain a YANG model.

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.

These checks do not apply to this draft.

## 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?

Yes.

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?

BMWG doesn’t do this; we don’t typically have lists of issues identified and addressed because they don’t come up that often. This section is NA.

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?

BMWG drafts become Informational RFCs; yes all the necessary bits reflect this.

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.

Yes

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

There are nits contained; 2 errors. I’ll reach out to the authors to address those 2 errors (obsoleted RFCs), and update the template to match the current year.

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

The document is fine as is.

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

NA

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.

None

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?

NA

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, it will not change the status of any existing RFCs.

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

This draft complies.


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.

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

No new IANA requirements contained within the draft.

# 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?

The document reached broad consensus.

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

There were no controversial discussions during the life cycle of the document.

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 one has threatened an appeal or otherwise indicated extreme discontent.

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)?

This is not a protocol document.

## 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 draft was reviewed  by srv6ops, and a liaison sent to ITU. Given the breadth of reviewers and comments received, no additional reviews would be necessary.

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.

This is not applicable for this raft.

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]?

This draft does not contain a YANG model.

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.

These checks do not apply to this draft.

## 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?

Yes.

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?

BMWG doesn’t do this; we don’t typically have lists of issues identified and addressed because they don’t come up that often. This section is NA.

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?

BMWG drafts become Informational RFCs; yes all the necessary bits reflect this.

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.

Yes

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

There are nits contained; 2 errors. I’ll reach out to the authors to address those 2 errors (obsoleted RFCs), and update the template to match the current year.

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

The document is fine as is.

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

NA

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.

None

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?

NA

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, it will not change the status of any existing RFCs.

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

This draft complies.


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.

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

No new IANA requirements contained within the draft.