Subject: [ippm] Comments for draft-li-ippm-pm-on-lag

From: wangyali <[email-masked]>
Date: Wed, 14 Oct 2020 07:09:40 +0000

Hi authors,

This is a valuable draft discussing about PM on LAG through OWAMP/TWAMP/STAMP extension.

The basic STAMP defined in RFC8762 has been extended to implement PM on member link of a LAG in your draft.  Do you consider the extended STAMP proposed in [draft-ietf-ippm-stamp-option-tlv] to be used for PM on LAG?

Nits:

OLD: When receives a Test packet, the micro STAMP Session-Reflector MUST

   use the member link from which the Test packet is received to

   correlate to a micro STAMP session and use the Sender/Reflector

   member link identifiers to validate whether the Test packet is is

   correctly transmitted over the expected member link.

NEW: When receives a Test packet, the micro STAMP Session-Reflector MUST

   use the member link from which the Test packet is received to

   correlate to a micro STAMP session and use the Sender/Reflector

   member link identifiers to validate whether the Test packet is

   correctly transmitted over the expected member link.

Best regards,
Yali

---

From: Mach Chen <[email-masked]>
Date: Thu, 15 Oct 2020 09:35:36 +0000

Hi Yali,

Thanks for your comments!

The current design extends the STAMP base format to implement PM on LAG, in my understanding, the STAMP-TLV draft extends the base STAMP by adding TLV following the base format. Therefore, the current design can be easily extended to support STAMP-TLV format. I am personally OK to add a format based on the STAMP-TLV format.

BTW, thanks for the nit, we will fix it in the next reversion.

Best regards,
Mach

From: ippm [mailto:[email-masked]] On Behalf Of wangyali
Sent: Wednesday, October 14, 2020 3:10 PM
To: [email-masked]
Cc: IETF IPPM WG <[email-masked]>
Subject: [ippm] Comments for draft-li-ippm-pm-on-lag

Hi authors,

Nits:

Best regards,
Yali

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 16 Oct 2020 09:28:15 +0800

Hi Yali,

Thank you for your support and suggestion.
The extended STAMP with optional TLV is an option to do PM on LAG. We discussed it internaly in our design team. The main concern about it is whether it is hardware friendly. Since the base STAMP with extensions proposed in this doc is sufficient for PM on LAG, do you still prefer the TLV option? We also want to know the opinion from this list.

Thanks,
Zhenqiang Li

[email-masked]
 
From: wangyali
Date: 2020-10-14 15:09
To: [email-masked]
CC: IETF IPPM WG
Subject: Comments for draft-li-ippm-pm-on-lag
Hi authors,

 
Nits:

Best regards,
Yali

---

From: wangyali <[email-masked]>
Date: Fri, 16 Oct 2020 01:26:54 +0000

Hi Mach,

Thanks for your feedback and kind consideration.

Referring to [I-D.ietf-ippm-stamp-option-tlv], SSID and multiple TLVs are extended following the base format.
And I suggest updating normative reference [I-D.ietf-ippm-stamp-option-tlv] to the latest version draft-ietf-ippm-stamp-option-tlv-09.

Best regards,
Yali

From: Mach Chen
Sent: Thursday, October 15, 2020 5:36 PM
To: wangyali <[email-masked]>; [email-masked]
Cc: IETF IPPM WG <[email-masked]>
Subject: RE: [ippm] Comments for draft-li-ippm-pm-on-lag

Hi Yali,

Best regards,
Mach

From: ippm [mailto:[email-masked]] On Behalf Of wangyali
Sent: Wednesday, October 14, 2020 3:10 PM
To: [email-masked]<mailto:[email-masked]>
Cc: IETF IPPM WG <[email-masked]<mailto:[email-masked]>>
Subject: [ippm] Comments for draft-li-ippm-pm-on-lag

Hi authors,

Nits:

Best regards,
Yali

---

From: wangyali <[email-masked]>
Date: Fri, 16 Oct 2020 03:44:49 +0000

Hi Zhenqiang,

Thanks for your reply. As the optional TLVs, the length of the extended STAMP test packet, indeed is variable. While such extensions enhance the STAMP base functions, which lead active PM to be scalable. I prefer that having the extension formats to be an additional option in this draft.

Comments from other forks are also welcome. :)

Best regards,
Yali

From: [email-masked] [mailto:[email-masked]]
Sent: Friday, October 16, 2020 9:28 AM
To: wangyali <[email-masked]>; draft-li-ippm-pm-on-lag <[email-masked]>
Cc: ippm <[email-masked]>
Subject: Re: Comments for draft-li-ippm-pm-on-lag

