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

[Aijun Wang <[e-mail]>]

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]] 代表 Ketan Talaulikar
发送时间: 2022年7月27日 17:32
收件人: [e-mail]
抄送: lsr <[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?

 

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. 

 

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? 

 

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.

 

Thanks,

Ketan