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]<mailto:[email protected]>> on behalf of Ketan Talaulikar <[email protected]<mailto:[email protected]>> Date: Wednesday, July 27, 2022 at 5:33 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: lsr <[email protected]<mailto:[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
