Hi, Les: Wish the below explanation can correct your understanding of this draft, and also your conclusions.
Aijun Wang China Telecom > On Jan 10, 2022, at 23:13, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > I oppose WG adoption of this draft. > > In addition to my comments below, I am in agreement with the points made by > Peter and Shraddha previously in this thread. > > My comments below are in the context of IS-IS/RFC5316, but I believe are > equally valid in the context of OSPF/RFC5392. > > There are two types of new information the draft proposes to advertise under > TLV 141: > > 1)Identifying a link by the prefix locally configured on the link rather than > by the local/remote addresses. > > The motivation for this addition seems to be to avoid the need for the > operator to locally configure the remote address. [WAJ] For inter-AS stub link type, it is. For other stub link type, it isn’t. > But I think this is not a desirable change. > > As pointed out by Peter, this does not work for unnumbered links. (It also > would not work for Pt-2-MP links). The authors assert that it is unlikely > that unnumbered links would be used in the expected use cases - but I do not > find this argument convincing. [WAJ] Is there any operator adopt unnumbered link at its boundary network? There is even very rare case for the unnumbered interface be used within the operator network. And, with the IPv6 deployment, what is the usages of unnumbered interface? Won’t it be depreciated in future? Very curious you and Peter stick to this point, but not considering its wider use scenarios. > Even if unnumbered links are not currently being used, the restriction that > they could not be used in the future seems highly undesirable. [WAJ] Would like to hear the reason and scenarios that the unnumbered interface will be used in future. I think it should be deprecated instead. > It would put us in the position of having to revise this functionality in the > future in an incompatible way in order to add such support. This is a bad > design choice. [WAJ] We should keep the trend, not stick to the obsolete obstacles. > > Aside: The assertion that unnumbered links will not be used seems at odds > with the inclusion of "loopback" as a link type. [WAJ] The loop back address won’t borrow address from others. Or if you consider it maybe, please give the reason. > More on that below. > > Also, as the draft builds on top of existing RFC5316 functionality, it is > still required to advertise remote AS Number and Remote ASBR ID as well as > remote Router IDs (IPv4 and/or IPv6) (see > https://datatracker.ietf.org/doc/html/rfc5316#section-3.3 ) [WAJ] No. With the newly defined TLV/sun-TLV, we need not configured the above information manually then. And for other stub link type(for example, the edge router that connects the server) there will be no remote-AS, no remote ASBR, how can you configure them? > - all of which still need to be locally configured since there is no IGP > operating on the link. So the suggestion that not having to configure the > remote link address provides significant simplification in deployment does > not stand up to scrutiny. [WAJ] Please see the previous explanation. > > 2)New link type information (AS boundary link/Loopback link/Vlan interface > link) to be advertised > > There is no mention in the draft as to how this information will be used. [WAJ] The information about various stub link type is mainly for the controller. If necessary, we can add some potential use cases for such type information, but this is not the main points of this draft. > Indeed, I do not even know what a "loopback link" is unless it is an > unnumbered link to which a loopback address has been associated - which makes > me wonder why the authors have dismissed the use of "unnumbered" in > deployments. [WAJ] Actually, it is loopback interface, not loopback link, which you have imaged that one unnumbered link borrows the address from the loopback interface. The loopback interface is one type of Stub Link, which has the characters that doesn’t send out IGP LSA. > > I therefore conclude that existing functionality defined in RFC 5316/RFC5392 > is sufficient and there is no need for the extensions defined in this draft. [WAJ] Wish the above explanation can correct your conclusions. > > Les > >> -----Original Message----- >> From: Lsr <[email protected]> On Behalf Of Christian Hopps >> Sent: Monday, January 3, 2022 10:59 PM >> To: [email protected] >> Cc: [email protected]; [email protected]; [email protected]; draft-wang-lsr- >> [email protected] >> Subject: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 >> >> Hi Folks, >> >> This begins a 2 week WG Adoption Call for the following draft: >> >> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ >> >> Please indicate your support or objections by January 18th, 2022. >> >> Authors, please respond to the list indicating whether you are aware of any >> IPR that applies to these drafts. >> >> Thanks, >> Chris. >> >> _______________________________________________ >> 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
