Subject: [Softwires] Problem Statement draft

From: "Durand, Alain" <[email-masked]>
Date: Mon, 24 Oct 2005 15:24:32 -0400

I don't know if the problem statement draft had been publish yet or not,
in any case, here is a link to it:

http://bgp.nu/~dward/softwires/draft-durand-so&tatement-00.txt

    - Alain.

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 25 Oct 2005 12:58:35 +0300 (EEST)

> in any case, here is a link to it:

Yes, it has been.

A few quick comments below.  I think the 'hub and spoke' problem can 
be reasonably well justified as indeed folks have talked about it a 
LOT during the past 5 years or more.

On the other hand, the case for 'mesh' problem is smaller.  I cannot 
see the justification for running v6-only core (for example) just so 
you can make 10 P routers v6-only, when you already have to handle v4 
addressing, routing, etc. for 20 PE routers!

It would make much more sense if none of the PE routers would need to 
support v4 or v4 would only need to be supported in up to 2 routers 
(solely for v4 peering and upstream connectivity plus tunnel 
demarcation for customers).

....

  - the editorial quality is not very good (full of typos etc.). 
Some of the subsections also defined requirements while others 
describe the scenarios.  It may or may not make sense to try to 
separate hese.

3.8.  Scaling

    In a hub and spoke model, an ISP MUST scale the solution to millions
    of softwire inititators by adding more hubs (i.e. softwire
    concentrator).

==> s/MUST scale/must be able to scale/

    - End-point failure detection (must be encapsulated w/in the tunnel
    in the transmitting direction

==> please clarify what you mean after '(', it's not clear.

    User Authentication

==> is authentication of the server a requirement or non-requirement 
(it'd be good to clarify this as this has often been raised when 
thinking about the auth mechanism)?

     Reference Diagram

                     ._._._._              ._._._._
                    |        |            |        |
                    |  V4    |            |  V4    |
                    |access  |            |access  |
                    |island  |            |island  |
                     ._._._._              ._._._._

==> I don't think this was the case we were talking about.  Shouldn't 
all the islands be dual-stack?  This is pretty important consideration 
-- the key point emerges when an island with protocol X would like 
talk to an island with protocol Y. (where an island could be the rest 
of the internet as well).

    The AFBR's are the only devices in the network that must be able to
    perform dual-stack operations and setup and encapsulate softwires in
    a mesh to the other islands.

==> s/network/ISP's network/ -- the CPEs should obviously be 
dual-stack, right, so those could set up tunnels if they wished to.

   It should be noted that according to reports the islands do not want
    to achieve network connectivity via tunneled Layer 2 mechanisms but,
    as distinct Layer 3 or MPLS routers.  This clearly helps scaling and
    Layer 2 discovery performance issues.

==> it isn't clear enough what this point means.

4.4.  Persistence, Discovery and Setup Time

    Discovery of the AFBRs and softwire encapsulation can be accomplished
    by the routing protocol (e.g.  BGP) during capability advertisement.
    Or, the endpoints can be passed in new data formats or attributes,
    yet to be defined.  The duration of the softwire for inter-island
    reachability is considered to be as long as the BGP peering session.
    Thus, dynamicity is very low.  The setup time should be on the order
    of the same duration to setup L3VPNs.

==> the first sentences in particular seem like solutionism, reword?
==> is it a requirement that islands must run BGP -- the document 
seems to assume so?

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

---

From: Xing Li <[email-masked]>
Date: Wed, 26 Oct 2005 15:42:42 +0800

hi, all,

> demarcation for customers).

the reasons of the mesh model are:

(1) other CNGI backbones may have more pure IPv6 P routers and less
    dual stack PE routers. this model may also apply to other developing 
    countries, they likely deploy IPv6 backbones, support many IPv6
    access networks and limited IPv4 access networks.
(2) the transition from IPv4 to IPv6 is happening, but the it may
    take many years. it may exist a state that many IPv6 access networks
    and several IPv4 access networks exist. in this case, not all the PE
routers need
    IPv4 support, but the number of access networks are still more then
what setting
    IPv4 tunnels between the access network can handle. 

