[Lsr] 答复: Comments on draft-wang-lsr-stub-link-attributes

[Aijun Wang <[e-mail]>]

Hi, Ketan and Acee:

 

Let me answer all your concern in the top post mode for brevity.

1)     For inter-AS link that described in  https://www.ietf.org/archive/id/draft-ietf-idr-bgpls-inter-as-topology-ext-11.txt, the AS number needn’t be configured and carried by the advertisement of every inter-AS link.

2)     The definition and inclusion of “Prefixes sub-TLV” doesn’t preclude other sub-TLV (for example, the local and remote identifier of the inter-AS link, if they are exist and can be known in advance)being included within the “Stub-Link TLV” if necessary.

3)     For the encoding of “Stub Link TLV”, I agree with your suggestions. We can put them in one more general container. 

For example, OSPFv2 related part can be put in https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xhtml#extended-link-opaque-lsa-tlvs (defined as “OSPFv2 Extended Stub-Link TLV”, which is corresponding to “OSPFv2 Extended Link TLV”)and OSPFv3 related part can be put in https://www.iana.org/assignments/ospfv3-parameters/ospfv3-parameters.xhtml#extended-lsa-tlvs (defined as “Router-Stub-Link TLV”?, which is corresponding to the “Router-Link TLV”).

 

For IS-IS, current version of the draft has stated that:

“Existing Sub-TLVs: Sub-TLVs that defined within "IS-IS Sub-TLVs for

   TLVs Advertising Neighbor Information " can be included if necessary.”

   Is it enough to illustrate that the newly defined TLV is one of the top TLV in IS-IS?

 

 

To Acee’s concerns about running BGP-LS in every border router:

We think such solution and deployment will decrease the brevity and efficiency of BGP-LS.  Normally, we need only one or two routers(for redundancy) within the domain to run BGP-LS with the controller. 

And, for other broader applications(EPE like approach to the connected server), such information can also be utilized by other internal routers, not only the controller. 

 

 

Best Regards

 

Aijun Wang

China Telecom

 

发件人: [e-mail] [mailto:[e-mail]] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 21:35
收件人: Aijun Wang <[e-mail]>
抄送: [e-mail]; lsr <[e-mail]>
主题: Re: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

 

Hi Aijun,

 

Please check inline below.

 

On Wed, Jul 27, 2022 at 5:07 PM Aijun Wang <[e-mail] <mailto:[e-mail]> > wrote:

Hi, Ketan:

 

Thanks for your comments and suggestions!

Some responses are inline below.

We can update the draft accordingly after we reach consensus on these points.

 

 

Best Regards

 

Aijun Wang

China Telecom.

 

发件人: [e-mail] <mailto:[e-mail]>  [mailto:[e-mail] <mailto:[e-mail]> ] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 17:32
收件人: [e-mail] <mailto:[e-mail]> 
抄送: lsr <[e-mail] <mailto:[e-mail]> >
主题: [Lsr] Comments on draft-wang-lsr-stub-link-attributes

 

Hello Authors,

 

Please find below my comments/suggestions on this draft. I am sharing them upfront given the packed LSR agenda.

 

1)  Sec 3 the rationale provided for not using the Inter-AS TE LSAs/TLVs is not sound in my opinion. I would say that the TE encoding may not be suitable for use in all deployments as their advertisement results in the addition of those Inter-AS links in a TE topology database and that may not be desired. So, I would suggest that the draft keeps the option of use of Inter-AS TE TLVs valid and goes ahead with the Stub Link proposal as an alternative with broader applicability (also see the next comment).

【WAJ】Yes, in the corresponding non-TE scenario, we don’t want to add additional information to the TE topology database. How about to add such statements, together with existing descriptions?

 

KT> IMHO the existing reason (and I am paraphrasing) "I don't want to configure local/remote AS on the intra-AS link endpoint routers" is not a justification for introducing a new TLV. If it is truly an Intra-AS link, then we should have those AS numbers.

 

 

2)  For the proclaimed wider applicability (e.g., links to servers/hosts) in the slides, there is no such text in the draft. The draft seems focused on Inter-AS links. I hope the authors update either the draft or the slides - to be in sync with their objectives.

【WAJ】If the WG agree the use case of links to servers/hosts, we can add some description back to the draft.

KT> I think it is for the proponents to share the use case that is motivating them. I personally did not find the previous reference to draft-dunbar-lsr-5g-edge-compute to be a good use case.

 

 

3)  The use of the prefix TLVs in this context is something that is (in my opinion) broken from day 1 of this draft. Prefixes are for reachability. For identification of links, we have the local/remote link identifiers along with the local/remote IP addresses (NOT prefixes!). This to me is a NO-GO for the progression of this document.

【WAJ】We consider “prefix TLV” is one kind of link attributes, which is same as other link attributes, not the identification of links.

Can you accept such explanations?

KT> No. Prefix advertisements are mostly related to reachability. I am suggesting the use of IP endpoint addresses as link identifiers - this is existing practice and can be extended for stub links too (note that the remote address/link-id can be 0 when unknown). So I fail to understand why you would wish to hold on to the prefix advertisement as a link attribute? Please clarify with a use case description, if I am missing something.

 

 

4)  The placement of the Stub Link TLV should be top-level (similar to other/existing links). I can share further suggestions offline, provided we reach an agreement on the above points and we converge on the main purpose/motivation for this work.

【WAJ】In the current draft, the IANA codepoint for the Stub Link TLV is allocated from https://www.iana.org/assignments/ospf-traffic-eng-tlvs/ospf-traffic-eng-tlvs.xhtml#top-level, which is already top-level(same as Link TLV). For IS-IS, it is also allocated from the top-level(https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml#tlv-codepoints). Are they reasonable? Anyway, we are welcome your further suggestions.

KT> Why use the TE TLVs for OSPF if the intention is to generalize it so it is not just specific to TE topology links? If the intention is to only over Intra-AS TE links then the solution already exists and we don't need the stub link. ISIS seems ok, but the document does not refer to existing ISIS TLVs (e.g., regarding sharing of sub-TLV space with which existing TLVs) and so it was not very clear to me.

 

Thanks,

Ketan

 

 

Thanks,

Ketan