Hi, Les: Please note the references to RFC5316/RFC5392 in draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what we are discussing are non-TE scenarios. For prefixes sub-TLV, would you like to revisit my responses to Ketan, before make any comments? For your convenience, I can elaborate again to you——-“The prefix sub-TLV is not the link identifier, it is just one kind of link attributes”. Is it clear enough?
Based on these facts, I think it is unnecessary to response your other baseless comments. Aijun Wang China Telecom > On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg) > <ginsberg=40cisco....@dmarc.ietf.org> wrote: > > > Acee – > > I have a somewhat different take on this draft. > > I agree with you that draft-ietf-idr-bgpls-inter-as-topology-ext-11 is > relevant – but I disagree that the lsr-stub-link draft is needed at all. > In fact one of the main points in the extensive discussion of this draft that > occurred several months ago ( see > https://mailarchive.ietf.org/arch/msg/lsr/8pY4d21J1XOb_GfwgrROJUijLQ8/ as a > pointer to one email in the thread) was that RFC 5316/RFC 5392 are sufficient > to support the use case. This is reinforced by the references to those two > RFCs in the bgpls-inter-as-topology draft. > > The other main point (discussed in #3 below) is that the use of a prefix as a > Link Identifier is a flawed concept and has been objected to by many WG > members. > > For these reasons I believe this draft is unnecessary and undesirable. > > Given the extensive review of the draft by many members of the WG and the > failed WG adoption, I believe the WG should move on to other priorities. I > understand that the authors of lsr-stub-link have not been convinced and want > to continue to advocate for the draft, but at some point the WG needs to say > we have done due diligence and the WG consensus is NOT to adopt the draft. > The continued discussion of this draft consumes WG resources (including > presentation slots) and diverts WG attention from other work. > > Les > > > From: Lsr <lsr-boun...@ietf.org> On Behalf Of Acee Lindem (acee) > Sent: Wednesday, July 27, 2022 11:37 AM > To: Ketan Talaulikar <ketant.i...@gmail.com>; > draft-wang-lsr-stub-link-attribu...@ietf.org > Cc: lsr <lsr@ietf.org> > Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes > > Hi Ketan, > I’m glad you brought this up. The primary (and AFAIK only) reason for this > draft is to get the stub-link information to a router in the IGP domain > running BGP-LS so that it can be advertised to the controller. For reference, > see > https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt > figure 1. So, the IGP encoding is only to get the stub-link information from > B1 and B3 to S2 and from B2 and B4 to T1. Since the IGPs and TE are not > consuming the information, the problem could be avoid by simply running > BGP-LS on B1-B4. See inline. > > > From: Lsr <lsr-boun...@ietf.org> on behalf of Ketan Talaulikar > <ketant.i...@gmail.com> > Date: Wednesday, July 27, 2022 at 5:33 AM > To: "draft-wang-lsr-stub-link-attribu...@ietf.org" > <draft-wang-lsr-stub-link-attribu...@ietf.org> > Cc: lsr <lsr@ietf.org> > Subject: [Lsr] Comments on draft-wang-lsr-stub-link-attributes > > Hello Authors, > > Please find below my comments/suggestions on this draft. I am sharing them > upfront given the packed LSR agenda. > > Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is not > sound in my opinion. I would say that the TE encoding may not be suitable for > use in all deployments as their advertisement results in the addition of > those Inter-AS links in a TE topology database and that may not be desired. > So, I would suggest that the draft keeps the option of use of Inter-AS TE > TLVs valid and goes ahead with the Stub Link proposal as an alternative with > broader applicability (also see the next comment). > > Agree. > > For the proclaimed wider applicability (e.g., links to servers/hosts) in the > slides, there is no such text in the draft. The draft seems focused on > Inter-AS links. I hope the authors update either the draft or the slides - to > be in sync with their objectives. > > It is solely for purposes of advertisement in BGP-LS and consumption by the > SDN controller as described in > https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt. > > > The use of the prefix TLVs in this context is something that is (in my > opinion) broken from day 1 of this draft. Prefixes are for reachability. For > identification of links, we have the local/remote link identifiers along with > the local/remote IP addresses (NOT prefixes!). This to me is a NO-GO for the > progression of this document. > > I agree, if this draft is to persist, these should be referred to as ASBR > addresses as in the IDR draft (the sole raison d’etre for this IGP draft). > > The placement of the Stub Link TLV should be top-level (similar to > other/existing links). I can share further suggestions offline, provided we > reach an agreement on the above points and we converge on the main > purpose/motivation for this work. > > I feel that strongly here as this is analogous to the new BGP-LS NLRI type in > > https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt. > > Thanks, > Acee > > > Thanks, > Ketan >
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
