Dear David, The comments and updates do help to get lw4o6 specification clearer. Thanks! But I have some thoughts about the following (minor) issue: >>> Minor issues (7): >>> >>> [3] The lack of discussion of management information is an >>> omission. See A.2.2 below in the OPS-Dir review section of this email >>> and the discussion in Section 3.2 of RFC 5706. A sentence pointing >>> at an applicable MIB and/or YANG draft or drafts would suffice. >> >> [if] There is a draft for a softwire YANG model which is due to be >> published shortly. We'll add an informative reference to this. I’m feeling it’s not necessary for such a specification to reference the YANG model document. The current lw4o6 specification does work without this management YANG model doc. I think the OA&M should be out of the scope for this protocol specification. And, I checked the RFC6333, where no such pointer exists. Is such a reference required by the OPS-Dir review? Thanks, Qi On Oct 16, 2014, at 4:27 AM, Black, David <david.black@xxxxxxx> wrote: > Hi Ian, > > Many thanks for the comprehensive response - I've extracted [1], [2] > and [7] for further attention here - your proposals for all of the > other items and nits are fine with me. > > I think the only open topic is [7], and I can live w/your proposed > rephrasing for that even though I'd like to see a sentence of > rationale added. > >>> [1] There are a number of places where SHOULD is used to refer to >>> requirements in another RFC, e.g., the following text in section 5.1: > > [... snip ...] > >> [if] OK with the above proposals. > > I supplied new text for 5.1 - please also make the corresponding changes > in 5.2.1 (twice) and 8.2, plus check whether this "SHOULD" problem > occurs elsewhere. > >>> [2] Section 4. Lightweight 4over6 Architecture >>> >>> 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 believe that this "companion document" needs to be cited as a >>> normative reference. The above text's vague allusion to the specification >>> of how to implement a "MUST" requirement is insufficient. >> >> [if] The synch mechanism is really down to how an operator has deployed >> the service, the specific provisioning protocols in use etc. What about >> the following wording change?: >> >> 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 protocols that are in use by the >> operator. If no automated process for this synchronisation is in use, then >> information in the provisioning systems and the lwAFTR MUST be >> synchronised manually, e.g. by copying aligned configuration files to each >> of the elements. > > That wording change is fine, and I prefer it to Ted's subsequent suggestion > of shorter "out of scope" language. > > My primary concern was the reference to a "companion document" which lead > to an obvious "where is that???" question. The new wording removes that > reference and provides some useful information on how the required > synchronization could be accomplished. > >>> [7] Also in Section 5.1 >>> >>> Unless an lwB4 is being allocated a full IPv4 address, it is >>> RECOMMENDED that PSIDs containing the well-known ports (0-1023) are >>> not allocated to lwB4s. >>> >>> Please explain why. Also, "well-known ports" is not the right term; >>> I believe those are the "system ports", e.g., see: >>> >>> http://www.iana.org/assignments/service-names-port-numbers/service-names-p >>> ort-numbers.xhtml >> >> [if] Reworded: >> >> Unless an lwB4 is being allocated a full IPv4 address, it is >> RECOMMENDED that PSIDs containing the system ports (0-1023) are >> not allocated to lwB4s. > > Why? Please add a sentence to explain, although I'll be ok if all that > is done is the rewording. > > Thanks, > --David > >> -----Original Message----- >> From: ian.farrer@xxxxxxxxxx [mailto:ian.farrer@xxxxxxxxxx] >> Sent: Wednesday, October 15, 2014 1:06 PM >> To: Black, David; yong@xxxxxxxxxxxxxxxxxxxxxxxxx; sunqiong@xxxxxxxxxxxx; >> mohamed.boucadair@xxxxxxxxxx; tena@xxxxxxxxxx; yiu_lee@xxxxxxxxxxxxxxxxx; gen- >> art@xxxxxxxx; ops-dir@xxxxxxxx >> Cc: ietf@xxxxxxxx; softwires@xxxxxxxx >> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-10 >> >> Hi David, >> >> Many thanks for the review. Please see comments inline. >> >> Cheers, >> Ian >> >> >> >> On 12/10/2014 00:30, "Black, David" <david.black@xxxxxxx> wrote: >> >>> This is a combined Gen-ART and OPS-DIR review. Boilerplate for both >>> follows, >>> and I apologize for it being a day late - United Airlines got me back to >>> Boston after midnight last night on a plane w/o working WiFi. >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at: >>> >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> Please resolve these comments along with any other Last Call comments you may receive. >>> >>> I have reviewed this document as part of the Operational directorate's ongoing >>> effort to review all IETF documents being processed by the IESG. These comments >>> were written primarily for the benefit of the operational area directors. >>> Document editors and WG chairs should treat these comments just like any other >>> last call comments. >>> >>> Document: draft-ietf-softwire-lw4over6-10 >>> Reviewer: David Black >>> Review Date: October 10, 2014 >>> IETF LC End Date: October 10, 2014 >>> IESG Telechat date: October 16, 2014 >>> >>> Summary: This draft is on the right track, but has open issues >>> described in the review. >>> >>> This draft describes an extension to Dual-Stack Lite that relocates the NAPT >>> functionality from the centralized tunnel concentrator to the DS-Lite client >>> - doing so has significant scalability benefits. The draft is generally >>> readable although understanding why some of the processing needs to be done >>> in the manner specified requires strong familiarity with both DS-Lite and NAPT. >>> >>> The draft is generally in good shape - I found three issues that I consider >>> to be significant, the most important of which are sloppiness in use of >>> RFC 2119 keywords, particularly in Section 5.1, and omission of what >>> appears to be a necessary normative reference. >>> >>> Major issues (2): >>> >>> [1] There are a number of places where SHOULD is used to refer to requirement >>> in another RFC, e.g., the following text in section 5.1: >>> >>> The DNS considerations described in Section 5.5 and Section 6.4 of >>> [RFC6333] SHOULD be followed. >>> >>> This has the side effect of weakening any MUST requirement in the referenced >>> RFC(s) to a SHOULD, which was probably not intended, and needs to be explicitly >>> stated if it was intended. Here's a possible rephrasing: >>> >>> The DNS considerations described in Section 5.5 and Section 6.4 of >>> [RFC6333] apply to Lightweight 4over6; lw4o6 implementations MUST >>> comply with all requirements stated there. >>> >>> The additional places where this occurs are: >>> >>> - Section 5.2.1 (twice): >>> >>> For TCP and UDP traffic the NAPT44 implemented in the lwB4 SHOULD >>> conform with the behaviour and best current practices documented in >>> [RFC4787], [RFC5508], and [RFC5382]. If the lwB4 supports DCCP, then >>> the requirements in [RFC5597] SHOULD be implemented. >>> >>> - Section 8.2: >>> >>> The lwB4 SHOULD implement the requirements defined in [RFC5508] for >>> ICMP forwarding. >> >> [if] OK with the above proposals. >> >> >>> >>> [2] Section 4. Lightweight 4over6 Architecture >>> >>> 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 believe that this "companion document" needs to be cited as a >>> normative reference. The above text's vague allusion to the specification >>> of how to implement a "MUST" requirement is insufficient. >> >> [if] The synch mechanism is really down to how an operator has deployed >> the service, the specific provisioning protocols in use etc. What about >> the following wording change?: >> >> 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 protocols that are in use by the >> operator. If no automated process for this synchronisation is in use, then >> information in the provisioning systems and the lwAFTR MUST be >> synchronised manually, e.g. by copying aligned configuration files to each >> of the elements. >> >> >>> >>> Minor issues (7): >>> >>> [3] The lack of discussion of management information is an >>> omission. See A.2.2 below in the OPS-Dir review section of this email >>> and the discussion in Section 3.2 of RFC 5706. A sentence pointing >>> at an applicable MIB and/or YANG draft or drafts would suffice. >> >> [if] There is a draft for a softwire YANG model which is due to be >> published shortly. We'll add an informative reference to this. >> >>> >>> [4] Section 4. Lightweight 4over6 Architecture >>> >>> The solution specified in this document allows the assignment of >>> either a full or a shared IPv4 address requesting CPEs. [RFC7040] >>> provides a mechanism for assigning a full IPv4 address only. >>> >>> Please explain what entities would share the IPv4 address. For example, >>> this is needed as a foundation for the statement in Section 8 that >>> "ICMPv4 does not work in an address sharing environment without >>> special handling [RFC6269]." >> >> [if] OK. Reworded version: >> >> The solution specified in this document allows the assignment of >> either a full IPv4 address for a CPE, or a single IPv4 address which is >> shared between multiple CPEs. [RFC7040] >> provides a mechanism for assigning a full IPv4 address only. >> >> >>> >>> [5] Section 5.1. Lightweight B4 Provisioning with DHCPv6 >>> >>> For DHCPv6 based configuration of these parameters, the lwB4 SHOULD >>> implement OPTION_S46_CONT_LW >>> >>> What are the consequences of not doing that? The could be addressed >>> by changing that "SHOULD" to a "MUST", although I suspect that what's >>> wanted here is a forward reference to the alternatives discussed in >>> Section 7. >> >> [if] Rewording with: >> >> To configure these parameters using DHCPv6, the lwB4 MUST implement >> OPTION_S46_CONT_LW. >> >> >>> >>> [6] Also in Section 5.1 >>> >>> If stateful IPv4 configuration or additional IPv4 configuration >>> information is required, DHCPv4 [RFC2131] must be used. >>> >>> "must" -> "MUST" >>> >>> In the event that the lwB4's encapsulation source address is changed >>> for any reason (such as the DHCPv6 lease expiring), the lwB4's >>> dynamic provisioning process must be re-initiated. >>> >>> "must" -> "MUST" >> >> [if] OK >> >>> >>> [7] Also in Section 5.1 >>> >>> Unless an lwB4 is being allocated a full IPv4 address, it is >>> RECOMMENDED that PSIDs containing the well-known ports (0-1023) are >>> not allocated to lwB4s. >>> >>> Please explain why. Also, "well-known ports" is not the right term; >>> I believe those are the "system ports", e.g., see: >>> >>> http://www.iana.org/assignments/service-names-port-numbers/service-names-p >>> ort-numbers.xhtml >> >> [if] Reworded: >> >> Unless an lwB4 is being allocated a full IPv4 address, it is >> RECOMMENDED that PSIDs containing the system ports (0-1023) are >> not allocated to lwB4s. >> >> >>> >>> >>> [8] Still in Section 5.1 >>> >>> In the event that the lwB4 receives an ICMPv6 error message (type 1, >>> code 5) originating from the lwAFTR, the lwB4 SHOULD interpret this >>> to mean that no matching entry in the lwAFTR's binding table has been >>> found. The lwB4 MAY then re-initiate the dynamic port-restricted >>> provisioning process. The lwB4's re-initiation policy SHOULD be >>> configurable. >>> >>> What happens if the lwB4 ignores the first "SHOULD"? >> >> >> [if] Reword: >> ...the lwB4 interprets this to mean that no matching entry in the lwAFTR's >> binding table has been found, so the IPv4 payload is not being forwarded >> by the lwAFTR. >> >> >> >>> >>> [9] Section 8.1. ICMPv4 Processing by the lwAFTR >>> >>> This describes two approaches to ICMPv4 processing. Are there any others? >>> If so, please add some text about them, otherwise, I suggest this change: >>> >>> OLD >>> Additionally, the lwAFTR MAY implement: >>> >>> o Discarding of all inbound ICMP messages. >>> NEW >>> Otherwise the lwAFTR MUST discard all inbound ICMPv4 messages. >> >> [if] OK >> >>> >>> >>> Nits/editorial comments: >>> >>> -- Section 1. Introduction >>> >>> Basic Bridging BroadBand element: A B4 element is a function >>> implemented on a dual-stack capable >>> node, either a directly connected >>> device or a CPE, that creates a >>> tunnel to an AFTR. >>> >>> I suggest changing "a tunnel to an AFTR" to "an IPv4-in-IPv6 tunnel >>> to an AFTR" for consistency with the AFTR definition. >> >> [if] OK >> >>> >>> -- Section 5.2. Lightweight B4 Data Plane Behavior >>> >>> Internally connected hosts source IPv4 packets with an [RFC1918] >>> address. >> >> [if] Reword with: >> >> Hosts connected to the customer's network behind the lwB4 source IPv4 >> packets with an [RFC1918] address. >> >> >>> >>> Internal to what? Please explain. >>> >>> -- Section 6.2. lwAFTR Data Plane Behavior >>> >>> The lwAFTR MUST support hairpinning of traffic between two lwB4s, by >>> performing de-capsulation and re-encapsulation of packets. The >>> hairpinning policy MUST be configurable. >>> >>> Please explain "hairpinning" - it should suffice to add "from one lwB4 >>> that need to be sent to another lwB4 associated with the same AFTR" >>> after "de-capsulation and re-encapsulation of packets". >> >> [if] OK with the suggested wording. >> >>> >>> -- Section 7. Additional IPv4 address and Port Set Provisioning >>> Mechanisms >>> >>> In a Lightweight 4over6 domain, the binding information MUST be >>> aligned between the lwB4s, the lwAFTRs and the provisioning server. >>> >>> "aligned between" -> "synchronized across" for consistency with use >>> of forms of "synchronize" elsewhere in this draft. >> >> [if] OK >> >>> >>> idnits found a few things to complain about: >>> >>> - The use of "the well-known range 192.0.0.0/29" in Section 5.1. This is >>> ok, >>> as it's describing DS-Lite use of that range that is documented >>> elsewhere. If lw4o6 is using that range, an explanation ought to be >>> added to Section 5.1. >> >> [if] lw4o6 doesn¹t use these >> >>> >>> - Three references have been updated: >>> >>> == Outdated reference: A later version (-09) exists of >>> draft-ietf-softwire-map-dhcp-07 >>> >>> == Outdated reference: draft-ietf-dhc-dhcpv4-over-dhcpv6 has been >>> published >>> as RFC 7341 >>> >>> == Outdated reference: A later version (-06) exists of >>> draft-ietf-pcp-port-set-05 >> >> [if] All should now be fixed in v11 (posted earlier today) >> >>> >>> --- Selected RFC 5706 Appendix A Q&A for OPS-Dir review --- >>> >>> A.1.1. Has deployment been discussed? >>> >>> Yes, this protocol is intended to improve scalability over the existing >>> DS-Lite mechanism. >>> >>> A.1.2. Has installation and initial setup been discussed? >>> >>> No, there are vague references to a provisioning mechanism and >>> synchronization functionality that need to be set up. See >>> major open issue [2] above which calls out a missing normative >>> reference that should address these topics. >>> >>> A.1.3. Has the migration path been discussed? >>> >>> No, but I suspect that this concern is inapplicable, as I think >>> a carrier would not migrate from DS-Lite to lw4o6, but would >>> deploy lw4o6 instead of DS-Lite. >>> >>> A.1.4. Have the Requirements on other protocols and functional >>> components been discussed? >>> >>> Yes, but major open issue [1] is effectively in this area. >>> >>> A.1.6. Have suggestions for verifying correct operation been discussed? >>> >>> No, and they probably should be, as this protocol requires state >>> synchronization among the lwB4, lwAFTR and the provisioning system, >>> and is likely to exhibit problematic behavior if the relevant state >>> information gets out of sync. >>> >>> A.1.9. Is configuration discussed? >>> >>> Yes, the draft does a good job of discussing what needs to be >>> configured to set up the protocol (aside from state synchronization) >>> and calling out protocol behavior aspects that should be configurable. >>> >>> A.2 Management >>> >>> This is really not discussed, and in particular the lack of discussion >>> of management information is notable because this protocol has a >>> different operational structure than DS-Lite. So, specifically: >>> >>> A.2.2. Is management information discussed? >>> >>> No, this is minor open issue [3]. A sentence pointing to applicable >>> MIB and/or YANG draft(s) would suffice to address this. >>> >>> A.2.4. Is configuration management discussed? >>> >>> Yes - the discussion is ok, even though specific configuration mechanisms >>> are not discussed. >>> >>> A.3. Documentation >>> >>> The protocol does have significant operational impacts on the Internet. >>> >>> The shepherd's writeup indicates that multiple implementations exist >>> among which interoperability has been tested. >>> >>> Thanks, >>> --David >>> ---------------------------------------------------- >>> David L. Black, Distinguished Engineer >>> EMC Corporation, 176 South St., Hopkinton, MA 01748 >>> +1 (508) 293-7953 FAX: +1 (508) 293-7786 >>> david.black@xxxxxxx Mobile: +1 (978) 394-7754 >>> ---------------------------------------------------- >>> > > _______________________________________________ > Softwires mailing list > Softwires@xxxxxxxx > https://www.ietf.org/mailman/listinfo/softwires