Subject: [OPSAWG] Comments on draft-brockners-inband-oam-* documents

From: Nobo Akiya <[email-masked]>
Date: Tue, 27 Dec 2016 13:45:28 +0900

Hi Authors,

I'm happy to see interesting work in the OAM area :)

Comments on draft-brockners-inband-oam-requirements-02:

>    o  Low-power Networks: Include application level OAM information

>      (e.g., battery charge level, cache or buffer fill level) into data

>      traffic to avoid sending extra OAM traffic which incur an extra

>      cost on the devices.  Using the battery charge level as example,

>      one could avoid sending extra OAM packets just to communicate

>      battery health, and as such would save battery on sensors.

Are you placing above use case in this document because you the protocol is
capable of doing this, or do you consider it to be a hard requirement for
in-band OAM?

Comments on draft-brockners-inband-oam-data-02:

> queue depth:  4-octet unsigned integer field.  This field indicates

>      the length of the egress interface queue of the interface where

>      the packet is forwarded out of.

Many interfaces can have multiple queues (e.g., multiple unicast queues and
multiple multicast queues). Won't be need an queue ID to indicate which
"queue" above is refering to?

>      node_id:  3-octet unsigned integer.  Node identifier field to

>         uniquely identify a node within in-situ OAM domain.  The

>         procedure to allocate, manage and map the node_ids is beyond

>         the scope of this document.

...

>       node_id:  7-octet unsigned integer.  Node identifier field to

>         uniquely identify a node within in-situ OAM domain.  The

>         procedure to allocate, manage and map the node_ids is beyond

>         the scope of this document.

Why is node_id defined as different size?

Same with if_id (4 bytes vs. 8 bytes).

>    Maximum Length:  8-bit unsigned integer.  This field specifies the

>      maximum length of the node data list in octets.  Given that the

>      sender knows the minimum path MTU, the sender can set the maximum

>      of node data bytes allowed before exceeding the MTU.  Thus, a

>      simple comparison between "Opt data Len" and "Max Length" allows

>      to decide whether or not data could be added.

How does the sender know this? PMTUD is a discovery of MTU on a path (i.e.,
point-to-point) and not the entire network domain. Meaning PMTUD is not
completely accurate, as a path a packet can take can change at anytime.
Does a centralized controller/orchestrator educate every sender?

>    OAM-trace-type:  16-bit identifier of a particular trace element

>      variant.

Offset will depend on which bits are set. Typically it is much easier to
implement if one option type having fixed data at fixed locations. I'm sure
"smart programmable chip" can handle this, but I feel that we are trying to
be too flexible here. Thoughts?

General comments:

- When a packet traverses a LAG, it would be good to clarify the expected
if_id to be used.

- When a packet traverses a virtualized environment, it would be good to
clarify the expected behavior of each physical/virtual node.- I feel that
much of "error" cases are lacking in the document. It would be good to
clarify how each node need to behave when there are errors. For example, if
a node receives an In Situ OAM packet with "overflow" bit already set but
can still add more data, do you expect this node to also skip or do you
expect this node add the data and clear the "overflow" bit?

Regards,

Nobo