Hi, Peter: I think you may not have time to follow the previous discussions. Please refer to https://mailarchive.ietf.org/arch/msg/lsr/molRRoWXOBhaHFc5GPAPmvVISDs/ for my summary responses, for how to apply the solution in various scenarios, include the unnumbered scenario(we have updated the draft during the adoption call process). We have discussed the drawback of using RFC5316 to solve such requirements intensely, and I think we need not loop it back again.
And, I can give you(also other LSR experts) another information for the potential application of this draft: The CAN(Computing-Aware Network) BOF has been established, here is its contents https://datatracker.ietf.org/doc/bofreq-liu-computing-aware-networking-can/ In the last of its description section, we can see: "This work may then result in an analysis of which protocols/extensions are required to discover, advertise the location and status of, dynamically share, and load-balance between services using computation resources and those resources themselves." Besides the solution advantage compared to RFC 5316, the CAN related scenarios is also one drive to forward this draft, as also described in the reference document https://datatracker.ietf.org/doc/html/draft-dunbar-lsr-5g-edge-compute-03 Best Regards Aijun Wang China Telecom -----Original Message----- From: [email protected] <[email protected]> On Behalf Of Peter Psenak Sent: Friday, February 18, 2022 3:52 PM To: Christian Hopps <[email protected]>; lsr <[email protected]> Subject: Re: [Lsr] Adoption Question Stub-Link vs RFC5316 Chris, the draft attempt to use the local subnet information for identifying two endpoints of the same link. That seems wrong in itself. In addition: 1) We have link local/remote IDs (and IP addresses) to pair the two endpoints of the link in both OSPF and ISIS. We do not need another mechanism for the same. 2) What is proposed does not work for unnumbered links. thanks, Peter On 18/02/2022 05:45, Christian Hopps wrote: > [As WG Chair] > > Hi LSR-WG, > > As my co-chair has joined the draft as a co-author making the call on whether we have rough consensus to adopt draft-wang-lsr-stub-link-attributes-02 now falls to me alone. > > I've reread the numerous emails on this adoption call and I see some support, and a few objections, and most of the objections are not that there is no problem to solve here, but they think this draft isn't the right way to do it and a revision of RFC5316 could be done instead. > > "A bird in the hand is worth two in the bush" > > While it might be nice that there is another way to accomplish things by re-using an existing TLV, that work has not been done, whereas we have a written draft in front of us -- that has now been beaten up and reviewed a good deal -- that does seem to provide a solution to an actual problem. > > So I'd like to give the WG a final chance to comment here, is there a > strongly compelling reason to reject the work that is done here. > Examples of "strongly compelling" would be something like "This will > break the (IS-IS) decision process" or "this will badly affect > scaling" or "this will significantly complicate a protocol > implementation", but not "this can be done differently" as the latter > is work not done (i.e., it's two birds "in the bush") > > I am *not* looking to rehash the entire discussion we've already had so please restrict your replies to the above question only. > > Thanks, > Chris. > [As WG Chair] > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
