Subject: [Softwires] WG Review: Softwires (softwire)

From: The IESG <[email-masked]>
Date: Mon, 10 Oct 2005 11:39:06 -0400

A new IETF working group has been proposed in the Internet Area. The IESG has not 
made any determination as yet. The following draft charter was submitted, and is 
provided for informational purposes only. Please send your comments to the IESG 
mailing list ([email-masked]) by October 12.

+++

Softwires (softwire)
----------------------

Current Status: Proposed Working Group

Chairs:
TBD

Internet Area Directors:
Mark Townsley <[email-masked]>
Margaret Wasserman <[email-masked]>

Internet Area Advisor:
Mark Townsley <[email-masked]>

Technical Advisors:
TBD

Mailing Lists:
General Discussion: [email-masked]
Send mail to: [email-masked]
With a subject line: subscribe
Archive: ftp://ftp.ietf.org/ietf-mail-archive/softwires-wg

Description of Working Group:

The Softwires Working Group is specifying the standardization of discovery, 
control and encapsulation methods for connecting IPv4 networks across IPv6 networks,
IPv6 networks across IPv4 networks in a way that will encourage multiple, 
inter-operable vendor implementations. For various reasons (financial or political), 
native IPv4 and/or IPv6 transport may not be available in all cases, and there is 
need to tunnel IPv4 in IPv6 or IPv6 in IPv4 to cross a part of the network which 
is not IPv4 or IPv6 capable. Configured tunnels or softwires are suited for the 
inter-networking job. Non-interoperable tunneling mechanisms have been developed 
based on the RFC3053 tunnel broker concept, and in addition, standardized mechanisms 
like RFC2893, RFC2473, GRE, L2TP, etc. have been used in some scenarios. Other 
deployments use non-standardized, incomplete solutions. The lack of interoperable 
and/or standardized solution in that space has been noted in the v6ops WG scenario 
analysis.

The focus of this WG is to define a softwire setup negotiation protocol and 
encapsulation to be use between a node and the corresponding softwire end-point. 
Softwire configuration includes two phases: softwire end point discovery and 
softwire set-up. The WG will attempt to reuse existing technologies as much as 
possible and if necessary, create additional building blocks. It is expected that 
existing encapsulations will be the starting point.

In the softwire set-up phase, the initator and the ISP negotiate the parameters 
necessary to establish the softwire. Those include:

    - The encapsulation type: IPv4-over-IPv6 or IPv6-over-IPv4 with a possible 
intermediary layer (e.g. UDP). This encapsulation negotiation should be extensible 
to cover future methods of both unicast and multicast traffic.

    - How to obtain the IP addresses to use for the softwire end-points. This could 
be done with an out-of-band mechanism or directly negotiated at set-up phase.

In the softwire end point discovery phase, the initiator gets a name or an IP 
address for the ISP-side end point of the softwire to establish. This phase is 
orthogonal to the set-up one.

The initial milestone for this working group will be the set-up phase. This WG is 
not chartered to work on the discovery phase and a re-charter will be needed prior 
to undertaking such work; once the base work has been completed (or is well under 
way), WG may consider re-chartering to address discovery.

The WG will reuse existing technologies as much as possible and will create 
additional building blocks when necessary.

The WG is chartered to complete the following work items:

    1. Document problem statement and submit to IESG as Informational. If this 
problem statement cannot be written within the IETF process of rough concensus, 
then the following items will not be advanced.

    2. Document softwire encapsulation and control protocol usage for IPv4-over-IPv6 
or IPv6-over-IPv4 with possible intermediary layer and submit the specification to 
the IESG for publication as a Proposed Standard.

    3. Develop the softwire MIB module and submit it to the IESG for publication 
as a Proposed Standard.

Goals and Milestones:
Jan 06 Submit a problem statement to the IESG to be considered as an Informational 
RFC

Jul 06 Submit softwire encapsulation and control protocol to the IESG to be 
considered as a Proposed Standard

Oct 06 Submit softwires MIB to the IESG to be considered as Proposed Standard 

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

---

From: Tim Chown <[email-masked]>
Date: Tue, 11 Oct 2005 08:52:33 +0100

Hi,

I think the timing here is unfortunate.   There is a softwires 'BoF' meeting
today and tomorrow in Paris in which the charter is subject to some 'bashing'.

If there is a plan to get the WG chartered in time for Vancouver, then it
may be prudent to recirculate the charter later this week for comment, after
the meeting concludes, if the current chairs can provide the updated text.

Tim

-- 
Tim/::1

---

From: Pekka Savola <[email-masked]>
Date: Tue, 11 Oct 2005 11:04:19 +0300 (EEST)

> encapsulation to be use between a node and the corresponding softwire end-point.

'a node' seems too generic.

Previously this was 'a customer (or network edge) node' with a 
suggestion to change that to 'a customer premises node'.

IMHO, making such a restriction in the charter would be useful because 
otherwise the scope for the creation of the problem statement will be 
much wider.  We really don't know anything about the generic case 
(e.g., on-demand tunnels between routers inside an ISP's backbone) 
while there's plenty of operational and implementation experience of 
ISP-customer tunnels. Thus, IMHO, it's easiest and safest to just 
focus on the ISP-customer scenario.

There are well enough ratholes to go into without introducing this
genericity of the problem scope to the charter and the resulting
problem statement effort.

-- 
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: Mark Townsley <[email-masked]>
Date: Thu, 13 Oct 2005 16:41:40 +0200

>the meeting concludes, if the current chairs can provide the updated text.
We did not touch or address the charter directly in Paris this week. We 
focused instead on the first deliverable, defining the scoped problem 
statement that will be solved. A lot of progress was made, which will be 
submitted for review to the list soon (Spencer took what I suspect will 
be his usual very good minutes, and editors have been designated to 
produce a -00 by cutoff on Monday).

To me, this is a sign that the group is working, rather than Bof-ing. As 
such, I would like to focus on approving *this* charter for Vancouver 
rather than revising it yet again.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Oct 2005 16:47:26 +0200

> (e.g., on-demand tunnels between routers inside an ISP's backbone) 

Actually, we do. That was made pretty clear at the interim meeting, and 
falls within at least two service provider scenerios represented at the 
interim and at the BoF in Paris last August.

> focus on the ISP-customer scenario.

Based on what I saw in Paris this week, I think this would be unfortunate.

- Mark

---

From: Tim Chown <[email-masked]>
Date: Thu, 13 Oct 2005 16:16:23 +0100

> Based on what I saw in Paris this week, I think this would be unfortunate.

Hi MArk,

If we can get a -00 on the table, great.

What I hope is that this -00 and the charter are not so set in stone as
those who were unable to make the Paris meeting cannot still at least
have some input to shape that.

I guess this is why normally such meetings can't be held within 30 days
of IETF cutoff and thus I-D cutoff - I don't envy the task of making a
good stab at a -00 by Monday :)

-- 
Tim/::1

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Oct 2005 17:57:13 +0200

>have some input to shape that.
The -00 is not in stone at all. It's a first cut, and being brought to 
the wider community ASAP. The charter was not discussed directly at the 
meeting, it never appeared on a slide in any form. The group worked on 
the problem statement.

Depending on where you draw the line, this could be incorporated into 
the charter, or stay within the problem statement. Either way, the 
problem statement must be finished before we make any decisions on 
solutions (as is stated in the current proposed charter).

>good stab at a -00 by Monday :)
It will be tough, but that was what they promised (after much good wine 
the night before, perhaps that had something to do with it).

The timing of this interim was admittedly difficult. We had a shorter 
amount of time between IETF meetings than is typical, and had the 
European August holiday month as well which certainly affected my 
attention to the scheduling.

- Mark

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Oct 2005 21:28:09 +0300 (EEST)

On Thu, 13 Oct 2005, Mark Townsley wrote:
>> Previously this was 'a customer (or network edge) node' with a suggestion 
>> to change that to 'a customer premises node'.
>> 
>> otherwise the scope for the creation of the problem statement will be much 
>> wider.  We really don't know anything about the generic case (e.g., 
>> on-demand tunnels between routers inside an ISP's backbone) 
>
> Actually, we do. That was made pretty clear at the interim meeting, and falls 
> within at least two service provider scenerios represented at the interim and 
> at the BoF in Paris last August.

A lot of things can be represented, but whether or not they are 
sufficiently well justified is another issue.  That justification 
certainly didn't seem to come up clearly enough in Paris, not sure 
about the interim meeting as I wasn't there.

So..

If someone wants to build a v6-only network ('isp') while the 
customers can be v4/v6 dual stack, that's fine.  But by definition, 
having v6-only network rules out any L3 v4-in-v6 tunneling in that 
network.

If the network ('ISP') wanted to participate in linking the customers 
using tunnels, all you have left is layer 2 tunneling (VPLS is the 
best candidate I guess) which is out of scope of softwires.

Or if the customers set up the tunnels themselves, ISP), that's no 
longer an "intra-ISP" case.

---

From: David Ward <[email-masked]>
Date: Thu, 13 Oct 2005 14:02:09 -0500

Pekka -

    The scenario described by Xing Li in Paris and at the interim meeting
isn't what you are summarizing below. I will post the interim meeting
minutes and preso's in just a moment.

-DWard

---

From: Mark Townsley <[email-masked]>
Date: Thu, 13 Oct 2005 21:08:08 +0200

> having v6-only network rules out any L3 v4-in-v6 tunneling in that 

I do not see how a v6-only network rules out L3 v4-in-v6 tunneling, if 
you want to use that v6-only network for transit service of v4. This is 
the problem presented by CERNET, echoed by Jordi, and if memory serves a 
few others at the mic in Paris.

> best candidate I guess) which is out of scope of softwires.

VPLS may very well be a solution, there may be others. In any case, we 
are focusing on the problems here, not the solutions at this point.

- Mark

---

From: Pekka Savola <[email-masked]>
Date: Fri, 14 Oct 2005 08:10:06 +0300 (EEST)

On Thu, 13 Oct 2005, Mark Townsley wrote:
>> If someone wants to build a v6-only network ('isp') while the customers can 
>> be v4/v6 dual stack, that's fine.  But by definition, having v6-only 
>> network rules out any L3 v4-in-v6 tunneling in that network.
>
> I do not see how a v6-only network rules out L3 v4-in-v6 tunneling, if you 
> want to use that v6-only network for transit service of v4. This is the 
> problem presented by CERNET, echoed by Jordi, and if memory serves a few 
> others at the mic in Paris.

Could you give an example how you can configure an IPv6-only PE router 
to do layer3 tunneling of v4 packets received from customer's 
interface (e.g., using manually configured [RFC2893] tunnels)? (A 
cisco example would be fine.)

To me it seems that the PE router needs to be dual-stack to process 
and forward the incoming v4 packets to the appropriate tunnel (if you
  do layer 3 tunneling, that is).  But I may be missing something, so 
I'd appreciate an example.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 14 Oct 2005 10:06:50 +0200

> I'd appreciate an example.
Yes, (using L3VPN terminology) to tunnel at L3 the PE router needs to be 
dual stack. The P routers do not (they constitute the strict "ipv6-only" 
part of the network). Perhaps we were simply missing one another on 
where the "edge" line was being drawn.

- Mark

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Oct 2005 11:53:43 +0300 (EEST)

Following up on this after having read the interim minutes and presos,

