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

[Qi Sun <[e-mail]>]

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 <[e-mail]> 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: [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]
>>> ----------------------------------------------------
>>> 
> 
> _______________________________________________
> Softwires mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/softwires