Hi Aijun, I do have some sympathy to what you are trying to do here. But I also have a concern if IGP is the right protocol to load it and use it disseminate completely opaque to its main role information.
Imagine your CAN use case and use of areas with summarization. The ingress nodes/machines may be far away in different areas. How are you planning to pass the information around ? Leak all stub links along with new information attached to them all over the domain ? Thx, R. On Fri, Feb 18, 2022 at 9:39 AM Aijun Wang <wangai...@tsinghua.org.cn> wrote: > 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: lsr-boun...@ietf.org <lsr-boun...@ietf.org> On Behalf Of Peter > Psenak > Sent: Friday, February 18, 2022 3:52 PM > To: Christian Hopps <cho...@chopps.org>; lsr <lsr@ietf.org> > 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 > > 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 >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
