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 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
> 抄送: Christian Hopps ; Yingzhen Qu
> 主题: 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 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
