Subject: Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

From: Linda Dunbar <[email-masked]>
Date: Tue, 3 Jan 2017 13:26:55 +0000

I support WG Adoption of https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt

But I don’t support the detailed mechanism described in https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt to be adopted. I think the approaches described are too complicated for the egress nodes.

Linda Dunbar

From: OPSAWG [mailto:[email-masked]] On Behalf Of Ram Krishnan
Sent: 2016年12月30日 6:41
To: Zhoutianran <[email-masked]>; [email-masked]
Subject: Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Hi Tianran,
I can see the new draft playing predominantly a complementary role. I have summarized some of the key areas and also added comments, please see below.

1)       https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
-        Complementary role of new draft:
o   Minimizing of In-band Telemetry Header for a specific use case such as latency measurement
o   Data export options
§  Summarizing monitoring information to build a scalable solution – for example, alert the central management system only when 99th percentile queue depth exceeds a high threshold for a flow
§  Flow mirroring
o   Service chaining use case (independent and coupled with underlay/overlay) – describes how network monitoring can help in identifying server side issues and pave the way to dynamic resource orchestration to remedy the issue

2)       https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
-        Complementary role of new draft:
o   Minimizing of In-band Telemetry Header format
o   Data export options format

-   Comments on above draft:

o   I am surprised to see http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf not being referenced.

3)       https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01

-   Comments on above draft:

o   The above id focusses on injected probe packets. The new draft is applicable to all packets including injected probe packets.

4)       Mapping in-band telemetry to different transport protocols – new contribution (this could be a separate draft or might be input to be above drafts)
o   Complementary role of new draft:
§  IPSEC use case for WAN and DC (beyond internet connectivity) and mapping
§  VXLAN-GPE/Geneve/NSH mapping

5)       https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt

-   Comments on above draft:

o   One of the key reasons for packets following a path different from a traffic engineered/service chain path is misconfiguration. With that background,

