ietf
[Top] [All Lists]

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

2014-10-20 10:36:03
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(_dot_)black(_at_)emc(_dot_)com> 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(_dot_)farrer(_at_)telekom(_dot_)de 
[mailto:ian(_dot_)farrer(_at_)telekom(_dot_)de]
Sent: Wednesday, October 15, 2014 1:06 PM
To: Black, David; 
yong(_at_)csnet1(_dot_)cs(_dot_)tsinghua(_dot_)edu(_dot_)cn; 
sunqiong(_at_)ctbri(_dot_)com(_dot_)cn;
mohamed(_dot_)boucadair(_at_)orange(_dot_)com; tena(_at_)huawei(_dot_)com; 
yiu_lee(_at_)cable(_dot_)comcast(_dot_)com; gen-
art(_at_)ietf(_dot_)org; ops-dir(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; softwires(_at_)ietf(_dot_)org
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(_dot_)black(_at_)emc(_dot_)com> 
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(_dot_)black(_at_)emc(_dot_)com        Mobile: +1 (978) 394-7754
----------------------------------------------------


_______________________________________________
Softwires mailing list
Softwires(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/softwires