Thank you for your response.
To be clear. We are implementing IFIT, that is, the basic measurement and
monitoring. In the deployment, we need to bound the test traffic within a
But right now we can only use manual configuration. Motivated by this, the
protocol-based automation is required.
I think the proposed IGP extension is useful and meets our requirement well.
发件人: Christian Hopps [mailto:cho...@chopps.org]
发送时间: 2020年7月20日 19:35
抄送: Christian Hopps; wangyali; email@example.com
主题: Re: [Lsr] New Version Notification for
So full speed ahead and ignoring the views expressed in the LSR WG? This is not
a recipe for success if you are basing your implementation on using LSR
[As WG member]
> On Jul 19, 2020, at 9:30 PM, qinfengwei wrote:
> IFIT Capability Advertisement accurately tracks the urgent requirements
> and real challenges when IFIT implementation.
> Right now, the IFIT test has been performed and is under
> implementation. We found that signaling Node IFIT capability to ingress nodes
> is indeed helpful for determining whether IFIT header and data fields could
> be encapsulated in packets.
> Fengwei Qin
> 发件人: wangyali [mailto:wangyal...@huawei.com]
> 发送时间: 2020年7月16日 23:20
> 收件人: 'firstname.lastname@example.org'
> 主题: FW: New Version Notification for draft-wang-lsr-igp-extensions-ifit-00.txt
> Dear LSR WG,
> We've uploaded a new revision of draft-wang-lsr-igp-extensions-ifit-00 to
> replace draft-wang-lsr-ifit-node-capability-advertisement. In this new
> revision, Node and Link Attribute TLVs are extended to IGP for signaling the
> supported IFIT capability of egress and/or intermediate nodes to the ingress
> The changes in this revision are:
> 1. added Link Attribute TLVs extension to IGP to signal IFIT Capability at
> link granularity.
> 2. updated Application section, which illustrates such advertisements would
> helpful for avoiding the leak of IFIT-specific header and metadata, as well
> as, for ingress routers to gather each router's IFIT capability for achieving
> the computation of TE paths or loose TE paths that be able to fulfill the
> visibility of on-path OAM data.
> 3. updated Acknowledgements sections, in which, the authors would like to
> thank Acee Lindem, Christian Hopps, Robert Raszuk, Les Ginsberg, Jeff
> Tantsura, Rakesh Gandhi, Tony Li and Greg Mirsky for the comments.
> 4. adding China Telecom into the author list.
> We are looking forward to hearing your feedback and comments, and try to
> achieve consensus.
> -Original Message-
> From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
> Sent: Monday, July 13, 2020 9:15 PM
> To: Tianran Zhou ; wangyali ;
> Huanan Chen ; Liumin (Lucy)
> ; Ran Pang ; Liumin (Lucy)
> Subject: New Version Notification for
> A new version of I-D, draft-wang-lsr-igp-extensions-ifit-00.txt
> has been successfully submitted by Yali Wang and posted to the IETF
> Name: draft-wang-lsr-igp-extensions-ifit
> Revision: 00
> Title: IGP Extensions for In-situ Flow Information Telemetry (IFIT)
> Capability Advertisement
> Document date: 2020-07-12
> Group: Individual Submission
> Pages: 12
> This document extends Node and Link Attribute TLVs to Interior
> Gateway Protocols (IGP) to advertise supported In-situ Flow
> Information Telemetry (IFIT) capabilities at node and/or link
> granularity. An ingress router cannot insert IFIT-Data-Fields for
> packets going into a path unless an egress router has indicated via
> signaling that it has the capability to process IFIT-Data-Fields. In
> addition, such advertisements would be useful for ingress routers to
> gather each router's IFIT capability for achieving the computation of
> Traffic Engineering (TE) paths or loose TE paths that be able to
> fulfill the visibility of on-path OAM data.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized versio