§  With an administrative domain, practical service verification scheme(s) (https://datatracker.ietf.org/doc/draft-irtf-nfvrg-service-verification/?include_text=) could suffice

§  The elaborate proof of transit scheme suggested in this draft is possibly applicable across administrative domains where it may not be possible to mandate service verification. Additionally, when the path is changed dynamically based on intermediate node state it is not clear how this scheme will work.

Thanks,
Ramki

From: Zhoutianran [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, December 25, 2016 10:57 PM
To: ram krishnan <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Hi Ramki,

Thanks for bringing a new I-D to this WG.
Could you please state the relationship or potential overlay with the In Situ OAM serial I-Ds and also (https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01)?

Best,
Tianran

From: OPSAWG [mailto:[email-masked]] On Behalf Of ram krishnan
Sent: Saturday, December 24, 2016 7:09 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

I support adoption of these drafts.

In addition, I would like bring a closely related draft to your attention -- https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1

This draft brings some important contributions in the area of requirements and data formats for

-          IPSEC tunneling

-          Pre-construction/minimizing of Telemetry header

-          Service chaining – benefits beyond the network interconnect

I was hoping to get this draft out by Seoul timeframe and make it in person, unfortunately couldn’t. Looking forward to discussions and collaboration on this interesting topic.

Thanks,
Ramki

---------- Forwarded message ----------
From: ram krishnan <[email-masked]<mailto:[email-masked]>>
Date: Fri, Dec 23, 2016 at 1:59 PM
Subject: FW: [OPSAWG] WG adoption poll for In-Situ OAM drafts
To: Ram Krishnan <[email-masked]<mailto:[email-masked]>>

 On 12/7/16 01:36, Zhoutianran wrote:

Hi All,

In Seoul, we got enough interest on the In Situ OAM work and positive

response on related drafts.

So this email starts a formal poll for adoption the following I-Ds.

​​<https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt>

https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt

https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt

https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt

To be efficient, we have the poll for three I-Ds in one thread. But you

can give your opinion on each of them. And the result is per I-D.

The question is:

Do you think that the WG should adopt all or some of these drafts?

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

--
Thanks,
Ramki

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 3 Jan 2017 13:43:17 +0000

Hi Linda,

thanks for supporting https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt.

On https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt: Could you elaborate a bit more why you believe that the approach would be too complicated for the egress node? All it takes for the verifier node is to perform a “(Secret + RND) mod prime” operation and compare this to the CML number received in the packet (RND and CML are the two numbers carried within the packet).

Thanks, Frank

From: OPSAWG [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Dienstag, 3. Januar 2017 14:27
To: Ram Krishnan <[email-masked]>; Zhoutianran <[email-masked]>; [email-masked]
Subject: Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Linda Dunbar

From: OPSAWG [mailto:[email-masked]] On Behalf Of Ram Krishnan
Sent: 2016年12月30日 6:41
To: Zhoutianran <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Hi Tianran,

Thanks,
Ramki

Hi Ramki,

Best,
Tianran

-          IPSEC tunneling

Thanks,
Ramki

---------- Forwarded message ----------
From: ram krishnan <[email-masked]<mailto:[email-masked]>>
Date: Fri, Dec 23, 2016 at 1:59 PM
Subject: FW: [OPSAWG] WG adoption poll for In-Situ OAM drafts
To: Ram Krishnan <[email-masked]<mailto:[email-masked]>>

Hi All,

The question is:

--
Thanks,
Ramki

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 10 Jan 2017 17:52:38 +0000

Frank,

Your suggested approach requires egress node to do the computation of “(Secret +RND) mod prime” and perform the comparison for every packet. For a node with hundreds of ports and each with 10G-100G capacity, the computation & comparison would be very heavy.

Linda

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: 2017年1月3日 7:43
To: Linda Dunbar <[email-masked]>; Ram Krishnan <[email-masked]>; Zhoutianran <[email-masked]>; [email-masked]
Subject: RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Hi Linda,

Thanks, Frank

From: OPSAWG [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Dienstag, 3. Januar 2017 14:27
To: Ram Krishnan <[email-masked]<mailto:[email-masked]>>; Zhoutianran <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Linda Dunbar

Hi Tianran,

Thanks,
Ramki

Hi Ramki,

Best,
Tianran

-          IPSEC tunneling

Thanks,
Ramki

---------- Forwarded message ----------
From: ram krishnan <[email-masked]<mailto:[email-masked]>>
Date: Fri, Dec 23, 2016 at 1:59 PM
Subject: FW: [OPSAWG] WG adoption poll for In-Situ OAM drafts
To: Ram Krishnan <[email-masked]<mailto:[email-masked]>>

Hi All,

The question is:

--
Thanks,
Ramki

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jan 2017 19:10:24 +0000

I share that concern.

I think that for this to fly, there needs to be a hardware friendly version.

It also seems to me that lots of applications would be satisfied with an 
approach that assumes that all routers are honest, perhaps simply 
setting a bit in a bit field, reserving the ultra-cautious check for 
special faults or special operating environments.

Stewart

On 10/01/2017 17:52, Linda Dunbar wrote:
>
> Frank,
>
> Your suggested approach requires egress node to do the computation of 
> “(Secret +RND) mod prime” and perform the comparison for every packet. 
> For a node with hundreds of ports and each with 10G-100G capacity, the 
> computation & comparison would be very heavy.
>
> Linda
>
> *From:*Frank Brockners (fbrockne) [mailto:[email-masked]]
> *Sent:* 2017年1月3日7:43
> *To:* Linda Dunbar <[email-masked]>; Ram Krishnan 
> <[email-masked]>; Zhoutianran <[email-masked]>; 
> [email-masked]
> *Subject:* RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
>
> Hi Linda,
>
> thanks for supporting 
> https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt.
>
> On 
> https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt: 
> Could you elaborate a bit more why you believe that the approach would 
> be too complicated for the egress node? All it takes for the verifier 
> node is to perform a “(Secret + RND) mod prime” operation and compare 
> this to the CML number received in the packet (RND and CML are the two 
> numbers carried within the packet).
>
> Thanks, Frank
>
> *From:*OPSAWG [mailto:[email-masked]] *On Behalf Of *Linda Dunbar
> *Sent:* Dienstag, 3. Januar 2017 14:27
> *To:* Ram Krishnan <[email-masked] <mailto:[email-masked]>>; 
> Zhoutianran <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
>
> I support WG Adoption of 
> But I don’t support the detailed mechanism described in 
> https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txtto 
> be adopted. I think the approaches described are too complicated for 
> the egress nodes.
> Linda Dunbar
>
> *From:*OPSAWG [mailto:[email-masked]] *On Behalf Of *Ram Krishnan
> *Sent:* 2016年12月30日6:41
> *To:* Zhoutianran <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
>
> Hi Tianran,
>
> I can see the new draft playing predominantly a complementary role. I 
> have summarized some of the key areas and also added comments, please 
> see below.
>
> 1)https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt 
>
>
> -Complementary role of new draft:
>
> oMinimizing of In-band Telemetry Header for a specific use case such 
> as latency measurement
>
> oData export options
>
> §Summarizing monitoring information to build a scalable solution – for 
> example, alert the central management system only when 99^th 
> percentile queue depth exceeds a high threshold for a flow
>
> §Flow mirroring
>
> oService chaining use case (independent and coupled with 
> underlay/overlay) – describes how network monitoring can help in 
> identifying server side issues and pave the way to dynamic resource 
> orchestration to remedy the issue
>
> 2)https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
>
> -Complementary role of new draft:
>
> oMinimizing of In-band Telemetry Header format
>
> oData export options format
>
> -Comments on above draft:
> oI am surprised to see 
> http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf not 
> being referenced.
> 3)https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01
> -Comments on above draft:
> oThe above id focusses on injected probe packets. The new draft is 
> applicable to all packets including injected probe packets.
> 4)Mapping in-band telemetry to different transport protocols – new 
> contribution (this could be a separate draft or might be input to be 
> above drafts)
>
> oComplementary role of new draft:
>
> §IPSEC use case for WAN and DC (beyond internet connectivity) and mapping
>
> §VXLAN-GPE/Geneve/NSH mapping
>
> 5)https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt
> -Comments on above draft:
> oOne of the key reasons for packets following a path different from a 
> traffic engineered/service chain path is misconfiguration. With that 
> background,
> §With an administrative domain, practical service verification 
> scheme(s) 
> (https://datatracker.ietf.org/doc/draft-irtf-nfvrg-service-verification/?include_text=) 
> could suffice
> §The elaborate proof of transit scheme suggested in this draft is 
> possibly applicable across administrative domains where it may not be 
> possible to mandate service verification. Additionally, when the path 
> is changed dynamically based on intermediate node state it is not 
> clear how this scheme will work.
>
> Thanks,
>
> Ramki
>
> *From:*Zhoutianran [mailto:[email-masked] 
> <mailto:[email-masked]>]
> *Sent:* Sunday, December 25, 2016 10:57 PM
> *To:* ram krishnan <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
> *Subj**ect:*RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
>
> Hi Ramki,
>
> Could you please state the relationship or potential overlay with the 
> In Situ OAM serial I-Ds and also 
> (https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01)?
>
> Best,
>
> Tianran
>
> *From:*OPSAWG [mailto:[email-masked]] *On Behalf Of *ram krishnan
> *Sent:* Saturday, December 24, 2016 7:09 PM
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
>
> In addition, I would like bring a closely related draft to your 
> attention -- 
> https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1
>
> -IPSEC tunneling
> -Pre-construction/minimizing of Telemetry header
>
> -Service chaining – benefits beyond the network interconnect
>
> I was hoping to get this draft out by Seoul timeframe and make it in 
> person, unfortunately couldn’t. Looking forward to discussions and 
> collaboration on this interesting topic.
>
> Thanks,
>
> Ramki
>
> From: *ram krishnan* <[email-masked] <mailto:[email-masked]>>
> To: Ram Krishnan <[email-masked] <mailto:[email-masked]>>
>
>     ​​
>     <https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt>
>
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
>
> -- 
>
> Thanks,
>
> Ramki
>
>
>
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Frank Brockners (fbrockne)" <[email-masked]>
Date: Tue, 10 Jan 2017 19:19:16 +0000

We probably need to differentiate things based on the use case, i.e.

1) *prove* in a secure way that a packet visited a particular set of nodes
2) *provide some hint* (e.g. to help operations) whether a packet visited a particular set of nodes

