Hi Cameron, You may need spend time to review it later, it's different from 6RD and DS-Lite,
Secondly, I am wondering whether it could fit for mobile CPE case. Best regards, -Hui 2011/7/28 Cameron Byrne <[email protected]> > > 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 > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
