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

From: Sheng Jiang <[email-masked]>
Date: Tue, 20 Jun 2017 08:00:33 +0000

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.

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 27 Jun 2017 06:21:24 +0200

Thanks a lot, Sheng! 

Integrated fixes for all comments (see inline discuss below). Pushed stable connectivity draft
into www.github.com/anima-wg/autonomic-control-plane together with ACP draft because i ended up
having to do a fix for the ACP draft as a result of your comments.

Diff between -02 and fixed up stable connectivity draft here: 

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt

If you are fine with the fixes let me know, and i'll push it to datatracker as -03.

If not ok. feel free to use email or now also add issue to the git.

Raw txt/git files of fixed stable connectivity text:

https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt
https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml

Diff for change done in ACP (explaining ACP connect better):

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.txt

Cheers
    Toerless

> 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 appli…

Yes, it is a mess. But it is documenting an actual deployment experience with an enterprise
customer. TAnd my understanding is tht it would be a quite common scenario for enterprises. There
was just recently a very nice RTG area WG chair tutorial that to me reconfirmed the ongoing
challenges with IPv6 only management planes.

I have added paragraphs to justify the need for this section and that its all undesirable workarounds
Please check. To me, this messy section is the price we have to pay so that the ACP
can simply be IPv6 only. Its a price i am happy to pay.

> 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. 

I have improved the text and categorization in this chapter to make it hopefully clearer to read and to be more precise in terminology.

> Point 2 is a precondition (it is actually conflicted with section 2.1.4.)

Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that is a challenge for which there is a workaround. Those workarounds are described in section 2.1.4. I've tried to improve all that text. I do not understand why point 2 would be a conflict with section 2.1.4 instead of rather pointing to 2.1.4.

> I don't understand point 4. What does "exposing the ACP natively" mean?

That is the term that was defined in ACP CP draft, section 6.1. Reading through that section, i improved it in the ACP section, and i updated the text about it in stable connectivity.

Oh, and this change had me change the term "NOC application device" to "NMS host" throughout the document because that is the term used in the ACP draft.

> 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? 

IMHO, considerations for names are one of the most crucial part of
operationalizing the ACP. The little text we have about the ACP is IMHO
a good compromise between overlooking the problem and writing a lot more
text.

The concept of using different addresses for a device for different actions
is not novel to ACP. Think of using a loopback to "reliably" talk to a router
vs. ping'ing specific interface addresses of a router to discover whether
an peer (reachable via that interface) is up/down. If you look at service 
providers name setups (often in DNS), then they will have different names
for those different addresses and use those different names in the different
tools. The text in this draft simply explains the same concept for
ACP vs. other addresses. 

DNS names can be setup by various locally built automation scripting or templates.
Same think for DNS names for ACP. Operators will likely point out that automating
the DNS name creation is more difficult because we do not use topology/semantic
ACP addresses, but in principle it's the same automation task.

> 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?

ALl the existing "actions" that you want to do for a device are just too stupid:
They do not include the logic of knowing which address is best for them to
use. That's why you use names for subsets of the possible addresses to allow
you to specify exatly those address(es) that will reach the device via the
network connection matching the intent of the action you're taking. 

> DNS registration & lookup by itself is a very complex and time-consumption procedure.

Depends on your automation. Its certainly an interesting aspect especially moving
from IPv4 to IPv6 where embedding logic into adresses becomes a whole different
ballgame.

> If we don't want to show the semantic of these addresses to any human, names are meaningless.

But you need new NOC tools where each action would need to know what type
of connection is best for it.

I have added one paragraph to 2.1.5 to outline this logic and justification for why
to describe DNS. Look for "Ideally, a NOC system would learn and keep track of all addresses of a device"