The POT mechanism in draft-brockners-proof-of-transit-02.txt is very much targeted at 1) – and the target box to perform these mechanisms is probably more like a firewall or similar, which would have the capabilities to do a bunch of operations on a packet – and differ from a core/backbone router.

Frank

From: OPSAWG [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: Dienstag, 10. Januar 2017 20:10
To: [email-masked]
Subject: Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

I share that concern.

It also seems to me that lots of applications would be satisfied with an approach that assumes that all routers are honest, perhaps simply setting a bit in a bit field, reserving the ultra-cautious check for special faults or special operating environments.

Stewart

Linda

From: Frank Brockners (fbrockne) [mailto:[email-masked]]
Sent: 2017年1月3日 7:43
To: Linda Dunbar <[email-masked]><mailto:[email-masked]>; Ram Krishnan <[email-masked]><mailto:[email-masked]>; Zhoutianran <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

Hi Linda,

Thanks, Frank

Linda Dunbar

Hi Tianran,

Thanks,
Ramki

Hi Ramki,

Best,
Tianran

-          IPSEC tunneling

Thanks,
Ramki

---------- Forwarded message ----------
From: ram krishnan <[email-masked]<mailto:[email-masked]>>
Date: Fri, Dec 23, 2016 at 1:59 PM
Subject: FW: [OPSAWG] WG adoption poll for In-Situ OAM drafts
To: Ram Krishnan <[email-masked]<mailto:[email-masked]>>

Hi All,

The question is:

--
Thanks,
Ramki

OPSAWG mailing list

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 10 Jan 2017 19:21:41 +0000

I can see the utility in that case, but I think that we need to set that 
expectation with the reader of the text.

Stewart

On 10/01/2017 19:19, Frank Brockners (fbrockne) wrote:
> The POT mechanism in draft-brockners-proof-of-transit-02.txt is very 
> much targeted at 1) – and the target box to perform these mechanisms 
> is probably more like a firewall or similar, which would have the 
> capabilities to do a bunch of operations on a packet – and differ from 
> a core/backbone router.
>
> Frank
>
> *From:*OPSAWG [mailto:[email-masked]] *On Behalf Of *Stewart 
> Bryant
> *Sent:* Dienstag, 10. Januar 2017 20:10
> *To:* [email-masked]
> It also seems to me that lots of applications would be satisfied with 
> an approach that assumes that all routers are honest, perhaps simply 
>     Your suggested approach requires egress node to do the computation
>     of “(Secret +RND) mod prime” and perform the comparison for every
>     packet. For a node with hundreds of ports and each with 10G-100G
>     capacity, the computation & comparison would be very heavy.
>
>     Linda
>
>     *To:* Linda Dunbar <[email-masked]>
>     <mailto:[email-masked]>; Ram Krishnan
>     <[email-masked]> <mailto:[email-masked]>; Zhoutianran
>     <[email-masked]> <mailto:[email-masked]>;
>     Could you elaborate a bit more why you believe that the approach
>     would be too complicated for the egress node? All it takes for the
>     verifier node is to perform a “(Secret + RND) mod prime” operation
>     and compare this to the CML number received in the packet (RND and
>     CML are the two numbers carried within the packet).
>
>     Thanks, Frank
>
>     *To:* Ram Krishnan <[email-masked]
>     <mailto:[email-masked]>>; Zhoutianran <[email-masked]
>     be adopted. I think the approaches described are too complicated
>     for the egress nodes.
>
>     Linda Dunbar
>
>     I can see the new draft playing predominantly a complementary
>     role. I have summarized some of the key areas and also added
>     comments, please see below.
>
>     oMinimizing of In-band Telemetry Header for a specific use case
>     such as latency measurement
>
>     oData export options
>
>     §Summarizing monitoring information to build a scalable solution –
>     for example, alert the central management system only when 99^th
>     identifying server side issues and pave the way to dynamic
>     resource orchestration to remedy the issue
>
>     http://p4.org/wp-content/uploads/fixed/INT/INT-current-spec.pdf
>     not being referenced.
>
>     contribution (this could be a separate draft or might be input to
>     be above drafts)
>
>     oOne of the key reasons for packets following a path different
>     from a traffic engineered/service chain path is misconfiguration.
>     With that background,
>
>     possibly applicable across administrative domains where it may not
>     be possible to mandate service verification. Additionally, when
>     the path is changed dynamically based on intermediate node state
>     it is not clear how this scheme will work.
>
>     Thanks,
>
>     Ramki
>
>     *To:* ram krishnan <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]>
>     Could you please state the relationship or potential overlay with
>     the In Situ OAM serial I-Ds and also
>     I was hoping to get this draft out by Seoul timeframe and make it
>     in person, unfortunately couldn’t. Looking forward to discussions
>     and collaboration on this interesting topic.
>
>     Thanks,
>
>     Ramki
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 Jan 2017 20:31:26 -0000

