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. 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? 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? 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? I think all occurrences of "CLI" should be replaced by "management" (or, if you really want, "management, such as CLI,". 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. 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. I also have a number of editorial and wording suggestions that I have sent to the authors. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA [email protected] On Mon, Sep 14, 2020 at 1:07 PM <[email protected]> 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://datatracker.ietf.org/doc/draft-ietf-lsr-isis-ttz/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-lsr-isis-ttz-00 > https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-ttz-00 > > > 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: > ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
