Aijun - Please see inline.
> -----Original Message----- > From: Aijun Wang <wangai...@tsinghua.org.cn> > Sent: Monday, January 10, 2022 8:34 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: Christian Hopps <cho...@chopps.org>; lsr@ietf.org; lsr-cha...@ietf.org; > lsr-...@ietf.org; draft-wang-lsr-stub-link-attribu...@ietf.org > Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02 > > 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) > <ginsberg=40cisco....@dmarc.ietf.org> 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. > [LES:] Aijun - Unnumbered links are in common usage today. We should not define extensions which do not allow support for this. > > 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. [LES:] Deprecating the use of unnumbered is outside the scope of this specification - and I would argue is not something we (the WG) should be advocating in any case. > > > 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. [LES:] Unnumbered is not obsolete - it is only you who have arbitrarily decided that it is no longer needed. > > > > > 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? > [LES:] Indeed - which means your extensions to TLV 141 violate RFC 5316. Please read the referenced section I provided and pay attention to the normative statements ("MUST") there. So, RFC 5316 conformant implementations will not accept the TLVs you apparently intend to send. This is not something which can be ignored. > > - 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. > [LES:] There is still nothing in the draft which explains what value the new information provides. For example, why does a controller or a router care whether a given link is a VLAN or not a VLAN? > > 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. > [LES:] The draft introduction discusses "... stub links is in a data center Layer 2 and Layer 3 Top of Rack(TOR) switch where the inter connected links between the TOR switches" This is clearly a link connecting two (or more) boxes - which means it isn’t a loopback. If you are including loopbacks proper in what your draft is addressing, then clearly a link TLV (TLV 141) isn’t appropriate. You seem unable to clearly define whether you are trying to advertise a prefix or a link which is truly an interconnect. They aren’t at all the same thing. > > > > > 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:] No it does not. What it does do is convince me that the draft is at best confusing, incomplete, and non-interoperable with existing RFC 5316 implementations. All of which are good reasons NOT to adopt the draft. Les > > > > 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 _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
