OK. It may not be final but I will submit that shortly. Regards Brian Carpenter
On 29/06/2017 18:17, Sheng Jiang wrote: > 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 protected]] On Behalf Of Brian E Carpenter >> Sent: Thursday, June 29, 2017 10:44 AM >> To: [email protected] >> Subject: Re: [Anima] Review of draft-ietf-anima-stable-connectivity-02 >> >> 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.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 >>> >>> 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/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 >>> >>> Diff for change done in ACP (explaining ACP connect better): >>> >>> 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 >>> >>> 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 > . > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
