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

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Oct 2014 13:10:26 -0500

On Oct 15, 2014, at 12:12 PM, [email-masked] wrote:
> 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.

It might be better to simply say "the precise mechanism whereby this synchronization occurs is out of scope for this document."

---

From: <[email-masked]>
Date: Wed, 15 Oct 2014 19:12:58 +0200

Hi David,

Many thanks for the review. Please see comments inline.

Cheers,
Ian

On 12/10/2014 00:30, "Black, David" <[email-masked]> 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?:

>
>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
>[email-masked]        Mobile: +1 (978) 394-7754
>----------------------------------------------------
>