Frank,
You probably used short-hand, but I think you mean "visited a particular set of nodes in a particular order".
 
I agree with Stewart where we can make reasonable assumptions about trust domains (e.g. where a breach in the trust domain is going to allow far worse things to happen). But I am not sure that SFC is within that environment, and I understood this work to be targeted at the path a packet might follow in *any* application space.
 
*And* I agree with Linda that we need to be careful to avoid making the solution too complicated (a way to address that might be to not try to do so much with one solution), and definitely avoid burdening platforms with per packet processing if they lack the capabilities to handle it at the required speed. I think that needs some more thought, however, given the availability of accelerators etc., etc.
 
Adrian
 
From: OPSAWG [mailto:[email-masked]] On Behalf Of Frank Brockners (fbrockne)
Sent: 10 January 2017 19:19
To: Stewart Bryant; [email-masked]
Subject: Re: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

 
 
Frank

I share that concern.

 
Linda
 
From: Frank Brockners (fbrockne) [mailto:[email-masked]] 
Sent: 2017年1月3日 7:43
To: Linda Dunbar  <mailto:[email-masked]> <[email-masked]>; Ram Krishnan  <mailto:[email-masked]> <[email-masked]>; Zhoutianran  <mailto:[email-masked]> <[email-masked]>; [email-masked]
Subject: RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
 
