On 06/07/2017 11:13, Toerless Eckert wrote: > On Tue, Jul 04, 2017 at 12:23:13PM +1200, Brian E Carpenter wrote: >> Toerless, >> >>> I actually expanded on the text to represent the whole M_FLOOD message >>> format >>> because i always found it highly irritating having to switch between the >>> taget draft (ACP etc.) and the GRASP draft to really see whats in the whole >>> message. >> >> I have mixed feelings about that, because of the obvious scope >> for error, and the general risk of duplicating material between >> documents. In any case, we need to check it in great detail. >> (The best check would be to make and debug a demo implementation, >> dump the actual packets, and check that they correspond.) > > See other mail thread about BRSKI. > >> This is actually why we also need consensus on the GRASP API. >> It's much easier to verify a use case against the API than to >> work out message details. > > Moving from protocol descriptions to API ? A small step for Brian > but a giant leap of faith for IETF ?
Indeed. It sometimes seems that the IETF wants to pretend that there are no operating systems or programming languages. > Aka: > 1. right now i didn't want BRSKI/ACP to refer to an API thats further out > from RFC than the protocol spec. I agree, I don't want that to be normative, it's just a very useful tool. > 2. I am not aware of BCP in the IETF to refer to APIs given how little > APIs the IETF has standardized, so i am a bit reluctant at this stage > in ANIMA to explore even more long term good things as scouts. If you > have pointers to other docs referring to other APIs defined by IETF > in a normative fashion, that would help aleviate that anxiety quite a bit. > > 3. Given how GRASP itself is not widely deployed, i do like the additional > cross-checking/validation we get by looking at the whole packet right now. > We already figured out the need to carry ports in GRASP IMHO because of > exactly this view - instead of just trusing APIs. Yes. But the quickest way I have to generate packets is to run my code with grasp.test_mode = True ;-) Brian > > Aka: I'd be happy to ask authors (including myself) to refer to only GRASP > APIs for any drafts that would have the same (or slower_ timeline as > GRASP API. And to put GRASP API on fast-track (as much as we can). > > Cheers > Toerless > >> Regards >> Brian >> >> On 04/07/2017 11:59, Toerless Eckert wrote: >>> On Thu, Jun 29, 2017 at 02:44:14PM +1200, Brian E Carpenter wrote: >>>> I had a look at both sets of changes and they seem good to me. >>> >>> Thanks. The reviewed document was just pushed as -03 to datatracker, see >>> other emails. >>> >>>> 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. >>> >>> I am still working through the last two IETFs agreement that we need to >>> update >>> BRSKI and ACP drafts to allow dissolving of the ani-objectives (and use it >>> as >>> the starting point). >>> >>> The BRSKI changes for this are still in a github branch we have not gotten >>> through >>> to merge into the main branch due to prioritizing voucher work first (get >>> thast >>> through last call). >>> >>> The ACP draft changes to introduce the ani-objectives proposed GRASP >>> objective >>> details are included in the -07 ACP draft that i also just submitted. >>> >>> I actually expanded on the text to represent the whole M_FLOOD message >>> format >>> because i always found it highly irritating having to switch between the >>> taget draft (ACP etc.) and the GRASP draft to really see whats in the whole >>> message. >>> >>> Wrt to GRASP in stable connectivity, i think we should try to also finish >>> up this >>> draft, the ideas how else NOC and ANI can be integrated is for both time and >>> other reasons better done in a followup draft: Another such reason could be >>> to introduce those GRASP objectives/functions as a standards strack document >>> (stable connectivity is just informational target). >>> >>> Cheers >>> Toerless >>> >>>> 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 >>> > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