> 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.

Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP protocol common direct-neighbor 
discovery and capability negotiation (GRASP via ACP and/or data-plane) and stable and secure
connectivity for functions running distributed in network devices (GRASP via 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." Doe…

Ack. Changed text to: A workaround without additional software functionality 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. A (virtual) 
 software loopback between the ACP and data plane VRF would of course be the better solution.

The key notion why the "gross" physcial loopback may be appreciated is because it doesn't require software work. Or specification of the behavior of such a software loopback in the roting behavior in the ACP draft. I would love to have that software loopback, but i think we (ACP doc authors) felt that we wanted to keep the ACP spec lightweight enough to be implementable without all possible enhancements. But i hope its fine to mention the option here in this document as you suggested.

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

Yes, but i think if you look through various IETF documents you will see that it is quite common for security consideration sections to outline additional steps to secure the documents work goal especially when those steps are otherwise orthogonal to the documents spec (eg: leverage existing components).

Whats the process for informational documents. It will get SEC AD review, right ? Maybe hold that thought for that review ? Or else i can proactively ask, because right now i am a bit at a loss whats the right limit of what to put into sec considerations vs. what to extract into a separate chapter.

> 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.

The text unfortunately builds up in the order it is written, so it would be a lot of rewrite to make sure it would still read after such a reordering. Instead i have added the following as the first paragraph:

<t>This section describes stable connectibity for centralized OAM operations via ACP/ANI
starting by what we expect to be the most likely easiest short-term deployment option. It
then describes limitation/challenges of that approach and their solutions/workarounds to finish
with the preferred target option of autonomic NOC devices in <xref target="autonomic-devices" />.</t>

<t>This order was choosen because it helps to explain how simple one can start using the ACP, 
how difficult workarounds can become (and therefore what to avoid), and finally because one very 
promising long-term solution alternative is exactly like the most easy short-term solution only virtualized
and automated.</t>

The last sentence is that punchline: The likely easiest/best atonomic NOC device solution is one where you do everything you do in the short-term approach, just virtualized and integrated into the NOC device. WHich means you'd need to explain all that stuff anyhow...

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

Good point. Added the following sentence:

<t>Note that even though the ACP only uses IPv6, it can and should be used to providestable connectivity for management of any network: IPv4 only, dual-stack or IPv6 only.</t>

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

Ack. Removed unnecessary references, introduced terms/references in the beginning of the document. All references now used at least once ;-)

> The document separate sections for Informative/Normative References

Hmm. It DOES NOT distinguish between normative and informational documents because i thought that an informational document like this could not have normative references. If it can and should have them let me know, then i'll make Bootstrap/Grasp/ACP normative and reference/definitions informational.

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

Done.

> 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.

Fixed.

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

added: Examples include change of IGP protocols or areas, PD (Provider
Dependent) to PI (Provider Independent) addressing, systematic topology changes.

> 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"

Done

> 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…

Done, added RFC references for those TLAs that have them as well.

> Last sentence of section 2.2 should be removed.

Done.

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

Done.

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

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

Done
> "networ" in section 2.1.5;

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

Done.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jun 2017 14:44:14 +1200

I had a look at both sets of changes and they seem good to me.

I find myself wondering, after seeing the slightly confused text
about GRASP objectives in the latest BRSKI, and noting the absence
of such objectives in the ACP and stable-connectivity drafts, whether
we should accept that we need a specialised draft for all the
GRASP objectives needed by the ANI.

Strangely enough, we have such a draft already:
https://tools.ietf.org/html/draft-carpenter-anima-ani-objectives-01
My idea was for this to be a temporary draft, with its contents
being moved into BSRKI, ACP and stable-connectivity. But would it
be more practical to keep it as a separate draft? It makes the other
three drafts a bit more self-contained, and allows for a consistent
definition of the infrastructure objectives.

What to do people think?

(Disregard the current details in draft-carpenter-anima-ani-objectives,
which has not been updated recently.)

Regards
    Brian

On 27/06/2017 16:21, Toerless Eckert wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 29 Jun 2017 06:17:41 +0000

Hi, Brian,

With my WG chair hat on, the situation regarding to these ANI objectives is strange indeed. Could you please resubmit your anima-ani-objectives before the deadline next Monday? Then, the chairs could discuss the situation with our responsible AD. It looks that the easiest way is to adopt this draft and quickly send it to IESG along with ACP and BRSKI.

Cheers,

Sheng

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Thursday, June 29, 2017 10:44 AM
> To: [email-masked]
> Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02
> 
> I find myself wondering, after seeing the slightly confused text about GRASP
> objectives in the latest BRSKI, and noting the absence of such objectives in the
> ACP and stable-connectivity drafts, whether we should accept that we need a
> specialised draft for all the GRASP objectives needed by the ANI.
> 
> My idea was for this to be a temporary draft, with its contents being moved
> into BSRKI, ACP and stable-connectivity. But would it be more practical to keep
> it as a separate draft? It makes the other three drafts a bit more self-contained,
> and allows for a consistent definition of the infrastructure objectives.
> 
> What to do people think?
> 
> > Integrated fixes for all comments (see inline discuss below). Pushed
> > stable connectivity draft into
> > www.github.com/anima-wg/autonomic-control-plane together with ACP
> draft because i ended up having to do a fix for the ACP draft as a result of your
> comments.
> >
> > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.gith
> > ubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-a
> > nima-stable-connectivity/draft-ietf-anima-stable-connectivity-02.txt&u
> > rl2=https://raw.githubusercontent.com/anima-wg/autonomic-control-plane
> > /master/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-c
> > onnectivity.txt
> >
> > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/mas
> > ter/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-conne
> > ctivity.txt
> > https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/mas
> > ter/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-conne
> > ctivity.xml
> >
> > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.gith
> > ubusercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-a
> > nima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane-
> > 06.txt&url2=https://raw.githubusercontent.com/anima-wg/autonomic-contr
> > ol-plane/master/draft-ietf-anima-autonomic-control-plane/draft-ietf-an
> > ima-autonomic-control-plane.txt
> >
> > Cheers
> >     Toerless
> >
> >> 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.
> >
> > Yes, it is a mess. But it is documenting an actual deployment
> > experience with an enterprise customer. TAnd my understanding is tht
> > it would be a quite common scenario for enterprises. There was just
> > recently a very nice RTG area WG chair tutorial that to me reconfirmed the
> ongoing challenges with IPv6 only management planes.
> >
> > I have added paragraphs to justify the need for this section and that
> > its all undesirable workarounds Please check. To me, this messy
> > section is the price we have to pay so that the ACP can simply be IPv6 only. Its
> a price i am happy to pay.
> >
> >> 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.
> >
> > I have improved the text and categorization in this chapter to make it
> hopefully clearer to read and to be more precise in terminology.
> >
> > Yes, IPv6 is a precondition. If a deployment can not meet this precondition,
> that is a challenge for which there is a workaround. Those workarounds are
> described in section 2.1.4. I've tried to improve all that text. I do not
> understand why point 2 would be a conflict with section 2.1.4 instead of rather
> pointing to 2.1.4.
> >
> > That is the term that was defined in ACP CP draft, section 6.1. Reading
> through that section, i improved it in the ACP section, and i updated the text
> about it in stable connectivity.
> >
> > Oh, and this change had me change the term "NOC application device" to
> "NMS host" throughout the document because that is the term used in the ACP
> draft.
> >
> > operationalizing the ACP. The little text we have about the ACP is
> > IMHO a good compromise between overlooking the problem and writing a
> > lot more text.
> >
> > The concept of using different addresses for a device for different
> > actions is not novel to ACP. Think of using a loopback to "reliably"
> > talk to a router vs. ping'ing specific interface addresses of a router
> > to discover whether an peer (reachable via that interface) is up/down.
> > If you look at service providers name setups (often in DNS), then they
> > will have different names for those different addresses and use those
> > different names in the different tools. The text in this draft simply
> > explains the same concept for ACP vs. other addresses.
> >
> > Same think for DNS names for ACP. Operators will likely point out that
> > automating the DNS name creation is more difficult because we do not
> > use topology/semantic ACP addresses, but in principle it's the same
> automation task.
> >
> >> 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?
> >
> > They do not include the logic of knowing which address is best for
> > them to use. That's why you use names for subsets of the possible
> > addresses to allow you to specify exatly those address(es) that will
> > reach the device via the network connection matching the intent of the action
> you're taking.
> >
> > Depends on your automation. Its certainly an interesting aspect
> > especially moving from IPv4 to IPv6 where embedding logic into
> > adresses becomes a whole different ballgame.
> >
> > But you need new NOC tools where each action would need to know what
> > type of connection is best for it.
> >
> > I have added one paragraph to 2.1.5 to outline this logic and
> > justification for why to describe DNS. Look for "Ideally, a NOC system would
> learn and keep track of all addresses of a device"
> >
> >
> >> 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.
> >
> > Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the
> > GRASP protocol common direct-neighbor discovery and capability
> > negotiation (GRASP via ACP and/or data-plane) and stable and secure
> >> 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.
> >
> > Ack. Changed text to: A workaround without additional software
> > functionality 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. A (virtual)  software loopback between the ACP and data plane VRF
> would of course be the better solution.
> >
> > The key notion why the "gross" physcial loopback may be appreciated is
> because it doesn't require software work. Or specification of the behavior of
> such a software loopback in the roting behavior in the ACP draft. I would love to
> have that software loopback, but i think we (ACP doc authors) felt that we
> wanted to keep the ACP spec lightweight enough to be implementable without
> all possible enhancements. But i hope its fine to mention the option here in this
> document as you suggested.
> >
> >> Section 3, "Security considerations" is more like a deployment
> >> considerations. Both ULA-C and reverse DNS are additional deployment
> >
> > Yes, but i think if you look through various IETF documents you will see that it
> is quite common for security consideration sections to outline additional steps
> to secure the documents work goal especially when those steps are otherwise
> orthogonal to the documents spec (eg: leverage existing components).
> >
> > Whats the process for informational documents. It will get SEC AD review,
> right ? Maybe hold that thought for that review ? Or else i can proactively ask,
> because right now i am a bit at a loss whats the right limit of what to put into
> sec considerations vs. what to extract into a separate chapter.
> >
> >> 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.
> >
> > The text unfortunately builds up in the order it is written, so it would be a lot
> of rewrite to make sure it would still read after such a reordering. Instead i
> have added the following as the first paragraph:
> >
> > <t>This section describes stable connectibity for centralized OAM
> > operations via ACP/ANI starting by what we expect to be the most
> > likely easiest short-term deployment option. It then describes
> > limitation/challenges of that approach and their solutions/workarounds
> > to finish with the preferred target option of autonomic NOC devices in
> > <xref target="autonomic-devices" />.</t>
> >
> > <t>This order was choosen because it helps to explain how simple one
> > can start using the ACP, how difficult workarounds can become (and
> > therefore what to avoid), and finally because one very promising
> > long-term solution alternative is exactly like the most easy
> > short-term solution only virtualized and automated.</t>
> >
> > The last sentence is that punchline: The likely easiest/best atonomic NOC
> device solution is one where you do everything you do in the short-term
> approach, just virtualized and integrated into the NOC device. WHich means
> you'd need to explain all that stuff anyhow...
> >
> >> It is worth of mentioning even the ACP provides only IPv6 connectivity,
> through it, IPv4 configuration or even non-IP configuration could be managed.
> >
> > <t>Note that even though the ACP only uses IPv6, it can and should be
> > used to providestable connectivity for management of any network: IPv4
> > only, dual-stack or IPv6 only.</t>
> >
> > Ack. Removed unnecessary references, introduced terms/references in
> > the beginning of the document. All references now used at least once
> > ;-)
> >
> > Hmm. It DOES NOT distinguish between normative and informational
> documents because i thought that an informational document like this could
> not have normative references. If it can and should have them let me know,
> then i'll make Bootstrap/Grasp/ACP normative and reference/definitions
> informational.
> >
> >> 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.
> >
> > Fixed.
> >
> >> 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"
> >
> > Done
> >
> >> 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.
> >

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 29 Jun 2017 07:39:00 +0000

