Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

[Ketan Talaulikar <[e-mail]>]

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