[Rtg-ooam-dt] draft-ietf-nvo3-arch-06 - OAM text

["Black, David" <[e-mail]>]

Hi Alia,

With many thanks to Greg for his help, we now have draft OAM text.   Email’s into Carlos asking him to take a look - after any necessary edits, I’ll send the resulting text to the nvo3 list (it definitely needs list review - the text turned out to be about 3 paragraphs).

I’ve pasted the text below if anyone’s curious ...

Thanks, --David

12.  Operations, Administration and Maintenance (OAM)

   The simplicity of operating and debugging overlay networks will be
   critical for successful deployment.

   Overlay networks are based on tunnels between NVEs, so the OAM
   (Operations and Administration and Maintenance) [RFC6291] framework
   for overlay networks can draw from prior IETF OAM work for tunnel-
   based networks, specifically L2VPN OAM [RFC6136].  RFC 6136 focuses
   on Fault Management and Performance Management as fundamental to
   L2VPN service delivery, leaving the Configuration, Management,
   Accounting Management and Security Management components of the OSI
  "FCAPS" taxonomy [M.3400] for further study.  This section does
   likewise for NVO3 OAM, but those three areas continue to be important
   parts of complete OAM functionality for NVO3.

   As is the case for L2VPN, there is a client/server relationship
   between the overlay and underlay networks that is a consideration for
   fault and performance management - a fault in the underlay may
   manifest as fault and/or performance issues in the overlay.
   Diagnosing and fixing such issues are complicated by NVO3 abstracting
   the underlay network away from the overlay network (e.g.,
   intermediate nodes on the underlay network path between NVEs are
   hidden from overlay VNs).

   NVO3-specific OAM techniques and tools are needed to look beyond this
   abstraction in order to diagnose and correct problems that appear in
   the overlay - one example of such a tool is underlay-aware
   traceroute, as proposed in
   [I-D.nordmark-nvo3-transcending-traceroute].  Such NVO3 tools and
   techniques are best viewed as complements to (i.e., not as
   replacements for) single-network tools that apply to the overlay or
   underlay network.  There is a resulting need for coordination among
   the tools for each individual network (overlay, underlay) and the
   NVO3-aware dual-network tools in order to achieve effective
   monitoring and fault diagnosis.  For example, all of the tools
   involved ought to use similar defect detection intervals and similar
   performance measurement intervals in order to provide consistency and
   comparability of results in each area.

From: Black, David
Sent: Friday, August 05, 2016 4:57 PM
To: Alia Atlas; Greg Mirsky
Cc: [e-mail]; [e-mail]; [e-mail]; Black, David
Subject: RE: [nvo3] AD review of draft-ietf-nvo3-arch-06

Hi Alia,

As a baseline plan, I’ll work with Greg next week on a 2-3 sentence rewrite of Section 12 of the nvo3 architecture draft.

I hope Larry (Kreeger) or Thomas (Narten) is online, as a new version of the nvo3 architecture draft looks like it will be needed, and I don’t have the XML source.

Thanks, --David

From: Alia Atlas [mailto:[e-mail]]
Sent: Friday, August 05, 2016 11:17 AM
To: Greg Mirsky
Cc: Black, David; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [nvo3] AD review of draft-ietf-nvo3-arch-06

Please let me know if you expect to get this done in the next week.
I'm fine with having it on a later telechat and extending or redoing the IETF Last
Call, if need be.

Depending on the technical depth of the change, it may need to briefly go back
to the WG.

Regards,
Alia

On Fri, Aug 5, 2016 at 11:14 AM, Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi David,
I'd be glad to work with you and authors of the NVO3 architecture document.
Please let me know if you have any comments, suggestions on the OOAM requirements document. And perhaps the tag of the section can be changed to Operations and Maintenance to use interpretation of OAM provided in RFC 6291.

Regards,
Greg

On Tue, Aug 2, 2016 at 3:46 PM, Black, David <[e-mail]<mailto:[e-mail]>> wrote:
Greg,
[-nvo3 list]

