Re: [Anima] WGLC on draft-ietf-anima-stable-connectivity-03 - Respond by July 28, 2017
This is embarassing. For some reason I completely missed the announcement of draft-ietf-anima-stable-connectivity-05, until today. I have now looked at the -05 and -06 versions and I'm happy with the result. Regards Brian On 18/09/2017 17:38, Toerless Eckert wrote: > Thanks, Brian: > > The "OLD" paragraph you list was from -04. After your review i had already > changed this in -05 to > > NEW: > >To connect IPv4 only management plane devices/applications with the >ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is >necessary. The basic mechanisms for this are defined in SIIT >([RFC7915]). There are multiple solutions using this mechanisms. To >understand the possible solutions, we consider the requirements: > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-04.txt=https://tools.ietf.org/id/draft-ietf-anima-stable-connectivity-05.txt > > I also did spend a good amount of time because of your -04 review and prior > request by mohammed to detail in the following parapgraphs the possible > options in more detail. That text leverages the 'SIIT' term and > discusses the EAM solutions (RFC7757 is best). > > Given how this is an informational OPS document, > i think it is helpfull to elaborate on the understood details of > requirements and how known current solutions fit them. > > The fact that none of the > currently defined NAT solutions provides for the most simple possible > configuration (aka: minimum number of prefix EAM's to configure) is > also IMHO a perfectly valid outcome for an OPS document. > > It could mean that users will simply accept the need for longer mnaual > NAT config (long list of 1:1 mappings) or vendors implement a proprietary > EAM (explicit address mapping) CLI to make it simpler. Or users will > move faster to IPv6 on the NOC ;-) > > So, for the time being, i just commited -06 with the second fix. > > Let me know what you folks think about WG last call status of > the stable connectivity draft. > > Cheers > Toerless > > On Fri, Sep 15, 2017 at 11:05:51AM +1200, Brian E Carpenter wrote: >> To cut a long story short, here's a friendly suggestion. The goal is to avoid >> comments during IETF/IESG review that the NAT text is too vague: >> >> OLD >>To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 >>NAT can be used. This NAT setup could for example be done in Rt1r1 >>in above picture to also support IPv4 only NMS hots connected to >>NOClan. >> >> NEW >>To bridge an IPv4-only management plane with the ACP, IPv4 to IPv6 >>translation [RFC 6145] could be used. This could for example be done in >> Rt1r1 >>in the above picture to also support IPv4-only NMS hosts connected to >>NOClan. Details of the address mapping to be used would depend on >>the exact scenario and are not specified here. >> >> And yes, I like this: >> >>> i'd suggest to replace the "split-horizon" sentence with: >>> >>> Operators may therefore need to use a private DNS setup for the ACP ULA >>> addresses. This is the same setup that would be necessary for using >>> RFC1918 addresses in DNS. See for example [RFC1918] section 5, last >>> paragraph. In [RFC6950] section 4, these setups are discussed in more >>> detail. >> >> Regards >>Brian >> >> On 15/09/2017 09:18, Toerless Eckert wrote: >>> >>> Hi Brian, >>> >>> Sorry, for the delay. I have not sen further feedback on >>> stable-connectivity-05 >>> bside this mail of yours. See answers below, let me know if you want me to >>> rev >>> with the one possible textual improvement or if we think -05 is good enough. >>> >>> Cheers >>> Toerless >>> >>> On Fri, Aug 04, 2017 at 11:31:37AM +1200, Brian E Carpenter wrote: I'm just coming back on a couple of points. Generally -05 is almost there... > See the rewritten SIIT section. IMHO, there can be no simpler "network" > based > address translation. Where network based means that the translation > happens > in some device he network operator needs to provision. Like the ACP edge > device. > Or even an additional address translation device. > > So, the only IMHO easier option is when the OS of the NMS host would > internally > have IPv4/IPv6 translation so the device/VM looks to the outside like > full IPv6. Yes, that is exactly the effect of 464XLAT in the end-system (not in the router). >>> >>> I found rfc6877 a confusing read, but from what i figure, it's not exactly >>> what >>> i was thinking of: with rfc6877, you still need the server side to have a >>> reachable/mappable >>> IPv4 address, and that is something any device in the ACP does not have >>> naturally. >>> (aka: NOC server as client connecting to ACP device, ACP device is server). >>> >>> If i already need to set up some other form of NAT to give an ACP device an >>> outside IPv4 >>>
[Anima] anima - New Meeting Session Request for IETF 100
A new meeting session request has just been submitted by Sheng Jiang, a Chair of the anima working group. - Working Group Name: Autonomic Networking Integrated Model and Approach Area Name: Operations and Management Area Session Requester: Sheng Jiang Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: 6tisch nmrg 6lo 6man Second Priority: roll v6ops dhc homenet netconf Third Priority: cfrg saag intarea opsarea People who must be present: Toerless Eckert Sheng Jiang Terry Manderson Resources Requested: Special Requests: The WG prefer to have meeting on Tuesday/Wednesday if possible. - ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Review on draft-ietf-anima-autonomic-control-plane-09
Thanks Sheng, Sorry for the delay, i was working through my queue in order. See prior reply to Brians review for which i just posted acp-10. Your review is now top of queue for me and i will quickly triangulate your -09 comments with -10 and work in your comments for -11. Cheers Toeress On Fri, Sep 01, 2017 at 01:21:25AM +, Sheng Jiang wrote: > Somehow, I don't know how, I misspelled the name of the draft. Resend my > review comments with the right name in title and to the right authors alias. > > Sheng > > From: Anima [mailto:anima-boun...@ietf.org] On Behalf Of Sheng Jiang > Sent: Thursday, August 31, 2017 7:01 PM > To: anima@ietf.org > Cc: draft-ietf-anima-auotnomic-data-plane.auth...@ietf.org > Subject: [Anima] Review on draft-ietf-anima-auotnomic-data-plane-09 > > > Hi, authors of draft-ietf-anima-auotnomic-data-plane, > > > > 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. This is a petty long document. Therefore, my review may be a little > bit disordered. Overall, I think this document has been in a good sharp > although I cannot claim all my comments are minor. I believe they are not > difficult to address. > > > In introduction section, it is better to reference the "Autonomic Control > Plane" definition & description in Section 5 of RFC7575, rather than > "[RFC7575] calls it the 'Autonomic Control Plane'" . > > > > The ACP could actually be communication channel for both management and > control plane. So, the name seems be mis-leading. My understanding is that we > could not change the name in such late stage. But it worth to see more on > this in the introduction, even in the abstract. > > > > "This document describes options for a ... ACP". I am confused by the word > "option". What option does it actually mean? At least, it is not clear from > the context. > > > > "It therefore remains operational even in...". My understanding for "it" is > the network, but from the context, my first expression for "it" is ACP. > > > > Used short for the first appearance, ANI, VRF, IKE, TLS/dTLS, SDN, NOC, OAM, > NMS, CA and although GRASP, BRSKI, EST, ULA, are defined in Section 2, but > their first appearance is before their terminologies. > > > > Section 2, > > > > "ACP provides secure zero-touch network wide IPv6 connectivity between > devices supporting it." This is not accurate. These two devices must be in > the same autonomic network. Actually, we did not define an important concept > yet - the domain of autonomic network. We were always assume there is only > one domain within the connectivity range or the autonomic network would > naturally be separated by non-AN devices. But it would not always be the case > if AN technologies become widely deployed > > > > In Section 3, > > > > "certain AAA misconfigurations can lock an administrator out of a device", I > am not sure how ACP helps in this use case. It seems for me the only way is > to log in with another admin account, then change the misconfig. It is no > different through normal data plane. This can still be recovered remotely > without ACP. > > > > "The ACP provides reachability that is largely independent of the data > plane." Why "largely"? It implies that is still partially (maybe small > proportion) dependent on the data plane. > > > > "ACP MUST NOT be tied to a particular protocol." ACP does need support from > some specific protocol, GRASP, IPv6. I am sure you did not mean them. But the > description should be improved to be more precise. > > > > "The ACP MUST provide security". I am not sure the "MUST". In many scenarios, > for example, some layer has very strong layer 2 security mechanism, or > network with physics isolation/protection. The connectivity is the vital > functionality that ACP could provide, while security provided by ACP is > redundant or not necessary. > > > > "The default mode of operation of the ACP is hop-by-hop." I guess you mean > "basic" or "fundamental" rather than "default". The multiple connectivity is > made up by hop-by-hop connections. > > > > " ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 addresses. > ACP addresses are ULA."Please don't consider ULA as an equivalent to > RFC1918. We used to have relevant discussion in v6ops WG, and people had > strong consensus on ULAs != RFC1918. (see > https://tools.ietf.org/html/draft-ietf-v6ops-ula-usage-considerations-02#section-3.1) > > > > The content of section 3.3 reads like the essential benefit rather than a > specific use case, especially comparing to Section 3.1 and 3.2. More proper > place for this may be Section 9 (Benefits). > > > > "ACP loopback interface" and "ACP virtual interface" refer to different > things as defined in the Terminology section. However, in the main text, > sometimes they are mixed
Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt
On Wed, Aug 02, 2017 at 02:39:03PM +1200, Brian E Carpenter wrote: > Hi, > > Here are my comments on ACP version -08. First the ones I rank > as substantive isssues, then a few nits. Thanks so much Brian, lots of help to improve quality. Alas, i got derailed from finishing the fixes for your review because the reviews/last-call for stable connectivity which had me figure out a bunch of changes to ACP document, and i first put all of those in acp-09 (and then i had a bunch of business travel, so i thin i hadn't even sent out a note about -09 to the list). Changes -08 - 09: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-08.txt=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt Might be useful to check that diff out separately, key big blocks: - Made the V8 scheme more flexible (allow 16 bit addresses, eg: for the the stateless BRSKI proxy mechanisms you and MichaelR where discussing. - All RPL profile detail fixups from MichaelR's review - Expanded ACP connect section (taken over from stable-connectivity). - introduced manual addressing sub-scheme for more consistent autonomic-connect (also as outcome of stable-connectivity review) - Doc now claims to update RFC4291/RFC4193, section to summarize those updates - aka: that section is meant for later review by 6ops or 6man. Details of changes of course in changelog of the draft. The changes from your review below then got into acp -10 that i just posted: Changes -09 - 10: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-10.txt See below. Hopefully all answers to your points are satisfactory. Cheers Toerless > Issues: > --- > > > 2. Terminology > ... > > ULA "Unique Local Address". The IPv6 equivalent to RFC1918 IPv4 > > addresses. ACP addresses are ULA. > > No, they are *not* equivalent to RFC1918, because those are ambiguous > and ULAs are not. Please avoid controversy, just cite RFC4193. IMHO, a terminology section has to try to explain terms without making the reader refer to ever mor ereferences. Had a lot of customers who didn't know what ULA are, but who klicked when i mentioned 1918. And differences/benefits over 1918 become obvious later in doc anyhow (ambiguity). acp-10 text: A "Unique Local Address" (ULA) is an IPv6 address in the block fc00::/7, defined in . It is the approximate IPv6 counterpart of the IPv4 private address (). If you do not like that, please fix in Wikipedia wherer i stole this from: https://en.wikipedia.org/wiki/Unique_local_address ;-) > > 3.2. Secure Bootstrap over an Unconfigured Network > ... > > ...This does not require any configuration > > on intermediate nodes, because they can communicate through the ACP. > > s/they can communicate/they can communicate securely/ ACK > > 4. Requirements > ... > > ACP4: The ACP MUST be generic. Usable by all the functions and > >protocols of the AN infrastructure. It MUST NOT be tied to a > >particular protocol. > > I'm not sure what the last sentence is saying. Do you mean > "MUST NOT be tied to a particular transport protocol" or > "MUST NOT be tied to a particular security protocol"? > Or do you mean "MUST NOT restrict the choice of upper layer > protocol"? Or do you simply mean "MUST provide a generic > IPv6 service"? This goes back to very early discussions in ANIMA when we argued that a greenfield autonomic networking design would not need any protocol other than GRASP for any ASA to ASA communications. In which case there would not have been a good argument for ACPs concept of a virtual IPv6 network to transport any management traffic. acp-10: "NOT be tied to a particular application or transport protocol.". Please suggest better text if thats not sufficient. > Also, there's no requirement about performance or the > expected traffic density. Should we say something either > in the Requirements section or in the Notes in the > Overview section? I assume that performance is not critical > and ACP traffic density is expected to be low. My practical experience was that proliferation of implementation was easier when you did not have performance requirements but when you could implement also in just software forwarding path. This did then lead to text in stable connectivity arguing about using the ACP primarily for critical operations. acp-10 has a new performance section restate that position: There are no performance requirements against ACP implementations defined in this document because the performance requirements depend on the intended use case. It is expected that full autonomic devices with a wide range of ASA can require high forwarding plane performance in the ACP, for example for telemetry, but that determination
