On Jul 28, 2011 5:08 AM, "Paco Cortes" <[email protected]> wrote: > > Hi Wojciech, > > two comments on the 3gpp sections of draft-dec-stateless-4v6-02. > > First, the definition of "Rx" is missing in section 4.2.1. > > Second, the table in section 4.2.2 claims "No discernible impact" for > "AF Application Function" for the 4V6 translation mode. This is not > fully correct. > The PCC architecture support a plurality of AFs communication over Rx > with the PCRF, and most of them "interact" in some way with the end > user payload. > An AF might terminate, proxy or transparently inspect a subset of the > UE traffic (for instance control signalling, like SIP). > An AF might also terminate, proxy or transparently inspect all UE > traffic (application server acting as AF, deep packet inspection > device, ...). > And the most important point: An AF might located in different > locations inside the operators networks, or even outside the operators > network. > Referring to your own "Figure 2" in the draft, this means that for > IPv4 traffic an AF might "intercept" traffic between the "PDN-Gw" and > the "S46 Gateway", i.e. with an IPv6 header, BUT it might also > intercept traffic behind the "S46 Gateway", i.e., with an IPv4 header. > > I propose to change the impact to "No impact for IPv6. Feature to map > IPv4-IPv6 addresses may be needed only in case of IPv4-only > applications". > > I'm aware that it would be theoretically possible to "hide" this > impact from an AF by using a more complex PCRF implementation that > "translates" IPv4 addresses in Rx message (including TFTs) into the > mapped IPv6, but this would imply limitations, and would just be one > implementation possibility. I believe that this draft should not > assume a specific implementation, unless clearly documented. >
+1, I believe this section causes confusion. I have not had time to do a full review. Tunneling traffic breaks pcc and a new bearer type is a tall order. We already visited these issues when concluding 6rd and ds-lite were not good fits for 3gpp. Cb > br, > Paco > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
