Hi, Peter: Thanks for your comments. Please see replies inline.
Aijun Wang China Telecom > On Jan 5, 2022, at 18:45, Peter Psenak <[email protected]> > wrote: > > Hi, > > I'm afraid the draft has some serious issues that would need to be addressed > if it is to become a WG document. > > Below comments use ISIS as an example, but most of it applies to OSPF as well. > > > 1. The draft says: > > "ISIS[RFC5316] defines the Inter-AS Reachability TLV to carry the TE > information about inter-AS links. This TLV can be used to transfer > the information about the stub link which is located at the boundary > of one AS. This document defines the Stub-Link sub-TLV within this > TLV to identify the stub link and transfer the associated attributes." > > - there is an existing mechanisms to advertise inter-AS link. There is > existing mechanisms to advertise external prefix. What exactly is the reason > to define a new TLV? > > It's still not clear to me what exactly is the use case for the new TLVs > defined in the document. [WAJ] RFC 5392 and RFC 5316 defines the TLV to carry the information about other endpoint for the inter-AS link, for example , the remote ASBR ID, the remote AS etc. Such information are normally derived from the manual configuration. For stub link, there are situations that the above information can’t easily be obtained or doesn’t exist, what we can get only the information about the local end, not the information about the remote end. Then It is better to use different TLV to differentiate the local information from the remote information. Define the Stub-Link TLV to contain such local obtained information is then the reasonable way. The use case of stub link can be referred at the introduction part of the draft. > > 2. Looking at the proposed ISIS Stub-link Sub-TLV, which is a sub-TLV of the > existing Inter-AS Reachability TLV: > > - it advertises prefix. The advertisement of the prefix and link information > is strictly decoupled in ISIS. Here the proposal is to advertise the prefix > inside the Inter-AS Reachability TLV, which is advertising a link. Why do we > need the prefix of the inter-AS link to be advertised inside the link > advertisement? [WAJ]For stub link, what we can get is only the interface addresses of the local end and its associated prefixes. The associated prefixes can be used to match the two ends of the stub-link, it can also indicate the server’s address as that described in https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/. > > 2. The new ISIS Stub-link Sub-TLV includes sub-TLVs, the text says: > > "Sub-TLVs: Existing sub-TLVs that defined within "Sub-TLVs for TLVs > 22, 23, 25, 141, 222, and 223" can be included if necessary." > > The parent Inter-AS Reachability TLV already has Sub-TLVs from the exact same > space. Not to mention that the new sub-TLV itself comes from the same space. [WAJ] 141(inter-AS reachability information) is mentioned in the above sentence. > > 3. Link Type in ISIS Stub-link Sub-TLV - what is it used for and why do we > need it? [WAJ] There are different kinds of stub link. Differentiate them via the link type can help the precise control and analyze these stub links. > > > thanks, > Peter > > > >> On 04/01/2022 07:58, Christian Hopps wrote: >> Hi Folks, >> This begins a 2 week WG Adoption Call for the following draft: >> https://datatracker.ietf.org/doc/draft-wang-lsr-stub-link-attributes/ >> Please indicate your support or objections by January 18th, 2022. >> Authors, please respond to the list indicating whether you are aware of any >> IPR that applies to these drafts. >> Thanks, >> Chris. >> _______________________________________________ >> Lsr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
