To Softwires: I've included comments below, but for the benefit of the authors and working group, the two actions items I see from this are:
1. map-dhcp should be a MUST, not a SHOULD. 2. the working group should decide whether DHCPv4-over-DHCPv6 is MTI in the B4, and whether pcp-port-set is MTI in the B4, because if they are not, operators can't deploy them. To David Harrington: First, thanks for the thoughtful comments. I don't agree with everything you've said here, but you've definitely pointed out two significant problems that need to be dealt with. On Oct 21, 2014, at 9:45 AM, David Harrington <ietf...@comcast.net> wrote: > 1) I think there is a problem with having a MUST condition in the spec > depending on a companion document that will be published later. > > "The consequence of this architecture is that the information > maintained by the provisioning mechanism and the one maintained by > the lwAFTR MUST be synchronized (See figure 2). The details of this > synchronization depend on the exact provisioning mechanism and will > be discussed in a companion document. > > “ I think the authors already have made changes to this text based on David Black's review. > There are additional synchronization requirements specified in 6.1 - Binding > Table Maintenance. > > If the synchronization is that important that it deserves multiple MUSTs in > the spec, and the details depend on the provisioning mechanism, then it > sounds reasonable to consider the companion document to be required. > > It seems to me that, if synchronization is critical and we want > interoperability, there should be a mandatory-to-implement synchronization > spec defined before this spec is ready for publication. I would certainly not object if you proposed such a mechanism. Short of that, with all due respect, this is a pretty absurd objection. This would be like saying that since IP requires a mechanism for keeping routing tables up to date, RFC 791 should not have been published until RFC 1058 was done. > 2) I have a related concern: I don’t see discussion of how the implementation > should be operated and monitored, remotely. > Since this implementation is expected to reside in customer premises > equipment, having a remote monitoring and management capability seems > important. > And since this is being developed in the IETF, where interoperability is > important, it would seem an IETF standardized monitoring and management > solution would be desirable. Do we require a MIB for existing routers with non-port-shared NATs? If not, then I think this is an example of something that would certainly be good to do, but is not a prerequisite. There is work being done on a YANG model, but I don't think anybody's doing a MIB, so again, if this is a matter that is of interest to you, I would encourage you to take on this work. > A MIB module would provide monitoring capability, but none is defined or > suggested here. This is an extension to DS-LIte, and there is a DS-Lite MIB. > There is no discussion of whetherr that DS-Lite MIB module would be > applicable to lw4o6, or whether that MIB module would require changes to be > applicable to lw4o6 monitoring. The DS-Lite MIB doesn't manage the B4; only the AFTR. > A YANG solution could address both the monitoring and provisioning > requirements. As I mentioned, work is progressing on a YANG data model. I think this is a good observation, but shouldn't block the base spec. > But an operator cannot use it if it isn’t implemented, so there should be a > mandatory-to-implement mechanism to allow for monitoring in an interoperable > manner. (Operators can still choose to deploy different non-interoperable > solutions fi they choose, but without a mandatory-to-implement baseline for > interoperability, they cannot choose one known to be interoperable across all > standard-compliant implementations.) Do you mean that the operator can't operate an AFTR without a management specification, or that an operator can't operate a network with B4s that can't be managed? > 3) I have a concern with section 3.2.1, which is entitled “Changes to RFC2473 > and RFC6333 Fragmentation Behavior”. > The text says to follow the best current practices of a number of other > documents, but it never actually discusses what the changes to fragmentation > behavior would be. > RFC2473 and RFC6333 are both standards-track. Is this document proposing to > update those standards? It doesn’t say so in the I-D heading. > The RFCs containing best current practices cover a lot of ground. This feels > like hand-waving as a result. We don't know how to solve this problem. It's being discussed in the working group. The text was added at my request based on similar text in the MAP specification; I think the authors will either take the text out, or else modify it to make it clear that this is a problem to look out for, not something we know how to fix. > Are all of the best practices needed for this spec to work properly, or just > some of them? > Are some of these BCPs REQUIRED for this spec to work properly? > This section is about changes in fragmentation behavior. Are there specific > sections of the BCPs that are important to apply, for the changes in > fragmentation behavior? > The text specifies following the best current practices as a SHOULD; it > doesn’t discuss why this is only a SHOULD and not a MUST. > Under what circumstances would it be acceptable to NOT follow these best > practices? > What would happen to the network or the users of the network if an lwB4 > implementation does NOT follow those guidelines? > (This would be easier to discuss if the spec referred to specific best > practices relevant to fragmentation.) The conclusion of the working group thus far (which may change) is that (a) this probably isn't a very big problem, (b) we don't know how to solve it in a way that doesn't possibly make things worse, and therefore (c) we mention it so that people can be aware of it, but do not make recommendations because we have none to make. It is worth noting that this same issue exists for DS-Lite, and we have not had reports from the field that there is evidence of actual operational problems. > 4) Section 7 suggests a number of additional provisioning mechanisms: > In addition to the DHCPv6 based mechanism described in section 5.1, > several other IPv4 provisioning protocols have been suggested. These > protocols MAY be implemented. These alternatives include: > > o DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4 > messages over an IPv6 only service providers network. This > enables leasing of IPv4 addresses and makes DHCPv4 options > available to the DHCPv4 over DHCPv6 client. > > > Cui, et al. Expires April 17, 2015 [Page 12] > Internet-Draft Lightweight 4over6 October 2014 > > > o PCP[RFC6887]: an lwB4 MAY use [I-D.ietf-pcp-port-set] to retrieve > a restricted IPv4 address and a set of ports. > > In a Lightweight 4over6 domain, the binding information MUST be > aligned between the lwB4s, the lwAFTRs and the provisioning server. > > > How do we achieve interoperability if each implementation can choose > different provisioning mechanisms? > Especially, given that synchronization is critical, and is dependent on the > provisioning mechanism used? Hm, I think the authors and wg should think about this. Right now the expectation is that the map-dhcp option is mandatory, and these mechanisms are not, but if they aren't MTI in the HG, the operator can't depend on them working. > 5) section 7 suggests provisioning mechanisms in addition to DHCPv6, so I > checked to see if DHCPv6 was required (i.e. mandatory to implement). > That also appears to merely be an option. > So there apparently is no mandatory-to-implement way to address these MUSTs: > " In lw4o6, a number of lw4o6 specific configuration parameters must be > provisioned to the lwB4. “ Good catch, I see that the document actually says SHOULD rather than MUST for the map-dhcp option. I think this should be a MUST. _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
