Qiong,
On 21 July 2012 11:46, Qiong <bingxu...@gmail.com> wrote: > Hi, Woj, > > This is not only about determining which parameter to explicitly exist in > MAP rule, but also the configuration in BR. If you include PSID explicitly, > then > 1) you need to configure per-subscriber rule in BR since the value of PSID > for different CPEs are different. This will take a lot of workload for > operators and it is obviously not the objective of any stateless solution. > Stateless does not mean configuration less, and never did. Even without an explicit PSID one could have thousands of "rules" configured, if one chooses to deploy it that way. > 2) IPv6 prefix has already carry the PSID implicitly, and the PSID in MAP > rule is redundant. > Therefore, I don't see the reason to include PSID explicitly in MAP > architecture. > So you don't disagree about the use, which is good. I'm however puzzled by why you see a need for a separate architecture document & specification to address the need for explicit port range, which the explicit PSID is, rather than working on a common solution... Regards, Woj. > > Best wishes > Qiong > > Wojciech Dec <wdec.i...@gmail.com>编写： > > > Remi, > > On 20 July 2012 17:03, Rémi Després <despres.r...@laposte.net> wrote: > >> Hi, Wojciech, >> >> 2012-07-20 12:56, Wojciech Dec: >> >> If the use of PSIDs in rules is useful, as it appears to be, >> >> >> This is the point that needs to be explained. >> > > The case is straightforward A+P. > For a single IPv4 address + port range it is desired to have it correspond > to an IPv6 address. > MAP and 4rd-u have that as a well established case with the IPv4 address > and / or PSID being mapped into the IPv6 prefix, but the IPv4 address not > given that it is configured on both sides (implicit). There is nothing in > the MAP architecture which restricts the PSID to not be such an implicit > parameter given that it can be configured at either side. > > -Woj. > > > >> Thanks. >> RD >> >> >> then there seems to be no reason not to allow that. >> >> Regards, >> Woj. >> >> >>> >>> - maoke >>> >>> >>>> >>>> Regards, >>>> Woj. >>>> >>>>> >>>>> >>>>> >> _______________________________________________ >> Softwires mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> >> >
_______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires
