Hi, Here are my comments on this draft. In general it seems to be ready, but there are some issues that IMHO need fixing. Here they are, followed by a few nits that I noticed.
Technical issues: ----------------- > 2.1.3. Simultaneous ACP and data plane connectivity ...> If the data-plane of the network is also supporting IPv6, then the > NOC devices that need access to the ACP should have a dual-homing > IPv6 setup. One option is to make the NOC devices multi-homed with > one logical or physical IPv6 interface connecting to the data-plane, > and another into the ACP. I don't understand the need to call this "dual-homing". That generally implies a physical topology with multiple links and/or routers. I think all you mean is that the nodes happen to have at least two addresses in different IPv6 prefixes (one for the data plane and one for the ACP). Having multiple addresses is a standard feature of IPv6. It might be done with multiple (virtual or real) interfaces, but it doesn't need to be. So I suggest: If the data-plane of the network also supports IPv6, then the NOC devices that need access to the ACP should have both data-plane and ACP IPv6 addresses. One option is to set up the NOC devices with one logical or physical IPv6 interface connecting to the data-plane, and another into the ACP. > The LAN that provides access to the ACP > should then be given an IPv6 prefix that shares a common prefix with > the IPv6 ULA... 1) It is surely a virtual interface, not a LAN. 2) I think it is better to say "should then be given an IPv6 prefix that lies within the ULA prefix..." (In fact, it doesn't matter that it's a ULA - what matters is that it's the prefix that covers the whole ACP. That really goes for the whole document; a ULA prefix is just another prefix, after all. It might be clearer to just say "ACP prefix" everywhere.) > ... so that the standard IPv6 > interface selection rules on the NOC host Cite [RFC6724] for complete clarity. > If this can not be achieved > automatically, then it needs to be done via simple IPv6 static routes > in the NOC host. But it can. That's why RFC6724 exists. Do we really need to say this? ... > Providing two virtual (eg: dot1q subnet) connections into NOC hosts > may be seen as undesired complexity. Either you have to explain 'dot1q' and give a reference, or delete it. I'd delete it. ... > In that case the routing policy > to provide access to both ACP and data-plane via IPv6 needs to happen > in the NOC network itself: The NMS host gets a single attachment > interface but still with the same two IPv6 addresses as in before - > one for use towards the ACP, one towards the data-plane. The first- > hop router connecting to the NMS host would then have separate > interfaces: one towards the data-plane, one towards the ACP. Routing > of traffic from NMS hosts would then have to be based on the source > IPv6 address of the host: Traffic from the address designated for ACP > use would get routed towards the ACP, traffic from the designated > data-plane address towards the data-plane. That seems like an explanation of very basic routing - does it need to be said? > In the most simple case, we get the following topology:... This part isn't very clear to follow. The ASCII art of Fig. 1 and Fig. 2 is a bit scrappy, and the explanation is a bit short. It would be better to start with an explanation of the terms like 'NOClan' and 'Rtr1'. And you suddenly start discssing VRFs without any definition. > 2.1.4. IPv4 only NMS hosts ... > The downside of this architectural decision is the potential need for > short-term workarounds when the operational practices in a network > that can not meet these target expectations. This section motivates > when and why these workarounds may be necessary and describes them. > All the workarounds described in this section are HIGHLY UNDESIRABLE. > The only long term solution is to enable IPv6 on NMS hosts. I full agree with the message but I think the wording has the wrong tone. The goal should be to welcome NOCs to the new world of IPv6, not to tell them they are dinosaurs. Something like: The implication of this architectural decision is the potential need for short-term workarounds when the operational practices in a network do not yet meet these target expectations. This section explains when and why these workarounds may be operationally necessary and describes them. However, the long term goal is to upgrade all NMS hosts to native IPv6, so the workarounds described in this section should not be considered permanent. ... > 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. I think this (and the following paragraph) is underspecified. It isn't clear to me whether this would be described as a NAT64 or a NAT46 scenario (which side is the client and which side is the server, in other words). There's a lot more to specify to make this work - maybe the details are out of scope, which should be stated if so. Also, it would be better to say 'IP/ICMP translation' not 'NAT' and cite RFC7915. Make that clearly separate from the issue of how addresses are mapped. (Incidentally, recall that (a) IPv4 addresses are only 32 bits and (b) we own the ACP address plan. So algorithmic mapping of IPv4 addresses into a special /96 in the ACP address plan is possible. Of course that would be an insecure zone in ACP terms.) > 2.1.5. Path selection policies A lot of this section comes across almost as hand-waving. I did wonder whether it would have been enough just to state the problem. ... > MP-TCP (Multipath TCP -see [RFC6824]) is a very attractive candidate > to automate the use of both data-plane and ACP... I'm not sure... you seem to be asking for new intelligence in MPTCP's choice of candidate addresses, not just a policy but a whole mechanism in support of that policy. And will you really benefit from MPTCP's main point, which is automatic load management between alternative paths. Wouldn't SCTP be a better match? > 2.1.8. Long term direction of the solution ...> 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the > network to enable use of ACP is long term undesirable. Having > IPv4 only applications automatically leverage IPv6 connectivity > via host-stack options is likely non-feasible (NOTE: this has > still to be vetted more). That NOTE needs to be cleared up. Something like 464XLAT (RFC6877) might be a good compromise. > 3. Security Considerations ... > ULA addressing as proposed in this document is preferred over... Was this pasted from the ACP draft? Surely that is where ULA is proposed. > Randomn ULA addressing provides more than sufficient protection > against address collision even though there is no central assignment > authority. I don't like that phrase: it isn't the *address* that's random, it's the /48 prefix. Also, somebody is always ready to complain about the collision risk. Suggest: The random nature of a ULA prefix provides strong protection against address collision even though there is no central assignment authority. > If packets with unexpected ULA addresses are seen and one expects > them to be from another networks ACP from which they leaked, then > some form of ULA prefix registrastion (not allocation) can be > beneficial. Some voluntary registries exist, for example > https://www.sixxs.net/tools/grh/ula/, although none of them is > preferrable because of being operated by some recognized authority. > If an operator would want to make its ULA prefix known, it might need > to register it with multiple existing registries. > > ULA Centrally assigned ULA addresses (ULA-C) was an attempt to > introduce centralized registration of randomly assigned addresses and > potentially even carve out a different ULA prefix for such addresses. > This proposal is currently not proceeding, and it is questionable > whether the stable connectivity use case provides sufficient > motivation to revive this effort. I think all that is a red herring. I suggest replacing it by a simple statement: If packets with unexpected ULA addresses are seen they should be discarded. (Even that is not really needed, since all border routers should discard such packets anyway.) > Using current registration options implies that there will not be > reverse DNS mapping for ACP addresses. Really? I assume we're talking about two-faced DNS, and afaik nothing stops an operator providing reverse mapping in the private DNS. That seems to be implied by the following paragraphs, so the text seems inconsistent anyway. > 4. No IPv4 for ACP This section seems out of place stuck between Security Considerations and IANA Considerations. Maybe it should be an Appendix, referenced in section 2.1.4. "IPv4 only NMS hosts". Nits/English: ------------- (There are probably other nits as well as these, which the RFC Editor will fix...) > Abstract ... > ... Provisioning during device/network bring > up tends to be far less easy to automate than service provisioning > later on, changes in core network functions impacting reachability > can not be automated either because of ongoing connectivity > requirements for the OAM equipment itself, and widely used OAM > protocols are not secure enough to be carried across the network > without security concerns. Suggested: Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. > This document describes how to integrate OAM processes with the > autonomic control plane (ACP) in Autonomic Networks (AN). to provide > stable and secure connectivity for those OAM processes. Suggested: This document describes how to integrate OAM processes with the autonomic control plane (ACP) in Autonomic Networks (AN) in order to provide stable and secure connectivity for those OAM processes. > 1.2. Data Communication Networks (DCNs) > > In the late 1990'th and early 2000, IP networks became the method of > choice to build separate OAM networks for the communications > infrastructure in service providers. This concept was standardized > in G.7712/Y.1703 This needs a complete informational reference. Also, according to https://www.itu.int/rec/T-REC-G.7712-200303-S/en it is a superseded reference, so maybe there is a better one? > 2.1.1. Simple connectivity for non-autonomic NMS hosts ... > For example, if DNS in the network was set up with > names for network devices as devicename.noc.example.com, then the ACP > address of that device could be mapped to devicename- > acp.noc.exmaple.com. ... acp.noc.example.com > 2.1.2. Challenges and limitation of simple connectivity ...> Note that these challenges and limitations exist because the ACP is > primarily designed to support distributed ASA ... Define "ASA" when first used. Regards, Brian _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
