From nobody Mon May 5 08:39:26 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855C91A038D for ; Mon, 5 May 2014 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TApava4szw6b for ; Mon, 5 May 2014 08:39:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 380CC1A03A6 for ; Mon, 5 May 2014 08:39:20 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0Lllxw-1XGOgb3QHI-00Zd4o; Mon, 05 May 2014 11:39:16 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_C8844F46-7221-40CD-924E-E366DB76BF6C" From: Alper Yegin X-Priority: 3 In-Reply-To: Date: Mon, 5 May 2014 18:39:12 +0300 Message-Id: <7377CFAF-F81C-4263-AFC2-1F2FFB3452F2@yegin.org> References: <416053726.1069491398771869203.JavaMail.nobody@rln9rmd101.webex.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:XV08uEen+DHnN4UWSecFYg5zcYrsuaInjUkRC+f8xxR L+HyFNGZf70rYzj4bgwJCevepxUg2vimonROZYAXkwi3mq0XX8 ZiAQHnklZ3RKEU+CzUPaS1GFGfEwlhfMd6PnQOaTVY5niAakDd 4GfaKQYACP/mTlTJJiRKTDBV5n9ptdsC0suja4afQ2ZAD/aEY5 dG7M6B7OCQU2yIZ2WjAGpZ3rfLUFrDLcLfgnESWyVJH6MFm341 NtFbASQytWTXPELfHYK2rklFUo95hgapnb3JBBLWeG7h8zOwPY Al7HbqbymsaZoN8KfWQi+UDL8n+d8Fbc12VScaBbY+X6Aq2ij+ H1GniGU84qG2lSWlTOfySsd1Ea4AkYFN4FVbBNlVguA47Wc9um +9HBtp09SNWZQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Rv4lFqSI61v-Jo644_HU4HGcTPw Subject: Re: [DMM] Invitation to WebEx meeting: Next-Generation Mobility Protocols and Architectures, Call #4 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:39:24 -0000 --Apple-Mail=_C8844F46-7221-40CD-924E-E366DB76BF6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Folks, You can find Charlie's slides at:=20 http://yegin.org/NGmobility/Why802-May2014.pptx Alper On Apr 29, 2014, at 2:46 PM, Alper Yegin wrote: > Folks, >=20 > Please see below for the details of the upcoming Next-Generation = Mobility Protocols and Architectures call. >=20 > Cheers, >=20 > Alper >=20 >=20 >=20 > Begin forwarded message: >=20 >>=20 >>=20 >>=20 >> Hi, >> =09 >> =20 >> Alper Yegin is inviting you to this WebEx meeting: >> =09 >> Next-Generation Mobility Protocols and Architectures, Call #4=20 >> Mon, May 5, 5:00 pm | 1 hr 30 min >> Istanbul (Eastern Europe Summer Time, GMT+03:00) >> Host: Alper Yegin >> =09 >> Join >> =09 >> =20 >> Add the attached iCalendar (.ics) file to your calendar. >> =09 >> Agenda >>=20 >> Charlie Perkins presenting "Wireless handovers: relative importance = of various technologies" >> =09 >> Access Information >>=20 >> Where: WebEx Online >> Meeting number: 236 359 345 >> Password: This meeting does not require a password. >> =09 >> Audio Connection >>=20 >> +44-203-478-5289 UK Domestic Toll >> Access code: 236 359 345 >> Can't access your meeting? Get help. >> Delivering the power of collaboration >> Cisco WebEx Team >>=20 >> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. By joining this meeting, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation. >>=20 >> =A92013 Cisco and/or its affiliates. All rights reserved. >> MT-A-001 >>=20 > >=20 --Apple-Mail=_C8844F46-7221-40CD-924E-E366DB76BF6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 http://yegin.org/= NGmobility/Why802-May2014.pptx

Alper



On Apr 29, 2014, at = 2:46 PM, Alper Yegin wrote:



= 3D"Cisco
=
=
Hi,
3D""
 
Alper Yegin is inviting you to this WebEx meeting:
3D""   
Next-Generation Mobility Protocols and Architectures, = Call #4
Mon, May 5, 5:00 pm | 1 hr 30 = min
Host: = Alper Yegin
  
3D""
 
3D""  

Agenda

= Charlie Perkins presenting "Wireless handovers: r= elative importance of various technologies"
3D""  

Access Information

Where:  WebEx Online
Meeting = number:  236 359 345
Password:  This meeting does not require a = password.
3D""  

Audio Connection

+44-203-478-5289 UK Domestic Toll
Access code: 236 359 345

Can't access your = meeting? Get = help.
= = = = = = = = =
=
= Delivering the power of collaboration
= Cisco WebEx Team =
=
= =
3D"Footer"
=20
IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation.
=20

=A92013 Cisco = and/or its affiliates. All rights reserved.
MT-A-001
= 3D"Cisco"
<Next-Generation Mobility = Protocols and Architectures, Call _4.ics>


= --Apple-Mail=_C8844F46-7221-40CD-924E-E366DB76BF6C-- From nobody Mon May 5 08:46:47 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AFA1A00BD for ; Mon, 5 May 2014 08:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHF3B4lH5KZ1 for ; Mon, 5 May 2014 08:46:39 -0700 (PDT) Received: from out67-ams.mf.surf.net (out67-ams.mf.surf.net [145.0.1.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4C11A0087 for ; Mon, 5 May 2014 08:46:38 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing3-ams.mf.surf.net (8.14.4/8.14.4/Debian-4) with ESMTP id s45FrICt022310; Mon, 5 May 2014 17:53:18 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Mon, 5 May 2014 17:46:31 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.47]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Mon, 5 May 2014 17:46:30 +0200 From: To: Thread-Topic: 802.11p: point mentioned during presentation of Charlie Thread-Index: Ac9od/g+VJD7QdEHTjqZ7KhXVUVIxg== Date: Mon, 5 May 2014 15:46:29 +0000 Message-ID: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F46647DEXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0bLWfRiQa - 0a4e029ac579 - 20140505 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/vzqKTthoeGfu_qx4TAeIBLF_9aU Cc: charles.perkins@earthlink.net Subject: [DMM] 802.11p: point mentioned during presentation of Charlie X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 May 2014 15:46:43 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F46647DEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Today, during the 4th Next-Generation Mobility Protocols and Architectures = call, Charlie Perkins presented the talk: "Wireless handovers: relative importance of various technologies" . During that call, Charlie asked me to send information related to the IEEE = 802.11p wireless technology. which is the WLAN technology for vehicular net= works. The protocol is in 2010 standardized by IEEE. The reference can be found vi= a: IEEE 802.11p, "IEEE Std 802.11p(TM)-2010, IEEE Standard for Information Tec= hnology - Telecommunications and information exchange between systems - Loc= al and metropolitan area networks -Specific requirements, Part 11: Wireless= LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, = Amendment 6: Wireless Access in Vehicular Environments; document freely ava= ilable at URL http://stan= dards.ieee.org/getieee802/download/802.11p-2010.pdf The main differences between IEEE 802.11a and IEEE 802.11p are very nicely = described in Appendix C of: http://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-01#ref-ieee802.1= 1p-2010 Best regards, Georgios --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F46647DEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Today, during the 4th Next-Generation Mobility Protocols and Architectur= es call, Charlie Perkins presented the talk:
"Wireless handovers: relative importance of various technologies"= .

 

During that call, Charlie asked me to send information related to the IE= EE 802.11p wireless technology. which is the WLAN technology for vehicular = networks.

 

The protocol is in 2010 standardized by IEEE. The reference can be found= via:

IEEE 802.11p, "IEEE Std 802.11p(TM)-2010, IEEE Standard for Informa= tion Technology - Telecommunications and information exchange between syste= ms - Local and metropolitan area networks -Specific requirements, Part 11: = Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications,  Amendment 6: Wireless Acces= s in Vehicular Environments; document freely available at URL

http://standards.ieee.org/getieee802/download/802.11p-2010.pdf

 

 

The main differences between IEEE 802.11a and IEEE 802.11p are very nice= ly described in Appendix C of:

http://tools.ietf.org/html/draft-petrescu-ipv6-over-= 80211p-01#ref-ieee802.11p-2010

 

Best regards,

Georgios

 

 

--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F46647DEXMBX23adutwent_-- From nobody Tue May 6 20:51:34 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BDF1A021D for ; Tue, 6 May 2014 20:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jmuX2kSIIQn for ; Tue, 6 May 2014 20:51:28 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id B65A01A0217 for ; Tue, 6 May 2014 20:51:28 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id ey11so515365pad.4 for ; Tue, 06 May 2014 20:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type; bh=JT++1EZkB8tOQphT1f3eKROSXNDASSUvs7W6VnTe7Z8=; b=SiHNMTIAH5QBXa8i4rcwQxpC5LGqJhdeCz29zABFDfDhaB5rOLeGfu/4RvNks4BOVf /3RP3+htvIOEZGedCMkArLCiENhyVQdNUPzppnVEsIvRSwvjrQcuVI4W5q5h0iu5LHDn 2CafQvf4s6ALIkDphlrr54KfXKUEbg945xoqAB+DHQ4+ptzOWoPzKkV/BRqYXZLmjn0c 5OTG21Li9R4kCwvQE8Xinh/9j42tXnYeB0PilxnxkDW5EfLtDkhS2odi6qCpqEUZWX6G mcGW2gXnAT8o32N2tnCQj3m4DYiasMtS5aC5d4E6dOVd3l1x+ucyhrX3nAMmBvlnWP4a gv7Q== X-Received: by 10.66.233.9 with SMTP id ts9mr13914175pac.37.1399434684559; Tue, 06 May 2014 20:51:24 -0700 (PDT) Received: from [192.168.43.11] ([117.136.38.99]) by mx.google.com with ESMTPSA id kl1sm468873pbd.73.2014.05.06.20.51.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 06 May 2014 20:51:23 -0700 (PDT) Date: Wed, 7 May 2014 11:53:54 +0800 From: Dapeng Liu To: dmm@ietf.org Message-ID: <98D710033C7C48B0AF7D24B35800F53B@gmail.com> In-Reply-To: <7377CFAF-F81C-4263-AFC2-1F2FFB3452F2@yegin.org> References: <416053726.1069491398771869203.JavaMail.nobody@rln9rmd101.webex.com> <7377CFAF-F81C-4263-AFC2-1F2FFB3452F2@yegin.org> X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5369ae52_1befd79f_468" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/C92wmrIbAyjIsCMW9WJYLXdGVq8 Cc: Charlie.Perkins@huawei.com Subject: [DMM] =?utf-8?Q?=E5=9B=9E=E5=A4=8D=EF=BC=9A_?=DMM gap discussion Invitation to WebEx meeting: Next-Generation Mobility Protocols and Architectures, Call #4 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 03:51:32 -0000 --5369ae52_1befd79f_468 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello All, =20 I forward Charlie=E2=80=99s mail to the list. Please check whether we can= agree on this. Best Regards, Jouni & Dapeng --------------------------------------------------- Hello Dapeng, I agree with both your points (1) and (2). It remains to be seen whether= the participants on Monday=E2=80=99s call would agree. Perhaps, if the = respondents on this email are all in agreement, we should verify consensu= s on the =5Bdmm=5D WG mailing list. =20 In fact, if we adopt a high-performance distributed mobility management s= olution and 3GPP uses it, that would be fabulous. =20 Regards, =20 Charlie P. =46rom: Dapeng Liu =5Bmailto:liudapeng=40chinamobile.com=5D =20 Sent: Tuesday, May 06, 2014 2:02 AM To: Charlie Perkins; 'H Anthony Chan'; 'Jouni Korhonen' Cc: draft-ietf-dmm-best-practices-gap-analysis=40tools.ietf.org; 'Alper Y= egin'; pierrick.seite=40orange.com Subject: =E7=AD=94=E5=A4=8D: Mail regarding draft-ietf-dmm-best-practices= -gap-analysis =20 Hello Charlie, =20 Please let us know whether the following answer address your concern: =20 1. In my understanding, PMIP/DSMIP do not have the requirement to be =E2=80= =9Ccompatible with 3GPP network=E2=80=9D when it was designed=3F And that= does not prevent PMIP/DSMIP been adopted by 3GPP specification. =20 2. DMM can take a similar approach and that will not prevent 3GPP to adop= t DMM as their mobility solution. Best regards, =20 Dapeng Liu =E5=8F=91=E4=BB=B6=E4=BA=BA: Charlie Perkins =5Bmailto:Charlie.Perkins=40= huawei.com=5D =20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B45=E6=9C=886=E6=97=A5 7= :11 =E6=94=B6=E4=BB=B6=E4=BA=BA: H Anthony Chan; Jouni Korhonen =E6=8A=84=E9=80=81: draft-ietf-dmm-best-practices-gap-analysis=40tools.ie= tf.org; Alper Yegin; pierrick.seite=40orange.com; Dapeng Liu =E4=B8=BB=E9=A2=98: RE: Mail regarding draft-ietf-dmm-best-practices-gap-= analysis =20 Hello folks, =20 To be clear, I am personally not lobbying for the requirement to be compa= tible with existing 3GPP operator deployments. But whether or not the wo= rking group mandates the requirement, it really has to be clear one way o= r the other. Moreover, there are varying degrees of compatibility, and i= n this case it will make a huge difference how strict the compatibility r= equirement is drawn up to be. =46or instance, is it enough to support PM= IP without establishing a charging ID=3F =20 Regards, =20 Charlie P. =46rom: H Anthony Chan =5Bmailto:h.anthony.chan=40gmail.com=5D =20 Sent: Monday, May 05, 2014 3:47 PM To: Charlie Perkins; Jouni Korhonen Cc: draft-ietf-dmm-best-practices-gap-analysis=40tools.ietf.org; Alper Ye= gin; pierrick.seite=40orange.com; Dapeng Liu Subject: Re: Mail regarding draft-ietf-dmm-best-practices-gap-analysis =20 Thanks to Charlie for bring this up. We are adding a new requirement on O= perations and management, and we are in the process of drafting it. I thi= nk what Charlie mentioned fits well within the scope of this OPS requirem= ent. I feel we need a very good draft of this requirement else it will no= t pass the IESG review. Pierrick has already suggested some text. Anyone= is welcome to edit that draft. =20 =20 I am currently studying other drafts in OPS before I do the final editing= early next week. =20 =20 H Anthony Chan =46rom: Charlie Perkins (mailto:Charlie.Perkins=40huawei.com) =20 Sent: Tuesday, May 06, 2014 2:46 AM To: Jouni Korhonen (mailto:jouni.nospam=40gmail.com%22%20%5Co%20%22jouni.= nospam=40gmail.com) =20 Cc: draft-ietf-dmm-best-practices-gap-analysis=40tools.ietf.org (mailto:d= raft-ietf-dmm-best-practices-gap-analysis=40tools.ietf.org%22%20%5Co%20%2= 2draft-ietf-dmm-best-practices-gap-analysis=40tools.ietf.org) ; 'H Anthon= y Chan' (mailto:h.a.chan=40ieee.org) ; Alper Yegin (mailto:alper.yegin=40= yegin.org%22%20%5Co%20%22alper.yegin=40yegin.org) ; pierrick.seite=40oran= ge.com (mailto:pierrick.seite=40orange.com%22%20%5Co%20%22pierrick.seite=40= orange.com) ; Dapeng Liu (%22mailto:liudapeng=40chi) =20 Subject: RE: Mail regarding draft-ietf-dmm-best-practices-gap-analysis Hello Jouni, During this morning's WebEx teleconference, the opinion was expressed tha= t the work in =5Bdmm=5D is *required* to be compatible with current opera= tor deployment, by which was meant LTE infrastructure (at least that's ho= w I understood it). This requirement is not expressed in the requirement= s document, and there is no relevant analysis in the gap document which w= ould enable us to judge how existing protocols fail to fit the needs of c= urrent operator deployment. I view this as a serious problem, and one which would almost certainly st= ymie any productive result from the working group. Do you think it is a serious problem=3F If so, how best should we attemp= t to make progress=3F If not, do you disagree with the requirement which= I understood to be emphasized in this morning's WebEx discussion=3F I think the first step is to decide whether or not the requirement is goi= ng to be a constraint on acceptable solutions, and the second step, if in= deed it is a requirement, is to determine precisely what are the gaps bet= ween that requirement and current IET=46 protocols. Without those steps,= deciding whether or not to go forward with the existing gap analysis doc= ument is more or less just busywork. Comments, please=3F Regards, Charlie P. -- =20 Dapeng Liu =E5=9C=A8 2014=E5=B9=B45=E6=9C=885=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF= =BC=8C=E4=B8=8B=E5=8D=8811:39=EF=BC=8CAlper Yegin =E5=86=99=E9=81=93=EF=BC= =9A =20 > =46olks, > =20 > You can find Charlie's slides at: =20 > =20 > http://yegin.org/NGmobility/Why802-May2014.pptx > =20 > Alper > =20 > =20 > =20 > On Apr 29, 2014, at 2:46 PM, Alper Yegin wrote: > > =46olks, > > =20 > > Please see below for the details of the upcoming Next-Generation Mobi= lity Protocols and Architectures call. > > =20 > > Cheers, > > =20 > > Alper > > =20 > > =20 > > =20 > > Begin forwarded message: > > > =20 > > > =20 > > > Hi, =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Alper Yegin is inviting you to this WebEx meeting: =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Next-Generation Mobility Protocols and Architectures, Call =234 (ht= tps://meetings.webex.com/collabs/meetings/view=3Fuuid=3DM3BYQGE1=46SOI2GB= 5LUVCRWJ5QQ-1KJ9&ucs=3Demail) =20 > > > Mon, May 5, 5:00 pm =7C 1 hr 30 min > > > Istanbul (Eastern Europe Summer Time, GMT+03:00) > > > Host: Alper Yegin > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Join (https://meetings.webex.com/collabs/meetings/join=3Fuuid=3DM3B= YQGE1=46SOI2GB5LUVCRWJ5QQ-1KJ9) =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Add the attached iCalendar (.ics) file to your calendar. =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Agenda > > > =20 > > > Charlie Perkins presenting =22Wireless handovers: relative importan= ce of various technologies=22 =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Access Information > > > =20 > > > Where: > > > =20 > > > WebEx Online > > > =20 > > > Meeting number: > > > =20 > > > 236 359 345 > > > =20 > > > Password: > > > =20 > > > This meeting does not require a password. > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Audio Connection > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > +44-203-478-5289 UK Domestic Toll > > > =20 > > > =20 > > > =20 > > > =20 > > > Access code: 236 359 345 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > Can't access your meeting=3F Get help. (https://meetings.webex.com/= collabs/=23/support) > > > =20 > > > =20 > > > Delivering the power of collaboration > > > Cisco WebEx Team =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows= audio and any documents and other materials exchanged or viewed during t= he meeting to be recorded. By joining this meeting, you automatically con= sent to such recordings. If you do not consent to the recording, discuss = your concerns with the meeting host prior to the start of the recording o= r do not join the meeting. Please note that any such recordings may be su= bject to discovery in the event of litigation. =20 > > > =20 > > > =20 > > > =C2=A92013 Cisco and/or its affiliates. All rights reserved. > > > MT-A-001 =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > > =20 > > =20 > > =20 > > =20 > > =20 > > = > > > =20 > > =20 > > =20 > > =20 > =20 > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F > dmm mailing list > dmm=40ietf.org (mailto:dmm=40ietf.org) > https://www.ietf.org/mailman/listinfo/dmm > =20 > =20 --5369ae52_1befd79f_468 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hello All,

I forward Charlie=E2=80=99s mai= l to the list. Please check whether we can agree on this.

<= /div>
Best Regards,
Jouni & Dapeng
-----= ----------------------------------------------

Hello Dapeng,


I agree with both your points (1) and (2).  It = remains to be seen whether the participants on Monday=E2=80=99s call woul= d agree.  Perhaps, if the respondents on this email are all in agree= ment, we should verify consensus on the =5Bdmm=5D WG mailing list.


In fact, if we adopt a high-performance distributed = mobility management solution and 3GPP uses it, that would be fabulous.


Regards,

Charlie P.



=46= rom: Dapeng Liu =5Bmailto:liudapeng=40chinamobile.com=5D
Sent: Tuesday, May 06, 2014 2:02 AM
To: Charlie Perkins; 'H Anthony Chan'; 'Jouni Korhonen'
Cc: draft-ietf-dmm-best-practices-gap-analysis=40tools.ietf.org; '= Alper Yegin'; pierrick.seite=40orange.com
Subject: =E7=AD=94=E5=A4= =8D: Mail regarding draft-ietf-dmm-best-practices-gap-analysis

=

=E5=B9=B45=E6=9C=886=E6=97=A5 7:11
=E6=94=B6=E4=BB=B6=E4=BA=BA= : H Anthony Chan; Jouni Korhonen
=E6=8A=84=E9=80=81: = draft-ietf-dmm-best-practices-gap-analysis=40tools.ietf.org; Alper Yegin;= pierrick.seite=40orange.com; Dapeng Liu
=E4=B8=BB=E9=A2=98: RE: Mail regarding draft= -ietf-dmm-best-practices-gap-analysis

; Alper Yegin ; pierrick.seite=40orange.com ;= Dapeng Liu 

Su= bject: RE: Mail regarding draft-ietf-dmm-best-practices-gap-analysis<= /p>


I view this as a serious problem, and one which would almost certainly st= ymie any productive result from the working group.

Do you think it is a serious problem=3F  If so, how best should we a= ttempt to make progress=3F  If not, do you disagree with the require= ment which I understood to be emphasized in this morning's WebEx discussi= on=3F

I think the first step is to decide whether or not the requirement is goi= ng to be a constraint on acceptable solutions, and the second step, if in= deed it is a requirement, is to determine precisely what are the gaps bet= ween that requirement and current IET=46 protocols.  Without those s= teps, deciding whether or not to go forward with the existing gap analysi= s document is more or less just busywork.

Comments, please=3F

Regards,
Charlie P.

-- 
Dapeng Liu

=E5=9C=A8 2014=E5=B9=B45=E6=9C=885=E6=97= =A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=8811:39=EF=BC=8CA= lper Yegin =E5=86=99=E9=81=93=EF=BC=9A
=46olks,

You can f= ind Charlie's slides at: 


Alper


On Apr 29, 2014, at 2:46 PM, Al= per Yegin wrote:

=46olks,

Please see below for th= e details of the upcoming Next-Generation Mobility Protocols and Architec= tures call.

Cheers,

Alp= er



Begin forwarded message:

=09 <=21--********************footer begin********************--> <=21--********************footer end********************-->
3D=22Cisco=
<=21--******************** header end********************-->
Hi,
=
3D=22=22
 
Alper Yegin is inviting you to this WebEx meeting:
=20
3D=22=22   
Next-Generation Mobility Protocols and Architectures, Ca= ll =234
Mon, May 5, 5:00 pm =7C 1 hr 30 min
Istanbul (Eastern Europe S= ummer Time, GMT+03:00)
Host: Alper Yegin
   <=21-- Button begin -->
<=21-- Button end -->
=20
3D=22=22
 
Add the att= ached iCalendar (.ics) file to your calendar.
=20
3D=22=22  

Agenda

Charlie Perkins presenting =22Wireless hand= overs: relative importance of various technologi= es=22
=20
3D=22=22<= /td>  

Access Information

Where:  WebEx Online
Meeting number:&nbs= p; 236 359 345
Password:  This meeting does not require a password.
=20
3D=22=22  

Audio Connection

+= 44-203-478-5289 UK Domestic Toll
=20
Access code: 236 359 345
=20
=20

=20

=20
=20
Can't access your meeting=3F = Get help.
<=21-- content footer begin-->
Delivering the power of collaboration
Cisco WebEx Team
<=21--content footer end-->
3D=22=46oo=
=20
IMPORTANT NOTICE: This WebEx service includes= a feature that allows audio and any documents and other materials exchan= ged or viewed during the meeting to be recorded. By joining this meeting,= you automatically consent to such recordings. If you do not consent to t= he recording, discuss your concerns with the meeting host prior to the st= art of the recording or do not join the meeting. Please note that any suc= h recordings may be subject to discovery in the event of litigation.
=20

=C2=A92013 Cisco and/or its affiliates. All r= ights reserved.
MT-A-001
3D=22Cisco=22=
<Next-Generation Mobility P= rotocols and Architectures, Call =5F4.ics>


=
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F<= /div>
dmm mailing list
<= /div> =20 =20 =20 =20
=20

--5369ae52_1befd79f_468-- From nobody Thu May 8 14:25:28 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794801A0173 for ; Thu, 8 May 2014 14:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnG7eNb_IHVk for ; Thu, 8 May 2014 14:25:25 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA7A1A0172 for ; Thu, 8 May 2014 14:25:25 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id p9so4358098lbv.7 for ; Thu, 08 May 2014 14:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=C11+TnaIkosRlV2MwIN5sNCei6sH7cM5orVD2yUh4ZU=; b=PEToM6oIlppfNKrBg6BGpAjV86YwDhR1CFOYsIir8ooKgU0iUds4ZcldYDvItNS7Mu F4racxD5yAHQFh/+wZ4A69rQpecazvPQjeMq9SRY6n5bYG3hLxhM1iEmEjkQFgm7z6KL gDgKqiXe6VmD4M57df3SqRtVxT7DyMJM/Mtb3pn/dpvXTUhyErKGq3UV2Dxb1VUkHlnq J0sPWLRTcYcHiLCpuuQU9hL7dZ3sCHtjmUqEZq1OJ2bFSL4qDq4GsWEoRn6abbmLxXf6 Qa+OY0wvxnfc5z1CoFbB6uw9BfAqadUWo9oEO/yTMgYuSQA/I+fljdszLxZ5iJrjGsp/ ZW5g== MIME-Version: 1.0 X-Received: by 10.112.147.36 with SMTP id th4mr6996111lbb.32.1399584319979; Thu, 08 May 2014 14:25:19 -0700 (PDT) Received: by 10.114.70.165 with HTTP; Thu, 8 May 2014 14:25:19 -0700 (PDT) Date: Thu, 8 May 2014 16:25:19 -0500 Message-ID: From: Behcet Sarikaya To: "dmm@ietf.org" , Satoru Matsushima , Ryuji Wakikawa Content-Type: multipart/alternative; boundary=047d7b3a86663a478d04f8ea1ebf Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_D-wyHKRjW5NRn8DP4U0YcjBwqg Subject: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 21:25:27 -0000 --047d7b3a86663a478d04f8ea1ebf Content-Type: text/plain; charset=UTF-8 Hi Matsushima-san, I have some other questions on your draft. Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I guess BGP Route Update) is initiated by which node and is going to which node? In Step 15 you have EPC-E initiating this and it is going towards RTR. Why is this not sufficient? i.e. since EPC-E can detect mobility? Why do you need Step 14? For the uplink traffic from UE, you seem to assume that it is always towards RTR. Could it not be directed to another UE? What happens in that case? You say that EPC-E supports the user plane functions of SGW and PGW. So there is no PGW in your design, I mean no anchor PGW? What happens to the control plane functions of SGW and PGW? Where are they? Regards, Behcet --047d7b3a86663a478d04f8ea1ebf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Matsushima= -san,

