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

[Huaimo Chen <[e-mail]>]

Hi Donald,

    Thank you very much for your valuable comments.
    They are addressed inline below with prefix [HC].

Best Regards,
Huaimo
________________________________
From: Lsr <[e-mail]> on behalf of Donald Eastlake <[e-mail]>
Sent: Tuesday, September 22, 2020 1:21 AM
To: [e-mail] <[e-mail]>
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   [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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-lsr-isis-ttz%2F&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&amp;sdata=H0goxD%2FO4Cy%2BqEY5Xl6VFCZtsxdMU%2BCsCXj1DJApjFk%3D&amp;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&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&amp;sdata=rGBezthZM%2FAsQUaSRZVc8KOqwSe%2Fh2gnpTApfu8Ro1A%3D&amp;reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lsr-isis-ttz-00&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&amp;sdata=8ZS3onjvxxyZXfIspi9dLIqE8aNB4v84Dh8Me2brmlQ%3D&amp;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&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093751808&amp;sdata=s70XFxS0C7V1wM0eJtmV0YlGXC%2Fnw2T9sSq%2BRTLiQAs%3D&amp;reserved=0

_______________________________________________
Lsr mailing list
[e-mail]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Flsr&amp;data=02%7C01%7Chuaimo.chen%40futurewei.com%7Ca33d6822b9cb4fc9e2cb08d85eb76710%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637363489093761767&amp;sdata=vcKQ2q8oJqtergNZ0BoOrAB9jZagx7HDg5aAjwPG%2FNg%3D&amp;reserved=0