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

"Aijun Wang" <wangaijun@tsinghua.org.cn> Wed, 28 March 2018 03:12 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B72B7126BF3 for <idr@ietfa.amsl.com>; Tue, 27 Mar 2018 20:12:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xGUbUlsXPD76 for <idr@ietfa.amsl.com>; Tue, 27 Mar 2018 20:12:37 -0700 (PDT)
Received: from m21397.mail.qiye.163.com (m21397.mail.qiye.163.com []) by ietfa.amsl.com (Postfix) with ESMTP id C8C03120724 for <idr@ietf.org>; Tue, 27 Mar 2018 20:12:34 -0700 (PDT)
Received: from WangajPC (unknown []) by m21397.mail.qiye.163.com (Hmail) with ESMTPA id E1FBF142CF6; Wed, 28 Mar 2018 11:12:11 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Acee Lindem \(acee\)'" <acee@cisco.com>, "'Jeff Tantsura'" <jefftant.ietf@gmail.com>
Cc: "'Ketan Talaulikar \(ketant\)'" <ketant@cisco.com>, <idr@ietf.org>
References: <0E372571-0C5D-48C7-A635-62366B2389B4@cisco.com>
In-Reply-To: <0E372571-0C5D-48C7-A635-62366B2389B4@cisco.com>
Date: Wed, 28 Mar 2018 11:12:10 +0800
Message-ID: <008b01d3c642$90690820$b13b1860$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01D3C685.9E8C4820"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHTxS3iDxB/OJJb4ECfV1g8qQ3hr6Pk3R6Q
Content-Language: zh-cn
X-HM-Tid: 0a626a976f257f6bkuuke1fbf142cf6
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uIWjn6IoUI8xOS1Y_RooTcpt_-I>
Subject: [Idr] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBCR1AtTFMgZXh0ZW5zaW9uIGZv?= =?utf-8?q?r_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, 28 Mar 2018 03:12:42 -0000

Hi, Acee:


The previous case is mainly for proposal that related to “Redistributed Route Originator” TLV, which is used in the non-TE scenario as I mentioned on the meeting.


The “Remote-AS”, “IPv4-Remote ASBR ID”, “IPv6 Remote ASBR ID” TLVs are used in TE scenario, in which case the TE is deployed within each domain and it is no need to redistribute the inter-AS link into the IGP domain, because TE will be configured also on these inter-AS links(still no IGP on these links). As described in [RFC5316] <https://tools.ietf.org/html/rfc5316> , [RFC5392] <https://datatracker.ietf.org/doc/html/rfc5392>  , “Remote AS Number Sub-TLV”, “IPv4 Remote ASBR ID Sub-TLV”, “IPv6 Remote ASBR ID Sub-TLV” will be generated by the ASBR and flooded within each domain. 

Our proposal ([draft-wang-idr-bgpls-inter-as-topology-ext] <https://datatracker.ietf.org/doc/draft-wang-idr-bgpls-inter-as-topology-ext/> ) is just to report these TLVs to the SDN controller, using the same semantic via the newly introduced TLVs for BGP-LS protocol, to facilitate the SDN controller to rebuild the inter-AS topology under this TE scenario.


Regarding to the non-TE scenario, the reason that we propose the newly introduced “Redistributed Route Originator” TLV are the followings:

1)       There is no clear clarification for what information should be carried via the “Local Node Descriptors” that is associated with “Prefix Descriptors” in IPv4/IPv6 Topology Prefix NLRI format.

2)       The recommendation from you and Ketan are reasonable, but it is also valuable to carry the information about who reports the “redistributed prefix”, because when SDN application retrieve the topology information from SDN controller, there is no information about it, although the SDN controller knows this. 

3)  [rfc7752#section-3.5] <https://tools.ietf.org/html/rfc7752#section-3.5>  leave the placeholder for “inter-AS links” as it said  “The exact mechanism used to provision the inter-AS links is outside the scope of this document”. Our proposal describes just these mechanisms in various scenario.

4)  It is more clear and consistent to let the  “Local Node Descriptors” carry the reporter information about the “redistributed prefix”, and let “Redistributed Route Originator” TLV to carry the originator of these “redistributed prefix”.



Best Regards.


Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.


发件人: Acee Lindem (acee) [mailto:acee@cisco.com] 
发送时间: 2018年3月27日 2:12
收件人: Aijun Wang; 'Jeff Tantsura'
抄送: Ketan Talaulikar (ketant); idr@ietf.org
主题: Re: 答复: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario


Hi Aijun, 


In this case, you don’t know anything about the remote end of these inter-AS links other than possibly the next hop. I’m not sure why you referenced new TLVs for the Remote-AS, IPv4-Remote ASBR ID, and IPv6 Remote ASBR ID. 

As I previously stated, the local node descriptors for the prefix will contain the ASBR that redistributes the prefix into the IGP – NOT the BGP speaker. I don’t think we need a draft for this. 



From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Sunday, March 25, 2018 at 10:55 PM
To: Acee Lindem <acee@cisco.com>om>, Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>om>, IDR List <idr@ietf.org>
Subject: 答复: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario


Hi, Acee:


We run BGP session between the loopback addresses of ASBRs in different domains, and redistribute the static routes(via inter-as physical links) to different domain respectively to ensure the connectivity to these BGP nexthop.

There is no dynamic IGP run between these different domain, then normally BGP-LS in each domain can’t get the information about inter-AS links.

We want to reconstruct the whole network topology on SDN controller automatically, include not only the topology in each domain, but also the inter-AS topology, to facilitate the inter-AS traffic engineering deployment under various scenario(based on mpls, or in Native IP network etc.)


Best Regards.


Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.


