Hi Donald, Thank you very much for your valuable comments. They are addressed inline below with prefix [HC].
Best Regards, Huaimo ________________________________ From: Lsr <lsr-boun...@ietf.org> on behalf of Donald Eastlake <d3e...@gmail.com> Sent: Tuesday, September 22, 2020 1:21 AM To: lsr@ietf.org <lsr@ietf.org> Subject: [Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt Hi, Here are some comments on draft-ietf-lsr-isis-ttz. These are not in any particular order. Section 1.1, the requirements language section should be updated to the current wording that references RFC 8174. [HC]: We will add the following text in the end of the section: [RFC8174] when, and only when, they appear in all capitals, as shown here. Towards the end of Section 4.1.3, I'm not sure exactly what an "LS ID" is and what it is used for. Does it relate to the IS-IS LSP ID or IS-IS LSP Sequence number? [HC]: We will revise and add some details about it. It is related to LSP ID. At the end of Section 4.1.3, I don't understand the reference to "stub links". If reachability to some addresses inside the TTZ needs to be advertised, why can't the virtual node representing the TTZ just advertise reachability to those addresses? What do "links" have to do with it? [HC]: The “stub links” means “stub networks” or say IP prefixes including loopback IP addresses “attached” to the virtual node (i.e., in the zone). For those IP prefixes/addresses in the zone to be accessible outside, they are included in the IP reachability TLV of the LSP for the virtual node. We will revise the related text in the draft about this. The procedures in Section 4.1.4 are presumably an optimization to more rapidly switch a neighbor to adjacency with the virtual node representing a zone. Presumably it all works without this since it says earlier that nodes outside the TTZ do not need to be aware of the TTZ. If it is an optimization, perhaps there should be a capability bit to indicate support. The draft should say what happens for invalid combinations of flag bits, for example both N and T are set in the Adjacent Node ID TLV? Should such a TLV be ignored? [HC]: We will simplify this section and remove the optimization. I think all occurrences of "CLI" should be replaced by "management" (or, if you really want, "management, such as CLI,". [HC]: We will update related text as you suggested accordingly. The IS Neighbor and ES Neighbor sub-TLVs seem to be patterned after the so called narrow metric TLV (#2). It is my impression that the so called wide metric TLV (#22) is more common these days so you might consider providing such a sub-TLV. Perhaps for Experimental use this is not very important. [HC]: We will change it to wide metric. One final question: I may be confused but my understanding of IS-IS is that there are Level 1 links, Level 2 links, and links that are both Level 1 and 2. A border router between Level 1 and Level 2 is a router that has both types of links attached to it. Such a router is a part of each Level 1 Area to which it is linked and a part of Level 2. So, the Level 1 / Level 2 boundary is, in a real sense, internal to such a border router. This does not seem to be a problem if a border router is part of a TTZ abstracted to a full mesh of the TTZ edge routers since it would seem straightforward for such a TTZ edge router to also be an IS-IS border router. However, when a TTZ is abstracted to a single virtual node, apparently that TTZ could include a border router since the draft says it could include all the routers in a Level 1 area which would include any border routers. So it would seem that the resulting single virtual node would also have to appear to be a border router and have Level 2 virtual adjacencies for every such adjacency that the real nodes in the TTZ have in addition to any Level 1 adjacencies it has. I do not think there is necessarily a problem here but it is not clear to me how this works from the draft. [HC]: We will add details about the TTZ/zone having area border routers into the draft. For area border router X that is on the TTZ, it (acting as the virtual node for the TTZ) forms L2 adjacency with the router Y connected to X in the backbone area and outside of the TTZ and sends the LSP for the virtual node to the router Y if the TTZ includes all the routers in its area. For TTZ edge router Ex, it (acting as the virtual node) forms L1 adjacency with the router Y connected to Ex in its L1 area and outside of the TTZ/zone and sends the LSP for the virtual node to the router Y. The LSP for the virtual node contains the adjacencies between the virtual node and the routers connected to the TTZ and outside of the TTZ. I also have a number of editorial and wording suggestions that I have sent to the authors. [HC]: We will revise the draft as you suggested accordingly. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Mon, Sep 14, 2020 at 1:07 PM <internet-dra...@ietf.org> wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Link State Routing WG of the IETF. > > Title : IS-IS Topology-Transparent Zone > Authors : Huaimo Chen > Richard Li > Yi Yang > Yanhe Fan > Ning So > Vic Liu > Mehmet Toy > Lei Liu > Kiran Makhijani > Filename : draft-ietf-lsr-isis-ttz-00.txt > Pages : 23 > Date : 2020-09-14 > > Abstract: > This document presents a topology-transparent zone in an area. A > zone is a block/piece of an area, which comprises a group of routers > and a number of circuits connecting them. It is abstracted as a > virtual entity such as a single virtual node or zone edges mesh. Any > router outside of the zone is not aware of the zone. The information > about the circuits and routers inside the zone is not distributed to > any router outside of the zone. > > > The IETF datatracker status page for this draft is: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-ttz%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&sdata=H0goxD%2FO4Cy%2BqEY5Xl6VFCZtsxdMU%2BCsCXj1DJApjFk%3D&reserved=0 > > There are also htmlized versions available at: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-lsr-isis-ttz-00&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&sdata=rGBezthZM%2FAsQUaSRZVc8KOqwSe%2Fh2gnpTApfu8Ro1A%3D&reserved=0 > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-isis-ttz-00&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&sdata=8ZS3onjvxxyZXfIspi9dLIqE8aNB4v84Dh8Me2brmlQ%3D&reserved=0 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2F&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&sdata=s70XFxS0C7V1wM0eJtmV0YlGXC%2Fnw2T9sSq%2BRTLiQAs%3D&reserved=0 _______________________________________________ Lsr mailing list Lsr@ietf.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093761767&sdata=vcKQ2q8oJqtergNZ0BoOrAB9jZagx7HDg5aAjwPG%2FNg%3D&reserved=0
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr