Subject: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

From: "qiangli (D)" <[email-masked]>
Date: Fri, 2 Jun 2017 09:36:29 +0000

Dear All,

We have upload "Gap Analysis for Network Slicing" draft 00 on https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?include_text=1

Your comments and reviews are greatly appreciated.

Abstract:

   This document presents network slicing differentiation from the non-

   partition network or from simply partition of connectivity resources.

   It lists 15 standardization gaps related to 6 key requirements for

   network slicing.  It also presents an analysis of existing related

   work and other potential solutions on network slicing.

   This gap analysis document aims to provide a basis for future works

   in network slicing.

Best regards,

Co-authors

---

From: "sebastian" <[email-masked]>
Date: Fri, 2 Jun 2017 08:30:23 -0500

Dear Colleagues,

Thanks for delineating the prominent aspects of network slicing.

Here are some thoughts on terminology.

With the diverse nature of services in the 5G realm, where XaaS (Anything as
a Service) is an emerging paradigm, perhaps some of the legacy terminology
may need to be generalized.

For example, the term 'operator' was typically used with reference to
various types of 'access' modalities.

In NGMN, such terminology is being generalized.

NSP : Network Service Provider (instead of 'operator'): This entity only
provides 'access' type of services

SP: Service Provider: This entity provides any service above the network
layer, but may also behave as an NSP

Best wishes.

-Sebastian

From: Netslices [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: Friday, June 2, 2017 4:36 AM
To: [email-masked]
Subject: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear All,

We have upload "Gap Analysis for Network Slicing" draft 00 on
https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?include
_text=1

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: <[email-masked]>
Date: Fri, 2 Jun 2017 13:59:18 +0000

Hi Cristina,

Thank you for sharing the draft. Please find below some comments, fwiw:

(1) Section 4.2.1 mentions the following:

"the [SLA-Exchange<https://tools.ietf.org/html/draft-qiang-netslices-gap-analysis-00#ref-SLA-Exchange>] can be used to
   negotiate the SLAs and report on SLA events.  Further analysis is
   needed to provide a complete package.
"

Actually, this is not possible with [SLA-Exchange] given that document says explicitly: "The SLA negotiation and assurance is outside the scope of this document."

(2) Section 4.2.2. says the following:

   The NSRS requirement for reachability, direction, bandwidth

   requirements, performance metrics, traffic isolation constraints, and

   flow identification can be built utilizing protocol which can perform

   operations (read, write, notification, actions (aka rpcs)) on a yang

   service layer that supports these traffic engineer and resource

   definition at the service layers.  The network slicing service data

   model can extend existing work in the TEAS and I2RS working group for

   protocol-independent topology models.  These models support

   configuration or the dynamic datastores defined in [NMDA<https://tools.ietf.org/html/draft-qiang-netslices-gap-analysis-00#ref-NMDA>] which will

   be abbreviated as NMDA in this section.  This section provides the

   detail on how the NSRS can be built from these models and the

   RESTCONF protocol.

I'm a little bit puzzled here given that the NSRS is not about interacting with underlying network nodes. Especially, I'm not sure to understand the discussion about "protocol which can perform operations (read, write, notification, actions (aka rpcs))" in this context.

(3) Table 2:

·         Putting aside what is meant by "NS state monitoring", is there any particular reason "Mechanism/protocols for NS state monitoring;" is listed under NSRS? This is IMHO more an OAM issue.

·         Item "8) Mechanisms for on-demand, isolated, elastic and efficient network slice instantiation and resource association" is mysterious. I failed to find where that item is discussed in Section 6.

·         I'm not sure to understand what is meant by "10) Mechanisms for customized network slices".

·         Items 12 and 13 are not related to NS identification. Further, those are not discussed in the corresponding section.

Thank you.

Cheers,
Med

De : Netslices [mailto:[email-masked]] De la part de qiangli (D)
Envoyé : vendredi 2 juin 2017 11:36
À : [email-masked]
Objet : [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 2 Jun 2017 16:20:56 +0200

Hello,

I have just skimmed the first part of the document.

1.) If you pull in terms defined in other drafts or (proposed) 
standards, please include the references. (random example: MDSC is 
defined in I.D-ietf-teas-actn-framework, I think).

If it is not getting too big and if it is vital to grasp the context of 
the draft, I would suggest to pull in the complete definition (and still 
reference the source, of course).

2.) Some terms I can only guess what they mean in this context, examples 
include terminal, guarantee, or the scope of the expression "individual 
parts and pieces of the overall system", which is probably something 
like every system entity or subsystem that is required to provide the 
capabilities of a differentiable network slice?

3.) In general, I like section 4.1 very much. It enables a good 
understanding of what are important characteristics of a network slice 
that are potential KPI.

