Re: [Rtg-ooam-dt] FW: Design Team on Overlay OAM in Routing is Chartered

[Gregory Mirsky <[e-mail]>]

Hi Erik,

so far I've identified two requirements towards an encapsulation that OAM sets forth:

*         recognize OAM as payload type to ensure active OAM in-band with data flow;

*         allocate two-bits long field that is not used in determining network treatment of the packet. The field may be used by marking method to instrument passive performance measurement (packet loss, delay and delay variation).

The first one already been noted in the dt-encaps work. We can note that and explain benefits of complying with the second requirement.



                Regards,

                                Greg



-----Original Message-----
From: Erik Nordmark [mailto:[e-mail]]
Sent: Monday, December 21, 2015 10:24 AM
To: Gregory Mirsky; [e-mail]
Cc: Alia Atlas ([e-mail])
Subject: Re: [Rtg-ooam-dt] FW: Design Team on Overlay OAM in Routing is Chartered



On 12/21/15 10:12 AM, Gregory Mirsky wrote:

>

> Happy holidays to All!

>

> hope you're reading this thread (I'll re-send it with adding the DT

> alias).

>

> My questions:

>

> *do you agree with Manish suggestion, i.e. add GRE to mandatory list

> of encapsulations the DT works on;

>

I don't understand what GRE (or GRE over UDP) adds that is unique.

Suppose we come up with an OAM channel identification approach which either needs a bit in the encaps header, and/or a next header value. The only thing I can see unique for GRE/GRE-UDP is how that would be encoded, which isn't central to OAM at all.



Am I missing something? Is there some OAM discussion in the GRE over UDP draft?



I think it is much more useful for the DT to look at how current and proposed OAM approaches work and what can be leverage to have something more common, plus what might be unique for the overlay such as mappings between overlay and underlay OAM.



My 2 cents,

    Erik



> *given our schedule, preparing review of GRE/UDP from OAM perspective

> for TSVWG LC may be done if "yes" is the answer to #1.

>

> Your thoughts, comments - always welcome and greatly appreciated.

>

> Regards,

>

> Greg

>

> *From:*routing-discussion [mailto:[e-mail]]

> *On Behalf Of *Black, David

> *Sent:* Monday, December 21, 2015 7:36 AM

> *To:* Manish Kumar (manishkr); Alia Atlas; [e-mail]<mailto:[e-mail]>

> *Cc:* Brian Haberman; [e-mail]<mailto:[e-mail]>;

> [e-mail]<mailto:[e-mail]>; joel jaeggli;

> [e-mail]<mailto:[e-mail]>; Benoit Claise (bclaise); [e-mail]<mailto:[e-mail]>

> *Subject:* RE: Design Team on Overlay OAM in Routing is Chartered

>

> > I believe that GRE should be mandatory rather than best effort as

> well given its wide deployment for overlays

>

> I have no opinion on that, but suggest that any OAM work on GRE should

> be done with GRE/UDP in mind.

>

> Moreover, the GRE/UDP draft is likely to go to WG Last Call in TSVWG

> in the next month or so. GRE/UDP is a simple encapsulation, as there

> is no (shim) header between the UDP and GRE headers, and none will be

> added (in contrast to the new encapsulations which have such headers):

>

> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-gre-in-udp-encap/

>

> If there are any OAM concerns or recommendations that ought to be

> covered in the GRE/UDP draft, now would be a good time to bring them

> up - please sending comments to [e-mail]<mailto:[e-mail]> <mailto:[e-mail]> .

>

> The current -08 version of the GRE/UDP draft is not really ready for

> comprehensive review - the text on separating operator network usage

> from general Internet usage is "digging in the right place," but I

> expect that another revision is needed to get it into good shape (to

> their credit, the authors have the new text in my [WG chair] Inbox for

> review prior to posting).  Hence I'd suggest focusing on OAM topics

> until the next version (-09) of the GRE/UDP draft is posted.

>

> Thanks,

> --David

>

> *From:*routing-discussion [mailto:[e-mail]]

> *On Behalf Of *Manish Kumar (manishkr)

> *Sent:* Sunday, December 20, 2015 5:57 PM

> *To:* Alia Atlas; [e-mail]<mailto:[e-mail]>

> <mailto:[e-mail]>

> *Cc:* Brian Haberman; [e-mail]<mailto:[e-mail]>