xing

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Oct 2005 12:29:34 +0300 (EEST)

On Wed, 26 Oct 2005, Xing Li wrote:
>    and several IPv4 access networks exist. in this case, not all the PE routers need

To me, this seems even a stronger reason (from the ISP) to strive for 
a design which would not require having v4 support on PE routers just 
to support a v4 access router, right?

Not sure how feasible this would be, but L2 tunneling seems to be an 
already widely deployed solution in this space.

---

From: Xing Li <[email-masked]>
Date: Wed, 26 Oct 2005 18:51:14 +0800

> to support a v4 access router, right?

sorry, this is not the case. 

(1) the number of access routers may be large
(2) the ISP can get more profit, when they provide the dual stack
service
    whenever it is necessary, rather than give the problem to the access
networks.

xing

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 26 Oct 2005 07:17:08 -0700

Pekka Savola wrote:

> On the other hand, the case for 'mesh' problem is smaller.  I cannot see 
> the justification for running v6-only core (for example) just so you can 
> make 10 P routers v6-only, when you already have to handle v4 
> (solely for v4 peering and upstream connectivity plus tunnel demarcation 
> for customers).

Pekka,

you seem to be saying that if you had the task to design this network, 
you would have designed it differently (based on, in your opinion, good 
reasons).
But I don't see what this has to do with
  - understanding the stated problem is
  - deciding whether softwires should try to address it

It's a well known ;-) fact that if you ask 10 engineers to design a 
network you come up with at least 11 different designs, all based on 
their different experiences and biases.

Here we have a network with a particular design, and there might be good 
reasons for some engineers to design other networks that way.
You might disagree with those reasons, and might feel that other 
considerations should be given more weight in the network design.

But I don't see how that helps us decide whether or not softwires should 
try to come up with a solution for those types of networks.

    Erik

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Oct 2005 22:11:36 +0300 (EEST)

On Wed, 26 Oct 2005, Erik Nordmark wrote:
> you seem to be saying that if you had the task to design this network, you 
> would have designed it differently (based on, in your opinion, good reasons).
...
> considerations should be given more weight in the network design.

Understanding why such and such a design was made helps in figuring 
out which problems we want to describe (and address).

Certainly, we could describe 10+ different problem statements in the 
softwire problem space.  Is it worth it?  Probably not; that's why 
we'll have to stick to a smaller number.  Those problem statements 
should likely be decided based on, for example:

  - how general they are (i.e., how many different kinds of problems
    they'd be solving) both by themselves and together
  - how widely deployed they are, or would be [importance, relevance]
  - an estimate on the difficulty of figuring a solution, either
     a) which already exists, or
     b) could be defined, implemented, etc.

In this particular instance: given that there is desire to build 
v6-only or v6-dominant networks, I'd expect that being able (but not 
required) to minimize the amount of v4 components in such a system is 
important.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 26 Oct 2005 22:18:49 +0300 (EEST)

>    whenever it is necessary, rather than give the problem to the access

I think you misunderstood my point because I didn't clearly define 
'access router'.  There seem to be basically three ways (AFAICS) in 
this kind of scenario:

  a) meshes between CPE devices, with little/no involvement from ISP
  b) meshes between PE devices, but requiring that PE devices support
     both v4 and v6 ("layer 3 tunneling")
  c) meshes between PE devices without requiring v4 support
     ("layer 2 tunneling")

While I think a) might be better, there may be business model and 
other issues with it as you note above; this certainly has been seen 
in the LxVPN WGs.

But both in b) and c), the ISP is seriously involved -- I don't see 
how these approaches would be different -- except b) requires each PE 
router connecting a v4 customer must be dual-stack and c) doesn't.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 27 Oct 2005 14:32:55 -0700

A couple of days before the published version was sent to the secretariat,
I've provided lots of inputs to the version that was circulated among the
co-authors, but now looking into this version, feel that most of them have
not been considered. So in order to provocate some discussion and also see
the feeling from others, here are my comments (R/ for replace suggestion,
original text indented, rest my own inputs).

