Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
Aijun Wang <wangaijun@tsinghua.org.cn> Fri, 29 July 2022 11:17 UTC
Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: lsr@ietfa.amsl.com
Delivered-To: lsr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A145BC1C9535 for <lsr@ietfa.amsl.com>; Fri, 29 Jul 2022 04:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZJTuOAnxebe for <lsr@ietfa.amsl.com>; Fri, 29 Jul 2022 04:17:45 -0700 (PDT)
Received: from mail-m121145.qiye.163.com (mail-m121145.qiye.163.com [115.236.121.145]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25DB4C1C953F for <lsr@ietf.org>; Fri, 29 Jul 2022 04:17:43 -0700 (PDT)
Received: from smtpclient.apple (unknown [219.142.69.78]) by mail-m121145.qiye.163.com (Hmail) with ESMTPA id 24B5B8000CC; Fri, 29 Jul 2022 19:17:41 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-9F67675E-14F2-41A8-AF08-C492B12979D9"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Fri, 29 Jul 2022 19:17:40 +0800
Message-Id: <DC10A7F2-4BB6-4B14-B640-85DF901D8171@tsinghua.org.cn>
References: <CAOj+MMEbcSgBtwo_v6mA5hx113R00sEOB71Ay-_eaXEMPCFvUg@mail.gmail.com>
Cc: Ketan Talaulikar <ketant.ietf@gmail.com>, "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "Acee Lindem (acee)" <acee=40cisco.com@dmarc.ietf.org>, lsr <lsr@ietf.org>
In-Reply-To: <CAOj+MMEbcSgBtwo_v6mA5hx113R00sEOB71Ay-_eaXEMPCFvUg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (19F77)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZFg8aDwILHllBWSg2Ly tZV1koWUFKTEtLSjdXWS1ZQUlXWQ8JGhUIEh9ZQVkaSkwZVkhLQkhNSUseSx0eGlUTARMWGhIXJB QOD1lXWRgSC1lBWUlKQlVKT0lVTUJVTENZV1kWGg8SFR0UWUFZT0tIVUpKS0hNSlVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6Ni46Njo5MD0xIz8tUQEXIUlW FhcwCQFVSlVKTU5CS0JIT01KTEJJVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxDWVdZCAFZQU9KSkNNNwY+
X-HM-Tid: 0a8249ad28a6b03akuuu24b5b8000cc
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/N7dN-zgKGbFmrdrPp3oA0W83SNQ>
Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 11:17:50 -0000
Hi, Robert: I think your proposal are valid. Option C like deployment can also use such information to select the optimized inter-AS link to reach the routers in other domain. The final effect will be like the EPE scenario. Aijun Wang China Telecom > On Jul 29, 2022, at 16:44, Robert Raszuk <robert@raszuk.net> wrote: > > > Hi Aijun, > > How does this proposal impacts BGP path selection ? > > Note that it is common to do next hop self on the ASBRs towards the intradomain. So your proposal would not require any signalling to be effective on a given ASBR. Local decision. > > Originally I was under impression that you want to enhance TE for option C like deployments. But if not then I see not much point of doing it. > > Thx, > R. > >> On Fri, Jul 29, 2022 at 4:09 AM Aijun Wang <wangaijun@tsinghua.org.cn> wrote: >> Hi, Ketan: >> >> >> >> In the inter-AS scenario, we will not deploy BGP session on each p2p link. The BGP session exists only within the loopback address of each ASBR pair. >> >> Such deployment is also same in the LAN scenario. Then there is no mesh or partial p2p link that congruent to the BGP sessions. >> >> But such LAN interfaces are sharing the same prefixes. >> >> >> >> And regarding to your comments on Prefix sub-TLV: yes, if we redistribute such external prefixes into the IGP, then they will be transported within the associated “External Prefixes TLV”. >> >> But for these stub links, if we configure them as “passive” only( no redistributed action), then the prefixes of these stub links will not exists within the IGP LSA. >> >> Attach the prefixes information with these stub links can certainly fill such gap. There will be no redundancy information. >> >> >> >> And, regarding to your comments: “… …- at least let us not go overboard and repeat the same info in multiple places. ”, this is also the main reason that we don’t want to use the RFC5316/RFC5392 mechanism to accomplish the goal for the inter-as topology recovery------there will be many redundancy information being flooded within the IGP area. >> >> >> >> >> >> Best Regards >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> >> >> From: Ketan Talaulikar <ketant.ietf@gmail.com> >> Sent: Thursday, July 28, 2022 4:54 PM >> To: Aijun Wang <wangaijun@tsinghua.org.cn> >> Cc: Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>; Acee Lindem (acee) <acee=40cisco.com@dmarc.ietf.org>; lsr <lsr@ietf.org> >> Subject: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes >> >> >> >> Hi Aijun, >> >> >> >> Please check inline below. >> >> >> >> On Thu, Jul 28, 2022 at 1:15 PM Aijun Wang <wangaijun@tsinghua.org.cn> wrote: >> >> Hi, Ketan: >> >> >> >> There are situation that such information is necessary: >> >> When several ASes are connected via the LAN interface, it is impossible to describe the inter-AS relationship with the current descriptors that provided by RFC5316 and RFC5392. >> >> >> >> KT> Note that we have BGP running on these Inter-AS links. Even when there is an underlying LAN, the BGP sessions are p-t-p and maybe a full or partial mesh. Therefore, I believe representing such a LAN as a mesh of p-t-p links that are congruent to the BGP sessions is the right approach. I am happy to be corrected. In any case, I still fail to see how a prefix associated with the links helps here. >> >> >> >> >> >> And another scenario is that when these stub links are used to correct servers, there is no remote-AS, remote ASBR ID information. But we can distinguish different stub link via their associated prefixes. >> >> >> >> KT> I disagree - such stub links can be identified by their local interface ids along with their local IP address. Note that we already have the corresponding prefix being advertised as prefix reachability. So I don't see the need to repeat. All of this is already overloading IGPs with info that is not used by IGPs - at least let us not go overboard and repeat the same info in multiple places. >> >> >> >> Please check the new fresh thread about use-cases. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> >> On Jul 28, 2022, at 15:03, Ketan Talaulikar <ketant.ietf@gmail.com> wrote: >> >> >> >> Hi Aijun, >> >> >> >> Similar to Les, I disagree with you on the use of Prefix TLV as an attribute of the "Stub Link". The reason is that this attribute is not required for the identification of a link in BGP-LS (or in IGPs for that matter) that was the main use case. I also don't see the use of that in Inter-AS links. Please justify this. >> >> >> >> Thanks, >> >> Ketan >> >> >> >> >> >> On Thu, Jul 28, 2022 at 12:19 PM Aijun Wang <wangaijun@tsinghua.org.cn> wrote: >> >> Hi, Les: >> >> >> >> Please note the references to RFC5316/RFC5392 in draft-ietf-idr-bgpls-inter-as-topology-ext-11 is for TE scenarios, and what we are discussing are non-TE scenarios. >> >> For prefixes sub-TLV, would you like to revisit my responses to Ketan, before make any comments? For your convenience, I can elaborate again to you——-“The prefix sub-TLV is not the link identifier, it is just one kind of link attributes”. Is it clear enough? >> >> >> >> Based on these facts, I think it is unnecessary to response your other baseless comments. >> >> >> >> Aijun Wang >> >> China Telecom >> >> >> >> >> On Jul 28, 2022, at 12:51, Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org> wrote: >> >> >> >> 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 <lsr-bounces@ietf.org> On Behalf Of Acee Lindem (acee) >> Sent: Wednesday, July 27, 2022 11:37 AM >> To: Ketan Talaulikar <ketant.ietf@gmail.com>; draft-wang-lsr-stub-link-attributes@ietf.org >> Cc: lsr <lsr@ietf.org> >> 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 <lsr-bounces@ietf.org> on behalf of Ketan Talaulikar <ketant.ietf@gmail.com> >> Date: Wednesday, July 27, 2022 at 5:33 AM >> To: "draft-wang-lsr-stub-link-attributes@ietf.org" <draft-wang-lsr-stub-link-attributes@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. >> >> >> >> 2. 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. >> >> >> >> >> >> 3. 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). >> >> >> >> 4. 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 >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr
- [Lsr] Comments on draft-wang-lsr-stub-link-attrib… Ketan Talaulikar
- [Lsr] 答复: Comments on draft-wang-lsr-stub-link-at… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Acee Lindem (acee)
- [Lsr] 答复: Comments on draft-wang-lsr-stub-link-at… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Les Ginsberg (ginsberg)
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Ketan Talaulikar
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Aijun Wang
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Robert Raszuk
- Re: [Lsr] Comments on draft-wang-lsr-stub-link-at… Aijun Wang