4.) I would like to see an explicit differentiation and definition of 
the terms action, task, procedure (and maybe even a "middle-layer" term 
between action and procedure called activity - a building block of 
actions that can compose procedures). The terms mentioned above imply a 
specialization (and there for a some sort of taxonomy) that can be used 
to map actual running solutions and actions that can be performed by 
them - to more general procedures that are required to create a network 
slice on an architectural level.

5.) I like the Topology Hierarchy (Stack) in Figure 2, but I am not sure 
if the expressiveness of, e.g. draft-ietf-i2rs-yang-l2-network-topology 
satisfies the requirements of network slicing. For example, top-of-the 
rack data plane units, which physical ports are mapped to multiple 
redundant endpoints that maintain a partially merged control plane (to 
handle the redundant mapping) but are separate information systems on 
the management plane cannot be modeled, I think. This is just one of the 
more complex examples that fall under the scope of resilience (see below).

6.) In general, the topic Guaranteed Slice Performance and Isolation 
does not seem to address availability or resilience of a or inside a 
network slice. Is that out of scope? That is why I would like a better 
understanding of what can be "guaranteed" in general (see item 2. above).

7.) I find the title 7.3. Abstraction of Network in Network confusing 
after reading the content of that section.

This was just a quick first pass. In general, this is an excellent 
contribution and really focuses an essential part of the ongoing 
activities! Thank you!

Viele Grüße,

Henk

On 06/02/2017 11:36 AM, qiangli (D) wrote:
> https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?include_text=1
> 
> _______________________________________________
> Netslices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netslices
>

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 2 Jun 2017 16:24:01 +0200

+1 aggregating and defining of legacy, current and maybe "new" terms 
will prevent confusing when trying to talk about the same thing.

BR,
Henk

