[Lsr] Review of draft-ietf-lsr-isis-ttz-00.txt

[Donald Eastlake <[e-mail]>]

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   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Mon, Sep 14, 2020 at 1:07 PM <[e-mail]> 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/