Re: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05

xiao.min2@zte.com.cn Mon, 18 January 2021 02:00 UTC

Return-Path: <xiao.min2@zte.com.cn>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF193A0C3B for <mpls@ietfa.amsl.com>; Sun, 17 Jan 2021 18:00:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.916
X-Spam-Level:
X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6BvtNay3kVE for <mpls@ietfa.amsl.com>; Sun, 17 Jan 2021 18:00:39 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74E4F3A0C3A for <mpls@ietf.org>; Sun, 17 Jan 2021 18:00:38 -0800 (PST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 393C793B44FC3757F4B4; Mon, 18 Jan 2021 10:00:36 +0800 (CST)
Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl1.zte.com.cn with SMTP id 10I20H7G082086; Mon, 18 Jan 2021 10:00:17 +0800 (GMT-8) (envelope-from xiao.min2@zte.com.cn)
Received: from mapi (njxapp02[null]) by mapi (Zmail) with MAPI id mid201; Mon, 18 Jan 2021 10:00:16 +0800 (CST)
Date: Mon, 18 Jan 2021 10:00:16 +0800
X-Zmail-TransId: 2afa6004ebb0133bf49d
X-Mailer: Zmail v1.0
Message-ID: <202101181000168475475@zte.com.cn>
In-Reply-To: <13ba46a9-1aa9-0693-7f27-5026bf3a5da3@pi.nu>
References: 202101120949094647407@zte.com.cn, 13ba46a9-1aa9-0693-7f27-5026bf3a5da3@pi.nu
Mime-Version: 1.0
From: xiao.min2@zte.com.cn
To: loa@pi.nu
Cc: mpls@ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn 10I20H7G082086
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/HT4jrVQsUloOxJCkowbcHHsWdys>
Subject: Re: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jan 2021 02:00:42 -0000

Hi Loa,




Thank you for your comments.
Please see inline my responses with <XM>.




Best Regards,
Xiao Min



原始邮件



发件人:LoaAndersson
收件人:肖敏10093570;mpls@ietf.org;
日 期 :2021年01月17日 13:04
主 题 :Re: [mpls] Comment on draft-gandhi-mpls-ioam-sr-05


Xiao,
 
imline please.
 
 
On 12/01/2021 09:49, xiao.min2@zte.com.cn wrote:
> Hi authors,
>  
> While looking through the updated -05 version of this draft, a question  
> emerged in my mind, with the separated Edge-to-Edge IOAM Indicator Label  
> and Hop-by-Hop IOAM Indicator Label,
 
FWIW my take here is that the Edge-to-Edge IOAM only is processed on the  
edge nodes and that Hop-by-Hop IOAM is processed by all nodes on along  
the LSP, including the edge node.
<XM> I absolutely agree.


how can the network operator
> achieve both the Edge-to-Edge IOAM and Hop-by-Hop IOAM simultaneously?
 
If I understand this correctly that is what is done by Hop-by-Hop IOAM.
<XM> Per IOAM itself, the Edge-to-Edge IOAM and Hop-by-Hop IOAM are independent of each other, they use different IOAM Option-Type. Per MPLS indicator label, I agree with you that Hop-by-Hop IOAM indicator label can be reused here, but IMHO the current text in this draft is not clear on it.



> I think there are two ways to achieve that, one way is to define the  
> third IOAM Indicator Label which indicates the existence of both  
> Edge-to-Edge IOAM and Hop-by-Hop IOAM,  
 
I don't see that as necessary, isn't that what the Hop-by-Hop IOAM  
indicator does.
<XM> See above.


another way is to merge the
> current two IOAM Indicator Labels and let the IOAM Option-Type to tell  
> the difference between Edge-to-Edge IOAM and Hop-by-Hop IOAM.
 
Does that mean that even if you are only Edge-to-Edge IOAM  you need to  
inspect the IOAM Option-Type on every node for evey packet?
<XM> Yes, correct. Actually you provide the third way to reuse the Hop-by-Hop IOAM indicator label, for the network operator to achieve both the Edge-to-Edge IOAM and Hop-by-Hop IOAM simultaneously. Acc to the reply from the author, the third way you provide is preferred by the authors, then I suggest to document this way explicitly, in my view this way is not reflected in the current text clearly.


My 2 c's, but I'm willing to be corrected.
 
/Loa
>  
> Best Regards,
> Xiao Min
>  
> 原始邮件
> *发件人:*internet-drafts@ietf.org
> *收件人:*i-d-announce@ietf.org ;
> *抄送人:*mpls@ietf.org;
> *日 期 :*2021年01月09日 23:49
> *主 题 :**[mpls] I-D Action: draft-gandhi-mpls-ioam-sr-05.txt*
>  
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Multiprotocol Label Switching WG of the IETF.
>  
>          Title           : MPLS Data Plane Encapsulation for In-situ OAM Dataloo
>          Authors         : Rakesh Gandhi
>                            Zafar Ali
>                            Clarence Filsfils
>                            Frank Brockners
>                            Bin Wen
>                            Voitek Kozak
>      Filename        : draft-gandhi-mpls-ioam-sr-05.txt
>      Pages           : 14
>      Date            : 2021-01-09
>  
> Abstract:
>     In-situ Operations, Administration, and Maintenance (IOAM) records
>     operational and telemetry information in the data packet while the
>     packet traverses a path between two nodes in the network.  This
>     document defines how IOAM data fields are transported with MPLS data
>     plane encapsulation using new Generic Associated Channel (G-ACh),
>     including Segment Routing (SR) with MPLS data plane (SR-MPLS).
>  
>  
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-gandhi-mpls-ioam-sr/
>  
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-gandhi-mpls-ioam-sr-05
> https://datatracker.ietf.org/doc/html/draft-gandhi-mpls-ioam-sr-05
>  
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-gandhi-mpls-ioam-sr-05
>  
>  
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>  
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>  
>  
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>  
>  
>  
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>  
 
--  
 
Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64