Hi, Acee:
发件人: [email protected] [mailto:[email protected]] 代表 Acee Lindem 发送时间: 2024年1月16日 6:44 收件人: Aijun Wang <[email protected]> 抄送: Christian Hopps <[email protected]>; Liyan Gong <[email protected]>; Yingzhen Qu <[email protected]>; lsr <[email protected]>; lsr-chairs <[email protected]> 主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes(01/05/2024 - 01/19/2024) 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. [WAJ]: The requirements for inter-AS TE and the requirements for inter-AS topology recovery are different. The key difference is that the previous covers only some of the inter-AS links, but the latter must cover all of the links between the AS. Then find some efficient way to solve the inter-AS recovery problem is necessary. See inline. On Jan 15, 2024, at 09:02, Aijun Wang <[email protected] <mailto:[email protected]> > 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)? [WAJ]:The procedures for A.2 and A.3 are similar: the receiving router can select the optimal forwarding path(or network exit), based on the attributes of the stub links. Currently, all the selections are based on the characteristics/attributes of internal links. 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. [WAJ] To rebuild the inter-as topology, we don’t need the above information from other sides, thus reduces the error-prone chances. What we assuming is that the stub link should share the same subnet, we can connect the two ends of the stub link automatically based on such assumption. If there is some errors for the shared prefix, the two ends can’t communicate with each other at all. 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 <[email protected] <mailto:[email protected]> > wrote: On Jan 15, 2024, at 06:27, Aijun Wang <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > wrote: Liyan Gong <[email protected] <mailto:[email protected]> > 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 <[email protected] <mailto:[email protected]> > 收件人：lsr <[email protected] <mailto:[email protected]> >,lsr-chairs <[email protected] <mailto:[email protected]> > 抄 送: (无) 发送时间：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 [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] <mailto:[email protected]> https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
