Re: [Idr] 答复: 答复: WG Adoption call for draft-wang-idr-bgpls-inter-as-topology-ext-02.txt (10/4/2018 to 10/18/2018)

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Tue, 09 October 2018 07:13 UTC

Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC7E1311D9; Tue, 9 Oct 2018 00:13:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.955
X-Spam-Level:
X-Spam-Status: No, score=-14.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 PJQt_w4hnbP4; Tue, 9 Oct 2018 00:12:57 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C488A1311C9; Tue, 9 Oct 2018 00:12:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31061; q=dns/txt; s=iport; t=1539069176; x=1540278776; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LN16KO1ZTuJgY3ho+gnG0wT0UGVJgOd/b450VQFsqa4=; b=B4UKNhdxHfqokA2I/7bbzYwWhMiIE0MreHV3AiH9gnS1Mjtz+okZxfAe XKevcf+ajntpiA7WM+oxUkAGIppE/RzI9m/boN8D2V1p9ucfiedLJ90d3 wJ2420YEZWAbFLsPZXZHyPO77BHPdu6+UlhonOSdHM0igEWSuo8TOXFgX c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACEVLxb/5pdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ53Zn8oCoNriBWMMoINeJV3gXoLAQE?= =?us-ascii?q?lhEcCF4QuITQNDQEDAQECAQECbRwMhTkBAQEBAx0QOhIQAgEGAhEEAQEhAQI?= =?us-ascii?q?EBQICMBQGAwgCBAENBQiDGoEdZA+IJZtHCIEshDMHhT0dBYs5F4FBP4ERAYJ?= =?us-ascii?q?dNYFBgVoBAQIBAYE2Pg8QgkeCWwKIOg2FSySFYoleCQKGTYUcgjyCGx+BToR?= =?us-ascii?q?niUqDI4kGiScCERSBJR04J4EucBWDJ4JOGYgwhT5vAQGKA4EugR8BAQ?=
X-IronPort-AV: E=Sophos;i="5.54,359,1534809600"; d="scan'208,217";a="182681542"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Oct 2018 07:12:55 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w997CtE5013692 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 9 Oct 2018 07:12:55 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 9 Oct 2018 02:12:54 -0500
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1395.000; Tue, 9 Oct 2018 02:12:54 -0500
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "'Dongjie (Jimmy)'" <jie.dong@huawei.com>, "'Susan Hares'" <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>
CC: "draft-wang-idr-bgpls-inter-as-topology-ext@ietf.org" <draft-wang-idr-bgpls-inter-as-topology-ext@ietf.org>
Thread-Topic: =?gb2312?B?W0lkcl0gtPC4tDogILTwuLQ6ICBXRyBBZG9wdGlvbiBjYWxsIGZvciBkcmFm?= =?gb2312?B?dC13YW5nLWlkci1iZ3Bscy1pbnRlci1hcy10b3BvbG9neS1leHQtMDIudHh0?= =?gb2312?Q?_(10/4/2018_to_10/18/2018)?=
Thread-Index: AQHUX3Rz9ePTH0L/XkCDs2tH+gw2IKUWeUmw
Date: Tue, 9 Oct 2018 07:12:54 +0000
Message-ID: <2eceb74fe53b432da237e2d13200fcb0@XCH-ALN-008.cisco.com>
References: <009b01d45c1e$9d9d4110$d8d7c330$@ndzh.com> <76CD132C3ADEF848BD84D028D243C927A7A03369@NKGEML515-MBX.china.huawei.com> <006c01d45f74$5c402620$14c07260$@org.cn>
In-Reply-To: <006c01d45f74$5c402620$14c07260$@org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.64.156]
Content-Type: multipart/alternative; boundary="_000_2eceb74fe53b432da237e2d13200fcb0XCHALN008ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KmTcqJMAyis-Y42ev2YjJOE9J0I>
Subject: Re: [Idr] =?gb2312?b?tPC4tDogILTwuLQ6ICBXRyBBZG9wdGlvbiBjYWxsIGZv?= =?gb2312?b?ciBkcmFmdC13YW5nLWlkci1iZ3Bscy1pbnRlci1hcy10b3BvbG9neS1leHQt?= =?gb2312?b?MDIudHh0ICgxMC80LzIwMTggdG8gMTAvMTgvMjAxOCk=?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Oct 2018 07:13:01 -0000

Hi Aijun,

I support the requirement for this draft to cover the Inter-AS links advertisement via BGP-LS which was left out by RFC 7752 (https://tools.ietf.org/html/rfc7752#section-3.5).

However, I have the following suggestions and comments.


1)     The Inter-AS TE scenario is more straight forward and well-defined be covered by this draft. But I would propose that such a link be encoded by re-using existing TLVs as also suggested by Jie. The details can be worked out, if you agree on the premise of re-use.