Hi, Toerless,

Thanks for addressing my review comments. The new version looks good to be apart from that I am still have concern regarding to use names to distinguish the path selection policies, particularly the necessity of this solution. However, with the newly added text and the possibility that there may be solutions for autonomic naming, I can hold my opinion on this as a personal observation. Please go ahead to submit the latest version. We could have the WGLC based on the new version.

Thanks and regards,

Sheng

> From: Toerless Eckert [mailto:[email-masked]]
> Sent: Tuesday, June 27, 2017 12:21 PM
> To: Sheng Jiang
> Cc: Anima WG; [email-masked]
> Integrated fixes for all comments (see inline discuss below). Pushed stable
> connectivity draft into www.github.com/anima-wg/autonomic-control-plane
> together with ACP draft because i ended up having to do a fix for the ACP draft
> as a result of your comments.
> 
> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubuserconte
> nt.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-stable-con
> nectivity/draft-ietf-anima-stable-connectivity-02.txt&url2=https://raw.githubus
> ercontent.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-st
> able-connectivity/draft-ietf-anima-stable-connectivity.txt
> 
> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/maste
> r/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.txt
> https://raw.githubusercontent.com/anima-wg/autonomic-control-plane/maste
> r/draft-ietf-anima-stable-connectivity/draft-ietf-anima-stable-connectivity.xml
> 
> http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://raw.githubuserconte
> nt.com/anima-wg/autonomic-control-plane/master/draft-ietf-anima-autonomi
> c-control-plane/draft-ietf-anima-autonomic-control-plane-06.txt&url2=https://r
> aw.githubusercontent.com/anima-wg/autonomic-control-plane/master/draft-i
> etf-anima-autonomic-control-plane/draft-ietf-anima-autonomic-control-plane.t
> xt
> 
> Cheers
>     Toerless
> 
> Yes, it is a mess. But it is documenting an actual deployment experience with
> an enterprise customer. TAnd my understanding is tht it would be a quite
> common scenario for enterprises. There was just recently a very nice RTG area
> WG chair tutorial that to me reconfirmed the ongoing challenges with IPv6 only
> management planes.
> 
> I have added paragraphs to justify the need for this section and that its all
> undesirable workarounds Please check. To me, this messy section is the price
> we have to pay so that the ACP can simply be IPv6 only. Its a price i am happy to
> pay.
> 
> I have improved the text and categorization in this chapter to make it hopefully
> clearer to read and to be more precise in terminology.
> 
> Yes, IPv6 is a precondition. If a deployment can not meet this precondition, that
> is a challenge for which there is a workaround. Those workarounds are
> That is the term that was defined in ACP CP draft, section 6.1. Reading through
> that section, i improved it in the ACP section, and i updated the text about it in
> stable connectivity.
> 
> operationalizing the ACP. The little text we have about the ACP is IMHO a good
> compromise between overlooking the problem and writing a lot more text.
> 
> The concept of using different addresses for a device for different actions is not
> novel to ACP. Think of using a loopback to "reliably" talk to a router vs. ping'ing
> specific interface addresses of a router to discover whether an peer (reachable
> via that interface) is up/down. If you look at service providers name setups
> (often in DNS), then they will have different names for those different
> addresses and use those different names in the different tools. The text in this
> draft simply explains the same concept for ACP vs. other addresses.
> 
> automating the DNS name creation is more difficult because we do not use
> topology/semantic ACP addresses, but in principle it's the same automation
> task.
> 
> > 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?
> 
> They do not include the logic of knowing which address is best for them to use.
> That's why you use names for subsets of the possible addresses to allow you to
> specify exatly those address(es) that will reach the device via the network
> connection matching the intent of the action you're taking.
> 
> Depends on your automation. Its certainly an interesting aspect especially
> moving from IPv4 to IPv6 where embedding logic into adresses becomes a
> whole different ballgame.
> 
> I have added one paragraph to 2.1.5 to outline this logic and justification for
> why to describe DNS. Look for "Ideally, a NOC system would learn and keep
> track of all addresses of a device"
> 
> 
> Ack. Changed to: The ANI (ACP, Bootstrap, GRASP) can provide via the GRASP
> protocol common direct-neighbor discovery and capability negotiation (GRASP
> via ACP and/or data-plane) and stable and secure connectivity for functions
> running distributed in network devices (GRASP via ACP).
> 
> Ack. Changed text to: A workaround without additional software functionality
> 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. A (virtual)  software
> loopback between the ACP and data plane VRF would of course be the better
> solution.
> 
> Yes, but i think if you look through various IETF documents you will see that it is
> quite common for security consideration sections to outline additional steps to
> secure the documents work goal especially when those steps are otherwise
> > 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.
> 
> The text unfortunately builds up in the order it is written, so it would be a lot of
> rewrite to make sure it would still read after such a reordering. Instead i have
> added the following as the first paragraph:
> 
> <t>This section describes stable connectibity for centralized OAM operations
> via ACP/ANI starting by what we expect to be the most likely easiest
> short-term deployment option. It then describes limitation/challenges of that
> approach and their solutions/workarounds to finish with the preferred target
> option of autonomic NOC devices in <xref target="autonomic-devices" />.</t>
> 
> <t>This order was choosen because it helps to explain how simple one can start
> using the ACP, how difficult workarounds can become (and therefore what to
> avoid), and finally because one very promising long-term solution alternative is
> exactly like the most easy short-term solution only virtualized and
> automated.</t>
> 
> <t>Note that even though the ACP only uses IPv6, it can and should be used to
> providestable connectivity for management of any network: IPv4 only,
> dual-stack or IPv6 only.</t>
> 
> Ack. Removed unnecessary references, introduced terms/references in the
> beginning of the document. All references now used at least once ;-)
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Jun 2017 14:45:10 +1200

OK. It may not be final but I will submit that shortly.

Regards
   Brian Carpenter

On 29/06/2017 18:17, Sheng Jiang wrote:
> .