Subject: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02

From: Suresh Krishnan <[email-masked]>
Date: Tue, 5 Feb 2013 00:29:07 -0500

Hi all,
  This draft was a result of the discussion initiated at the softwire
meeting in Atlanta to attempt to come up with a unified CPE
specification that can work with both MAP and lw4o6. This call is being
initiated to determine whether there is WG consensus towards adoption of
draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state
whether or not you're in favor of the adoption by replying to this
email. If you are not in favor, please also state your objections in
your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong

---

From: Maoke <[email-masked]>
Date: Tue, 5 Feb 2013 14:54:42 +0900

hi Suresh and all,

personally i think this work is still premature for the WG adoption.
reasons are below:

1. current draft makes a logic for the CPE to decide its mode according to
what information it received from DHCP options. however, DHCP options are
not the only available provision mean. what if my CPE get MAP information
through DHCP, while lw4over6 information from PCP, while another MAP
domain's provision through manually configuration? when such kind of basic
questions not yet fully discussed, i doubt it is suitable to adopt this
work at so early stage.

2. some important issues are not yet comprehensively discussed, or almost
missing, in the current draft. e.g. (but not limited to),
    - what is the correct NAPT source port overlapping behaviour for the
unified CPE?
    - what is the correct fragment/reassemble behaviour for the unified
CPE?

as currently there is no MAP members joins this draft, i am worrying that
the draft has fully reflected the concern from the MAP side.

thanks and regards,
maoke

2013/2/5 Suresh Krishnan <[email-masked]>

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

---

From: <[email-masked]>
Date: Tue, 5 Feb 2013 09:55:43 +0100

I see a useful work here that brings together the different Softwire approaches under a unified CPE and would that's why vote for an adoption as WG working item.

Kind regards

Olaf 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Suresh Krishnan
Gesendet: Dienstag, 5. Februar 2013 06:29
An: Softwires WG
Cc: Yong Cui; Ralph Droms
Betreff: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02

Hi all,
  This draft was a result of the discussion initiated at the softwire meeting in Atlanta to attempt to come up with a unified CPE specification that can work with both MAP and lw4o6. This call is being initiated to determine whether there is WG consensus towards adoption of
draft-bfmk-softwire-unified-cpe-02 as a softwire WG draft. Please state whether or not you're in favor of the adoption by replying to this email. If you are not in favor, please also state your objections in your response. This adoption call will complete on 2013-02-18.

Regards
Suresh & Yong

---

From: <[email-masked]>
Date: Tue, 5 Feb 2013 09:57:38 +0100

Hi Maoke,

Thanks for your response. Comments inline.

Cheers,
Ian

From: Maoke <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, 5 February 2013 06:54
To: Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Cc: Softwires WG <[email-masked]<mailto:[email-masked]>>, Yong Cui <[email-masked]<mailto:[email-masked]>>, Ralph Droms <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02

hi Suresh and all,

personally i think this work is still premature for the WG adoption. reasons are below:

1. current draft makes a logic for the CPE to decide its mode according to what information it received from DHCP options. however, DHCP options are not the only available provision mean. what if my CPE get MAP information through DHCP, while lw4over6 information from PCP, while another MAP domain's provision through manually configuration? when such kind of basic questions not yet fully discussed, i doubt it is suitable to adopt this work at so early stage.

[ian] The intention for the draft is to describe using the presence (or absence) of configuration parameters so that a CPE can work out which mode to configure. The DHCP section is there to show how this would work if you were using DHCP as the config mechanism, but it doesn't

2. some important issues are not yet comprehensively discussed, or almost missing, in the current draft. e.g. (but not limited to),
    - what is the correct NAPT source port overlapping behaviour for the unified CPE?
    - what is the correct fragment/reassemble behaviour for the unified CPE?

[ian] I agree that these are problems that need to be addressed across both MAP and LW, but both of these problems need solutions that are aligned at both ends of the softwire, not just the CPE.

[ian] For the fragmentation question, Ole proposed this as being a suitable task to tackle as it is common to all solutions. I would propose that this is how it is tackled, and then any affected drafts are updated based on the outcome.

as currently there is no MAP members joins this draft, i am worrying that the draft has fully reflected the concern from the MAP side.

[ian] As there haven't been any comments on the draft for some time from anyone involved in the WG, I'm hoping that this means that everyone is happy with the content!

thanks and regards,
maoke

2013/2/5 Suresh Krishnan <[email-masked]<mailto:[email-masked]>>
Hi all,

Regards
Suresh & Yong

_______________________________________________
Softwires mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/softwires

---

From: Simon Perreault <[email-masked]>
Date: Tue, 05 Feb 2013 10:45:01 +0100

Le 2013-02-05 09:55, [email-masked] a écrit :
> I see a useful work here that brings together the different Softwire
> approaches under a unified CPE and would that's why vote for an
> adoption as WG working item.

+1

Simon

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Feb 2013 10:49:58 +0100