On Fri, 14 Oct 2005, Mark Townsley wrote:
> Pekka Savola wrote:
>> To me it seems that the PE router needs to be dual-stack to process and 
>> forward the incoming v4 packets to the appropriate tunnel (if you
>>  do layer 3 tunneling, that is).  But I may be missing something, so I'd 
>> appreciate an example.
>> 
> Yes, (using L3VPN terminology) to tunnel at L3 the PE router needs to be dual 
> stack. The P routers do not (they constitute the strict "ipv6-only" part of 
> the network). Perhaps we were simply missing one another on where the "edge" 
> line was being drawn.

My impression of the CERNET presentation is that they have no 'P' 
routers at all -- about all the 19 backbone routers are also PE 
(connecting an access network).

So, the question is, who controls the access network?  Are those local 
universities (or whatever), locally administered networks, or what? 
(I'm assuming access networks are separate.)

My reaction here is that the "mesh" problem should be handled either 
at layer 2 by the ISP or at layer 3 by the customer organizations. It 
seems this mesh problem is something that should be kicked over to 
L2VPN and L3VPN WGs.

(One note on the ephemeral part of the problem: if the tunnels are not 
pre-set-up, there are problems w/ hardware implementations similar to 
running ARP.  All the packets sent while the on-demand 'adjacency' is 
being brough up are discarded.)

---

From: Xing Li <[email-masked]>
Date: Mon, 24 Oct 2005 19:19:19 +0800

hi, all,

> (connecting an access network).

currently, there is no pure P routers in CERNET2. but in the near
future, 
there will be pure P routers and separate PE routers.

> (I'm assuming access networks are separate.)

PE routers are peering with the routers of the access network via BGP or
static/default routes. the backbone and access network are in different
administrative domain.

> seems this mesh problem is something that should be kicked over to

CERNET2 needs pure IPv6 in the P routers, dual-stack in the PE routers
and PE router peering with IPv4 access networks via BGP or 
static/default routes.  we believe mesh problem is in this scope.

> being brough up are discarded.)

if anyone need more clarification, please let us know.

regards,

xing
cernet2

---

From: Pekka Savola <[email-masked]>
Date: Mon, 24 Oct 2005 14:28:06 +0300 (EEST)

On Mon, 24 Oct 2005, Xing Li wrote:
> future, there will be pure P routers and separate PE routers.

Could you clarify the expected number of the PE and P routers, 
respectively?

> static/default routes. the backbone and access network are in different

Thanks.  How many CPE routers do you have (e.g., static route/BGP 
next-hops)?  I.e., I'd like to get a feel on the number of N (if the 
mesh would be between the CPE routers, not PE routers)?

> static/default routes.  we believe mesh problem is in this scope.

No doubt this is a problem; to me it's not just yet clear, whether it 
is a problem which this BOF/WG should solve, or whether it has been 
already solved (e.g., in L2VPN or L3VPN WGs).

---

From: David Ward <[email-masked]>
Date: Mon, 24 Oct 2005 11:12:57 -0500

All -

Note that what hasn't been resolved in L-N-VPN is IPvX over IPvY. Iff we
choose to reuse similar technology that has been developed there (check out
Simon's preso's if you haven't already) we will work w/ those groups. Also
there are some comments on scaling in the notes.

That all being said, if we can fully articulate the problem and find
existing technology that solves it, we will do the work in the right WG.
Since we aren't there yet (noone else has articulated or worked on the
problem), I prefer to keep working on fully documenting the problem and then
look at possible solutions.  Pushing it out at this point seems premature.

Thanks

-DWard

---

From: Xing Li <[email-masked]>
Date: Tue, 25 Oct 2005 13:43:47 +0800

> Could you clarify the expected number of the PE and P routers,

PE = 30
P  = 10

> mesh would be between the CPE routers, not PE routers)?

CPE = 150+

> already solved (e.g., in L2VPN or L3VPN WGs).

Thanks.

xing