Hi Simon, Please see inline.
Cheers, Med >-----Message d'origine----- >De : [email protected] >[mailto:[email protected]] De la part de Simon Perreault >Envoyé : vendredi 30 novembre 2012 13:59 >À : [email protected] >Objet : Re: [Softwires] Unified Softwire CPE: >draft-bfmk-softwire-unified-cpe > >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. Med: Thanks. > > >- 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? Med: The rationale we adopted in this draft is as follows: * there are three major flavors: full stateful, full stateless, and binding mode * all these modes can support assigning a full or a shared IPv4 address As such Public4over6 is classified as part of binding mode (see Section 3) (2) Binding approach (e.g., Lightweight 4over6 (Lw4o6) [I-D.cui-softwire-b4-translated-ds-lite], [I-D.ietf-softwire-public-4over6] or MAP 1:1 [I-D.ietf-softwire-map] ): Requires a single per-subscriber state (or a few) to be maintained in the Service Provider's network. > > >- 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) Med: The current text of Section 3.2 says: +---------+-------------------------------------+ | Mode | Provisioning Information | +---------+-------------------------------------+ | DS-Lite | Remote IPv4-in-IPv6 Tunnel Endpoint | | Lw4o6 | Remote IPv4-in-IPv6 Tunnel Endpoint | | | IPv4 Address | | | Port Set | | MAP-E | Mapping Rules | | | MAP Domain Parameters | +---------+-------------------------------------+ Table 4: Provisioning Information Note: MAP Mapping Rules are translated into the following configuration parameters: Set of Remote IPv4-in-IPv6 Tunnel Endpoints, IPv4 Address and Port Set. Can you please explicit the change you want to see appear in that text? Thanks. > >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. Med: Do you think this is different from the approach adopted in Section 4.3? > >(I will refrain from commenting on section 4.4 until we have the >higher-level design figured out.) > >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
