[ippm] Robert Wilton's No Objection on draft-ietf-ippm-otwamp-on-lag-07: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-ippm-otwamp-on-lag-07: 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-otwamp-on-lag/



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

Hi,

The same comment that applies to the stamp document equally applies here
(repeated below):

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