Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

From: Tianran Zhou <[email-masked]>
Date: Mon, 24 Jan 2022 06:23:11 +0000

Hi WG,

We think this is an useful work on adapting OWAMP/TWAMP in LAG performance measurement.
We updated this draft based on the comments from the meeting discussion and mailing list.
Thanks for all the suggestions.
More reviews and comments are welcome.

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>; Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran Zhou <[email-masked]>; Zhenqiang Li <[email-masked]>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
has been successfully submitted by Tianran Zhou and posted to the IETF repository.

Name:		draft-li-ippm-otwamp-on-lag
Revision:	02
Title:		One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG
Document date:	2022-01-24
Group:		Individual Submission
Pages:		13
URL:            https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt
Status:         https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
Diff:           https://www.ietf.org/rfcdiff?url2=draft-li-ippm-otwamp-on-lag-02

Abstract:
   This document defines extensions to One-way Active Measurement
   Protocol (OWAMP), and Two-way Active Measurement Protocol (TWAMP) to
   implement performance measurement on every member link of a Link
   Aggregation Group (LAG).  Knowing the measured metrics of each member
   link of a LAG enables operators to enforce the performance based
   traffic steering policy across the member links.

The IETF Secretariat

---

From: Mach Chen <[email-masked]>
Date: Mon, 24 Jan 2022 06:38:45 +0000

Hi Tianran,

Thanks very much for taking this useful work up.
After several revisions, I see this draft is much improved and mature.
I would like to see the WG to move this draft forward.
Although I will not hold the pen for this draft anymore, I would like to continue to contribute.

Regards,
Mach

> From: ippm [mailto:[email-masked]] On Behalf Of Tianran Zhou
> Sent: Monday, January 24, 2022 2:23 PM
> To: IETF IPPM WG ([email-masked]) <[email-masked]>
> Subject: [ippm] FW: New Version Notification for
> draft-li-ippm-otwamp-on-lag-02.txt
> 
> Hi WG,
> 
> To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>;
> Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>;
> Tianran Zhou <[email-masked]>; Zhenqiang Li
> <[email-masked]>
> URL:
> https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-li-ippm-otwamp-on-lag-02
> 
> Abstract:
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 23 Jan 2022 22:58:13 -0800

+1, useful work, support its progress.

Cheers,
Jeff

> On Jan 23, 2022, at 22:39, Mach Chen <mach.chen=[email-masked]> wrote:
> 
> Hi Tianran,
>

---

From: Haoyu Song <[email-masked]>
Date: Mon, 24 Jan 2022 17:06:44 +0000

WG, 

I think the scenario for LAG performance measurement is practical and the method is sound, so I support this work.
For Figure 1, I think usually for load balancing with hashing, the number of links of a LAG would be power of two. 

Best,
Haoyu Song

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Sunday, January 23, 2022 10:23 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>; Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran Zhou <[email-masked]>; Zhenqiang Li <[email-masked]>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Name:		draft-li-ippm-otwamp-on-lag
Revision:	02
Title:		One-way/Two-way Active Measurement Protocol Extensions for Performance Measurement on LAG
Document date:	2022-01-24
Group:		Individual Submission
Pages:		13
URL:            https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-li-ippm-otwamp-on-lag-02.txt&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df020bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=O1SD54x5%2FM99g7YjxnzaMjaZuJ9S4UxNGcm6NAkTXng%3D&amp;reserved=0
Status:         https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-ippm-otwamp-on-lag%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df020bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=UYUXVf0BvrCuH20ydOjxCI26KjgpAopEIV40%2BqjuxKY%3D&amp;reserved=0
Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-li-ippm-otwamp-on-lag&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df020bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=gN9hSIQaMM%2BE%2BtDLSFxe95J%2FyX4omBdv6rtBTMB4B8o%3D&amp;reserved=0
Diff:           https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-li-ippm-otwamp-on-lag-02&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df020bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=NPJcFQoHUAw47%2FJ%2BO4SeOLEaQUNe%2FAI4UDUGMA%2BKK%2Fo%3D&amp;reserved=0

Abstract:

The IETF Secretariat

_______________________________________________
ippm mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7Ca16115736bab48d99c2f08d9df020bed%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637786022170908705%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DHVbIOrP6nfAfjGnIl5N%2F%2B5B0O6qDonb%2F%2Beq2uTEJu4%3D&amp;reserved=0