Would you and the other members of the overlay OAM design team be interested in working with the NVO3 architecture draft authors on a reasonably short replacement for Section 12 of that architecture draft including a reference to the ooamdt requirements draft?

Here’s what Section 12 currently says (and I won’t disagree with Alia’s critique of it):

12.  Operations and Management

   The simplicity of operating and debugging overlay networks will be
   critical for successful deployment.  Some architectural choices can
   facilitate or hinder OAM.  Related OAM drafts include
   [I-D.ashwood-nvo3-operational-requirement].

Thanks, --David

From: Greg Mirsky [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Sunday, July 31, 2016 1:34 AM
To: Black, David
Cc: Alia Atlas; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [nvo3] AD review of draft-ietf-nvo3-arch-06

Hi David,
greatly appreciate your consideration of draft-ooamdt-rtgwg-ooam-requirement-01. If you have comments, any questions, suggestions please share them and we'll work to address them in timely manner.

Regards,
Greg

On Fri, Jul 29, 2016 at 4:33 PM, Black, David <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alia,

> I will optimistically send this document to IETF Last Call - but the authors do need to update this section and respond to my other concerns.

Thanks for doing this.  Regarding your Major concern:

>  i) I note that draft-ashwood-nvo3-operational-requirement-03 expired about 3 years ago.  Section 12 basically says that
> OAM is important and punts to this draft.  I believe that you will need more details.

Would it be acceptable to provide a little bit more in the way of details and then point to draft-ooamdt-rtgwg-ooam-requirement-01 ?
It seems preferable to have overlay OAM requirements discussions in the context of that draft rather than this NVO3 architecture draft.

For your first minor concern:

>    1) Please add C-VID to the terminology.  It is used without context in 3.1.1.

I think we should rewrite that sentence to just eliminate the C-VID acronym, e.g.,

OLD
   Note that the handling of C-VIDs has additional complications, as
   described in Section 4.2.1 below.
NEW
  Note that there are additional considerations when VLAN tags are used to
  identify both the VN and a Tenant System VLAN within that VN,
  as described in Section 4.2.1 below.

Everything else appears to be useful editorial suggestions.

Thanks, --David

From: Alia Atlas [mailto:[e-mail]<mailto:[e-mail]>]
Sent: Friday, July 29, 2016 6:14 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: AD review of draft-ietf-nvo3-arch-06

First, I would like to thank the authors, David, Jon, Larry, Marc, and Thomas, for their work on this draft and pushing it to completion.

As is customary, I have done my AD review of draft-ietf-nvo3-arch-06 before progressing it.  I do apologize for the delay in my review; I had a lot of documents show up quite quickly this winter and spring.

My primary concern is around the operational and management considerations.  My detailed review is below.   I will optimistically send this document to IETF Last Call - but the authors do need to update this section and respond to my other concerns.  If they are timely, then this can make it onto the IESG telechat on August 18.

Major:

   i) I note that draft-ashwood-nvo3-operational-requirement-03 expired about 3 years ago.  Section 12 basically says that OAM is important and punts to this draft.  I believe that you will need more details.

Minor:

   1) Please add C-VID to the terminology.  It is used without context in 3.1.1.

    2)In Sec 4.1:  "While there may be APIs between the NVE and hypervisor to support necessary interaction, the details of such an API are not in-scope for the IETF to work on."
Could this be softened to "not specifically in-scope for the NVO3 WG to work on"?  If there were agreement that the NVE and hypervisors need interoperability, I could see APIs being in scope.

  3) It looks like work on draft-ietf-nvo3-dataplane-requirements-03 has been abandoned (which is fine).  Please remove the reference.


Nits:

a) In Sec 3.4, it says "in use today".  Replace with "in use in 2016" or the like - since the RFC will live for a long time and not be updated with "today" systems.

Regards & Thanks,
Alia

_______________________________________________
nvo3 mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/nvo3