Re: [ippm] Alvaro Retana's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)

xiao.min2@zte.com.cn Sat, 29 October 2022 01:07 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B01F8C14F72F; Fri, 28 Oct 2022 18:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEjery3kWRoK; Fri, 28 Oct 2022 18:07:19 -0700 (PDT)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.216.63.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D81E6C14F733; Fri, 28 Oct 2022 18:07:17 -0700 (PDT)
Received: from mxct.zte.com.cn (unknown [192.168.251.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mxhk.zte.com.cn (FangMail) with ESMTPS id 4Mzh8g5218z5BNRf; Sat, 29 Oct 2022 09:07:15 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.5.228.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mxct.zte.com.cn (FangMail) with ESMTPS id 4Mzh854LjZz501Sg; Sat, 29 Oct 2022 09:06:45 +0800 (CST)
Received: from njxh01app01.zte.com.cn ([10.41.132.205]) by mse-fl1.zte.com.cn with SMTP id 29T16c72019552; Sat, 29 Oct 2022 09:06:38 +0800 (+08) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxh01app01[null]) by mapi (Zmail) with MAPI id mid201; Sat, 29 Oct 2022 09:06:39 +0800 (CST)
Date: Sat, 29 Oct 2022 09:06:39 +0800
X-Zmail-TransId: 2af9635c7c9f701346cd
X-Mailer: Zmail v1.0
Message-ID: <202210290906397710582@zte.com.cn>
In-Reply-To: <CAMMESswTOESVwx8LGmXOnJ4OFZst9hbgAhCaXdtsvGQRu5BQRQ@mail.gmail.com>
References: 202210281022397100489@zte.com.cn, CAMMESswTOESVwx8LGmXOnJ4OFZst9hbgAhCaXdtsvGQRu5BQRQ@mail.gmail.com
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: aretana.ietf@gmail.com
Cc: ippm@ietf.org, marcus.ihlar@ericsson.com, ippm-chairs@ietf.org, iesg@ietf.org, draft-ietf-ippm-ioam-conf-state@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 29T16c72019552
X-Fangmail-Gw-Spam-Type: 0
X-FangMail-Miltered: at cgslv5.04-192.168.250.138.novalocal with ID 635C7CC3.000 by FangMail milter!
X-FangMail-Envelope: 1667005635/4Mzh8g5218z5BNRf/635C7CC3.000/192.168.251.13/[192.168.251.13]/mxct.zte.com.cn/<xiao.min2@zte.com.cn>
X-Fangmail-Anti-Spam-Filtered: true
X-Fangmail-MID-QID: 635C7CC3.000/4Mzh8g5218z5BNRf
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ZPpUZqCej_7hieTD8ttXDWNezF0>
Subject: Re: [ippm] Alvaro Retana's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Oct 2022 01:07:20 -0000

Hi Alvaro,





Thank you for the reply. I got it.





Best Regards,


Xiao Min







Original



From: AlvaroRetana <aretana.ietf@gmail.com>
To: 肖敏10093570;
Cc: ippm@ietf.org <ippm@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;iesg@ietf.org <iesg@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;
Date: 2022年10月28日 18:44
Subject: Re: Alvaro Retana's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)



Hi!


Yes, those changes work for me.


Thanks!


Alvaro. 


On October 27, 2022 at 10:22:46 PM, xiao.min2@zte.com.cn (xiao.min2@zte.com.cn) wrote:



Hi Alvaro,






Please check inline my responses.






Best Regards,


Xiao Min












From: AlvaroRetana <aretana.ietf@gmail.com>
To: 肖敏10093570;
Cc: ippm@ietf.org <ippm@ietf.org>;ippm-chairs@ietf.org <ippm-chairs@ietf.org>;marcus.ihlar@ericsson.com <marcus.ihlar@ericsson.com>;iesg@ietf.org <iesg@ietf.org>;draft-ietf-ippm-ioam-conf-state@ietf.org <draft-ietf-ippm-ioam-conf-state@ietf.org>;
Date: 2022年10月26日 21:40
Subject: Re: Alvaro Retana's No Objection on draft-ietf-ippm-ioam-conf-state-07: (with COMMENT)


On October 26, 2022 at 3:08:08 AM, xiao.min2@zte.com.cn wrote:
 
 
Xiao Min:
 
Hi!
 
 
....
> [XM]>>> OK. Combining your comment and that one from Eric Vyncke on the
> abstract, I propose to change the abstract (and the corresponding text in the
> introduction) as below.
> 
> NEW
> 
>    This document describes a generic format for the echo request/reply
>    mechanisms used in IPv6, MPLS, Service Function Chain (SFC) and Bit
>    Index Explicit Replication (BIER) environments, which can be used
>    within the In situ Operations, Administration, and Maintenance (IOAM)
>    domain, allowing the IOAM encapsulating node to discover the enabled
>    IOAM capabilities of each IOAM transit and IOAM decapsulating node.
 
This text still says that the "document describes a generic
format...used in IPv6, MPLS, Service Function Chain (SFC) and Bit
Index Explicit Replication (BIER) environments".
 
I think this is still misleading because, as you point out below, the
work to make this generic format work in IPV6, MPLS, etc. hasn't been
done.  In fact, all the drafts mentioned below are individual
submissions.
 
Suggestion> 
 
   This document describes a generic format for use in echo
request/reply mechanisms, which can be used within an In situ
Operations, Administration, and Maintenance (IOAM) domain, allowing
the IOAM encapsulating node to discover the enabled IOAM capabilities
of each IOAM transit and IOAM decapsulating node.  The generic format
is intended to be used with a variety of data planes such as IPv6,
MPLS, Service Function Chain (SFC)
   and Bit Index Explicit Replication (BIER).
 [XM-2]>>> The abstract suggested by you looks good. Will use it. For the introduction, does the changes proposed by John Scudder as below work for you?

OLD:   This document describes an extension to the echo request/reply   mechanisms used in IPv6 (including SRv6), MPLS (including SR-MPLS),   SFC and BIER environments, which can be used within the IOAM domain,   allowing the IOAM encapsulating node to discover the enabled IOAM   capabilities of each IOAM transit and IOAM decapsulating node.NEW:   This document specifies formats and objects that can be used in the   extension of echo request/reply mechanisms used in IPv6 (including   SRv6), MPLS (including SR-MPLS), SFC and BIER environments, which can   be used within the IOAM domain, allowing the IOAM encapsulating node   to discover the enabled IOAM capabilities of each IOAM transit and


   IOAM decapsulating node.




OLD:   Note that specification details for these different echo request/   reply protocols are outside the scope of this document.  It is   expected that each such protocol extension would be specified by an   RFC and jointly designed by the working group that develops or   maintains the echo request/reply protocol and the IETF IP Performance   Measurement (IPPM) Working Group.NEW:   It is expected that the specification of the instantiation of each of   these extensions will be done in the form of an RFC jointly designed   by the working group that develops or maintains the echo   request/reply protocol and the IETF IP Performance Measurement (IPPM)


   Working Group.




Thanks!
 
Alvaro.
 
 
 
> [XM]>>> As far as I can tell, the cross-wg review and communication can
> always be improved. As to this case, the idea is that (like RFC9197) the main
> document defines a generic format that can be reused by some follow-on
> documents, avoiding repetitive definition of the same format in multiple
> documents. For IPv6 (including SRv6), draft-xiao-6man-icmpv6-ioam-conf-state
> has been submitted as the follow-on document, which was presented twice (at
> IETF 112 and 114) in 6man and some good discussions happened at the meeting
> and on the mailing list. For MPLS (including SR-MPLS),
> draft-xiao-mpls-lsp-ping-ioam-conf-state has been submitted as the follow-on
> document, which is on the agenda for mpls@IETF-115. For SFC and BIER, the
> follow-on documents are in the plan (note that one co-author of the main
> document is also the primary author of SFC echo request/reply and a co-author
> of BIER echo request/reply). You're right we authors could have done more
> consultations with the corresponding WGs, and I promise to make the
> improvement in the future.
>