Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

[<[e-mail]>]

Hi Simon,

Please see inline. 

Cheers,
Med 

>-----Message d'origine-----
>De : [e-mail] 
>[mailto:[e-mail]] De la part de Simon Perreault
>Envoyé : vendredi 30 novembre 2012 13:59
>À : [e-mail]
>Objet : Re: [Softwires] Unified Softwire CPE: 
>draft-bfmk-softwire-unified-cpe
>
>Le 2012-11-29 11:16, [e-mail] 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
>[e-mail]
>https://www.ietf.org/mailman/listinfo/softwires
>