Skip to main content

Telechat Review of draft-ietf-softwire-lw4over6-11

Request Review of draft-ietf-softwire-lw4over6
Requested revision No specific revision (document currently at 13)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2014-10-28
Requested 2014-10-24
Authors Yong Cui , Qiong Sun , Mohamed Boucadair , Tina Tsou (Ting ZOU) , Yiu Lee , Ian Farrer
I-D last updated 2014-10-24
Completed reviews Genart Last Call review of -10 by David L. Black (diff)
Genart Last Call review of -11 by David L. Black (diff)
Secdir Last Call review of -10 by Samuel Weiler (diff)
Opsdir Last Call review of -10 by David L. Black (diff)
Opsdir Telechat review of -11 by David Harrington (diff)
Opsdir Telechat review of -13 by David L. Black
Assignment Reviewer David Harrington
State Completed
Review review-ietf-softwire-lw4over6-11-opsdir-telechat-harrington-2014-10-24
Reviewed revision 11 (document currently at 13)
Result Has Issues
Completed 2014-10-24

I think there are a few problems with this draft that should be looked at more

1) I think there is a problem with having a MUST condition in the spec
depending on a companion document that will be published later.


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.


There are additional synchronization requirements specified in 6.1 - Binding
Table Maintenance.

If the synchronization is that important that it deserves multiple MUSTs in the
spec, and the details depend on the provisioning mechanism, then it sounds
reasonable to consider the companion document to be required.

It seems to me that, if synchronization is critical and we want
interoperability, there should  be a mandatory-to-implement synchronization
spec defined before this spec is ready for publication.

2) I have a related concern: I don’t see discussion of how the implementation
should be operated and monitored, remotely.

Since this implementation is expected to reside in customer premises equipment,
having a remote monitoring and management capability seems important.

And since this is being developed in the IETF, where interoperability is
important, it would seem an IETF standardized monitoring and management
solution would be desirable.

A MIB module would provide monitoring capability, but none is defined or
suggested here. This is an extension to DS-LIte, and there is a DS-Lite MIB.
There is no discussion of whetherr that DS-Lite MIB module would be applicable
to lw4o6, or whether that MIB module would require changes to be applicable to
lw4o6 monitoring.

A YANG solution could address both the monitoring and provisioning requirements.

But an operator cannot use it if it isn’t implemented, so there should be a
mandatory-to-implement mechanism to allow for monitoring in an interoperable
manner. (Operators can still choose to deploy different non-interoperable
solutions fi they choose, but without a mandatory-to-implement baseline for
interoperability, they cannot choose one known to be interoperable across all
standard-compliant implementations.)

3) I have a concern with section 3.2.1, which is entitled “Changes to RFC2473
and RFC6333 Fragmentation Behavior”.

The text says to follow the best current practices of a number of other
documents, but it never actually discusses what the changes to fragmentation
behavior would be.

RFC2473 and RFC6333 are both standards-track. Is this document proposing to
update those standards? It doesn’t say so in the I-D heading.

The RFCs containing best current practices cover a lot of ground. This feels
like hand-waving as a result.

Are all of the best practices needed for this spec to work properly, or just
some of them?

Are some of these BCPs REQUIRED for this spec to work properly?

This section is about changes in fragmentation behavior. Are there specific
sections of the BCPs that are important to apply, for the changes in
fragmentation behavior?

The text specifies following the best current practices as a SHOULD; it doesn’t
discuss why this is only a SHOULD and not a MUST.

Under what circumstances would it be acceptable to NOT follow these best

What would happen to the network or the users of the network if an lwB4
implementation does NOT follow those guidelines?

(This would be easier to discuss if the spec referred to specific best
practices relevant to fragmentation.)

4) Section 7 suggests a number of additional provisioning mechanisms:

   In addition to the DHCPv6 based mechanism described in section 5.1,
   several other IPv4 provisioning protocols have been suggested.  These
   protocols MAY be implemented.  These alternatives include:

   o  DHCPv4 over DHCPv6: [RFC7341] describes implementing DHCPv4
      messages over an IPv6 only service providers network.  This
      enables leasing of IPv4 addresses and makes DHCPv4 options
      available to the DHCPv4 over DHCPv6 client.

Cui, et al.              Expires April 17, 2015                [Page 12]

Internet-Draft             Lightweight 4over6               October 2014

   o  PCP[RFC6887]: an lwB4 MAY use [I-D.ietf-pcp-port-set] to retrieve
      a restricted IPv4 address and a set of ports.

   In a Lightweight 4over6 domain, the binding information MUST be
   aligned between the lwB4s, the lwAFTRs and the provisioning server.

How do we achieve interoperability if each implementation can choose different
provisioning mechanisms?

Especially, given that synchronization is critical, and is dependent on the
provisioning mechanism used?

5) section 7 suggests provisioning mechanisms in addition to DHCPv6, so I
checked to see if DHCPv6 was required (i.e. mandatory to implement).

That also appears to merely be an option.

So there apparently is no mandatory-to-implement way to address these MUSTs:


   In lw4o6, a number of lw4o6 specific configuration parameters must be

   provisioned to the lwB4. “

David Harrington

ietfdbh at

On Oct 21, 2014, at 3:48 AM, Qi Sun <

sunqi.csnet.thu at

> wrote:

Dear Ted, David,

As a co-author the the draft-sun-softwire-yang-00, I have to admit this draft
is pre-mature and needs in-depth discussion before it can go forward. We don’t
know how far it will have progressed since this original idea as well as the
document structure needs feedback from both the Softwire WG and the netmod WG.
We don’t hope this draft to be a potential blocking point of the doc that has
got consensus of the WG, as the discussions might be long.



On Oct 21, 2014, at 1:03 AM, Ted Lemon <

ted.lemon at

> wrote:

On Oct 20, 2014, at 9:43 AM, Black, David < at

> wrote:

Whether adding an informative mention of the YANG model rises to the level of

"required" would be up to the OPS ADs.  It may help implementers find the YANG

model, which could be useful.

The problem with this is that the informative reference would wind up being to
a -00 draft of the yang data model; unless that document makes rapid progress,
it's unlikely that the reference will be to a version of the document that
anybody would find useful.   It might be worth asking the authors of that
document where they think it will be in two or three months, since that's about
the length of the RFC Editor queue at the moment, IIRC.


OPS-DIR mailing list