Hi, inline...
On 30 July 2013 12:43, Simon Perreault <[email protected]> wrote: > Le 2013-07-30 10:16, Mikael Abrahamsson a écrit : > > Just want to be sure a certain use case is covered by the current draft: >> >> I'm an ISP and I don't control CPEs. Customers buy them at local >> electronics store and plug the in. I want to support "all" (or subsetof) >> transition mechanisms for 4 over 6 and 6 over 4 etc. Customers might >> purchase devices that support 0 to all of these mechanisms. >> >> Is there anything in the current discussions about "unified cpe" that >> causes problems in the above scenario? I don't know if I understood >> correctly when I heard stuff about overloading options with slightly >> different meanings in different contexts? >> > > I see three options: > > If OPTION_MAP_BIND doesn't exist: > > Option 1: Send OPTION_S46_BRULE with EA-length = 0. But you don't get to > benefit from meshing if you support it. > > Option 2: Send *two* OPTION_S46_BRULE, one with EA-length=0, and another > with EA-length=N. You get to benefit from meshing, but then we need to > specify how CPEs are to handle multiple BRULEs. > Woj> This is strictly speaking not correct, in terms of enabling meshing. To do that, one would send an FRULE with pretty much the same content as the BRULE. Multiple BRULES really come into the picture with CE's attached to "multiple domains" Regards, Woj. > > If OPTION_MAP_BIND exists: > > Option 3: Send OPTION_S46_BRULE with EA-length=N and OPTION_MAP_BIND. > > > The current consensus, as I understand it, is for option 3. > > Simon > -- > DTN made easy, lean, and smart --> > http://postellation.viagenie.**ca<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<https://www.ietf.org/mailman/listinfo/softwires> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
