Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario

"Acee Lindem (acee)" <acee@cisco.com> Wed, 21 March 2018 07:06 UTC

Return-Path: <acee@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 E2454120454 for <idr@ietfa.amsl.com>; Wed, 21 Mar 2018 00:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level:
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Vdq8olcINI-s for <idr@ietfa.amsl.com>; Wed, 21 Mar 2018 00:06:38 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3D51201FA for <idr@ietf.org>; Wed, 21 Mar 2018 00:06:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=68080; q=dns/txt; s=iport; t=1521615998; x=1522825598; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6sL9kRR0BW1GXA64z6MVXfH4Mv6XHq8+pusY5mw5AX4=; b=X3zwpTdk/eJOBr9Ek1imYmxSz0cY5OEieywRcequwJF5f7ZiPi8f2Jl+ 7sTkaqkrtAJWYAIHTPUPXZVn0g06a1BKQSgImPJB7c35aPsBQev3PSTyY Qr//cLcdhyrFahvZTkeXzaP2np3lEeaTJ60oIpRqDD+5syc6/UYWF3YZu Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ArAQBBA7Ja/4oNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYJaRTBmcigKg1OKD416gVopgRaHFYxugg4LGAEMhGwCGoM2ITQYAQIBAQEBAQECayiFJQEBAQQBASFEBwQHEAIBBgIRAwEBASEBBgMCAgIfBgsUCQgBAQQBCQQFhCpMAxUPjnibPYIlhGCCOA2BLIIJBYUvghODIwElDIJnglhEAQECAQGBNz4JBhCCSzCCJAOHLIEDhBeEd4ZOMAkChg2GCHiCK402iTQ6hiICERMBgSUBHDiBUnAVOioBghgJghoYEo4EcI02gTGBFgEBAQ
X-IronPort-AV: E=Sophos;i="5.48,338,1517875200"; d="scan'208,217";a="368613997"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2018 07:06:35 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w2L76ZYo008700 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Mar 2018 07:06:35 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Mar 2018 03:06:34 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Wed, 21 Mar 2018 03:06:34 -0400
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>, "Ketan Talaulikar (ketant)" <ketant@cisco.com>
CC: Dhruv Dhody <dhruv.ietf@gmail.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario
Thread-Index: AdO0ctzTW983pn7wRkG5g91zHcVBqALvt1ygAAlqyQAAAKcLgAApT6eA///HxoA=
Date: Wed, 21 Mar 2018 07:06:34 +0000
Message-ID: <F203469C-4B3E-419F-8864-8724EFDC2BA2@cisco.com>
References: <00a101d3b472$dd1a8310$974f8930$@org.cn> <c13ea7f1b6a54345887c0659ea9322e0@XCH-ALN-008.cisco.com> <CAB75xn52_ErQV4cbp2K-hsw7C_FrRGFnUzFuJrfGU-X4R70R6Q@mail.gmail.com> <539839a042914eaea08928562503fd26@XCH-ALN-008.cisco.com> <BB2B8346-5D40-4CA2-ADC8-614404356879@tsinghua.org.cn>
In-Reply-To: <BB2B8346-5D40-4CA2-ADC8-614404356879@tsinghua.org.cn>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.95.193]
Content-Type: multipart/alternative; boundary="_000_F203469C4B3E419F88648724EFDC2BA2ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jzvHlWb0HBcsHvCul9TpgIpHwKI>
Subject: Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 21 Mar 2018 07:06:41 -0000

Hi Aijun,

From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Wednesday, March 21, 2018 at 2:29 AM
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>, IDR List <idr@ietf.org>, Acee Lindem <acee@cisco.com>
Subject: Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario

Hi Ketan and Dhruv:

Thanks for your clarification and responses about the questions that you raised during the meeting. The followings are my considerations for these issues, if you still argues about them, we can digest the related RFC/Drafts more deeply.
1. Let's first respond the issue raised by Dhruv(it seems more easily explained:)). Normally, there will be no OSPF/IS-IS protocol deployed on the inter-AS links, then there will be no LINK NLRI of these inter-AS links being reported via the BGP-LS. So the AS Sub TLV will only be carried within the NODE NLRI of  ASBR, which is not enough to retrieve the information about the ASBR in other end. Then the newly proposed TLVs for TE Scenario are necessary to rebuild the inter-AS topology.
These TLVs should be introduced as new Link Descriptor TLVs as Ketan proposed. I will correct this point in next version.

2.Regarding the newly defined “Redistributed Routes Originator TLV” .
Actually, there's associated "Local Node descriptors" with the "Prefix Descriptor" within the "IPv4/IPv6 Topology Prefix NLRI". But as I discussed with Acee offline after the meeting, there is no indication in RFC7752 that the "Local Node descriptor" will carry the originator information of the redistributed inter-AS prefixes. From the context of the related parts in this RFC, one can often deduce that the "Local Node descriptor" will only describe the information about the node that built with the BGP-LS peer relation with the SDN controller, not the node that originated the redistributed prefixes.
If the above assumption is not true, why we need to introduce the new extension TLV "Source Router ID TLV" in https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-ext/(referred as SR-EXT later)

