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

["Black, David" <[e-mail]>]

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:[e-mail]]
> Sent: Wednesday, October 17, 2012 8:46 PM
> To: Black, David; [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; [e-mail]; 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" <[e-mail]> 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
> >[phone]             FAX: [phone]
> >[e-mail]        Mobile: [phone]
> >----------------------------------------------------
> >
> >