Also, I did a nice picture trying to show all the possibilities, but
according to Alain is too much complicate, when actually I want to make in
order to make sure that all the choices are covered:

                              IPv6/IPv4
                                Host
                                (  )
                               (    )
                              ( IPv4 )
                               (    )
                                (  )
                           (w/ or w/o NAT)
                     (-----------------------)
                    (                         )
                   (                           )
     IPv6/IPv4    (          Internet           )    IPv6/IPv4
        Host       (                           )       Host
        ()          (                         )         ()
       (  )          (_______________________)         (  )
      (    )          (   )            (    )         (    )
     ( IPv4 )        (     )          (      )       ( IPv6 )
      (    )       (IPv6/IPv4)       (IPv6/IPv4)      (    )
       (  )          (     )           (    )          (  )
        ()            (   )             (  )            ()
  (w/ or w/o NAT)      TEP              TEP             ()
   (------------------------)        (------------------------)
  (                          )      (                          )
 (                            )    (                            )
(           IPv4-only          )  (           IPv6-only          )
 (           Network          )    (           Network          )
  (                          )      (                          )
   (________________________)        (________________________)
      ()              ()               ()              ()
     (  )            (  )             (  )            (  )
    (    )          (    )           (    )          (    )
   ( IPv4 )        ( IPv4 )         ( IPv6 )        ( IPv6 )
    (    )          (    )           (    )          (    )
     (  )            (  )             (  )            (  )
      ()              ()               ()              ()
     NAT         IPv6/IPv4 CPE    IPv6/IPv4 CPE   IPv6-only CPE
   (-----)         (-----)          (-----)         (-----)
  (       )       (       )        (       )       (       )
 (         )     (         )      (         )     (         )
( IPv4-only )   ( IPv6/IPv4 )    ( IPv6/IPv4 )   ( IPv6-only )
 ( Network )     ( Network )      ( Network )     ( Network )
  (       )       (       )        (       )       (       )
   (_____)         (_____)          (_____)         (_____)
  IPv6/IPv4       IPv6/IPv4        IPv6/IPv4       IPv6/IPv4
     Host            Host             Host           Host

2.  Introduction

   networks across IPv6 networks, IPv6 networks across IPv4 networks in

R/networks across IPv6-only networks and IPv6 networks across IPv4-only
networks in

   This document describes two fundamentals scenarios that the softwire

R/This document describes two fundamental scenarios that the softwire

   solution elements will be the same for both scenarios, but not all.

R/solution elements could be the same for both scenarios, but not
necessarily all.

   are to be used in IP based networks to forward both unicast and
   multicast trafic.  They are also assumed to be non-ephemeral in
   nature thus, they are peristent or long-lived.  Last, the setup time
   of a softwire is expected to have to be a very small fraction of the
   total time of the CPE/Address Family Boundry Router (AFBR)

R/is to be used in IP based networks to forward both unicast and multicast
traffic.  They are also assumed to be non-ephemeral in nature thus, they are
persistent or long-lived.  Last, the setup time of a softwire is expected to
have to be a very small fraction of the total time of the CPE/Address Family
Boundary Router (AFBR)

New text:
One more final consideration is the assumption that the nodes (hosts,
routers), using the softwires solution ("the softwires initiator device")
should support dual-stack (IPv4 and IPv6). Typically the Local Area Networks
will be in fact dual-stack in order to support the coexistence of
applications which are IPv4-only, IPv6-only and IPv4/IPv6 aware.

3.  Hubs and Spokes Problem

   The "Hubs and Spokes" problem in named in reference to the airline
   industry where major companies have establised a relatively small

R/The "Hubs and Spokes" problem is named in reference to the airline
industry where major companies have established a relatively small

3.1.  Description

   In this scenario, ISPs (or large enterprise networks acting as ISP
   for their internal resources) establish a dual stack core (either
   natively or by running tunnels, potentially managed by softwires in a
   "Mesh" scenario) and a number of dual stack Points of Presence (POP)
   where they connect their customers.  However, one or two things may
   happen:

I'm not sure about this one. If the core is native for both AFs, then could
seem that we don't have the problem, so I will change a bit the wording to
make it more evident. So here is complete new text for all the section 3.1
(description):

