Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

[Maoke <[e-mail]>]

dear Med,

thanks for the response. please see inline.

2012/11/30 <[e-mail]>

> **
> Dear Maoke,
>
> Thank you for the review and comments.
>
> Please see inline.
>
> Cheers,
> Med
>
>  ------------------------------
> *De :* Maoke [mailto:[e-mail]]
> *Envoyé :* vendredi 30 novembre 2012 03:31
> *À :* Suresh Krishnan
> *Cc :* BOUCADAIR Mohamed OLNC/OLN;
> draft-cui-softwire-b4-translated-ds-lite;
> [e-mail];
> [e-mail]; [e-mail];
> [e-mail]
> *Objet :* Re: [Softwires] Unified Softwire CPE:
> draft-bfmk-softwire-unified-cpe
>
>  thanks Med for the initialization of the work!
>
> i noticed that:
>
> 1. MAP is working in the context of prefix delegation and therefore the
> LAN side IPv6 addresses (prefix) is involved in the mapping between the
> IPv4 and IPv6, while lw4over6 applies the WAN IPv6 address directly. when a
> unified CPE is made, the logic of the address assignment to interfaces
> should also consider this difference in the behaviour.
> [Med] I'm not sure I understand your point. Could you please clarify
> further the difference between the stateless and binding mode and what you
> think it should be added to bullet (2.3.2) of Section 3.4? Thanks.
>
> [maoke] i a little doubt the binding mode is a proper way to unify the MAP
1:1 and lw4over6. because MAP 1:1 is still working in the model of
delegation while lw4over6 applies the WAN IPv6 address for the
encapsulation. what if the CPE has a delegated prefix at LAN and an address
at WAN simultaneously? which address is used for the source address of the
tunnel in the "binding mode"? is the CPE choice fits the reality at the
AFTR/BR? to my understanding, the behaviour of MAP 1:1 is identical with
any MAP but different from lw4over6 to some extent.

>
> 2. is the deployment of difference modes able to be overlapped? current
> section 4.4 implies the answer is "yes". i agree. but is it the best
> behaviour to select one mode at the device-wise according to a certain
> preferences? my question is: when the CPE receives multiple
> rules/parameter-sets from different sources of provisioning, can it store
> and use these pieces of information to adapt packets for corresponding mode
> of service, i.e., applying a proper mode on demand and session-specific?
> [Med] The current text says:
>
>    o  For a given network attachment, only one mode MUST be activated.
>
> [maoke ] why only ONE mode MUST be activated?

[maoke] we noticed a fact that a domain of softwire, at least MAP,  can be
different from the "domain" in the sense of autonomous system, because the
model of prefix delegation is totally independent of the deployment of the
softwire. this feature makes the softwire domain able to spread over
different AS. therefore it is possible that a CPE is involved in a AS's
lw4over6 domain and meanwhile also involved in a inter-AS MAP domain.
administration of the lw4over6 domain and that of the MAP domain are surely
independent to each other but they impact the CPE simultaneously -- it
could be treated as  a typical case of softwire multi-homing. and we expect
the CPE gets the benefits from the multi-homing: policy-based path
selection, load-balance, fault-tolerance, etc.

   o  The CPE MAY be configured by a user or via remote device
>       management means (e.g., DHCP, TR-069).
>    o  A network which supports one or several modes MUST return valid
>       configuration data allowing requesting devices to unambiguously
>       select a single mode to use for attachment.
>
> Does this text answer your questions? If not, what you think is needed to
> be added? Thanks.
>
>
> 3. related to 2, how can we keep the CPE/BR CPE/AFTR consistency?
>
> 4. fragmentation issue is common to all modes and it is also needed to be
> clarified/unified for the unified CPE.
> [Med] Fully agree. We preferred to focus first on the unified logic. If
> the WG accepts the proposed direction, then the document should be updated
> to cover items common to all modes.
>
> thanks,
- maoke

P.S. i will be in a  3-nights&2-days trip since tonight so any further
discussion will be responded in the beginning of next week. sorry in
advance for the delay.

>
> only my 2 cents, identifying the problems that i expect this draft to
> cover.
>
> - maoke
>
> 2012/11/29 Suresh Krishnan <[e-mail]>
>
>> Thanks Med. This is a highly exploratory draft to be used as a strawman
>> to determine if an unified CPE is even possible. Please comment on it so
>> that we can determine if proceeding in this path is worthwhile. Also, if
>> you are interested in being an editor of this draft and are not currently
>> working on any of the current solution drafts please contact the chairs.
>>
>> Thanks
>> Suresh
>>
>>
>> ----- Original Message -----
>> From: "[e-mail]" <[e-mail]>
>> To: "[e-mail]" <
>> [e-mail]>, "
>> [e-mail]" <
>> [e-mail]>, "
>> [e-mail]" <
>> [e-mail]>,
>> draft-cui-softwire-b4-translated-ds-lite <
>> [e-mail]>, "Reinaldo
>> Penno  (repenno)" <[e-mail]>, "[e-mail]" <
>> [e-mail]>
>> Sent: 11/29/2012 5:16 AM
>> Subject: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
>>
>>
>>
>> Dear all,
>>
>> As agreed in Atlanta, we prepared an I-D describing a proposed approach
>> for the unified CPE.
>>
>> We hope this version is a good starting point to have fruitful discussion.
>>
>> Your comments, suggestions and contributions are more than welcome.
>>
>> Cheers,
>> Med
>>
>>
>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]]
>> De la part de [e-mail]
>> Envoyé : jeudi 29 novembre 2012 10:57
>> À : [e-mail]
>> Objet : I-D Action: draft-bfmk-softwire-unified-cpe-00.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>
>>
>>         Title           : Unified Softwire CPE
>>         Author(s)       : Mohamed Boucadair
>>                           Ian Farrer
>>                           Suresh Krishnan
>>         Filename        : draft-bfmk-softwire-unified-cpe-00.txt
>>         Pages           : 12
>>         Date            : 2012-11-29
>>
>> Abstract:
>>    Transporting IPv4 packets over IPv6 is a common solution to the
>>    problem of IPv4 service continuity over IPv6-only provider networks.
>>    A number of differing functional approaches have been developed for
>>    this, each having their own specific characteristics.  As these
>>    approaches share a similar functional architecture and use the same
>>    data plane mechanisms, this memo describes a specification whereby a
>>    single CPE can interwork with all of the standardized and proposed
>>    approaches to providing encapsulated IPv4 in IPv6 services.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-bfmk-softwire-unified-cpe
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-00
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft<https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>directories:
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>> _______________________________________________
>> Softwires mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>>
>
>