On 06/02/2017 03:30 PM, sebastian wrote:
> With the diverse nature of services in the 5G realm, where XaaS 
> (Anything as a Service) is an emerging paradigm, perhaps some of the 
> legacy terminology may need to be generalized.
> 
> For example, the term ‘operator’ was typically used with reference to 
> various types of ‘access’ modalities.
> 
> *NSP*: Network Service Provider (instead of ‘operator’): This entity 
> only provides ‘access’ type of services
> 
> *SP*: Service Provider: This entity provides any service above the 
> network layer, but may also behave as an NSP
> 
> Best wishes.
> 
> -Sebastian
> 
> *From:*Netslices [mailto:[email-masked]] *On Behalf Of 
> *qiangli (D)
> *Sent:* Friday, June 2, 2017 4:36 AM
> *To:* [email-masked]
> *Subject:* [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded
> 
> Dear All,
>

---

From: GENG Liang <[email-masked]>
Date: Fri, 2 Jun 2017 20:58:52 +0000

Hi Sebastian,

We have defined term with similar generalization concernsin Architecture draft. All other rnetslices draft is referring to these terminologies. This document can be find here
https://tools.ietf.org/html/draft-geng-netslices-architecture-01

Best wishes
Liang

________________________________
Liang GENG
China Mobile Research Institute

From: sebastian<mailto:[email-masked]>
Date: 2017-06-02 21:30
To: 'qiangli \(D\)'<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded
Dear Colleagues,

With the diverse nature of services in the 5G realm, where XaaS (Anything as a Service) is an emerging paradigm, perhaps some of the legacy terminology may need to be generalized.
For example, the term ‘operator’ was typically used with reference to various types of ‘access’ modalities.

In NGMN, such terminology is being generalized.
NSP : Network Service Provider (instead of ‘operator’): This entity only provides ‘access’ type of services
SP: Service Provider: This entity provides any service above the network layer, but may also behave as an NSP

Best wishes.
-Sebastian

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: "sebastian" <[email-masked]>
Date: Fri, 2 Jun 2017 21:49:33 -0500

Hello, Liang,

Thanks for the reference draft.

The terminology with respect to the various aspects of a network slice and related abstractions, look good.

In several sections of the draft there are references to the term ‘operator’, in different contexts.

A generalized distinction, in terms of NSP and SP would be relevant in the draft, from a forward-looking perspective, where domain owners may either just be an NSP or an SP, or an SP that also behaves as an NSP.

Happy to scrub the text, with tracked changes with generalized terminology that uses SP and NSP, instead of ‘operator’

Many thanks.

-Sebastian

From: GENG Liang [mailto:[email-masked]] 
Sent: Friday, June 2, 2017 3:59 PM
To: sebastian.thalanany <[email-masked]>; 'qiangli (D)' <[email-masked]>; [email-masked]
Subject: Re: Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Hi Sebastian,

 <https://tools.ietf.org/html/draft-geng-netslices-architecture-01> https://tools.ietf.org/html/draft-geng-netslices-architecture-01 

Best wishes

Liang

  _____  

Liang GENG 

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

Date: 2017-06-02 21:30

To: 'qiangli \(D\)' <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 

Dear Colleagues,

Best wishes.

-Sebastian

From: Netslices [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: Friday, June 2, 2017 4:36 AM
To: [email-masked] <mailto:[email-masked]> 
Subject: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: Igor Bryskin <[email-masked]>
Date: Sat, 3 Jun 2017 18:05:16 +0000

Hi,

I think "3.3.1 Reclusiveness" should me replaced with "3.3.1 Recursiveness" .

Cheers,
Igor
From:sebastian
To:'GENG Liang','sebastian.thalanany',qiangli (D),[email-masked],
Date:2017-06-02 22:50:04
Subject:Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Hello, Liang,

Many thanks.
-Sebastian

Hi Sebastian,

Best wishes
Liang

Best wishes.
-Sebastian

From: Netslices [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: Friday, June 2, 2017 4:36 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: Alex Galis <[email-masked]>
Date: Sun, 4 Jun 2017 12:04:20 +0100

Hi Igor

Thank you for your careful reading of the gap analysis draft. It looks that an automatic ‘spell checker’ added a funny twist in the process ….

Many “recursive" cheers

Alex
> On 3 Jun 2017, at 19:05, Igor Bryskin <[email-masked]> wrote:
> 
> Hi,
> 
> To:'GENG Liang','sebastian.thalanany',qiangli (D),[email-masked] <mailto:[email-masked]>,
> Date:2017-06-02 22:50:04
>   <>
> From: GENG Liang [mailto:[email-masked] <mailto:[email-masked]>] 
> To: sebastian.thalanany <[email-masked] <mailto:[email-masked]>>; 'qiangli (D)' <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> https://tools.ietf.org/html/draft-geng-netslices-architecture-01 <https://tools.ietf.org/html/draft-geng-netslices-architecture-01> 
> 
> 
> Best wishes
> Liang
>  
> Liang GENG
> To: 'qiangli \(D\)' <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>
> From: Netslices [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of qiangli (D)
> We have upload "Gap Analysis for Network Slicing" draft 00 on https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?include_text=1 <https://datatracker.ietf.org/doc/draft-qiang-netslices-gap-analysis/?include_text=1>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netslices <https://www.ietf.org/mailman/listinfo/netslices>

---

From: "qiangli (D)" <[email-masked]>
Date: Mon, 5 Jun 2017 02:00:20 +0000

Hi Sebastian,

Good point. As we stated in Sec. 2, all of the network slicing related terminology used in the gap-analysis doc. have been defined in draft-geng-netslices-architecture-01.

Best regards,

Cristina QIANG

From: sebastian [mailto:[email-masked]]
Sent: Friday, June 02, 2017 9:30 PM
To: qiangli (D); [email-masked]
Subject: RE: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear Colleagues,

With the diverse nature of services in the 5G realm, where XaaS (Anything as a Service) is an emerging paradigm, perhaps some of the legacy terminology may need to be generalized.
For example, the term 'operator' was typically used with reference to various types of 'access' modalities.

In NGMN, such terminology is being generalized.
NSP : Network Service Provider (instead of 'operator'): This entity only provides 'access' type of services
SP: Service Provider: This entity provides any service above the network layer, but may also behave as an NSP

Best wishes.
-Sebastian

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: "qiangli (D)" <[email-masked]>
Date: Mon, 5 Jun 2017 08:02:06 +0000

Hi Henk,

Thank you for your comments, please see my reply inline marked as [Cr].

Best regards,

Cristina QIANG

-----Original Message-----
From: Netslices [mailto:[email-masked]] On Behalf Of Henk Birkholz
Sent: Friday, June 02, 2017 10:21 PM
To: [email-masked]
Subject: Re: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Hello,

1.) If you pull in terms defined in other drafts or (proposed) standards, please include the references. (random example: MDSC is defined in I.D-ietf-teas-actn-framework, I think).

If it is not getting too big and if it is vital to grasp the context of the draft, I would suggest to pull in the complete definition (and still reference the source, of course).

[Cr] will do in the next version.

2.) Some terms I can only guess what they mean in this context, examples include terminal, guarantee, or the scope of the expression "individual parts and pieces of the overall system", which is probably something like every system entity or subsystem that is required to provide the capabilities of a differentiable network slice?

[Cr] I think the term "(network slice) terminal" has been defined in draft-geng-netslices-architecture-01. We will use more explicit expression and define necessary terms later. 

3.) In general, I like section 4.1 very much. It enables a good understanding of what are important characteristics of a network slice that are potential KPI.

4.) I would like to see an explicit differentiation and definition of the terms action, task, procedure (and maybe even a "middle-layer" term between action and procedure called activity - a building block of actions that can compose procedures). The terms mentioned above imply a specialization (and there for a some sort of taxonomy) that can be used to map actual running solutions and actions that can be performed by them - to more general procedures that are required to create a network slice on an architectural level.

