Re: [Rtg-ooam-dt] [sfc] Identifying OAM in NSH

[Gregory Mirsky <[e-mail]>]

Hi Dave,
thank you for the clarification. You point to the very important issue that has implication onto applicability of methods that add, prepend or append, OAM-specific information to a data packet. One way to address, I assume, is to introduce Length field that equals number of octets in Next Protocol.

	Regards,
		Greg

-----Original Message-----
From: Dave Dolson [mailto:[e-mail]] 
Sent: Thursday, July 21, 2016 9:58 AM
To: Gregory Mirsky <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: Re: [sfc] Identifying OAM in NSH

Greg,
This answers some of the questions I had after your presentations.

However, regarding appending OAM after the packet, NSH header doesn't have a length field that could indicate where the appended portion begins.
The current Length field is regarding the header size.


-Dave


From: Gregory Mirsky
Sent: Thursday, July 21, 2016 9:01 AM
To: [e-mail]
Cc: [e-mail]
Subject: [sfc] Identifying OAM in NSH


Dear All,
we had very good discussion on OAM this week. We've touched on Active, Passive and Something-in-between OAM. But can NSH indicate which OAM type, if any, associated with a packet? I think that the current version of draft-ietf-sfc-nsh does not allow that and may be ambiguous in some cases. I propose change to interpretation and applicability description of the O(AM) flag and allocation of the new protocol type to be used in the Next Protocol field.

RFC 7799 defines Active OAM as following:
An Active Metric or Method depends on a dedicated measurement packet stream and observations of the stream.
Thus, regardless of encapsulation used by OAM, it is the packet constructed solely for monitoring, measuring network's metric and should not leave given domain. And, I believe, such packets should be identified by the protocol type of their own. OAM which behaves as much as Passive OAM or Something-in-between, e.g. OAM appended to data packet either at the domain's edge or on-the-fly, identified by the protocol type of the data packet carried in NSH.
Below are changes I'd like to propose:
Section 3.2 O-bit:
OLD
   O bit: when set to 0x1 indicates that this packet is an Operations,
   Administration and Maintenance (OAM) message.  The receiving SFF and
   SFs nodes MUST examine the payload and take appropriate action (e.g.
   return status information).  OAM message specifics and handling
   details are outside the scope of this document.
END
NEW
O bit: when set to 0x1 indicates that data packet identified by the Next Protocol type has OAM metadata appended. Definition of the format(s) used by OAM metadata is outside the scope of this document.
END

At the end of Section 3.2:
OLD
   This draft defines the following Next Protocol values:

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6-0xFD: Unassigned
   0xFE-0xFF: Experimental
END
NEW
   This draft defines the following Next Protocol values:

   0x1 : IPv4
   0x2 : IPv6
   0x3 : Ethernet
   0x4: NSH
   0x5: MPLS
   0x6: Active OAM
   0x7-0xFD: Unassigned
   0xFE-0xFF: Experimental
END

And, consequently, section 13.2.5 in IANA Considerations section will request allocation of value 0x6 to be assigned to Active OAM protocols.

Greatly appreciate your consideration and comments.

                Regards,
                                Greg