Hi, Acee:
发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee Lindem 发送时间: 2024年1月9日 3:03 收件人: Yingzhen Qu <yingzhen.i...@gmail.com> 抄送: lsr <lsr@ietf.org> 主题: 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? [WAJ]: The stub links are existing at the network boundary. We can’t advertise them as one normal IGP link. Then, what’s your proposal that “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. [WAJ]: As explained in the document----“it is required that the BGP-LS to be enabled on every router that has the stub links, which is challenging for the network operation. It is desirable to advertise the stub link info into the IGP to ease the deployment of BGP-LS on any router in the IGP domain.” Furthermore, if it were to be put into the IGPs, why wouldn’t something like RFC 9346 be used for inter-AS TE? [WAJ] It is very inefficient. We have explained this point several times before-----the operator must appoint the identification of remoted devices for each stub link. For the use case in A.2, anycast prefix advertisement is already handled and documents exist to identify a prefix as an anycast address. [WAJ] The motivation of use case in A.2 is not for advertising the anycast prefix, but for the selection of optimal path to the anycast server.----“It will be help for the router R0, to know the attributes of the stub links and select the optimal Anycast server to serve the customer's application” 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. [WAJ] There are multiple routes(include the stub links among the AS) between the BGP neighbors(R10 and R20). They can select the optimal ones to install into their RIB/FIB, to reach each other, after considering on the characteristics of the stub link. Thanks, Acee On Jan 5, 2024, at 19:23, Yingzhen Qu <yingzhen.i...@gmail.com <mailto:yingzhen.i...@gmail.com> > 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/> 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) <https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/> Thanks, Yingzhen
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
