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

["Lee, Yiu" <[e-mail]>]

Thanks David! I will apply your changes to the next version.

On 10/17/12 9:11 PM, "Black, David" <[e-mail]> wrote:

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