Le 29 juil. 2011 à 17:18, GangChen a écrit :
> 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
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
>
> Gang
>
>
> 2011/7/29, Rémi Després <[email protected]>:
>> 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 :
>>
>>> Attaching here since they don't seem to be posted yet.
>>>
>>> -Dave
>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:[email protected]] On
>>>> Behalf Of Satoru Matsushima
>>>> Sent: Thursday, July 28, 2011 1:29 PM
>>>> To: [email protected] list
>>>> Subject: [Softwires] Yesterday's slides
>>>>
>>>> Hi,
>>>>
>>>> Could someone tell me where is Dave Thaler's slides?
>>>>
>>>> Best regards,
>>>> --satoru
>>>> _______________________________________________
>>>> Softwires mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>> <Framing Discussion.pdf>_______________________________________________
>>> Softwires mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>
>>
>> _______________________________________________
>> Softwires mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