Hi Yali,

Thanks,
Zhenqiang Li
________________________________
[email-masked]<mailto:[email-masked]>

From: wangyali<mailto:[email-masked]>
Date: 2020-10-14 15:09
To: [email-masked]<mailto:[email-masked]>
CC: IETF IPPM WG<mailto:[email-masked]>
Subject: Comments for draft-li-ippm-pm-on-lag
Hi authors,

Nits:

Best regards,
Yali

---

From: Mach Chen <[email-masked]>
Date: Fri, 16 Oct 2020 07:30:38 +0000

Hi Yali,

One clarify question, do you mean that the additional option is just to allow the optional TLVs (but has nothing business with PM on LAG function) that follow the base format as defined in the current draft, or to use the optional TLV to implement the PM on LAG?  I assume it's the former.

Best regards,
Mach

From: ippm [mailto:[email-masked]] On Behalf Of wangyali
Sent: Friday, October 16, 2020 11:45 AM
To: [email-masked]; draft-li-ippm-pm-on-lag <[email-masked]>
Cc: ippm <[email-masked]>
Subject: Re: [ippm] Comments for draft-li-ippm-pm-on-lag

Hi Zhenqiang,

Best regards,
Yali

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Friday, October 16, 2020 9:28 AM
To: wangyali <[email-masked]<mailto:[email-masked]>>; draft-li-ippm-pm-on-lag <[email-masked]<mailto:[email-masked]>>
Cc: ippm <[email-masked]<mailto:[email-masked]>>
Subject: Re: Comments for draft-li-ippm-pm-on-lag

Hi Yali,

Thanks,
Zhenqiang Li

Nits:

Best regards,
Yali

---

From: wangyali <[email-masked]>
Date: Mon, 19 Oct 2020 01:47:39 +0000

Hi Mach,

Thanks for your feedback. Yes. I mean it’s better to keep the base format which has been defined in the current draft. In addition, I suggest to add the additional option, which allow the optional TLVs that follow the base format.

Best regards,
Yali

发件人: Mach Chen
发送时间: 2020年10月16日 15:31
收件人: wangyali <[email-masked]>; [email-masked]; draft-li-ippm-pm-on-lag <[email-masked]>
抄送: ippm <[email-masked]>
主题: RE: Comments for draft-li-ippm-pm-on-lag

Hi Yali,

One clarify question, do you mean that the additional option is just to allow the optional TLVs (but has nothing business with PM on LAG function) that follow the base format as defined in the current draft, or to use the optional TLV to implement the PM on LAG?  I assume it’s the former.

Best regards,
Mach

To: [email-masked]<mailto:[email-masked]>; draft-li-ippm-pm-on-lag <[email-masked]<mailto:[email-masked]>>

Hi Zhenqiang,

Best regards,
Yali

Hi Yali,

Thanks,
Zhenqiang Li

Nits:

Best regards,
Yali

---

From: Rakesh Gandhi <[email-masked]>
Date: Mon, 19 Oct 2020 10:59:27 -0400

Hi Mach,

The new fields defined in this draft conflicts with the control field
format that has been already defined in SR drafts for some time now.

LAG
---------------------------------------------------------
| Sender Member Link ID | Reflector Member Link ID |
-----------------------------------

SR:
-----------------------------------
|         MBZ          |Se Control Code|
-----------------------------------

- draft-gandhi-spring-twamp-srpm
<https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/>
- draft-gandhi-spring-stamp-srpm
<https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>

The proposed field in the SR drafts was discussed in March:
https://mailarchive.ietf.org/arch/search/?q=%22draft-gandhi-spring-twamp-srpm%22

The SR drafts were updated accordingly and presented in IETF 108 IPPM WG:
https://www.ietf.org/proceedings/108/slides/slides-108-ippm-performance-measurement-using-stamp-for-segment-routing-networks-00

Thanks,
Rakesh

On Sun, Oct 18, 2020 at 9:48 PM wangyali <[email-masked]> wrote:

