Hi Chris., 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 limited domain. 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. Thanks, Fengwei Qin -----邮件原件----- 发件人: Christian Hopps [mailto:cho...@chopps.org] 发送时间: 2020年7月20日 19:35 收件人: qinfengwei 抄送: Christian Hopps; wangyali; lsr@ietf.org 主题: Re: [Lsr] New Version Notification for draft-wang-lsr-igp-extensions-ifit-00.txt 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 protocols. Thanks, Chris. [As WG member] > On Jul 19, 2020, at 9:30 PM, qinfengwei <qinfeng...@chinamobile.com> wrote: > > Hi, > 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. > > > > Thanks, > Fengwei Qin > > -----邮件原件----- > 发件人: wangyali [mailto:wangyal...@huawei.com] > 发送时间: 2020年7月16日 23:20 > 收件人: 'lsr@ietf.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 > nodes. > > 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. > > Thanks, > Yali > > > -----Original Message----- > From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] > Sent: Monday, July 13, 2020 9:15 PM > To: Tianran Zhou <zhoutian...@huawei.com>; wangyali <wangyal...@huawei.com>; > Huanan Chen <chenhu...@chinatelecom.cn>; Liumin (Lucy) > <lucy.liu...@huawei.com>; Ran Pang <pang...@chinaunicom.cn>; Liumin (Lucy) > <lucy.liu...@huawei.com> > Subject: New Version Notification for > draft-wang-lsr-igp-extensions-ifit-00.txt > > > 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 > repository. > > 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 > URL: > https://www.ietf.org/internet-drafts/draft-wang-lsr-igp-extensions-ifit-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wang-lsr-igp-extensions-ifit/ > Htmlized: > https://tools.ietf.org/html/draft-wang-lsr-igp-extensions-ifit-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-wang-lsr-igp-extensions-ifit > > > Abstract: > 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 version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
