Hi, Acee:
I have uploaded the updated version of draft, to address your concerns. The major update contents are the followings: 1) Separate the OSPF and IS-IS protocol extension for stub-link attributes, redefines the relevant Sub-TLVs to conform the current OSPF/IS-IS format. 2) Change some descriptions for scenario A.3, from "Optimized BGP Next-hop Selection" to "Egress Engineering for the path to BGP Next-hop". 3) Updates the graph for scenario A.2, let it more general. Detail replies are inline below. Please let me know whether you have other issues or not, for the scenario, for the solution, for the encoding etc. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Acee Lindem 发送时间: 2023年11月16日 3:56 收件人: Aijun Wang <wangai...@tsinghua.org.cn> 抄送: Christian Hopps <cho...@chopps.org>; Yingzhen Qu <yingzhen.i...@gmail.com>; draft-wang-lsr-stub-link-attribu...@ietf.org; Lsr <lsr@ietf.org> 主题: Re: [Lsr] I-D Action: draft-wang-lsr-stub-link-attributes-07.txt 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 <wangai...@tsinghua.org.cn> 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:acee.i...@gmail.com] > 发送时间: 2023年11月15日 6:07 > 收件人: Aijun Wang <wangai...@tsinghua.org.cn> > 抄送: Christian Hopps <cho...@chopps.org>; Yingzhen Qu > <yingzhen.i...@gmail.com> > 主题: 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. 【WAJ】: It is not only AS number, but also the "IPv6/IPv4 Remote ASBR Identifier" for each link. The operator must manually identify them if we use the current solution. > > Thanks, > Acee > > >> On Nov 14, 2023, at 16:40, Acee Lindem <acee.i...@gmail.com> 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. 【WAJ】For unnumbered stub link, as explained and stated in the draft, they must be identified and labeled specially. And we should know that unnumbered interface is seldom used within the network now. To include them is just for the integrity of the standard. > >> 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. 【WAJ】Have updated draft to address your concerns > > >> 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. 【WAJ】Have updated draft to address your concerns > >> 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. 【WAJ】It is the attributes of the stub-link that other than prefix information differentiate the Anycast server. And it is impossible to associate the stub link attribute with the prefix If we use OSPFv2 Extended Prefix LSA to transfer the prefix information separately(for example, when two servers are under the same edge router, please see the updated Figure 3 in A.2) > >> 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. 【WAJ】The router within the IGP that runs BGP-LS will use such information. > >> 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. 【WAJ】It is EBGP. If R11 advertises the stub links information between R11 and R21, R10 can use them to select the best forwarding exit/stub link to reach R20(EPE like effect)-----the draft has been updated to describe such behavior more accurately. I would like to step down as coauthor as I don’t see any of these as valid use cases. 【WAJ】OK. Thanks for your previous contributions! Wish the above explanation can assist you understand the use cases. If you have any questions about the use cases, please let me know, I will explain to you more clearly. Thanks, Acee > >> >> Thanks, >> Acee >> >> >> >> >>> On Nov 13, 2023, at 21:22, Aijun Wang <wangai...@tsinghua.org.cn> 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:wangai...@tsinghua.org.cn] >>> 发送时间: 2023年10月10日 9:20 >>> 收件人: 'lsr-cha...@ietf.org' <lsr-cha...@ietf.org> >>> 主题: 答复: [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:wangai...@tsinghua.org.cn] >>> 发送时间: 2023年6月5日 10:03 >>> 收件人: 'lsr-cha...@ietf.org' <lsr-cha...@ietf.org> >>> 主题: 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: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of >>>> internet- dra...@ietf.org >>>> Sent: Monday, June 5, 2023 9:32 AM >>>> To: i-d-annou...@ietf.org >>>> Cc: lsr@ietf.org >>>> 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-attribute >>>> s >>>> / >>>> >>>> There is also an htmlized version available at: >>>> https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attr >>>> i >>>> 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 >>>> 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
