Hi Aijun, Please check inline below.
On Thu, Jul 28, 2022 at 1:09 PM Aijun Wang <[email protected]> wrote: > 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. > KT> I believe some of these can be tackled with ease of configuration. No matter what approach is taken, I don't see how any of this configuration is avoidable. > 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. > KT> These things may not be coming out as well. Let me try to summarize on a fresh thread. Thanks, Ketan > > 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. >> >> >> >> 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 >> . >> > > 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
