Hello Roberta, In that case, more text is needed to explain in Section 2.8, and the related theft of service concern also needs to be discussed in that section and/or the Security Considerations section.
Thanks, --David > -----Original Message----- > From: Maglione Roberta [mailto:[email protected]] > Sent: Thursday, October 18, 2012 3:18 AM > To: Black, David; Lee, Yiu; 'draft-ietf-softwire-dslite- > [email protected]' > Cc: Ralph Droms; [email protected]; [email protected] > Subject: RE: Gen-ART review of draft-ietf-softwire-dslite-deployment-06 > > Hello Yiu and David, > regarding point 5: > > > [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." > > The point related to the accounting is different: what I meant here with > accounting is RADIUS based accounting, commonly used in Broadband networks. > > Today RADIUS accounting is done at the BNG level, the problem with the > introduction of the AFTR is that the AFTR does not interact with AAA/RADIUS > Server for the initial authentication/authorization/accounting phase because > the authentication/authorization/accounting process happens between BNG and > RADIUS Server when the session comes up. > The ATFR is not able to perform RADIUS accounting because as it does not > interact with the RADIUS Server it does not have " detailed customer identity > information" for example it does know the accounting session ID associated to > that session, that's why it cannot do detailed accounting for each single > subscriber even if the ATFR can still correlated IPv6 and IPv4 traffic > belonging to the same user. > > This is an important operational issue, I would suggest to keep this concept. > If you think is needed I can add some lines of text in order to clarify this > point. > > Thanks > Regards, > Roberta > > -----Original Message----- > From: Black, David [mailto:[email protected]] > Sent: Thursday, October 18, 2012 3:12 AM > To: Lee, Yiu; Maglione Roberta; [email protected]; > [email protected]; [email protected]; [email protected] > Cc: [email protected]; [email protected]; Ralph Droms; Black, David > Subject: RE: Gen-ART review of draft-ietf-softwire-dslite-deployment-06 > > 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:[email protected]] > > Sent: Wednesday, October 17, 2012 8:46 PM > > To: Black, David; [email protected]; [email protected]; > > [email protected]; [email protected]; gen- > [email protected] > > Cc: [email protected]; [email protected]; 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" <[email protected]> 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 > > >[email protected] Mobile: +1 (978) 394-7754 > > >---------------------------------------------------- > > > > > > > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora > abbiate ricevuto questo documento per errore siete cortesemente pregati di > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the intended > recipient, please delete this message and any attachments and advise the > sender by return e-mail, Thanks. > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
