[Anima] Review of draft-ietf-anima-stable-connectivity-02

Sheng Jiang <jiangsheng@huawei.com> Tue, 20 June 2017 08:00 UTC

From: Sheng Jiang <jiangsheng@huawei.com>
To: Anima WG <anima@ietf.org>
CC: "anima-chairs@ietf.org" <anima-chairs@ietf.org>
Thread-Topic: Review of draft-ietf-anima-stable-connectivity-02
Thread-Index: AdLpmz27hzNx1om7RNeFQD3MAwJWUA==
Date: Tue, 20 Jun 2017 08:00:33 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B927CDE5CCF@NKGEML515-MBX.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B927CDE5CCFNKGEML515MBXchi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/FWTIolOC27mA0gShEmMdZAWdM-c>
Subject: [Anima] Review of draft-ietf-anima-stable-connectivity-02
Precedence: list

Hi, authors of draft-ietf-anima-stable-connectivity,

I am doing a thorough review as the document shepherd with my ANIMA chair hat on. Please address the below comments so that we could process this document further.

First, I have issues for section 2.1.4, "IPv4 only NOC application devices". It would be an unlike scenario to manage an IPv6 network (all managed devices are IPv6 enabled) with IPv4 only NOC application devices. Furthermore, the NAT64 setup in this scenario is complex, and connectivity between IPv4 only NOC application devices and NAT is unsecure. I would suggest to reduce the whole section or add a clear statement that it is a not-recommended scenario at the end of this section.

Secondly, the description and category in section 2.1.2, "Limitations and enhancement overview". For me, only the point 1 & 3 are really limitation of ACP itself. Point 2 is a precondition (it is actually conflicted with section 2.1.4.) I don't understand point 4. What does "exposing the ACP natively" mean?

Thirdly, I have issues to use names to distinguish the path selection policies. This is a chicken&egg issue in the autonomic scenario. Who and how the DNS names are setup, by human administrator? If there is a mechanism to distinguish the IP addresses of ACP and data-plane without human intelligence, why does it bore to use DNS? DNS registration & lookup by itself is a very complex and time-consumption procedure. If we don't want to show the semantic of these addresses to any human, names are meaningless.

In section 2.2, "The ACP can provide common direct-neighbor discovery and capability negotiation". This is a wrong statement. ANI does provide this, but it is done by GRASP, not ACP.

At the end of section 2.1.3, "A simple short-term workaround could be a physical external loopback cable into two ports of ANrtr1 to connect the data-plane and ACP VRF as shown in the picture." Does this has to be "a PHYSICAL external loopback CABLE"? It sounds like a very strong requirement. Personally, I believe this could be done by a virtual loopback interface.

Section 3, "Security considerations" is more like a deployment considerations. Both ULA-C and reverse DNS are additional deployment

Minor comments,

Section 2.1.6, "Autonomic NOC device/applications" should be moved to early part of this document. For me, it is the default scenario/requirement. It should be section 2.1.1, I guess.

It is worth of mentioning even the ACP provides only IPv6 connectivity, through it, IPv4 configuration or even non-IP configuration could be managed.

The document does not properly quota references in the text. The references defined are mostly not used.

The document separate sections for Informative/Normative References

The empty section 5 "Further considerations", should be removed.

Most of references are out of date. behringer-anima-reference-model > ietf-anima-reference-model, irtf-nmrg-an-gap-analysis > RFC 7576, irtf-nmrg-autonomic-network-definitions > RFC 7575.

In section 1.1, "the introduction of IPv6 or other mayor re-hauls in the infrastructure design." What is the mean for "other mayor"?

In section 1.3, "the Autonomic Networks Autonomic Control plane (ACP)" may be better to presented as "the Autonomic Control plane (ACP) in Autonomic Networks"

There is no full names for "NOC" in section 1.1, "PSTN" in section 1.3, AT" in section 2.1, "DNS" in section 2.1.1, "RoI" in section 2.1.4, MP-TCP in section 2.1.5, "KARP" in section 2.2, even the first appearances.

Last sentence of section 2.2 should be removed.

In section 3, first sentence, add "In this section,"

There are typos, needed to be fixed too:

Two "the the" in the end of section 2.1.2 and end of section 4;

A couple of "randomn" -> "random";

"networ" in section 2.1.5;

"jut" -> "just" at the end of section 2.1.6, I guess.

"The most simple" -> "the simplest" in section 2.17.

[Anima] Review of draft-ietf-anima-stable-connect… Sheng Jiang
Re: [Anima] Review of draft-ietf-anima-stable-con… Toerless Eckert
Re: [Anima] Review of draft-ietf-anima-stable-con… Brian E Carpenter
Re: [Anima] Review of draft-ietf-anima-stable-con… Sheng Jiang
Re: [Anima] Review of draft-ietf-anima-stable-con… Sheng Jiang
Re: [Anima] Review of draft-ietf-anima-stable-con… Brian E Carpenter
Re: [Anima] Review of draft-ietf-anima-stable-con… Toerless Eckert
Re: [Anima] Review of draft-ietf-anima-stable-con… Brian E Carpenter
Re: [Anima] Review of draft-ietf-anima-stable-con… Toerless Eckert
Re: [Anima] Review of draft-ietf-anima-stable-con… Brian E Carpenter