Hi Simon, One answer in line (I think Med covered off the rest)
Cheers, Ian On 30/11/2012 13:59, "Simon Perreault" <[email protected]> wrote: >Le 2012-11-29 11:16, [email protected] a écrit : >> As agreed in Atlanta, we prepared an I-D describing a proposed approach >>for the unified CPE. >> >> We hope this version is a good starting point to have fruitful >>discussion. >> >> Your comments, suggestions and contributions are more than welcome. > >Here are some: > >- First, I think this is very positive. I like what I'm reading. > > >- Didn't we also consider public 4o6 as one mode? Any reason why it was >left out? > - Is public 4o6 the "minor change to lw4o6" that section 4.1 hints at? > > >- In section "3.2. Required Provisoning Information", I believe it would >be possible and beneficial to specify only what each mode requires *in >addition* to what the previous mode already provides. e.g. > - DS-Lite requires the remote tunnel endpoint address. > - In addition to that, lw4o6 requires the CPE's IPv4 address and port >set. > - In addition to that, MAP requires mesh routes. >So each mode's provisioning parameters would be a superset of the >previous one. (DS-Lite < lw4o6 < MAP) > >One we have this kind of hierarchical provisioning, we can define CPE >behaviour in the same way. For example, MAP behaviour would be: >1. Do exactly what a lw4o6 CPE does. >2. In addition to 1, also send and receive packets directly to and from >other CPEs according to the provisioned mesh routes. > >(I will refrain from commenting on section 4.4 until we have the >higher-level design figured out.) Ian: I broadly agree with what you've said, but one use case that did cross my mind is if you only needed to provision mesh routes to a client with no need for a concentrator/default route. A closed machine-to-machine type service could be an example of this architecture. I'm not sure if it's a strong enough use case to build the provisioning model around, however. > >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