> <mailto:[e-mail]>; joel jaeggli; [e-mail]<mailto:[e-mail]>

> <mailto:[e-mail]>; Benoit Claise (bclaise);

> [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>

> *Subject:* Re: Design Team on Overlay OAM in Routing is Chartered

>

> Hi Alia,

>

> Good to see  this integrated (rather than fragmented!); there would be

> more commonalities than difference of requirements. I believe that GRE

> should be mandatory rather than best effort as well given its wide

> deployment for overlays (perhaps the most widely deployed general

> purpose encap, keeping MPLS in a different league!).

>

> Thanks,

>

> Manish

>

> *From: *rtgwg <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

> on behalf of Alia Atlas <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>

> *Date: *Thursday, 17 December 2015 1:03 am

> *To: *"[e-mail]

> <mailto:[e-mail]>" <[e-mail]

> <mailto:[e-mail]>>

> *Cc: *Brian Haberman <[e-mail]

> <mailto:[e-mail]>>, "[e-mail]

> <mailto:[e-mail]>" <[e-mail]

> <mailto:[e-mail]>>, joel jaeggli <[e-mail]

> <mailto:[e-mail]>>, "[e-mail]

> <mailto:[e-mail]>" <[e-mail]

> <mailto:[e-mail]>>, "Benoit Claise (bclaise)"

> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>, Terry Manderson

> <[e-mail] <mailto:[e-mail]<mailto:[e-mail]%20%3cmailto:[e-mail]>>>,

> "[e-mail] <mailto:[e-mail]><mailto:[e-mail]%20%3cmailto:[e-mail]%3e>" <[e-mail]

> <mailto:[e-mail]>>

> *Subject: *Design Team on Overlay OAM in Routing is Chartered

>

> Based on the presentation by Greg Mirsky and discussion in rtgwg and

> elsewhere, I have decided to charter a fast-moving Routing Area design

> team to work on Overlay OAM.

>

> The charter is below:

>

>     In the Routing Area, several WGs (e.g. NVO3, BIER, and SFC) are

>     working on relatively new encapsulations to create overlays. These

>     overlay or service encapsulations are transport-independent since

>     they may be over different transports or at different layers in

>     the networking stack. Each WG is starting to discuss what OAM and

>     tools need to be developed (see draft-ietf-sfc-oam-framework-00,

>     draft-ietf-bier-oam-requirements-00, and individual drafts in

>     NVO3). With increasing use of overlay and service layer tunnels,

>     extensions to traceroute to allow visibility into multiple layers

>     are being discussed (e.g.

>     draft-nordmark-nvo3-transcending-traceroute-01).

>

>     There is an opportunity to propose protocols and methods to

>     provide Overlay OAM in a sufficiently generic fashion that they

>     can meet the requirements and be applied to at least BIER, NSH,

>     VXLAN-GPE, GENEVE, and GUE. A truly successful result would also

>     be applicable to other technologies.

>

>     This Design Team is chartered to first produce a brief gap

>     analysis and requirements document to focus its work on protocol

>     extensions. This should be published by March 2016. With that

>     basis, this Design Team is chartered to rapidly propose extensions

>     to existing IETF OAM protocols such as those discussed in [RFC

>     7276] and new ones to support the requirements for OAM from NVO3,

>     BIER, and SFC. The Design Team will produce an initial proposal by

>     IETF 95. It is expected that the initial proposal will provide

>     guidance to additional people who will be interested in working on

>     the details and gaps.

>

>     The Design Team will consider the preliminary OAM requirements

>     from NVO3, BIER, and SFC. The Design Team should align with the

>     LIME WG's work on common YANG models of OAM.

>

> The members of the design team are:

>

>  Greg Mirsky (DT lead)

>

>  Ignas Bagdonas

>

>  Erik Nordmark

>

>  Carlos Pignataro

>

>  Mach Chen

>

>  Santosh Pallagatti

>

>  Deepak Kumarde

>

>  David Mozes

>

>  Nagendra Kumar Nainar

>

> The design team has a private mailing list that will be publicly archived.

>

> The mailing list is [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>.

>

> The design team will also use a wiki to track some information.

> Others are also welcome to comment and interact there.

>

> The wiki is at:

> http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgOoamDT

>

> Regards,

>

> Alia

>

>

>

> _______________________________________________

> Rtg-ooam-dt mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt