Subject: [Softwires] more charter bashing

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Sep 2005 12:13:05 +0300 (EEST)

More detailed comments on the proposed charter below.

In summary, I think the proposed charter is either too lean on details 
(if the goal is to make a focused charter and to define the scenarios 
before chartering), or rich on scenario assumptions and ambiguous 
wordings (if the goal is to develop the scenarios/PS after 
chartering).

Depending on the approach chosen (see separate thread on this), the 
charter should be more explicit of the scenarios and technology, or 
focus solely on the basics of defining what's needed to get the 
problem statement well under way.

>Some networks are mandated to be IPv4 or IPv6 only (e.g. due to 
>financial or political reasons); configured tunnels or 'softwires' 
>are suited for the inter-networking job.

==> "IPv4 or IPv6 only" lacks context.  If you read that with a strict 
interpretation, a network that is purely IPv4/IPv6-only cannot have 
any dual-stack nodes which would be needed to create the softwires 
(and the only solution at that point would be using edge-to-edge L2 
pseudowires).  So, I don't think this text is good as it is -- and it 
seems targeting mostly the intra-ISP case, which I do not (at this 
point) believe in.

Maybe just replace with something more generic, like,

"For various reasons, native IPv4 and/or IPv6 transport may not be 
available in all cases, and there is need to tunnel IPvX in IPvY to 
cross a part of the network which is not IPvX -capable."

(An alternative would be punting this here, and describing the 
scenarios at more length later in the charter -- which might be a good 
thing)

>Currently, a number of deployments have been undertaken using the 
>tunnel broker approach, RFC3053. However, as no tunneling 
>encapsulation or configuration protocol is specified in 3053, 
>interoperability and management of the softwires are a significant 
>burden. Other deployments use non-standardized, incomplete solutions.

==> as RFC3053 is an *Informational* RFC, and just a concept, I don't 
think the last sentence is correct.  It might be better to say that 
non-interoperable tunneling mechanisms have been developed based on 
the RFC3053 concept, and in addition, standardized mechanisms like 
trans-mech, RFC2473, GRE, L2TP, etc. have been used in some scenarios.

We also need to describe (or at least summarize, see the point about 
problem statement prior/after chartering) why the standardized 
mechanisms mentioned above are not sufficient.

>This protocol will be able to provide control aspects to negotiate 
>different softwire properties between a customer or network edge node 
>and the corresponding softwire end-point.

==> is the negotiation done inside the softwire, or prior to setting 
up the softwire?  In slightly different terms, can the negotiation 
happen between routers A and B while the softwire would be set up 
between C and D (or A and D)?  The charter seems too loose on this 
point, and this has significant architectural and technical 
implications.  I'd suggest restricting to the same peers that did the 
negotiation.  Either way, this needs to be explicitly spelled out in 
the charter.

>-          The IP addresses to use for the softwire end-points

==> it may not be required to have the softwire control protocol 
negotiate this.  It may be important to be able to automatically 
obtain IP addresses on top of the softwire.  This can be done both 
in-band and out-of-band, and I guess we're not yet deciding which one. 
So the list of characteristics should be reworded to make it clearer 
that all of these features might not require negotiation.

>-          A control mechanism for softwire setup, policy, 
>autodetection and reconciliation of mismatched parameters (such as 
>MTU, encapsulation, authentication, etc..)

==> I'm having trouble understanding this one.  This seems potentially 
overly generic goal which would lead to complexity (e.g., dynamic MTU 
detection before set-up).  I'd restrict to the very basic features, 
and explicitly spell out which they are -- or not say anything at 
all.

That is, I don't like giving a blanket statement that the protocol 
must include support for arbitrary kind of autodetection, policy, 
reconciliation, etc. capabilities when I have no idea what those mean 
and I have no scenario context to portray them against.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Softwires mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/softwires

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 08 Sep 2005 17:11:29 +0700

I think the IPv6 in IPv4 scenario is already described in several docs from
v6ops (unmanaged, ISP, enterprises, etc.). We can just put a reference or
copy/paste some text.

For the IPv4 in IPv6, a simple description of a specific (and actually real)
example will be something like:
A network doing the transition to IPv6 discovers that keeping dual stack in
the core, access and LAN's, is slightly more costly than keeping only IPv6
in the core or/and access, specially when most of the traffic is becoming
already IPv6-only (other reasons are possible). However in this
IPv6-dominant network, is still important for a few applications and for
ensuring the IPv4 communication with other IPv4 or dual-stack networks.
Consequently, the LANs and hosts are dual-stack (or some hosts which can't
be upgraded stay as IPv4-only). Consequently, there is a need for an
automatic tunneling mechanism which allows either a single hosts (only
possible if it is dual stack) or the border router in the LAN (must be dual
stack), to allow transporting IPv4 traffic in the IPv6-only core and/or
access infrastructure. The de-capsulation will be done either in another
host (must be dual stack) or in a router (dual stack) which is located in
the border between the IPv6-only infrastructure and a dual stack or
IPv4-only network.

This text can be slightly modified to be "generic" (IPvX in IPvY), but will
be more difficult to read probably.

Regards,
Jordi

> De: Pekka Savola <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 8 Sep 2005 12:13:05 +0300 (EEST)
> Para: "[email-masked]" <[email-masked]>
> Asunto: [Softwires] more charter bashing
> 

************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.