Subject: [Rtg-ooam-dt] OOAM Ping update

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

Dear All,
I've expanded IANA section and added text to how the Reply Mode field controls/instructs the responding overlay node.

Please review, share your comments, suggestions.

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Fri, 8 Jul 2016 14:43:17 +0000

OOAM Design team,

Would it be reasonable to add a Reply Mode of "Respond to Sender", which is applicable in some cases?

I outlined my SFC use-case for SFFs probing the liveliness of SFs, which is not met by either "Do not reply" or "Reply via IPv4/IPv6 UDP packet".

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Wednesday, July 06, 2016 5:00 PM
To: [email-masked]
Cc: Dave Dolson; Tal Mizrahi
Subject: OOAM Ping update

Dear All,

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Fri, 8 Jul 2016 15:11:05 +0000

Looking at the packet format again, I think a total length field is required, to allow the message to be carried within frames that do not have a frame size (e.g., Ethernet or MPLS).

Dear All,

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Fri, 8 Jul 2016 18:53:50 +0000

OOAM Design Team,

Based on https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-00,
we've written this draft for SFC:
https://tools.ietf.org/html/draft-dolson-sfc-oam-sff-sf-cv-00

It assumes the existence of a "Return to Sender" Reply Mode, which we assume we can allocate by some means even if not added to draft-ooamdt-rtgwg-demand-cc-cv

Perhaps you'll find this useful in presenting to SFC, if granted a speaking slot on the agenda.

-Dave

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Sat, 9 Jul 2016 07:10:41 +0000

Hi Dave,
Echo Request/Reply messages, as all OOAM messages, will have OOAM Header that, as defined in draft-ooam-rtgwf-ooam-header-00, has Length field that is the number of octets of the OOAM packet. We've discussed the have, I think in addition to the Length field, First TLV Offset field. I think that we need more input from NPU vendors whether this is something they find useful.

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Friday, July 08, 2016 8:11 AM
To: Gregory Mirsky <[email-masked]>; [email-masked]
Cc: Tal Mizrahi <[email-masked]>
Subject: RE: OOAM Ping update

To: [email-masked]<mailto:[email-masked]>

Dear All,

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Sat, 9 Jul 2016 13:21:21 +0000

I totally missed the point that the ping message should be carried within the ooam header. That certainly answers the length question.

I think the cc-cv draft should mention that.

Regarding the first TLV offset, take care that adding redundant information to a packet just means more sanity checking to be done. Receiver must check that the offset doesn't go past the end of the frame, for instance.

From: Gregory Mirsky
Sent: Saturday, July 9, 2016 3:10 AM
To: Dave Dolson; [email-masked]
Cc: Tal Mizrahi
Subject: RE: OOAM Ping update

Hi Dave,
Echo Request/Reply messages, as all OOAM messages, will have OOAM Header that, as defined in draft-ooam-rtgwf-ooam-header-00, has Length field that is the number of octets of the OOAM packet. We’ve discussed the have, I think in addition to the Length field, First TLV Offset field. I think that we need more input from NPU vendors whether this is something they find useful.

                Regards,
                                Greg

Dear All,
I’ve expanded IANA section and added text to how the Reply Mode field controls/instructs the responding overlay node.

                Regards,
                                Greg

---

From: Dave Dolson <[email-masked]>
Date: Mon, 11 Jul 2016 14:10:35 +0000

To put the OAM header within SFC, a value is required in the "Next Protocol" field of the NSH header.

Where (in which working group and draft) should this be documented in?
Should draft-ooamdt-rtgwg-ooam-header discuss this, or should there be a document for "OOAM within NSH" ?

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Saturday, July 09, 2016 3:11 AM
To: Dave Dolson; [email-masked]
Cc: Tal Mizrahi
Subject: RE: OOAM Ping update

Hi Dave,

                Regards,
                                Greg

From: Dave Dolson [mailto:[email-masked]]
Sent: Friday, July 08, 2016 8:11 AM
To: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Tal Mizrahi <[email-masked]<mailto:[email-masked]>>
Subject: RE: OOAM Ping update

Dear All,

                Regards,
                                Greg

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 11 Jul 2016 18:48:41 +0000

Hi Dave,
you've asked very important question. I think that in Berlin it will be discussed with our Responsible Area Director, WG chairs (SFC, NVO3, and BIER) and those interested and involved in development of OAM protocols, solutions. There's not just one way to slice the bread but, and I agree, we should come with way to coordinate our work to avoid disconnect, duplication of our efforts.

                Regards,
                                Greg

Sent: Monday, July 11, 2016 7:11 AM

From: Gregory Mirsky [mailto:[email-masked]]
Sent: Saturday, July 09, 2016 3:11 AM
To: Dave Dolson; [email-masked]<mailto:[email-masked]>
Cc: Tal Mizrahi
Subject: RE: OOAM Ping update

Hi Dave,

                Regards,
                                Greg

Dear All,

                Regards,
                                Greg