Speaking as WG member: Hi Aijun,
See inline. I’ve added the co-authors and LSR to the discussion - lest we don’t need to repeat it. > On Nov 14, 2023, at 21:52, Aijun Wang <[email protected]> wrote: > > Hi, Acee: > > I explained in detail inline below to your comments. > Wish they can address your concerns. > If you have any further questions, please let me know. > > -----邮件原件----- > 发件人: Acee Lindem [mailto:[email protected]] > 发送时间: 2023年11月15日 6:07 > 收件人: Aijun Wang <[email protected]> > 抄送: Christian Hopps <[email protected]>; Yingzhen Qu <[email protected]> > 主题: Re: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt > > And for inter-AS use case, we already have: > > https://datatracker.ietf.org/doc/rfc5392/ > > I’m sure there is something similar for IS-IS. Why do we need anything more? > > 【WAJ】: Actually, we have explained the reason briefly at > https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-07#section-3. > There are scenarios that inter-AS scenario can't cover. And even for > inter-AS scenario, to apply RFC 5392(OSPF), or RFC 5316(IS-IS, now is > obsoleted by RFC9346), it requires every inter-AS link be configured with > "remote AS", and "IPv6/IPv4 Remote ASBR Identifier", which is inefficient. In the use case, given that there is an active BGP session between the routers, it would seem that the remote AS is known. > > Thanks, > Acee > > >> On Nov 14, 2023, at 16:40, Acee Lindem <[email protected]> wrote: >> >> Hi Aijun, >> >> I have the following comments: >> >> 1. What would be the purpose of an unnumbered stub link - if the link >> doesn’t go anywhere and doesn’t have an address, it doesn’t seem to serve >> any purpose. However, see comment #5 as this would imply the links aren’t >> really stubs. > 【WAJ】The information carried within the stub link will be flooding across the > IGP domain, and each of them have an address, and also the prefix. The > scenario described in A.1-A.3 explain the use case of such information. But unnumbered links don’t have a unique address. > >> 2. For IS-IS, the TLVs and sub-TLVs have 1 octet type/length. > 【WAJ】There is already the discussion about the limitation of 1 octet length, > should we avoid it happen again? And > https://www.rfc-editor.org/rfc/rfc7356.htm defines also the Extended TLVs and > Extended Sub-TLVs which use the 16bit type and 16 bit length. Given the constraints of extend TLV/sub-TLVs in RFC 7356, they wouldn’t seem to apply to your area scope use cases. > > >> 3. For the prefix sub-TLVs, the first length in the sub-TLV is the length >> of the value in the TLV. It cannot double as the prefix length. > 【WAJ】The length value in the container TLV is the sum of attached sub-TLV; > the length field in the sub-TLV is the length of each sub-TLV. What's the > meaning of "it cannot double as the prefix length”? In sections 4.3 and 4.4 there is only one length and it should be the sub-TLV length, not the prefix length. > >> 4. The Appendix A.2 use case is already typically done with prefix >> advertisements. > 【WAJ】There is no existing sub-TLV to encode the prefix information of the > stub link and there is also no way to advertise such prefix information. All > the works are proposed in our draft. I’m saying that anycast address selection is already being facilitated using prefix advertisements. For example, with OSPFv2 Extended Prefix LSAs. > >> 5. For the Appendix A.1 use case, why does it matter that it is a stub >> link? In this case, you are inferring that the stub links are inter-AS >> links? Why not just advertise that they are inter-AS links since it if >> connects another AS, it isn’t really a stub? > 【WAJ】The reason that we call such link as "stub-link" is from the IGP > viewpoint-----that is, in such scenarios, only one end of the link > participate the IGP domain. But the IGP doesn’t use this information in any of the purported use cases. > >> 6. I don’t really understand the use case in A.3 unless it is just a >> restatement of the use case in A.1. > 【WAJ】It is different from the use case in A.1-----For A.1, the stub link > information will be used by the controller but for A.3, the stub link > information is consumed by the router itself. The use case in A.3 makes no sense with current BGP next-hop resolution mechanisms. Is this EBGP or IBGP? R10 and R11 aren’t going to be advertising the interfaces on the directly connected routers as next hops. I would like to step down as coauthor as I don’t see any of these as valid use cases. Thanks, Acee > >> >> Thanks, >> Acee >> >> >> >> >>> On Nov 13, 2023, at 21:22, Aijun Wang <[email protected]> wrote: >>> >>> Hi, Acee: >>> >>> As discussed during the Prague meeting, we would like to know your >>> comments for the latest version of >>> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/. >>> We will update the draft to address your concerns then. And if there >>> is no >>> more(major) issues, we would like to ask the chair(Chris) to begin >>> the adoption call then. >>> >>> Thanks in advance for your efforts. >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> -----邮件原件----- >>> 发件人: Aijun Wang [mailto:[email protected]] >>> 发送时间: 2023年10月10日 9:20 >>> 收件人: '[email protected]' <[email protected]> >>> 主题: 答复: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt >>> >>> Hi, Chris and Acee: >>> >>> We would like to ask to begin the adoption call of this draft >>> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/. >>> Four months past from the last application mail. >>> >>> Thanks in advance. >>> >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>> >>> -----邮件原件----- >>> 发件人: Aijun Wang [mailto:[email protected]] >>> 发送时间: 2023年6月5日 10:03 >>> 收件人: '[email protected]' <[email protected]> >>> 主题: FW: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt >>> >>> Hi, Chris and Acee: >>> >>> Can we start the WG adoption call now? >>> We think the updated draft has addressed the concerns that raised >>> during the last WG adoption call. >>> >>> Thanks in advance for your efforts. >>> >>> Best Regards >>> >>> Aijun Wang >>> China Telecom >>> >>>> -----Original Message----- >>>> From: [email protected] <[email protected]> On Behalf Of >>>> internet- [email protected] >>>> Sent: Monday, June 5, 2023 9:32 AM >>>> To: [email protected] >>>> Cc: [email protected] >>>> Subject: [Lsr] I-D Action: >>>> draft-wang-lsr-stub-link-attributes-07.txt >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>>> This Internet-Draft is a work item of the Link State Routing >>>> (LSR) WG of the IETF. >>>> >>>> Title : Advertisement of Stub Link Attributes >>>> Authors : Aijun Wang >>>> Zhibo Hu >>>> Acee Lindem >>>> Gyan S. Mishra >>>> Jinsong Sun >>>> Filename : draft-wang-lsr-stub-link-attributes-07.txt >>>> Pages : 13 >>>> Date : 2023-06-04 >>>> >>>> Abstract: >>>> This document describes the mechanism that can be used to advertise >>>> the stub link attributes within the IS-IS or OSPF domain. >>>> >>>> The IETF datatracker status page for this Internet-Draft is: >>>> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes >>>> / >>>> >>>> There is also an htmlized version available at: >>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attri >>>> bu >>>> tes-07 >>>> >>>> A diff from the previous version is available at: >>>> https://author-tools.ietf.org/iddiff?url2=draft-wang-lsr-stub-link-a >>>> tt >>>> ributes-07 >>>> >>>> Internet-Drafts are also available by rsync at >>>> rsync.ietf.org::internet-drafts >>>> >>>> >>>> _______________________________________________ >>>> Lsr mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >> > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