---

From: Tianran Zhou <[email-masked]>
Date: Tue, 25 Jan 2022 01:05:27 +0000

Hi Haoyu,

Thanks very much for your comments. Your perspective is correct.
I will revise the document in the next version.

Best,
Tianran

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Haoyu Song
Sent: Tuesday, January 25, 2022 1:07 AM
To: Tianran Zhou <zhoutianran=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

WG, 

Best,
Haoyu Song

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Sunday, January 23, 2022 10:23 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>; Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran Zhou <[email-masked]>; Zhenqiang Li <[email-masked]>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

---

From: "Aijun Wang" <[email-masked]>
Date: Wed, 26 Jan 2022 17:20:40 +0800

Hi, Tianran:

Have a brief review of this draft. I think its aim is straightforward and
will be useful to utilize the member link within the LAG.
Some comments are below:
1) It seems there is no Sender/Reflector behavior description for the Mirco
OWAMP session and the packet format? 
2) For the newly defined Session-Sender Packet/Session-Reflector Packet, how
to assure the backward compatibility? What I have seen is that you add two
additional fields within the existing Packet? 

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 2:23 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] FW: New Version Notification for

Hi WG,

We think this is an useful work on adapting OWAMP/TWAMP in LAG performance
measurement.
We updated this draft based on the comments from the meeting discussion and
mailing list.
Thanks for all the suggestions.
More reviews and comments are welcome.

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>; Jun
Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran Zhou
<[email-masked]>; Zhenqiang Li <[email-masked]>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

A new version of I-D, draft-li-ippm-otwamp-on-lag-02.txt
has been successfully submitted by Tianran Zhou and posted to the IETF
repository.

Name:           draft-li-ippm-otwamp-on-lag
Revision:       02
Title:          One-way/Two-way Active Measurement Protocol Extensions for
Performance Measurement on LAG
Document date:  2022-01-24
Group:          Individual Submission
Pages:          13
URL:
https://www.ietf.org/archive/id/draft-li-ippm-otwamp-on-lag-02.txt
Status:
https://datatracker.ietf.org/doc/draft-li-ippm-otwamp-on-lag/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-li-ippm-otwamp-on-lag
Diff:
https://www.ietf.org/rfcdiff?url2=draft-li-ippm-otwamp-on-lag-02

Abstract:

The IETF Secretariat

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 26 Jan 2022 10:03:21 +0000

Hi Anjun,

Thanks very much for your interest and comments.
Both are good questions.
Please see in line.

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2022 5:21 PM
To: Tianran Zhou <[email-masked]>; 'IETF IPPM WG' <[email-masked]>
Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi, Tianran:

Have a brief review of this draft. I think its aim is straightforward and will be useful to utilize the member link within the LAG.
Some comments are below:
1) It seems there is no Sender/Reflector behavior description for the Mirco OWAMP session and the packet format? 

ZTR> OWAMP is simple and there is no reflector. The sender cannot get the ack from the receiver. So we are not going to extend the OWAMP test packet.
The behavior is described in section 3.2:
" The micro OWAMP Sender MUST send the micro OWAMP-Test packets over the member link with which the session is associated. When receives a Test packet, the micro OWAMP receiver MUST use the member link from which the Test packet is received to correlate the micro OWAMP session. If there is no such a session, the Test packet MUST be discarded. " 

2) For the newly defined Session-Sender Packet/Session-Reflector Packet, how to assure the backward compatibility? What I have seen is that you add two additional fields within the existing Packet? 

ZTR> I am not aware of the compatibility problem. If a node supports micro session, it can understand the new packet extension. If a node does not support micro session, it just ignores the new fields. Because the new fields is in the reserved zone.
Moreover, the validation mechanism can figure out if the reflector can support the micro session. 

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 2:23 PM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>; Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran Zhou <[email-masked]>; Zhenqiang Li <[email-masked]>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

---

From: Henrik Nydell <[email-masked]>
Date: Wed, 26 Jan 2022 11:16:50 +0100

I had a brief review but failed to find details on how the TWAMP sessions
would be "guaranteed" to travel on a certain LAG segment. As far as I know
the LAG implementation may be different between vendors and as such I know
of no "one method fits all" to actually accomplish the measurement.

So this draft does not actually provide any solution to the problem of
being able to measure LAG segments separately and deterministically.

On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zhoutianran=
[email-masked]> wrote:

> 1) It seems there is no Sender/Reflector behavior description for the
> Mirco OWAMP session and the packet format?
>
>
> ZTR> OWAMP is simple and there is no reflector. The sender cannot get the
> ack from the receiver. So we are not going to extend the OWAMP test packet.
> " The micro OWAMP Sender MUST send the micro OWAMP-Test packets over the
> member link with which the session is associated. When receives a Test
> packet, the micro OWAMP receiver MUST use the member link from which the
> Test packet is received to correlate the micro OWAMP session. If there is
> no such a session, the Test packet MUST be discarded. "
>
> 2) For the newly defined Session-Sender Packet/Session-Reflector Packet,
> how to assure the backward compatibility? What I have seen is that you add
> two additional fields within the existing Packet?
>
> ZTR> I am not aware of the compatibility problem. If a node supports micro
> session, it can understand the new packet extension. If a node does not
> support micro session, it just ignores the new fields. Because the new
> fields is in the reserved zone.
> Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran
> Zhou <[email-masked]>; Zhenqiang Li <[email-masked]>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>
<https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
<https://ca.linkedin.com/company/accedian>
<http://www.accedian.com>
*accedian.com <http://accedian.com>*

-- 

Avis de confidentialité

Les
 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.

Confidentiality notice

This
 e-mail message and any attachment hereto contain confidential 
information 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Jan 2022 01:37:24 +0000

Hi Henrik,

Thanks very much for your review.
Your perspective is absolutely correct.
This draft is not able to “guarantee” a specific LAG path. For example, there is a switch between the two end points, or in the case the reflector is not capable.
I.e., as you said, there is no "one method fits all" to guarantee the path.

However, this draft seek another way round, the member link validation mechanism.
There is an assumption in the introduction “This document intends to address the scenario where a LAG directly connects two nodes (A and B).”
With the member link validation, sender/reflector will drop measurement data, when the test packet is not from the expected member link.
In this way, the measurement could always be correct.

This is somewhat similar to Paris Traceroute (https://paris-traceroute.net/about/), IMHO.

Cheers,
Tianran

From: Henrik Nydell [mailto:[email-masked]]
Sent: Wednesday, January 26, 2022 6:17 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]; IETF IPPM WG <[email-masked]>
Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

I had a brief review but failed to find details on how the TWAMP sessions would be "guaranteed" to travel on a certain LAG segment. As far as I know the LAG implementation may be different between vendors and as such I know of no "one method fits all" to actually accomplish the measurement.

So this draft does not actually provide any solution to the problem of being able to measure LAG segments separately and deterministically.

On Wed, Jan 26, 2022 at 11:03 AM Tianran Zhou <zhoutianran=[email-masked]<mailto:[email-masked]>> wrote:
Hi Anjun,

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 26, 2022 5:21 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; 'IETF IPPM WG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi, Tianran:

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 2:23 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Guo Jun <[email-masked]<mailto:[email-masked]>>; Jun Guo <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Zhenqiang Li <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

_______________________________________________
ippm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ippm

--

