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

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 28 Apr 2016 14:39:09 +0000

Hi Dave,

Does below format is flexible enough for your requirement (rfc7455, rfc 7456).

FirstTLVOffset make it easy for hardware to start TLV parsing. OpCode allows granular functionality other than ping/traceroute).

Flags are not used except 1 bit so that can be overloaded to make common.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | xxx | Version | OpCode        |  Flags        |FirstTLVOffset |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .   OpCode-Specific Information                                 .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    .         TLVs                                                  .
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Thanks,

Deepak

From: Rtg-ooam-dt <[email-masked]<mailto:[email-masked]>> on behalf of Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 28, 2016 at 7:28 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rtg-ooam-dt] SFC/NSH OAM for connectivity

Greg,
There are certainly many common elements, but the BIER proposal contains some BIER-isms.

    Message Type

      This document defines the following Message Types:

                   Type      Value Field
                   --------  ---------------
                     1      BIER Echo Request
                     2      BIER Echo Reply

and
    Reply mode

      The Reply mode is set to one of the below:

                   Value      Meaning
                   --------  ---------------
                     1        Do not Reply
                     2        Reply via IPv4/IPv6 UDP packet.
                     3        Reply via BIER packet

and some return codes are BIER-specific:
   The Return Code can be one of the following:

           Value      Value Meaning
           --------  ---------------
            0      No return code
            1      Malformed Echo Request received
            2      One or more of the TLVs was not understood
            3      Replying BFR is the only BFER in header Bitstring
            4      Replying BFR is one of the BFER in header Bitstring
            5      Packet-Forward-Success
            6      Invalid Multipath Info Request
            8      No matching entry in forwarding table.
            9      Set-Identifier Mismatch

and the TLVs seem generally BIER-specific.

Also (which would be a general complaint against the draft) is that the IEEE precision time format appears to be a closed standard requiring one to purchase the document.
http://standards.ieee.org/findstds/standard/1588-2008.html
- I see no reason to support anything other than the NTP time option.
- in general there are too many options, versions and protocol fields, IMHO. Contrast with ICMP.

Also, it would seem to be useful for the OAM message format to have a length field to know where the TLVs end.

My conclusion is that we could share a base protocol only if the draft-kumarzheng-bier-ping authors are willing to make some changes and refactor the document.
I would say two documents:
 1- a base OAM format (with some changes), with some generic TLVs.
2- a BIER-ping extension to the base format.

-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.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 28 Apr 2016 15:03:34 +0000

Deepak,
I'm unclear on how the first 3 bits (xxx or MD-L) are to be used, but also from the SFC perspective there is a problem with this format not having a total length field.

Because the NSH header doesn't have a total length field, it isn't possible for the parser to know when to stop parsing TLVs.

Using the envelop below, the minimum size NSH OAM packet is 12 bytes. (8 for NSH, 4 for OAM when FirstTLVOffset=4)
So when carried in Ethernet that is padded to 64 bytes, there are 34 bytes of padding (64 - 14 - 4 - 12) after the OAM.

Certainly the parser cannot be expected to wander into undefined octets and try to make sense of it...

Maybe I've missed something?

-Dave

From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 10:39 AM
To: Dave Dolson; Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]
Subject: Re: [Rtg-ooam-dt] SFC/NSH OAM for connectivity

Hi Dave,

    |                                                               |

    |                                                               |

    |                                                               |

    .         TLVs                                                  .

    |                                                               |

Thanks,

Deepak

Greg,

    Message Type

                   Type      Value Field
                   --------  ---------------
                     1      BIER Echo Request
                     2      BIER Echo Reply

and
    Reply mode

                   Value      Meaning
                   --------  ---------------
                     1        Do not Reply

           Value      Value Meaning
           --------  ---------------
            0      No return code

-Dave

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

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

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).

   The fields are:

      OAM Sub-type:

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:

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

Thanks,
-Dave

Hi, DT,

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,

Dave,

Thanks!

- Carlos.

---

From: "Deepak Kumar (dekumar)" <[email-masked]>
Date: Thu, 28 Apr 2016 15:06:47 +0000

Hi Dave,

There’s End of TLV is defined to stop parsing the TLV.

Thanks,
Deepak

From: Dave Dolson <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 28, 2016 at 8:03 AM
To: dekumar <[email-masked]<mailto:[email-masked]>>, Gregory Mirsky <[email-masked]<mailto:[email-masked]>>, "Carlos Pignataro (cpignata)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rtg-ooam-dt] SFC/NSH OAM for connectivity

Deepak,
I’m unclear on how the first 3 bits (xxx or MD-L) are to be used, but also from the SFC perspective there is a problem with this format not having a total length field.

Because the NSH header doesn’t have a total length field, it isn’t possible for the parser to know when to stop parsing TLVs.

Certainly the parser cannot be expected to wander into undefined octets and try to make sense of it…

Maybe I’ve missed something?

-Dave

From: Deepak Kumar (dekumar) [mailto:[email-masked]]
Sent: Thursday, April 28, 2016 10:39 AM
To: Dave Dolson; Gregory Mirsky; Carlos Pignataro (cpignata); [email-masked]<mailto:[email-masked]>
Subject: Re: [Rtg-ooam-dt] SFC/NSH OAM for connectivity

Hi Dave,

    |                                                               |

    |                                                               |

    |                                                               |

    .         TLVs                                                  .

    |                                                               |

Thanks,

Deepak

Greg,

    Message Type

                   Type      Value Field
                   --------  ---------------
                     1      BIER Echo Request
                     2      BIER Echo Reply

and
    Reply mode

                   Value      Meaning
                   --------  ---------------
                     1        Do not Reply

           Value      Value Meaning
           --------  ---------------
            0      No return code

-Dave

Hi Dave,

                Regards,
                                Greg

Thanks Carlos,

   The fields are:

      OAM Sub-type:

Questions:

Thanks,
-Dave

Hi, DT,

Greg,

Dave,

Thanks!

— Carlos.