Hi, LSR chairs:
Along the adoption call procedure, I think we all noticed that there are some limitations for the p2p(RFC9346/RFC5392) based existing solutions for the potential scenarios(A.1-A.3) that mentioned in the draft. Then we want to apply for extending the adoption call for one week or more, to confirm these limitations and also the values of proposed draft. The limitation for the p2p (RFC9346/RFC5392) based solutions are the followings: 1) Scalability: Within the operator’s network, there are always tens/hundreds of the links between any two ASBRs. It is very challenge to get/validate the information of other end of the inter-AS links, that is required by the existing solutions. We should find some scalable solutions to solve the issue. 2) Coverage: RFC9346/RFC5392 cover only p2p link, it doesn’t support the broadcast network, also the P2MP network. If these types of network are represented by individual P2P link(as Les suggested), then the following two additional questions should be answered: 2-1) whether one interface can be appointed to different neighbor? Will the latter override the former? 2-2) The efficiency. The total neighbor information will be O(N*N), the operator must get and verify them manually(no automatic method, not relevant to the NMS management), where if we use the subnet instead, the operator needs only confirm one information—-the shared subnet/prefix. Should we find some efficient way to cover more types of network then? 3) Flexibility: RFC 9346/RFC5392 requires the remote AS number and the IPv4/IPv6 Remote ASBR sub-TLVs must be presented in the advertisement, but in some scenarios(non inter-as scenario, for example A.2 in the draft), they are not exists or not necessary, stick to these standards lead the solution very rigid and can’t be deployed. Actually, “Stub Link” is one more general concept than the “inter-AS link”, we can pair them(form the inter-as link), or not(act independently) upon our demands. We all should know that the components are more flexible than the compounds. The actual pair methods can be refined later to meet the various requirements/scenarios(for example, unnumbered scenario, VRF scenario(as Robert mentioned) etc.) Then, if the LSR experts agree the above limitations of the existing solutions, we expect to forward this draft to solve these limitations. Or else, we expect to discuss them further and more deeper in the coming times. As operators, we expect to find one more attractive solution. Best Regards Aijun Wang China Telecom 发件人: forwardingalgori...@ietf.org [mailto:forwardingalgori...@ietf.org] 代表 Yingzhen Qu 发送时间: 2024年1月6日 8:23 收件人: lsr <lsr@ietf.org>; lsr-chairs <lsr-cha...@ietf.org> 主题: [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/> 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) <https://mailarchive.ietf.org/arch/msg/lsr/Li7wJsaY68gzJ8mXxff7K-Fy_nw/> Thanks, Yingzhen
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
