ietf
[Top] [All Lists]

RE: Gen-ART review of draft-ietf-softwire-dslite-deployment-06

2012-10-18 11:04:30
Yiu,

Thank you for your responses - most of them look fine, and in 
particular anything that I don't comment on here is acceptable to me.

[YL] In 2.2, we will add:

"Note that reassembly at Tunnel Exit-Point is resource
      intensive. A large number of B4 may terminate on the same AFTR. If many 
B4
      fragment the packets, it would increase sufficient load to the AFTR for
      reassembly. We recommend the operator should increase the MTU size of 
the IPv6
      network between B4 and AFTR to avoid fragmentation."

I would change "is" to "may be" in the first line.

[5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that
"the AFTR does not have detailed customer identity information."  Does
that create a theft of service possibility?  If so, that possibility
should be mentioned as a security consideration.  Also, Section 2.8
ought to be expanded with a sentence or two explaining why the AFTR
does not have that identity information, and in particular to explain
whether and why it is unreasonable in some or all cases to expect
that customer identity information be provided to the AFTR as part
of provisioning each customer's softwire.

[YL] Good catch. Actually I believe AFTR "does" have both IPv4 and IPv6 to
identify the customer. I suggest we remove

"but it will potentially introduce some additional complexity because
   the AFTR does not have detailed customer identity information."

That's definitely an easy way to address that issue, and it's fine with me.

Section 2.3 on MTU Considerations could usefully mention MTU discovery
techniques, as possibilities for customer IPv4 traffic to adapt to a
smaller IPv4 MTU.  If this is done, it would be useful to mention
RFC 4821 in addition to the mention of RFC 1191 in RFC 6333.

[YL] We would consider RFC 4821. However, the challenge is I don't have
information how many current OS support RFC 4821. Since DS-lite is a
transition technology, it would be unreasonable to ask the OS company to
implement RFC 4821 for DS-lite.

That's ok - this was a nit.

- Are one or both types of logging recommended?

[YL] We tempted to recommend source-specific log. However, some regulators
require to use both and the regulations vary country from country, this is
why we left it open and let the operators to decide.

Please add a version of your explanation to the draft.

In Section 2.7, I'm having a hard time understanding which traffic is
intended to be subject to the Outgoing Policies and the Incoming Policies.
Expanding each of those two bullets to explain what traffic is subject
to each class of policies would help.

[YL] Does this help?

Outgoing Policies apply to packets originating from B4 to IPv4 network.
Incoming Policies apply to packets originating from IPv4 network to B4.

Yes, that's clearer, although the B4 is not the network endpoint for any
of that traffic.  I suggest:

Outgoing Policies apply to packets originating from behind the B4 with 
a destination on the IPv4 network.

Incoming Policies apply to packets originating from the IPv4 network to
a destination behind the B4.

Thanks,
--David


-----Original Message-----
From: Lee, Yiu [mailto:Yiu_Lee(_at_)cable(_dot_)comcast(_dot_)com]
Sent: Wednesday, October 17, 2012 8:46 PM
To: Black, David; roberta(_dot_)maglione(_at_)telecomitalia(_dot_)it; 
carlw(_at_)mcsr-labs(_dot_)org;
christian(_dot_)jacquenet(_at_)orange(_dot_)com; 
mohamed(_dot_)boucadair(_at_)orange(_dot_)com; gen-art(_at_)ietf(_dot_)org
Cc: softwires(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; Ralph Droms
Subject: Re: Gen-ART review of draft-ietf-softwire-dslite-deployment-06

Hi David,

Thanks very much for review the draft. Comments inline.

Thanks,
Yiu

On 10/15/12 7:10 PM, "Black, David" <david(_dot_)black(_at_)emc(_dot_)com> 
wrote:

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.

Document: draft-ietf-softwire-dslite-deployment-06
Reviewer: David L. Black
Review Date: October 15, 2012
IETF LC End Date: October 16, 2012
IESG Telechat Date: October 25, 2012

Summary:

This draft is on the right track but has open issues, described in the
review.

This is a generally well-written draft that expands considerably on the brief
deployment considerations for DS-Lite in Appendix A of RFC 6333.  The draft
is clear and reasonably well-written, and a significant improvement on that
RFC 6333 Appendix, although an understanding of RFC 6333 is necessary to
understand this draft, which seems completely reasonable.

The B4 and AFTR acronyms are clever - kudos to whomever came up with
those.

I found five open issues, all of which are minor.

Minor Issues:

[1] Ironically, the first issue is that something should be said about
the relationship of this draft to Appendix A of RFC 6333.  It probably
suffices to say that this draft expands on the material in that Appendix,
as I see no need to specify that this draft updates RFC 6333 solely to
change non-normative material in an Appendix.

[YL] In "Overview", we will add:

"This document expands Appendix A of RFC6333 and discusses various
DS-Lite deployment considerations for operators."


[2] The MTU increase technique in Section 2.2 is a "may", which is
consistent with Section 5.3 of RFC 6333.  OTOH, Section 2.2 of this
draft should also discuss the AFTR resource exhaustion concern that
described in Section 6.3 of RFC 6333, as that is a potential
operational reason for an ISP to increase MTU size (e.g., if customer
sourcing of large IPv4 packets is not sufficiently rare).

[YL] In 2.2, we will add:

"Note that reassembly at Tunnel Exit-Point is resource
      intensive. A large number of B4 may terminate on the same AFTR. If many 
B4
      fragment the packets, it would increase sufficient load to the AFTR for
      reassembly. We recommend the operator should increase the MTU size of 
the IPv6
      network between B4 and AFTR to avoid fragmentation."


[3] Section 2.7 refers to "the AFTR's internal interface".  There may be
two internal interfaces, the physical IPv6 interface (outer header) and
the tunnel's IPv4 interface (inner header).  The text should be clarified
to indicate which interface is involved - it appears that the AFTR's
physical IPv6 interface is intended in this section.

[YL] We replace "internal" to "IPv6"


[4] Section 2.7 cites RFC 6333 for use of DHCPv6 with DS-Lite.  RFC 6334
should be cited - either in addition to or instead of RFC 6333.

[YL] Fixed


[5] Section 2.8 discusses IPv4 accounting at the AFTR, but notes that
"the AFTR does not have detailed customer identity information."  Does
that create a theft of service possibility?  If so, that possibility
should be mentioned as a security consideration.  Also, Section 2.8
ought to be expanded with a sentence or two explaining why the AFTR
does not have that identity information, and in particular to explain
whether and why it is unreasonable in some or all cases to expect
that customer identity information be provided to the AFTR as part
of provisioning each customer's softwire.

[YL] Good catch. Actually I believe AFTR "does" have both IPv4 and IPv6 to
identify the customer. I suggest we remove

"but it will potentially introduce some additional complexity because
   the AFTR does not have detailed customer identity information."


Nits:

Section 2.3 on MTU Considerations could usefully mention MTU discovery
techniques, as possibilities for customer IPv4 traffic to adapt to a
smaller IPv4 MTU.  If this is done, it would be useful to mention
RFC 4821 in addition to the mention of RFC 1191 in RFC 6333.

[YL] We would consider RFC 4821. However, the challenge is I don't have
information how many current OS support RFC 4821. Since DS-lite is a
transition technology, it would be unreasonable to ask the OS company to
implement RFC 4821 for DS-lite.


Section 2.4 should define "lawful intercept".  It would be helpful to
cite a reference for this concept if something appropriate can be found.

[YL] We will find whether there is any reference to this concept. If we
can't find any, we would add an explanation in the draft.


Section 2.5:
- Are one or both types of logging recommended?

[YL] We tempted to recommend source-specific log. However, some regulators
require to use both and the regulations vary country from country, this is
why we left it open and let the operators to decide.

- Last paragraph on p.4, "timestamped log" is not a good verb phrase.
    "maintain a timestamped log of" would be a better replacement.

[YL] Fixed

- Last paragraph in section, where is the batch file sent?

[YL] We will add:

"The files may be compressed before transferring to a repository server
      to better utilize bandwidth and storage."



In Section 2.7, I'm having a hard time understanding which traffic is
intended to be subject to the Outgoing Policies and the Incoming Policies.
Expanding each of those two bullets to explain what traffic is subject
to each class of policies would help.

[YL] Does this help?

Outgoing Policies apply to packets originating from B4 to IPv4 network.
Incoming Policies apply to packets originating from IPv4 network to B4.




Section 3.2.2.2 uses 192.0.0.2/32 as an example IP address for the
B4.  That section should also cross-reference Section 5.7 on RFC 6333
on IP address assignment to B4s, as other IP addresses may be used.

[YL] Added the cite.


idnits 2.12.13 found a tiny nit - draft-ietf-pcp-base is now at
version 28.

[YL] Fixed.


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