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

From: "Black, David" <[email-masked]>
Date: Sat, 11 Oct 2014 22:30:26 +0000

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.

[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.

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.

[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]."

[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.

[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"

[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-port-numbers.xhtml

[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"?

[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.

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.

-- Section 5.2.  Lightweight B4 Data Plane Behavior

   Internally connected hosts 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".

-- 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.

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.

- 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

--- 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
----------------------------------------------------

---

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

Hi David,

Many thanks for the review. Please see comments inline.

Cheers,
Ian

>   The lwB4 SHOULD implement the requirements defined in [RFC5508] for

[if] OK with the above proposals.

>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.

>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.

>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.

>wanted here is a forward reference to the alternatives discussed in

[if] Rewording with:

To configure these parameters using DHCPv6, the lwB4 MUST implement
OPTION_S46_CONT_LW.

>   dynamic provisioning process must be re-initiated.

[if] OK

>http://www.iana.org/assignments/service-names-port-numbers/service-names-p

[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.

>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.

>   Otherwise the lwAFTR MUST discard all inbound ICMPv4 messages.

[if] OK

>to an AFTR" for consistency with the AFTR definition.

[if] OK

>   Internally connected hosts source IPv4 packets with an [RFC1918]

[if] Reword with:

Hosts connected to the customer's network behind the lwB4 source IPv4
packets with an [RFC1918] address.

>after "de-capsulation and re-encapsulation of packets".

[if] OK with the suggested wording.

>of forms of "synchronize" elsewhere in this draft.

[if] OK

>	elsewhere.  If lw4o6 is using that range, an explanation ought to be

[if] lw4o6 doesn¹t use these

>     draft-ietf-pcp-port-set-05

[if] All should now be fixed in v11 (posted earlier today)

---

From: "Black, David" <[email-masked]>
Date: Wed, 15 Oct 2014 20:27:06 +0000

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.

> synchronised manually, e.g. by copying aligned configuration files to each

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.

>    RECOMMENDED that PSIDs containing the system ports (0-1023) are

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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 15, 2014 1:06 PM
> To: Black, David; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; gen-
> [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Gen-ART and OPS-Dir review of draft-ietf-softwire-lw4over6-10
> 
> Hi David,
> 
> >Please resolve these comments along with any other Last Call comments you may receive.
> >
> >in the manner specified requires strong familiarity with both DS-Lite and NAPT.
> >

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Oct 2014 14:55:05 -0700

Thank you for the substantive review, David. And thank you Ian et al for the effort to answer the questions in the review. At this point I think it looks like you are on your way to address everything that has been brought up, at least on the level where I feel that I have no blocking comments to make in the IESG review. I plan to ballot No-Objection, but keep monitoring this thread.

Jari

---

From: Qi Sun <[email-masked]>
Date: Mon, 20 Oct 2014 14:19:48 +0800

Dear David, 

The comments and updates do help to get lw4o6 specification clearer. Thanks! 

>> 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 <[email-masked]> wrote:

> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: "Black, David" <[email-masked]>
Date: Mon, 20 Oct 2014 13:43:42 +0000

Hello Qi,

> 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.

Well, the lw4o6 specification results in significant operational change from the
current DS-Lite, so that does raise the question of how to manage lw4o6.

That said, I characterized this as a minor issue, and regard such a reference
as helpful, but not essential.  I'm suggesting an informative reference, not
normative - a sentence observing that the YANG model exists would suffice
(I see no need for a "MUST" or "SHOULD" requirement for YANG in this draft).

> Is such a reference required by the OPS-Dir review?

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.

Thanks,
--David

> From: Qi Sun [mailto:[email-masked]]
> Sent: Monday, October 20, 2014 2:20 AM
> To: Black, David
> Cc: [email-masked]; [email-masked]; sunqiong;
> [email-masked]; [email-masked]; Yiu Lee; [email-masked]; ops-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Softwires] Gen-ART and OPS-Dir review of draft-ietf-softwire-
> lw4over6-10
> 
> Dear David,
> 
> 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.
> 
> requirement

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Oct 2014 13:03:30 -0400

> 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.

---

From: Qi Sun <[email-masked]>
Date: Tue, 21 Oct 2014 15:48:15 +0800

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. 

Thanks, 
Qi

---

From: David Harrington <[email-masked]>
Date: Tue, 21 Oct 2014 09:45:07 -0400

Hi,

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

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
“

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 practices?
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.

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
[email-masked]

On Oct 21, 2014, at 3:48 AM, Qi Sun <[email-masked]> wrote:

> OPS-DIR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ops-dir

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Oct 2014 11:09:41 -0400

To Softwires:

I've included comments below, but for the benefit of the authors and working group, the two actions items I see from this are:

1. map-dhcp should be a MUST, not a SHOULD.
2. the working group should decide whether DHCPv4-over-DHCPv6 is MTI in the B4, and whether pcp-port-set is MTI in the B4, because if they are not, operators can't deploy them.

To David Harrington:

First, thanks for the thoughtful comments.   I don't agree with everything you've said here, but you've definitely pointed out two significant problems that need to be dealt with.

>    be discussed in a companion document.

I think the authors already have made changes to this text based on David Black's review.

> 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.

I would certainly not object if you proposed such a mechanism.   Short of that, with all due respect, this is a pretty absurd objection.   This would be like saying that since IP requires a mechanism for keeping routing tables up to date, RFC 791 should not have been published until RFC 1058 was done.

> 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.

Do we require a MIB for existing routers with non-port-shared NATs?   If not, then I think this is an example of something that would certainly be good to do, but is not a prerequisite.   There is work being done on a YANG model, but I don't think anybody's doing a MIB, so again, if this is a matter that is of interest to you, I would encourage you to take on this work.

> 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…

The DS-Lite MIB doesn't manage the B4; only the AFTR.

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

As I mentioned, work is progressing on a YANG data model.   I think this is a good observation, but shouldn't block the base spec.

> 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 deplo…

Do you mean that the operator can't operate an AFTR without a management specification, or that an operator can't operate a network with B4s that can't be managed?

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

We don't know how to solve this problem.   It's being discussed in the working group.   The text was added at my request based on similar text in the MAP specification; I think the authors will either take the text out, or else modify it to make it clear that this is a problem to look out for, not something we know how to fix.

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

The conclusion of the working group thus far (which may change) is that (a) this probably isn't a very big problem, (b) we don't know how to solve it in a way that doesn't possibly make things worse, and therefore (c) we mention it so that people can be aware of it, but do not make recommendations because we have none to make.   It is worth noting that this same issue exists for DS-Lite, and we have not had reports from the field that there is evidence of actual operational problems.

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

Hm, I think the authors and wg should think about this.   Right now the expectation is that the map-dhcp option is mandatory, and these mechanisms are not, but if they aren't MTI in the HG, the operator can't depend on them working.

>    provisioned to the lwB4. “

Good catch, I see that the document actually says SHOULD rather than MUST for the map-dhcp option.   I think this should be a MUST.