Le 2012-11-30 14:09, mohamed.boucad...@orange.com 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
_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to