In this scenario, ISPs (or large enterprise networks acting as ISP for their
internal resources) have an infrastructure which in one or several parts
(core, access, CPE device) is only aware of a single address family (IPv4 or
IPv6). However, in order to support applications running the other address
family (i.e., if the infrastructure is IPv4-only, IPv6 applications, or if
the infrastructure is IPv6-only, IPv4 applications), it is necessary to
establish a virtual dual-stack infrastructure (end-to-end), typically by
means of tunnels automatically setup (softwires intend).

The reason for running a single address family in one or several parts of
this infrastructure could be on purpose (i.e., traffic on the network is
dominant in one of the address families, intend to lower O&M cost, etc.) or
because one or more devices are not able to support the both address
families.

The issues which do not allow running both address families may be:

a) Any of the devices (typically routers, but may be other POP or
aggregation points equipment, such as those depending on the access media
specifics) being used across the infrastructure (core, access) supports only
one address family.
Typically the reason for this is the lack of vendor support for one of the
address families, the (perceived) cost of upgrading them, complexity of
running both address families natively, O&M reasons to avoid upgrading them
(perhaps temporarily), non-technical reasons (such as small amount or
non-significant traffic enough with the non-supported address family to be
commercially meaningful), etc.

b) The CPE device (typically a router or a device behaving as such), can not
be easily upgraded to support both address families.
Typically the reason for this is the lack of vendor support for one of the
address families, commercial or operational reasons for not doing the
upgrade (i.e., operational changes and/or cost may need to be supported by
the ISP for all the customers, which can turn into millions of units),
customers reluctance to change/upgrade their CPE device (cost, "work, so not
change it", ), etc..

* I will not use CPE router, as it can be something different (even if is a
router), such as a home gateway, STB, cable modem, etc., so speaking about
CPE device seems to me more "terminology neutral".

3.2.  NAT

I would rename the section 3.2. from NAT to "CPE device dependencies" (or
"CPE device considerations"). Then I will change the text on that section
to:

In the case the CPE device supports only one address family (typically IPv4
with NAT), a softwire will have to be established by a node located behind
that CPE device.
This can be accomplished either by:
a) A regular PC in the home running some ad-hoc softwires software.
b) Dedicated piece of hardware acting as the "IPv6 router", running
softwires software.
c) Running sofwires in several devices behind the CPE device, but clearly is
not an optimal solution as it could mean that local IPv6 traffic travels via
the softwire tunnels instead of being kept locally.

The considerations are similar if the CPE device supports only IPv6.

Such a device indicated in case b), may be fairly simple in design and only
requires one physical network interface.

If the address family supported by the CPE router is IPv4, it is very common
that this device is performing NAT, so the softwires solution would have to
support NAT traversal.

It could happen that the NAT is not in the CPE device, but in the equipment
located at the other end of the access link (typically in the ISP POP), but
the same consideration will apply here, regarding the need to support NAT
traversal.

3.3.  Static Prefix Delegation

New text (at the end of the existing one):
Similarly, in the case of an IPv4 softwire, the address could be provided by
means of DHCP.

* I'm not sure "concentrator" is the best wording. I think TEP (Tunnel End
Point) is a very common terminology, and no reason for invent something new,
so I would change the title to "Softwire TEP"

3.4.  Softwire TEP or Concentrator

   On the ISP side, softwires are termintated on a softwire
   contentrator.  An ISP may deploy several concentrators (for example
   one per POP) for scaling reasons.  A concentrator is in practice a
   dual stack router connected to the dual stack core ISP
   infrastructure.

R/On the ISP side, softwires are terminated on a softwire TEP (Tunnel End
Point) or concentrator.  An ISP may deploy several TEPs or concentrators
(for example one per POP) for scalability reasons.  A TEP or concentrator is
in practice a dual-stack router connected to the dual-stack core of the ISP
or directly to the upstream providers.
It may be the case that one of the address families is not natively
supported, even if this is not optimal, in the TEP or concentrator, but
instead by means of tunnels to the upstreams (or other networks). This is
out of the scope of softwires, but must be supported transparently.

