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. 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. Even if unnumbered links are not currently being used, the restriction that they could not be used in the future seems highly undesirable. 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. Aside: The assertion that unnumbered links will not be used seems at odds with the inclusion of "loopback" as a link type. 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 ) - 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. 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. 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. 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. Les > -----Original Message----- > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Christian Hopps > Sent: Monday, January 3, 2022 10:59 PM > To: lsr@ietf.org > Cc: lsr-cha...@ietf.org; lsr-...@ietf.org; cho...@chopps.org; draft-wang-lsr- > stub-link-attribu...@ietf.org > 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 > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
