Hi Paco, I agree with you when IPv4-in-IPvY mode is the standard ds-lite model. I guess the extension here means to define a new set of identifiers which can be use by the GW (aka B4) for the . It doesn't necessary mean to extend the NAT table.
Best Regards, Yiu From: Paco Cortes <[email protected]<mailto:[email protected]>> Date: Tue, 8 Mar 2011 12:26:36 +0100 To: <[email protected]<mailto:[email protected]>> Subject: Re: [Softwires] Review of I-D draft-ietf-softwire-gateway-init-ds-lite-02 Hi, one more comment: - Page 4, 1st bullet point in section 4: This bullet is not always applicable. If the source IP address has been used as CID, as mentioned several times above as a possibility, then this parameter is already in a traditional NAT binding entry and no extension is needed for it. If the softwire technology/implementation used is seen by the AFTR as a logical interface, traditional NAT binding entries already include it, so that no extension is needed either. In particular, in the MPLS VPN embodiement described in section 6, NAT extensions would not be needed. A new qualifier part like "depending on the embodiement" should be added to this bullet. Kind regards, Paco 2011/3/7 <[email protected]<mailto:[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/ - 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 - 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". - 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"? >From my point of view this document is (if the above minor changes are >applied) ready for the next steps of the RFC process. So far my 0,02$. Kind regards Olaf _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
