Aijun - I am aware that, subsequent to this email, you posted a revised version of the draft. But in regards to how I prefer to move forward I am choosing to respond to this email.
It is important to remember that this thread is a 2 week WG adoption call. The primary purpose of this thread is to determine the WG consensus as to whether the draft is ready for adoption - not to do major revisions of the draft. I believe you have received meaningful feedback from multiple WG members that indicate there are significant issues with the draft in its current form. The issues raised question not just the implementation details, but whether the goals of the draft as currently stated are desirable. This, in my mind, is sufficient to conclude that the draft in its current form is NOT ready for WG adoption. The new version you posted does not come close to fully addressing these issues. The most practical way forward (IMO of course) is for you to voluntarily withdraw your request for WG adoption. This will give you an opportunity to address the substantive issues that have been raised. It will also demonstrate that you are listening to the feedback being given. You can, of course, choose not to follow this path - in which case it will fall to the WG Chairs to determine the outcome of the adoption call. Thanx. Les > -----Original Message----- > From: Aijun Wang <wangai...@tsinghua.org.cn> > Sent: Monday, January 10, 2022 10:19 PM > 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: > > 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
