Le 19 août 2011 à 17:21, Mark Townsley a écrit : > > When the RFP is coming from Best Buy for a consumer device, you want fewer > alternatives.
Having the address mapping part separated from the tunneling part doesn't increase the number of alternatives, does it? To reduce the number of alternatives, encapsulation, which is completely transparent in all cases (shared and non shared addresses) would be the natural choice, but if two solutions are found better for different use cases, double translation (à la dIVI or 4rd-T which are essentially the same) also makes sense. RD > > - Mark > > On Aug 19, 2011, at 9:25 AM, Rajiv Asati (rajiva) wrote: > >> +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 _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
