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

["Aijun Wang" <[e-mail]>]

Hi, Ketan:

 

Thanks for your supports and comments.

I replied to the detail issues inline below, please refer them for our
current considerations. 

 

On summary, there may be several options to accomplish the requirements, we
will try to find the most suitable way, based on the implementation
experience of BGP-LS protocol, from Cisco and other vendors in future.  

Wish to get more helps, comments, contribution from you and other experts on
this draft.

 

 

Best Regards.

 

Aijun Wang

Network R&D and Operation Support Department

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

·¢¼þÈË: Ketan Talaulikar (ketant) [mailto:[e-mail]] 
·¢ËÍʱ¼ä: 2018Äê10ÔÂ9ÈÕ 15:13
ÊÕ¼þÈË: Aijun Wang; 'Dongjie (Jimmy)'; 'Susan Hares'; [e-mail]
³­ËÍ: [e-mail]
Ö÷Ìâ: RE: [Idr] ´ð¸´: ´ð¸´: WG Adoption call for
draft-wang-idr-bgpls-inter-as-topology-ext-02.txt (10/4/2018 to 10/18/2018)

 

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.

[Aijun Wang]: The primary aim that we use different TLVs is to distinguish
these inter-as links easily from the internal links that the original
IGP/BGP-LS advertise. One possible approach is to define one new NLRI(for
example inter-AS link NLRI) and reuses the existing the TLV; or we reuse the
existing Link NLRI, but use different TLVs.  If we do not take such
approaches, then it is not easy for the controller to filter the inter-as
links from BGP-LS report information.  This is similar requirements as
described in RFC5316 <https://tools.ietf.org/html/rfc5316>  (inter-AS TE for
ISIS) and RFC5392 <https://tools.ietf.org/html/rfc5392> (inter-AS TE for
OSPF)

 

 

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.

                        [Aijun Wang] You are right. Not every
redistributed/external routes be inter-as links. To exclude the possible
exception, we can tag the redistributed inter-AS links, distinguish them
from the other redistributed prefixes. This is general administration
issues. We can add this in the updated version of this draft.

 

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

                        [Aijun Wang] I have described the retrieval process
at the present slide
<https://datatracker.ietf.org/meeting/102/materials/slides-102-idr-sessb-bgp
-ls-extend-for-inter-as-topology-retrieval-00>  in IETF 102 meeting. Will
this be help to you to grasp its essence? Anyway, the controller has more
capability to retrieval the inter-as topology based on the additional report
information via BGP-LS. We can discuss its applicable scenarios later in
detail.

  

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 <[e-mail]> On Behalf Of Aijun Wang
Sent: 09 October 2018 07:34
To: 'Dongjie (Jimmy)' <[e-mail]>; 'Susan Hares'
<[e-mail]>; [e-mail]
Cc: [e-mail]
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#se
ction-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:[e-mail]] 
·¢ËÍʱ¼ä: 2018Äê10ÔÂ8ÈÕ 22:34
ÊÕ¼þÈË: Susan Hares; [e-mail]
³­ËÍ: [e-mail]
Ö÷Ìâ: [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:[e-mail]] ´ú±í Susan Hares
·¢ËÍʱ¼ä: 2018Äê10ÔÂ5ÈÕ 4:13
ÊÕ¼þÈË: [e-mail]
³­ËÍ: [e-mail]
Ö÷Ìâ: [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