Subject: Re: [Rtg-ooam-dt] Split solution draft

From: Dave Dolson <[email-masked]>
Date: Mon, 4 Jul 2016 16:24:12 +0000

Regarding ooam-rtgwg-ooam-header-00.txt,

In section2, OOAM header is defined as
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V | Msg Type  |     Flags     |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                  OOAM Control Packet                          ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

But I don't think the OAM control packet is intended to be part of the OOAM header, is it?

Later, it is written "The OOAM header may be followed by the Timestamp control block Figure 2 and then by OOAM Control Packet identified by the Msg Type  field."
Saying this is after the OOAM header but before the OOAM control packet contradicts the definition of the header above including OOAM control packet.

If I understand the intent correctly, the header should be presented as only this part:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V | Msg Type  |     Flags     |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or the entire message could be presented as:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V | Msg Type  |     Flags     |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Optional timestamps                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ OOAM Control packet                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Also, which flag exactly indicates the timestamps are present?

I also have questions about the timestamp portion of the packet.
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  QTF  |  RTF  |                   Reserved                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp 1                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                                                               ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp 4                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I really don't understand  this. Which of the timestamps is the querier, which is the responder? And why are there 4 ?  What is the format of the 64 bits? Is it 4 bytes of seconds since epoch followed by 4 bytes of nanoseconds?

Proposal:
Timestamp format:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       seconds since epoch                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Nanoseconds fraction of second                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Or perhaps refer to NTP format.

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, July 01, 2016 12:11 AM
To: Dave Dolson; Fioccola Giuseppe; Erik Nordmark; [email-masked]; 'Alia Atlas'
Cc: Tal Mizrahi
Subject: Split solution draft

Dear All,

as we've discussed in the last meeting, I've split the solutions text into two:

*         introduce Overlay OAM Header and set Overlay OAM Protocol Type registry;

*         introduce Overlay Ping control packet.

I think that the second document may have one or two use cases with required TLVs introduced (yes, will have new sub-registry).

Both documents need Abstract. Welcome your suggestions, comments.

                Regards,

                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Mon, 4 Jul 2016 16:54:50 +0000

Regarding draft-ooamdt-rtgwg-demand-cc-cv document,

Clearly it needs to be fleshed out more, but regarding the intent of it,

-          Is Figure 1 supposed to be generic or just for ping (per the caption)?

-          Would the message type ever modify the packet syntax, or can only Version indicate a different syntax?

-          Are the Reply modules supposed to be the in-band and out-of-band concepts?

To be fleshed out:

-          Actual values for Version

-          Actual value of Message Type for ping

-          Values for reply modes

-          TLVs should be padded to 4-byte alignment? (It is often done in IETF standards)

To what extent will these have to be clarified in OOAM-for-SFC, OOAM-for-BIER, etc.?

-Dave

Dear All,

                Regards,

                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 5 Jul 2016 01:55:10 +0000

Hi Dave,
great questions, thank you. Please find my notes in-line and tagged GIM>>. We should discuss your questions tomorrow.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, July 04, 2016 9:55 AM
To: Gregory Mirsky; Fioccola Giuseppe; Erik Nordmark; [email-masked]; 'Alia Atlas'
Cc: Tal Mizrahi
Subject: RE: Split solution draft

-          Is Figure 1 supposed to be generic or just for ping (per the caption)?
GIM>> I think only for ping/traceroute. Though I think that referring to them as Echo Request/Echo Reply is more generic and technically accurate.

-          Would the message type ever modify the packet syntax, or can only Version indicate a different syntax?
GIM>> I think that this message will have only two types: Request and Reply. Some fields will be ignored if type is Request, and some fields, I think - when type is Reply. It all should be documented in details.

-          Are the Reply modules supposed to be the in-band and out-of-band concepts?
GIM>> I think that Reply may be in-band in the overlay network is bi-directional. But out-of-band probably will be more common, default case.

