Re: [spring] [ippm] Active OAM in SRv6

[Tianran Zhou]

Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport 
layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

Best,
Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song 
Cc: spring@ietf.org; IETF IPPM WG 
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the 
concept of Active IOAM is introduced in the IPPM WG 
draft it 
seems to me like adding the IPPM WG community to the discussion is the right 
thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi SPRING WG,

Real time monitor on every node and every link on a network is necessary to 
detect  gray failures, which are the key culprit for poor QoS but hard to 
catch. SR provides an ideal mechanism, when working with some efficient 
planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ 
Active Measurement (SIAM) suggests a simple  active measurement approach which 
can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, 
e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It 
appears to me that, for example, STAMP and its extensions, including the SRPM 
draft, 
comprehensively address the PM OAM requirements for SRv6.
options of IOAM and other OAM methods in SRv6, without needing to worry about 
the extension header issue.
GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
   In terms of the classification given
   in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
Does your proposal change that?

Your comments, questions, and suggestions are very welcome. I’d like to know 
your opinion if you think this work is in scope and should be adopted by the 
working group.  If you are interested in contributing to this work, please also 
let me know. https://datatracker.ietf.org/doc/draft-song-spring-siam/

Thank you very much!

Best regards,
Haoyu
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [ippm] Active OAM in SRv6

[Gyan Mishra]

Hi Haoyu

I think it would be good to identify the problem statement and gap with
existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be
utilized or fall short in what you are trying to achieve with Active OAM in
SRv6.

In-situ IOAM data packets is already possible with SRv6 as mentioned as
this draft mentions below as normative reference.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16

This draft as well mentioned as normative reference draft below provides
OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list
tracing capabilities very handy for troubleshooting.

https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1
3

This draft as well also mentioned as normative reference draft below
provides in-situ IOAM for OAM and PM information can be piggybacked in data
packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational
and telemetry info in the data packets.

https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05



Thanks

Gyan

On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou  wrote:

> Hi Haoyu,
>
>
>
> The application is really interesting and useful.
>
> I am not sure if it is necessary to create a new OAM protocol at transport
> layer.
>
> IMHO, a per hop/per segment extension based on STAMP could be more
> practical.
>
> https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt
>
>
>
> Best,
>
> Tianran
>
>
>
> *From:* ippm [mailto:ippm-boun...@ietf.org] *On Behalf Of *Greg Mirsky
> *Sent:* Thursday, January 27, 2022 7:01 AM
> *To:* Haoyu Song 
> *Cc:* spring@ietf.org; IETF IPPM WG 
> *Subject:* Re: [ippm] [spring] Active OAM in SRv6
>
>
>
> Hi Haoyu,
>
> thank you for bringing the topic of Active OAM to the discussion. As the
> concept of Active IOAM is introduced in the IPPM WG draft
>  it
> seems to me like adding the IPPM WG community to the discussion is the
> right thing to do.
>
> Please find my notes in-lined below under the GIM>> tag.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song 
> wrote:
>
> Hi SPRING WG,
>
>
>
> Real time monitor on every node and every link on a network is necessary
> to detect  gray failures, which are the key culprit for poor QoS but hard
> to catch. SR provides an ideal mechanism, when working with some efficient
> planning algorithm, to achieve that with low cost.   Our proposal SRv6
> In-situ Active Measurement (SIAM) suggests a simple  active measurement
> approach which can support different
>
> GIM>> I wonder what gaps you find in the existing active measurement
> protocols, e.g., STAMP and RFC 6734 (would be more convenient to use an
> acronym). It appears to me that, for example, STAMP and its extensions,
> including the SRPM draft
> ,
> comprehensively address the PM OAM requirements for SRv6.
>
> options of IOAM and other OAM methods in SRv6, without needing to worry
> about the extension header issue.
>
> GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
>
>In terms of the classification given
>
>in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
>
> Does your proposal change that?
>
>
>
> Your comments, questions, and suggestions are very welcome. I’d like to
> know your opinion if you think this work is in scope and should be adopted
> by the working group.  If you are interested in contributing to this work,
> please also let me know.
> https://datatracker.ietf.org/doc/draft-song-spring-siam/
>
>
>
> Thank you very much!
>
>
>
> Best regards,
>
> Haoyu
>
> ___
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> ___
> ippm mailing list
> i...@ietf.org
> https://www.ietf.org/mailman/listinfo/ippm
>
-- 



