Subject: [Softwires] Yesterday's slides

From: Satoru Matsushima <[email-masked]>
Date: Thu, 28 Jul 2011 13:28:56 -0400

Hi, 

Could someone tell me where is Dave Thaler's slides?

Best regards,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 28 Jul 2011 16:21:32 -0400

Dave, thank you to share your slides.

--satoru
On 2011/07/28, at 15:45, Dave Thaler wrote:

> Attaching here since they don't seem to be posted yet.
> 
> -Dave
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Satoru Matsushima
>> Sent: Thursday, July 28, 2011 1:29 PM
>> To: [email-masked] list
>> Subject: [Softwires] Yesterday's slides
>> 
>> Hi,
>> 
>> _______________________________________________
>> Softwires mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/softwires
> 
> <Framing Discussion.pdf>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 28 Jul 2011 19:45:04 +0000

-Dave

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 11:41:46 +0200

Dear all,

Dave rightly expresses in the Softwire meeting the need to separate/clarify discussion about:
- Stateless vs stateful
– Static vs dynamic port sets

The need to clarify is IMHO even larger than that.

I therefore worked out a way to present the range of solutions to be compared, with the following taken in consideration:
- The stateless/stateful IPv4 across IPv6 comparison isn't limited to IPv4 shared addresses (applies also to exclusive IPv4 customer addresses).
- If there is, in BR/AFBR's, no Customer state (i.e. no states referring to individual IPv6 prefixes), there can't be per-transport-connection state either.
- CE-CE direct paths are possible only if IPv4/IPv6 mappings of BR/AFBR's don't depend on Customer state.

The proposed document structure is as follows, with pros and cons for each section:
a) Stateful per transport connection (and also stateful per customer IPv6 prefix)
   e.g. DS-lite with CGN
b) Stateful per customer IPv6 prefix (but Stateless per transport connection) 
   e.g. draft-cui-softwire-host-4over6-06
c) Stateless per customer IPv6 prefix (and also stateless per transport connection)
   - Hub-an-spoke    
     TBD
   - Direct CE-CE paths (mesh)
     . Encapsulation based 
       e.g. draft-murakami-softwire-4rd-00 alias
     . Translation based  
       e.g. draft-murakami-softwire-4v6-translation-00

Thoughts?

Regards,
RD

Le 28 juil. 2011 à 21:45, Dave Thaler a écrit :

> <Framing Discussion.pdf>_______________________________________________
> Softwires mailing list
> [email-masked]

---

From: GangChen <[email-masked]>
Date: Fri, 29 Jul 2011 23:18:43 +0800

Before making such comparison (of course it should be as fair as possible),
I think we need to state what solution space we are targeting and what
category mode we should take care.
If I understand correctly, I would paraphrase as following categories.

a) Stateful+Dynamic port sets: e.g. DS-Lite
b) Stateful+Static port set: e.g. draft-cui-softwire-host-4over6-06
c) Stateless + Static port set: e.g. 4rd, 4via6 translation
d) Stateless + Dynamic port set: ??(Any candidate solution?)

Gang

2011/7/29, Rémi Després <[email-masked]>:
> I therefore worked out a way to present the range of solutions to be
> compared, with the following taken in consideration:
> - The stateless/stateful IPv4 across IPv6 comparison isn't limited to IPv4
> shared addresses (applies also to exclusive IPv4 customer addresses).
> - If there is, in BR/AFBR's, no Customer state (i.e. no states referring to
> individual IPv6 prefixes), there can't be per-transport-connection state
> either.

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 17:58:20 +0200

> c) Stateless + Static port set: e.g. 4rd, 4via6 translation

OK so far, assuming that "stateful/stateless" implicitly means "Stateful/stateless concerning individual customers".

Note however that this isn't what stateful means _in general_, in particular in NAT discussions. 
The statefulness/statelessness we talk about should be expressed one way or another ("per customer" is a proposal to do that). 

> d) Stateless + Dynamic port set: ??(Any candidate solution?)

NOK for this one: if BR/AFTR's are stateless (i.e. have no per customer state) they can't manage dynamic port sets.
That's the point below, now preceded by an *.

The possible solution I mentioned is one where:
- like with 4rd and 4via6 Translation, BR/AFTR's are stateless per customer (and therefore also stateless per transport connection)
- unlike with 4rd and 4via6, CE-CE paths within the ISP network always via at least one BR (the hub and spoke topology) 
This hasn't been described yet, AFAIK, but can be simple variations of 4rd (i.e. 4via6 Encapsulation) and of 4via6 Translation.

Is that clearer?

Regards,
RD

>> shared addresses (applies also to exclusive IPv4 customer addresses).
*

---

From: "Peng Wu" <[email-masked]>
Date: Sat, 30 Jul 2011 21:26:38 +0800

Hi Gang,

>d) Stateless + Dynamic port set: ??(Any candidate solution?)

I would say that the last one makes no sense

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 30 Jul 2011 08:38:58 -0500

> I would say that the last one makes no sense

Agree. It is a problem space only on that logical frame.
I think that the analysis work doesn't need to insist necessity of unfeasible area solution.

cheers,
--satoru

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 30 Jul 2011 08:57:09 -0500

One clarification.

> d) Stateless + Dynamic port set: ??(Any candidate solution?)

AFAIK, the 'draft-cui-softwire-host-4over6' doesn't mention IPv4 address sharing. Is that correct?

cheers,
--satoru