Hi Olaf, thanks for your detailed review. Please see inline...
> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of [email protected] > > Hi folks > > @IETF79 I have been asked to do a review of the above mentioned I-D and > that's why I had another round of reading this doc (and all the other > reviews of this I-D that happened during the last weeks). > > From my perspective this I-D is a well written document that extends > the applicability of the DS-lite tunnel approach also to the 3G world > and other point-to-point tunnel based network access architectures. GI- > DS-lite is furthermore referenced within the 3GPP standardization > documents as one of the technologies for supporting IPv6 deployment and > IPv4 address exhaustion mitigation. That's why I think, that the GI-DS- > lite spec is very useful and also needed in communities outside the > IETF. > > Since the doc is already in a very good shape I've only to add the > follwoing minor comments (Besides the remarks already posted by Yiu Lee > :): > - Page 7 - 2nd bullet point: > s/can its/can use its/ > s/and IPv4 packet/an IPv4 packet/ ..FB: ok > - Page 8 - 2nd bullet point: MPLS VPN > Did I get this right, that your assumption for this tunnel > scenario is, that there are "point-to-point" MPLS VPN > links between AFTR and Gateway? (I.e. each VPN contains only one > Gateway and one AFTR interface.) > In that case I would suggest: > s/IPv4 address/IPv4 address of the Gateway/g ..FB: This could be a "point to point" VPN - but doesn't have to be one. Much like you could have multiple NAT boxes deployed in a normal NAT deployment, one could have multiple NAT boxes present in a single VPN - and setup your routing in a way that you achieve some load balancing across the different NAT boxes. (Though your (corrected) comment - "s/IPv4 address/IPv4 address of the AD/" applies of course). > - Page 8 - 3rd bullet point - I agree with Yiu Lee's remark that it > seems useful to clarify the IP-in-IP case and to explicitely describe > from which IP header (inner/outer, IPv4/IPv6) the address or flow > label are choosen. > Perhaps it is also useful to name these cases explicitely "Plain > IPv4-in-IPvX". ...FB: Agreed. > > - Page 9 - Chapter 7.1.: Just a question: Since this example call flow > seems to be only for clarification, would it make sense to shift this > to some kind of appendix? > > - Page 9 - Chapter 7.2: Would it make sense to substitue the word > "examples" with "Network scenarios"? .. FB: Fine for me. How about making section 7 (so both 7.1 and 7.2) Appendix A? The only downside I see with an appendix approach is really that the text which some readers might still be interested in is a bit separated from the real document - because (per formatting rules), it'll end up at the very end of the document, behind the references. > > From my point of view this document is (if the above minor changes are > applied) ready for the next steps of the RFC process. Thanks again for your detailed review. Regards, Frank > > So far my 0,02$. Kind regards > Olaf > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
