Subject: Re: [Rtg-ooam-dt] SFC/NSH OAM for connectivity

From: Gregory Mirsky <[email-masked]>
Date: Mon, 2 May 2016 22:32:58 +0000

Hi Dave, et. al,
I've tried to match your list of requirements to the draft-ooamdt-rtgwg-ooam-requirement-00. Please find my notes in-lined and tagged GIM>>.
Looking forward to more live discussion in the call tomorrow.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 1:24 PM
To: Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]
Subject: RE: SFC/NSH OAM for connectivity

Let me try to summarize requirements:
I'm looking for active, pro-active, bidirectional monitoring between a load-balancer and service functions with an echo-request mechanism.
GIM>> REQ#2 should be interpreted as any node that is part of the Overlay network must be able to participate in the Overlay OAM, both as sender and receiver/responder. Then REQ#4 covers the on-demand and pro-active modes. And REQ#7 - bi-directional active OAM.
I wish to perform this check multiple times per second to have an "immediate" automatic recovery.
GIM>> We don't have specific requirement towards intervals that must be supported but given that for pro-active continuity check mechanism we propose BFD, that should not be a problem.
The packet must use both directions of the data plane.
GIM>> Are we talking about SFC data plane of underlay? We have REQ#6 that requires fate-sharing/in-band with data without differentiating whether overlay is unidirectional or bi-directional.
It should be possible to pipeline the messages, with multiple requests in flight at once.
GIM>> As I think of it, all OAM protocols have interval parameter associated with transmission of test packets.
The service functions are "adjacent" to the load-balancer in the overlay network.
GIM>> I interpret that as fate-sharing/in-band with data flow, i.e. REQ#6. Would you agree?
It must be possible to check that the nodes can speak to each other at the NSH protocol layer.
GIM>> Wouldn't that require specific NSH OAM then? I look at SFC OAM as SFP OAM. NSH, in my view, would be Service OAM.
I wish to be able to assert an MTU is configured properly by sending a large packet.
GIM>> Yes, we need to discuss and likely add as the new requirement.
I wish to be able to measure round-trip time at the initiator.
GIM>> REQ#18 Overlay OAM MUST support active two-way packet delay measurement.
The NSH packet needs to work directly on top of Ethernet.
GIM>> That may be not directly related to OAM but to defining NSH Encapsulation.

There will be other requirements for SFC, but these define my immediate need.
I don't think there is anything difficult about defining such a protocol, just standardization.

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 1:22 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: SFC/NSH OAM for connectivity

Hi Dave,
if you can share these requirements before the meeting on Tuesday, then we can discuss how they relate to the Overlay OAM Requirements<https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-00> draft. That would be very good additional topic for the meeting.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 7:38 AM
To: Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: SFC/NSH OAM for connectivity

Also, to put things in perspective, several OAM requirements have been identified for SFC, but I'm only looking at a single-hop check at this time.
Our proposal does not attempt to check an entire path, for example.
Specifically we are trying to help an SFF (with load-balancer) detect problems with adjacent Service Functions and reachability thereof.

And I should have said that I like the idea of using TLVs vs. variable-length opaque data (which could be done with a TLV), provided the responder must echo back the entire packet (for MTU validation).

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, April 27, 2016 5:56 PM
To: Dave Dolson; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: RE: SFC/NSH OAM for connectivity

Hi Dave,
many thanks for the details on SPI and SI values to be used for SFC OAM. Identification of OAM payload by distinct value in the Protocol field of SFC header ensures that active OAM is in-band, i.e. is fate-sharing, with the data. We've discussed format of active OAM control packets and consider using proposal from BIER Ping and Trace<https://tools.ietf.org/html/draft-kumarzheng-bier-ping-02>, where the first word of an OAM control packet (section 3.1):
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Ver  | Message Type  | Proto |             Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                  Message Type Dependent Data                  ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields of the Ping packet, as proposed in the BIER document, have lots commonality with your proposal:
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Ver  | Echo Req/Rep  | Proto |             Reserved          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   QTF |   RTF |   Reply mode  |  Return Code  | Return Subcode|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sender's Handle                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        Sequence Number                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    TimeStamp Sent                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  TimeStamp Sent                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  TimeStamp Received                           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                TimeStamp Received                             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ~                              TLVs                             ~
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I'm looking forward to discuss scope of SFC OAM, i.e. what is SFP monitoring; OAM requirements (what we need SFC Ping for), and formats.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Wednesday, April 27, 2016 7:40 AM
To: Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>; Gregory Mirsky
Subject: RE: SFC/NSH OAM for connectivity

Thanks Carlos,
I'll give a brief description here. I can clarify if necessary.
I welcome feedback before the meeting too.

Our immediate requirement is for an SFF to health-check connected SFs at the NSH protocol layer.
(We don't find the IP-layer ping to be sufficient.)
But for standardization, we came up with something more generic, which is a next-hop echo request.
The idea is that it could be used between any "adjacent" NSH-capable elements. (SFF-to-SF, SFF-to-SFF, CF-to-SFF).

Please note this is NOT a path check; hence the SPI and SI are to be ignored. We suggest setting 0xffffff and 0xff respectively to make this clear.
(We would like this to work even if the SFF tables are empty.)

Proposal for generic OAM Connectivity Protocol (128?), which would be for adjacent NSH elements:
(Showing with MD-type 2; use MD-type 1 if you wish.)

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|C|R|R|R|R|R|R|  Length=2 |  MD-type=0x2  | OAM Proto=128 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path ID=0xffffff             | SI=0xff       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OAM Sub-type                  |  OAM Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sub-type-specific data...
   ~

And for our Echo requirement, using sub-types 0 and 1:

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Ver|O|C|R|R|R|R|R|R|  Length=2 |  MD-type=0x2  | OAM Proto=128 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Service Path ID=0xffffff             | SI=0xff       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OAM Sub-type                  |  OAM Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Query Identifier                                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Sequence Number                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Request timestamp seconds                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Request timestamp microseconds                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~      Variable Length Opaque Data  (optional)                  ~
   |      (Total Octets - 20) octets                               |
   |                                                   +-----------+
   |                                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The fields are:

      OAM Protocol: a value of 128 indicates the NSH header is followed
      by an OAM connectivity message.

      Service Path ID: Should be set by sender to 0xffffff; receiver
      should ignore it.

      Service Index: Should be set by sender to 255.

      OAM Sub-type:

         A value of 0 indicates echo request

         A value of 1 indicates echo response

      OAM Length: number of octets of the OAM portion of the packet.
      The minimum value for echo request/response is 20, and may be
      larger when Variable Length Opaque Data is present.

      Query Identifier is opaque to the responder; it may be used by the
      initiator to demultiplex responses.

      Sequence Number is opaque to the responder; it may be used by the
      initiator to discriminate responses from the same peer.

      The Request Timestamp Seconds and Microseconds together represent
      the time the initiator sent the packet.  It may be used for the
      initiator to determine round-trip time.  The values are defined as
      seconds and nanoseconds since the Epoch, 1970-01-01 00:00:00 +0000
      (UTC).

      Variable Length Opaque Data: the sender may put any data here.
      Data may be placed here to facilitate MTU verification.

The responder's responsibility is to echo all fields, with the exception of changing the OAM sub-type from 0 to 1.
The responder should return the response on the same transport on which it received the request.

Questions:

1.       Is there anything that already serves this purpose?

2.       If the OAM bit is set, does the NSH "Next protocol" field change to "OAM protocol"?  I.e., is it a different space?

3.       In any case, what Next Protocol value could be used for hop-by-hop? (128?)

4.       Should we create a draft?

Thanks,
-Dave

From: Carlos Pignataro (cpignata) [mailto:[email-masked]]
Sent: Tuesday, April 26, 2016 11:34 PM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>; Gregory Mirsky
Subject: SFC/NSH OAM for connectivity

Hi, DT,

In the context of SFC, Dave Dolson has been discussing a packet format for a connectivity check and OAM. Dave is interested in cross-checking with other potential proposals and related pieces of work, and asked me about it.

I shared with Dave about the OOAM DR and suggested to him it would be useful for him to present and share his ideas in our DT meeting - he would very much like that.

[disclosure - I've not seen the packet formats or proposals]

Greg,

Could Dave present out our next DT meeting?

Dave,

Please do share any early material you have with this DT alias.

Thanks!

- Carlos.