To be fleshed out:

-          Values for reply modes

-          TLVs should be padded to 4-byte alignment? (It is often done in IETF standards)
GIM>> Very true, Dave. Will need to fill IANA Considerations section.
To what extent will these have to be clarified in OOAM-for-SFC, OOAM-for-BIER, etc.?

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Friday, July 01, 2016 12:11 AM
To: Dave Dolson; Fioccola Giuseppe; Erik Nordmark; [email-masked]<mailto:[email-masked]>; 'Alia Atlas'
Cc: Tal Mizrahi
Subject: Split solution draft

Dear All,

                Regards,

                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Tue, 5 Jul 2016 15:26:14 +0000

Related to Deepak's ideas on the call, the document could clarify different headers per message type.
Currently, the first octet contains version and message type, which might be the only part that is truly common.

So the fixed (non-TLV) portion of the header could  be determined by these two fields.

Specifically, e.g., along these lines:

OAM packets begin with a single octet:
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   | V | Msg Type  |
   +-+-+-+-+-+-+-+-+

if version==0, the fixed header always begins with these fields:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V | Msg Type  |     Flags     |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

MessageType indicates the format of the fixed header.
If Version==0 and MessageType == PING, the format is:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V | Msg Type  |     Flags     |          Length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ Optional timestamps                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~ OOAM Control packet                                           ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then different Message Types can have different fixed headers.
And also, behavior for unknown versions and message types needs to be defined. We could define a flag for whether to drop or forward (or ?) unknown message types.

-Dave

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Monday, July 04, 2016 9:55 PM
To: Dave Dolson; Fioccola Giuseppe; Erik Nordmark; [email-masked]; 'Alia Atlas'
Cc: Tal Mizrahi
Subject: RE: Split solution draft

Hi Dave,

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Monday, July 04, 2016 9:55 AM
To: Gregory Mirsky; Fioccola Giuseppe; Erik Nordmark; [email-masked]<mailto:[email-masked]>; 'Alia Atlas'
Cc: Tal Mizrahi
Subject: RE: Split solution draft

To be fleshed out:

-          Values for reply modes

-Dave

Dear All,

                Regards,

                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 6 Jul 2016 00:15:26 +0000

Hi Dave,
I've thought of the Overlay OAM Header as analogous to G-ACh, defined in RFC 5586 whose goal described as:
1.1<https://tools.ietf.org/html/rfc5586#section-1.1>.  Objectives

   This document defines a mechanism that provides a solution to the
   extended maintenance needs of emerging applications for MPLS.  It
   creates a generic control channel mechanism that may be applied to
   MPLS LSPs and Sections, while maintaining compatibility with the PW
   associated channel.  It also normalizes the use of the ACH for PWs in
   a transport context, and defines a label-based exception mechanism to
   alert LERs/LSRs of the presence of an ACH after the bottom of the
   label stack.

I don't know whether there ever will be bump in Version number because someone needs to changes header's format.
The use the Message Type field will be similar to the Channel Type in G-ACh that has its sub-registry http://www.iana.org/assignments/g-ach-parameters/g-ach-parameters.xhtml#mpls-g-ach-types .
I agree that different Message Types will have different headers but may share common TLV/sub-TLV registry. We'll need to set the sub-registry for TLV/sub-TLV using our experience, good and bad, with LSP Ping TLVs.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Tuesday, July 05, 2016 8:26 AM
To: Gregory Mirsky <[email-masked]>; Fioccola Giuseppe <[email-masked]>; Erik Nordmark <[email-masked]>; [email-masked]; 'Alia Atlas' <[email-masked]>
Cc: Tal Mizrahi <[email-masked]>
Subject: RE: Split solution draft

-Dave

Hi Dave,

                Regards,
                                Greg

To be fleshed out:

-          Values for reply modes

-Dave

Dear All,

                Regards,

                                Greg