IETF Logo Mail Archive

Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02

Aijun Wang <wangaijun@tsinghua.org.cn> Sat, 15 January 2022 00:10 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 B15213A17E2 for <lsr@ietfa.amsl.com>; Fri, 14 Jan 2022 16:10:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLKWDtV0rkS4 for <lsr@ietfa.amsl.com>; Fri, 14 Jan 2022 16:09:56 -0800 (PST)
Received: from mail-m17638.qiye.163.com (mail-m17638.qiye.163.com [59.111.176.38]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B8E3A17E4 for <lsr@ietf.org>; Fri, 14 Jan 2022 16:09:55 -0800 (PST)
Received: from smtpclient.apple (unknown [221.223.101.81]) by mail-m17638.qiye.163.com (Hmail) with ESMTPA id D14361C03F4; Sat, 15 Jan 2022 08:09:53 +0800 (CST)
Content-Type: multipart/alternative; boundary="Apple-Mail-61513415-1C05-4DDE-91FA-9ECBD93F7662"
Content-Transfer-Encoding: 7bit
From: Aijun Wang <wangaijun@tsinghua.org.cn>
Mime-Version: 1.0 (1.0)
Date: Sat, 15 Jan 2022 08:09:52 +0800
Message-Id: <D866942F-028B-48EF-8012-6F5505F1C94B@tsinghua.org.cn>
References: <CAOj+MMH5HEYBBnCG1LiatsR_AsjsdGqLM14Y+K7H660mZT_vqw@mail.gmail.com>
Cc: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, lsr <lsr@ietf.org>, John E Drake <jdrake=40juniper.net@dmarc.ietf.org>
In-Reply-To: <CAOj+MMH5HEYBBnCG1LiatsR_AsjsdGqLM14Y+K7H660mZT_vqw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (19B74)
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgPGg8OCBgUHx5ZQUlOS1dZCBgUCR5ZQVlLVUtZV1 kWDxoPAgseWUFZKDYvK1lXWShZQUpMS0tKN1dZLVlBSVdZDwkaFQgSH1lBWRoaGh9WSU8aHkoZGE IaTx1NVRMBExYaEhckFA4PWVdZFhoPEhUdFFlBWVVLWQY+
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6MT46Kjo*Cz5RD0xKGAsBMjoJ Qy0wCi9VSlVKTU9JSUtOSEJPSk1KVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSUpVSUlIVUpLSlVDSllXWQgBWUFOSkxDNwY+
X-HM-Tid: 0a7e5b11b3c4d993kuwsd14361c03f4
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/T33NE6V_VMAzXzqVVIZ3Jdl7UEI>
Subject: Re: [Lsr] WG Adoption Call for draft-wang-lsr-stub-link-attributes-02
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 15 Jan 2022 00:10:02 -0000

Hi, Robert:

Sorry, the correct description should be “For inter-AS stub link, we must generate unnecessary Remote-AS, Remote ASBR Router ID for scenarios that described in  https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09#section-5.1
 For non inter-AS stub link, we must generate Bogus-AS, and Bogus Remote ASBR Router ID”

Aijun Wang
China Telecom

> On Jan 15, 2022, at 07:59, Robert Raszuk <robert@raszuk.net> wrote:
> 
> 
>  
>> For the current scenarios and solutions, we have analyzed that RFC 5316 and RFC5392 are not suitable for such purposes—we must generate bogus AS, bogus Remote ASBR Router ID on every inter-AS, or non inter-AS boundary links.
> 
> Why do you think those values need to be "bogus" ? And Inter-AS is just a perfect example on what you call a "stub link" so I would not hold on that much to the nomenclature. 
> 
>> I would like to hear the constructive comments, or other solutions that better the the one in this draft.
> 
> I think what has been suggested is just that, but of course you are entitled to have your own opinion. 
> 
> Kind regards,
> Robert
>

v2.23.0 | Report a Bug | By Email