Henrik Nydell
Sr Product Manager
1.866.685.8181
[email-masked]<mailto:[email-masked]>
[https://i.xink.io/Images/Get/N63832/a65.png]<http://accedian.com>
[https://i.xink.io/Images/Get/N63832/f97.png]<https://www.facebook.com/accedian/> [https://i.xink.io/Images/Get/N63832/t99.png] <https://twitter.com/Accedian>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://ca.linkedin.com/company/accedian>
<http://www.accedian.com>
accedian.com<http://accedian.com>

Avis de confidentialité

Les informations contenues dans le présent message et dans toute pièce qui lui est jointe sont confidentielles et peuvent être protégées par le secret professionnel. Ces informations sont à l’usage exclusif de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez s’il vous plait communiquer immédiatement avec l’expéditeur et en détruire tout exemplaire. De plus, il vous est strictement interdit de le divulguer, de le distribuer ou de le reproduire sans l’autorisation de l’expéditeur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential information which may be privileged and which is intended for the exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof. Furthermore, any disclosure, distribution or copying of this message and/or any attachment hereto without the consent of the sender is strictly prohibited. Thank you.

---

From: Henrik Nydell <[email-masked]>
Date: Thu, 27 Jan 2022 10:28:34 +0100

Thanks for the clarification, but this "member link validation mechanism"
depends fully on configuration between the session sender and the session
reflector right? So even if they have agreed that a certain session ID
belongs to lag link A, there is no way to be sure that this is the case,
the intermediate switches may place these packets randomly over links A-C
and the TWAMP/OWAMP sender/reflectors will have no knowledge of this. So I
dont know if this addition adds much usefulnes over the already existing
capabilities of TWAMP, where you can use the 5-tuple of port-pair, IP-pair
and TOS to differentiate session from each other.

On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou <[email-masked]> wrote:

> This draft is not able to “guarantee” a specific LAG path. For example,
> there is a switch between the two end points, or in the case the reflector
> is not capable.
>
> There is an assumption in the introduction “This document intends to
> address the scenario where a LAG directly connects two nodes (A and B).”
>
> With the member link validation, sender/reflector will drop measurement
> data, when the test packet is not from the expected member link.
>
> This is somewhat similar to Paris Traceroute (
> https://paris-traceroute.net/about/), IMHO.
>
>
>
> Cheers,
>
> Tianran
>
>
>
> *From:* Henrik Nydell [mailto:[email-masked]]
> *Sent:* Wednesday, January 26, 2022 6:17 PM
> *To:* Tianran Zhou <[email-masked]>
> *Cc:* [email-masked]; IETF IPPM WG <[email-masked]>
> *Subject:* Re: [ippm] FW: New Version Notification for
> Les informations contenues dans le présent message et dans toute pièce qui
> lui est jointe sont confidentielles et peuvent être protégées par le secret
> professionnel. Ces informations sont à l’usage exclusif de son ou de ses
> destinataires. Si vous recevez ce message par erreur, veuillez s’il vous
> plait communiquer immédiatement avec l’expéditeur et en détruire tout
> exemplaire. De plus, il vous est strictement interdit de le divulguer, de
> le distribuer ou de le reproduire sans l’autorisation de l’expéditeur.
> Merci.
>
> Confidentiality notice
>
> This e-mail message and any attachment hereto contain confidential
> information which may be privileged and which is intended for the exclusive
> use of its addressee(s). If you receive this message in error, please
> inform sender immediately and destroy any copy thereof. Furthermore, any
> disclosure, distribution or copying of this message and/or any attachment
> hereto without the consent of the sender is strictly prohibited. Thank you.
>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Jan 2022 09:48:47 +0000

Hi Henrik,

Both sender and reflector keep the mapping between member link and the micro session. Either by configuration or negotiation or auto-learning.
So, in your switch case, if the sender receives the packet from C, not A, the sender know it’s wrong. The test packet should be dropped and not counted.

Best,
Tianran
Sent: Thursday, January 27, 2022 5:29 PM

Thanks for the clarification, but this "member link validation mechanism" depends fully on configuration between the session sender and the session reflector right? So even if they have agreed that a certain session ID belongs to lag link A, there is no way to be sure that this is the case, the intermediate switches may place these packets randomly over links A-C and the TWAMP/OWAMP sender/reflectors will have no knowledge of this. So I dont know if this addition adds much usefulnes over the already existing capabilities of TWAMP, where you can use the 5-tuple of port-pair, IP-pair and TOS to differentiate session from each other.

On Thu, Jan 27, 2022 at 2:37 AM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Henrik,

Cheers,
Tianran

From: Henrik Nydell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 26, 2022 6:17 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 26, 2022 5:21 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; 'IETF IPPM WG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi, Tianran:

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 2:23 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Guo Jun <[email-masked]<mailto:[email-masked]>>; Jun Guo <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Zhenqiang Li <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: Henrik Nydell <[email-masked]>
Date: Thu, 27 Jan 2022 11:15:11 +0100

OK, but this requires that the sender runs on the device that performs the
LAG. This would be quite a serious limitation of the feature I believe

On Thu, Jan 27, 2022 at 10:48 AM Tianran Zhou <[email-masked]>
wrote:

> Hi Henrik,
>
>
>
> Both sender and reflector keep the mapping between member link and the
> micro session. Either by configuration or negotiation or auto-learning.
>
> So, in your switch case, if the sender receives the packet from C, not A,
> the sender know it’s wrong. The test packet should be dropped and not
> counted.
>
>
>
> Best,
>
> Tianran
>
> *Sent:* Thursday, January 27, 2022 5:29 PM

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Jan 2022 11:48:26 +0000

Hi Henrik,

May I understand what’s the limits?
The twamp or lag? Or other?
Actually both are supported in existing devices. As far as I know quite normal.

Best,
Tianran

________________________________

Sent from WeLink
发件人： Henrik Nydell<[email-masked]<mailto:[email-masked]>>
收件人： Tianran Zhou<[email-masked]<mailto:[email-masked]>>
抄送： wangaj3<[email-masked]<mailto:[email-masked]>>;IETF IPPM WG<[email-masked]<mailto:[email-masked]>>
主题： Re: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt
时间： 2022-01-27 18:15:39

OK, but this requires that the sender runs on the device that performs the LAG. This would be quite a serious limitation of the feature I believe

On Thu, Jan 27, 2022 at 10:48 AM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Henrik,

Best,
Tianran

Cheers,
Tianran

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 26, 2022 5:21 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; 'IETF IPPM WG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi, Tianran:

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 2:23 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Guo Jun <[email-masked]<mailto:[email-masked]>>; Jun Guo <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Zhenqiang Li <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: Henrik Nydell <[email-masked]>
Date: Thu, 27 Jan 2022 13:20:20 +0100

In my mind TWAMP, being a layer-3 method, is more commonly used on longer
e-2-e layer3 connections, for example sender from a central core site out
to a reflector on a radio base station. The path between may have several
layer3 hops and many layer-2. If there is LAG somewhere there in the middle
of the path, how will this draft help?

On Thu, Jan 27, 2022 at 12:48 PM Tianran Zhou <[email-masked]>
wrote:

> ------------------------------
>
> Sent from WeLink
> *发件人： *Henrik Nydell<[email-masked]>
> *收件人： *Tianran Zhou<[email-masked]>
> *抄送： *wangaj3<[email-masked]>;IETF IPPM WG<[email-masked]>
> *主题： *Re: [ippm] FW: New Version Notification for
> *时间： *2022-01-27 18:15:39
>
>> ZTR> I am not aware of the compatibility problem. If a node supports
>> micro session, it can understand the new packet extension. If a node does
>> not support micro session, it just ignores the new fields. Because the new
>> Tianran Zhou <[email-masked]>; Zhenqiang Li <
>> [email-masked]>
>> Les informations contenues dans le présent message et dans toute pièce
>> qui lui est jointe sont confidentielles et peuvent être protégées par le
>> secret professionnel. Ces informations sont à l’usage exclusif de son ou de
>> ses destinataires. Si vous recevez ce message par erreur, veuillez s’il
>> vous plait communiquer immédiatement avec l’expéditeur et en détruire tout
>> Les informations contenues dans le présent message et dans toute pièce
>> qui lui est jointe sont confidentielles et peuvent être protégées par le
>> secret professionnel. Ces informations sont à l’usage exclusif de son ou de
>> ses destinataires. Si vous recevez ce message par erreur, veuillez s’il
>> vous plait communiquer immédiatement avec l’expéditeur et en détruire tout

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Tianran Zhou <[email-masked]>
Date: Thu, 27 Jan 2022 12:36:46 +0000

Hi Henrik,

This draft is not targeting for your case. China mobile raised the LAG PM requirement in their network.

But as I mentioned in the introduction, it could be potentially used for SR policy with L3 multi hops. This is out of scope. But I would happy to share my point. :-)

Best,
Tianran

Sent from WeLink
时间： 2022-01-27 20:20:53

In my mind TWAMP, being a layer-3 method, is more commonly used on longer e-2-e layer3 connections, for example sender from a central core site out to a reflector on a radio base station. The path between may have several layer3 hops and many layer-2. If there is LAG somewhere there in the middle of the path, how will this draft help?

On Thu, Jan 27, 2022 at 12:48 PM Tianran Zhou <[email-masked]<mailto:[email-masked]>> wrote:
Hi Henrik,

Best,
Tianran

Sent from WeLink

Best,
Tianran

Cheers,
Tianran

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, January 26, 2022 5:21 PM
To: Tianran Zhou <[email-masked]<mailto:[email-masked]>>; 'IETF IPPM WG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi, Tianran:

Best Regards

Aijun Wang
China Telecom

-----Original Message-----
From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 2:23 PM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Guo Jun <[email-masked]<mailto:[email-masked]>>; Jun Guo <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Zhenqiang Li <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice

---

From: Henrik Nydell <[email-masked]>
Date: Thu, 27 Jan 2022 13:56:30 +0100

OK, then I fail to understand why this extension is required, at least when
it comes to LAG. There are already standards for monitoring L2 links, and
in you LAG case it would then be more appropriate to use 3x Y.1731 or
similar to accomplish this.

In general I would support the concept of "micro sessions", or "session
IDs" but this should then be promoted as a common method to allow several
TWAMP flows between the same two endpoints, and not mention LAG
specifically, since it actually does not help monitoring LAG paths in a
general sense as I have described.

On Thu, Jan 27, 2022 at 1:37 PM Tianran Zhou <[email-masked]> wrote:

> *时间： *2022-01-27 20:20:53
>
>> OK, but this requires that the sender runs on the device that performs
>> the LAG. This would be quite a serious limitation of the feature I believe
>>
>>> So, in your switch case, if the sender receives the packet from C, not
>>> A, the sender know it’s wrong. The test packet should be dropped and not
>>> counted.
>>>
>>>
>>>
>>> Best,
>>>
>>> Tianran
>>>
>>> Thanks for the clarification, but this "member link validation
>>> mechanism" depends fully on configuration between the session sender and
>>> the session reflector right? So even if they have agreed that a certain
>>> session ID belongs to lag link A, there is no way to be sure that this is
>>> the case, the intermediate switches may place these packets randomly over
>>> links A-C and the TWAMP/OWAMP sender/reflectors will have no knowledge of
>>> this. So I dont know if this addition adds much usefulnes over the already
>>> existing capabilities of TWAMP, where you can use the 5-tuple of port-pair,
>>> IP-pair and TOS to differentiate session from each other.
>>>
>>>
>>>
>>>
>>>
>>> I had a brief review but failed to find details on how the TWAMP
>>> sessions would be "guaranteed" to travel on a certain LAG segment. As far
>>> as I know the LAG implementation may be different between vendors and as
>>> such I know of no "one method fits all" to actually accomplish the
>>> measurement.
>>>
>>>
>>>
>>> To: Tianran Zhou <[email-masked]>; 'IETF IPPM WG' <[email-masked]
>>> >
>>> Have a brief review of this draft. I think its aim is straightforward
>>> and will be useful to utilize the member link within the LAG.
>>> Some comments are below:
>>> ZTR> OWAMP is simple and there is no reflector. The sender cannot get
>>> the ack from the receiver. So we are not going to extend the OWAMP test
>>> packet.

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 28 Jan 2022 11:03:29 +0000

Hi Tianran, All,
I think that this is a useful work.
For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also complement passive and hybrid methods. Indeed, the extensions proposed in this draft allow to monitor all the links and not only the link crossed by the observed packet stream.
Maybe, you can also highlight this point in the introduction section.

Minor nits:
s/Reflector Member Link ID fields/Reflector Member Link ID field/

s/When sending a response to the received Test packet, the micro TWAMP Session-Sender/ When sending a response to the received Test packet, the micro TWAMP Session- Reflector/

Regards,

Giuseppe

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 7:23 AM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>; Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran Zhou <[email-masked]>; Zhenqiang Li <[email-masked]>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 28 Jan 2022 11:14:49 +0000

Hi Giuseppe,

Thanks very much for your review.
I will incorporate your suggestions in the next revision.

Cheers,
Tianran

-----Original Message-----
From: ippm [mailto:[email-masked]] On Behalf Of Giuseppe Fioccola
Sent: Friday, January 28, 2022 7:03 PM
To: Tianran Zhou <zhoutianran=[email-masked]>; IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi Tianran, All,

Minor nits:

Regards,

Giuseppe

-----Original Message-----
From: ippm <[email-masked]> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 7:23 AM
To: IETF IPPM WG ([email-masked]) <[email-masked]>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]>; Guo Jun <[email-masked]>; Jun Guo <[email-masked]>; Rakesh Gandhi <[email-masked]>; Tianran Zhou <[email-masked]>; Zhenqiang Li <[email-masked]>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

---

From: Henrik Nydell <[email-masked]>
Date: Fri, 28 Jan 2022 12:56:51 +0100

I still think it would be much better to generalize this micro TWAMP
concept and not tie this to LAG, since that will be implementation specific
- only if you implement TWAMP directly on a LAG-device this draft would
apply.
Better then to generalize the concept and call the added identifier
"Substream ID" or something similar. Then this draft would also apply to
for example a vendor that implements routing over different paths or as
Tianran pointed out, MPLS-SR uses. Thus I would propose removing all
references to LAG in this draft and widen the scope to any situation where
there would be uses for labelled (ID:ed) substreams between the same
TWAMP-sender and session-reflector.

On Fri, Jan 28, 2022 at 12:15 PM Tianran Zhou <zhoutianran=
[email-masked]> wrote:

> For LAG, the use of active methods (OWAMP, TWAMP, STAMP) can also
> complement passive and hybrid methods. Indeed, the extensions proposed in
> this draft allow to monitor all the links and not only the link crossed by
> the observed packet stream.
> s/When sending a response to the received Test packet, the micro TWAMP
> Session-Sender/ When sending a response to the received Test packet, the
> micro TWAMP Session- Reflector/
>
>
> Regards,
>
> Giuseppe
>
>

-- 

*Henrik Nydell*
*Sr Product Manager*
1.866.685.8181
[email-masked]
<http://accedian.com>

-- 

Avis de confidentialité

Les

Confidentiality notice

This

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 28 Jan 2022 13:08:47 +0000

Hi Henrik,

Thanks for your interest.
This draft is not aiming for a big ambition, but to solve a specific requirement from existing network operations. Without well thought and design, I am not sure if we can simply remove the LAG assumption.

How about we work together on a new draft to generalize this for the more common use? And hence the two work can complement.

Best,
Tianran

Sent from WeLink
发件人： Henrik Nydell<[email-masked]<mailto:[email-masked]>>
收件人： Tianran Zhou<[email-masked]<mailto:[email-masked]>>
抄送： Giuseppe Fioccola<[email-masked]<mailto:[email-masked]>>;IETF IPPM WG (ippm<[email-masked]<mailto:[email-masked]>>
主题： Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt
时间： 2022-01-28 19:57:28

I still think it would be much better to generalize this micro TWAMP concept and not tie this to LAG, since that will be implementation specific - only if you implement TWAMP directly on a LAG-device this draft would apply.
Better then to generalize the concept and call the added identifier "Substream ID" or something similar. Then this draft would also apply to for example a vendor that implements routing over different paths or as Tianran pointed out, MPLS-SR uses. Thus I would propose removing all references to LAG in this draft and widen the scope to any situation where there would be uses for labelled (ID:ed) substreams between the same TWAMP-sender and session-reflector.

On Fri, Jan 28, 2022 at 12:15 PM Tianran Zhou <zhoutianran=[email-masked]<mailto:[email-masked]>> wrote:
Hi Giuseppe,

Cheers,
Tianran

-----Original Message-----
From: ippm [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Giuseppe Fioccola
Sent: Friday, January 28, 2022 7:03 PM
To: Tianran Zhou <zhoutianran=[email-masked]<mailto:[email-masked]>>; IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [ippm] New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi Tianran, All,

Minor nits:

Regards,

Giuseppe

-----Original Message-----
From: ippm <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Monday, January 24, 2022 7:23 AM
To: IETF IPPM WG ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] FW: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Hi WG,

Cheers,
Tianran

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, January 24, 2022 2:17 PM
To: Greg Mirsky <[email-masked]<mailto:[email-masked]>>; Guo Jun <[email-masked]<mailto:[email-masked]>>; Jun Guo <[email-masked]<mailto:[email-masked]>>; Rakesh Gandhi <[email-masked]<mailto:[email-masked]>>; Tianran Zhou <[email-masked]<mailto:[email-masked]>>; Zhenqiang Li <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-li-ippm-otwamp-on-lag-02.txt

Abstract:

The IETF Secretariat

--

Henrik Nydell
Sr Product Manager
1.866.685.8181

Avis de confidentialité

Confidentiality notice