Re: [Softwires] Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-10

["Black, David" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, October 15, 2014 1:06 PM
> To: Black, David; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]; gen-
> [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]
> 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" <[e-mail]> 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
> >[phone]             FAX: [phone]
> >[e-mail]        Mobile: [phone]
> >----------------------------------------------------
> >