Hi Aijun, Similar to Les, I disagree with you on the use of Prefix TLV as an attribute of the "Stub Link". The reason is that this attribute is not required for the identification of a link in BGP-LS (or in IGPs for that matter) that was the main use case. I also don't see the use of that in Inter-AS links. Please justify this.
Thanks, Ketan On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang <[email protected]> wrote: > 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= > [email protected]> 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 <[email protected]> *On Behalf Of * Acee Lindem (acee) > *Sent:* Wednesday, July 27, 2022 11:37 AM > *To:* Ketan Talaulikar <[email protected]>; > [email protected] > *Cc:* lsr <[email protected]> > *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 <[email protected]> on behalf of Ketan Talaulikar < > [email protected]> > *Date: *Wednesday, July 27, 2022 at 5:33 AM > *To: *"[email protected]" < > [email protected]> > *Cc: *lsr <[email protected]> > *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. > > > > 1. 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. > > > > 1. 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 > . > > > > > > 1. 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). > > > > 1. 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 [email protected] https://www.ietf.org/mailman/listinfo/lsr
