Subject: [Detnet] Fwd: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt

From: Greg Mirsky <[email-masked]>
Date: Thu, 28 Jun 2018 13:34:49 -0700

Dear All,
I hope that this new draft (yes, that's what I wanted to send the first
time) will be of interest to those working on overlay encapsulations.
Appreciate your comments, questions, and suggestions.

Regards,
Greg

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Jun 28, 2018 at 9:51 AM
Subject: New Version Notification for draft-mirsky-rtgwg-oam-identify-00.txt
To: Gregory Mirsky <[email-masked]>

A new version of I-D, draft-mirsky-rtgwg-oam-identify-00.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:           draft-mirsky-rtgwg-oam-identify
Revision:       00
Title:          Identification of Overlay Operations, Administration, and
Maintenance (OAM)
Document date:  2018-06-28
Group:          Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam-
identify-00.txt
Status:         https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-
identify/
Htmlized:       https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-
identify-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-
oam-identify

Abstract:
   This document analyzes how the presence of Operations,
   Administration, and Maintenance (OAM) control command and/or special
   data is identified in some overlay networks, and an impact on the
   choice of identification may have on OAM functionality.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Tom Herbert <[email-masked]>
Date: Thu, 28 Jun 2018 14:31:53 -0700

> Appreciate your comments, questions, and suggestions.

Regarding OAM in GUE, the C bit can be set to indicate a control
packet which could be OAM (draft-ietf-intarea-gue-05). I imagine that
OAM could be implement in one or more ctypes. This is considered an
alternative to GUE carrying a data protocol payload, it's not
considered part of the GUE header and isn't limited by GUE header len.

The statement in Geneve description "transit devices MUST NOT attempt
to interpret or process it" is true for all UDP encapsulation
protocols. The problem is that encapsulation is determined by
destination port number. As described in RFC7605, UDP port numbers
only have meaning at the endpoints, so transit devices may incorrectly
interpret packets as being an encapsulation. Incorrectly reading a
packet as encapsulation might be innocuous, but an intermediate node
modifying such a packet that it incorrectly believes is an
encapsulation would be systematic data corruption. Because of this,
probably the only robust method for in-situ OAM is Hop-by-Hop options.

Tom

> URL:
> https://www.ietf.org/internet-drafts/draft-mirsky-rtgwg-oam-identify-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-mirsky-rtgwg-oam-identify/
> Htmlized:
> https://tools.ietf.org/html/draft-mirsky-rtgwg-oam-identify-00
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-mirsky-rtgwg-oam-identify
>
>
> Abstract:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 29 Jun 2018 10:06:48 -0700

Hi Tom,
many thanks for taking interest in the topic and helping with details on
GUE and OAM. I've reviewed the listed in the draft encapsulations and
analyzed how active OAM may be identified in each of the cases. For active
OAM to be more useful the test packets must be in-band with the data that
is being monitored. For the GUE case, I believe, that means that an OAM
test packet will have all the values that characterize the monitored flow
that may affect routing the packet with exception of values of C-bit and
Proto/ctype field.

Regards,
Greg