Re: [bmwg] Review for draft-vfv-bmwg-srmpls-bench-meth

[Giuseppe Fioccola <[e-mail]>]

Dear Boris,
Thanks a lot for your review.
Please find my replies inline tagged as [GF].

Regards,

Giuseppe


From: bmwg <[e-mail]> On Behalf Of Boris Khasanov
Sent: Wednesday, October 19, 2022 4:34 PM
To: [e-mail]
Subject: [bmwg] Review for draft-vfv-bmwg-srmpls-bench-meth

Hi all,
Sorry for delay with the review which I promised at IETF-114 too. But better late than never.

I think that it is a right approach to mention that this draft is a complement to the RFC 5695 which have detailed methodology. More comments are below.

1) Item "2. SR-MPLS forwarding" has the following statement:

"SR policy may be installed by PCEP [RFC8664], BGP [I-D.ietf-idr-segment-routing-te-policy], or via manual configuration on the router.  PCEP signaling can be the case of a controller-based deployment.  For all these reasons, SR Policies scale better than traditional TE mechanisms."

I would like to propose a slightly different version: "SR policy may be installed by PCEP [RFC8664], BGP [I-D.ietf-idr-segment-routing-te-policy], or via manual configuration on the router. PCEP  and BGP signaling  of SR Policies can be the case of a controller-based deployment. "

[GF]: Agree with this change. We will apply it to the next revision.

Obviously controller can communicate with a router for sending  SR Policy via both ways: PCEP and BGP SR Policy SAFI. Also  I think that a scalability topic for TE requires some more arguments for comparison and should be skipped  since this is out of scope of the draft. Also t SR Policy benchmarking methodology does require a separate draft, IMO.

[GF]: Yes, it is not necessary to mention TE scalability.

2) item 3.2
"It is RECOMMENDED that at least one routing protocol (OSPF or ISIS or BGP) should be used for the construction of the simplest stack of 1 SID."
I understand that this was made similarly to the corresponding statement of RFC 5695. But  in current environment I would change RECOMMENDED to SHOULD. I seriously doubt that anyone nowadays/future will test SR performance without IGP.
3)  3.3.  Frame Formats and Sizes
"RECOMMENDED frame sizes are the following:

   *  Ethernet Minimal: 64+n*4..."
I would add "where n =  #labels (SID Depth)"

[GF]: It makes sense to replace RECOMMENDED with SHOULD. It is also better to clarify that n =  number of labels (SID Depth)

4) 3.5.  Trial Duration
Wouldn't be better just use some static number for trial duration here?  RFC 5695 in the section 4.1.7 says: "

the test portion of each trial SHOULD be... no less than 200 seconds when a dynamic routing protocol..."
Why can't we say similarly like " Duration of each test trial SHOULD be not less than 250 seconds..."?

[GF]: I agree that it can be suggested the use of a static number for trial duration and 250 seconds is a reasonable value based on default timers. But we would also specify that a test may also adapt to the real setup and select a different value if default configuration has been changed.



5)

5.1.1.  Throughput for SR-MPLS PUSH,

5.1.2.  Throughput for SR-MPLS NEXT,

5.1.3.  Throughput for SR-MPLS CONTINUE
etc.
I would add some more details for each test, like : " As in Section 6 of RFC 5695  the traffic is

 sent from test tool Tx  port(s) to the DUT at a constant load for a fixed-time interval, and is received from the DUT on test tool Rx port(s).

If any frame loss is detected, then a new iteration is needed where the offered load is decreased and the sender will transmit

again.  An iterative search algorithm MUST be used to determine the maximum offered frame rate with a zero frame loss (No-Drop Rate - NDR).

Each iteration should involve varying the offered load of the traffic, while keeping the other parameters (test duration, number

of ports, number of addresses, frame size, etc.) constant, until the maximum rate at which none of the offered frames are dropped

is determined."
To make very short description of methodology, because currently it requires from the reader to go and read whole RFC 5695 and jump back and forth.

[GF]: Yes, we can add a short description of the methodology for each test similarly to RFC 5695.

6) Item 5.6 Reset
I doubt that referal to the same section of RFC 5695 (6.5) is really helpful here, because RFC 5695 does not have enough details for reset operations. Instead I think that change RFC 6201 from OPTIONAL to SHOULD is needed. Also we need to explicitly clarify which label operations (PUSH, NEXT, CONT. or all of them ) have to be tested  with Reset.

[GF]: Ok, we will revise this section. We can omit the reference to RFC 5695 and just refer to RFC 6201.

Thank you.

SY,
Boris