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

From: Alia Atlas <[email-masked]>
Date: Fri, 18 Dec 2015 10:16:38 -0500

Hi Thomas,

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.

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.

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

Thanks,
Alia

On Fri, Dec 18, 2015 at 3:49 AM, Thomas Morin <[email-masked]>
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 [email-masked] <mailto:[email-masked]>.
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> rtgwg mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>>
>>>
>

---

From: Thomas Morin <[email-masked]>
Date: Fri, 18 Dec 2015 17:06:44 +0100

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)

> 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 <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi everyone,
>
>     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
>
>
>
>
>                  discussed (e.g.
>             draft-nordmark-nvo3-transcending-traceroute-01).
>
>             The design team has a private mailing list that will be
>             publicly archived.
>             The mailing list is [email-masked]
>             <mailto:[email-masked]> <mailto:[email-masked]
>             <mailto:[email-masked]>>.
>
>             The wiki is at:
>             http://wiki.tools.ietf.org/area/rtg/trac/wiki/RtgOoamDT
>
>             Regards,
>             Alia
>
>

---

From: Alia Atlas <[email-masked]>
Date: Fri, 18 Dec 2015 12:43:37 -0500

Hi Thomas,

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

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

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.

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

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 21 Dec 2015 18:12:38 +0000

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;

*         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:[email-masked]] On Behalf Of Black, David
Sent: Monday, December 21, 2015 7:36 AM
To: Manish Kumar (manishkr); Alia Atlas; [email-masked]
Cc: Brian Haberman; [email-masked]; [email-masked]; joel jaeggli; [email-masked]; Benoit Claise (bclaise); [email-masked]
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 [email-masked]<mailto:[email-masked]> .

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:[email-masked]] On Behalf Of Manish Kumar (manishkr)
Sent: Sunday, December 20, 2015 5:57 PM
To: Alia Atlas; [email-masked]<mailto:[email-masked]>
Cc: Brian Haberman; [email-masked]<mailto:[email-masked]>; joel jaeggli; [email-masked]<mailto:[email-masked]>; Benoit Claise (bclaise); [email-masked]<mailto:[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> on behalf of Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 17 December 2015 1:03 am
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Brian Haberman <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, joel jaeggli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Benoit Claise (bclaise)" <[email-masked]<mailto:[email-masked]>>, Terry Manderson <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 [email-masked]<mailto:[email-masked]>.

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

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 21 Dec 2015 18:13:28 +0000

+ Overlay OAM DT

Thanks,
--David

Hi Alia,

Thanks,
Manish

The charter is below:

Regards,
Alia

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 Dec 2015 10:23:38 -0800

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:[email-masked]] 
> *On Behalf Of *Black, David
> *Sent:* Monday, December 21, 2015 7:36 AM
> *To:* Manish Kumar (manishkr); Alia Atlas; [email-masked]
> *Cc:* Brian Haberman; [email-masked]; 
> [email-masked]; joel jaeggli; 
> [email-masked]; Benoit Claise (bclaise); [email-masked]
> *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
>
> 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):
>
> 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 [email-masked] <mailto:[email-masked]> .
>
> 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:[email-masked]] 
> *On Behalf Of *Manish Kumar (manishkr)
> *Sent:* Sunday, December 20, 2015 5:57 PM
> *To:* Alia Atlas; [email-masked] 
> <mailto:[email-masked]>
> *Cc:* Brian Haberman; [email-masked] 
> <mailto:[email-masked]>; joel jaeggli; [email-masked] 
> <mailto:[email-masked]>; Benoit Claise (bclaise); 
> [email-masked] <mailto:[email-masked]>
> *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 <[email-masked] <mailto:[email-masked]>> 
> on behalf of Alia Atlas <[email-masked] <mailto:[email-masked]>>
> *Date: *Thursday, 17 December 2015 1:03 am
> *To: *"[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Cc: *Brian Haberman <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, joel jaeggli <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>, "Benoit Claise (bclaise)" 
> <[email-masked] <mailto:[email-masked]>>, Terry Manderson 
> <[email-masked] <mailto:[email-masked]>>, 
> "[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Subject: *Design Team on Overlay OAM in Routing is Chartered
>
>     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.
>     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 design team will also use a wiki to track some information.  
> Others are also welcome to comment and interact there.
>
> Rtg-ooam-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-ooam-dt

---

From: Gregory Mirsky <[email-masked]>
Date: Mon, 21 Dec 2015 18:42:17 +0000

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:[email-masked]]
Sent: Monday, December 21, 2015 10:24 AM
To: Gregory Mirsky; [email-masked]
Cc: Alia Atlas ([email-masked])
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:

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

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

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.

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

> *Cc:* Brian Haberman; [email-masked]<mailto:[email-masked]>;

> [email-masked]<mailto:[email-masked]>; joel jaeggli;

> [email-masked]<mailto:[email-masked]>; Benoit Claise (bclaise); [email-masked]<mailto:[email-masked]>

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

> be done with GRE/UDP in mind.

> up - please sending comments to [email-masked]<mailto:[email-masked]> <mailto:[email-masked]> .

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

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

> *To:* Alia Atlas; [email-masked]<mailto:[email-masked]>

> *Cc:* Brian Haberman; [email-masked]<mailto:[email-masked]>

> <mailto:[email-masked]>; joel jaeggli; [email-masked]<mailto:[email-masked]>

> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

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

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

> *From: *rtgwg <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>

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

> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>, Terry Manderson

> <[email-masked] <mailto:[email-masked]<mailto:[email-masked]%20%3cmailto:[email-masked]>>>,

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

> The mailing list is [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>.

> [email-masked]<mailto:[email-masked]>