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) <a...@cisco.com> 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 <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. > > > > 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 Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