2)     For the Inter-AS ¡°Native IP¡± scenario, the draft proposes to use the Prefix NLRI corresponding to the redistributed Inter-AS link subnet to derive (or construct) the Inter-AS link topology. I find this problematic due to follows:

a.      Are all redistributed/external routes now going to get assumed to be Inter-AS links? This generalization is not correct.

b.      I do not understand how the inter-AS link is going to get ¡°derived¡± from this prefix ¨C it is just the prefix subnet without any information of the remote node AS or link identifier information (which is what we have in case (1) above as well as when using BGP EPE).

In summary, I support the adoption for the signalling for Inter-AS TE links (with suggestion to re-use existing TLVs). But I don¡¯t support the use-case/scenario (2) which is being described as it would break the existing BGP-LS functionality for signalling of external/redistribute prefixes by implying that they are all Inter-AS links.

Thanks,
Ketan

From: Idr <idr-bounces@ietf.org> On Behalf Of Aijun Wang
Sent: 09 October 2018 07:34
To: 'Dongjie (Jimmy)' <jie.dong@huawei.com>om>; 'Susan Hares' <shares@ndzh.com>om>; idr@ietf.org
Cc: draft-wang-idr-bgpls-inter-as-topology-ext@ietf.org
Subject: [Idr] ´ð¸´: ´ð¸´: WG Adoption call for draft-wang-idr-bgpls-inter-as-topology-ext-02.txt (10/4/2018 to 10/18/2018)

Hi, Jie:

Thanks for your supports and comments.
Let¡¯s explain to you for our considerations for your concern points.

1)      For Non-TE scenario, the redistributed link information will be carried in ¡°prefix descriptor¡±, as described in https://tools.ietf.org/html/draft-wang-idr-bgpls-inter-as-topology-ext-02#section-3.1, then no link related TLV will be carried.

2)   For TE scenario, the inter-as link TLV should be treated different from the ordinary link TLV, as stated in https://tools.ietf.org/html/rfc5392#section-3.2.1  ¡°Given that OSPF is an IGP and should only be utilized between routers in the same routing domain, the OSPF specific Link ID and Neighbor ID sub-TLVs are not applicable to inter-AS links. ¡°, this is the same reason that we define the new TLV within BGP-LS.



The format of these TLVs can be aligned, but the type ID should be different. For BGP-LS protocol, they should be newly assigned.



Best Regards.

Aijun Wang
Network R&D and Operation Support Department
China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

·¢¼þÈË: Dongjie (Jimmy) [mailto:jie.dong@huawei.com]
·¢ËÍʱ¼ä: 2018Äê10ÔÂ8ÈÕ 22:34
ÊÕ¼þÈË: Susan Hares; idr@ietf.org<mailto:idr@ietf.org>
³­ËÍ: draft-wang-idr-bgpls-inter-as-topology-ext@ietf.org<mailto:draft-wang-idr-bgpls-inter-as-topology-ext@ietf.org>
Ö÷Ìâ: [Idr] ´ð¸´: WG Adoption call for draft-wang-idr-bgpls-inter-as-topology-ext-02.txt (10/4/2018 to 10/18/2018)

Hi,

This document describes valid use cases of building inter-domain topology using  BGP-LS. Thus I support the adoption.

And a few comment about section 4:

The Link NLRI of BGP-LS includes the local node descriptors and remote node descriptors, in which the AS number TLV can be carried. Can this be used to specify the remote AS information? If so, the new remote AS number TLV may not be necessary.


Please clarify whether the remote ASBR-ID is similar to one of the following TLVs:

a.       BGP router-ID as defined in draft-ietf-idr-bgpls-segment-routing-epe,

b.       IGP router-ID as defined in node descriptor sub-TLVs in RFC 7752,

c.       IPv4/IPv6 Router-ID as defined in Link attribute TLVs of RFC 7752.

It would be good if some existing TLVs can be reused to fulfill the use cases described.

Best regards,
Jie

·¢¼þÈË: Idr [mailto:idr-bounces@ietf.org] ´ú±í Susan Hares
·¢ËÍʱ¼ä: 2018Äê10ÔÂ5ÈÕ 4:13
ÊÕ¼þÈË: idr@ietf.org<mailto:idr@ietf.org>
³­ËÍ: draft-wang-idr-bgpls-inter-as-topology-ext@ietf.org<mailto:draft-wang-idr-bgpls-inter-as-topology-ext@ietf.org>
Ö÷Ìâ: [Idr] WG Adoption call for draft-wang-idr-bgpls-inter-as-topology-ext-02.txt (10/4/2018 to 10/18/2018)

Greetings:

This is a WG adoption call for draft-want-idr-bgpls-inter-as-topology-ext-02.txt (10/4/2018 to 10/18/2018)..  A quick link to the draft is at:
https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/

Please comment on whether you feel this addition to the BGP-LS set of drafts will help operational management of networks.

Susan Hares
IDR co-chair