Re: [bmwg] draft-vfv-bmwg-srv6-bench-meth

[Vasilenko Eduard <[e-mail]>]

Hi Gábor,
Thanks for the review. See in-line.
Eduard
From: bmwg [mailto:[e-mail]] On Behalf Of Gábor LENCSE
Sent: Sunday, March 12, 2023 11:05 PM
To: [e-mail]
Subject: Re: [bmwg] draft-vfv-bmwg-srv6-bench-meth

Dear Authors,
2/27/2023 12:59 PM keltezéssel, Giuseppe Fioccola írta:

Dear All,

We just submitted the new revisions of the benchmarking methodology drafts on SR-MPLS and SRv6. In particular, we addressed the comments received by Bruno Decraene.
I have re-read https://datatracker.ietf.org/doc/draft-vfv-bmwg-srv6-bench-meth
[EV] Thanks!



Your comments and suggestions are welcome.

A have a few minor comments.

In the Introduction:

   devices.  This document aims to extend the efforts of [RFC1242] and

   [RFC2544] to SR network.
As this document is about IPv6 segment routing, I think this section should mention [RFC5180] besides (or instead of) the previous RFCs. (Later I have seen that [RFC5180] is mentioned on the next page.)
[EV] Logical. Thanks.


   This document is limited to Headend encapsulations (H.Encaps.xxx) and

   segment Endpoints (End, End.X).  It is expected that future documents

   may cover the benchmarking of SRv6 applications with decapsulation

   (End.Dxxx), Binding (End.Bxxx), Fast ReRoute

   [I-D.ietf-rtgwg-segment-routing-ti-lfa], etc.
Could you please elaborate the considerations behind the above scope selection?

It seems to me that the decapsulation is the other side of encapsulation, thus they are probably equally important. But I am not familiar with segment routing, so may be I miss some important difference of the two.
[EV] Well, just because it was a tradition in BMWG.
RFC 5695 separates services (no RFC for it) and TE (RFC 6894).
The document would be 2x bigger if services are added.
If TE would be added then 3x.
It is possible to discuss everything in one big document if WG believes that is the right way.

3.2. Locator and Endpoint behaviors methods

   A routing protocol (OSPF or IS-IS) SHOULD be used for the

   construction of the simplest SRH with 1 SID.
I wonder why BGP is not included here, but it is included in "3.5. Trial Duration". (I am sorry, I have no idea, if SR is used only within an AS or also over multiple AS-es.)
[EV] BGP is used for transport topologies only in a few very corner cases.
BGP is signaling primarily for services.

3.4. Protocol Addresses

   IANA reserved an IPv6 address block 2001:0200::/48 for use with IPv6

   benchmark testing (see section 8 of [RFC5180]).
This is a typo in RFC 5180, please see the Errata. The correct text is:

   IANA reserved an IPv6 address block 2001:0002::/48 for use with IPv6

   benchmark testing (see section 8 of [RFC5180]).

[EV] Thanks!

3.7. Buffer tests

   Back-to-back test
I recommend to rephrase (in all cases):

   Back-to-back frame test

[EV] OK.

4. Reporting Format

   *  Port media type may be reported only one time for all tests if

      only Ethernet media would be tested
I recommend:

   *  Port media type may be reported only one time for all tests if

      only Ethernet media is tested.

[EV] OK

All-in-all, I think that the document is in a good shape.

What about a WG adoption call?
[EV] Bingo! We suggest the same.


Best regards,

Gábor Lencse