> I see a useful work here that brings together the different Softwire approaches under a unified CPE and would that's why vote for an adoption as WG working item.

yes, I agree with that.  while I think the document needs some more polishing, I do think it is something we should work on.

cheers,
Ole

---

From: Vízdal Aleš <[email-masked]>
Date: Tue, 5 Feb 2013 13:09:52 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Simon Perreault
> Sent: Tuesday, February 05, 2013 10:45 AM
> To: [email-masked]

+1

Ales

---

From: Tim Chown <[email-masked]>
Date: Tue, 5 Feb 2013 12:45:48 +0000

>> adoption as WG working item.

Agree to adoption.

---

From: Tom Taylor <[email-masked]>
Date: Tue, 05 Feb 2013 10:50:18 -0500

Support.

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Tue, 5 Feb 2013 17:44:58 +0000

Support.

---

From: Tina TSOU <[email-masked]>
Date: Tue, 5 Feb 2013 19:43:18 +0000

Dear all,
I'm in favor of the adoption.

Thank you,
Tina

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Senthil Sivakumar (ssenthil)
> Sent: 2013年2月5日 9:45
> To: Suresh Krishnan; Softwires WG
> Cc: Yong Cui; Ralph Droms (rdroms)

---

From: Maoke <[email-masked]>
Date: Wed, 6 Feb 2013 10:58:58 +0900

2013/2/5 <[email-masked]>

> From: Maoke <[email-masked]>
> To: Suresh Krishnan <[email-masked]>
> Cc: Softwires WG <[email-masked]>, Yong Cui <[email-masked]>,
> Ralph Droms <[email-masked]>
> [ian] The intention for the draft is to describe using the presence (or
> absence) of configuration parameters so that a CPE can work out which mode
> to configure. The DHCP section is there to show how this would work if you
> were using DHCP as the config mechanism, but it doesn't
>
>
[maoke] the draft states "e.g." for the DHCP configuration firstly but
later the total discussion is based on only DHCP. i doubt this can be a
good direction for the further approach.

> [ian] I agree that these are problems that need to be addressed across
> both MAP and LW, but both of these problems need solutions that are aligned
> at both ends of the softwire, not just the CPE.
>

[maoke] NAPT issue is totally CPE issue. i don't agree it is a problem for
the *both* ends. fragmentation issue involves both sides, but CPE behaviour
impacting the anycast BR/AFTR performance is a well-known issue in the
community. even BR/AFTR has any change, the CPE must contain a work on this
issue.

> [ian] For the fragmentation question, Ole proposed this as being a
> suitable task to tackle as it is common to all solutions. I would propose
> that this is how it is tackled, and then any affected drafts are updated
> based on the outcome.
>
> [ian] As there haven't been any comments on the draft for some time from
> anyone involved in the WG, I'm hoping that this means that everyone is
> happy with the content!
>

[maoke] happy with the content at current stage = acknowledge to the
authors' effort != happy with the content at the level of WG adoption. ;-)
for the time being...

- maoke

---

From: Qiong <[email-masked]>
Date: Wed, 6 Feb 2013 13:40:43 +0800

Dear all,

Support to adopt. This is a good starting point to work with both MAP and
LW4O6.

Best wishes
Qiong

-- 
==============================================
Qiong Sun
China Telecom Beijing Research Institude

Open source code:
lightweight 4over6: *http://sourceforge.net/projects/laft6/*
PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ *
===============================================

---

From: Branimir Rajtar <[email-masked]>
Date: Thu, 7 Feb 2013 21:50:32 +0000

Hi all,

I agree with the response below and I support adoption.

(Also, I'm new to this workgroup, but I’ve had a bit of experience with softwires so I hope to contribute in the future.)

BR,
Branimir Rajtar
Croatian Telecom

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qiong
Sent: Wednesday, February 06, 2013 6:41 AM
To: Suresh Krishnan
Cc: Softwires WG; Yong Cui; Ralph Droms
Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02

Dear all,

Support to adopt. This is a good starting point to work with both MAP and LW4O6.

Best wishes
Qiong

On Tue, Feb 5, 2013 at 1:29 PM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

Regards
Suresh & Yong

Open source code:
lightweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoord: http://sourceforge.net/projects/pcpportsetdemo/
===============================================

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadržaj ove poruke i eventualno priloženih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greškom, molimo Vas, obavijestite pošiljatelja, a poruku i sve njene privitke odmah, bez čitanja, trajno uklonite s računala. Bilo kakvo prenošenje, kopiranje ili distribucija informacija sadržanih u poruci trećim osobama je zabranjeno i može biti zakonski kažnjivo. Sadržaj, stavovi i mišljenja izneseni u poruci su autorovi i ne predstavljaju nužno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaća nikakvu odgovornost za eventualnu štetu nastalu primitkom ove poruke i priloga sadržanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>

---

From: <[email-masked]>
Date: Fri, 8 Feb 2013 09:44:32 +0100

HI Maoke,

Comments in line.

Cheers,
Ian

Deutsche Telekom AG
Group Technology
Ian Farrer
IP Engineering
Landgrabenweg 151, 53227 Bonn, Germany
+49 228 93638046 (Phone)
+49 170 4557418 (Mobile)
E-Mail: [email-masked]<mailto:[email-masked]>www.telekom.com<http://www.telekom.com/>

Life is for sharing.

Deutsche Telekom AG
Supervisory Board: Prof. Dr. Ulrich Lehner (Chairman)
Board of Management: René Obermann (Chairman),
Reinhard Clemens, Niek Jan van Damme, Timotheus Höttges,
Dr. Thomas Kremer, Claudia Nemat, Prof. Dr. Marion Schick
Commercial register: Amtsgericht Bonn HRB 6794
Registered office: Bonn
VAT identification no. DE 123475223

Big changes start small – conserve resources by not printing every e-mail.

From: Maoke <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 6 February 2013 02:58
To: Ian Farrer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Softwires] Call for adoption of draft-bfmk-softwire-unified-cpe-02

