Hi, Les: There is the way to solve your concern. 1. https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.1 and https://datatracker.ietf.org/doc/html/draft-wang-lsr-stub-link-attributes-02#section-4.2 includes also the sub-TLVs field, which is pointed to the corresponding part for TE-Link TLV(for OSPF) and Inter-AS Reachability TLV (TLV 141). That is to say, the draft doesn't preclude the inclusion of Remote-AS, IPv4/IPv6 remote ASBR Identifier sub TLV. So, if you insist that the unnumbered link will be used between the ASes, then for such stub-link type(we can add one new stub link type), the operator should configure the remote information manually. And for such stub link type, the Remote-AS/IPv4/IPv6 Identifier sub TLV MUST be included(same as the rules defined in RFC5316). For other numbered interface, such information needn't be manually configured. This can certainly save the cost for management of the network, and also meet your mentioned scenario. Is it OK for you?
2. For the consideration of current extension violate the rules defined in RFC5316, I have proposed another solution at https://mailarchive.ietf.org/arch/msg/lsr/kTWLct7VgEfOxexdwzwcFS3Ctqc/ upon the comments from Peter. That is to say: "[WAJ] It seems to define one new TLV that at the same level of “Inter-AS reachability TLV”, for example “Stub-Link reachability TLV” is better. If acceptable, will update the draft." For the above two proposals, do you have other comments? If not, will update the draft to reflect it. Best Regards Aijun Wang China Telecom -----Original Message----- From: Les Ginsberg (ginsberg) <ginsb...@cisco.com> Sent: Tuesday, January 11, 2022 3:50 AM To: Aijun Wang <wangai...@tsinghua.org.cn> 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 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-attribute > >> s/ > >> > >> 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