*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mis...@verizon.com *



*M 301 502-1347*
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [ippm] Active OAM in SRv6

[Haoyu Song]

Hi Gyan,

Thank you for your comments! Please see inline for response marked with [HS]

Best,
Haoyu

From: Gyan Mishra 
Sent: Wednesday, January 26, 2022 9:03 PM
To: Tianran Zhou 
Cc: Greg Mirsky ; Haoyu Song ; 
IETF IPPM WG ; spring@ietf.org
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

I think it would be good to identify the problem statement and gap with 
existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be utilized 
or fall short in what you are trying to achieve with Active OAM in SRv6.

[HS] My understanding is that STAMP/TWAMP are for end-to-end measurements, here 
we want to collect data from every node and every link on any path, without 
needing to set up any sessions. So the scope and coverage are different.

In-situ IOAM data packets is already possible with SRv6 as mentioned as this 
draft mentions below as normative reference.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16

[HS] There's no accepted solution on how to support IOAM in SRv6 yet. Our 
proposal aims to provide such a solution, and (1) the solution avoids the 
issues on encapsulating the IOAM trace in EHs and (2) it's extensible to 
include OAM methods beyond IOAM.

This draft as well mentioned as normative reference draft below provides OAM 
ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list tracing 
capabilities very handy for troubleshooting.

https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-13

