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

[<[e-mail]>]

Re-,

 

>-----Message d'origine-----
>De : Simon Perreault [mailto:[e-mail]] 
>Envoyé : vendredi 30 novembre 2012 14:24
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [e-mail]
>Objet : Re: [Softwires] Unified Softwire CPE: 
>draft-bfmk-softwire-unified-cpe
>
>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

Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP.

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

Med: you need also MAP parameters (offset, EA-...).

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

Med: Isn't this covered by the combination of these two points: 

   o  A network which supports one or several modes MUST return valid
      configuration data allowing requesting devices to unambiguously
      select a single mode to use for attachment.

and

   (1)  If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE
        MUST be configured with the required provisioning information
        listed in Table 4.  If all of the required information is not
        available locally, the CPE MUST use available provisioning means
        (e.g., DHCP) to retrieve the missing configuration data.

If one mode is enabled, the CPE won't ask for more than what it needs. 
If its receives more, it will ignore them. I can add this to text if you think it is missing.