Re: [ippm] Robert Wilton's No Objection on draft-ietf-ippm-stamp-on-lag-05: (with COMMENT)

[Tianran Zhou <[e-mail]>]

Hi Robert,

Thanks very much for this thoughtful thinking.
I do not argue, but it's the requirement from China Mobile. And I believe there is some requirement to support RFC 8668.

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

I do not really understand why it relates to this draft. Because, IMHO,  STAMP/TWAMP/OWAMP are all performance measurement tools.
It's not to detect the failure. 
There is RFC7130 BFD on LAG. It's for  failure detection and robustness.

Best,
Tianran

-----Original Message-----
From: Robert Wilton via Datatracker [mailto:[e-mail]] 
Sent: Thursday, November 30, 2023 9:31 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Robert Wilton's No Objection on draft-ietf-ippm-stamp-on-lag-05: (with COMMENT)

Robert Wilton has entered the following ballot position for
draft-ietf-ippm-stamp-on-lag-05: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-on-lag/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

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

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

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

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

Regards,
Rob