Hi all, The adoption call is closed, and the document is not adopted.
The author has requested an extension of the adoption call for one week, however since we fail to see new technical points being discussed, the chairs decided to close the call as planned. During the second adoption call, the discussion has been focusing on simplifying inter-as link discovery and topology management although there are existing solutions. Additionally the added use cases were discussed, but are also covered by existing solutions. No rough consensus has been reached about the use cases, nor the solution. Please note: many of the same points were discussed in the first adoption call. In the future, if the authors are to request another adoption call, the condition will be to have a discussion on the list first and achieve rough consensus of the use case and solution. Thanks, Acee, Chris and Yingzhen (LSR Co-chairs) On Thu, Jan 18, 2024 at 5:52 PM Aijun Wang <wangai...@tsinghua.org.cn> wrote: > Hi, Les: > > > > Let’s top post my responses to your specific questions: > > > > *1) **LAN partitioning can occur. So R1 and R2 may be able to talk > to each and R3 and R4 may be able to talk to each – but the two partitions > have no connectivity. Yet all nodes will advertise the LAN subnet – which > in your world means that you think you have full connectivity when you do > not. * > > [WAJ] If the partition is occurred by design, then R1-R4 should not > declare the same subnet; if the partition is occurred by the switch faulty, > it needs other OAM tools to detect. This is also true for the P2P based > existing solutions(RFC9346/RFC5392). > > > > *2) **Your draft says: “It will be help for the router R0, to know > the attributes of the stub links and select the optimal Anycast server to > serve the customer's application.”.* > > *Given that you don’t actually know which of the anycast servers each of > the border routers can reach (you just “assume” it is all of them) the > ability of R0 to make a correct decision is compromised.* > > [WAJ] Here, “the optimal Anycast server” refer to the “the optimal > path(exits) to Anycast server”. The reason that we use Anycast is that all > these servers can provide the same services. The difference is that the > path attributes(internal links and stub link) to them. > > > > Wish the above explanations can address your concerns. > > > > > > Best Regards > > > > Aijun Wang > > China Telecom > > > > *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] *代表 > *Les Ginsberg (ginsberg) > *发送时间:* 2024年1月19日 0:51 > *收件人:* Aijun Wang <wangai...@tsinghua.org.cn> > *抄送:* 'Christian Hopps' <cho...@chopps.org>; 'Huzhibo' <huzh...@huawei.com>; > 'Acee Lindem' <acee.i...@gmail.com>; 'Yingzhen Qu' < > yingzhen.i...@gmail.com>; lsr@ietf.org > *主题:* Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > > > Aijun – > > > > Frankly, I have a limited tolerance for these exchanges because your > responses to specific points are evasive. > > You are like a boxer whose main goal is to avoid any punch thrown by your > opponent from landing directly. This is a pretty useful skill in a boxing > ring, but pretty tiresome when trying to have a frank exchange of views on > the technical points of a draft. > > I am unlikely to respond further after this – but please find some > responses inline. See [LES2:]. > > > > *From:* Aijun Wang <wangai...@tsinghua.org.cn> > *Sent:* Thursday, January 18, 2024 1:29 AM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* 'Christian Hopps' <cho...@chopps.org>; 'Huzhibo' <huzh...@huawei.com>; > 'Acee Lindem' <acee.i...@gmail.com>; 'Yingzhen Qu' < > yingzhen.i...@gmail.com>; lsr@ietf.org > *Subject:* 答复: [Lsr] WG Adoption Call - > draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) > > > > Hi, Les: > > > > *发件人:* forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org > <forwardingalgori...@ietf.org>] *代表 *Les Ginsberg (ginsberg) > *发送时间:* 2024年1月18日 0:16 > *收件人:* Aijun Wang <wangai...@tsinghua.org.cn> > *抄送:* Christian Hopps <cho...@chopps.org>; Huzhibo <huzh...@huawei.com>; > Acee Lindem <acee.i...@gmail.com>; Yingzhen Qu <yingzhen.i...@gmail.com>; > lsr@ietf.org > *主题:* Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > > > Aijun - > > > > *From:* Aijun Wang <wangai...@tsinghua.org.cn> > *Sent:* Tuesday, January 16, 2024 10:56 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* Christian Hopps <cho...@chopps.org>; Huzhibo <huzh...@huawei.com>; > Acee Lindem <acee.i...@gmail.com>; Yingzhen Qu <yingzhen.i...@gmail.com>; > lsr@ietf.org > *Subject:* Re: [Lsr] WG Adoption Call - > draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) > > > > Hi, Les: > > > > Let’s keep the discussions simple. > > > > Please answer the following two questions that you haven’t responsed > directly in previous mail: > > 1) How the existing point-to-point based solution(RFC9346/RFC5392) > solve the broadcast(LAN, A.1 Figure2) inter-AS topology recovery > scenario---There are multiple neighbors on one interfaces, which are > located in different AS. How to encode the information within one inter-AS > reachability TLV? > > > > *[LES:] In the absence of the existence of an advertisement of the LAN > itself (the “pseudonode” in IS-IS), a LAN is represented as a set of P2P > links between each of the nodes connected to the LAN.* > > *Less scaleable but just as functional.* > > > > *You, however, think you can get away with “If R1 advertises connectivity > to the LAN subnet and R2 and R3 also advertise connectivity to the same > subnet that we can assume that they are all connected” – which is an > assumption that works some of the time – but is not guaranteed.* > > *It is easy to imagine this case if there is a switch and one of the ports > on the switch is faulty. (Other failure scenarios exist)* > > > > *[WAJ] If one of the ports on the switch is faulty, then the router that > connected is disconnected from the subnet. The topology recovery will not > include this router.* > > > > *[LES2:] You have missed the point. LAN partitioning can occur. So R1 and > R2 may be able to talk to each and R3 and R4 may be able to talk to each – > but the two partitions have no connectivity. Yet all nodes will advertise > the LAN subnet – which in your world means that you think you have full > connectivity when you do not. * > > > > 2) How the inter-AS based solutions solve the non inter-AS > scenario requirements(A.2)? > > > > *[LES:] An interesting question given that you haven’t addressed this > yourself.* > > *What does it mean to advertise reachability to an anycast address (as you > propose to do)?* > > *Does that tell you if you are connected to one of anycast servers? Some > of the anycast servers? All of the anycast servers?* > > *[WAJ] All of the anycast servers* > > > > *You don’t know – you are just assuming.* > > *But since your goal is “topology discovery” it is important to actually > know whether you have a link to a particular anycast server or not.* > > *You don’t know – you just assume.* > > *[WAJ] For A.2, the aim is not topology discovery, the aim is to select > the optimal path(or exits) that to the anycast server, based not only the > internal link information, but also the stub link information that connects > to the server.* > > > > *[LES2:] Your draft says: “It will be help for the router R0, to know the > attributes of the stub links and select the optimal Anycast server to serve > the customer's application.”.* > > *Given that you don’t actually know which of the anycast servers each of > the border routers can reach (you just “assume” it is all of them) the > ability of R0 to make a correct decision is compromised.* > > > > * Les* > > > > One point that I want to remind for your misunderstanding: the proposed > Stub-link TLV can contain other attributes sub-TLVs of the link. > > And, if the interfaces share the same prefixes, they are in the same IP > subnet. Is there any ambiguously for the IP topology recovery? > > > > What I want to emphasize is that the existing solutions are suitable for > inter-AS point-to-point TE, the proposed solutions are suitable(more > efficient)for inter-AS topology recovery(p2p, p2mp and broadcast etc.) and > also other non inter-as traffic optimization scenarios. They are not > contrary. > > > > *[LES:] AFAICT, your sole aim is efficiency – and you have given no > thought to validating the actual topology.* > > *[WAJ]: If you have any scenario, that the proposed solution can’t give > the actual topology, please illustrate it or them.* > > > > * Les* > > > > > > Aijun Wang > > China Telecom > > > > On Jan 17, 2024, at 00:57, Les Ginsberg (ginsberg) < > ginsberg=40cisco....@dmarc.ietf.org> wrote: > > > > Aijun – > > > > Please see inline. > > > > *From:* Aijun Wang <wangai...@tsinghua.org.cn> > *Sent:* Tuesday, January 16, 2024 12:18 AM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; 'Christian Hopps' < > cho...@chopps.org>; 'Huzhibo' <huzh...@huawei.com> > *Cc:* 'Acee Lindem' <acee.i...@gmail.com>; 'Yingzhen Qu' < > yingzhen.i...@gmail.com>; lsr@ietf.org > *Subject:* 答复: [Lsr] WG Adoption Call - > draft-wang-lsr-stub-link-attributes (01/05/2024 - 01/19/2024) > > > > Hi, Les: > > > > -----邮件原件----- > 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org > <forwardingalgori...@ietf.org>] 代表 Les Ginsberg (ginsberg) > 发送时间: 2024年1月16日 0:16 > 收件人: Christian Hopps <cho...@chopps.org>; Huzhibo < > huzhibo=40huawei....@dmarc.ietf.org> > 抄送: Acee Lindem <acee.i...@gmail.com>; Yingzhen Qu < > yingzhen.i...@gmail.com>; lsr@ietf.org > 主题: Re: [Lsr] WG Adoption Call - draft-wang-lsr-stub-link-attributes > (01/05/2024 - 01/19/2024) > > > > I respect that individuals may have different opinions - but it is > important to distinguish what is factual from what is not. > > Opinions based upon false information are clearly compromised. > > > > Please do heed Chris's (as WG chair) admonition to review the first WG > adoption thread. That will reveal to you what the substantive objections > were. > > > > 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 > > > > > > Please also do examine the delta between the previous version which was > put up for WG adoption (V3) and the current version (V8) so you can see > what has changed. > > > https://author-tools.ietf.org/iddiff?url1=draft-wang-lsr-stub-link-attributes-03&url2=draft-wang-lsr-stub-link-attributes-08&difftype=--html > > > > Some facts: > > > > The substantive objections raised during the first adoption call had > nothing to do with use cases - they had to do with: > > > > a)The use of a prefix to identify a link between two nodes is a flawed > concept. It is not robust enough to be used in cases of unnumbered or > Pt-2-MP. > > [WAJ] Current encoding has covered the unnumbered scenario. For Pt-2-MP > scenario, they share also the same subnet, please see our previous > discussion at > https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/ > > > > *[LES:] I have no idea why you think the email you point to resolved the > issue. It was an early email in a very long thread, the lack of support for > unnumbered etc. continued to be discussed in subsequent emails by multiple > participants and has been raised again by multiple participants in this > second adoption call thread.* > > *The minor changes you made to the encoding of Stub Link advertisement > does nothing to resolve the issue.* > > *The fundamental issue is that the same prefix can be associated with > multiple links, so what you have defined is ambiguous in some cases.* > > *Either you don’t understand this or don’t think this is important – I am > not sure which – but many of us do believe this is important.* > > > > b)Existing mechanisms (RFC 9346/was RFC 5316 and RFC 5392) fully cover the > potential use cases and do so more robustly than the Stub-link proposal. > > [WAJ] If you make such claims, then please give the encoding example for > A.1 Figures 2(LAN scenario). How to configure/encode the several neighbors > that located in different AS in one inter-AS reachability TLV? > > > > *[LES:] RFC 9346/RFC 5362 provide a robust way to uniquely identify > inter-AS links, verify two-way connectivity, and optionally advertise > additional link attributes if desired. (Apply this portion of the response > to your other comments below.)* > > *You apparently think this is too onerous and you propose a different > mechanism that isn’t robust, does not allow two-way connectivity > verification, and doesn’t support link attribute advertisement.* > > *But because you see it as “simpler” you think you have sufficient > justification to overlook its flaws.* > > *I don’t agree.* > > > > *The long-lived success of the IGPs has happened because we have worked > diligently to provide robust solutions – not settle for solutions that only > work some of the time.* > > > > * Les* > > > > The latest version of the draft makes no substantive changes to the stub > link concept or its advertisement. > > The only substantive change in the latest version is a reorganization of > the presentation of use cases. > > But lack of clarity in the use cases was not the basis on which first WG > adoption call was rejected. > > > > In this thread (the second WG adoption call), the authors have asserted > that they have addressed the concerns raised in the previous adoption call. > > They have not. The concept and mechanism to identify a stub link has not > changed. > > > > In this thread the authors continue to assert that RFC 9346/RFC 5392 > cannot address the use cases. > > This is FALSE. > > As has been pointed out repeatedly, the existing mechanisms provide a > robust means to uniquely identify inter-AS links using endpoint identifiers > - be they IPv4/IPv6 addresses or Link IDs. > > [WAJ] And, please give the solution for the non inter-AS scenario(A.2). > Please do not mention the bogus AS again > > > > This addresses all cases - numbered and unnumbered. > > There is therefore no need for a new mechanism. > > [WAJ] Repeat again. The requirements of inter-AS TE solution are different > from the requirements of inter-AS topology recovery. We should find more > efficient solution to solve the latter scenario. > > The inefficiency of existing solutions for inter-AS topology recovery lies > in that it requires the operators to get the other end information for > every inter-as links manually, this is very challenge and error-prone, as > that also indicated in RFC9346 and RFC5392 themselves. > > > > No fact-based argument has been made to justify reconsideration of WG > adoption. > > > > I hope when people post their opinions, that they consider the facts. > > > > Les > > > > > -----Original Message----- > > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps > > > Sent: Wednesday, January 10, 2024 2:17 AM > > > To: Huzhibo <huzhibo=40huawei....@dmarc.ietf.org> > > > Cc: Acee Lindem <acee.i...@gmail.com>; Yingzhen Qu > > > <yingzhen.i...@gmail.com>; lsr@ietf.org > > > Subject: Re: [Lsr] WG Adoption Call - > > > draft-wang-lsr-stub-link-attributes > > > (01/05/2024 - 01/19/2024) > > > > > > [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. > > > > > _______________________________________________ > > 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
