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 On Thu, Jun 28, 2018 at 2:31 PM, Tom Herbert <t...@herbertland.com> wrote: > On Thu, Jun 28, 2018 at 1:34 PM, Greg Mirsky <gregimir...@gmail.com> > wrote: > > 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. > > > > 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 > > > > > > Regards, > > Greg > > > > ---------- Forwarded message ---------- > > From: <internet-dra...@ietf.org> > > Date: Thu, Jun 28, 2018 at 9:51 AM > > Subject: New Version Notification for draft-mirsky-rtgwg-oam- > identify-00.txt > > To: Gregory Mirsky <gregimir...@gmail.com> > > > > > > > > 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 > > > > > > > > _______________________________________________ > > Int-area mailing list > > Int-area@ietf.org > > https://www.ietf.org/mailman/listinfo/int-area > > >
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
