Hi, Chris: The first adoption call focus on the A.1 use case(figure 1), not cover all of the use case that listed in A.1-A.3 For A.1(Figure 1) use case, previous discussions focus on mainly the benefits of the configuration simplification, which you emphasize that IGP does not mainly for such work.
OK, now let us consider other issues of the existing solutions——how to get the related information automatically and error-proofing? RFC9346 and RFC 5392 mentioned all such challenges, they even propose to use BGP to cross verify such information, which is still on the imagination stage. Then, if there is solution can bypass such requirements, should we consider it then? Especially from the deployment viewpoint of the operator? Together with the above points, the proposed solution can cover other use cases, which are not discussed throughly in previous adoption call. If one proposal can simply the deployment requirements of existing solution for some cases(A.1 Figure 1 and A.3), can solve some case that existing solution can’t(A.1 Figure 2 and A.2) should we accept it then? We can discuss throughly on the above statements then for the second adoption call, pass the configuration simplification arguments. Aijun Wang China Telecom > On Jan 15, 2024, at 20:19, Christian Hopps <cho...@chopps.org> wrote: > > > >> On Jan 15, 2024, at 06:27, Aijun Wang <wangai...@tsinghua.org.cn> wrote: >> >> 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. > > [As WG member] > > The original use case may not have been listed in previous document, but it > was discussed very thoroughly during the adoption call. > > It did not convince the WG to adopt the first time, b/c the WG felt existing > solutions were sufficient -- nothing changed with respect to this for this > second adoption call that I see. > > Thanks, > Chris. > >> >> 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
