Speaking as WG member: Hi Aijun,
I know you have gotten some of your co-authors on other drafts and colleagues to parrot your arguments in favor of this draft. However, you still have not addressed my comments. Why is better to advertise the link as stub link and surmise that it is an inter-AS link than it is to advertise this inter-AS status directly? Presumably, if you advertise this inter-AS link, you’re going to have routes using the link. If you have routes using the link, you’d think that you’d know the AS of these routes and this is not “inefficient” as you characterize it. It would seem if you going to use this link for intra-AS TE, you should know the AS to which this is directed. I don’t see why your encoding is any more efficient. See inline. > On Jan 15, 2024, at 09:02, Aijun Wang <wangai...@tsinghua.org.cn> wrote: > > 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.wor The use cases in A.2 and A.3 aren’t applicable. For anycast servers, why you this have anything to do with stub links? More protocol intuition? We have mechanisms advertise anycast prefixes - arguing that this a use case for stub links is just wrong. As for A.3, how does this even work? Why couldn’t this just be done on the prefix to which BGP routes resolve (as it is done today)? > > 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. How is what you are proposing better? Since you are ASSUMING that a stub link connects another AS, it is even more error-prone. Thanks, Acee > > 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
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