The Local Node Descriptor will reflect the OSPF or IS-IS Router that advertised the prefix at the corresponding flooding scope in the IGP. It should NOT reflect the BGP speaker advertising the BGP-LS address family – this wouldn’t be very useful. Also note the LS in BGP-LS stands for “Link-State” so it would only be appropriate for the Local Node Descriptor to reflect the advertising router within Link State protocol.

My understanding is that the “Source Router ID TLV” is used for prefixes that are leaked between areas by an ABR (Area Border Router). Hence, the Local Node descriptor would reflect the ABR leaking a prefix between areas and the Source Router ID would reflect the originating IS-IS router in the source area.

Thanks,
Acee

And actually, for the redistributed prefixes, the information about who reported these prefixes and who originated these prefixes are all important for the SDN controller. Then I prefer to redefine one different TLV to transfer the prefix originator information, as done by the above SR-EXT draft.

The reason that we do not use the "Source Router ID TLV" is that it covered only the IS-IS scenario currently, not include the other IGP scenarios as illustrated in our draft although it can extend to accomplish this. Even it extends this concept, it did not mention how to rebuild the inter-as topology based in this information.
And considering the various situations that summarized in https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/, we prefer to take the overlapped TLV out of the SR-EXT draft because it has less correlation with SR than Inter-AS topology retrieval.

Aijun Wang
China Telecom



在 2018年3月20日,10:44,Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> 写道:
Hi Dhruv,

You are right and perhaps new TLVs are not required (we can reuse existing).

My point was more that the Inter-AS TE link signalling via BGP-LS (that this draft addresses) is not yet covered and but that this draft should be corrected to indicate how these node/link descriptors need to be used for such links.

Thanks,
Ketan

From: dhruvdhody@gmail.com<mailto:dhruvdhody@gmail.com> <dhruvdhody@gmail.com<mailto:dhruvdhody@gmail.com>> On Behalf Of Dhruv Dhody
Sent: 20 March 2018 10:26
To: Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>>
Cc: Aijun Wang <wangaijun@tsinghua.org.cn<mailto:wangaijun@tsinghua.org.cn>>; idr@ietf.org<mailto:idr@ietf.org>
Subject: Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario

Hi Ketan, Aijun,

On Tue, Mar 20, 2018 at 10:13 AM, Ketan Talaulikar (ketant) <ketant@cisco.com<mailto:ketant@cisco.com>> wrote:
Hi Aijun,

Perhaps the comments provided during the IDR WG meeting yesterday on this draft were not clear and would like to share the same on the list.


1)     The “Redistributed Routes Originator TLV” is not necessary and if your intention is to determine the originating router for redistributed routes then this is already solved as follows:

a.      The Prefix NLRI descriptor includes the Node descriptor which allows determination of the originator of the redistribution point router.

b.      The Source Router ID TLV is required in ISIS only because the redistribution point router may be in a different level/area and unlike OSPF where the flooding for type 5 is AS scope, this TLV is required for ISIS. The BGP-LS spec allows use of this Source Router ID TLV for any protocol in general, if required.

2)     The 2nd part of your draft which relates to signalling of inter-AS TE links is required and missing from the current BGP-LS specs AFAIK. However, the draft is not handling this properly. The new TLVs which you have listed in sec 3.3.2 need to be introduced as new Link Descriptor TLVs – not as attributes. While descriptor and attribute TLVs are taken from the same registry, they are very different from packaging perspective. So the draft needs to be fixed to correct this.


​   The Link NLRI (NLRI Type = 2)


is shown in the following figure.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+
     |  Protocol-ID  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Identifier                          |
     |                            (64 bits)                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Local Node Descriptors (variable)             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //               Remote Node Descriptors (variable)            //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                  Link Descriptors (variable)                //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 8: The Link NLRI Format

The Autonomous System sub-TLV is part of both Local and Remote Node Descriptors.
For inter-AS link, the AS sub-TLV (as part of the Remote node descriptor) carry the remote AS number?
Do we really need a new sub-TLV? ​

​Or am I missing something? ​

Thanks!
Dhruv



In summary, your draft does address a gap with respect to signalling of inter-AS TE links from IGPs into BGP-LS, but there is no gap when it comes to determination of redistributed route’s originators.

Thanks,
Ketan

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Aijun Wang
Sent: 05 March 2018 11:13
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario

Hi, All:

We just uploaded one draft at https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/ to describe the BGP-LS extension for inter-as topology retrieval in different scenarios.
We are also applying the time slot on the upcoming IETF 101 meeting to present this topic. Any comments are welcome.

The abstracts of this draft are the followings:
This document describes new TLVs extended for BGP-LS to transfer the originator of redistributed routes and other inter-AS TE related TLVs to let the SDN controller to retrieve the network topology automatically under the multi-domain environments.
This extension can expand the usage of BGP-LS protocol to multi-domain; enable the network operator to collect the connection relationship between different domains and then calculate the overall network topology automatically based on the information provided by BGP-LS protocol.


Best Regards.

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



_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr