Hi, Chris： There are significant changes from the last adoption call(version 02) to the current version(version 08). Then I doubt the valid information from the previous discussions.
For example, there is no concrete use cases description in the previous version, which is provided in the appendix A.1-A.3 of current version. There are also the updates for the protocol extension, which absorbs the experts’ various comments from the last update. Until know, it seems people focus mainly on the use cases, we have explained them to them at https://mailarchive.ietf.org/arch/msg/lsr/er9iQ6sgEmvqJSCz_vtZjQ6FB-g/. If there is more question on the responses, please continue the discussion. Regarding to the use case A.1 (Figure 1)which what you mentioned as one failed use case of the first adoption call, what we want to emphasize is that it is not only the configuration challenges in the complex network, but also how to get the correct/error-proof information automatically from the other sides. Such challenges are also mentioned in the existing RFC https://www.rfc-editor.org/rfc/rfc9346.html#section-4.1, https://www.rfc-editor.org/rfc/rfc9346.html#section-5 and also the corresponding parts of RFC5392. Then, If there is solution that can bypass these challenges, why don’t we adopt it? For use case A.1(Figure 2), as Huaimo points out, the existing RFC cannot solve the requirements. For use case A.2, the inter-AS based solution cannot solve the non inter-AS scenario. For use case A.3, it has the same benefits as that for use case A.1(Figure 1) when compared with the existing solution. The differences are that A.1(Figure) focuses on the topology recovery, A.3 focuses on forward path optimization. When we consider whether one proposal is reasonable enough, we should not only consider the implementation possibilities, but also the deployment challenges(not configuration/management). If it is not practical for the deployment, then what’s the value of standard/implementation? And, people are arguing that there exists inter-AS TE solutions(RFC9346/RFC5392), but how many operators have deployed them in the network? Are anyone considering the reason that hinders their deployments? Aijun Wang China Telecom > On Jan 15, 2024, at 17:35, Christian Hopps <cho...@chopps.org> wrote: > > Liyan Gong <gongli...@chinamobile.com> writes: > >> Hi WG, >> >> >> I Support its adoption. >> >> Currently there is no automatic and error-proof way to get the >> related information of the other ends for inter-as links, it is >> difficult for operator to rebuild the complex inter-as topology. >> >> The proposed protocol extension in this draft can assist the operator >> to overcome the above obstacles. > > [As WG member] > > This use-case is covered by other solutions, and was discussed and denied as > a reason to adopt already in the first failed adoption call. > > [As co-char] > > This second call for adoption indicated that people should go and read the > first failed adoption call and the ton of email it generated. Repeating the > same points found technically lacking the first time is unproductive and will > not positively influence rough consensus a second time just b/c they are > being repeated over and over. > > Thanks, > Chris. > > >> >> >> Best Regards, >> >> Liyan >> >> >> ----邮件原文---- >> 发件人：Yingzhen Qu <yingzhen.i...@gmail.com> >> 收件人：lsr <lsr@ietf.org>,lsr-chairs <lsr-cha...@ietf.org> >> 抄 送: (无) >> 发送时间：2024-01-06 08:23:00 >> 主题：[Lsr] >> WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/ >> 2024 - 01/19/2024) >> >> 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