[Cr] same reply as above.

5.) I like the Topology Hierarchy (Stack) in Figure 2, but I am not sure if the expressiveness of, e.g. draft-ietf-i2rs-yang-l2-network-topology
satisfies the requirements of network slicing. For example, top-of-the rack data plane units, which physical ports are mapped to multiple redundant endpoints that maintain a partially merged control plane (to handle the redundant mapping) but are separate information systems on the management plane cannot be modeled, I think. This is just one of the more complex examples that fall under the scope of resilience (see below).

6.) In general, the topic Guaranteed Slice Performance and Isolation does not seem to address availability or resilience of a or inside a network slice. Is that out of scope? That is why I would like a better understanding of what can be "guaranteed" in general (see item 2. above).

[Cr] a network slice could be simply regarded as a logical network resource/function union that owned by a tenant. To a certain extent, how to manage and use this resource (including how to achieve the availability or resilience inside a network slice) is the tenant's business, that is out of the scope of this topic. As table 1 illustrated, the guaranteed slice performance and isolation topic aims to discuss that the isolation among different network slices is quite necessary for guaranteeing the performance, security, operation, reliability, etc. 

7.) I find the title 7.3. Abstraction of Network in Network confusing after reading the content of that section.

[Cr] The subsection 7.3 mainly discusses the abstraction of a network slice that across multiple domains. What do you think of the title "multi-domain abstraction"? Or do you have any good suggestions?