Hi Linda,

 
Thanks, Frank

 
Linda Dunbar

Hi Tianran,

 

 
 
Thanks,
Ramki
 
From: Zhoutianran [mailto:[email-masked]] 
Sent: Sunday, December 25, 2016 10:57 PM
To: ram krishnan <[email-masked]>; [email-masked]
Subject: RE: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts
 
Hi Ramki,
 
Thanks for bringing a new I-D to this WG.
Could you please state the relationship or potential overlay with the In Situ OAM serial I-Ds and also ( <https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01> https://tools.ietf.org/html/draft-lapukhov-dataplane-probe-01)?
 
Best,
Tianran
 
From: OPSAWG [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of ram krishnan
Sent: Saturday, December 24, 2016 7:09 PM
To:  <mailto:[email-masked]> [email-masked]
Subject: [OPSAWG] FW: FW: WG adoption poll for In-Situ OAM drafts

In addition, I would like bring a closely related draft to your attention --  <https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1> https://datatracker.ietf.org/doc/draft-krishnan-opsawg-in-band-pro-sla/?include_text=1

 
Thanks,
Ramki
 
---------- Forwarded message ----------
From: ram krishnan <[email-masked]>
Date: Fri, Dec 23, 2016 at 1:59 PM
Subject: FW: [OPSAWG] WG adoption poll for In-Situ OAM drafts
To: Ram Krishnan <[email-masked]>

 

 <https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt> ​​
https://tools.ietf.org/html/draft-brockners-inband-oam-requirements-02.txt
https://tools.ietf.org/html/draft-brockners-inband-oam-data-02.txt
https://tools.ietf.org/html/draft-brockners-proof-of-transit-02.txt

 
The question is:

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is 
believed to be clean. 

-- 
Thanks, 
Ramki