[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 <huzhibo=40huawei....@dmarc.ietf.org> 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:lsr-boun...@ietf.org] On Behalf Of Acee Lindem Sent: Tuesday, January 9, 2024 3:03 AM To: Yingzhen Qu <yingzhen.i...@gmail.com> Cc: lsr <lsr@ietf.org> 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 <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/ 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr