Hi Acee & Les Thank you for your comments. 1、Using Tag, it is step 1 of redistribution policy to identity the route to pick out these incoming or outgoing routing prefix. The tag setting and matching have a little bit complex if service traffic requirement have a great deal of different routing prefix go through different multiple protocol domain path. 2、For step 2 of redistribution policy, it must be considered to impact routing selection using complicated cost and preference configuration, instead of only filter, the step 2 have more trouble and challenge, each protocol have different default redistribution principle. it need exact configuration depend on different scenario. In fact some multiple domain scenario have nature routing loop problem if without preference adjustment. 3、For more difficult, any network change related to topology change or IP range change on any of single protocol domain, network engineer must to review whole network each redistribution points policy configuration. The traditional tag solution maintenance already faced with big risk and challenge for current complex architecture. 4、so we need the "TTR" attenuation mechanism as united and simple method , including ISIS/OSPF/BGP extension, to prevent routing loop and ensure correct routing selection, rather than each protocol have individual method. 5、For partial deployment, let the "TTR" attenuation function default is disable but support extension firstly, it is not effect to routing selection for existing network intermediate status. the existing traditional tag solution still is preferred. The "TTR" attenuation is enabled until full network extension deployment or new network.
Thanks Regards WQ -----邮件原件----- 发件人: Les Ginsberg (ginsberg) [mailto:ginsb...@cisco.com] 发送时间: 2023年3月11日 3:00 收件人: Acee Lindem <acee.i...@gmail.com>; Wangqiang (WQ) <wangqian...@huawei.com> 抄送: Yingzhen Qu <yingzhen.i...@gmail.com>; lsr-cha...@ietf.org; lsr@ietf.org 主题: Comments on draft-wang-lsr-redistribution-credibility-id (Changing the subject to avoid confusion with all other "slot requests") I agree with Acee that there are existing solutions for this problem space. I also believe your approach is quite problematic. To maintain the count ("TTR") accurately, you would require full deployment of this extension - partial deployment would not be viable. Also, you are proposing changes to route preference, which means you are altering the IS-IS Route Preference rules as defined in RFC 7775/RFC5302. With partial deployment, we would be at risk for loops as some nodes would be operating on existing preference rules and some nodes would be operating on revised preference rules. Given these issues and the fact that there is no compelling need for a new solution, I do not see a future for this draft - or its predecessor draft-yue-lsr-loop-detection-for-imported-routes. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem > Sent: Friday, March 10, 2023 4:52 AM > To: Wangqiang (WQ) <wangqian...@huawei.com> > Cc: Yingzhen Qu <yingzhen.i...@gmail.com>; lsr-cha...@ietf.org; > lsr@ietf.org > Subject: Re: [Lsr] Slot request for LSR IETF 116 > > Speaking as WG Member: > > Hi WQ, > > I have no doubt that your proposed extension could be used to suppress > redistribution loops between routing domains. The question is why this > is needed when this has been accomplished using route tags for > decades. This is a solved problem and you need to convince the WG that > using route tags doesn’t work. > > Thanks, > Acee > > > On Mar 9, 2023, at 8:40 PM, Wangqiang (WQ) > <wangqian...@huawei.com> wrote: > > > > Hi Acee & Yingzhen, > > I would like to apply for a timeslot. > > Draft：draft-wang-lsr-redistribution-credibility-id-00(Route > > Redistribution > Credibility ID for Avoiding Routing Loop) > > Presenter name: Qiang Wang > > Estimated time: 10 mins > > A new version of I-D, > > draft-wang-lsr-redistribution-credibility-id-00.txt > > has been successfully submitted by Qiang WANG and posted to the IETF > repository. > > Name: draft-wang-lsr-redistribution-credibility-id > > Revision: 00 > > Title: Route Redistribution Credibility ID for Avoiding > > Routing Loop > > Document date: 2023-03-02 > > Group: Individual Submission > > Pages: 5 > > URL: > > https://www.ietf.org/archive/id/draft-wang-lsr-redistribution- > credibility-id-00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-wang-lsr-redistribution- > credibility-id/ > > Htmlized: https://datatracker.ietf.org/doc/html/draft-wang-lsr- > redistribution-credibility-id > > Thanks > > Regards > > WQ > > 发件人: Lsr [mailto:lsr-boun...@ietf.org] 代表 Yingzhen Qu > > 发送时间: 2023年3月1日 2:37 > > 收件人: lsr-chairs <lsr-cha...@ietf.org>; lsr <lsr@ietf.org> > > 主题: [Lsr] Slot request for LSR IETF 116 Dear LSR WG: > > The preliminary agenda for IETF 116 has been released, and the LSR > session is scheduled on Monday Session I (9:30-11:30). > > Please send your presentation request to LSR WG chairs (lsr- > cha...@ietf.org) before the end of Monday March 13 with the following info: > > · draft to be presented > > · presenter name > > · estimated time needed, including Q&A If there is any question, > > please let me know. > > Thanks, > > Yingzhen > > > _______________________________________________ > 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
