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

[Thomas Morin <[e-mail]>]

Hi Alia,

2015-12-18, Alia Atlas:
> I think we've set the charter though I certainly agree that MPLS/GRE 
> and MPLS/UDP are examples of overlay technologies that could benefit 
> from improved OAM.

(I don't understand why this charter couldn't be modified now)

> My hope is that the DT can come up with a sufficiently generic 
> extensions/protocol to cover these cases as well, but I need the 
> design focus to be on the new encapsulations that don't have any OAM 
> yet.  That's where we have a chance to stop the industry from 
> diverging.  If the result is suitably generic and the benefits are 
> seen as useful, then I think it's more likely for industry to adopt 
> and use it for existing technologies.

Not explicitly including MPLS/IP in the charter of this DT seems to me 
as creating a risk of divergence:
- whether MPLS has some form of OAM applicable to service-layer tunnels, 
and then not including such OAM in the gap analysis creates a risk of 
divergence (e.g. this DT reinventing a wheel)
- or MPLS OAM for service-layers tunnels is not specified or suitable, 
and then not including MPLS/IP in the scope of the DT, like "the new 
encapsulations that don't have any OAM yet", creates a risk of 
divergence as well (by creating something that would not be a good fit 
for MPLS/IP)

So what I would draw from your explanation that the choice of not 
including MPLS/IP encaps in the charter is made with idea that it will 
help the DT focus on avoiding a divergence of OAM *inside* the family of 
new encapsulations, accepting the associated risk of a divergence of 
whatever ends up being designed for this family and OAM for MPLS/IP encaps.

Is this a correct understanding of your choice ?

 > It'd be quite helpful if you could articulate in email to the design 
team what you see as the existing gaps.

I haven't stated anything on the existence or non-existence of gaps, but 
as explained above, I don't think we have to do a gap analysis to get to 
the conclusion that it may be wishful thinking to not include MPLS/IP in 
the charter and still hope that things will converge between new encaps 
and MPLS/IP encaps.

Best,

-Thomas



>
>
> On Fri, Dec 18, 2015 at 3:49 AM, Thomas Morin <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi everyone,
>
>     2015-12-18, Loa Andersson:
>
>         Let me know if there is any support I can give from the bottom
>         of my
>         mpls well.
>
>
>     This comment is a good opportunity to highlight the fact that
>     MPLS/GRE and MPLS/UDP are part of various service layer tunnels
>     used for overlays.
>
>     I will go as far as to suggest that these encaps should be
>     explicitely called out in the DT charter (more than through "other
>     technologies").
>
>     Best,
>
>     -Thomas
>
>
>
>
>         On 2015-12-17 03:33, Alia Atlas wrote:
>
>             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]
>             <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
>
>