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: > 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 > > On Tue, Jun 20, 2017 at 08:00:33AM +0000, Sheng Jiang wrote: >> 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. > > 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." 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. > > 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 first appearances. > > 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. > >> There are typos, needed to be fixed too: >> >> 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 >> >> "jut" -> "just" at the end of section 2.1.6, I guess. >> >> "The most simple" -> "the simplest" in section 2.17. > > Done. > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
