You're apparently missing some key points: 1. It's a functional requirement of a CPE, specifying how the CPE behaves with a case of NOT having an IPv4 address. What is the to be the bahviour of a MAP CPE without one? 2. This is NOT about configuring a ds-lite CPE
Throughout, its still not been answered what is the downside of having this functionality of a *MAP CPE*? On 23 November 2013 19:13, Ole Troan <[email protected]> wrote: > > This is hardly a hack, it's a functional requirement of a CPE, > specifying how the CPE behaves with a case of NOT having an IPv4 address = > no NAT44, in this case. It's not about overflow. > > > > Besides that very obvious case to handle, I provided an explanation of > the value the described behaviour brings, which has also been demonstrated > (per Xing's mail). So far you have not substantiated what is the down-side > of having this functionality on a MAP CPE, other than considering it not > useful. Could you do that? > > > > Re: your substitution: No, an SP can hardly predict which CPEs in > question need to have DS-Lite capabilities (as in support ds-lite options, > et al) > > to take the overflow case, then you'd still need to provision this as two > MAP domains. > does it make much difference if you provision it as one MAP domain and one > 6334 option? > > I'm in favour of having these mechanisms as ships in the night. > > given that we already have a way to provision DS-lite (6334), I wouldn't > really be in favour of adding another one. > I think CPE implementors have enough combinations already. ;-) > > cheers, > Ole >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