I have some other questions on your draft.

Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I gues= s BGP Route Update) is initiated by which node and is going to which node?<= br>
In Step 15 you have EPC-E initiating this and it is going towards= RTR. Why is this not sufficient? i.e. since EPC-E can detect mobility?
=
Why do you need Step 14?

For the uplink traffic from= UE, you seem to assume that it is always towards RTR. Could it not be dire= cted to another UE? What happens in that case?

You say that
EPC-E supports the user
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 plane functions of SGW and PGW.

So there is no PGW = in your design, I mean no anchor PGW?

What happens to the= control plane functions of SGW and PGW? Where are they?

Regards,

Behcet
--047d7b3a86663a478d04f8ea1ebf-- From nobody Wed May 14 22:45:26 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2CB1A022D for ; Wed, 14 May 2014 22:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2L29yB3G5oZ for ; Wed, 14 May 2014 22:45:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA1031A0225 for ; Wed, 14 May 2014 22:45:20 -0700 (PDT) Received: from vpn-cust-10-119-8-2.witopia.net (115-187-74-73.op-net.com [115.187.74.73]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0M8NJq-1WycGv31es-00wE88; Thu, 15 May 2014 01:45:12 -0400 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_3E71691A-5FE5-4AC6-AD9C-13309FEF1999" Date: Thu, 15 May 2014 08:45:06 +0300 In-Reply-To: <98D710033C7C48B0AF7D24B35800F53B@gmail.com> To: dmm@ietf.org References: <416053726.1069491398771869203.JavaMail.nobody@rln9rmd101.webex.com> <7377CFAF-F81C-4263-AFC2-1F2FFB3452F2@yegin.org> <98D710033C7C48B0AF7D24B35800F53B@gmail.com> Message-Id: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:aHa4AaHVEDgJIKJz8vpfc1WVsd6FkTRmvbL8XTPmnCQ VGfRleyFnA7SqA6qLquhftkKmXpaK94JRXrjSSbAAJDKSObZql He2YGILfuNPqgGnFtgjr443eJ4M2SRbgdjneJjZIj8zeY0XtFb VZ8lePVmNTm04X8SiBGOPhPJ08BhJp1OuWtlLJQYrIJOPz+1k+ FLp6w7ExQ++2KrvzCHmhSMawD4sJtHkq4zaQtODVnqucPEqlII PXqakGhnQeAlrFXBPlpYpROMJOqMO+ULRTaWjyOklpBomWxWcy bFJ0sP0DgPHYlc/L46cZFSkA+D/gmDwmfKuyssiP8hYKGopRcg QxYDCrshk0F0ES7K51bXaY7GJn6baa4/k/HexlUzO6aMUG0NJs 4fbadEjY4OpiMAVJHfVoWbrO5mEkE/E9jU= Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-1ZqXyAwOpS996v7yHYAZmy61xc Subject: Re: [DMM] =?utf-8?b?5Zue5aSN77yaIERNTSBnYXAgZGlzY3Vzc2lvbiBJbnZpdGF0?= =?utf-8?q?ion_to_WebEx_meeting=3A_Next-Generation_Mobility_Protocols_and_?= =?utf-8?q?Architectures=2C_Call_=234?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2014 05:45:24 -0000 --Apple-Mail=_3E71691A-5FE5-4AC6-AD9C-13309FEF1999 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, The way to increase the chances of an IETF protocol getting adopted by = 3GPP involves: - considering 3GPP architecture (with its on-going and upcoming work) = during the protocol design level, and - involving in 3GPP to propose the protocol for adoption by identifying = or creating a relevant work item. "if you build it, they'll come" does not work all the time... Alper On May 7, 2014, at 6:53 AM, Dapeng Liu wrote: > Hello All, >=20 > I forward Charlie=E2=80=99s mail to the list. Please check whether we = can agree on this. >=20 > Best Regards, > Jouni & Dapeng > --------------------------------------------------- > Hello Dapeng, >=20 > I agree with both your points (1) and (2). It remains to be seen = whether the participants on Monday=E2=80=99s call would agree. Perhaps, = if the respondents on this email are all in agreement, we should verify = consensus on the [dmm] WG mailing list. >=20 > In fact, if we adopt a high-performance distributed mobility = management solution and 3GPP uses it, that would be fabulous. >=20 > Regards, > Charlie P. >=20 >=20 > From: Dapeng Liu [mailto:liudapeng@chinamobile.com]=20 > Sent: Tuesday, May 06, 2014 2:02 AM > To: Charlie Perkins; 'H Anthony Chan'; 'Jouni Korhonen' > Cc: draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org; 'Alper = Yegin'; pierrick.seite@orange.com > Subject: =E7=AD=94=E5=A4=8D: Mail regarding = draft-ietf-dmm-best-practices-gap-analysis >=20 > Hello Charlie, >=20 > Please let us know whether the following answer address your concern: >=20 > 1. In my understanding, PMIP/DSMIP do not have the requirement to = be =E2=80=9Ccompatible with 3GPP network=E2=80=9D when it was designed? = And that does not prevent PMIP/DSMIP been adopted by 3GPP specification. > 2. DMM can take a similar approach and that will not prevent 3GPP = to adopt DMM as their mobility solution. >=20 > Best regards, > Dapeng Liu > =E5=8F=91=E4=BB=B6=E4=BA=BA: Charlie Perkins = [mailto:Charlie.Perkins@huawei.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2014=E5=B9=B45=E6=9C=886=E6=97=A5 = 7:11 > =E6=94=B6=E4=BB=B6=E4=BA=BA: H Anthony Chan; Jouni Korhonen > =E6=8A=84=E9=80=81: = draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org; Alper Yegin; = pierrick.seite@orange.com; Dapeng Liu > =E4=B8=BB=E9=A2=98: RE: Mail regarding = draft-ietf-dmm-best-practices-gap-analysis >=20 > Hello folks, >=20 > To be clear, I am personally not lobbying for the requirement to be = compatible with existing 3GPP operator deployments. But whether or not = the working group mandates the requirement, it really has to be clear = one way or the other. Moreover, there are varying degrees of = compatibility, and in this case it will make a huge difference how = strict the compatibility requirement is drawn up to be. For instance, = is it enough to support PMIP without establishing a charging ID? >=20 > Regards, > Charlie P. >=20 >=20 >=20 > From: H Anthony Chan [mailto:h.anthony.chan@gmail.com]=20 > Sent: Monday, May 05, 2014 3:47 PM > To: Charlie Perkins; Jouni Korhonen > Cc: draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org; Alper = Yegin; pierrick.seite@orange.com; Dapeng Liu > Subject: Re: Mail regarding draft-ietf-dmm-best-practices-gap-analysis >=20 > Thanks to Charlie for bring this up. We are adding a new requirement = on Operations and management, and we are in the process of drafting it. = I think what Charlie mentioned fits well within the scope of this OPS = requirement. I feel we need a very good draft of this requirement else = it will not pass the IESG review. Pierrick has already suggested some = text. Anyone is welcome to edit that draft.=20 > =20 > I am currently studying other drafts in OPS before I do the final = editing early next week.=20 > =20 > H Anthony Chan >=20 > From: Charlie Perkins=20 > Sent: Tuesday, May 06, 2014 2:46 AM > To: Jouni Korhonen=20 > Cc: draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org ; 'H = Anthony Chan' ; Alper Yegin ; pierrick.seite@orange.com ; Dapeng Liu=20 > Subject: RE: Mail regarding draft-ietf-dmm-best-practices-gap-analysis >=20 > Hello Jouni, >=20 > During this morning's WebEx teleconference, the opinion was expressed = that the work in [dmm] is *required* to be compatible with current = operator deployment, by which was meant LTE infrastructure (at least = that's how I understood it). This requirement is not expressed in the = requirements document, and there is no relevant analysis in the gap = document which would enable us to judge how existing protocols fail to = fit the needs of current operator deployment. >=20 > I view this as a serious problem, and one which would almost certainly = stymie any productive result from the working group. >=20 > Do you think it is a serious problem? If so, how best should we = attempt to make progress? If not, do you disagree with the requirement = which I understood to be emphasized in this morning's WebEx discussion? >=20 > I think the first step is to decide whether or not the requirement is = going to be a constraint on acceptable solutions, and the second step, = if indeed it is a requirement, is to determine precisely what are the = gaps between that requirement and current IETF protocols. Without those = steps, deciding whether or not to go forward with the existing gap = analysis document is more or less just busywork. >=20 > Comments, please? >=20 > Regards, > Charlie P. > --=20 > Dapeng Liu >=20 > =E5=9C=A8 2014=E5=B9=B45=E6=9C=885=E6=97=A5 = =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=8811:39=EF=BC=8CAlper = Yegin =E5=86=99=E9=81=93=EF=BC=9A >> Folks, >>=20 >> You can find Charlie's slides at:=20 >>=20 >> http://yegin.org/NGmobility/Why802-May2014.pptx >>=20 >> Alper >>=20 >>=20 >>=20 >> On Apr 29, 2014, at 2:46 PM, Alper Yegin wrote: >>=20 >>> Folks, >>>=20 >>> Please see below for the details of the upcoming Next-Generation = Mobility Protocols and Architectures call. >>>=20 >>> Cheers, >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Hi, >>>> =09 >>>> =20 >>>> Alper Yegin is inviting you to this WebEx meeting: >>>> =09 >>>> Next-Generation Mobility Protocols and Architectures, Call #4=20 >>>> Mon, May 5, 5:00 pm | 1 hr 30 min >>>> Istanbul (Eastern Europe Summer Time, GMT+03:00) >>>> Host: Alper Yegin >>>> =09 >>>> Join >>>> =09 >>>> =20 >>>> Add the attached iCalendar (.ics) file to your calendar. >>>> =09 >>>> Agenda >>>>=20 >>>> Charlie Perkins presenting "Wireless handovers: relative importance = of various technologies" >>>> =09 >>>> Access Information >>>>=20 >>>> Where: WebEx Online >>>> Meeting number: 236 359 345 >>>> Password: This meeting does not require a password. >>>> =09 >>>> Audio Connection >>>>=20 >>>> +44-203-478-5289 UK Domestic Toll >>>> Access code: 236 359 345 >>>> Can't access your meeting? Get help. >>>> Delivering the power of collaboration >>>> Cisco WebEx Team >>>>=20 >>>> IMPORTANT NOTICE: This WebEx service includes a feature that allows = audio and any documents and other materials exchanged or viewed during = the meeting to be recorded. By joining this meeting, you automatically = consent to such recordings. If you do not consent to the recording, = discuss your concerns with the meeting host prior to the start of the = recording or do not join the meeting. Please note that any such = recordings may be subject to discovery in the event of litigation. >>>>=20 >>>> =C2=A92013 Cisco and/or its affiliates. All rights reserved. >>>> MT-A-001 >>>>=20 >>> >>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_3E71691A-5FE5-4AC6-AD9C-13309FEF1999 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Alper


=





=
On May 7, 2014, at 6:53 AM, Dapeng Liu wrote:

Hello All,

I forward Charlie=E2=80=99s = mail to the list. Please check whether we can agree on = this.

Best Regards,
Jouni & = Dapeng
---------------------------------------------------<= /div>
Hello Dapeng,

I agree with both = your points (1) and (2).  It remains to be seen whether the = participants on Monday=E2=80=99s call would agree.  Perhaps, if the = respondents on this email are all in agreement, we should verify = consensus on the [dmm] WG mailing list.
In fact, if we adopt a = high-performance distributed mobility management solution and 3GPP uses = it, that would be fabulous.
Regards,
Charlie P.


From: Dapeng Liu = [mailto:liudapeng@chinamobile.com]
Sent: Tuesday, May 06, 2014 2:02 AM
To: Charlie Perkins; 'H Anthony Chan'; 'Jouni Korhonen'
Cc: = draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org; 'Alper = Yegin'; pierrick.seite@orange.com Subject: =E7=AD=94=E5=A4=8D= : Mail regarding = draft-ietf-dmm-best-practices-gap-analysis

Hello Charlie,
Please let us know whether the = following answer address your concern:
1. In my understanding, PMIP/DSMIP = do not have the requirement to be =E2=80=9Ccompatible with 3GPP = network=E2=80=9D when it was designed? And that does not prevent = PMIP/DSMIP been adopted by 3GPP specification.
  • 2. DMM can take a similar approach = and that will not prevent 3GPP to adopt DMM as their mobility = solution.

    • Best = regards,
    Dapeng Liu
    =E5=8F=91=E4=BB=B6=E4=BA=BA: = Charlie Perkins [mailto:Charlie.Perkins@huawei.com]
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= : 2014=E5=B9=B45=E6=9C=886=E6=97=A5 7:11
    =E6=94=B6=E4=BB=B6=E4=BA=BA: H Anthony Chan; Jouni Korhonen
    =E6=8A=84=E9=80=81: = draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org; Alper = Yegin; pierrick.seite@orange.com; = Dapeng Liu
    =E4=B8=BB=E9=A2=98: RE: Mail regarding = draft-ietf-dmm-best-practices-gap-analysis

    Hello folks,
    To be clear, I am personally not = lobbying for the requirement to be compatible with existing 3GPP = operator deployments.  But whether or not the working group = mandates the requirement, it really has to be clear one way or the = other.  Moreover, there are varying degrees of compatibility, and = in this case it will make a huge difference how strict the compatibility = requirement is drawn up to be.  For instance, is it enough to = support PMIP without establishing a charging ID?

    Charlie P.


    From: H = Anthony Chan [mailto:h.anthony.chan@gmail.com]
    Sent: Monday, May 05, 2014 3:47 PM
    To: Charlie Perkins; Jouni Korhonen
    Cc: = draft-ietf-dmm-best-practices-gap-analysis@tools.ietf.org; Alper = Yegin; pierrick.seite@orange.com; = Dapeng Liu
    Subject: Re: Mail regarding = draft-ietf-dmm-best-practices-gap-analysis

    Thanks to = Charlie for bring this up. We are adding a new requirement on Operations = and management, and we are in the process of drafting it. I think what = Charlie mentioned fits well within the scope of this OPS = requirement. I feel we need a very good draft of this = requirement else it will not pass the  IESG review. Pierrick has = already suggested some text. Anyone is welcome to edit that = draft. 

     

    I am currently studying other drafts in = OPS before I do the final editing early next week. 

     

    H Anthony Chan

    Sent: Tuesday, May 06, 2014 2:46 = AM
    Subject: RE: Mail regarding = draft-ietf-dmm-best-practices-gap-analysis


    =E5=9C=A8 2014=E5=B9=B45=E6=9C=885=E6= =97=A5 =E6=98=9F=E6=9C=9F=E4=B8=80=EF=BC=8C=E4=B8=8B=E5=8D=8811:39=EF=BC=8C= Alper Yegin =E5=86=99=E9=81=93=EF=BC=9A
    Folks,

    You can = find Charlie's slides at: 


    Alper



    On Apr 29, 2014, at = 2:46 PM, Alper Yegin wrote:



    =09
    = 3D"Cisco
    =
    =
    Hi,
    3D""
     
    Alper Yegin is inviting you to this WebEx meeting:
    =20
    3D""   
    Next-Generation Mobility Protocols and Architectures, = Call #4
    Mon, May 5, 5:00 pm | 1 hr 30 = min
    Host: = Alper Yegin
    		  
    =20
    3D""
     
    =20
    3D""  

    Agenda

    = Charlie Perkins presenting "Wireless handovers: r= elative importance of various technologies"
    =20
    3D""  

    Access Information

    Where:  WebEx Online
    Meeting = number:  236 359 345
    Password:  This meeting does not require a = password.
    =20
    3D""  

    Audio Connection

    +44-203-478-5289 UK Domestic Toll
    =20
    Access code: 236 359 345
    =20
    =20

    =20

    =20
    =20
    Can't access your = meeting? Get = help.
    = = = = = = = = =
    =
    = Delivering the power of collaboration
    = Cisco WebEx Team =
    =
    = =
    3D"Footer"
    =20
    IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation.
    =20

    =C2=A92013 Cisco = and/or its affiliates. All rights reserved.
    MT-A-001
    = 3D"Cisco"
    <Next-Generation Mobility = Protocols and Architectures, Call _4.ics>


    _____________________________________= __________
    dmm mailing list
    =20 =20 =20 =20
    =20

    _______________________________________________
    dmm = mailing list
    dmm@ietf.org
    https://www.ietf.org/mail= man/listinfo/dmm

    = --Apple-Mail=_3E71691A-5FE5-4AC6-AD9C-13309FEF1999-- From nobody Sat May 17 15:25:41 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FB71A028D for ; Sat, 17 May 2014 15:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2WDFukoWBct for ; Sat, 17 May 2014 15:25:28 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77BF01A0119 for ; Sat, 17 May 2014 15:25:27 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id l4so2939439lbv.6 for ; Sat, 17 May 2014 15:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=gMQ8qjayb1w1BBi2wTbD40U7Jsqp8SHVLIKi+lHAkBQ=; b=AV2hQjKgHH2tvmzSs+Y6ZDP5hCmslxBG0/iBXzKxwTQh025hCnLDGx4Pt+1LpISpKs +YydlyxWZvPJvet6H5mwz3Hn8q8ETs1mfhLEK1ldTmeym7vGGSFzpXarw0g4gQOV2kOs YeG/XwMSgToJXuKvuiDF53IEtDvspkkt+0cwkDkHSI9g2ayNxvH0XnU6zWzjDrvHUdcN eg0ZUsPmEXUp9JqBQlb9jzIvrMObsHzRoYnMwzjnUa/ROaWtHg++CzJQG/6Ewov5pcBw EkbxPsYJr+XolhJH5oRdWnXn7jvIfmVj89ZDcogU4SoABTSvZYbZFTGCRhUNPspql8vC /laA== X-Received: by 10.112.180.225 with SMTP id dr1mr8245918lbc.51.1400365525781; Sat, 17 May 2014 15:25:25 -0700 (PDT) Received: from [10.17.0.22] ([83.150.126.201]) by mx.google.com with ESMTPSA id r9sm14167363lal.0.2014.05.17.15.25.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 17 May 2014 15:25:25 -0700 (PDT) Message-ID: <5377E1D3.2030904@gmail.com> Date: Sun, 18 May 2014 01:25:23 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" References: <8770.1400250056@sandelman.ca> In-Reply-To: <8770.1400250056@sandelman.ca> X-Forwarded-Message-Id: <8770.1400250056@sandelman.ca> Content-Type: multipart/mixed; boundary="------------090304080803030905010003" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/zJxSdk2HpOgMvdX-XCs0YnkRY7I Subject: [DMM] Fwd: NomCom 2014-2015 Call for Volunteers X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2014 22:25:36 -0000 This is a multi-part message in MIME format. --------------090304080803030905010003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit FYI -------- Alkuperäinen viesti / Orig.Msg. -------- Aihe: NomCom 2014-2015 Call for Volunteers Päiväys: Fri, 16 May 2014 10:20:56 -0400 Lähettäjä: Michael Richardson Vastausosoite: mcr+nomcom@sandelman.ca Vastaanottaja: ietf@ietf.org The IETF nominating committee (nomcom) process for 2014-15 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG (including IETF Chair). Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. Let's break the 200 volunteer mark again this year! The details of the operation of the nomcom can be found in RFC 3777, and BCP10/RFC3797 details the selection algorithm. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended *three* are IETF 85(Atlanta), \ 86(Orlando), \ 87(Berlin), *** ANY THREE! 88(Vancouver), / 89(London) / If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2015 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: To be confirmed IAB: Joel Halpern Russ Housley Eliot Lear Xing Li Andrew Sullivan Dave Thaler IESG: Pete Resnick (Applications) Ted Lemon (Internet) Joel Jaeggli (Operations and Management) Richard Barnes (RAI) Adrian Farrel* (Routing) Stephen Farrell (Security) Spencer Dawkins (Transport) Jari Arkko (Gen) (names with * have publically indicated they will not serve another term) The primary activity for this nomcom will begin in July 2014 and should be completed in January 2015. The nomcom will have regularly scheduled conference calls to ensure progress. (We might dogfood WebRTC) There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment; but it is also a very rewarding experience. It is very important that you be able to attend IETF91 to conduct interviews. Being at IETF90 is useful for training. Being at IETF92 is not essential. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 22, 2013, as follows: To: nomcom-chair-2014@ietf.org Subject: Nomcom 2014-15 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Questions by email or voice are welcome. Volunteering for the nomcom is a great way to contribute to the IETF! You can find a detailed timeline on the nomcom web site at: https://datatracker.ietf.org/nomcom/2014/ I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Michael Richardson mcr+nomcom@sandelman.ca nomcom-chair-2014@ietf.org --------------090304080803030905010003 Content-Type: application/pgp-signature; name="Liitetty viestin osa" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Liitetty viestin osa" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0NClZlcnNpb246IEdudVBHIHYxLjQuMTIg KEdOVS9MaW51eCkNCg0KaVFFVkF3VUJVM1lleDRDTGNQdmQwTjFsQVFMYVVRZ0FwbUt6elh4 Tk55aFhvcDY1VkxaVnFjL3dKL1BBY0xvcw0KWTBlY1lneFY5SHJ3UGF6QkdaMDU0M0NPTGkv Zm15M3dIMVhqY1QwK3VqSnRkcmZGMTZxODNMSStucEVvclV1MA0KS3lYclAwOVM2bWhlRkF6 Q3VkUk1tQ1UzektIUzdqK3FxNEFHMGhFeUo0Q0pUVnhiMEl5MEpDMzVTaDcxRW5kVA0Kb0R2 T29oRXVUbHAwdnFrZUg3LzNPVnRDekxmcnZoRXFKMDNNWERYZ1BGaE8vb2JDTk9EM3cxdC9u TWZBOGhjcg0KUGxQOVBGQVl0dEdWMWtBLzEvTllhM1NYUDljdUo3NjJMb2NGNDFoaUhsMU5Y dkVYdXZjYVZIV3dtWUlqQ05aVw0KYzR5SkV3bkhkcWUreFVKTFlZUHhvY0ZwT0dWTENuOE4w djExaGt1bmVFS0QvdWVkMEV0ZzV3PT0NCj1CZlY5DQotLS0tLUVORCBQR1AgU0lHTkFUVVJF LS0tLS0NCg== --------------090304080803030905010003-- From nobody Mon May 19 23:06:37 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662B91A02E2 for ; Mon, 19 May 2014 23:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHQ_I-32jI6W for ; Mon, 19 May 2014 23:06:28 -0700 (PDT) Received: from mail-yh0-x232.google.com (mail-yh0-x232.google.com [IPv6:2607:f8b0:4002:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED811A0290 for ; Mon, 19 May 2014 23:06:27 -0700 (PDT) Received: by mail-yh0-f50.google.com with SMTP id 29so7683880yhl.23 for ; Mon, 19 May 2014 23:06:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FQl5b/sdOS2cH00vchCgssC6a9jTAhqhGvsFYaYTSm0=; b=fToU2C4+W/dYmvR6GxDDsWnLqNDLQBRQqNAVtKtLW+kFk+N8TCTDTYC2TmML8/GkFe 1FVQ0YiNC4Dejcu8/rI93gYjuMVYEb93mgafG8zVeItB44/AcGleO0RSVG8Op3cY4z1q 36UvuhSkHIbtKAZO8IeqJOVe0I9nM/0Si8XTWTn+SD0Ih0cRgZQlZhgxxEFK5DEf++Pz Sda4ZN2usfAnQxb6Ymkkx4wNCd49frk6K7pm5ftrbdKW/d2qrIa15ks3uRYcm20ROMTF wszbrbypXfY0nKuTUmIvtOFnR2YrT7LL8q3UAu3kr5cuHhUMFFMuyoh6n+/BMISxKsma 3uyw== MIME-Version: 1.0 X-Received: by 10.236.93.195 with SMTP id l43mr59837028yhf.40.1400565986919; Mon, 19 May 2014 23:06:26 -0700 (PDT) Received: by 10.170.155.213 with HTTP; Mon, 19 May 2014 23:06:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 May 2014 15:06:26 +0900 Message-ID: From: Satoru Matsushima To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf3010e34d228a8b04f9ceaea5 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2yR5lFc6P_riowHdxe1EoeqZ2oY Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 06:06:29 -0000 --20cf3010e34d228a8b04f9ceaea5 Content-Type: text/plain; charset=UTF-8 Hi Behcet, Sorry for my late response. Let me try to answer to your questions. > Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I guess BGP Route Update) is initiated by > which node and is going to which node? As you see step 14 in the sequence, any specific node aren't assumed to initiate routing update on vEPC side, due to the scope of the draft, EPC-E router is the receiving node of routing update > In Step 15 you have EPC-E initiating this and it is going towards RTR. Why is this not sufficient? i.e. since EPC-E > can detect mobility? > Why do you need Step 14? The reason of the EPC-E advertise route toward RTR is that EPC-E can aggregate multiple UE's prefixes into less BGP routes as a part of normal routing operation within operator's network. Step 14 makes EPC-E not to detect mobility directly. > For the uplink traffic from UE, you seem to assume that it is always towards RTR. Could it not be directed to > another UE? What happens in that case? When an EPC-E router has a route for destination of the packet from UE, the EPC-E router forward the packet to the destination. Otherwise, the packet would be forwarded along with routing table of the router. > You say that > EPC-E supports the user > plane functions of SGW and PGW. > So there is no PGW in your design, I mean no anchor PGW? Yes, there're no entities of PGW and SGW in terms of user-plane. Also in the routing point of view, since a cluster of EPC-Es share same UE routes set, each of them can be an anchor. > What happens to the control plane functions of SGW and PGW? Where are they? In terms of control-plane, they are expected to exist in the vEPC. You can see another benefit for that in section 4.2 of the draft. cheers, --satoru On Fri, May 9, 2014 at 6:25 AM, Behcet Sarikaya wrote: > Hi Matsushima-san, > > I have some other questions on your draft. > > Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I > guess BGP Route Update) is initiated by which node and is going to which > node? > > In Step 15 you have EPC-E initiating this and it is going towards RTR. Why > is this not sufficient? i.e. since EPC-E can detect mobility? > > Why do you need Step 14? > > For the uplink traffic from UE, you seem to assume that it is always > towards RTR. Could it not be directed to another UE? What happens in that > case? > > You say that > EPC-E supports the user > plane functions of SGW and PGW. > > So there is no PGW in your design, I mean no anchor PGW? > > What happens to the control plane functions of SGW and PGW? Where are they? > > Regards, > > Behcet > --20cf3010e34d228a8b04f9ceaea5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Behcet,=C2=A0

    Sorry for my late resp= onse. Let me try to answer to your questions.=C2=A0

    > Referrin= g to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I guess BGP Rou= te Update) is initiated by=C2=A0
    > which= node and is going to which node?

    As you see step 14 in the sequence, any specific node are= n't assumed to initiate routing update on vEPC side, due to the scope o= f the draft, EPC-E router is the receiving node of routing update

    > In Step 15 you have EPC-E initiating this and it is going towards= RTR. Why is this not sufficient? i.e. since EPC-E=C2=A0
    <= span style=3D"font-family:arial,sans-serif;font-size:13px">> can detect = mobility?
    >=C2=A0Why do you need Step 14?

    The reason of the EP= C-E advertise route toward RTR is that=C2=A0EPC-E can aggregate multiple UE= 's prefixes into less=C2=A0BGP routes as a part of normal routing opera= tion within operator's=C2=A0network. Step 14 makes EPC-E not to detect = mobility directly.=C2=A0

    > For the uplink traffic from UE, you seem to assume that it is alw= ays towards RTR. Could it not be directed to=C2=A0
    > another UE? What = happens in that case?

    =
    When an EPC-E router has= a route for destination of the packet from UE,=C2=A0the EPC-E router forwa= rd the packet to the destination. Otherwise,=C2=A0the packet would be=C2=A0= forwarded along with routing table of=C2=A0the router.

    > You say that=C2=A0> EPC-E supports the user
    > =C2=A0 =C2=A0 =C2=A0 plane functions = of SGW and PGW.=C2=A0
    > So there is no PGW in your design, I mean no anchor PGW?

    Yes, there're no= entities of PGW and SGW in terms of user-plane. Also in the routing point = of view, since a cluster of EPC-Es share same UE routes set, each of them c= an be an anchor.

    > What happens to t= he control plane functions of SGW and PGW? Where are they?
    <= div>
    In terms of control-plane, they are expected to exist in the v= EPC.=C2=A0You can see another benefit for that in section 4.2 of the draft.=

    cheers,
    --satoru


    <= br>
    On Fri, May 9, 2014 at 6:25 AM, Behcet Sarikaya <sarikaya2012@gmail.c= om> wrote:
    Hi Matsushima= -san,

    I have some other questions on your draft.

    Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I gues= s BGP Route Update) is initiated by which node and is going to which node?<= br>
    In Step 15 you have EPC-E initiating this and it is going towards= RTR. Why is this not sufficient? i.e. since EPC-E can detect mobility?
    =
    Why do you need Step 14?

    For the uplink traffic from= UE, you seem to assume that it is always towards RTR. Could it not be dire= cted to another UE? What happens in that case?

    You say that
    EPC-E supports the user
    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 plane functions of SGW and PGW.

    So there is no PGW = in your design, I mean no anchor PGW?

    What happens to the= control plane functions of SGW and PGW? Where are they?

    Regards,

    Behcet

    --20cf3010e34d228a8b04f9ceaea5-- From nobody Tue May 20 09:17:36 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7AA41A0152 for ; Tue, 20 May 2014 09:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B59x1H49lk4A for ; Tue, 20 May 2014 09:17:33 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696FF1A0169 for ; Tue, 20 May 2014 09:17:33 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id pn19so603761lab.34 for ; Tue, 20 May 2014 09:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BNudecaV9Vd/V68DAdpmtzGvL0/kWFX9xBxuUuaguEU=; b=PV6Zz0YhPWsNczdXYZw1xPkMPfVPkV40wNtI5i/voblXTPfrpu1m6fs4MVy9dkGyy7 5pcJNUzjJ2+yLhpHAMVJNtCN/JQQHJP+SNDQM9l/bwU0Fb9x69+doxV/mW4DxK+1jmLP b1tMLbVMsZ2vbQxokpfZT4BoJzahfvm6xsTv4SwAKdWh3OX34DfLfiLisfUEuEWW9Gto Qbet8rKbMDawgtqUWxNcUSMuZQvx/yRFtlzZYsDn8IYdvNnfgV/XC7ltrFfBoZB9Znha BhbWZKwVCnzgXDMLCkZMjKWzteRcBFa9WI49Kts9wixRwP8JTbOB0gPbLJzZMHF7m4vz kK0w== MIME-Version: 1.0 X-Received: by 10.112.73.211 with SMTP id n19mr2152149lbv.84.1400602651213; Tue, 20 May 2014 09:17:31 -0700 (PDT) Received: by 10.114.27.106 with HTTP; Tue, 20 May 2014 09:17:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 May 2014 11:17:31 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/w0TcHACwU4jYF2UJ0JQTFc8RvUg Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2014 16:17:34 -0000 Hi Satoru, Thanks for your reply. My further comments are inline. Regards, Behcet On Tue, May 20, 2014 at 1:06 AM, Satoru Matsushima wrote: > Hi Behcet, > > Sorry for my late response. Let me try to answer to your questions. > >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I >> guess BGP Route Update) is initiated by >> which node and is going to which node? > > As you see step 14 in the sequence, any specific node aren't assumed to > initiate routing update on vEPC side, due to the scope of the draft, EPC-E > router is the receiving node of routing update You mean more than one node can initiate it, my question was which node(s)? > >> In Step 15 you have EPC-E initiating this and it is going towards RTR. Why >> is this not sufficient? i.e. since EPC-E >> can detect mobility? >> Why do you need Step 14? > > The reason of the EPC-E advertise route toward RTR is that EPC-E can > aggregate multiple UE's prefixes into less BGP routes as a part of normal > routing operation within operator's network. You mean host routes are not needed in the upstream BGP routers? How does that work? >Step 14 makes EPC-E not to > detect mobility directly. I understand that. > >> For the uplink traffic from UE, you seem to assume that it is always >> towards RTR. Could it not be directed to >> another UE? What happens in that case? > > When an EPC-E router has a route for destination of the packet from UE, the > EPC-E router forward the packet to the destination. You mean to another EPC-E? > Otherwise, the packet > would be forwarded along with routing table of the router. > >> You say that >> EPC-E supports the user >> plane functions of SGW and PGW. >> So there is no PGW in your design, I mean no anchor PGW? > > Yes, there're no entities of PGW and SGW in terms of user-plane. Also in the > routing point of view, since a cluster of EPC-Es share same UE routes set, > each of them can be an anchor. > >> What happens to the control plane functions of SGW and PGW? Where are >> they? > > In terms of control-plane, they are expected to exist in the vEPC. You can > see another benefit for that in section 4.2 of the draft. > > cheers, > --satoru > > > > On Fri, May 9, 2014 at 6:25 AM, Behcet Sarikaya > wrote: >> >> Hi Matsushima-san, >> >> I have some other questions on your draft. >> >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I >> guess BGP Route Update) is initiated by which node and is going to which >> node? >> >> In Step 15 you have EPC-E initiating this and it is going towards RTR. Why >> is this not sufficient? i.e. since EPC-E can detect mobility? >> >> Why do you need Step 14? >> >> For the uplink traffic from UE, you seem to assume that it is always >> towards RTR. Could it not be directed to another UE? What happens in that >> case? >> >> You say that >> EPC-E supports the user >> plane functions of SGW and PGW. >> >> So there is no PGW in your design, I mean no anchor PGW? >> >> What happens to the control plane functions of SGW and PGW? Where are >> they? >> >> Regards, >> >> Behcet > > From nobody Tue May 20 18:47:07 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6831A0400 for ; Tue, 20 May 2014 18:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nz8SMmOraeDV for ; Tue, 20 May 2014 18:47:04 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9007C1A03F6 for ; Tue, 20 May 2014 18:47:04 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 9so1066442ykp.41 for ; Tue, 20 May 2014 18:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F7H0A+e4vGFQA7zQ4fF5WwKii9S0brujsAMa7ID7vaA=; b=C5l137FXh9OeluR0dKX+/5Yt/SGYFnBfEtQPnBYoXfU7ZdPx24nM1c8FJOsdzAbB3c +/KW+v1XbqtspOM4xPhzwWt6zuu3/xny70FPEpHZcm1ZzZxytSJlCp2WW9HSZZPktI0y H5MelOkWnO2mVx+wmXzXTSixJVoTC0TLtCBoCbpkYP+P1Y6s7lv3QrvGo0abvmPI8wVW MabtH1OmYbSCbJoc7aFaVKuHiG47tBHQD4l/8MNqylQKdbnKfBWy4XFGf6Gul4qH/FEb y/3S2uk7Ih7jYOTK8XuaFIiUVmu+si09XSnTO+JEc3qy4cP8EBYQteRMZOLsqhBY4yZt EYkA== MIME-Version: 1.0 X-Received: by 10.236.156.170 with SMTP id m30mr29153492yhk.60.1400636823500; Tue, 20 May 2014 18:47:03 -0700 (PDT) Received: by 10.170.155.213 with HTTP; Tue, 20 May 2014 18:47:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 10:47:03 +0900 Message-ID: From: Satoru Matsushima To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf303a2f8152ffb104f9df2cba Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/D03LxIUZUVlLyv67CzzvELU7Rlk Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 01:47:06 -0000 --20cf303a2f8152ffb104f9df2cba Content-Type: text/plain; charset=UTF-8 Hi Behcet, On Wed, May 21, 2014 at 1:17 AM, Behcet Sarikaya wrote: -- snip -- > > > >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I > >> guess BGP Route Update) is initiated by > >> which node and is going to which node? > > > > As you see step 14 in the sequence, any specific node aren't assumed to > > initiate routing update on vEPC side, due to the scope of the draft, > EPC-E > > router is the receiving node of routing update > > You mean more than one node can initiate it, my question was which node(s)? > > I meant that the draft doesn't mention exactly which node advertise that, it could be expected to exist in the vEPC side. But I find that in terms of usual BGP operation, that node could be Route-Reflector(RR), or Route-Server(RS). Just one case would be expected that a set of information which includes an endpoint information of tunnel and an UE assigned prefix is informed from a mobility management node in the vEPC to RR or RS. > > > >> In Step 15 you have EPC-E initiating this and it is going towards RTR. > Why > >> is this not sufficient? i.e. since EPC-E > >> can detect mobility? > >> Why do you need Step 14? > > > > The reason of the EPC-E advertise route toward RTR is that EPC-E can > > aggregate multiple UE's prefixes into less BGP routes as a part of normal > > routing operation within operator's network. > > You mean host routes are not needed in the upstream BGP routers? How > does that work? > Yes, host routes are not needed in the upstream routers because aggregated routes EPC-E router advertised work well for the upstream routers to send out packets toward advertising EPC-E routers. > > >Step 14 makes EPC-E not to > > detect mobility directly. > > I understand that. > > > > >> For the uplink traffic from UE, you seem to assume that it is always > >> towards RTR. Could it not be directed to > >> another UE? What happens in that case? > > > > When an EPC-E router has a route for destination of the packet from UE, > the > > EPC-E router forward the packet to the destination. > > You mean to another EPC-E? > > I just meant that the packets are always forwarded along with the routing table of each node. cheers, --satoru --20cf303a2f8152ffb104f9df2cba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Behcet,


    On Wed, May 21, 2014 at 1:17 AM, Behcet Sarikaya <= span dir=3D"ltr"><sarikaya2012@gmail.com> wrote:
    -- snip --
    =C2=A0
    >
    >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update= (I
    >> guess BGP Route Update) is initiated by
    >> which node and is going to which node?
    >
    > As you see step 14 in the sequence, any specific node aren't assum= ed to
    > initiate routing update on vEPC side, due to the scope of the draft, E= PC-E
    > router is the receiving node of routing update

    You mean more than one node can initiate it, my question was which no= de(s)?


    I meant that the= draft doesn't mention exactly which node advertise that, it could be e= xpected to exist in the vEPC side. But I find that in terms of usual BGP op= eration, that node could be Route-Reflector(RR), or Route-Server(RS).
    Just one case would be expected that a set of information which includ= es an endpoint information of tunnel and an UE assigned prefix is informed = from a mobility management node in the vEPC to RR or RS.

    =C2=A0
    >
    >> In Step 15 you have EPC-E initiating this and it is going towards = RTR. Why
    >> is this not sufficient? i.e. since EPC-E
    >> can detect mobility?
    >> Why do you need Step 14?
    >
    > The reason of the EPC-E advertise route toward RTR is that EPC-E can > aggregate multiple UE's prefixes into less BGP routes as a part of= normal
    > routing operation within operator's network.

    You mean host routes are not needed in the upstream BGP routers? How<= br> does that work?

    Yes, host routes are no= t needed in the upstream routers because aggregated routes EPC-E router adv= ertised work well for the upstream routers to send out packets toward adver= tising EPC-E routers.

    =C2=A0

    >Step 14 makes EPC-E not to
    > detect mobility directly.

    I understand that.

    >
    >> For the uplink traffic from UE, you seem to assume that it is alwa= ys
    >> towards RTR. Could it not be directed to
    >> another UE? What happens in that case?
    >
    > When an EPC-E router has a route for destination of the packet from UE= , the
    > EPC-E router forward the packet to the destination.

    You mean to another EPC-E?

    <= br>
    I just meant that the packets are always forwarded along with= the routing table of each node.=C2=A0

    cheers,
    --satoru
    --20cf303a2f8152ffb104f9df2cba-- From nobody Wed May 21 08:58:31 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6551A073F for ; Wed, 21 May 2014 08:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SA32Sw5usC8d for ; Wed, 21 May 2014 08:58:28 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703251A0769 for ; Wed, 21 May 2014 08:58:23 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id mc6so1760447lab.35 for ; Wed, 21 May 2014 08:58:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=SbZ4JbnYN/3z5/7eF8LDPW4lSKp+0Khv0kIUtt14YOU=; b=0h2m5cPp56UjnxdZMHBedLtH393IljybmpcOgPgfXbTyYj30xorh2kW4a1cYVVImEJ TOsr6p6bvzunHAXF1g0VQbCzmoeQxXBIODZYYhSLfvqUlSlcN9pO0qynDNdKmuLZ/zr7 kUuvxQpwukpxHolTP9Hfb1DELnyJoznjS90Epq9ypdKN9viJseIW9MH26yoiJrFWcjvM 1SN35gKt6CQb2QHBL0oEvTTHM1/MLqhMqi0cPFR3ODmQGYsZDTvOuhLU8yrEd4tplQ0W i3gbLJHeHcs+LC44Ruy0ukEL3p9bT9qkmGfjb9oD4BB9nVyzXIaU1gTsKaM6buCfuXjv UV5Q== MIME-Version: 1.0 X-Received: by 10.152.4.1 with SMTP id g1mr38591191lag.20.1400687901085; Wed, 21 May 2014 08:58:21 -0700 (PDT) Received: by 10.114.27.106 with HTTP; Wed, 21 May 2014 08:58:20 -0700 (PDT) In-Reply-To: References: Date: Wed, 21 May 2014 10:58:20 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8tZk6wVmBzwnslgOBEfGJSK6PXo Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 15:58:28 -0000 Hi Satoru, Thanks again. Please see my replies inline. Regards, Behcet On Tue, May 20, 2014 at 8:47 PM, Satoru Matsushima wrote: > Hi Behcet, > > > On Wed, May 21, 2014 at 1:17 AM, Behcet Sarikaya > wrote: > -- snip -- > >> >> > >> >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I >> >> guess BGP Route Update) is initiated by >> >> which node and is going to which node? >> > >> > As you see step 14 in the sequence, any specific node aren't assumed to >> > initiate routing update on vEPC side, due to the scope of the draft, >> > EPC-E >> > router is the receiving node of routing update >> >> You mean more than one node can initiate it, my question was which >> node(s)? >> > > I meant that the draft doesn't mention exactly which node advertise that, it > could be expected to exist in the vEPC side. But I find that in terms of > usual BGP operation, that node could be Route-Reflector(RR), or > Route-Server(RS). > Just one case would be expected that a set of information which includes an > endpoint information of tunnel and an UE assigned prefix is informed from a > mobility management node in the vEPC to RR or RS. > Are you sure? How would RR or RS know about UE mobility? I was expecting you to say MME? > >> >> > >> >> In Step 15 you have EPC-E initiating this and it is going towards RTR. >> >> Why >> >> is this not sufficient? i.e. since EPC-E >> >> can detect mobility? >> >> Why do you need Step 14? >> > >> > The reason of the EPC-E advertise route toward RTR is that EPC-E can >> > aggregate multiple UE's prefixes into less BGP routes as a part of >> > normal >> > routing operation within operator's network. >> >> You mean host routes are not needed in the upstream BGP routers? How >> does that work? > > > Yes, host routes are not needed in the upstream routers because aggregated > routes EPC-E router advertised work well for the upstream routers to send > out packets toward advertising EPC-E routers. > Isn't it kind of host routes? Maybe host prefixes? Otherwise I can not image how you would route to UEs that are topologically incorrect? > >> >> >> >Step 14 makes EPC-E not to >> > detect mobility directly. >> >> I understand that. >> >> > >> >> For the uplink traffic from UE, you seem to assume that it is always >> >> towards RTR. Could it not be directed to >> >> another UE? What happens in that case? >> > >> > When an EPC-E router has a route for destination of the packet from UE, >> > the >> > EPC-E router forward the packet to the destination. >> >> You mean to another EPC-E? >> > > I just meant that the packets are always forwarded along with the routing > table of each node. > Yes, I think that the packet to another UE would be routed downstream before reaching the RTR. > cheers, > --satoru From nobody Wed May 21 19:49:31 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A801A0078 for ; Wed, 21 May 2014 19:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wQeNG8OWNnX for ; Wed, 21 May 2014 19:49:28 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BD51A006D for ; Wed, 21 May 2014 19:49:28 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id b6so2467632yha.31 for ; Wed, 21 May 2014 19:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lYzrQYNcdSAbm3OnFijZX1NzeRIGcDCGjP/cJwS920s=; b=QoplVtqEAdiUq7pjImJ1Yr1cO6gM/M275efKNM7C4CEYu5MaVPoWYDnHMKabLnpIyU MwD5n8ATOf8ymEmalCIMxbft+2UQtXnWSOeAlmKL38m90MpgOb6iwMY53YHYSkL1v+5A oZuzFNa0DaGiWBX67FRR4PaiyC39GRAfaH5ieoGhKheOani4lFRsHIoYa4LDlelO7oa2 8tgf3SNBTbDZqgaX1tj/JjGJqV+H2bKRM+vPtvCHtvE3AaBhB/axHcwB7bPoEs/tPGqh FNouUGvWqogAyxPU8LFokldTEsW0KribBSY7WFxnZDtkn8/7P6ACATrA0u7kfGWw9/Ts Pddw== MIME-Version: 1.0 X-Received: by 10.236.172.170 with SMTP id t30mr32197287yhl.136.1400726967078; Wed, 21 May 2014 19:49:27 -0700 (PDT) Received: by 10.170.155.213 with HTTP; Wed, 21 May 2014 19:49:27 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 11:49:27 +0900 Message-ID: From: Satoru Matsushima To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf30426ef04d35eb04f9f4299a Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/glteYOOV1o0rOTkdMByfRqM3s0M Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 02:49:30 -0000 --20cf30426ef04d35eb04f9f4299a Content-Type: text/plain; charset=UTF-8 Hi Behcet, On Thu, May 22, 2014 at 12:58 AM, Behcet Sarikaya wrote: -- snip -- > >> >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I > >> >> guess BGP Route Update) is initiated by > >> >> which node and is going to which node? > >> > > >> > As you see step 14 in the sequence, any specific node aren't assumed > to > >> > initiate routing update on vEPC side, due to the scope of the draft, > >> > EPC-E > >> > router is the receiving node of routing update > >> > >> You mean more than one node can initiate it, my question was which > >> node(s)? > >> > > > > I meant that the draft doesn't mention exactly which node advertise > that, it > > could be expected to exist in the vEPC side. But I find that in terms of > > usual BGP operation, that node could be Route-Reflector(RR), or > > Route-Server(RS). > > Just one case would be expected that a set of information which includes > an > > endpoint information of tunnel and an UE assigned prefix is informed > from a > > mobility management node in the vEPC to RR or RS. > > > > Are you sure? > How would RR or RS know about UE mobility? > > I was expecting you to say MME? > > Ah, I see what you mean. Yes, I'm sure that RR/RS just only know about routes, nor whole mobility information exists. When I see a node which plays MME role, the node could also be a BGP speaker to export the mobility info transformed to the routes. > > > >> > >> > > >> >> In Step 15 you have EPC-E initiating this and it is going towards > RTR. > >> >> Why > >> >> is this not sufficient? i.e. since EPC-E > >> >> can detect mobility? > >> >> Why do you need Step 14? > >> > > >> > The reason of the EPC-E advertise route toward RTR is that EPC-E can > >> > aggregate multiple UE's prefixes into less BGP routes as a part of > >> > normal > >> > routing operation within operator's network. > >> > >> You mean host routes are not needed in the upstream BGP routers? How > >> does that work? > > > > > > Yes, host routes are not needed in the upstream routers because > aggregated > > routes EPC-E router advertised work well for the upstream routers to send > > out packets toward advertising EPC-E routers. > > > > Isn't it kind of host routes? Maybe host prefixes? Otherwise I can not > image how you would route to UEs that are topologically incorrect? > What do you mean by "topologically incorrect"? Is that the assigned prefixes are disordered to be aggregated? cheers, --satoru --20cf30426ef04d35eb04f9f4299a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Behcet,=C2=A0


    On Thu, May 22, 2014 at 12:58 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrote:
    -- snip --
    =C2=A0
    >> >> Referring to Steps 14 and 15 in Figure 4, in St= ep 14, Route Update (I
    >> >> guess BGP Route Update) is initiated by
    >> >> which node and is going to which node?
    >> >
    >> > As you see step 14 in the sequence, any specific node aren= 9;t assumed to
    >> > initiate routing update on vEPC side, due to the scope of the= draft,
    >> > EPC-E
    >> > router is the receiving node of routing update
    >>
    >> You mean more than one node can initiate it, my question was which=
    >> node(s)?
    >>
    >
    > I meant that the draft doesn't mention exactly which node advertis= e that, it
    > could be expected to exist in the vEPC side. But I find that in terms = of
    > usual BGP operation, that node could be Route-Reflector(RR), or
    > Route-Server(RS).
    > Just one case would be expected that a set of information which includ= es an
    > endpoint information of tunnel and an UE assigned prefix is informed f= rom a
    > mobility management node in the vEPC to RR or RS.
    >

    Are you sure?
    How would RR or RS know about UE mobility?

    I was expecting you to say MME?


    Ah, I see what y= ou mean. Yes, I'm sure that RR/RS just only know about routes, nor whol= e mobility information exists. When I see a node which plays MME role, the = node could also be a BGP speaker to export the mobility info transformed to= the routes.=C2=A0

    =C2=A0
    >
    >>
    >> >
    >> >> In Step 15 you have EPC-E initiating this and it is going= towards RTR.
    >> >> Why
    >> >> is this not sufficient? i.e. since EPC-E
    >> >> can detect mobility?
    >> >> Why do you need Step 14?
    >> >
    >> > The reason of the EPC-E advertise route toward RTR is that EP= C-E can
    >> > aggregate multiple UE's prefixes into less BGP routes as = a part of
    >> > normal
    >> > routing operation within operator's network.
    >>
    >> You mean host routes are not needed in the upstream BGP routers? H= ow
    >> does that work?
    >
    >
    > Yes, host routes are not needed in the upstream routers because aggreg= ated
    > routes EPC-E router advertised work well for the upstream routers to s= end
    > out packets toward advertising EPC-E routers.
    >

    Isn't it kind of host routes? Maybe host prefixes? Otherwise I ca= n not
    image how you would route to UEs that are topologically incorrect?

    What do you mean by "topologically incorre= ct"?
    Is that the assigned prefixes are disordered to be aggr= egated?

    cheers,
    --satoru
    --20cf30426ef04d35eb04f9f4299a-- From nobody Thu May 22 12:16:20 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E977A1A0302 for ; Thu, 22 May 2014 12:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHj8V_O0Q9U9 for ; Thu, 22 May 2014 12:16:05 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD7D61A0301 for ; Thu, 22 May 2014 12:16:01 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 200so3217474ykr.0 for ; Thu, 22 May 2014 12:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Z29vdLzKMYRf+CHafvo9wtwR+P4+B/g8OzKxJOVMvhc=; b=fAV+zBVnSv2fPsHmuDxMIhzgaixEvmX6Vtat4sePz5knWNeQz5rOKx+yuuOjJJJhMC YvQp0i1OL/F8+q0rJYv11FZrf+RfI0f+CZgHO4WfI+VcjbZbURuOGlA6IZlasCmtwc8+ NVnMJVquEJbpDRW9GC5HqBksM0NzGhjYL2aUqhJUn2iUs0ZD603V4Pu4fKi6B1RDr7ih IVOHfIk0nrt7vzUWgTOnQCTZCCCwwLUKPt2ImFzGCVLYqTtQnBu3sWYTaa+AGuXvx8PZ b0Ju/JswMvDQ7biH/03JEZWF8fbHu1lOExVbyN3yESEtebCkuq+xl3uXMs8KhURzK/Ka hMyw== MIME-Version: 1.0 X-Received: by 10.236.42.43 with SMTP id i31mr86663362yhb.31.1400786160030; Thu, 22 May 2014 12:16:00 -0700 (PDT) Received: by 10.170.126.18 with HTTP; Thu, 22 May 2014 12:15:59 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 May 2014 14:15:59 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Gfyw7Js6ywTEMUcNYdyOcKE7XeE Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 19:16:07 -0000 On Wed, May 21, 2014 at 9:49 PM, Satoru Matsushima wrote: > Hi Behcet, > > > On Thu, May 22, 2014 at 12:58 AM, Behcet Sarikaya > wrote: > -- snip -- > >> >> >> >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update >> >> >> (I >> >> >> guess BGP Route Update) is initiated by >> >> >> which node and is going to which node? >> >> > >> >> > As you see step 14 in the sequence, any specific node aren't assumed >> >> > to >> >> > initiate routing update on vEPC side, due to the scope of the draft, >> >> > EPC-E >> >> > router is the receiving node of routing update >> >> >> >> You mean more than one node can initiate it, my question was which >> >> node(s)? >> >> >> > >> > I meant that the draft doesn't mention exactly which node advertise >> > that, it >> > could be expected to exist in the vEPC side. But I find that in terms of >> > usual BGP operation, that node could be Route-Reflector(RR), or >> > Route-Server(RS). >> > Just one case would be expected that a set of information which includes >> > an >> > endpoint information of tunnel and an UE assigned prefix is informed >> > from a >> > mobility management node in the vEPC to RR or RS. >> > >> >> Are you sure? >> How would RR or RS know about UE mobility? >> >> I was expecting you to say MME? >> > > Ah, I see what you mean. Yes, I'm sure that RR/RS just only know about > routes, nor whole mobility information exists. When I see a node which plays > MME role, the node could also be a BGP speaker to export the mobility info > transformed to the routes. > So MME should be BGP speaker? If not then what would happen? > >> >> > >> >> >> >> > >> >> >> In Step 15 you have EPC-E initiating this and it is going towards >> >> >> RTR. >> >> >> Why >> >> >> is this not sufficient? i.e. since EPC-E >> >> >> can detect mobility? >> >> >> Why do you need Step 14? >> >> > >> >> > The reason of the EPC-E advertise route toward RTR is that EPC-E can >> >> > aggregate multiple UE's prefixes into less BGP routes as a part of >> >> > normal >> >> > routing operation within operator's network. >> >> >> >> You mean host routes are not needed in the upstream BGP routers? How >> >> does that work? >> > >> > >> > Yes, host routes are not needed in the upstream routers because >> > aggregated >> > routes EPC-E router advertised work well for the upstream routers to >> > send >> > out packets toward advertising EPC-E routers. >> > >> >> Isn't it kind of host routes? Maybe host prefixes? Otherwise I can not >> image how you would route to UEs that are topologically incorrect? > > > What do you mean by "topologically incorrect"? > Is that the assigned prefixes are disordered to be aggregated? > Yes. UE moves to another EPC-E which supports a different prefix than UE has? You need to keep host-based prefixes as routes, is there another way? Regards, Behcet > cheers, > --satoru From nobody Fri May 23 01:39:27 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4871A03DA for ; Fri, 23 May 2014 01:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhRY6T5ruOys for ; Fri, 23 May 2014 01:39:24 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C0891A03D9 for ; Fri, 23 May 2014 01:39:23 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so3945163yha.40 for ; Fri, 23 May 2014 01:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sq8fIVIw/8tQWZJDJhlO9cpdAvQkyNPJwPzPd+ta+Rc=; b=RQ2LC/Q0CN4rMG7EiixP460WQguMDKnQ0gvS9D15Cblr9AQCMmPh75AQJXeo5wNUQ9 KpBL/I9+tBhf2zBDC5isAOYJgDTPC7ApG1kFsSpE9nmHxKqtaz2lJk6KnwjkwIiRXpR3 tNsfWmZuOi7qRffzYLr5fmGqPWUhieRjXzpPCVTeARVTWKGOB+Oe+E9LhXEBGTMQhLBk EHDslbXQpF3Bkc0v3bMnD1dptqF0++FR/nUbqkv1Swwx2WZKZJuh//iS9dVYNK3V/rmB hVGF4l3NwUBE9fL0TJXxABxjiTxYouxkK2NhWBXbzpoV2K6QYfcoXroYe+t1+I0dunGN /rDA== MIME-Version: 1.0 X-Received: by 10.236.114.193 with SMTP id c41mr1602995yhh.156.1400834360928; Fri, 23 May 2014 01:39:20 -0700 (PDT) Received: by 10.170.155.213 with HTTP; Fri, 23 May 2014 01:39:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 May 2014 17:39:20 +0900 Message-ID: From: Satoru Matsushima To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf303b3fe778ede304fa0d2aa7 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/xToo6c6T3IrXRQjqoRQyzLQnmb4 Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 08:39:25 -0000 --20cf303b3fe778ede304fa0d2aa7 Content-Type: text/plain; charset=UTF-8 Behcet, thanks for clarifying more clearly. :) On Fri, May 23, 2014 at 4:15 AM, Behcet Sarikaya wrote: -- snip -- > > > > > Ah, I see what you mean. Yes, I'm sure that RR/RS just only know about > > routes, nor whole mobility information exists. When I see a node which > plays > > MME role, the node could also be a BGP speaker to export the mobility > info > > transformed to the routes. > > > > So MME should be BGP speaker? > If not then what would happen? > > Precisely, say MME, which 3GPP defined mobility management entity, doesn't have the BGP function. IMO, If the entity can be coexist with BGP in a single node, an interface for exposing/retrieving mobility information would be required between them. > > What do you mean by "topologically incorrect"? > > Is that the assigned prefixes are disordered to be aggregated? > > > > Yes. UE moves to another EPC-E which supports a different prefix than UE > has? > You need to keep host-based prefixes as routes, is there another way? > > In the draft, as long as an UE keeps same prefix during hand-over among EPC-E routers, those routers belong to a same group that is expected to preserve same prefix for the UE. It should be initial attach when the UE is attached to different EPC-E and assigned different prefix from previous one. Please read section 3.3 and 3.4 of the draft. cheers, --satoru --20cf303b3fe778ede304fa0d2aa7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Behcet, thanks for clarifying more clearly. :)


    On Fri, May 23, 2014 at= 4:15 AM, Behcet Sarikaya <sarikaya2012@gmail.com> wrot= e:
    -- snip --
    =C2= =A0
    >
    > Ah, I see what you mean. Yes, I'm sure that RR/RS just only know a= bout
    > routes, nor whole mobility information exists. When I see a node which= plays
    > MME role, the node could also be a BGP speaker to export the mobility = info
    > transformed to the routes.
    >

    So MME should be BGP speaker?
    If not then what would happen?


    Precisely, say MME, which 3= GPP defined mobility management entity, doesn't have the BGP function. = IMO, If the entity can be coexist with BGP in a single node, an interface f= or exposing/retrieving mobility information would be required between them.= =C2=A0

    =C2=A0
    > What do you mean by "topologically incorrect"?
    > Is that the assigned prefixes are disordered to be aggregated?
    >

    Yes. UE moves to another EPC-E which supports a different prefix than= UE has?
    You need to keep host-based prefixes as routes, is there another way?


    In the draft, as long as an UE keeps s= ame prefix during hand-over among EPC-E routers, those routers belong to a = same group that is expected to preserve same prefix for the UE. It should b= e initial attach when the UE is attached to different EPC-E and assigned di= fferent prefix from previous one. Please read section 3.3 and 3.4 of the dr= aft.

    cheers,
    --satoru
    --20cf303b3fe778ede304fa0d2aa7-- From nobody Fri May 23 09:23:42 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E541C1A06D4 for ; Fri, 23 May 2014 09:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uk-8kmJUCgHF for ; Fri, 23 May 2014 09:23:39 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 018DD1A0698 for ; Fri, 23 May 2014 09:23:38 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 142so4159939ykq.2 for ; Fri, 23 May 2014 09:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=od8NLY73ZJ4TubCKzxjxGzm737NBIbc2Dr3eDbczJrg=; b=I0ywgMEUgXXBB2tlrZhtNC4Qbo55OdX4J/Dh9vSNDh7yrkremBl57pmpyOvRoR/HQ0 o5j7OJtOVriVoMbuKWfhSvRrwgUWZVVVQjq0Aq/LueBvUMGAmbFf7aVtkb1LijnnW2Kv 9tsdSsKyQ6csoc/kmDVfnBVo22h2D7I4dTnLMkc9MWRZujPUtKMcgMCx3g9iWkT4FzpI RcvaYkHhzruqvGFJv0b7ETERhDPKmHKgbff2ZczN1ngezTOKh9wErGCGYU0PZeg6RYld 8w21JSLkLEcCXzMSWbNHFjJ959ZALPaJAK0g9aeoLov2zATVrQyepOYpORd9v9oddN1w wgPQ== MIME-Version: 1.0 X-Received: by 10.236.137.243 with SMTP id y79mr3530696yhi.31.1400862216843; Fri, 23 May 2014 09:23:36 -0700 (PDT) Received: by 10.170.126.18 with HTTP; Fri, 23 May 2014 09:23:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 May 2014 11:23:36 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/RPYwXequuPJ-EH8vnfsj4Pol54k Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 16:23:40 -0000 Hi Satoru, It seems most issues are resolved, except one below. Regards, Behcet On Fri, May 23, 2014 at 3:39 AM, Satoru Matsushima wrote: > Behcet, thanks for clarifying more clearly. :) > > > On Fri, May 23, 2014 at 4:15 AM, Behcet Sarikaya > wrote: > -- snip -- > >> >> > >> >> > Ah, I see what you mean. Yes, I'm sure that RR/RS just only know about >> > routes, nor whole mobility information exists. When I see a node which >> > plays >> > MME role, the node could also be a BGP speaker to export the mobility >> > info >> > transformed to the routes. >> > >> >> So MME should be BGP speaker? >> If not then what would happen? >> > > Precisely, say MME, which 3GPP defined mobility management entity, doesn't > have the BGP function. IMO, If the entity can be coexist with BGP in a > single node, an interface for exposing/retrieving mobility information would > be required between them. > > >> >> > What do you mean by "topologically incorrect"? >> > Is that the assigned prefixes are disordered to be aggregated? >> > >> >> Yes. UE moves to another EPC-E which supports a different prefix than UE >> has? >> You need to keep host-based prefixes as routes, is there another way? >> > > In the draft, as long as an UE keeps same prefix during hand-over among > EPC-E routers, those routers belong to a same group that is expected to > preserve same prefix for the UE. It should be initial attach when the UE is > attached to different EPC-E and assigned different prefix from previous one. > Please read section 3.3 and 3.4 of the draft. > Attach is OK but I am talking about handover. In Section 3.4 you say: Thus, UE's address is unchanged even after handover. I don't understand your statement those routers belong to a same group that is expected to preserve same prefix for the UE. I think you mentioned this before in another conversation that EPC-E's will be assigned prefixes based on geographical division. If a UE moves to a different region, how could the routers preserve the same prefix for the UE without host routes or host prefixes? Regards, Behcet > cheers, > --satoru From nobody Sun May 25 20:13:37 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC0B1A0446; Sun, 25 May 2014 20:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfnrZ1OnbzNA; Sun, 25 May 2014 20:13:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C84C1A0434; Sun, 25 May 2014 20:13:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.2.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140526031332.9415.12165.idtracker@ietfa.amsl.com> Date: Sun, 25 May 2014 20:13:32 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/IJvZk2h3VCUVMWiscWhBmI8sm4o Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analysis-04.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:13:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management Working Group of the IETF. Title : Distributed Mobility Management: Current practices and gap analysis Authors : Dapeng Liu Juan Carlos Zuniga Pierrick Seite H Anthony Chan Carlos J. Bernardos Filename : draft-ietf-dmm-best-practices-gap-analysis-04.txt Pages : 28 Date : 2014-05-25 Abstract: The present document analyzes deployment practices of existing IP mobility protocols in a distributed mobility management environment. It then identifies existing limitations when compared to the requirements defined for a distributed mobility management solution. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun May 25 20:40:03 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B561A044B for ; Sun, 25 May 2014 20:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRpEPZPKIdu2 for ; Sun, 25 May 2014 20:40:01 -0700 (PDT) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23AAD1A0448 for ; Sun, 25 May 2014 20:40:00 -0700 (PDT) Received: by mail-lb0-f174.google.com with SMTP id n15so3925630lbi.19 for ; Sun, 25 May 2014 20:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=htm5BwE0zwKYiRy7uXFmyrQiW7L7yD3aWVJ3OMpmhc0=; b=RxdNZ4FE9o/TAB6iyfg+L+zB3g3c4v6Xg3MEAr0AIJnuVFkqVocNfcMwZswWaJZuqT arwJuaqtiMnCFqq/yw4d04wGHl2TCLX/X4zAGHokYwGwk4VCf7J8RZTdc1CpeHFj3ijl 01dPfB+/Q1kTPhSWM75Sl+EgxG5Tkd7nCjCwFOopl1oRFYxGtVeoSjUmEOI4WrRizGvO zER1s1fbKUvhEoRo9sNcpVCLx7YMndN2qwbJHJKbVKbOkqt41BELiaQkANbJANoh/ap5 TaEIjAGAyRk6dYtz55YPAdQkxCh8+YGa9JfKk1AcNWo5UJVRT9WjuKcbXT0Ghp5uwtGw QBPA== X-Received: by 10.112.52.167 with SMTP id u7mr14256170lbo.28.1401075596734; Sun, 25 May 2014 20:39:56 -0700 (PDT) Received: from [10.222.29.178] ([82.203.205.227]) by mx.google.com with ESMTPSA id sq7sm10842580lbb.10.2014.05.25.20.39.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 25 May 2014 20:39:56 -0700 (PDT) Message-ID: <5382B78C.5060409@gmail.com> Date: Mon, 26 May 2014 06:39:56 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/SW-pucD0QFhh2_G02KsMX46QAB4 Cc: "dmm-chairs@tools.ietf.org" Subject: [DMM] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 03:40:02 -0000 Folks, This email starts a one week WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04. Issue you comments to the mailing list and place possible tickets to the issue tracker. There are quite a few changed mainly to tackle Charlie's comments. The WGLC ends 2ns June 2014 EOB (EEST). Silence is accounted as an acceptance for the content. - Jouni (as a DMM co-chair) From nobody Mon May 26 19:27:34 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013A81A02F8 for ; Mon, 26 May 2014 19:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZUvDoRTi1CE for ; Mon, 26 May 2014 19:27:31 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9974E1A02F4 for ; Mon, 26 May 2014 19:27:31 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id 29so6998133yhl.19 for ; Mon, 26 May 2014 19:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o2aMuvAPW6WJDvSM3bXevkMf6WhiHtZd50hG5pwHHEM=; b=PyZsAN+7CN5G2G9Dh+409YGgD63q8Dv7bjlMX0b7WqKLov1TB9QvHFn4pHOz/U2AL1 rCfkyBlnLyxKGR8GQeUvtgCQ4GdKv6ZYLN3hWlpKLrvLUTOInfxQrdwikVdurWxncJmm Jvz1Hw9crdcTValpVK3XJD6gBybpCHA8Lcon54nEoBeD3Q9sD9uqY4TRcRfQx1iNRpc/ 9LTadhIu7iQKZ3lczC1mp2GvGgCADaMf9hfXZxLnTS8LSuqMlacLEHZURzk1VKTdN4HY cPmK9qD1D1wK8bI361sW/xEFvYgY4JEOjNoCN1+KvDf8OgT2jYSMIXQYOerEUQHavM/s h6sQ== MIME-Version: 1.0 X-Received: by 10.236.137.243 with SMTP id y79mr36694108yhi.31.1401157648260; Mon, 26 May 2014 19:27:28 -0700 (PDT) Received: by 10.170.155.213 with HTTP; Mon, 26 May 2014 19:27:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 May 2014 11:27:28 +0900 Message-ID: From: Satoru Matsushima To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=20cf303a2b5be6227104fa586ff6 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/7N-DGKEvnuh-E6hKa9BQ8VI5T3w Cc: "dmm@ietf.org" Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 02:27:33 -0000 --20cf303a2b5be6227104fa586ff6 Content-Type: text/plain; charset=UTF-8 Hi Behcet, On Sat, May 24, 2014 at 1:23 AM, Behcet Sarikaya wrote: -- snip -- > > > > In the draft, as long as an UE keeps same prefix during hand-over among > > EPC-E routers, those routers belong to a same group that is expected to > > preserve same prefix for the UE. It should be initial attach when the UE > is > > attached to different EPC-E and assigned different prefix from previous > one. > > Please read section 3.3 and 3.4 of the draft. > > > > Attach is OK but I am talking about handover. In Section 3.4 you say: > Thus, UE's address > is unchanged even after handover. > > I don't understand your statement > those routers belong to a same group that is expected to > preserve same prefix for the UE. > > I think you mentioned this before in another conversation that EPC-E's > will be assigned prefixes based on geographical division. If a UE > moves to a different region, how could the routers preserve the same > prefix for the UE without host routes or host prefixes? > > That's true geographical prefix could be a type of operation policy, but it doesn't mean connectivity within the access and core network are also divided geographically. If connectivity is also divided by the area, the UE prefix must be re-assinged when the handover across the area. But that's an operation matter. If it's not, which is my thought, the EPC-E routers that belong to one group can be reachable from eNBs during UE handover, the control-plane doesn't need to change the tunnel endpoint address. Since that address is an anycast address shared among the EPC-Es, all packets come from UE are continuously forwarded to same EPC-E group. So the UE can keep same prefix. cheers, --satoru --20cf303a2b5be6227104fa586ff6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Behcet,


    On Sat, May 24, 2014 at 1:23 AM, Behcet Sarikaya <= sarikaya2012@gmail.com> wrote:
    -- snip --=C2=A0
    >
    > In the draft, as long as an UE keeps same prefix during hand-over amon= g
    > EPC-E routers, those routers belong to a same group that is expected t= o
    > preserve same prefix for the UE. It should be initial attach when the = UE is
    > attached to different EPC-E and assigned different prefix from previou= s one.
    > Please read section 3.3 and 3.4 of the draft.
    >

    Attach is OK but I am talking about handover. In Section 3.4 yo= u say:
    Thus, UE's address
    =C2=A0 =C2=A0is unchanged even after handover.

    I don't understand your statement
    those routers belong to a same group that is expected to =C2=A0preserve same prefix for the UE.

    I think you mentioned this before in another conversation that EPC-E&= #39;s
    will be assigned prefixes based on geographical division. If a UE
    moves to a different region, how could the routers preserve the same
    prefix for the UE without host routes or host prefixes?


    That's true geographical prefix co= uld be a type of operation policy, but it doesn't mean connectivity wit= hin the access and core network are also divided geographically. If connect= ivity is also divided by the area, the UE prefix must be re-assinged when t= he handover across the area. But that's an operation matter.=C2=A0

    If it's not, which is my thought, the EPC-E routers= that belong to one group can be reachable from eNBs during UE handover, = =C2=A0the control-plane doesn't need to change the tunnel endpoint addr= ess. Since that address is an anycast address shared among the EPC-Es, all = packets come from UE are continuously forwarded to same EPC-E group. So the= UE can keep same prefix.=C2=A0

    cheers,
    --satoru
    --20cf303a2b5be6227104fa586ff6-- From nobody Tue May 27 01:51:04 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691841A002D for ; Tue, 27 May 2014 01:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vCFUvSAootTy for ; Tue, 27 May 2014 01:51:01 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD451A0049 for ; Tue, 27 May 2014 01:50:56 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id mc6so6291722lab.16 for ; Tue, 27 May 2014 01:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=uqe7/sgaFrVyL/fSNxpq6J7m9PjA8ClgGw38BhjxJ2k=; b=o/cMUgAXWzXqLI+4RJUO+/krWjhWL20JeL50PqGZ1Xv91tyB5CBfdaw3ZOzcmIoWl9 4l3WvbbobLTWpYMcEn8kQMA+TYwSxi3QriJ3DUHE6fUjDagt2TYO1dF5uXu9w7Qp2KTH Hw2XO/Ye615tpHYsAOWRKPP2GT/GKHZLkKTNUAiuajolwUqUimvQlFvgkJV7pxk8Kqug 2YvqMXYGmZQkW5YSjVdfm1g8Xq2a111+3t8PTFI7aZi0GzPGOq5qej1jv0mBXeM4NApf azHspmQfLOuHRiJIWpsqkTJtk9x8Gd3WQ9atVLHkSff98gPPMmZZqnQbdakDaweybWh7 0RwA== X-Received: by 10.112.58.202 with SMTP id t10mr20752326lbq.6.1401180652092; Tue, 27 May 2014 01:50:52 -0700 (PDT) Received: from [10.71.2.166] (50-76-52-230-ip-static.hfc.comcastbusiness.net. [50.76.52.230]) by mx.google.com with ESMTPSA id i10sm12636087lah.13.2014.05.27.01.50.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 01:50:51 -0700 (PDT) Message-ID: <538451E9.2020104@gmail.com> Date: Tue, 27 May 2014 11:50:49 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "dmm@ietf.org" References: <535666B3.9060301@gmail.com> In-Reply-To: <535666B3.9060301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/7ukBI4R9hX4rP9yANOz90ufBzME Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 08:51:03 -0000 Now that the gap analysis I-D is almost on the stage of leaving the WG and the requirements I-D has almost completed IESG, it would be time to return to the rechartering topic. First, the latest revision can be found at: https://github.com/jounikor/dmm-re-charter Second, have a look at it. There are few changes proposed by Alper eons ago and corrected milestones pointed by Behcet. Third, let us get this finally done.. - Jouni 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: > Folks, > > Sorry for letting this topic to rot in a dark for the couple of last > weeks. I'll crank out a revision shortly.. > > - Jouni & Dapeng From nobody Tue May 27 10:55:06 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84191A04F8 for ; Tue, 27 May 2014 10:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hX_utHRoZK5a for ; Tue, 27 May 2014 10:54:57 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E413D1A04E9 for ; Tue, 27 May 2014 10:54:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4RHsrgG031799; Tue, 27 May 2014 10:54:53 -0700 Received: from XCH-PHX-110.sw.nos.boeing.com (xch-phx-110.sw.nos.boeing.com [130.247.25.39]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4RHsltF031667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 27 May 2014 10:54:47 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-110.sw.nos.boeing.com ([169.254.10.123]) with mapi id 14.03.0181.006; Tue, 27 May 2014 10:54:45 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] rechartering Thread-Index: AQHPeYja6maHhbLaYkabe0CHt1fbHZtUtHyQ Date: Tue, 27 May 2014 17:54:45 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2B52C6@XCH-BLV-504.nw.nos.boeing.com> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> In-Reply-To: <538451E9.2020104@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/A-XuE9z5QklIO9dvZYUHaRwc-Xk Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 17:54:58 -0000 Hi Jouni, I have one small edit to propose: "However, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node. Specifically, when solutions are not based on IP mobility protocols, the DMM working group should cooperat= e with other IETF working groups working on other technologies that might allow the mobility of an end host. These working groups include but are not limited to I2rs, Lisp, Idr and Forces." Suggest changing the final two sentences to the following: "Specifically, when solutions are not based on IP mobility protocols, the DMM working group should cooperate with other IETF working group= s and/or consider non-working group items working on other technologie= s that might allow the mobility of an end host. These working groups include but are not limited to I2rs, Lisp, Idr and Forces, while non-working group items are considered based on their merit." Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > Sent: Tuesday, May 27, 2014 1:51 AM > To: dmm@ietf.org > Subject: Re: [DMM] rechartering >=20 >=20 > Now that the gap analysis I-D is almost on the stage of leaving the WG > and the requirements I-D has almost completed IESG, it would be time to > return to the rechartering topic. >=20 > First, the latest revision can be found at: > https://github.com/jounikor/dmm-re-charter >=20 > Second, have a look at it. There are few changes proposed by Alper eons > ago and corrected milestones pointed by Behcet. >=20 > Third, let us get this finally done.. >=20 > - Jouni >=20 > 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: > > Folks, > > > > Sorry for letting this topic to rot in a dark for the couple of last > > weeks. I'll crank out a revision shortly.. > > > > - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue May 27 17:11:20 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AE51A081D for ; Tue, 27 May 2014 17:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-0XX5gtDTex for ; Tue, 27 May 2014 17:11:08 -0700 (PDT) Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95AB61A07D4 for ; Tue, 27 May 2014 17:11:08 -0700 (PDT) Received: by mail-pb0-f52.google.com with SMTP id rr13so10182424pbb.11 for ; Tue, 27 May 2014 17:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EqpHT2maYFDCPxqtPNgNeM3/zswTVTLr2cvl5lsTEXA=; b=wtY4LJuSqYkdNJH0lxR2ZgXHaPArRJDaDulHz732nyDFMl8sYbznRtHW7r99NU3ZDY l4jc01+/VI+RYoOwG3G/0Bi42yGCY3b84leDgGUMUGfP3zpGRTbw1tNao9hdlwITNzOw xrwjOfoj0tAWTQSHUHRKZh3xvs02+24OyHnla5anVp23vziUX9WhL6UueUYZphk0/80r ARLVv6AnvBnJD58onAT/5sbQ7wxmyEIw2lM6c5PbCp+yxxgNvW/X+meljZmqWh3XyfT1 Uwn0JcLwHoNxoqp3AYacIZxToGzqjQ3IXP79jUlnP4gByQtMZmqIM7EeRh6aZUrNSrCV QyPg== X-Received: by 10.68.125.164 with SMTP id mr4mr40620815pbb.27.1401235865369; Tue, 27 May 2014 17:11:05 -0700 (PDT) Received: from [10.16.10.48] ([216.31.219.19]) by mx.google.com with ESMTPSA id gu11sm25235563pbd.38.2014.05.27.17.11.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 May 2014 17:11:04 -0700 (PDT) Message-ID: <53852996.4000902@gmail.com> Date: Wed, 28 May 2014 03:11:02 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "Templin, Fred L" , "dmm@ietf.org" References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <2134F8430051B64F815C691A62D983181B2B52C6@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D983181B2B52C6@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/uWtSHDl8-YKPFa6CuwrH7_tWEwY Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 00:11:17 -0000 Fred, I think your concern (assuming you have SEAL et al in mind..) should already be convered by: [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. However, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node. - Jouni 5/27/2014 8:54 PM, Templin, Fred L kirjoitti: > Hi Jouni, > > I have one small edit to propose: > > "However, mobility management in a limited area, such as within an > autonomous system, is not strictly limited to mentioned IP mobility > protocols but can be any existing or a new protocol solution enabling > the movement of a mobile node. Specifically, when solutions are not > based on IP mobility protocols, the DMM working group should cooperate > with other IETF working groups working on other technologies that > might allow the mobility of an end host. These working groups include > but are not limited to I2rs, Lisp, Idr and Forces." > > Suggest changing the final two sentences to the following: > > "Specifically, when solutions are not based on IP mobility protocols, > the DMM working group should cooperate with other IETF working groups > and/or consider non-working group items working on other technologies > that might allow the mobility of an end host. These working groups > include but are not limited to I2rs, Lisp, Idr and Forces, while > non-working group items are considered based on their merit." > > Thanks - Fred > fred.l.templin@boeing.com > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Tuesday, May 27, 2014 1:51 AM >> To: dmm@ietf.org >> Subject: Re: [DMM] rechartering >> >> >> Now that the gap analysis I-D is almost on the stage of leaving the WG >> and the requirements I-D has almost completed IESG, it would be time to >> return to the rechartering topic. >> >> First, the latest revision can be found at: >> https://github.com/jounikor/dmm-re-charter >> >> Second, have a look at it. There are few changes proposed by Alper eons >> ago and corrected milestones pointed by Behcet. >> >> Third, let us get this finally done.. >> >> - Jouni >> >> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>> Folks, >>> >>> Sorry for letting this topic to rot in a dark for the couple of last >>> weeks. I'll crank out a revision shortly.. >>> >>> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed May 28 05:36:06 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BB91A096F for ; Wed, 28 May 2014 05:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.253 X-Spam-Level: X-Spam-Status: No, score=-3.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbqJu2dYDFzw for ; Wed, 28 May 2014 05:36:01 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7744E1A00EA for ; Wed, 28 May 2014 05:36:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DF77310770D; Wed, 28 May 2014 14:35:55 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdlNfa6f+N5m; Wed, 28 May 2014 14:35:55 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id C32B610770B; Wed, 28 May 2014 14:35:45 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.100]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 28 May 2014 14:35:46 +0200 From: Marco Liebsch To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] rechartering Thread-Index: AQHPXio+mlGJRLLwFkeq/GQyjtwnTZtUM6eAgAHpkjA= Date: Wed, 28 May 2014 12:35:45 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D808C1C94@PALLENE.office.hd> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> In-Reply-To: <538451E9.2020104@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2v59Uzap0M1PehOJOyTtCJBLeeI Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 12:36:04 -0000 Hi Jouni, all, let me pick up some comments again, which we should clarify.=20 About anchor selection: Referring to the milestones, having the anchor re-selection document separated from the advanced anchor selection only by 3 months does not seem to be useful, even if you consider re-selection to be used only for ad= vanced DMM deployment and operation, whereas basic anchor selection is required fo= r any DMM deployment with decentralized data plane anchors.=20 I understand this document treats solely selection and runtime re-selection= , not the associated establishment of routing/tunnel states according to the selected anchor. So, I think both aspects, selection and re-selection, shou= ld go into a single document. Unless the WG decides that re-selection is too a= dvanced, then it may go into a separate document when the base selection spec is alm= ost ready, as it will depend on it. About forwarding path and signaling management: In particular if the support of runtime/mid-session anchor change is consid= ered for the first set of DMM solution documents, the described work item about 'forwarding path and signaling management' should be given a milestone, as this is essential if anchors are changed mid-session and IP address continuation is expected. So far there is no document about this work item in the charter list. Inter-working between mobility functions and network nodes, e.g. routers, requires the use of some non-mobility protocol. DMM should at least describ= e which states (identifiers, locator addresses/IDs, ..) to expose through the= se protocols. That's what I understood behind mobility state exposure, whereas the text in the work items list reads more like this is about announcements from the network to an MN about the characteristics of an IP address to sup= port the MN in picking the right address for an application. I know it's more a = terms issue, but we need clarification what we expect from a work item. Hope the above makes sense and we can easily clarify. marco =20 >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >Sent: Dienstag, 27. Mai 2014 10:51 >To: dmm@ietf.org >Subject: Re: [DMM] rechartering > > >Now that the gap analysis I-D is almost on the stage of leaving the WG and= the >requirements I-D has almost completed IESG, it would be time to return to = the >rechartering topic. > >First, the latest revision can be found at: >https://github.com/jounikor/dmm-re-charter > >Second, have a look at it. There are few changes proposed by Alper eons ag= o >and corrected milestones pointed by Behcet. > >Third, let us get this finally done.. > >- Jouni > >4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >> Folks, >> >> Sorry for letting this topic to rot in a dark for the couple of last >> weeks. I'll crank out a revision shortly.. >> >> - Jouni & Dapeng > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Wed May 28 07:10:20 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE471A0946 for ; Wed, 28 May 2014 07:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VGBcyF0EGfw for ; Wed, 28 May 2014 07:10:16 -0700 (PDT) Received: from stl-mbsout-02.boeing.com (stl-mbsout-02.boeing.com [130.76.96.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AA901A0119 for ; Wed, 28 May 2014 07:10:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s4SEAC90017579; Wed, 28 May 2014 09:10:12 -0500 Received: from XCH-PHX-209.sw.nos.boeing.com (xch-phx-209.sw.nos.boeing.com [130.247.25.29]) by stl-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s4SEA3ox016948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 28 May 2014 09:10:04 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.105]) by XCH-PHX-209.sw.nos.boeing.com ([169.254.9.197]) with mapi id 14.03.0181.006; Wed, 28 May 2014 07:10:02 -0700 From: "Templin, Fred L" To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: [DMM] rechartering Thread-Index: AQHPeYja6maHhbLaYkabe0CHt1fbHZtUtHyQgADgaQCAAHOQAA== Date: Wed, 28 May 2014 14:10:02 +0000 Message-ID: <2134F8430051B64F815C691A62D983181B2B5EFD@XCH-BLV-504.nw.nos.boeing.com> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <2134F8430051B64F815C691A62D983181B2B52C6@XCH-BLV-504.nw.nos.boeing.com> <53852996.4000902@gmail.com> In-Reply-To: <53852996.4000902@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/5k6XCfF_ERuvHK_wRdGhT6ugVTY Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 14:10:18 -0000 Hi Jouni, I am OK with what you have if you think my concern is already covered. BTW, I am no longer pushing forward with SEAL and am interested in consideration for AERO: https://datatracker.ietf.org/doc/draft-templin-aerolink/ SEAL was trying to do too much to be all things to all people; AERO is simple, and is really nothing more than IPv6 neighbor discovery applied to tunnels. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Tuesday, May 27, 2014 5:11 PM > To: Templin, Fred L; dmm@ietf.org > Subject: Re: [DMM] rechartering >=20 >=20 > Fred, >=20 > I think your concern (assuming you have SEAL et al in mind..) should > already be convered by: >=20 > [RFC6275, 5555], Proxy Mobile IPv6 [RFC5213, 5844] and NEMO [RFC3963]. > However, mobility management in a limited area, such as within an > autonomous system, is not strictly limited to mentioned IP mobility > protocols but can be any existing or a new protocol solution enabling > the movement of a mobile node. >=20 > - Jouni >=20 > 5/27/2014 8:54 PM, Templin, Fred L kirjoitti: > > Hi Jouni, > > > > I have one small edit to propose: > > > > "However, mobility management in a limited area, such as within = an > > autonomous system, is not strictly limited to mentioned IP mobil= ity > > protocols but can be any existing or a new protocol solution ena= bling > > the movement of a mobile node. Specifically, when solutions are = not > > based on IP mobility protocols, the DMM working group should coo= perate > > with other IETF working groups working on other technologies tha= t > > might allow the mobility of an end host. These working groups in= clude > > but are not limited to I2rs, Lisp, Idr and Forces." > > > > Suggest changing the final two sentences to the following: > > > > "Specifically, when solutions are not based on IP mobility proto= cols, > > the DMM working group should cooperate with other IETF working = groups > > and/or consider non-working group items working on other techno= logies > > that might allow the mobility of an end host. These working gro= ups > > include but are not limited to I2rs, Lisp, Idr and Forces, whil= e > > non-working group items are considered based on their merit." > > > > Thanks - Fred > > fred.l.templin@boeing.com > > > >> -----Original Message----- > >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen > >> Sent: Tuesday, May 27, 2014 1:51 AM > >> To: dmm@ietf.org > >> Subject: Re: [DMM] rechartering > >> > >> > >> Now that the gap analysis I-D is almost on the stage of leaving the WG > >> and the requirements I-D has almost completed IESG, it would be time t= o > >> return to the rechartering topic. > >> > >> First, the latest revision can be found at: > >> https://github.com/jounikor/dmm-re-charter > >> > >> Second, have a look at it. There are few changes proposed by Alper eon= s > >> ago and corrected milestones pointed by Behcet. > >> > >> Third, let us get this finally done.. > >> > >> - Jouni > >> > >> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: > >>> Folks, > >>> > >>> Sorry for letting this topic to rot in a dark for the couple of last > >>> weeks. I'll crank out a revision shortly.. > >>> > >>> - Jouni & Dapeng > >> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed May 28 10:55:01 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA881A01B6 for ; Wed, 28 May 2014 10:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_BACKHAIR_27=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXbUAKVhEfMm for ; Wed, 28 May 2014 10:54:58 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B3C31A01AB for ; Wed, 28 May 2014 10:54:58 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id um1so11548608pbc.32 for ; Wed, 28 May 2014 10:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QOPUaimnJ0SxlV18VBy5bRqjjLPXaCyCShI9QS7B4vU=; b=CQZQCO2wiQdFnlo9QlVDXaKxLdW/JDp9DE1j16WkVBCs1D4iH1oX/o8IpNjY8N7tWV 6KPUYD0M28Zc+iNJ6Zj3vbIiklDQVfs6aspGmIX+2L3HYJe81rIxGtmus8ewEjrMM2c7 jQRnGCICta3OgN/G/JzpzNBvPMoi7nsBw/vjSMKHHqKoi7FtNtHnFZTnF+i1gx9v13MW M76ysEphLx0dcItLV30MifXk0gj+VbZXSlpJpnJPY4U/q5iN6ATt3NNSxaTkKIXc9cc3 dNpsjlp6tldIL8PF66V7vHoiFZEtSMvqwad1AkXV+SQtUEoHdQGiorfmfVSNPRM+R1/6 zmkw== X-Received: by 10.68.174.33 with SMTP id bp1mr1652349pbc.74.1401299694570; Wed, 28 May 2014 10:54:54 -0700 (PDT) Received: from [10.16.10.28] ([216.31.219.19]) by mx.google.com with ESMTPSA id no9sm29414865pbc.83.2014.05.28.10.54.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 10:54:53 -0700 (PDT) Message-ID: <538622EB.9030404@gmail.com> Date: Wed, 28 May 2014 20:54:51 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marco Liebsch , "dmm@ietf.org" References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <69756203DDDDE64E987BC4F70B71A26D808C1C94@PALLENE.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D808C1C94@PALLENE.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_mbLtZZWXcMIxMo7SssTswxc8kM Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 17:54:59 -0000 Marco, 5/28/2014 3:35 PM, Marco Liebsch kirjoitti: > Hi Jouni, all, > > let me pick up some comments again, which we should clarify. > > About anchor selection: > > Referring to the milestones, having the anchor re-selection document > separated from the advanced anchor selection only by 3 months does not > seem to be useful, even if you consider re-selection to be used only for advanced > DMM deployment and operation, whereas basic anchor selection is required for > any DMM deployment with decentralized data plane anchors. > > I understand this document treats solely selection and runtime re-selection, > not the associated establishment of routing/tunnel states according to the Actually, I was in an opinion that re-selection would also cover the needed parts for possible re-routing of traffic.. whatever the mechanisms is. Does anyone else share the same view? > selected anchor. So, I think both aspects, selection and re-selection, should > go into a single document. Unless the WG decides that re-selection is too advanced, > then it may go into a separate document when the base selection spec is almost ready, > as it will depend on it. > > About forwarding path and signaling management: > > In particular if the support of runtime/mid-session anchor change is considered for the first > set of DMM solution documents, the described work item about 'forwarding > path and signaling management' should be given a milestone, as this is > essential if anchors are changed mid-session and IP address continuation > is expected. So far there is no document about this work item in the > charter list. Right, any suggestions for the actual document name and time lines? > Inter-working between mobility functions and network nodes, e.g. routers, > requires the use of some non-mobility protocol. DMM should at least describe > which states (identifiers, locator addresses/IDs, ..) to expose through these > protocols. That's what I understood behind mobility state exposure, whereas > the text in the work items list reads more like this is about announcements > from the network to an MN about the characteristics of an IP address to support > the MN in picking the right address for an application. I know it's more a terms issue, > but we need clarification what we expect from a work item. The latter is what I had in mind.. mainly the MN<->network communication. > Hope the above makes sense and we can easily clarify. Sure. - Jouni > > marco > > > > >> -----Original Message----- >> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >> Sent: Dienstag, 27. Mai 2014 10:51 >> To: dmm@ietf.org >> Subject: Re: [DMM] rechartering >> >> >> Now that the gap analysis I-D is almost on the stage of leaving the WG and the >> requirements I-D has almost completed IESG, it would be time to return to the >> rechartering topic. >> >> First, the latest revision can be found at: >> https://github.com/jounikor/dmm-re-charter >> >> Second, have a look at it. There are few changes proposed by Alper eons ago >> and corrected milestones pointed by Behcet. >> >> Third, let us get this finally done.. >> >> - Jouni >> >> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>> Folks, >>> >>> Sorry for letting this topic to rot in a dark for the couple of last >>> weeks. I'll crank out a revision shortly.. >>> >>> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed May 28 22:40:55 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2EE1A030A for ; Wed, 28 May 2014 22:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_27=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkdatVVufEaz for ; Wed, 28 May 2014 22:40:52 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536261A02B0 for ; Wed, 28 May 2014 22:40:52 -0700 (PDT) Received: from [192.168.3.233] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LsCuN-1Whjxq1DW3-013ILA; Thu, 29 May 2014 01:40:43 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <538622EB.9030404@gmail.com> Date: Thu, 29 May 2014 08:40:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <06EFACA3-E5F7-40AA-A078-11FF3D4BD9D9@yegin.org> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <69756203DDDDE64E987BC4F70B71A26D808C1C94@PALLENE.office.hd> <538622EB.9030404@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Fkt/tQy6+vRfaMdgO8OW+pVnDy4l7wtJIesQ7Urb7KK syntuVJGr9b2L3uY4bjUfkB4TcyL2W6GYFU3NgDgO7C6pGPJfN LhqYcekRJPYRpqENDLVIYc9bIT3NhBVglF6hRCIP3RTGdCgwcL 6uftn6SQZCddvdcKN2hDO5Zd9jm2V09jtQYQwt3FT4N9avx6M5 clBUZijY7VkGkXJqARLbxzXyrSgfyc7J4fHIWIbE9B4oq8B/Xk Ij5OrG3MAiisrXXW4wJAjtlYij9VB+gyuzD8OPlGNKVtp4tTEj 5diq4v1v6Q9f/DOs3K7M8C1iNOj1FTWsre9zYKx3ZoBcRl3TwM WR7ivmHbzWeNXYfWzSkccy92Uao5yzmzRgLtnh38L8YH7NWfEh C7Ao5B1wV9O9w== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/QgvYUHnf5LTzKytU8H-OxyAxNJk Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 05:40:53 -0000 >> Inter-working between mobility functions and network nodes, e.g. = routers, >> requires the use of some non-mobility protocol. DMM should at least = describe >> which states (identifiers, locator addresses/IDs, ..) to expose = through these >> protocols. That's what I understood behind mobility state exposure, = whereas >> the text in the work items list reads more like this is about = announcements >> from the network to an MN about the characteristics of an IP address = to support >> the MN in picking the right address for an application. I know it's = more a terms issue, >> but we need clarification what we expect from a work item. >=20 > The latter is what I had in mind.. mainly the MN<->network = communication. >=20 Plus, the interaction between the apps and the IP stack on the MN. Alper >> Hope the above makes sense and we can easily clarify. >=20 > Sure. >=20 > - Jouni >=20 >=20 >>=20 >> marco >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >>> Sent: Dienstag, 27. Mai 2014 10:51 >>> To: dmm@ietf.org >>> Subject: Re: [DMM] rechartering >>>=20 >>>=20 >>> Now that the gap analysis I-D is almost on the stage of leaving the = WG and the >>> requirements I-D has almost completed IESG, it would be time to = return to the >>> rechartering topic. >>>=20 >>> First, the latest revision can be found at: >>> https://github.com/jounikor/dmm-re-charter >>>=20 >>> Second, have a look at it. There are few changes proposed by Alper = eons ago >>> and corrected milestones pointed by Behcet. >>>=20 >>> Third, let us get this finally done.. >>>=20 >>> - Jouni >>>=20 >>> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>>> Folks, >>>>=20 >>>> Sorry for letting this topic to rot in a dark for the couple of = last >>>> weeks. I'll crank out a revision shortly.. >>>>=20 >>>> - Jouni & Dapeng >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu May 29 11:27:02 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D8F1A0958 for ; Thu, 29 May 2014 11:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_BACKHAIR_27=1, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVRs6H6oiIWn for ; Thu, 29 May 2014 11:26:58 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348351A046B for ; Thu, 29 May 2014 11:26:58 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id rd3so764140pab.7 for ; Thu, 29 May 2014 11:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=v0UCvHAYggVQJYXovX3qJ503l3jRuRslcz0twD3CisA=; b=WJxL5Y+vy86f+bnylAcAxU8+x73jETanz8t+Du8rQ6OHKrlR3uYctE2CSXlBCAVrK0 eSkXBq1s22QDMxVHnM2cLcczx7grR5aCzMkLzNY+XypLY+ED9cvgCWYcTrUzFvxc3vaR e0oTdrcyynSC9FTjEet1hAfXvyNFVnR+qgKHQzKtfEL4bXlWWZIEC+J1SIiokqGp4zkb 5+89KpdDF7b/5221kaAlpo89GuqgtL7nIVAurwieoOryVDcrEFDUW/BOkZvVxrcltOXv gkiUvmN/WsDn0dsuhz4N2KMYWmBKYk5whpKfEU5R00ntHt/JhKWvqS1+JF+GPA+iuoWn uMcg== X-Received: by 10.66.232.68 with SMTP id tm4mr11089563pac.114.1401388013444; Thu, 29 May 2014 11:26:53 -0700 (PDT) Received: from [10.16.10.192] ([216.31.219.19]) by mx.google.com with ESMTPSA id wg7sm2351871pbc.73.2014.05.29.11.26.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 11:26:51 -0700 (PDT) Message-ID: <53877BE8.4040600@gmail.com> Date: Thu, 29 May 2014 21:26:48 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alper Yegin References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <69756203DDDDE64E987BC4F70B71A26D808C1C94@PALLENE.office.hd> <538622EB.9030404@gmail.com> <06EFACA3-E5F7-40AA-A078-11FF3D4BD9D9@yegin.org> In-Reply-To: <06EFACA3-E5F7-40AA-A078-11FF3D4BD9D9@yegin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/xSYWCHDNDbfBEMQ-iTeIO5aq_9A Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 18:26:59 -0000 5/29/2014 8:40 AM, Alper Yegin kirjoitti: >>> Inter-working between mobility functions and network nodes, e.g. routers, >>> requires the use of some non-mobility protocol. DMM should at least describe >>> which states (identifiers, locator addresses/IDs, ..) to expose through these >>> protocols. That's what I understood behind mobility state exposure, whereas >>> the text in the work items list reads more like this is about announcements >>> from the network to an MN about the characteristics of an IP address to support >>> the MN in picking the right address for an application. I know it's more a terms issue, >>> but we need clarification what we expect from a work item. >> >> The latter is what I had in mind.. mainly the MN<->network communication. >> > > Plus, the interaction between the apps and the IP stack on the MN. Correct. - Jouni > > Alper > > > > > >>> Hope the above makes sense and we can easily clarify. >> >> Sure. >> >> - Jouni >> >> >>> >>> marco >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen >>>> Sent: Dienstag, 27. Mai 2014 10:51 >>>> To: dmm@ietf.org >>>> Subject: Re: [DMM] rechartering >>>> >>>> >>>> Now that the gap analysis I-D is almost on the stage of leaving the WG and the >>>> requirements I-D has almost completed IESG, it would be time to return to the >>>> rechartering topic. >>>> >>>> First, the latest revision can be found at: >>>> https://github.com/jounikor/dmm-re-charter >>>> >>>> Second, have a look at it. There are few changes proposed by Alper eons ago >>>> and corrected milestones pointed by Behcet. >>>> >>>> Third, let us get this finally done.. >>>> >>>> - Jouni >>>> >>>> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>>>> Folks, >>>>> >>>>> Sorry for letting this topic to rot in a dark for the couple of last >>>>> weeks. I'll crank out a revision shortly.. >>>>> >>>>> - Jouni & Dapeng >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu May 29 13:17:42 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F101A066B for ; Thu, 29 May 2014 13:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caXTmTHx1e3d for ; Thu, 29 May 2014 13:17:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324D31A063F for ; Thu, 29 May 2014 13:17:38 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MgKcw-1XAVQc2H4g-00O02r; Thu, 29 May 2014 16:17:31 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1CFE3656-C941-4CAE-8F75-E9E8E7CFCEFB" From: Alper Yegin In-Reply-To: <538451E9.2020104@gmail.com> Date: Thu, 29 May 2014 23:17:26 +0300 Message-Id: <1F2273AA-CDB3-416A-9349-95ADD9A4285A@yegin.org> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:TQuVB4GwbLc5qUfovUEo65V4nOnP0zeN8p9sS7UW+N6 s+8qZfnZd5D4mqGD7HqC66T5qRmefaifx7THbiJ0rvbSKQsQmC IwP9FZ3zsnOy92qeBPXHJHkRpBJCYBiM3c1LruLYmEhVHou9wx PO/UTu0N6Ol3lRHlffEEA83Eu57eB9Cf2aOi73Y8cvekli1eLR WHzUJbNwSiysAVVc86MtS0iCs9SkXeW6wpbAFD6o9GlZl91DWH HFWrqmegvNIJLNs3z6wB49Z5we6PgL7a/j1arTI1SzckVvn3g8 Q/5MNXlQRXaSsMaLB7xbcNmMKrOQS+n89ZxyZAPxjzHbaurHpt F9Kw0bbpnpLG1zBAXHgaVWR2NRk0+MvAki7gUXBTiFKP3hiPVv VPc4hB2mCyYFA== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/z6-UoyRvMQWtxBuBhsuVR_VcW7c Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:17:40 -0000 --Apple-Mail=_1CFE3656-C941-4CAE-8F75-E9E8E7CFCEFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Jouni, folks, Here are few more comments: DMM can be used to realise such a distributed deployment model, by distributing forwarding functions at optimal location; = for example, closer either to the mobile user or the corresponding = node. We had already talked about that: s/mobile user/mobile node.=20 o Enhanced gateway & mobility anchor selection and re-selection: = define=20 protocol solutions for a gateway and mobility anchor selection = that go beyond what has been, for example, described in RFC 6097. The solution should also define a mechanism for anchor re-selection = that allow preserving ongoing mobility sessions in a single administrative = domain. =20 o Forwarding path and signalling management: the mobility agent = that handles the mobility signalling interacts with the network elements in = the DMM network for managing the forwarding state associated with a mobile = node's IP traffic. These two functions may or may not be collocated. Furthermore, = the forwarding state may also be distributed into multiple network elements = instead of a single anchor like network element. Define required protocol = extensions to allow described forwarding path and signalling management. GW selection and data-path management signaling may be defined in the = same "solution" document. In at least some cases these are provided as = part of the same solution set. They may also be separable, maybe, but we = shall not be hung up on producing separate documents for these=85 The = solution discussions will guide us=85 (no specific change required on = the above text, more on this below=85) The milestones are missing any document that defines the "data-path = management signaling" (what's mentioned above). And like I said before, = that's "the" product of this WG IMO. It'd of course be supplemented by = GW selection and mobility state exposure bits to complete the picture. Let's add another milestone: Nov 2014 - Submit 'Forwarding path and signaling management' as a = working group document. To be Proposed Standard. Mar 2015 - Submit 'Forwarding path and signaling management' submitted = to the IESG. To be Proposed Standard. Cheers, Alper On May 27, 2014, at 11:50 AM, Jouni Korhonen wrote: >=20 > Now that the gap analysis I-D is almost on the stage of leaving the WG = and the requirements I-D has almost completed IESG, it would be time to = return to the rechartering topic. >=20 > First, the latest revision can be found at: > https://github.com/jounikor/dmm-re-charter >=20 > Second, have a look at it. There are few changes proposed by Alper = eons ago and corrected milestones pointed by Behcet. >=20 > Third, let us get this finally done.. >=20 > - Jouni >=20 > 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >> Folks, >>=20 >> Sorry for letting this topic to rot in a dark for the couple of last >> weeks. I'll crank out a revision shortly.. >>=20 >> - Jouni & Dapeng >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_1CFE3656-C941-4CAE-8F75-E9E8E7CFCEFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Jouni, folks,

    Here are few more = comments:

      =     DMM can be used to realise such a distributed = deployment
         o Enhanced gateway & = mobility anchor selection and re-selection: define 
           


    GW = selection and data-path management signaling may be defined in the same = "solution" document. In at least some cases these are provided as part = of the same solution set. They may also be separable, maybe, but we = shall not be hung up on producing separate documents for these=85 The = solution discussions will guide us=85 (no specific change required on = the above text, more on this below=85)

    The milestones are missing any document that = defines the "data-path management signaling" (what's mentioned above). = And like I said before, that's "the"  product of this WG IMO. It'd = of course be supplemented by GW selection and mobility state exposure = bits to complete the picture.
    Let's add another = milestone:

    Nov 2014 - Submit 'Forwarding path and = signaling management' as a working group document. To be = Proposed Standard.
    Mar 2015 - Submit = 'Forwarding path and signaling management' submitted to = the IESG. To be Proposed = Standard.


    Cheers,

    Alper








    Now= that the gap analysis I-D is almost on the stage of leaving the WG and = the requirements I-D has almost completed IESG, it would be time to = return to the rechartering topic.

    First, the latest revision can = be found at:
    https://github.com/jou= nikor/dmm-re-charter

    Second, have a look at it. There are few = changes proposed by Alper eons ago and corrected milestones pointed by = Behcet.

    Third, let us get this finally done..

    - = Jouni

    4/22/2014 3:55 PM, Jouni Korhonen kirjoitti:
    Folks,

    Sorry for = letting this topic to rot in a dark for the couple of = last
    weeks. I'll crank out a = revision shortly..

    - Jouni & = Dapeng

    _______________________________________________=
    dmm mailing = list
    dmm@ietf.org
    https://www.ietf.org/mailman/listinfo/dmm

    = --Apple-Mail=_1CFE3656-C941-4CAE-8F75-E9E8E7CFCEFB-- From nobody Thu May 29 13:36:19 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DA91A00EA for ; Thu, 29 May 2014 13:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyoLxrNuKrSx for ; Thu, 29 May 2014 13:36:15 -0700 (PDT) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB681A0677 for ; Thu, 29 May 2014 13:36:15 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id rr13so892176pbb.21 for ; Thu, 29 May 2014 13:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=uhwzvc9aaohM+QDjTX5cflIAmT0OUhSPKN3WPqTVnlk=; b=keEB/GCDGTKQPfGsIBV+FStxAUSeBByxrDPwky04cv7LtP5hyEplA3BFosVyAhKA0w rEUEeDYQVu/HjPMvhcOo5z/NtnK/PL6Ch95lJx2N/0Qwj8c8+U5OmudKdPZAwsUff+LX wX7tlE2xXDLqdlxPi/safR7Dtt0JsG09M2THRHzkIxhAlYk+6HZE3NDMtfP5/1s6ol8X 9o+kiugxmWjbY2wcfbFRUjKwIzBTnQNaAAjcIv34mLYXkpZOwZ5ZiRjpygVLuRvQB1L5 wm8YHhsKO1L56GFAegji8Pz+eCUefsPxctN39qXycr4UVxrzdaSgtqOG0ahFf/egHmKP 7aGg== X-Received: by 10.66.241.66 with SMTP id wg2mr12061775pac.132.1401395771249; Thu, 29 May 2014 13:36:11 -0700 (PDT) Received: from [10.16.10.192] ([216.31.219.19]) by mx.google.com with ESMTPSA id ky8sm2678650pbc.64.2014.05.29.13.36.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 13:36:10 -0700 (PDT) Message-ID: <53879A37.9050307@gmail.com> Date: Thu, 29 May 2014 23:36:07 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alper Yegin References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <1F2273AA-CDB3-416A-9349-95ADD9A4285A@yegin.org> In-Reply-To: <1F2273AA-CDB3-416A-9349-95ADD9A4285A@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_tPWK7TLwX978obX3xLIQ5H6JTc Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:36:18 -0000 Alper, 5/29/2014 11:17 PM, Alper Yegin kirjoitti: > Hello Jouni, folks, > > Here are few more comments: > > DMM can be used to realise such a distributed deployment > model, by distributing forwarding functions at optimal location; for > example, closer either to the mobile user or the corresponding node. > > We had already talked about that: s/mobile user/mobile node. Ack. > > > > o Enhanced gateway & mobility anchor selection and re-selection: > define > protocol solutions for a gateway and mobility anchor selection that > go beyond what has been, for example, described in RFC 6097. The > solution should also define a mechanism for anchor re-selection > that allow > preserving ongoing mobility sessions in a single administrative > domain. > > o Forwarding path and signalling management: the mobility agent > that handles > the mobility signalling interacts with the network elements in > the DMM network > for managing the forwarding state associated with a mobile > node's IP traffic. > These two functions may or may not be collocated. Furthermore, > the forwarding > state may also be distributed into multiple network elements > instead of a > single anchor like network element. Define required protocol > extensions to > allow described forwarding path and signalling management. > > GW selection and data-path management signaling may be defined in the > same "solution" document. In at least some cases these are provided as > part of the same solution set. They may also be separable, maybe, but we > shall not be hung up on producing separate documents for these… The > solution discussions will guide us… (no specific change required on the > above text, more on this below…) > > > The milestones are missing any document that defines the "data-path > management signaling" (what's mentioned above). And like I said before, > that's "the" product of this WG IMO. It'd of course be supplemented by > GW selection and mobility state exposure bits to complete the picture. > > Let's add another milestone: > > Nov 2014 - Submit 'Forwarding path and signaling management' as a > working group document. To be Proposed Standard. > Mar 2015 - Submit 'Forwarding path and signaling management' submitted > to the IESG. To be Proposed Standard. Ack. Somewhat ambitious timeline though ;) - Jouni > > > Cheers, > > Alper > > > > > > > > > > > > > > > > On May 27, 2014, at 11:50 AM, Jouni Korhonen wrote: > >> >> Now that the gap analysis I-D is almost on the stage of leaving the WG >> and the requirements I-D has almost completed IESG, it would be time >> to return to the rechartering topic. >> >> First, the latest revision can be found at: >> https://github.com/jounikor/dmm-re-charter >> >> Second, have a look at it. There are few changes proposed by Alper >> eons ago and corrected milestones pointed by Behcet. >> >> Third, let us get this finally done.. >> >> - Jouni >> >> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>> Folks, >>> >>> Sorry for letting this topic to rot in a dark for the couple of last >>> weeks. I'll crank out a revision shortly.. >>> >>> - Jouni & Dapeng >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > From nobody Thu May 29 13:52:46 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003B71A034D for ; Thu, 29 May 2014 13:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuYYKzoq1eKh for ; Thu, 29 May 2014 13:52:41 -0700 (PDT) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94611A00EA for ; Thu, 29 May 2014 13:52:41 -0700 (PDT) Received: by mail-yk0-f169.google.com with SMTP id 200so767081ykr.14 for ; Thu, 29 May 2014 13:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QW3h7zbp3JUcqIOzdNXGk1+a8CPfHDWqCaYuy7ZQjvc=; b=j+izaX5UmuCFuofBe6sFKc+IogZcP5u+8zlQB6V3MCOajKHpjWtOh8LRx/FsiOiOCz 3eV8zsrhpvyhpEQo0jS/5ib9eSajJxiDI4Pebr8+XOzLwsqkdk6R7I23rT1XEMgbdCB7 ZbklGDxWohy4hSrZyp4tmFj8xDHRh8EJBokPr7ZqMYLXKuV3tL9NR/7smtzG0/+MmyJ9 cYoigDe5yBbdhhFntZbuVSZbflGR2bYJqaPW2Vvq0G7+kFsqO7BCucYjyDTCA1SYyDiF XoJMgYZTNdJlE5VFZ/qgdMn06uaggvCBHtJJnXcZsttZfvrf9vjEwIdDHj57Y3bCki+e VZQg== MIME-Version: 1.0 X-Received: by 10.236.191.132 with SMTP id g4mr13913862yhn.32.1401396757472; Thu, 29 May 2014 13:52:37 -0700 (PDT) Received: by 10.170.126.18 with HTTP; Thu, 29 May 2014 13:52:37 -0700 (PDT) In-Reply-To: <538451E9.2020104@gmail.com> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> Date: Thu, 29 May 2014 15:52:37 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/jyrln2AGiJyRJY2sYZltyb5ERec Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 20:52:43 -0000 Hi Jouni, I was looking at the charter text and noticed one important issue. The charter seems to be stuck with the good old anchor think. Almost all text is about anchoring, anchor selection, anchor reselection, and so on. However in the past several months, we have seen in Alper's events, presentations which seem to have no anchor. I don't see any active draft that talks about the anchors. In view of this, my question is how are we going to go ahead with this charter and meet the deadlines? Or else, are we better off with a charter text which is much less dependent on the anchors, something which could make it possible to progress one of those proposals?? Regards, Behcet On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen wrote: > > Now that the gap analysis I-D is almost on the stage of leaving the WG and > the requirements I-D has almost completed IESG, it would be time to return > to the rechartering topic. > > First, the latest revision can be found at: > https://github.com/jounikor/dmm-re-charter > > Second, have a look at it. There are few changes proposed by Alper eons ago > and corrected milestones pointed by Behcet. > > Third, let us get this finally done.. > > - Jouni > > 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: > >> Folks, >> >> Sorry for letting this topic to rot in a dark for the couple of last >> weeks. I'll crank out a revision shortly.. >> >> - Jouni & Dapeng > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Thu May 29 14:03:40 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D301A06B6 for ; Thu, 29 May 2014 14:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFJOXAv1v9K1 for ; Thu, 29 May 2014 14:03:34 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675D61A06B3 for ; Thu, 29 May 2014 14:03:34 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so156442pde.28 for ; Thu, 29 May 2014 14:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lVBrn2B869VBRUYfRxM4fhN/4pudRZDejfhdJxJpuL8=; b=hUlWxTJNmKvBKIw0qg/0k7F8ywsdDxrbn1nMjNTvvAElCFgt0DUP7fhW+rV0hIwsHD K9sJ73IpYrwyT+3nMjYawO6FDH8V975DjZFJpWwMsldIInf462IQQ+YwgQY1nWLeAuU6 p+JpCgbOjnAX88V4ouo8G1hN0Rsv6BV33UcOPDqYA3Y9e0I3ZpUl0NXJSj5axwPCdFUC Cns6yMxI7FpInsWxXOtYXynmrglHwU2VK9qz2gFYw54lRkXKU+EXFxPexqP1U0ysiUqR zN4jUevJHtNBZFLjrzKxsqxhEpvLQ27eQV1R50qef+e8pSm2z0e7MqP/R/G3goYlZUQf 5rEQ== X-Received: by 10.66.144.129 with SMTP id sm1mr12331717pab.40.1401397410452; Thu, 29 May 2014 14:03:30 -0700 (PDT) Received: from [10.16.10.192] ([216.31.219.19]) by mx.google.com with ESMTPSA id zv3sm8075064pab.20.2014.05.29.14.03.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 14:03:29 -0700 (PDT) Message-ID: <5387A09F.7070604@gmail.com> Date: Fri, 30 May 2014 00:03:27 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ZQK7Gm_pPBgSja-Rkex7q_Q6wAE Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:03:36 -0000 Bechet, 5/29/2014 11:52 PM, Behcet Sarikaya kirjoitti: > Hi Jouni, > > I was looking at the charter text and noticed one important issue. The > charter seems to be stuck with the good old anchor think. Almost all > text is about anchoring, anchor selection, anchor reselection, and so > on. > > However in the past several months, we have seen in Alper's events, > presentations which seem to have no anchor. > > I don't see any active draft that talks about the anchors. > > In view of this, my question is how are we going to go ahead with this > charter and meet the deadlines? I (myself) see still value dragging along some anchoring stuff just to allow smoother migration from current deployed models toward less centralized architectures. But you are right that we should not get stuck on those.. and that has not been the intent either. > Or else, are we better off with a charter text which is much less > dependent on the anchors, something which could make it possible to > progress one of those proposals?? You are welcome to propose concrete text & change snippets to the current charter text. - Jouni > > Regards, > > Behcet > > > On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen wrote: >> >> Now that the gap analysis I-D is almost on the stage of leaving the WG and >> the requirements I-D has almost completed IESG, it would be time to return >> to the rechartering topic. >> >> First, the latest revision can be found at: >> https://github.com/jounikor/dmm-re-charter >> >> Second, have a look at it. There are few changes proposed by Alper eons ago >> and corrected milestones pointed by Behcet. >> >> Third, let us get this finally done.. >> >> - Jouni >> >> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >> >>> Folks, >>> >>> Sorry for letting this topic to rot in a dark for the couple of last >>> weeks. I'll crank out a revision shortly.. >>> >>> - Jouni & Dapeng >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Thu May 29 14:29:25 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE351A09C2 for ; Thu, 29 May 2014 14:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHDmQjM8qNu5 for ; Thu, 29 May 2014 14:29:20 -0700 (PDT) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DDD1A091F for ; Thu, 29 May 2014 14:29:20 -0700 (PDT) Received: by mail-yh0-f53.google.com with SMTP id i57so840950yha.40 for ; Thu, 29 May 2014 14:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zrEFcePx9SOYesHQLlXPynfPErXGSCdnm0ELyvpLUWk=; b=yZ9Qqtjso5/GN2zf+NKi7iQyB5dB0N1U985/qivB2VTFc4quFG7xmxxavejYhlKGxk Lj8E52/GEFNCTM6UaGjsDKZjpoEEBb692Ge9ywQ0LRx96EkMJVjHd9kqWSfdUK81dSYK zpPklrIU4ZOHh41Xqs0m/66lWKkoinRmU6aQCHrPZFqEl1KsvmLYrESMfAbEiSRqbnwM RLOqLnenrITWAq2dZl9BwZNxTtCw0PvOge50rQ8LzuQk7dy3TJpcTfD0soeWbAXovbpz avmDAvK1q9y0nGWLYl06mgJOuB+O7bUs9PTutHb77/3Lc9dkilUTBBLdFqjY9yziN/04 wKzA== MIME-Version: 1.0 X-Received: by 10.236.198.178 with SMTP id v38mr13942288yhn.71.1401398955830; Thu, 29 May 2014 14:29:15 -0700 (PDT) Received: by 10.170.126.18 with HTTP; Thu, 29 May 2014 14:29:15 -0700 (PDT) In-Reply-To: <5387A09F.7070604@gmail.com> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <5387A09F.7070604@gmail.com> Date: Thu, 29 May 2014 16:29:15 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/v23rM1piPyiglTFi3RfP2TkwLro Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 21:29:21 -0000 About two months ago I had made this proposal First cycle, select one from each category of solutions, client, network based and routing based Second cycle, select one from the selected ones as the dmm solution. which still stands, I think. On Thu, May 29, 2014 at 4:03 PM, Jouni Korhonen wrote: > Bechet, > > 5/29/2014 11:52 PM, Behcet Sarikaya kirjoitti: > >> Hi Jouni, >> >> I was looking at the charter text and noticed one important issue. The >> charter seems to be stuck with the good old anchor think. Almost all >> text is about anchoring, anchor selection, anchor reselection, and so >> on. >> >> However in the past several months, we have seen in Alper's events, >> presentations which seem to have no anchor. >> >> I don't see any active draft that talks about the anchors. >> >> In view of this, my question is how are we going to go ahead with this >> charter and meet the deadlines? > > > I (myself) see still value dragging along some anchoring stuff just to allow > smoother migration from current deployed models toward less centralized > architectures. > > But you are right that we should not get stuck on those.. and that has not > been the intent either. > > >> Or else, are we better off with a charter text which is much less >> dependent on the anchors, something which could make it possible to >> progress one of those proposals?? > > > You are welcome to propose concrete text & change snippets to the current > charter text. > > - Jouni > > >> >> Regards, >> >> Behcet >> >> >> On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen >> wrote: >>> >>> >>> Now that the gap analysis I-D is almost on the stage of leaving the WG >>> and >>> the requirements I-D has almost completed IESG, it would be time to >>> return >>> to the rechartering topic. >>> >>> First, the latest revision can be found at: >>> https://github.com/jounikor/dmm-re-charter >>> >>> Second, have a look at it. There are few changes proposed by Alper eons >>> ago >>> and corrected milestones pointed by Behcet. >>> >>> Third, let us get this finally done.. >>> >>> - Jouni >>> >>> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>> >>>> Folks, >>>> >>>> Sorry for letting this topic to rot in a dark for the couple of last >>>> weeks. I'll crank out a revision shortly.. >>>> >>>> - Jouni & Dapeng >>> >>> >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm From nobody Thu May 29 16:01:47 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD7A1A04BA for ; Thu, 29 May 2014 16:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XW2D7wqLzg1 for ; Thu, 29 May 2014 16:01:42 -0700 (PDT) Received: from mail-pd0-x22e.google.com (mail-pd0-x22e.google.com [IPv6:2607:f8b0:400e:c02::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1811A0469 for ; Thu, 29 May 2014 16:01:42 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id r10so245415pdi.5 for ; Thu, 29 May 2014 16:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rnEeLFIZ/M3sANQ9EvNvsBmo4oj/xq2Bqk0KvoMkLQI=; b=I7zRDByHbtEYy6VE8rCRXCNQUdEcg40yWGWJJOckLXUgwP/OwLzoOfsF3gLimOcYWD 1pJQrCAO/QzIplolAIBi/PJphDMFKAEfQ65T1sJ7stmw88wrKYw3yiLUjO3dW1OzP5Im +snk+f3kQtr9BzQsL3LjtwEhclTDCRcEJliRMdKlin2ukgSOFJMO5UlaUMh1oIf+jHGP 1c/0N39R3iUDowdGRtoGlFCjgsjfGqQdCZMHecx00TsmfJhapwfIeG7Bl08RGtOAOSqM DxtRC2RIJrKrohN71jYD7ff9jnER47w1RWaCvLpfM5/u8wwG+MQGnfPwTPx/qC4BrEdI 7YMg== X-Received: by 10.66.237.8 with SMTP id uy8mr5107474pac.95.1401404498690; Thu, 29 May 2014 16:01:38 -0700 (PDT) Received: from [10.16.10.192] ([216.31.219.19]) by mx.google.com with ESMTPSA id pl10sm3000161pbb.56.2014.05.29.16.01.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 29 May 2014 16:01:37 -0700 (PDT) Message-ID: <5387BC50.4050100@gmail.com> Date: Fri, 30 May 2014 02:01:36 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: sarikaya@ieee.org References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <5387A09F.7070604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/BBbpHT2wJQVIfEGFlEURRZFOrLk Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 23:01:45 -0000 Bechet, All what we discuss here has been discussed 2-4 months ago already. Repeating myself: propose concrete text & change snippets. - Jouni 5/30/2014 12:29 AM, Behcet Sarikaya kirjoitti: > About two months ago I had made this proposal > > First cycle, select one from each category of solutions, client, > network based and routing based > Second cycle, select one from the selected ones as the dmm solution. > > which still stands, I think. > > > > On Thu, May 29, 2014 at 4:03 PM, Jouni Korhonen wrote: >> Bechet, >> >> 5/29/2014 11:52 PM, Behcet Sarikaya kirjoitti: >> >>> Hi Jouni, >>> >>> I was looking at the charter text and noticed one important issue. The >>> charter seems to be stuck with the good old anchor think. Almost all >>> text is about anchoring, anchor selection, anchor reselection, and so >>> on. >>> >>> However in the past several months, we have seen in Alper's events, >>> presentations which seem to have no anchor. >>> >>> I don't see any active draft that talks about the anchors. >>> >>> In view of this, my question is how are we going to go ahead with this >>> charter and meet the deadlines? >> >> >> I (myself) see still value dragging along some anchoring stuff just to allow >> smoother migration from current deployed models toward less centralized >> architectures. >> >> But you are right that we should not get stuck on those.. and that has not >> been the intent either. >> >> >>> Or else, are we better off with a charter text which is much less >>> dependent on the anchors, something which could make it possible to >>> progress one of those proposals?? >> >> >> You are welcome to propose concrete text & change snippets to the current >> charter text. >> >> - Jouni >> >> >>> >>> Regards, >>> >>> Behcet >>> >>> >>> On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen >>> wrote: >>>> >>>> >>>> Now that the gap analysis I-D is almost on the stage of leaving the WG >>>> and >>>> the requirements I-D has almost completed IESG, it would be time to >>>> return >>>> to the rechartering topic. >>>> >>>> First, the latest revision can be found at: >>>> https://github.com/jounikor/dmm-re-charter >>>> >>>> Second, have a look at it. There are few changes proposed by Alper eons >>>> ago >>>> and corrected milestones pointed by Behcet. >>>> >>>> Third, let us get this finally done.. >>>> >>>> - Jouni >>>> >>>> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>>> >>>>> Folks, >>>>> >>>>> Sorry for letting this topic to rot in a dark for the couple of last >>>>> weeks. I'll crank out a revision shortly.. >>>>> >>>>> - Jouni & Dapeng >>>> >>>> >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm From nobody Thu May 29 21:35:48 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392661A077B for ; Thu, 29 May 2014 21:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4DJ3EfrqEXD for ; Thu, 29 May 2014 21:35:45 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BBC1A0766 for ; Thu, 29 May 2014 21:35:45 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id um1so1271248pbc.18 for ; Thu, 29 May 2014 21:35:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type; bh=m4CmzkTZfjZvzzTeww3FbQWgmA7BE68xjHKHI7HYkJo=; b=Lvq36k/ozcRvLRHtKMORkZrYBIq6wI2n3VWeTNKb9SjIg66pMalVnsKXCYlP+03ied +VYEQxesjPRNA+Tis1WeXvGw3ts0RVdtsfsqlLphZ5ZiPVlyYSrf9Tb1AC4QtiBtQmca 3mC7X2VDqDB8vxqh+h0lJyE5MGuTKztJx9l9NxUWpsXxuWtDHrfXxHWdM88SN2VhsZru SFY0pas6UvyQymZGazZKVJsAioLQW16BPDb8SPgmUY1XA1N5bWUu6GTJ6Ej/sg4mKBoa Uj5CrVxUGDorp2Y3H+Vl8ia1YU0Dncv5z6lqFTUkwrXjezUZ859Kv4Om5nIN56jDkOhz nMkw== X-Received: by 10.66.122.208 with SMTP id lu16mr14396275pab.129.1401424541275; Thu, 29 May 2014 21:35:41 -0700 (PDT) Received: from [183.243.152.134] ([183.243.152.134]) by mx.google.com with ESMTPSA id bq4sm3917805pbb.60.2014.05.29.21.35.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 29 May 2014 21:35:40 -0700 (PDT) Date: Fri, 30 May 2014 12:39:33 +0800 From: Dapeng Liu To: dmm Message-ID: X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="53880b85_109cf92e_639c" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/6HPcjxdb0tq43L0Xw5qMqA6-ZC4 Subject: [DMM] Teleconference X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 04:35:47 -0000 --53880b85_109cf92e_639c Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, The WG decide to have a teleconference next week. Please select your prefer time in doodle. Doodle: https://doodle.com/d7fsc2gsdsgd2e52n438gimr/private?tmail=poll_invitecontact_participant_invitation&tlink=pollbtn Thanks, -- Dapeng&Jouni --53880b85_109cf92e_639c Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

    Hello= ,


    The WG decide to have a teleconference = next week. Please select your prefer time in doodle.


    Doodle:

    https://doodle.com/d7fsc= 2gsdsgd2e52n438gimr/private=3Ftmail=3Dpoll=5Finvitecontact=5Fparticipant=5F= invitation&tlink=3Dpollbtn


    Thanks,
    -- 
    Dapeng&= ;Jouni

    --53880b85_109cf92e_639c-- From nobody Thu May 29 22:58:21 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105B41A06EE for ; Thu, 29 May 2014 22:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UL8DhT98JyQG for ; Thu, 29 May 2014 22:58:07 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA02C1A0829 for ; Thu, 29 May 2014 22:58:04 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LgaRJ-1WVmNS166n-00npLw; Fri, 30 May 2014 01:57:59 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <5387A09F.7070604@gmail.com> Date: Fri, 30 May 2014 08:57:53 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <06C713BC-5AB0-46C7-B5B2-01D9B8120B6F@yegin.org> References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <5387A09F.7070604@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:H7vNnEOe0jCmDtFT6B47fXrhWYTIyh4E3/OVae8UTEl 8q+D5+AzuvPnXFpcBgoqFWUw/QJOflKK6Rz8Bsjd+x3mBKwZn0 nanzm+l/OujbflSHbypz070pRB2Fg5WZ2+JY1RqASx8nkx39Mu WAs2Bp8t5k1R3+jWUC71mwb2bTRnlIlq4PBmzRqEMksgCzWJJL 3mmdxp6A9/Bnytxf4X5lWmUr+ChgIF0iaaibpq2chI+JLLHeQx CwugHhBQx8tK0fz21GpVto2Y1dk6BuucJVdJkXLj+DZcwCIzKC RX3V0KheXgGLBnfuidXEmnPri90AaaJzTfuBaBNXXZeEyf+Sa1 NDqUfv18mXgaibL8AYYaxdtrWSICm4A95tlmtwwIE1w8R6G49P v3u4S3RYikKrQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/WezXmfTYfBsj6lkD6KR3ynf92M0 Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 05:58:18 -0000 IMO, solutions that do not rely on "anchors" are welcome. Even though the charter uses that term, we are not hung up on solutions = that have "anchors" Besides, remember I made an attempt to refine the term with an = additional one "deflector"=85 So, we do need to have some discussions = around that eventually. But I don't think we need to have that right now in the context of the = charter text. As long as people understand that anchor-less solutions are welcome for = discussion, and we may eventually refine the term, we can move forward = with the current text -- I'd say. Alper On May 30, 2014, at 12:03 AM, Jouni Korhonen wrote: > Bechet, >=20 > 5/29/2014 11:52 PM, Behcet Sarikaya kirjoitti: >> Hi Jouni, >>=20 >> I was looking at the charter text and noticed one important issue. = The >> charter seems to be stuck with the good old anchor think. Almost all >> text is about anchoring, anchor selection, anchor reselection, and so >> on. >>=20 >> However in the past several months, we have seen in Alper's events, >> presentations which seem to have no anchor. >>=20 >> I don't see any active draft that talks about the anchors. >>=20 >> In view of this, my question is how are we going to go ahead with = this >> charter and meet the deadlines? >=20 > I (myself) see still value dragging along some anchoring stuff just to = allow smoother migration from current deployed models toward less = centralized architectures. >=20 > But you are right that we should not get stuck on those.. and that has = not been the intent either. >=20 >> Or else, are we better off with a charter text which is much less >> dependent on the anchors, something which could make it possible to >> progress one of those proposals?? >=20 > You are welcome to propose concrete text & change snippets to the = current charter text. >=20 > - Jouni >=20 >>=20 >> Regards, >>=20 >> Behcet >>=20 >>=20 >> On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen = wrote: >>>=20 >>> Now that the gap analysis I-D is almost on the stage of leaving the = WG and >>> the requirements I-D has almost completed IESG, it would be time to = return >>> to the rechartering topic. >>>=20 >>> First, the latest revision can be found at: >>> https://github.com/jounikor/dmm-re-charter >>>=20 >>> Second, have a look at it. There are few changes proposed by Alper = eons ago >>> and corrected milestones pointed by Behcet. >>>=20 >>> Third, let us get this finally done.. >>>=20 >>> - Jouni >>>=20 >>> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>>=20 >>>> Folks, >>>>=20 >>>> Sorry for letting this topic to rot in a dark for the couple of = last >>>> weeks. I'll crank out a revision shortly.. >>>>=20 >>>> - Jouni & Dapeng >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri May 30 00:28:44 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2EC1A085C for ; Fri, 30 May 2014 00:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ-GZF0Zwrv0 for ; Fri, 30 May 2014 00:28:41 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7A31A085B for ; Fri, 30 May 2014 00:28:41 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0M6T2Z-1WbtkX01zH-00yJoU; Fri, 30 May 2014 03:28:06 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_1B2A12CC-3CE9-4A92-B988-C844BE927435" From: Alper Yegin In-Reply-To: <5382B78C.5060409@gmail.com> Date: Fri, 30 May 2014 10:28:01 +0300 Message-Id: References: <5382B78C.5060409@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:7EioT+UbS8syJPSHYSnkfS4gMOZy6kMFGVpWHJidrB7 wwp6tBRrLwaZEZD7qDdwCW1ZsA1qtpVOJgFuYKdt8x7asNzJ/U h8Q5KRFabJTVQ1Fr7gBVwrXHhGmhBjWQdniRtP7z0m176WNLdW bZcxP8PHEN44BNJ+YM3SozYrLWhcnCd+lRyaZrXkysP/Pw7hWF kwNx0Xj5yRvMsaFcS4XfTzPPtzeSMDy214Xnc+bOC0+95mzXNY 2LMqw9NITMCoQIqnXShOBMDACBlXn/WVLeWPgPBCZeE3Z1SUKP aK8D8ia+5qgZxnje7Spj6kxozRkZLlrXrONuLjhKRbFH00Pb9/ mHYYxZY4aPEuXs+ts3eP2/CFdThk4FnX1rOVE6SyhrvdDA9Tx4 i0/KSNYx9eM6Q== Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/r00iLCL2GnoO6F9OYGGyfyLSkds Cc: "dmm@ietf.org" , "dmm-chairs@tools.ietf.org" Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 07:28:43 -0000 --Apple-Mail=_1B2A12CC-3CE9-4A92-B988-C844BE927435 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Few comments=85 Red-colored text added below: The use of HMIPv6 enables some form of route optimization, since a mobile node may decide to directly use the RCoA as source address for a communication with a given correspondent node, particularly if the MN does not expect to move outside the local domain during the lifetime of the communication. This can be seen as a potential DMM mode of operation, though it fails to provide session continuity if=20= and when the MN moves outside the local domain. =20 In the example shown in Figure 3, MN1 is using its global HoA to communicate with CN1, while it is using its RCoA to communicate with CN2. o Multiple (distributed) anchoring: ability to anchor different sessions of a single mobile node at different anchors. In order to provide improved routing, some anchors might need to be placed closer to the mobile node or the corresponding node. s/boht/both Alper On May 26, 2014, at 6:39 AM, Jouni Korhonen wrote: > Folks, >=20 > This email starts a one week WGLC #2 for = draft-ietf-dmm-best-practices-gap-analysis-04. Issue you comments to the = mailing list and place possible tickets to the issue tracker. There are = quite a few changed mainly to tackle Charlie's comments. >=20 > The WGLC ends 2ns June 2014 EOB (EEST). Silence is accounted as an = acceptance for the content. >=20 > - Jouni (as a DMM co-chair) >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_1B2A12CC-3CE9-4A92-B988-C844BE927435 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Few = comments=85


    Red-colored text added = below:

       The use of HMIPv6 = enables some form of route optimization, since a
       a communication with a given = correspondent node, particularly if the
       MN does not = expect to move outside the local domain during the
       mode of operation, though it fails to = provide session continuity if 
       and when the = MN moves outside the local domain.  
       its global HoA to communicate with CN1, = while it is using its RCoA to
       communicate with = CN2.




          sessions of a single mobile = node at different anchors.  In order
          to = provide improved routing, some anchors might need to be placed
    or the corresponding = node.



    =

    Alper
    Folks,

    This email starts a one week WGLC #2 = for draft-ietf-dmm-best-practices-gap-analysis-04. Issue you comments to = the mailing list and place possible tickets to the issue tracker. There = are quite a few changed mainly to tackle Charlie's comments.

    The = WGLC ends 2ns June 2014 EOB (EEST). Silence is accounted as an = acceptance for the content.

    - Jouni (as a DMM = co-chair)

    _______________________________________________
    dmm = mailing list
    dmm@ietf.org
    https://www.ietf.org/mail= man/listinfo/dmm

    = --Apple-Mail=_1B2A12CC-3CE9-4A92-B988-C844BE927435-- From nobody Fri May 30 10:08:25 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8793E1A03C6 for ; Fri, 30 May 2014 10:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jra6bS3JP6-4 for ; Fri, 30 May 2014 10:08:20 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BA81A038E for ; Fri, 30 May 2014 10:08:20 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id rd3so1908370pab.15 for ; Fri, 30 May 2014 10:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DyOJNMGJHYuxqJkmWEl8iuC5EV7TcQnljG6vzPfagq4=; b=fo5sj7MKp8FKx0r6J1e/BjgfXnTVI/fGndxLP/Ced97JYA3QDf1sbtO/iTTt4EhPqa jx0ORlAe9cXUlzxHXD8qZD4/hpNDzz0UOJCIWnoP2lzXEQXHx3fzcsEPM/dtdNCnOJSw dW0UyCPWsfSEEr79fyb8n5T3lgBrncYvFjAJYkFj+HC/wOGDnSiL0sC8mNHds+kZwxOQ kfRm4fgMlqFU9MAouY/Cabr+V2AebG+aU9vphYh+IeI8N1uLK5rajWw6ORaBgWcLwqxD i8SJnPhgMl5JJPUXlkwXm37OXzG4cAmrWihstyDusmqd/eF7qtBQPUaWKFH2+LiGSGft 011Q== X-Received: by 10.68.192.106 with SMTP id hf10mr20299667pbc.30.1401469695967; Fri, 30 May 2014 10:08:15 -0700 (PDT) Received: from [10.16.10.43] ([216.31.219.19]) by mx.google.com with ESMTPSA id hb10sm7268861pbd.75.2014.05.30.10.08.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 30 May 2014 10:08:15 -0700 (PDT) Message-ID: <5388BAFD.6050009@gmail.com> Date: Fri, 30 May 2014 20:08:13 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Alper Yegin References: <535666B3.9060301@gmail.com> <538451E9.2020104@gmail.com> <5387A09F.7070604@gmail.com> <06C713BC-5AB0-46C7-B5B2-01D9B8120B6F@yegin.org> In-Reply-To: <06C713BC-5AB0-46C7-B5B2-01D9B8120B6F@yegin.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/9Q-ooNo364YfqvyB_SIk9B8RZ7A Cc: "dmm@ietf.org" Subject: Re: [DMM] rechartering X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:08:22 -0000 Agree. 5/30/2014 8:57 AM, Alper Yegin kirjoitti: > IMO, solutions that do not rely on "anchors" are welcome. > Even though the charter uses that term, we are not hung up on solutions that have "anchors" > Besides, remember I made an attempt to refine the term with an additional one "deflector"… So, we do need to have some discussions around that eventually. > But I don't think we need to have that right now in the context of the charter text. > As long as people understand that anchor-less solutions are welcome for discussion, and we may eventually refine the term, we can move forward with the current text -- I'd say. > > Alper > > > > On May 30, 2014, at 12:03 AM, Jouni Korhonen wrote: > >> Bechet, >> >> 5/29/2014 11:52 PM, Behcet Sarikaya kirjoitti: >>> Hi Jouni, >>> >>> I was looking at the charter text and noticed one important issue. The >>> charter seems to be stuck with the good old anchor think. Almost all >>> text is about anchoring, anchor selection, anchor reselection, and so >>> on. >>> >>> However in the past several months, we have seen in Alper's events, >>> presentations which seem to have no anchor. >>> >>> I don't see any active draft that talks about the anchors. >>> >>> In view of this, my question is how are we going to go ahead with this >>> charter and meet the deadlines? >> >> I (myself) see still value dragging along some anchoring stuff just to allow smoother migration from current deployed models toward less centralized architectures. >> >> But you are right that we should not get stuck on those.. and that has not been the intent either. >> >>> Or else, are we better off with a charter text which is much less >>> dependent on the anchors, something which could make it possible to >>> progress one of those proposals?? >> >> You are welcome to propose concrete text & change snippets to the current charter text. >> >> - Jouni >> >>> >>> Regards, >>> >>> Behcet >>> >>> >>> On Tue, May 27, 2014 at 3:50 AM, Jouni Korhonen wrote: >>>> >>>> Now that the gap analysis I-D is almost on the stage of leaving the WG and >>>> the requirements I-D has almost completed IESG, it would be time to return >>>> to the rechartering topic. >>>> >>>> First, the latest revision can be found at: >>>> https://github.com/jounikor/dmm-re-charter >>>> >>>> Second, have a look at it. There are few changes proposed by Alper eons ago >>>> and corrected milestones pointed by Behcet. >>>> >>>> Third, let us get this finally done.. >>>> >>>> - Jouni >>>> >>>> 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: >>>> >>>>> Folks, >>>>> >>>>> Sorry for letting this topic to rot in a dark for the couple of last >>>>> weeks. I'll crank out a revision shortly.. >>>>> >>>>> - Jouni & Dapeng >>>> >>>> >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > From nobody Fri May 30 10:41:19 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2B1A6FC0 for ; Fri, 30 May 2014 10:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.951 X-Spam-Level: X-Spam-Status: No, score=-8.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtEnKgIDVEtq for ; Fri, 30 May 2014 10:41:16 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id E7AC01A6FBB for ; Fri, 30 May 2014 10:41:15 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 30 May 2014 10:41:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.98,942,1392192000"; d="scan'208,217";a="549031967" Received: from fmsmsx108.amr.corp.intel.com ([10.19.9.228]) by orsmga002.jf.intel.com with ESMTP; 30 May 2014 10:41:10 -0700 Received: from fmsmsx155.amr.corp.intel.com (10.18.116.71) by FMSMSX108.amr.corp.intel.com (10.19.9.228) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 30 May 2014 10:41:10 -0700 Received: from hasmsx103.ger.corp.intel.com (10.184.198.6) by FMSMSX155.amr.corp.intel.com (10.18.116.71) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 30 May 2014 10:41:09 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.111]) by HASMSX103.ger.corp.intel.com ([169.254.6.103]) with mapi id 14.03.0123.003; Fri, 30 May 2014 20:41:07 +0300 From: "Moses, Danny" To: Dapeng Liu , dmm Thread-Topic: [DMM] Teleconference Thread-Index: AQHPe8CqW/LZ9qpb3UuHlEVVFYcob5tZZL4w Date: Fri, 30 May 2014 17:41:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2811AE0160DHASMSX106gercor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ACbVnUEolDvDyRg9G-Rqv4Ev_s4 Subject: Re: [DMM] Teleconference X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2014 17:41:18 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2811AE0160DHASMSX106gercor_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkuIEZvciBzb21lIHJlYXNvbiBJIGNhbm5vdCB2b3RlLiBXaGVuIGVudGVyaW5nIERvb2RsZSBJ IHJlY2VpdmUgYW4gaW5kaWNhdGlvbiB0aGF0IEkgaGF2ZSBhbHJlYWR5IHZvdGVkIGV2ZW4gdGhv dWdoIEkgZGlkIG5vdC4NCg0KQW0gSSB0aGUgb25seSBvbmU/DQoNClRoYW5rcywNCiAgICAgICAg ICAgICAgICAvRGFubnkNCg0KRnJvbTogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBEYXBlbmcgTGl1DQpTZW50OiBGcmlkYXksIE1heSAzMCwgMjAxNCAwNzo0 MA0KVG86IGRtbQ0KU3ViamVjdDogW0RNTV0gVGVsZWNvbmZlcmVuY2UNCg0KDQpIZWxsbywNCg0K DQoNClRoZSBXRyBkZWNpZGUgdG8gaGF2ZSBhIHRlbGVjb25mZXJlbmNlIG5leHQgd2Vlay4gUGxl YXNlIHNlbGVjdCB5b3VyIHByZWZlciB0aW1lIGluIGRvb2RsZS4NCg0KDQoNCkRvb2RsZToNCg0K aHR0cHM6Ly9kb29kbGUuY29tL2Q3ZnNjMmdzZHNnZDJlNTJuNDM4Z2ltci9wcml2YXRlP3RtYWls PXBvbGxfaW52aXRlY29udGFjdF9wYXJ0aWNpcGFudF9pbnZpdGF0aW9uJnRsaW5rPXBvbGxidG4N Cg0KVGhhbmtzLA0KLS0NCkRhcGVuZyZKb3VuaQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQSBtZW1iZXIgb2Yg dGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9mIGNvbXBhbmllcwoKVGhpcyBlLW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgbWF0ZXJpYWwgZm9yCnRo ZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpLiBBbnkgcmV2aWV3IG9yIGRp c3RyaWJ1dGlvbgpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkCnJlY2lwaWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIGFsbCBjb3BpZXMuCg== --_000_F0CF5715D3D1884BAC731EA1103AC2811AE0160DHASMSX106gercor_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SGkuIEZvciBzb21lIHJlYXNvbiBJIGNhbm5vdCB2b3RlLiBXaGVuIGVudGVyaW5nIERvb2Rs ZSBJIHJlY2VpdmUgYW4gaW5kaWNhdGlvbiB0aGF0IEkgaGF2ZSBhbHJlYWR5IHZvdGVkIGV2ZW4g dGhvdWdoIEkgZGlkIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFtIEkgdGhlIG9ubHkgb25lPw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAvRGFubnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IGRtbSBbbWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5EYXBlbmcgTGl1PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDMwLCAyMDE0 IDA3OjQwPGJyPg0KPGI+VG86PC9iPiBkbW08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0RNTV0gVGVs ZWNvbmZlcmVuY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjow aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21pbi1oZWlnaHQ6IDExcHgiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowaW47bWFyZ2luLWJvdHRvbTouMDAwMXB0O21pbi1o ZWlnaHQ6IDExcHgiPlRoZSBXRyBkZWNpZGUgdG8gaGF2ZSBhIHRlbGVjb25mZXJlbmNlIG5leHQg d2Vlay4gUGxlYXNlIHNlbGVjdCB5b3VyIHByZWZlciB0aW1lIGluIGRvb2RsZS48bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdDttaW4taGVp Z2h0OiAxMXB4Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkRvb2RsZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjx1PjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzA0MzNG RiI+PGEgaHJlZj0iaHR0cHM6Ly9kb29kbGUuY29tL2Q3ZnNjMmdzZHNnZDJlNTJuNDM4Z2ltci9w cml2YXRlP3RtYWlsPXBvbGxfaW52aXRlY29udGFjdF9wYXJ0aWNpcGFudF9pbnZpdGF0aW9uJmFt cDt0bGluaz1wb2xsYnRuIj5odHRwczovL2Rvb2RsZS5jb20vZDdmc2MyZ3Nkc2dkMmU1Mm40Mzhn aW1yL3ByaXZhdGU/dG1haWw9cG9sbF9pbnZpdGVjb250YWN0X3BhcnRpY2lwYW50X2ludml0YXRp b24mYW1wO3RsaW5rPXBvbGxidG48L2E+PC9zcGFuPjwvdT48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwNDMz RkYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXBlbmcmYW1wO0pvdW5pPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4KQSBtZW1iZXIgb2Yg dGhlIEludGVsIENvcnBvcmF0aW9uIGdyb3VwIG9mIGNvbXBhbmllczwvcD4KCjxwPlRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG1hdGVyaWFs IGZvcjxicj4KdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykuIEFueSBy ZXZpZXcgb3IgZGlzdHJpYnV0aW9uPGJyPgpieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkPGJyPgpyZWNpcGllbnQsIHBsZWFzZSBjb250 YWN0IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSBhbGwgY29waWVzLjwvcD48L2JvZHk+DQo8L2h0bWw+ DQo= --_000_F0CF5715D3D1884BAC731EA1103AC2811AE0160DHASMSX106gercor_-- From nobody Sat May 31 03:05:47 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8DB1A07DE for ; Sat, 31 May 2014 03:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzEkOywIROhY for ; Sat, 31 May 2014 03:05:43 -0700 (PDT) Received: from out49-ams.mf.surf.net (out49-ams.mf.surf.net [145.0.1.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826351A07CD for ; Sat, 31 May 2014 03:05:42 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s4VA5YEA014509; Sat, 31 May 2014 12:05:35 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sat, 31 May 2014 12:05:39 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.152]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Sat, 31 May 2014 12:05:34 +0200 From: To: , , Thread-Topic: [DMM] Teleconference Thread-Index: AQHPe8Cl7Ypn7lqlM0qQGRokYazZgZtZQ6OAgAE0Ws8= Date: Sat, 31 May 2014 10:05:33 +0000 Message-ID: References: , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47893AEXMBX23adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vM8y5yEx - db010bb5ae59 - 20140531 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ugks4dFul0jcbXuYWAp69ESVAto Subject: Re: [DMM] Teleconference X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 10:05:45 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47893AEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Danny, Hi all, Yes, I am getting the same indication and I cannot vote! Best regards, Georgios ________________________________ Van: dmm [dmm-bounces@ietf.org] namens Moses, Danny [danny.moses@intel.com] Verzonden: vrijdag 30 mei 2014 19:41 Aan: Dapeng Liu; dmm Onderwerp: Re: [DMM] Teleconference Hi. For some reason I cannot vote. When entering Doodle I receive an indica= tion that I have already voted even though I did not. Am I the only one? Thanks, /Danny From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dapeng Liu Sent: Friday, May 30, 2014 07:40 To: dmm Subject: [DMM] Teleconference Hello, The WG decide to have a teleconference next week. Please select your prefer= time in doodle. Doodle: https://doodle.com/d7fsc2gsdsgd2e52n438gimr/private?tmail=3Dpoll_invitecont= act_participant_invitation&tlink=3Dpollbtn Thanks, -- Dapeng&Jouni --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47893AEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi Danny, Hi all,

     

    Yes, I am getting the same indication and I cannot vote!

    Best regards,

    Georgios

     

    Van: dmm [dmm-bounces@ietf.org] namens Mos= es, Danny [danny.moses@intel.com]
    Verzonden: vrijdag 30 mei 2014 19:41
    Aan: Dapeng Liu; dmm
    Onderwerp: Re: [DMM] Teleconference

    Hi. For some reason I cannot vote. When en= tering Doodle I receive an indication that I have already voted even though= I did not.

     

    Am I the only one?

     

    Thanks,

           =          /Danny

     

    From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dapeng Liu
    Sent: Friday, May 30, 2014 07:40
    To: dmm
    Subject: [DMM] Teleconference

     

    Hello,

     

    The WG decide to have a = teleconference next week. Please select your prefer time in doodle.

     

    Doodle:

    https://doodle.com/d7fsc2gsdsgd2e52n438gimr/= private?tmail=3Dpoll_invitecontact_participant_invitation&tlink=3Dpollb= tn

     

    Thanks,

    -- 

    Dapeng&Jouni

     

    --------------------------------------------------------------------- A member of the Intel Corporation group of companies

    This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution
    by others is strictly prohibited. If you are not the intended
    recipient, please contact the sender and delete all copies.

    --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F47893AEXMBX23adutwent_-- From nobody Sat May 31 08:41:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CA61A0005 for ; Sat, 31 May 2014 08:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDOjFFC68sKv for ; Sat, 31 May 2014 08:41:51 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id A51981A0004 for ; Sat, 31 May 2014 08:41:51 -0700 (PDT) Received: from [99.51.72.196] (helo=[192.168.1.81]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1WqlPi-0007pU-SZ; Sat, 31 May 2014 11:41:43 -0400 Message-ID: <5389F832.1030700@computer.org> Date: Sat, 31 May 2014 08:41:38 -0700 From: "Charles E. Perkins" Organization: Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: karagian@cs.utwente.nl, danny.moses@intel.com, maxpassion@gmail.com, dmm@ietf.org References: , In-Reply-To: Content-Type: multipart/alternative; boundary="------------020604020008020208000205" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7749910d8f32870c1c45e087e16ed65ed350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Flkmx170HbErD-E0nW52a2aUwwE Subject: Re: [DMM] Teleconference X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 May 2014 15:41:53 -0000 This is a multi-part message in MIME format. --------------020604020008020208000205 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello folks, Likewise here. I am not available on Wednesday or Friday early morning Pacific Time, or on Tuesday around lunchtime, or Monday or Friday evening, or Thursday afternoon. For most of the week, except for the indicated times, I will be able to attend. Regards, Charlie P. On 5/31/2014 3:05 AM, karagian@cs.utwente.nl wrote: > > Hi Danny, Hi all, > > Yes, I am getting the same indication and I cannot vote! > > Best regards, > > Georgios > > ------------------------------------------------------------------------ > *Van:* dmm [dmm-bounces@ietf.org] namens Moses, Danny > [danny.moses@intel.com] > *Verzonden:* vrijdag 30 mei 2014 19:41 > *Aan:* Dapeng Liu; dmm > *Onderwerp:* Re: [DMM] Teleconference > > Hi. For some reason I cannot vote. When entering Doodle I receive an > indication that I have already voted even though I did not. > > Am I the only one? > > Thanks, > > /Danny > > *From:*dmm [mailto:dmm-bounces@ietf.org] *On Behalf Of *Dapeng Liu > *Sent:* Friday, May 30, 2014 07:40 > *To:* dmm > *Subject:* [DMM] Teleconference > > Hello, > > The WG decide to have a teleconference next week. Please select your > prefer time in doodle. > > Doodle: > > _https://doodle.com/d7fsc2gsdsgd2e52n438gimr/private?tmail=poll_invitecontact_participant_invitation&tlink=pollbtn_ > > Thanks, > > -- > > Dapeng&Jouni > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm -- Regards, Charlie P. --------------020604020008020208000205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
    Hello folks,

    Likewise here.

    I am not available on Wednesday or Friday early morning
    Pacific Time, or on Tuesday around lunchtime, or Monday
    or Friday evening, or Thursday afternoon.  For most of the
    week, except for the indicated times, I will be able to attend.

    Regards,
    Charlie P.


    On 5/31/2014 3:05 AM, karagian@cs.utwente.nl wrote:

    Hi Danny, Hi all,

     

    Yes, I am getting the same indication and I cannot vote!

    Best regards,

    Georgios

     

    Van: dmm [dmm-bounces@ietf.org] namens Moses, Danny [danny.moses@intel.com]
    Verzonden: vrijdag 30 mei 2014 19:41
    Aan: Dapeng Liu; dmm
    Onderwerp: Re: [DMM] Teleconference

    Hi. For some reason I cannot vote. When entering Doodle I receive an indication that I have already voted even though I did not.

     

    Am I the only one?

     

    Thanks,

                    /Danny

     

    From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Dapeng Liu
    Sent: Friday, May 30, 2014 07:40
    To: dmm
    Subject: [DMM] Teleconference

     

    Hello,

     

    The WG decide to have a teleconference next week. Please select your prefer time in doodle.

     

    Doodle:

    https://doodle.com/d7fsc2gsdsgd2e52n438gimr/private?tmail=poll_invitecontact_participant_invitation&tlink=pollbtn

     

    Thanks,

    -- 

    Dapeng&Jouni

     

    ---------------------------------------------------------------------
    A member of the Intel Corporation group of companies

    This e-mail and any attachments may contain confidential material for
    the sole use of the intended recipient(s). Any review or distribution
    by others is strictly prohibited. If you are not the intended
    recipient, please contact the sender and delete all copies.



    _______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



    -- 
Regards,
Charlie P.
    --------------020604020008020208000205--