2013/2/5 <[email-masked]<mailto:[email-masked]>>
Hi Maoke,

Cheers,
Ian

hi Suresh and all,

[maoke] the draft states "e.g." for the DHCP configuration firstly but later the total discussion is based on only DHCP. i doubt this can be a good direction for the further approach.

[ian] That's not the intention. Only section 3.3 discusses DHCP in depth to show how this works. The implementation is given as a should req. to be in line with the DHCP provisioning should requirements in both MAP and lw4o6. Point taken however – I'll try and make the rest of the document (e.g. Except sec 3.3) less DHCP focused.

[maoke] NAPT issue is totally CPE issue. i don't agree it is a problem for the *both* ends. fragmentation issue involves both sides, but CPE behaviour impacting the anycast BR/AFTR performance is a well-known issue in the community. even BR/AFTR has any change, the CPE must contain a work on this issue.

[ian] If there are overlapping source ports, then this is also a problem for the concentrator. If multiple initiators share the same v4 destination address / source ports, on what basis can the initiator forward ingress traffic?

[maoke] happy with the content at current stage = acknowledge to the authors' effort != happy with the content at the level of WG adoption. ;-) for the time being...

[ian] Let's see what the outcome of the adoption call is then.

- maoke

thanks and regards,
maoke

Regards
Suresh & Yong

---

From: Maoke <[email-masked]>
Date: Fri, 8 Feb 2013 18:29:58 +0900

hi Ian,

2013/2/8 <[email-masked]>

> E-Mail: [email-masked]
>
> Life is for sharing.
>
> Deutsche Telekom AG
> *Big changes start small **–** conserve resources by not printing every
> e-mail.*
>
> To: Ian Farrer <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "
> [email-masked]" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "[email-masked]" <[email-masked]>
>
>> 1. current draft makes a logic for the CPE to decide its mode according
>> to what information it received from DHCP options. however, DHCP options
>> are not the only available provision mean. what if my CPE get MAP
>> information through DHCP, while lw4over6 information from PCP, while
>> another MAP domain's provision through manually configuration? when such
>> kind of basic questions not yet fully discussed, i doubt it is suitable to
>> adopt this work at so early stage.
>>
> [ian] That's not the intention. Only section 3.3 discusses DHCP in depth
> to show how this works. The implementation is given as a should req. to be
> in line with the DHCP provisioning should requirements in both MAP and
> lw4o6. Point taken however – I'll try and make the rest of the document
> (e.g. Except sec 3.3) less DHCP focused.
>

[maoke] in contrast, i don't think DHCP MUST be the only way for
provisioning. i'd prefer the "e.g." rather than limiting the further
mechanisms DHCP-focused.

> [ian] If there are overlapping source ports, then this is also a problem
> for the concentrator. If multiple initiators share the same v4 destination
> address / source ports, on what basis can the initiator forward ingress
> traffic?
>

[maoke] we have had at least 3 alternative strategies regarding source port
overlapping and are comparing their pros/cons. practical usage has proved
the availability to some extent.

> [ian] Let's see what the outcome of the adoption call is then.

[maoke] i insist to propose considering the problems: 1) if DHCP is the
only way that the unified CPE can do with? 2) if participating multiple
domain is/cannot definitely be supported? 3) how the CPE support source
port overlapping and fragmentation with multiple domain exits? i
contributed these concerns to the community -- it is enough for me. if the
draft is less qualified with my criteria, i just do not use it.

as to the adoption, i have expressed my comments. the result is not in my
concern.

thanks and regards,
maoke

---

From: Qi Sun <[email-masked]>
Date: Fri, 15 Feb 2013 17:52:32 +0800

Dear all,

Support. This work should be helpful for moving forward with both lw4o6 and MAP.

Best Regards,
Qi Sun

On 2013-2-6, at 下午1:40, Qiong wrote:

> On Tue, Feb 5, 2013 at 1:29 PM, Suresh Krishnan <[email-masked]> wrote:
> Hi all,