+1.
It is fair enough.
But the operators will probably meet more difficulties to change v4 CPE than to 
change v6 CPE. (Maybe irrelevant to this thread.)


Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html



-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf 
Of Rajiv Asati (rajiva)
Sent: Friday, August 19, 2011 6:26 AM
To: Simon Perreault
Cc: [email protected]
Subject: Re: [Softwires] 4rd mapping rule separation

+1. 

The RFP angle is an important one, Simon.

Cheers,
Rajiv

Sent from Phone....

On Aug 19, 2011, at 8:57 AM, "Simon Perreault" <[email protected]> 
wrote:

> On 2011-08-19 05:19, Tetsuya Murakami wrote:
>> draft-murakami-softwire-4rd
>> draft-murakami-softiwire-4v6-translation
>> 
>> I think it might be good to combine these 2 drafts to create one unified 
>> document for 4rd specification.
> 
> The problem I see with this is:
> 
> - We (the IETF) might need to specify both translation and encapsulation
> protocols, because they have different applicability. (Still needs to be
> decided.)
> 
> - Operators will choose translation or encapsulation for each
> deployment, probably not both.
> 
> - Implementations of translation vs encapsulation will probably be very
> different. I see this as leading to different "products" or "feature
> sets" targeted to different markets. For example 3GPP products might
> want to implement translation while broadband products might want to
> implement encapsulation.
> 
> So in the end, I see an operator A needing the 4rd-Translation solution
> and operator B needing the 4rd-Encapsulation solution. This fits nicely
> with two different RFCs, is more easily cited in RFPs, etc.
> 
> Simon
> -- 
> DTN made easy, lean, and smart --> http://postellation.viagenie.ca
> NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> STUN/TURN server               --> http://numb.viagenie.ca
> _______________________________________________
> 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

Reply via email to