[HS] This is for in-band OAM for SRv6 user traffic and it only works for 
triggering postcard exports (i.e., don't allow the packet to carry data). Our 
proposal support all the IOAM options and more important, it's an active method 
which means one can generate and inject probing packets to cover arbitrary 
paths by crafting an SRH.

This draft as well also mentioned as normative reference draft below provides 
in-situ IOAM for OAM and PM information can be piggybacked in data packets in 
SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and telemetry 
info in the data packets.

https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05

[HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the overhead 
concern (IOAM trace could be large) and other issues related to EH, I don't 
support such a solution.

[HS] The three drafts you mentioned are all be reference in our draft and 
discussed. We think our use cases are different and our approach is more 
general and extensible to our use cases.

Thanks

Gyan

On Wed, Jan 26, 2022 at 10:19 PM Tianran Zhou 
mailto:40huawei@dmarc.ietf.org>> 
wrote:
Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport 
layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

Best,
Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On 
Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Re:

Re: [spring] [ippm] Active OAM in SRv6

[Haoyu Song]

Hi Tianran,

We didn't invent any new protocol but to simply use UDP for the probing packets 
in SRv6.
What we want to avoid is SRH TLV in EH which can significantly increase the EH 
overhead because the data needed to be carried may be too large.
Also, since IOAM options have been well defined, it's unnecessary to augment 
the other existing protocols to provide similar functionality. We just need a 
way to encapsulate them.

Best,
Haoyu

From: Tianran Zhou 
Sent: Wednesday, January 26, 2022 7:19 PM
To: Greg Mirsky ; Haoyu Song 
Cc: spring@ietf.org; IETF IPPM WG 
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport 
layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

Best,
Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the 
concept of Active IOAM is introduced in the IPPM WG 
draft
 it seems to me like adding the IPPM WG community to the discussion is the 
right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi SPRING WG,

Real time monitor on every node and every link on a network is necessary to 
detect  gray failures, which are the key culprit for poor QoS but hard to 
catch. SR provides an ideal mechanism, when working with some efficient 
planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ 
Active Measurement (SIAM) suggests a simple  active measurement approach which 
can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, 
e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It 
appears to me that, for example, STAMP and its extensions, including the SRPM 
draft,
 comprehensively address the PM OAM requirements for SRv6.
options of IOAM and other OAM methods in SRv6, without needing to worry about 
the extension header issue.
GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
   In terms of the classification given
   in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
Does your proposal change that?

Your comments, questions, and suggestions are very welcome. I'd like to know 
your opinion if you think this work is in scope and should be adopted by the 
working group.  If you are interested in contributing to this work, please also 
let me know. 
https://datatracker.ietf.org/doc/draft-song-spring-siam/

Thank you very much!

Best regards,
Haoyu
___
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

Re: [spring] [ippm] Active OAM in SRv6

[Tianran Zhou]

Hi Haoyu,

I agree with Greg. I think IOAM with existing OAM protocol can address your 
case.
Again, I can show you some more details on your motivation.
(1) it’s session-less and we don’t need assign any roles (e.g.,  reflector);
ZTR> I am not sure if I understand what the “session-less” mean.
But I think in your application, the sender should keep the session state, 
right?
Reflector is not always required. OWAMP is one way, so no reflector. STAMP, 
IMHO, could also be one way.
In RFC8762, STAMP “enables the measurement of both one-way and round-trip 
performance metrics”.

(2) no needs for a return path. The measurement can start and end at any node 
(solely determined by the SRH);
ZTR> This is achieved by SRH, you did not create anything on OAM after UDP. So 
this applies for any one way OAM protocol.
On the other hand, many measurement need two ways (e.g., delay). Even data 
collections need two ways, because the forward and backward are totally 
different two paths.
Of cause, you can use one way protocol to travel both way.
Two way need a reflector, but will also reduce a lot of resources. For example 
the length of the SID list.

(3) udp-based which can support any existing IOAM modes and potentially other 
OAM methods.
ZTR> STAMP is UDP based.

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, January 28, 2022 6:01 AM
To: Haoyu Song 
Cc: spring@ietf.org; IETF IPPM WG 
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for your detailed reply. Please find my follow-up notes in-lined 
below under the GIM2>> tag.

Regards,
Greg

On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi Greg,

Thank you for your questions. Please see inline response.

Best,
Haoyu

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Sent: Wednesday, January 26, 2022 3:01 PM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Re: [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the 
concept of Active IOAM is introduced in the IPPM WG 
draft
 it seems to me like adding the IPPM WG community to the discussion is the 
right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi SPRING WG,

Real time monitor on every node and every link on a network is necessary to 
detect  gray failures, which are the key culprit for poor QoS but hard to 
catch. SR provides an ideal mechanism, when working with some efficient 
planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ 
Active Measurement (SIAM) suggests a simple  active measurement approach which 
can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, 
e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It 
appears to me that, for example, STAMP and its extensions, including the SRPM 
draft,
 comprehensively address the PM OAM requirements for SRv6.

HS>> Let’s give a few features of our proposal: (1) it’s session-less and we 
don’t need assign any roles (e.g.,  reflector); (2) no needs for a return path. 
The measurement can start and end at any node (solely determined by the SRH); 
(3) udp-based which can support any existing IOAM modes and potentially other 
OAM methods.
GIM2>> I don't think adding a protocol that can generate a test probe from an 
arbitrary node to arbitrary targets (SRv6 supports multicast) is as simple as 
you present. If an operator needs to monitor the performance of the SR policy 
used by data packets, IOAM can be applied to data packets. If the operator 
wants to explore a policy that is not used for data traffic, I imagine IOAM can 
be added to a test packet of the existing OAM protocol, e.g., ICMP. Am I 
missing some of the requirements?
options of IOAM and other OAM methods in SRv6, without needing to worry about 
the extension header issue.
GIM>> draft-ietf-ippm-ioam-data

Re: [spring] [ippm] Active OAM in SRv6

[Tianran Zhou]

Hi Haoyu,

I do not understand why the UDP encapsulation is better than SRH TLV.
IMO, IOAM is already too complex, some more work on TLV parsing is not critical.
If you care about the data length "because the data needed to be carried may be 
too large", what's the limit on SRH TLV?
What's your use case, and your requirement? Let's evaluate it with numbers.

Best,
Tianran

From: Haoyu Song [mailto:haoyu.s...@futurewei.com]
Sent: Friday, January 28, 2022 2:50 AM
To: Tianran Zhou ; Greg Mirsky 
Cc: spring@ietf.org; IETF IPPM WG 
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Tianran,

We didn't invent any new protocol but to simply use UDP for the probing packets 
in SRv6.
What we want to avoid is SRH TLV in EH which can significantly increase the EH 
overhead because the data needed to be carried may be too large.
Also, since IOAM options have been well defined, it's unnecessary to augment 
the other existing protocols to provide similar functionality. We just need a 
way to encapsulate them.

Best,
Haoyu

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Wednesday, January 26, 2022 7:19 PM
To: Greg Mirsky mailto:gregimir...@gmail.com>>; Haoyu 
Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport 
layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

Best,
Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the 
concept of Active IOAM is introduced in the IPPM WG 
draft
 it seems to me like adding the IPPM WG community to the discussion is the 
right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi SPRING WG,

Real time monitor on every node and every link on a network is necessary to 
detect  gray failures, which are the key culprit for poor QoS but hard to 
catch. SR provides an ideal mechanism, when working with some efficient 
planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ 
Active Measurement (SIAM) suggests a simple  active measurement approach which 
can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, 
e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It 
appears to me that, for example, STAMP and its extensions, including the SRPM 
draft,
 comprehensively address the PM OAM requirements for SRv6.
options of IOAM and other OAM methods in SRv6, without needing to worry about 
the extension header issue.
GIM>> draft-ietf-ippm-ioam-data classifies IOAM as follows:
   In terms of the classification given
   in [RFC7799] IOAM could be portrayed as Hybrid Type 1.
Does your proposal change that?

Your comments, questions, and suggestions are very welcome. I'd like to know 
your opinion if you think this work is in scope and should be adopted by the 
working group.  If you are interested in contributing to this work, please also 
let me know. 
https://datatracker.ietf.org/doc/draft-song-spring-siam/

Re: [spring] [ippm] Active OAM in SRv6

[Haoyu Song]

Hi Tianran,

The use case I target  is to generate probing packets to collect node/link data 
on arbitrary path. We have algorithms to generate such packets on a few path to 
cover the entire network (reference is given in the draft). If we periodically 
do such measurements, we can gain the visibility of the whole network and 
detect the gray failures, which can have countless  useful applications.

Why using UDP rather than EH TLV? here's some of my thoughts. First, I don't 
need to do it in user packets, so essentially the payload is free to use.
Second, there are a lot of discussions and debates on the size/location of the 
IPv6 EHs, and there are so many proposals want to use the EHs. I don't want to 
add more complexity to it.
Third, the proposal can be extended to support other OAM schemes using the same 
method. Of course, you can also keep introducing new TLV options to EH. But 
again, that's the path I don't want to go.

Best,
Haoyu

From: Tianran Zhou 
Sent: Thursday, January 27, 2022 4:22 PM
To: Haoyu Song ; Greg Mirsky 
Cc: spring@ietf.org; IETF IPPM WG 
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

I do not understand why the UDP encapsulation is better than SRH TLV.
IMO, IOAM is already too complex, some more work on TLV parsing is not critical.
If you care about the data length "because the data needed to be carried may be 
too large", what's the limit on SRH TLV?
What's your use case, and your requirement? Let's evaluate it with numbers.

Best,
Tianran

From: Haoyu Song [mailto:haoyu.s...@futurewei.com]
Sent: Friday, January 28, 2022 2:50 AM
To: Tianran Zhou mailto:zhoutian...@huawei.com>>; Greg 
Mirsky mailto:gregimir...@gmail.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Tianran,

We didn't invent any new protocol but to simply use UDP for the probing packets 
in SRv6.
What we want to avoid is SRH TLV in EH which can significantly increase the EH 
overhead because the data needed to be carried may be too large.
Also, since IOAM options have been well defined, it's unnecessary to augment 
the other existing protocols to provide similar functionality. We just need a 
way to encapsulate them.

Best,
Haoyu

From: Tianran Zhou mailto:zhoutian...@huawei.com>>
Sent: Wednesday, January 26, 2022 7:19 PM
To: Greg Mirsky mailto:gregimir...@gmail.com>>; Haoyu 
Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

The application is really interesting and useful.
I am not sure if it is necessary to create a new OAM protocol at transport 
layer.
IMHO, a per hop/per segment extension based on STAMP could be more practical.
https://www.ietf.org/archive/id/draft-wang-ippm-stamp-hbh-extensions-03.txt

Best,
Tianran

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Thursday, January 27, 2022 7:01 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the 
concept of Active IOAM is introduced in the IPPM WG 
draft
 it seems to me like adding the IPPM WG community to the discussion is the 
right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi SPRING WG,

Real time monitor on every node and every link on a network is necessary to 
detect  gray failures, which are the key culprit for poor QoS but hard to 
catch. SR provides an ideal mechanism, when working with some efficient 
planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ 
Active Measurement (SIAM) suggests a simple  active measurement approach which 
can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, 
e.g., STAMP and RFC 6734 

Re: [spring] [ippm] Active OAM in SRv6

[Haoyu Song]

See inline

-Haoyu

From: Tianran Zhou 
Sent: Thursday, January 27, 2022 3:53 PM
To: Greg Mirsky ; Haoyu Song 
Cc: spring@ietf.org; IETF IPPM WG 
Subject: RE: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,

I agree with Greg. I think IOAM with existing OAM protocol can address your 
case.
Again, I can show you some more details on your motivation.
(1) it's session-less and we don't need assign any roles (e.g.,  reflector);
ZTR> I am not sure if I understand what the "session-less" mean.
But I think in your application, the sender should keep the session state, 
right?
Reflector is not always required. OWAMP is one way, so no reflector. STAMP, 
IMHO, could also be one way.
In RFC8762, STAMP "enables the measurement of both one-way and round-trip 
performance metrics".

HS> It means "stateless". The state could be some identifier kept by the 
network device. Augmenting some existing protocols to cover new function 
require the same amount of work and in many cases, due to the limitations of 
the original protocol, the extensibility is seriously limited. The protocols 
you mentioned were designed for e2e measurement. Each new patch adding to them 
will raise the concern for the standard updates and eventually make the 
protocol itself unwieldy because the new things are beyond the original design 
scope. In other words, having the existing protocol doesn't help here but exert 
unnecessary limitations.

(2) no needs for a return path. The measurement can start and end at any node 
(solely determined by the SRH);
ZTR> This is achieved by SRH, you did not create anything on OAM after UDP. So 
this applies for any one way OAM protocol.
On the other hand, many measurement need two ways (e.g., delay). Even data 
collections need two ways, because the forward and backward are totally 
different two paths.
Of cause, you can use one way protocol to travel both way.
Two way need a reflector, but will also reduce a lot of resources. For example 
the length of the SID list.

HS> Two way can easily be supported by SRH itself (just add the round trip path 
in segment list). There's no need to introduce any other mechanism.

(3) udp-based which can support any existing IOAM modes and potentially other 
OAM methods.
ZTR> STAMP is UDP based.

HS> If so, it can also be supported by our framework. But there's no need to 
force IOAM functions as a part of STAMP. That's like reinventing the wheel.

From: ippm [mailto:ippm-boun...@ietf.org] On Behalf Of Greg Mirsky
Sent: Friday, January 28, 2022 6:01 AM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu,
thank you for your detailed reply. Please find my follow-up notes in-lined 
below under the GIM2>> tag.

Regards,
Greg

On Thu, Jan 27, 2022 at 11:00 AM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi Greg,

Thank you for your questions. Please see inline response.

Best,
Haoyu

From: Greg Mirsky mailto:gregimir...@gmail.com>>
Sent: Wednesday, January 26, 2022 3:01 PM
To: Haoyu Song mailto:haoyu.s...@futurewei.com>>
Cc: spring@ietf.org; IETF IPPM WG 
mailto:i...@ietf.org>>
Subject: Re: [spring] Active OAM in SRv6

Hi Haoyu,
thank you for bringing the topic of Active OAM to the discussion. As the 
concept of Active IOAM is introduced in the IPPM WG 
draft
 it seems to me like adding the IPPM WG community to the discussion is the 
right thing to do.
Please find my notes in-lined below under the GIM>> tag.

Regards,
Greg

On Wed, Jan 26, 2022 at 2:37 PM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi SPRING WG,

Real time monitor on every node and every link on a network is necessary to 
detect  gray failures, which are the key culprit for poor QoS but hard to 
catch. SR provides an ideal mechanism, when working with some efficient 
planning algorithm, to achieve that with low cost.   Our proposal SRv6 In-situ 
Active Measurement (SIAM) suggests a simple  active measurement approach which 
can support different
GIM>> I wonder what gaps you find in the existing active measurement protocols, 
e.g., STAMP and RFC 6734 (would be more convenient to use an acronym). It 
appears to me that, for example, STAMP and its extensions, including the SRPM 
draft

Re: [spring] [ippm] Active OAM in SRv6

[Gyan Mishra]

Hi Haoyu

On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song  wrote:

> Hi Gyan,
>
>
>
> Thank you for your comments! Please see inline for response marked with
> [HS]
>
>
>
> Best,
>
> Haoyu
>
>
>
> *From:* Gyan Mishra 
> *Sent:* Wednesday, January 26, 2022 9:03 PM
> *To:* Tianran Zhou 
> *Cc:* Greg Mirsky ; Haoyu Song <
> haoyu.s...@futurewei.com>; IETF IPPM WG ; spring@ietf.org
> *Subject:* Re: [ippm] [spring] Active OAM in SRv6
>
>
>
> Hi Haoyu
>
>
>
> I think it would be good to identify the problem statement and gap with
> existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be
> utilized or fall short in what you are trying to achieve with Active OAM in
> SRv6.
>
>
>
> [HS] My understanding is that STAMP/TWAMP are for end-to-end measurements,
> here we want to collect data from every node and every link on any path,
> without needing to set up any sessions. So the scope and coverage are
> different.
>
>  Gyan> Understood.  STAMP/TWAMP can be used as well to collect from every
> node as well.
>
> In-situ IOAM data packets is already possible with SRv6 as mentioned as
> this draft mentions below as normative reference.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16
> 
>
>
>
> [HS] There’s no accepted solution on how to support IOAM in SRv6 yet. Our
> proposal aims to provide such a solution, and (1) the solution avoids the
> issues on encapsulating the IOAM trace in EHs and (2) it’s extensible to
> include OAM methods beyond IOAM.
>
>  Gyan> IPPM WG can speak to this document which has been adopted and been
> developed since 2016 and provides in-situ OAM as you desire and supports
> Segment Routing SRv6 as well as other encapsulations.
>
> This draft as well mentioned as normative reference draft below provides
> OAM ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list
> tracing capabilities very handy for troubleshooting.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-1
> 
> 3
>
>
>
> [HS] This is for in-band OAM for SRv6 user traffic and it only works for
> triggering postcard exports (i.e., don’t allow the packet to carry data).
> Our proposal support all the IOAM options and more important, it’s an
> active method which means one can generate and inject probing packets to
> cover arbitrary paths by crafting an SRH.
>
>  Gyan> Understood
>
> This draft as well also mentioned as normative reference draft below
> provides in-situ IOAM for OAM and PM information can be piggybacked in data
> packets in SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational
> and telemetry info in the data packets.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05
> 
>
>
>
> [HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the
> overhead concern (IOAM trace could be large) and other issues related to
> EH, I don’t support such a solution.
>
>  Gyan> Understood.  Work is being done in 6MAN WG to address EH headers
> issues below as well as other drafts to make EH viable and reduce overhead.
>

https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00.txt


[HS] The three drafts you mentioned are all be reference in our draft and
> discussed. We think our use cases are different and our approach is more
> general and extensible to our use cases.
>
> Gyan> Understood.  I think if you can add some additional verbiage as to
> problem statement and why existing solutions drafts mentioned are not
> sufficient for your requirements.  Maybe listing out your requirements
> would help couple to your proposed solution.
>
> Thanks
>
>
>
> Gyan
>
>
>
> On Wed, Jan 26, 2022 at 10:19 PM Tianran Zh

Re: [spring] [ippm] Active OAM in SRv6

[Haoyu Song]

Thanks Gyan!
In the next revision, I'll add more information on the requirements and 
comparisons with the other approaches.

Best,
Haoyu

From: Gyan Mishra 
Sent: Sunday, January 30, 2022 9:41 AM
To: Haoyu Song 
Cc: Greg Mirsky ; IETF IPPM WG ; Tianran 
Zhou ; spring@ietf.org
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

On Thu, Jan 27, 2022 at 1:42 PM Haoyu Song 
mailto:haoyu.s...@futurewei.com>> wrote:
Hi Gyan,

Thank you for your comments! Please see inline for response marked with [HS]

Best,
Haoyu

From: Gyan Mishra mailto:hayabusa...@gmail.com>>
Sent: Wednesday, January 26, 2022 9:03 PM
To: Tianran Zhou 
mailto:40huawei@dmarc.ietf.org>>
Cc: Greg Mirsky mailto:gregimir...@gmail.com>>; Haoyu 
Song mailto:haoyu.s...@futurewei.com>>; IETF IPPM WG 
mailto:i...@ietf.org>>; spring@ietf.org
Subject: Re: [ippm] [spring] Active OAM in SRv6

Hi Haoyu

I think it would be good to identify the problem statement and gap with 
existing IPPM WG STAMP, TWAMP PM technologies and why they cannot be utilized 
or fall short in what you are trying to achieve with Active OAM in SRv6.

[HS] My understanding is that STAMP/TWAMP are for end-to-end measurements, here 
we want to collect data from every node and every link on any path, without 
needing to set up any sessions. So the scope and coverage are different.
 Gyan> Understood.  STAMP/TWAMP can be used as well to collect from every node 
as well.
In-situ IOAM data packets is already possible with SRv6 as mentioned as this 
draft mentions below as normative reference.

https://datatracker.ietf.org/doc/html/draft-ietf-ippm-ioam-data-16

[HS] There's no accepted solution on how to support IOAM in SRv6 yet. Our 
proposal aims to provide such a solution, and (1) the solution avoids the 
issues on encapsulating the IOAM trace in EHs and (2) it's extensible to 
include OAM methods beyond IOAM.
 Gyan> IPPM WG can speak to this document which has been adopted and been 
developed since 2016 and provides in-situ OAM as you desire and supports 
Segment Routing SRv6 as well as other encapsulations.
This draft as well mentioned as normative reference draft below provides OAM 
ping and traceroute with SRH O flag to SRv6 PGM endpoints and SID list tracing 
capabilities very handy for troubleshooting.

https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-13

[HS] This is for in-band OAM for SRv6 user traffic and it only works for 
triggering postcard exports (i.e., don't allow the packet to carry data). Our 
proposal support all the IOAM options and more important, it's an active method 
which means one can generate and inject probing packets to cover arbitrary 
paths by crafting an SRH.
 Gyan> Understood
This draft as well also mentioned as normative reference draft below provides 
in-situ IOAM for OAM and PM information can be piggybacked in data packets in 
SRH TLV SRv6 PGM SIF function SRv6.TLV recording the operational and telemetry 
info in the data packets.

https://datatracker.ietf.org/doc/html/draft-ali-spring-ioam-srv6-05

[HS] This draft proposes to encapsulate IOAM in SRH TLV. Due to the overhead 
concern (IOAM trace could be large) and other issues related to EH, I don't 
support such a solution.
 Gyan> Understood.  Work is being done in 6MAN WG to address EH headers issues 
below as well as other drafts to make EH viable and reduce overhead.

https://datatracker.ietf.org/doc/html/draft-herbert-6man-eh-limits-00.txt