> Hi Mach,
>
>
>
> Thanks for your feedback. Yes. I mean it’s better to keep the base format
> which has been defined in the current draft. In addition, I suggest to add
> the additional option, which allow the optional TLVs that follow the base
> format.
>
>
>
> Best regards,
>
> Yali
>
>
>
> *发件人**:* Mach Chen
> *发送时间:* 2020年10月16日 15:31
> *收件人:* wangyali <[email-masked]>; [email-masked];
> draft-li-ippm-pm-on-lag <[email-masked]>
> *抄送:* ippm <[email-masked]>
> *主题:* RE: Comments for draft-li-ippm-pm-on-lag
>
>
>
> Hi Yali,
>
>
>
> One clarify question, do you mean that the additional option is just to
> allow the optional TLVs (but has nothing business with PM on LAG function)
> that follow the base format as defined in the current draft, or to use the
> optional TLV to implement the PM on LAG?  I assume it’s the former.
>
>
>
> Best regards,
>
> Mach
>
>
>
> *From:* ippm [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *wangyali
> *Sent:* Friday, October 16, 2020 11:45 AM
> *To:* [email-masked]; draft-li-ippm-pm-on-lag <
> [email-masked]>
> *Cc:* ippm <[email-masked]>
> *Subject:* Re: [ippm] Comments for draft-li-ippm-pm-on-lag
>
>
>
> Hi Zhenqiang,
>
>
>
> Thanks for your reply. As the optional TLVs, the length of the extended
> STAMP test packet, indeed is variable. While such extensions enhance the
> STAMP base functions, which lead active PM to be scalable. I prefer that
> having the extension formats to be an additional option in this draft.
>
>
>
> Comments from other forks are also welcome. J
>
>
>
> Best regards,
>
> Yali
>
>
>
> *From:* [email-masked] [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Friday, October 16, 2020 9:28 AM
> *To:* wangyali <[email-masked]>; draft-li-ippm-pm-on-lag <
> [email-masked]>
> *Cc:* ippm <[email-masked]>
> *Subject:* Re: Comments for draft-li-ippm-pm-on-lag
>
>
>
> Hi Yali,
>
>
>
> The extended STAMP with optional TLV is an option to do PM on LAG. We
> discussed it internaly in our design team. The main concern about it is
> whether it is hardware friendly. Since the base STAMP with extensions
> proposed in this doc is sufficient for PM on LAG, do you still prefer the
> TLV option? We also want to know the opinion from this list.
>
>
>
> Thanks,
>
> Zhenqiang Li
> ------------------------------
>
> [email-masked]
>
>
>
> *From:* wangyali <[email-masked]>
>
> *Date:* 2020-10-14 15:09
>
> *To:* [email-masked]
>
> *CC:* IETF IPPM WG <[email-masked]>
>
> *Subject:* Comments for draft-li-ippm-pm-on-lag
>
> Hi authors,
>
>
>
> The basic STAMP defined in RFC8762 has been extended to implement PM on
> member link of a LAG in your draft.  Do you consider the extended STAMP
> proposed in [draft-ietf-ippm-stamp-option-tlv] to be used for PM on LAG?
>
>
>
> Nits:
>
>    member link identifiers to validate whether the Test packet *is is*
>
>    member link identifiers to validate whether the Test packet* is*
>
> _______________________________________________
> ippm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ippm
>

---

From: Mach Chen <[email-masked]>
Date: Tue, 20 Oct 2020 08:22:27 +0000

Hi Rakesh,

Thanks for pointing out this!

We will fix this in the next revision.

Best regards,
Mach

From: Rakesh Gandhi [mailto:[email-masked]]
Sent: Monday, October 19, 2020 10:59 PM
To: wangyali <[email-masked]>
Cc: Mach Chen <[email-masked]>; [email-masked]; draft-li-ippm-pm-on-lag <[email-masked]>; ippm <[email-masked]>; IPPM Chairs <[email-masked]>
Subject: Re: [ippm] 答复: Comments for draft-li-ippm-pm-on-lag

Hi Mach,

The new fields defined in this draft conflicts with the control field format that has been already defined in SR drafts for some time now.

LAG

SR:
-----------------------------------
|         MBZ          |Se Control Code|
-----------------------------------
•  draft-gandhi-spring-twamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-twamp-srpm/>
•  draft-gandhi-spring-stamp-srpm<https://datatracker.ietf.org/doc/draft-gandhi-spring-stamp-srpm/>

Thanks,
Rakesh

On Sun, Oct 18, 2020 at 9:48 PM wangyali <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mach,

Best regards,
Yali

发件人: Mach Chen
发送时间: 2020年10月16日 15:31
收件人: wangyali <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; draft-li-ippm-pm-on-lag <[email-masked]<mailto:[email-masked]>>
抄送: ippm <[email-masked]<mailto:[email-masked]>>
主题: RE: Comments for draft-li-ippm-pm-on-lag

Hi Yali,

Best regards,
Mach

Hi Zhenqiang,

Comments from other forks are also welcome. ☺

Best regards,
Yali

Hi Yali,

Thanks,
Zhenqiang Li

Nits:

Best regards,
Yali

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