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

[Simon Perreault <[e-mail]>]

Le 2012-11-30 14:09, [e-mail] a écrit :
>> - 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.

Ah, right, I missed that reference. Thanks.

>> - 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.

Something like:

DS-Lite:
- Remote IPv4-in-IPv6 Tunnel Endpoint

Lw4o6:
- DS-Lite set of provisioning information
- IPv4 address
- Port set

MAP-E:
- Lw4o6 set of provisioning information
- Forwarding mapping rules

My intuition is that with a unified CPE we don't need MAP to 
differentiate between "basic mapping rule", "forwarding mapping rule", 
and "default mapping rule".
- Basic mapping rule is just a forwarding mapping rule + IPv4 address + 
port set.
- Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint.

So in MAP mode we can just provide forwarding mapping rules in addition 
to the stuff that L4o6 already requires.

>> 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?

Well just from reading I thought it was different. Maybe your intent was 
what I expected, just not formulated the way I expected it.

One thing I expected to see is that if you take a unified CPE that only 
implements up to LW4o6 mode, and provision it with full MAP mode 
parameters, it will still work. It will ignore the forwarding mapping 
rules, and thus will not do mesh networking, but it will still work.

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