发件人: Acee Lindem (acee) [mailto:acee@cisco.com] 
发送时间: 2018年3月26日 6:10
收件人: Aijun Wang; Jeff Tantsura
抄送: Ketan Talaulikar (ketant); idr@ietf.org
主题: Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario


Hi Aijun


From: Aijun Wang <wangaijun@tsinghua.org.cn>
Date: Thursday, March 22, 2018 at 4:14 AM
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: "Ketan Talaulikar (ketant)" <ketant@cisco.com>om>, Acee Lindem <acee@cisco.com>om>, IDR List <idr@ietf.org>
Subject: Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario


Hi, Ketan and Jeff


If we don't introduce new TLV to transfer the Remote-AS, IPv4-Remote ASBR ID, IPv6 Remote ASBR ID, how can you distinguish them from the Local-AS, IPv4 TE Router ID and IPv6 TE Router ID?


We should keep in mind that there will be no IGP run on these inter-AS link, then the advertising behavior of these informations is different from the links within the IGP domain.


Are you running BGP on the Inter-AS links? It isn’t clear what you are trying to correlate. This is a completely different proposal than your draft. 


And also to Acee:

There is no more meaning to know the advertising router information(via "Local Node Descriptor")when the redistributed prefixes is leaked between different in IS-IS as you mentioned. What we want to know is the originator of the redistributed prefixes via the RRO TLV, together with who reports these information via the "Local Node Descriptor" that is associated with the "Prefixes Descriptor". 


And considering these ambiguous, I think it is necessary to propose one new draft to clarify these points, which should include the scenarios, existing TLV reusable guidelines, new TLV definition and the procedure descriptions for inter-AS topology retrieval. The relationship of this draft with RFC7752 should be similar with that between RFC5316(https://tools.ietf.org/html/rfc5316 <https://tools.ietf.org/html/rfc5316#section-3.3.5> ) and RFC5305(https://tools.ietf.org/html/rfc5305).


Section 3.5(https://tools.ietf.org/html/rfc7752#section-3.5) as mentioned by Ketan also said "

The exact mechanism used to provision the inter-AS links is outside the scope of this document", then I think we should start this work now.
I think you need to make your use case clear. What are you trying to correlate and, more importantly, how will you use this information? 
Best Regards.
Aijun Wang
China Telecom 


在 2018年3月21日,10:18,Jeff Tantsura <jefftant.ietf@gmail.com> 写道:

I agree with the comments by Acee/Ketan.

It seems that some clarification text might benefit the future applications making use of the technology.




From: Idr <idr-bounces@ietf.org> on behalf of "Ketan Talaulikar (ketant)" <ketant@cisco.com>
Date: Wednesday, March 21, 2018 at 09:00
To: "Acee Lindem (acee)" <acee@cisco.com>om>, Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario


Hi Aijun


As Acee and I have pointed out in the meeting and again on this list, there seems to be some misunderstanding of BGP-LS advertisement of prefixes. Please check inline below.


From: Acee Lindem (acee) 
Sent: 21 March 2018 07:07
To: Aijun Wang <wangaijun@tsinghua.org.cn>cn>; Ketan Talaulikar (ketant) <ketant@cisco.com>
Cc: Dhruv Dhody <dhruv.ietf@gmail.com>om>; idr@ietf.org
Subject: Re: [Idr] BGP-LS extension for inter-as topology retrieval in different scenario


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>om>, IDR List <idr@ietf.org>rg>, 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.

[KT] After having thought over this a bit more, I would recommend the following since these are described in  <https://tools.ietf.org/html/rfc7752#section-3.5> https://tools.ietf.org/html/rfc7752#section-3.5 just that the procedure is not clearly specified:

-          There is no need to introduce any new TLVs

-          The Local Node descriptor should include the local AS number and the local IGP ID

-          The Remote Node descriptor should include the remote AS number and the remote IGP ID

-          The link descriptor should include the local address and/or the local-id. The remote address/ID MAY be included if available.


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.

[KT] The underlying IGP LSA or LSP info is reflected in the BGP-LS.

>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/> 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. 

[KT] I agree completely. Doing it any different would be an implementation bug.


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. 

[KT] This is correct. As the example that I had provided, there is no AS scope flooding in ISIS and prefixes are leaked between ISIS levels then the originator information is lost. Similar may apply for OSPF for inter-area prefixes. The Source Router ID TLV in BGP-LS is usable for any protocol – please check  <https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#page-16> https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-ext-04#page-16 




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/> 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.

[KT] The TLVs are not tied to a specific use-case and there is no point duplicating TLVs with exactly the same semantics just because they are being used for different use-cases. I think this is where I have a disconnect and disagreement with this draft proposal.


Aijun Wang

China Telecom



在 2018年3月20日,10:44,Ketan Talaulikar (ketant) < <mailto:ketant@cisco.com> 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.





From:  <mailto:dhruvdhody@gmail.com> dhruvdhody@gmail.com < <mailto:dhruvdhody@gmail.com> dhruvdhody@gmail.com> On Behalf Of Dhruv Dhody
Sent: 20 March 2018 10:26
To: Ketan Talaulikar (ketant) < <mailto:ketant@cisco.com> ketant@cisco.com>
Cc: Aijun Wang < <mailto:wangaijun@tsinghua.org.cn> wangaijun@tsinghua.org.cn>gt;;  <mailto:idr@ietf.org> 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) < <mailto:ketant@cisco.com> 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? ​







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.





From: Idr < <mailto:idr-bounces@ietf.org> idr-bounces@ietf.org> On Behalf Of Aijun Wang
Sent: 05 March 2018 11:13
To:  <mailto:idr@ietf.org> 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/> 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
 <mailto:Idr@ietf.org> Idr@ietf.org
 <https://www.ietf.org/mailman/listinfo/idr> https://www.ietf.org/mailman/listinfo/idr


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