Hi, Ketan: For the mentioned scenario, not only we need to run BGP-LS on every edge router, but also we need to configure every inter-AS link the following information: remote—AS number, remote ASBR ID. Regardless of the redundancy configured efforts, such information will be also need to imported into the TE Database unnecessary , as also pointed out by you.
And, imagining there are lots of inter-AS links between the ASBRs in real deployments, such approach is certainly not extensible and should be avoided. From the POV of operator, we want to keep the network simple and easy to operate. Aijun Wang China Telecom > On Jul 28, 2022, at 14:58, Ketan Talaulikar <[email protected]> wrote: > > > Hi Acee, > > Thanks for your clarifications and please check inline below for responses as > co-author of the referenced BGP-LS draft with Aijun. > >> On Thu, Jul 28, 2022 at 12:07 AM Acee Lindem (acee) <[email protected]> wrote: >> 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. >> > > KT> This scenario is addressed in the BGP-LS draft that you point to - i.e., > direct advertisement by BGP-LS from B1 and B3. This way the information gets > to the controller/application and IGPs don't need to be bothered. My > impression is that Aijun wanted to avoid enabling BGP-LS on B1 and B3 - that > is the only reason why this is being pushed into the IGPs. Aijun, please > correct me, if I am wrong here. > >> 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. >> >> >> >> 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. >> > > KT> The original scope of that BGP-LS draft was narrowed to only Inter-AS > links. These links are not IGP adjacencies and their link identifiers are > different. Hence the new Stub NLRI so they don't get mixed up with "regular" > IGP link-state links. The NLRI could as well have been named "Inter-AS Link" > NLRI if the narrow inter-AS focus is retained. In my view, we are a bit stuck > on progressing that BGP-LS work due to the dependency on the outcome of this > individual LSR draft. > > Thanks, > Ketan > >> >> >> Thanks, >> Acee >> >> >> >> >> >> Thanks, >> >> Ketan >> >> >> > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
