Hi, Peter: Aijun Wang China Telecom
> On Jan 5, 2022, at 21:54, Peter Psenak <ppsenak=40cisco....@dmarc.ietf.org> > wrote: > > Hi Aijun, > > please see inline (##PP): > >> On 05/01/2022 13:01, Aijun Wang wrote: >> Hi, Peter: >> Thanks for your comments. >> Please see replies inline. >> Aijun Wang >> China Telecom >>>> On Jan 5, 2022, at 18:45, Peter Psenak >>>> <ppsenak=40cisco....@dmarc.ietf.org> 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. > > ##PP > > All link related TLVs, including Inter-AS Reachability TLV share the same > Sub-TLV space, including Link Local/Remote Identifiers IPv4/IPv6 local/remote > address, etc. What exactly is missing? > > All you have defined is the prefix advertisement with the link? What is the > exact usage of the prefix that is advertised with the link? [WAJ] Yes, they all share the same sub-TLV space, but there is no place to identify the link is one stub link. There is also no sub-TLV to define the associated prefixes for the stub-Link. > >> 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. > > ##PP > I don't understand the above. We have existing sub-TLVs that include both > local and remote link data. [WAJ] Reuse the Link TLV that defined in inter-AS-TE-v2/v3 to contain such information is possible, but we should still to define the link type(as that in RFC3630) to identify the stub-link, also the prefixes related sub-TLV. Comparing the two different approaches, we select to define one new sub-TLV to contain the above information in one place together. > > >> The use case of stub link can be referred at the introduction part of the >> draft. > > ##PP > the description in the draft is very high level. Please provide an exact use > case for the prefix that is advertised with the link. [WAJ] it can be used to pair the two ends of the stub-link, it can also be used to identify the severs address that attached to the stub link. > >>> >>> 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 > > ##PP > > ok, so you want to use the prefix information of the Inter-AS Reachability > TLV to link the two endpoints of such link together? > > Inter-AS Reachability TLV includes: > > a) the "IPv4/v6 remote ASBR identifier" which identifies the remote > end-point and should carry the TE Router ID (see sections 3.3.2 and 3.3.3 of > RFC5316). > > b) The local end-point ID is advertised in the form of the "IPv4/IPv6 TE > Router ID" in the IS-IS Router Capability TLV of the originator. > > These two are sufficient to pair the two endpoints of the inter-AS link > together. [WAJ] The above remote information must be configured manually on the local device. It is paired by manual. Thinking there are many links among the ASBRs, would you like to configure them manually for every remote ends on each link? We are looking for the automatic pairing solution. The prefixes that associated with the stub link can assist to accomplish this task automatically. > > >> https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ >> <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. > > ##PP > what you have is: > > Inter-AS Reachability TLV > Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 > ISIS Stub-link Sub-TLV > Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 > > where ISIS Stub-link Sub-TLV is part of the > "Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223" > [WAJ] It seems to define one new TLV that at the same level of “Inter-AS reachability TLV”, for example “Stub-Link reachability TLV” is better. If acceptable, will update the draft. > >>> >>> 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. > > ##PP > exact use case please. [WAJ] For example, the stub-link(loop back type) can be used to identify the router; the stub-link(AS boundary type) can be used to identify the boundaries of AS; the stub-link(Vlan interface type) can be used to identify the logical GW for layer 2 domain etc. > > thanks, > Peter > > > >>> >>> >>> 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 >>>> Lsr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/lsr >>> >>> _______________________________________________ >>> Lsr mailing list >>> Lsr@ietf.org >>> https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
