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

[Alia Atlas <[e-mail]>]

Hi Thomas,

On Fri, Dec 18, 2015 at 11:06 AM, Thomas Morin <[e-mail]>
wrote:

> 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)
>

Because the DT needs to get moving and having this conversation is more
fruitful.  The DT is already hopeful to have something that has broader
reach - but there's a clear problem.


> 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 ?
>

No, of course not!   I didn't specify IP/IP or PWE3/MPLS or many other
encaps, because they already have OAM and the protocols providing that OAM
is where the DT starts to think about what extensions are needed or
possible.

The DT is supposed to look at existing IETF protocols and consider
extensions to them.  That does include the set used for MPLS/IP encaps.
BIER is also primarily an MPLS encap, though IPv6 is also being discussed.
I don't see MPLS/IP as especially different.

The DT has to be reasonably scoped to get something done rapidly.


> > 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.
>

If MPLS/IP OAM is already good and sufficient, then it can be a target for
extending as necessary for the additional OAM for these new encaps.  If
not, understanding the gaps will help with seeing how additional OAM can
help.

What I hear you saying is "please don't diverge from what's there for
MPLS/IP" and yes, if it is practical to extend existing OAM protocols, then
that will be done.  If not, there will be reasons explained and the
applicability of any new protocol to be more generic will be considered.

The DT is supposed to come up with protocol work in not quite 3 months.
They need to move fast and there will be opportunity and time to improve
and discuss what they are thinking.

If you have suggestions for what RFCs/drafts the DT should be sure to look
at, please email them and/or put them up on the DT wiki.

Regards,
Alia

Best,
>
> -Thomas
>
>
>
>
>
>
> On Fri, Dec 18, 2015 at 3:49 AM, Thomas Morin <[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]>.
>>>>
>>>> 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
>>>>
>>>>
>>>>
>