Viele Grüße,

Henk

---

From: "qinjun (G)" <[email-masked]>
Date: Tue, 6 Jun 2017 05:53:41 +0000

Hi, Cristina:

Thanks for your contribution work. The draft could be a good reference and basis for the network slicing related work.

After reading the whole draft, I am wondering about the difference between  VN in ACTN and network slicing, and  still a little confused about the meaning of "ACTN is path-oriented (i.e., TE tunnel based), whilst network slicing is resource-oriented." Which mentioned in the third paragraph in section 5.2.2.  What is the exact meaning of "path-oriented" and "resource-oriented"? In my understanding, in VN of ACTN, there's no explicit limitation that it cannot control the network resources, by using suitable technology, I think the "path" can be combined with the underlay resources.  About figure 4, in network slicing environment, if LSP1 and 2 belongs to two  slices, although the whole bandwidth on path C-D has no change, but the bandwidth of each slice changed, I think it still need reconfiguration.

Best regards
Jun Qin

From: Netslices [mailto:[email-masked]] On Behalf Of qiangli (D)
Sent: Friday, June 02, 2017 5:36 PM
To: [email-masked]
Subject: [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: "qiangli (D)" <[email-masked]>
Date: Tue, 6 Jun 2017 06:48:38 +0000

Hi Med,

Thank you very much for your comment, I will try to reply you inline.

Best regards,

Cristina QIANG

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, June 02, 2017 9:59 PM
To: qiangli (D); [email-masked]
Subject: RE: draft-qiang-netslices-gap-analysis-00 Uploaded

Hi Cristina,

[Cr] [SLA-Exchange](i.e., draft-ietf-idr-sla-exchange-10.txt) provides an in-band method to exchange the SLA parameters, and then by the receiving devices to translate SLA in technical specific provisioning languages. Our statement is indeed not accurate enough, [SLA-Exchange] could be a potential solution that INDIRECTLY implements the SLA negotiation IMHO. But also as this draft says "There does not exist any standard protocol to translate SLA agreements into technical clauses and configurations", this is a technical gap we are facing now.

   RESTCONF protocol.

(3) Table 2:

[Cr] monitoring state (i.e. including monitoring of the resource  network functions usage) would require explicit probes dynamically configure and set up based on new mechanism. At such monitoring state and its configuration is a special and key part of the capability exposure. IMHO such monitoring is a key features which is currently not available - it is a gap.

[Cr] The second paragraph of Sec. 6.1 simply discusses this point. The relevant discussion could be enhanced in next version.

[Cr] Item 12, NS identification is essential for determining/discovering the corresponding network slice for coming flows, OAM operations, etc. ; Item 13, the E2E repository for NS includes the mechanisms for name of NS translations when needed.  The relevant discussion will be enhanced in next version.

Thank you.

Cheers,
Med

De : Netslices [mailto:[email-masked]] De la part de qiangli (D)
Envoyé : vendredi 2 juin 2017 11:36
À : [email-masked]<mailto:[email-masked]>
Objet : [Netslices] draft-qiang-netslices-gap-analysis-00 Uploaded

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: <[email-masked]>
Date: Wed, 7 Jun 2017 12:37:51 +0000

Hi Cristina,

Please see inline.

Cheers,
Med

De : qiangli (D) [mailto:[email-masked]]
Envoyé : mardi 6 juin 2017 08:49
À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
Cc : Susan Hares; 'Alex Galis'
Objet : RE: draft-qiang-netslices-gap-analysis-00 Uploaded

Hi Med,

Best regards,

Cristina QIANG

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, June 02, 2017 9:59 PM
To: qiangli (D); [email-masked]<mailto:[email-masked]>
Subject: RE: draft-qiang-netslices-gap-analysis-00 Uploaded

Hi Cristina,

[Med] Yes, the problem addressed in draft-ietf-idr-sla is worth to be solved... but it is a distinct one vs. negotiation/NSRS.

   RESTCONF protocol.

[Med] It seems that this one is to be yet discussed.

(3) Table 2:

[Cr] monitoring state (i.e. including monitoring of the resource  network functions usage) would require explicit probes dynamically configure and set up based on new mechanism. At such monitoring state and its configuration is a special and key part of the capability exposure. IMHO such monitoring is a key features which is currently not available - it is a gap.
[Med] I hear you, but all this should not be listed as part of the NSRS gap item. My comment was to move this activity to the OAM section.

[Med] OK, thanks.

[Med] What about this one?

[Cr] Item 12, NS identification is essential for determining/discovering the corresponding network slice for coming flows, OAM operations, etc. ;

[Med] Yes, but discovery is discussed in Section 9, not Section 8:

   o  Ability to automatically discover the underlying service functions
      and the slices they are involved in or they belong to.

The table should be consistent with the core text. Thanks.

Item 13, the E2E repository for NS includes the mechanisms for name of NS translations when needed.

[Med] Not sure to get the point, especially I don't understand what you meant by "name of NS translations"

The relevant discussion will be enhanced in next version.

[Med] OK, thanks.

Thank you.

Cheers,
Med

Dear All,

Abstract:

   in network slicing.

Best regards,

Co-authors

---

From: Greg Mirsky <[email-masked]>
Date: Fri, 9 Jun 2017 11:15:40 -0700

Dear Authors, et. al,
thank you for your dedicated work. I believe that this is very much need
document. I have some comments to OAM section:

   - it will be helpful to give interpretation of OAM per RFC 6921 in the
   Introduction section rather than hold it off till Section 9;
   - opening of the Section 9 lists mix of requirements and use cases. I
   agree that these are needed to help us to identify the gaps between what is
   available and what is required of OAM protocols. In Overlay OAM DT we've
   started with the requirements document
   <https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-02> and
   then worked through the gap analysis
   <https://tools.ietf.org/html/draft-ooamdt-rtgwg-oam-gap-analysis-02>. I
   think that these documents may be used in discussing OAM;
   - in addition to [I-D.ooamdt-rtgwg-ooam-header] that proposes Overlay
   Associated Channel there's Overlay Echo Request/Reply
   <https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-03> draft
   that may be of use and re-use.

Regards,
Greg

---

From: Alex Galis <[email-masked]>
Date: Sat, 10 Jun 2017 12:39:08 +0100

Dear Greg,

Thank you for your valuable comments and review which would be accommodated in the revised version "draft-qiang-netslices-gap-analysis-01” planed before IETF99

Best Regards
Alex 
> On 9 Jun 2017, at 19:15, Greg Mirsky <[email-masked]> wrote:
> 
> Dear Authors, et. al,
> thank you for your dedicated work. I believe that this is very much need document. I have some comments to OAM section:
> it will be helpful to give interpretation of OAM per RFC 6921 in the Introduction section rather than hold it off till Section 9;
> opening of the Section 9 lists mix of requirements and use cases. I agree that these are needed to help us to identify the gaps between what is available and what is required of OAM protocols. In Overlay OAM DT we've started with the requirements document <https://tools.ietf.org/html/draft-ooamdt-rtgwg-ooam-requirement-02> and then worked through the gap analysis <https://tools.ietf.org/html/draft-ooamdt-rtgwg-oam-gap-analysis-02>. I think that these documents may be used in discussing OAM;
> in addition to [I-D.ooamdt-rtgwg-ooam-header] that proposes Overlay Associated Channel there's Overlay Echo Request/Reply <https://tools.ietf.org/html/draft-ooamdt-rtgwg-demand-cc-cv-03> draft that may be of use and re-use.
> Regards,
> Greg
> 
> On Fri, Jun 2, 2017 at 2:36 AM, qiangli (D) <[email-masked] <mailto:[email-masked]>> wrote:
> Dear All,
> 
>  
>