3.6.  Scaling

   In a hub and spoke model, an ISP could scale the solution to millions
   of customers by adding more hubs (i.e. softwire concentrator).  DNS
   redirection, local anycast addresses couple with the to be determined
   softwire concentrator discovery solution will enable sharing the load
   among concentrators.

R/In a hub and spoke model, an ISP could scale the solution to millions of
customers by adding more hubs (i.e. softwire TEP or concentrator).  DNS
redirection and/or local anycast addresses among other choices, coupled with
the to be determined softwire concentrator discovery solution will enable
sharing the load among TEPs or concentrators.

* To avoid confusions with the "migration" terminology that some people uses
instead of transition for IPv4-to-IPv6, I will prefer to use "Softwire
Initiator Considerations".

3.7.  Softwire Initiator Considerations

   The node hosting the end of the softwire within the customer network
   is called the softwire initiator.  As noticed earlier, this can be
   the CPE access router, another dedicated CPE router behind the CPE
   access router or simply a host.

R/The node hosting the end of the softwire within the customer network is
called the softwire initiator.  As noticed earlier, this can be the CPE
access device, another dedicated CPE device behind the original CPE access
device or simply any kind of node (host, appliance, sensor, etc.).

   The softwire initiator doee not have to be always the same node
   and/or always have the same IP address.  In particular, in the road
   warrior case, the softwire initiator could be roaming from one place
   to another, potentially outside its original ISP network.

R/ The softwire initiator does not have to be always the same node and/or
always have the same IP address.  In particular, in the road warrior case,
the softwire initiator could be roaming from one place to another,
potentially outside its original ISP network, so nomadicity should be
supported.

3.10.  Security

   In the control plane, the softwire solution has to support
   authentication, but an ISP may decide to turn it off in some
   circumstances.

R/In the control plane, the softwire solution has to support authentication,
but an ISP may decide to turn it off in some circumstances, for instance,
when the user is already authenticated by some other means, such close
networks, 3GPP networks, PLC, etc., in order to avoid unnecessary overhead.

3.11.  OAM

   In the case the softwire has to go accross a NAT, it will have to use
   a keepalive mechanism.  However such a mechanism will consume
   unnecessary bandwidth in the case there is no NAT, so a NAT detection
   solution is needed.

New text:
The keepalive mechanism could be disabled in some circumstances (i.e.,
narrowband access, billing per traffic, etc.), or the periodicity modified
to a minimum.

3.12.  Encapsulations

   IPv6/IPv4, IPv6/UDP/IPV4 and IPv4/IPv6 are on the critical path for
   softwires.  Other encapsulations, like IPv4/IPv4, are nice to have
   but not on the critical path.

I think it was clear, at least for me, that it will become more important
IPv6/IPv6 than IPv4/IPv4, so if we mention one of the non-critical path
examples, should be that one ;-)

R/IPv6/IPv4, IPv6/UDP/IPV4 and IPv4/IPv6 are on the critical path for
softwires.  Other encapsulations, like IPv6/IPv6, are nice to have but not
on the critical path.

Regards,
Jordi

> De: "Durand, Alain" <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 24 Oct 2005 15:24:32 -0400
> Para: <[email-masked]>
> Conversación: Problem Statement draft
> Asunto: [Softwires] Problem Statement draft
> 

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

---

From: Xing Li <[email-masked]>
Date: Fri, 28 Oct 2005 18:26:14 +0800

> >    whenever it is necessary, rather than give the problem to the access

thanks for the clarification.

>   c) meshes between PE devices without requiring v4 support

agree. above is a good summary.

> other issues with it as you note above; this certainly has been seen

we choose b), since it reflects a good business model for ISP. 

> router connecting a v4 customer must be dual-stack and c) doesn't.

for c) it can solve the problem, but we feel 

(1) if it is point to point layer 2, then it is similar to hub and
spoke, and scalability may be a problem.
(2) if it is multple-point to multiple-point layer 2, the broadcast
storm may be a problem.

therefore, we believe b) could be feasible solution.

thanks for your comments.

xing