[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
