Hi Aijun, Please check inline below.
On Wed, Jul 27, 2022 at 5:07 PM Aijun Wang <[email protected]> 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. > > > > *发件人:* [email protected] [mailto:[email protected]] *代表 *Ketan > Talaulikar > *发送时间:* 2022年7月27日 17:32 > *收件人:* [email protected] > *抄送:* lsr <[email protected]> > *主题:* [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 > > >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
