Hi, Chris: For the use case A.1(inter-as topology recovery), RFC9346/RFC5392 based solution requires the prerequisite knowledge of remote identifier on each stub link. Considering there maybe tens/hundreds of links among the ASBRs, there is no easy way to get such information automatically now.
And, there are situations that the stub links are not the inter-as link【use case A.2(Egress Engineering for Anycast Servers)]】, which is not suitable to reuse the RFC9346/RFC5392 based solution. Then, it is necessary to extend the protocol to solve the above scenarios in one general manner. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Christian Hopps 发送时间: 2024年1月10日 18:17 收件人: Huzhibo <[email protected]> 抄送: Acee Lindem <[email protected]>; Yingzhen Qu <[email protected]>; [email protected] 主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) [As WG Co-Chair] Hi Folks, Before posting support reasons please read and considerl *all* the email in the archive covering the first failed adoption call. https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/ https://www.mail-archive.com/search?l=lsr%40ietf.org&q=stub+link&x=0&y=0 This adoption call should be considering if the changes made to the document since it failed to be adopted the first time, are sufficient to reverse the WGs previous decision. [As WG Member] To repeat from the first failed adoption call... "Reducing configuraiton" is not a reason to modify the routing protocols. Operators aren't doing by-hand manual configuration, and even if they were we shouldn't be trying to support it in this day and age. Thanks, Chris. Huzhibo <[email protected]> writes: > Hi Acee: > > > > You're right, there are alternatives to address inter-domain > link advertisements, and this document attempts to address such issues > in a more simplified way, reducing the number of BGP-LS sessions > required, or avoid the configurations related to the peering AS > domains as required by RFC 9346. Do you have any suggestions for the > problems this article is trying to solve? > > > > Thanks > > Zhibo Hu > > > > From: Lsr [mailto:[email protected]] On Behalf Of Acee Lindem > Sent: Tuesday, January 9, 2024 3:03 AM > To: Yingzhen Qu <[email protected]> > Cc: lsr <[email protected]> > Subject: Re: [Lsr] WG Adoption Call - > draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) > > > > Speaking as WG member: > > > > I don’t support adoption of this draft. > > > > First of all, I think the basic premise of the draft is flawed in that > a link is advertised as a stub and, from that, one can deduce uses of > the link. Why not just advertise what is being deduced? > > > > Second, I don’t think the draft is necessary. The use case in A.1 is > solely for an IGP router to advertise this stub link characteristic to > a controller for inter-AS TE. Since it is only for the controller why > wouldn’t be BGP-LS be used? It seems this is how it ultimately gets to > the controller anyway. Furthermore, if it were to be put into the > IGPs, why wouldn’t something like RFC 9346 be used for inter-AS TE? > For the use case in A.2, anycast prefix advertisement is already > handled and documents exist to identify a prefix as an anycast > address. For the use case in A.3, I don’t even understand how it works > or what is supposed to happen between BGP and the IGPs? What is > different about this from normal BGP route recursion over the IGP > route? For this, the fact that it is a stub link is irrelevant. > > > > Thanks, > > Acee > > > > > > > > > > On Jan 5, 2024, at 19:23, Yingzhen Qu <[email protected]> > wrote: > > > > Hi, > > > > This begins a 2 week WG Adoption Call for the following draft: > > > > > https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ > > > > Please indicate your support or objections by January 19th, 2024. > > > > Authors, please respond to the list indicating whether you are aware of > any IPR that applies to the draft. > > *** Please note that this is the second WG adoption poll of the > draft. The first one was tried two years ago and you can see the > discussions in the archive: > > [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 > (ietf.org) > > > > Thanks, > > Yingzhen > > > > > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
