From karagian@cs.utwente.nl Sun Nov 3 06:35:41 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08BE411E8282 for ; Sun, 3 Nov 2013 06:35:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.203 X-Spam-Level: X-Spam-Status: No, score=-0.203 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rb+CFP3zuLQ4 for ; Sun, 3 Nov 2013 06:35:36 -0800 (PST) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id C42B011E829F for ; Sun, 3 Nov 2013 06:35:31 -0800 (PST) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sun, 3 Nov 2013 15:35:32 +0100 Received: from EXMBX23.ad.utwente.nl ([169.254.3.67]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Sun, 3 Nov 2013 15:35:30 +0100 From: To: Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analysis-02.txt Thread-Index: AQHO0I5jXFPkyX7VqUq/RM9GAZw+t5oTojSGgAAAm+s= Date: Sun, 3 Nov 2013 14:35:28 +0000 Message-ID: References: <20131021215137.32508.53515.idtracker@ietfa.amsl.com>, <72A59607-C034-4972-81E2-2FC6DD74B64B@gmail.com> In-Reply-To: <72A59607-C034-4972-81E2-2FC6DD74B64B@gmail.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [64.114.24.114] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F52CFEXMBX23adutwent_" MIME-Version: 1.0 Subject: Re: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analysis-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 14:35:41 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F52CFEXMBX23adutwent_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I have reviewed draft-ietf-dmm-best-practices-gap-analysis-02.txt: http://tools.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-02.txt Below you can see my initial comments: Comment_1: Emphasize in Section 1 that the gaps (limitations) that are desc= ribed in this draft are related to(depend on) the requirements that are spe= cified by the DMM WG. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment_2: Section 4.1: I miss two assumptions that in my opinion will be needed to be considered: Assumption 5: Solutions should allow to select the entity (ingress to the D= MM plane) where the traffic redirection should start. Please notice that in this way, an entity, which might not be the original = (source) anchor point to redirect the traffic towards the target anchor poi= nt. This is needed in order to optimize the data plane performance. Assumption 6: The solution should be able to manage the period of time that= the traffic redirection towards a target anchor point needs to be maintain= ed. Please notice that this assumption is needed, since redirection of traffic = from an original anchor point to a new anchor point cannot be maintained f= or ever. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment_3: Please explain whether the solutions described in Sections 4.2 a= nd 4.3 support all the assumptions or a subset of the assumptions described= in Section 4.1. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment_4: In table 5.8 a table is given that shows the gaps (limitations) = of the presented solutions. It is not clear, in the text, why solutions MIP= v6 RO and HMIPv6 are able to support requirement REQ2: Transparency to Uppe= r Layers=94, while all the other solutions are not able to support this req= uirement. Please elaborate on this point in Section 5.2. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comment_5: More solutions could be included in the gap related discussion. = In particular in September 2012, I had proposed on the DMM mailing list a s= et of such solutions: http://www.ietf.org/mail-archive/web/dmm/current/msg00372.html =3D=3D=3D=3D=3D=3D=3D=3D=3D Comment_6: I found some editorials. Some examples are: Section 4.1, page 6, Assumption 3, please change from: =93.. Typically, the a connection ..=94 INTO: =93.. Typically, the connection ..=94 Section 4.2.1, page 12: please change from: =93There other host-based approaches ..=94 INTO: =93There are other host-based approaches ..=94 Best regards, Georgios ________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Jouni Korhonen [jou= ni.nospam@gmail.com] Verzonden: donderdag 24 oktober 2013 9:54 To: dmm@ietf.org Onderwerp: Re: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-analysis= -02.txt Folks, Please review the latest revision of the gap analysis and pay close attention to the conclusions (Section 5.8.) the I-D draws. I'd like to remind you that this I-D is the justification for the possible further work and rechartering. This implies, the conclusions on gaps and identified new work needed must be then found from this I-D. The discussion has to start already before the meeting. - Jouni (on behalf of the chairs) On Oct 22, 2013, at 12:51 AM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Distributed Mobility Management Working = Group of the IETF. > > Title : Distributed Mobility Management: Current practic= es and gap analysis > Author(s) : Dapeng Liu > Juan Carlos Zuniga > Pierrick Seite > H Anthony Chan > Carlos J. Bernardos > Filename : draft-ietf-dmm-best-practices-gap-analysis-02.tx= t > Pages : 26 > Date : 2013-10-21 > > Abstract: > The present document analyses deplyment practices of existing > mobility protocols in a distributed mobility management environment. > It also identifies some limitations compared to the expected > functionality of a fully distributed mobility management system. The > comparison is made taking into account the identified DMM > requirements. > _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F52CFEXMBX23adutwent_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi all,

 

I have reviewed draft-ietf= -dmm-best-practices-gap-analysis-02.txt:

 

http://tools.ietf.org/id/d= raft-ietf-dmm-best-practices-gap-analysis-02.txt

 

Below you can see my initi= al comments:

 

Comment_1: Emphasize in Se= ction 1 that the gaps (limitations) that are described in this draft are re= lated to(depend on) the requirements that are specified by the DMM WG.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

 

Comment_2: Section 4.1:

I miss two assumptions tha= t in my opinion will be needed to be considered:

 

Assumption 5: Solutions sh= ould allow to select the entity (ingress to the DMM plane)  where the traffic redirectio= n should start.

 

Please notice that in this= way, an entity, which might not be the original (source) anchor point to r= edirect the traffic towards the target anchor point.

This is needed in order to= optimize the data plane performance.

 

Assumption 6: The solution= should be able to manage the period of time that the traffic redirection t= owards a target anchor point needs to be maintained.

 

Please notice that this as= sumption is needed, since redirection of traffic from an original anchor po= int to a new anchor  point cannot be maintained for ever.

 

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

 

Comment_3: Please explain = whether the solutions described in Sections 4.2 and 4.3 support all the ass= umptions or a subset of the assumptions described in Section 4.1.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Comment_4: In table 5.8 a = table is given that shows the gaps (limitations) of the presented solutions= . It is not clear, in the text, why solutions MIPv6 RO and HMIPv6 are able to support requirement REQ2: Transparency to = Upper Layers=94, while all the other solutions are not able to support this= requirement.

Please elaborate on this p= oint in Section 5.2.

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Comment_5: More solutions = could be included in the gap related discussion. In particular in September= 2012, I had proposed on the DMM mailing list a set of such solutions:

 

http://www.ietf.org/mail-archive/web/dmm/current/msg00372.html

 

=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Comment_6: I found some ed= itorials. Some examples are:

 

Section 4.1, page 6, Assum= ption 3, please change from:

=93.. Typically, the a con= nection ..=94

 

INTO:

 

=93.. Typically, the conne= ction ..=94

 

Section 4.2.1, page 12: pl= ease change from:

=93There other host-based = approaches ..=94

INTO:

=93There are other host-ba= sed approaches ..=94

 

 

Best regards,

Georgios

 

Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Jouni Ko= rhonen [jouni.nospam@gmail.com]
Verzonden: donderdag 24 oktober 2013 9:54
To: dmm@ietf.org
Onderwerp: Re: [DMM] I-D Action: draft-ietf-dmm-best-practices-gap-a= nalysis-02.txt

Folks,

Please review the latest revision of the gap analysis and
pay close attention to the conclusions (Section 5.8.) the
I-D draws. I'd like to remind you that this I-D is the
justification for the possible further work and rechartering.
This implies, the conclusions on gaps and identified new
work needed must be then found from this I-D.

The discussion has to start already before the meeting.

- Jouni (on behalf of the chairs)



On Oct 22, 2013, at 12:51 AM, internet-drafts@ietf.org wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Distributed Mobility Management Worki= ng Group of the IETF.
>
>        Title    = ;       : Distributed Mobility Management: Cu= rrent practices and gap analysis
>        Author(s)   &= nbsp;   : Dapeng Liu
>            = ;            &n= bsp; Juan Carlos Zuniga
>            = ;            &n= bsp; Pierrick Seite
>            = ;            &n= bsp; H Anthony Chan
>            = ;            &n= bsp; Carlos J. Bernardos
>        Filename   &n= bsp;    : draft-ietf-dmm-best-practices-gap-analysis-02.txt<= br> >        Pages    = ;       : 26
>        Date    =         : 2013-10-21
>
> Abstract:
>   The present document analyses deplyment practices of exist= ing
>   mobility protocols in a distributed mobility management en= vironment.
>   It also identifies some limitations compared to the expect= ed
>   functionality of a fully distributed mobility management s= ystem.  The
>   comparison is made taking into account the identified DMM<= br> >   requirements.
>

_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm
--_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3F52CFEXMBX23adutwent_-- From Marco.Liebsch@neclab.eu Sun Nov 3 16:44:15 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148E021F9EE5 for ; Sun, 3 Nov 2013 16:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6ltLn1jh4yd for ; Sun, 3 Nov 2013 16:44:09 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 1F22B11E8245 for ; Sun, 3 Nov 2013 16:44:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 6DC24105E3F for ; Mon, 4 Nov 2013 01:38:05 +0100 (CET) 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 ZW6ZPSWQZoxm for ; Mon, 4 Nov 2013 01:38:05 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 4748A105EDB for ; Mon, 4 Nov 2013 01:38:00 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.11]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 4 Nov 2013 01:44:00 +0100 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: review of draft-ietf-dmm-best-practices-gap-analysis-02 Thread-Index: Ac7Y9t0oh3opQjX7SB2cA5SBjZVGrQ== Date: Mon, 4 Nov 2013 00:43:59 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D6373E70C@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [DMM] review of draft-ietf-dmm-best-practices-gap-analysis-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 00:44:15 -0000 Please find below some comments about draft-ietf-dmm-best-practices-gap-ana= lysis-02. Authors did a good job in merging two BCP and gap analysis drafts. I have s= ome comments though which may help to improve readability and gaining advantage from suc= h document. General notes: I think it's important to consider MN capability in the gap analysis. If a host cannot differentiate the type of source IP address (deprecated, c= urrent), it's supposed to be a gap, isn't it? Not sure we can just assume the MN can= handle and use multiple IP addresses in a DMM-friendly way, means not to use IP addresses from previous anchors for new data sessions. Maybe a small section on host considerations would be good. About Section 5, which is about the gap analysis, my personal opinion is th= at it's better to match gaps against functional elements, which are required to ena= ble optimal decentralized deployment and optimal paths, instead of describing t= hem by a match against a list of requirements as per the DMM requirements draft= . The advantage of the match against identified functions for DMM is that the protocol gap gets clear, e.g. export/import of HoA context and transfer bet= ween anchors, data plane indirection to transport packets to an anchor, which im= ports a topologically incorrect HoA,..=20 Just an opinion, not necessarily biased by being an author of a DMM framewo= rk draft ;-) Section 1. Introduction '.. how these functions can be reconfigured to work in a DMM environment..' What does reconfiguration of functions mean? A HA or LMA have different fun= ction. These are co-located. Now you can place one or multiple HAs on different location= s in the topology to enable DMM by exploiting e.g. multiple registration support. But the mea= ning of reconfiguration in this context is not clear to me. Section 2. Terminology This section defines some terms for relevant functions. These should be rel= ated to IP mobility protocols or refer to general functions, such as a router, which has no mobility func= tionality. It defines Mobility Routing as the function to intercept packets. Typically= that's the topological anchor doing that, otherwise the packet won't arrive at that fu= nction. Sect. 3 introduces the AF. If that's really considered a separate function = compared to the MR, I'd propose defining all relevant functions in the Terms section 2 = instead of introducing the AF in section 3. But IMHO, these are the same functions. Location Management: Why not using known terms of locator and identifier IP= addresses? The Location Management resolved the HoA/HNP, which is treated as identifie= r, into the locator IP address, which is the topologically correct address representing= the MN's location, e.g. the (proxy) CoA. The chosen term 'MN routing address' seems not so cle= ar to me. =20 Section 3. Functions of existing mobility protocols '..are both logically centralized mobility management approaches..' =20 Does this refer to fact that protocol specifications co-locate several of t= he functions MR/AF, LM.. ? That's not centralized. Or does it refer to the centralized deployment of mobility anchors? Here I = would disagree. You can deploy host MIP and PMIP in a decentralized way by placin= g LMAs/HAs at the edge. Continuity of IP addresses works out of the box. Please clarif= y which kind of centralization you refer to here. 'Internetwork Location Management'. Text needs IMO clarification about the kind of resolution. This is a mobility-specific function and I'd describe i= t as it resolves the HoA of the MN into a locator IP address, either a CoA (MIP, PMIP) or a next mobility anchor (MAP). In case of HMIP, there is simply a chain of LMs, each doing the same. It must be clear in the text that the LM is a mobility protocol-specific function. Section 4.1 'Since this document cannot be too exhaustive..' I don't think that's the constraint to limit the number of pages of this do= cument ;-) I'd describe that the scope of the BCP and the gap analysis is determined c= learly by given IP mobility protocols and any kind of deployment options which do not viola= te the original specification. Point number 3 in the list: '..IP flows of applications which do not need a constant IP address should = not be handled by DMM..' I don't think the DMM solution explicitly excludes traffic of such applicat= ions; that's how I read it. What about this: "Applications which adopt to changes in the MN's IP addres= s do not depend on DMM." Point number 4 in this list:=20 '4. Mobility management and traffic redirection should only be triggered due to IP mobility reasons, that is when the MN moves from the point of attachment where the IP flow was originally initiated.' Please clarify what's meant with 'point of attachment' here. Is it the topological anchor of the MN's IP address (HA, LMA) or is it the Access Point/Router, which represents the locator/CoA? Section 4.2.2 Network-based IP DMM practices 'As with Mobile IPv6, plain Proxy Mobile IPv6 operation cannot be easily de= centralized..' I would not see it that strict, as the draft describes later that decentral= ized deployment is possible by placing LMAs at the edge. That's decentralization. Also it r= esults in a good routing path to the MN (from the mobility anchor point of view). That path = turns into a more sub-optimal one after mobility. So, I would separate the problem of = decentralized operation and maintenance of optimal paths in this analysis. Section 4.3. 3GPP network flattening approaches I fully agree that 3GPP is a potential vendor of DMM solutions, but I am wo= ndering how relevant this larger section is in the BCP and gap analysis draft. It c= ould be shortened by just describing that 3GPP deploys local anchor points for MNs (to differ= entiate from TOF-like hacks for UMTS) and has mechanisms for local anchor selection acco= rding to the MN's location. Just as a note. Section 5.1 It's written that for client MIP it's not an issue to manage multiple IP ad= dresses anchored at different anchors. Maybe it should be noted to have a gap on th= e MN to handle IP addresses in a DMM-friendly way. That means IP addresses of previous mobility anchors are classified as deprecated and should not be used for new sessions. This section describes the gap of transferring mobility context between anc= hors. If the intention is to import mobility context including HoA into a differe= nt anchor, a relevant gap is the forwarding of traffic to that importing anchor. That = gap can be seen in the routing plane above anchors or in mobility-protocols to forw= ard traffic from a topologically correct previous anchor to the importing ancho= r. =20 Best regards, marco From alper.yegin@yegin.org Mon Nov 4 10:19:58 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88BF21E8097 for ; Mon, 4 Nov 2013 10:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd0ITXnyD8NB for ; Mon, 4 Nov 2013 10:19:52 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7F72F11E81FB for ; Mon, 4 Nov 2013 10:19:52 -0800 (PST) Received: from [10.119.8.2] (213-128-81-68.turkrdns.com [213.128.81.68]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MOfDa-1VXMby2COc-006GDj; Mon, 04 Nov 2013 13:19:51 -0500 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_187FD82C-8A43-4ABC-8D70-54DED59D86DD" Date: Mon, 4 Nov 2013 20:19:45 +0200 Message-Id: <660E41D7-7F6A-47B4-86CE-C00ECA136DA8@yegin.org> To: dmm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:h4slQ0kRUKJiagcx+CcDwfOlBpWuRTer/pFMpCBQzZF fKWkMBAooZjfrhreeo9tavkGAtL0TKPl65R0buYzWHnwk7i9EN nwx+e8RXzQAEw9IOQVcNhaWvUUmamHQPRN/dYYkxTAa5oLizDk nI6nUrtMNMExr7qG7HW2yx1tnsrKOsfRkr7SILkKGE1GQaPQA5 a80/f0ALskr8Z8rTaUUnZoo46ALlloVCDbkyUM9YBE8j5pALel eJdT997xdqKPEfjU8N/HnOwq0AYxc7o6S8gFreEA8dESxRqFVX nTLNWipufTdhzPXkGW8KplVODmSRZAb0vyRpY5YjyEcO2v4bYO QzoQLJTSzGFws1UMAr3gAN+f67Nb0+dsUVjOVXe7i Subject: [DMM] Requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:19:58 -0000 --Apple-Mail=_187FD82C-8A43-4ABC-8D70-54DED59D86DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello folks, Here I have two comments on this document. "When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be considered to be eliminated." I don't quite understand what that means.=20 "Infrequent node mobility coupled with application intelligence suggest that mobility support could be provided selectively such as in [I-D.bhandari-dhc-class-based- prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing the amount of context maintained in the network." Two more related work references that are complementary to the ones = already provided are: - draft-yegin-dmm-ondemand-mobility-00 - draft-liu-dmm-mobility-api-01 I recommend we include these references as well. Alper --Apple-Mail=_187FD82C-8A43-4ABC-8D70-54DED59D86DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = folks,

Here I have two comments on this = document.

"When the existing security = mechanisms/protocols are
applied to protect the DMM = entities, the security risks that
may be introduced by DMM MUST be = considered to be eliminated."

I don't quite understand = what that means. 

"Infrequent node mobility coupled = with
application intelligence suggest that mobility = support could be
provided selectively such as in = [I-D.bhandari-dhc-class-based-
prefix] and = [I-D.korhonen-6man-prefix-properties], thus reducing
the = amount of context maintained in the network."
Two more related work references that are = complementary to the ones already provided are:
- = draft-yegin-dmm-ondemand-mobility-00
- = draft-liu-dmm-mobility-api-01

I recommend we include these = references as well.

Alper

Date: Tue, 05 Nov 2013 02:20:41 +0100 Organization: Universidad Carlos III de Madrid Content-Type: multipart/mixed; boundary="=-iJolKQdIisAQUthTp5qu" X-Mailer: Evolution 3.8.5-2 Mime-Version: 1.0 X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20268.003 Subject: [DMM] Review of draft-liebsch-dmm-framework-analysis-02 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:20:54 -0000 --=-iJolKQdIisAQUthTp5qu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, I've read the latest version of the draft. I think it is a useful exercise. I have some comments/questions in form of a PDF (attached) with comments. I hope this is fine, if not I can try to extract my comments and post them in an e-mail. Thanks, Carlos --=-iJolKQdIisAQUthTp5qu Content-Type: application/pdf; name="draft-liebsch-dmm-framework-analysis-02.pdf" Content-Disposition: attachment; filename="draft-liebsch-dmm-framework-analysis-02.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjQKJeLjz9MKMSAwIG9iago8PAovVGl0bGUgKGRyYWZ0LWxpZWJzY2gtZG1tLWZyYW1l d29yay1hbmFseXNpcy0wMiAtIERpc3RyaWJ1dGVkIE1vYmlsaXR5IE1hbmFnZW1lbnQgLSBGcmFt ZXdvcmsgJiBBbmFseXNpcykKL0F1dGhvciAoKQovQ3JlYXRvciAoaHRtbDJwcyB2ZXJzaW9uIDEu MCBiZXRhNykKL01vZERhdGUgKEQ6MjAxMzExMDIxOTQwNTUrMDEnMDAnKQovU3ViamVjdCAoKQov S2V5d29yZHMgKCkKL1Byb2R1Y2VyIChHUEwgR2hvc3RzY3JpcHQgOS4wMikKL0NyZWF0aW9uRGF0 ZSAoRDoyMDEzMTAyMjA4MzkwNyswMicwMCcpCi9QWENWaWV3ZXJJbmZvIChQREYtWENoYW5nZSBW aWV3ZXI7Mi41LjIwNy4wIFsqBQFQcml2YXRlQnVpbGRdO05vdiAxMiAyMDEyOzIwOjAxOjM3O0Q6 MjAxMzExMDIxOTQwNTUrMDEnMDAnKQo+PgplbmRvYmoKMiAwIG9iago8PAovVHlwZSAvQ2F0YWxv ZwovRGVzdHMgMyAwIFIKL1BhZ2VzIDQgMCBSCi9NZXRhZGF0YSA1IDAgUgo+PgplbmRvYmoKMyAw IG9iago8PAovMCBbNiAwIFIgL1hZWiAtNCA3OTEgbnVsbF0KLzEgWzYgMCBSIC9YWVogLTQgNzkx IG51bGxdCi8yIFs3IDAgUiAvWFlaIC00IDcwNiBudWxsXQovMyBbOCAwIFIgL1hZWiAtNCA3MDYg bnVsbF0KLzQgWzggMCBSIC9YWVogLTQgNjYyLjggbnVsbF0KLzUgWzkgMCBSIC9YWVogLTQgNzA2 IG51bGxdCi82IFsxMCAwIFIgL1hZWiAtNCA3MDYgbnVsbF0KLzcgWzEwIDAgUiAvWFlaIC00IDY2 Mi44IG51bGxdCi84IFsxMSAwIFIgL1hZWiAtNCA3MDYgbnVsbF0KLzkgWzExIDAgUiAvWFlaIC00 IDY2Mi44IG51bGxdCi8xMCBbMTIgMCBSIC9YWVogLTQgNzA2IG51bGxdCi8xMSBbMTMgMCBSIC9Y WVogLTQgNzA2IG51bGxdCi8xMiBbMTQgMCBSIC9YWVogLTQgNzA2IG51bGxdCi8xMyBbMTUgMCBS IC9YWVogLTQgNzA2IG51bGxdCi8xNCBbMTYgMCBSIC9YWVogLTQgNzA2IG51bGxdCi8xNSBbMTYg MCBSIC9YWVogLTQgNjYyLjggbnVsbF0KLzE2IFsxNiAwIFIgL1hZWiAtNCA1MTEuNiBudWxsXQov MTcgWzE3IDAgUiAvWFlaIC00IDcwNiBudWxsXQovMTggWzE3IDAgUiAvWFlaIC00IDI5NS41OTk5 NzYgbnVsbF0KLzE5IFsxOCAwIFIgL1hZWiAtNCA3MDYgbnVsbF0KLzIwIFsxOSAwIFIgL1hZWiAt NCA3MDYgbnVsbF0KLzIxIFsxOSAwIFIgL1hZWiAtNCA2NjIuOCBudWxsXQovMjIgWzIwIDAgUiAv WFlaIC00IDcwNiBudWxsXQovMjMgWzIwIDAgUiAvWFlaIC00IDY2Mi44IG51bGxdCi8yNCBbMjEg MCBSIC9YWVogLTQgNzA2IG51bGxdCi8yNSBbMjEgMCBSIC9YWVogLTQgNjYyLjggbnVsbF0KLzI2 IFsyMSAwIFIgL1hZWiAtNCA2NDEuMiBudWxsXQovMjcgWzIxIDAgUiAvWFlaIC00IDYxOS42IG51 bGxdCi8yOCBbMjEgMCBSIC9YWVogLTQgNTU0LjggbnVsbF0KLzI5IFsyMSAwIFIgL1hZWiAtNCA1 MjIuNCBudWxsXQovMzAgWzIxIDAgUiAvWFlaIC00IDQ3OS4yIG51bGxdCi8zMSBbMjEgMCBSIC9Y WVogLTQgNDI1LjE5OTk4MiBudWxsXQovMzIgWzIxIDAgUiAvWFlaIC00IDM4MiBudWxsXQovMzMg WzIxIDAgUiAvWFlaIC00IDM2MC40IG51bGxdCi8zNCBbMjEgMCBSIC9YWVogLTQgMzE3LjE5OTk4 MiBudWxsXQovMzUgWzIyIDAgUiAvWFlaIC00IDcwNiBudWxsXQovMzYgWzIyIDAgUiAvWFlaIC00 IDY2Mi44IG51bGxdCi8zNyBbMjIgMCBSIC9YWVogLTQgNDY4LjQwMDAyNCBudWxsXQovMzggWzIy IDAgUiAvWFlaIC00IDM0OS41OTk5NzYgbnVsbF0KLzM5IFsyMiAwIFIgL1hZWiAtNCAyMjAgbnVs bF0KLzQwIFsyMyAwIFIgL1hZWiAtNCA3MDYgbnVsbF0KLzQxIFsyMyAwIFIgL1hZWiAtNCAyMjAg bnVsbF0KLzQyIFsyNCAwIFIgL1hZWiAtNCA3MDYgbnVsbF0KLzQzIFsyNSAwIFIgL1hZWiAtNCA3 MDYgbnVsbF0KLzQ0IFsyNiAwIFIgL1hZWiAtNCA3MDYgbnVsbF0KLzQ1IFsyNiAwIFIgL1hZWiAt NCA2NjIuOCBudWxsXQovNDYgWzI3IDAgUiAvWFlaIC00IDcwNiBudWxsXQovNDcgWzI4IDAgUiAv WFlaIC00IDcwNiBudWxsXQovNDggWzI5IDAgUiAvWFlaIC00IDcwNiBudWxsXQovNDkgWzMwIDAg UiAvWFlaIC00IDcwNiBudWxsXQovNTAgWzMwIDAgUiAvWFlaIC00IDY2Mi44IG51bGxdCi81MSBb MzEgMCBSIC9YWVogLTQgNzA2IG51bGxdCj4+CmVuZG9iago0IDAgb2JqCjw8Ci9LaWRzIFs2IDAg UiA3IDAgUiA4IDAgUiA5IDAgUiAxMCAwIFIgMTEgMCBSIDEyIDAgUiAxMyAwIFIgMTQgMCBSIDE1 IDAgUiAxNiAwIFIgMTcgMCBSIDE4IDAgUiAxOSAwIFIgMjAgMCBSIDIxIDAgUgoyMiAwIFIgMjMg MCBSIDI0IDAgUiAyNSAwIFIgMjYgMCBSIDI3IDAgUiAyOCAwIFIgMjkgMCBSIDMwIDAgUiAzMSAw IFJdCi9UeXBlIC9QYWdlcwovQ291bnQgMjYKPj4KZW5kb2JqCjUgMCBvYmoKPDwKL1R5cGUgL01l dGFkYXRhCi9MZW5ndGggMzU1NQovU3VidHlwZSAvWE1MCj4+CnN0cmVhbQo8P3hwYWNrZXQgYmVn aW49Iu+7vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5z Ong9ImFkb2JlOm5zOm1ldGEvIiB4OnhtcHRrPSJYTVAgQ29yZSA0LjEuMSI+Cgk8cmRmOlJERiB4 bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPgoJ CTxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCgkJCQl4bWxuczpwZGY9Imh0dHA6Ly9ucy5h ZG9iZS5jb20vcGRmLzEuMy8iPgoJCQk8cGRmOlByb2R1Y2VyPkdQTCBHaG9zdHNjcmlwdCA5LjAy PC9wZGY6UHJvZHVjZXI+CgkJCTxwZGY6S2V5d29yZHM+KCk8L3BkZjpLZXl3b3Jkcz4KCQk8L3Jk ZjpEZXNjcmlwdGlvbj4KCQk8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgoJCQkJeG1sbnM6 eGFwPSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KCQkJPHhhcDpNb2RpZnlEYXRlPjIw MTMtMTEtMDJUMTk6NDA6NTUrMDE6MDA8L3hhcDpNb2RpZnlEYXRlPgoJCQk8eGFwOkNyZWF0ZURh dGU+MjAxMy0xMC0yMlQwODozOTowNyswMjowMDwveGFwOkNyZWF0ZURhdGU+CgkJCTx4YXA6Q3Jl YXRvclRvb2w+aHRtbDJwcyB2ZXJzaW9uIDEuMCBiZXRhNzwveGFwOkNyZWF0b3JUb29sPgoJCTwv cmRmOkRlc2NyaXB0aW9uPgoJCTxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCgkJCQl4bWxu czp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyI+CgkJCTx4YXBNTTpEb2N1 bWVudElEPjMzMGVhODZmLTczMDEtMTFlZS0wMDAwLTUzZmYxYWZlMGJlYzwveGFwTU06RG9jdW1l bnRJRD4KCQkJPHhhcE1NOkluc3RhbmNlSUQ+MzMwZWE4NmYtNzMwMS0xMWVlLTAwMDAtNTNmZjFh ZmUwYmVjPC94YXBNTTpJbnN0YW5jZUlEPgoJCTwvcmRmOkRlc2NyaXB0aW9uPgoJCTxyZGY6RGVz Y3JpcHRpb24gcmRmOmFib3V0PSIiCgkJCQl4bWxuczpkYz0iaHR0cDovL3B1cmwub3JnL2RjL2Vs ZW1lbnRzLzEuMS8iPgoJCQk8ZGM6Zm9ybWF0PmFwcGxpY2F0aW9uL3BkZjwvZGM6Zm9ybWF0PgoJ CQk8ZGM6dGl0bGU+CgkJCQk8cmRmOkFsdD4KCQkJCQk8cmRmOmxpIHhtbDpsYW5nPSJ4LWRlZmF1 bHQiPmRyYWZ0LWxpZWJzY2gtZG1tLWZyYW1ld29yay1hbmFseXNpcy0wMiAtIERpc3RyaWJ1dGVk IE1vYmlsaXR5IE1hbmFnZW1lbnQgLSBGcmFtZXdvcmsgJmFtcDsgQW5hbHlzaXM8L3JkZjpsaT4K CQkJCTwvcmRmOkFsdD4KCQkJPC9kYzp0aXRsZT4KCQkJPGRjOmNyZWF0b3I+CgkJCQk8cmRmOlNl cT4KCQkJCQk8cmRmOmxpPigpPC9yZGY6bGk+CgkJCQk8L3JkZjpTZXE+CgkJCTwvZGM6Y3JlYXRv cj4KCQkJPGRjOmRlc2NyaXB0aW9uPgoJCQkJPHJkZjpBbHQ+CgkJCQkJPHJkZjpsaSB4bWw6bGFu Zz0ieC1yZXBhaXIiPigpPC9yZGY6bGk+CgkJCQk8L3JkZjpBbHQ+CgkJCTwvZGM6ZGVzY3JpcHRp b24+CgkJPC9yZGY6RGVzY3JpcHRpb24+Cgk8L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/eHBhY2tldCBl bmQ9InciPz4KZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Bbm5vdHMg WzMyIDAgUiAzMyAwIFIgMzQgMCBSXQovUGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29udGVudHMg MzUgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9SZXNvdXJjZXMgPDwKL0ZvbnQgMzYgMCBS Ci9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDM3IDAgUgo+Pgo+PgplbmRvYmoKNyAw IG9iago8PAovVHlwZSAvUGFnZQovQW5ub3RzIFszOCAwIFIgMzkgMCBSIDQwIDAgUiA0MSAwIFIg NDIgMCBSIDQzIDAgUiA0NCAwIFIgNDUgMCBSIDQ2IDAgUiA0NyAwIFIgNDggMCBSIDQ5IDAgUiA1 MCAwIFIgNTEgMCBSIDUyIDAgUiA1MyAwIFIKNTQgMCBSIDU1IDAgUiA1NiAwIFIgNTcgMCBSIDU4 IDAgUiA1OSAwIFIgNjAgMCBSIDYxIDAgUiA2MiAwIFIgNjMgMCBSIDY0IDAgUiA2NSAwIFIgNjYg MCBSIDY3IDAgUiA2OCAwIFIgNjkgMCBSCjcwIDAgUiA3MSAwIFIgNzIgMCBSIDczIDAgUiA3NCAw IFIgNzUgMCBSIDc2IDAgUiA3NyAwIFJdCi9QYXJlbnQgNCAwIFIKL1JvdGF0ZSAwCi9Db250ZW50 cyA3OCAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcyA8PAovRm9udCA3OSAw IFIKL1Byb2NTZXQgWy9QREYgL1RleHRdCi9FeHRHU3RhdGUgODAgMCBSCj4+Cj4+CmVuZG9iago4 IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Bbm5vdHMgWzgxIDAgUiA4MiAwIFIgODMgMCBSIDg0IDAg UiA4NSAwIFIgODYgMCBSXQovUGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29udGVudHMgODcgMCBS Ci9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9SZXNvdXJjZXMgPDwKL0ZvbnQgODggMCBSCi9Qcm9j U2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDg5IDAgUgo+Pgo+PgplbmRvYmoKOSAwIG9iago8 PAovVHlwZSAvUGFnZQovQW5ub3RzIFs5MCAwIFIgOTEgMCBSXQovUGFyZW50IDQgMCBSCi9Sb3Rh dGUgMAovQ29udGVudHMgOTIgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9SZXNvdXJjZXMg PDwKL0ZvbnQgOTMgMCBSCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDk0IDAgUgo+ Pgo+PgplbmRvYmoKMTAgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL0Fubm90cyBbOTUgMCBSIDk2IDAg UiA5NyAwIFJdCi9QYXJlbnQgNCAwIFIKL1JvdGF0ZSAwCi9Db250ZW50cyA5OCAwIFIKL01lZGlh Qm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcyA8PAovRm9udCA5OSAwIFIKL1Byb2NTZXQgWy9Q REYgL1RleHRdCi9FeHRHU3RhdGUgMTAwIDAgUgo+Pgo+PgplbmRvYmoKMTEgMCBvYmoKPDwKL1R5 cGUgL1BhZ2UKL0Fubm90cyBbMTAxIDAgUiAxMDIgMCBSIDEwMyAwIFJdCi9QYXJlbnQgNCAwIFIK L1JvdGF0ZSAwCi9Db250ZW50cyAxMDQgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9SZXNv dXJjZXMgPDwKL0ZvbnQgMTA1IDAgUgovUHJvY1NldCBbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAx MDYgMCBSCj4+Cj4+CmVuZG9iagoxMiAwIG9iago8PAovVHlwZSAvUGFnZQovQW5ub3RzIFsxMDcg MCBSIDEwOCAwIFIgMTA5IDAgUl0KL1BhcmVudCA0IDAgUgovUm90YXRlIDAKL0NvbnRlbnRzIDEx MCAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcyA8PAovRm9udCAxMTEgMCBS Ci9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDExMiAwIFIKPj4KPj4KZW5kb2JqCjEz IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Bbm5vdHMgWzExMyAwIFJdCi9QYXJlbnQgNCAwIFIKL1Jv dGF0ZSAwCi9Db250ZW50cyAxMTQgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9SZXNvdXJj ZXMgPDwKL0ZvbnQgMTE1IDAgUgovUHJvY1NldCBbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMTYg MCBSCj4+Cj4+CmVuZG9iagoxNCAwIG9iago8PAovVHlwZSAvUGFnZQovQW5ub3RzIFsxMTcgMCBS XQovUGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29udGVudHMgMTE4IDAgUgovTWVkaWFCb3ggWzAg MCA1OTUgODQyXQovUmVzb3VyY2VzIDw8Ci9Gb250IDExOSAwIFIKL1Byb2NTZXQgWy9QREYgL1Rl eHRdCi9FeHRHU3RhdGUgMTIwIDAgUgo+Pgo+PgplbmRvYmoKMTUgMCBvYmoKPDwKL1R5cGUgL1Bh Z2UKL0Fubm90cyBbMTIxIDAgUl0KL1BhcmVudCA0IDAgUgovUm90YXRlIDAKL0NvbnRlbnRzIDEy MiAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcyA8PAovRm9udCAxMjMgMCBS Ci9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEyNCAwIFIKPj4KPj4KZW5kb2JqCjE2 IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Bbm5vdHMgWzEyNSAwIFIgMTI2IDAgUiAxMjcgMCBSIDEy OCAwIFIgMTI5IDAgUl0KL1BhcmVudCA0IDAgUgovUm90YXRlIDAKL0NvbnRlbnRzIDEzMCAwIFIK L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcyA8PAovRm9udCAxMzEgMCBSCi9Qcm9j U2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDEzMiAwIFIKPj4KPj4KZW5kb2JqCjE3IDAgb2Jq Cjw8Ci9UeXBlIC9QYWdlCi9Bbm5vdHMgWzEzMyAwIFIgMTM0IDAgUiAxMzUgMCBSIDEzNiAwIFJd Ci9QYXJlbnQgNCAwIFIKL1JvdGF0ZSAwCi9Db250ZW50cyAxMzcgMCBSCi9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9SZXNvdXJjZXMgPDwKL0ZvbnQgMTM4IDAgUgovUHJvY1NldCBbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSAxMzkgMCBSCj4+Cj4+CmVuZG9iagoxOCAwIG9iago8PAovVHlwZSAvUGFn ZQovQW5ub3RzIFsxNDAgMCBSXQovUGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29udGVudHMgMTQx IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUmVzb3VyY2VzIDw8Ci9Gb250IDE0MiAwIFIK L1Byb2NTZXQgWy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTQzIDAgUgo+Pgo+PgplbmRvYmoKMTkg MCBvYmoKPDwKL1R5cGUgL1BhZ2UKL0Fubm90cyBbMTQ0IDAgUiAxNDUgMCBSXQovUGFyZW50IDQg MCBSCi9Sb3RhdGUgMAovQ29udGVudHMgMTQ2IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQov UmVzb3VyY2VzIDw8Ci9Gb250IDE0NyAwIFIKL1Byb2NTZXQgWy9QREYgL1RleHRdCi9FeHRHU3Rh dGUgMTQ4IDAgUgo+Pgo+PgplbmRvYmoKMjAgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL0Fubm90cyBb MTQ5IDAgUiAxNTAgMCBSXQovUGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29udGVudHMgMTUxIDAg UgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUmVzb3VyY2VzIDw8Ci9Gb250IDE1MiAwIFIKL1By b2NTZXQgWy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTUzIDAgUgo+Pgo+PgplbmRvYmoKMjEgMCBv YmoKPDwKL1R5cGUgL1BhZ2UKL0Fubm90cyBbMTU0IDAgUiAxNTUgMCBSIDE1NiAwIFIgMTU3IDAg UiAxNTggMCBSIDE1OSAwIFIgMTYwIDAgUiAxNjEgMCBSIDE2MiAwIFIgMTYzIDAgUl0KL1BhcmVu dCA0IDAgUgovUm90YXRlIDAKL0NvbnRlbnRzIDE2NCAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0 Ml0KL1Jlc291cmNlcyA8PAovRm9udCAxNjUgMCBSCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRXh0 R1N0YXRlIDE2NiAwIFIKPj4KPj4KZW5kb2JqCjIyIDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Bbm5v dHMgWzE2NyAwIFIgMTY4IDAgUiAxNjkgMCBSIDE3MCAwIFIgMTcxIDAgUiAxNzIgMCBSIDE3MyAw IFIgMTc0IDAgUl0KL1BhcmVudCA0IDAgUgovUm90YXRlIDAKL0NvbnRlbnRzIDE3NSAwIFIKL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcyA8PAovRm9udCAxNzYgMCBSCi9Qcm9jU2V0 IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE3NyAwIFIKPj4KPj4KZW5kb2JqCjIzIDAgb2JqCjw8 Ci9UeXBlIC9QYWdlCi9Bbm5vdHMgWzE3OCAwIFIgMTc5IDAgUl0KL1BhcmVudCA0IDAgUgovUm90 YXRlIDAKL0NvbnRlbnRzIDE4MCAwIFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNl cyA8PAovRm9udCAxODEgMCBSCi9Qcm9jU2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDE4MiAw IFIKPj4KPj4KZW5kb2JqCjI0IDAgb2JqCjw8Ci9UeXBlIC9QYWdlCi9Bbm5vdHMgWzE4MyAwIFJd Ci9QYXJlbnQgNCAwIFIKL1JvdGF0ZSAwCi9Db250ZW50cyAxODQgMCBSCi9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9SZXNvdXJjZXMgPDwKL0ZvbnQgMTg1IDAgUgovUHJvY1NldCBbL1BERiAvVGV4 dF0KL0V4dEdTdGF0ZSAxODYgMCBSCj4+Cj4+CmVuZG9iagoyNSAwIG9iago8PAovVHlwZSAvUGFn ZQovQW5ub3RzIFsxODcgMCBSXQovUGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29udGVudHMgMTg4 IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUmVzb3VyY2VzIDw8Ci9Gb250IDE4OSAwIFIK L1Byb2NTZXQgWy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMTkwIDAgUgo+Pgo+PgplbmRvYmoKMjYg MCBvYmoKPDwKL1R5cGUgL1BhZ2UKL0Fubm90cyBbMTkxIDAgUiAxOTIgMCBSIDE5MyAwIFIgMTk0 IDAgUiAxOTUgMCBSIDE5NiAwIFIgMTk3IDAgUiAxOTggMCBSIDE5OSAwIFJdCi9QYXJlbnQgNCAw IFIKL1JvdGF0ZSAwCi9Db250ZW50cyAyMDAgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9S ZXNvdXJjZXMgPDwKL0ZvbnQgMjAxIDAgUgovUHJvY1NldCBbL1BERiAvVGV4dF0KL0V4dEdTdGF0 ZSAyMDIgMCBSCj4+Cj4+CmVuZG9iagoyNyAwIG9iago8PAovVHlwZSAvUGFnZQovQW5ub3RzIFsy MDMgMCBSIDIwNCAwIFJdCi9QYXJlbnQgNCAwIFIKL1JvdGF0ZSAwCi9Db250ZW50cyAyMDUgMCBS Ci9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9SZXNvdXJjZXMgPDwKL0ZvbnQgMjA2IDAgUgovUHJv Y1NldCBbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAyMDcgMCBSCj4+Cj4+CmVuZG9iagoyOCAwIG9i ago8PAovVHlwZSAvUGFnZQovQW5ub3RzIFsyMDggMCBSIDIwOSAwIFJdCi9QYXJlbnQgNCAwIFIK L1JvdGF0ZSAwCi9Db250ZW50cyAyMTAgMCBSCi9NZWRpYUJveCBbMCAwIDU5NSA4NDJdCi9SZXNv dXJjZXMgPDwKL0ZvbnQgMjExIDAgUgovUHJvY1NldCBbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAy MTIgMCBSCj4+Cj4+CmVuZG9iagoyOSAwIG9iago8PAovVHlwZSAvUGFnZQovQW5ub3RzIFsyMTMg MCBSIDIxNCAwIFIgMjE1IDAgUiAyMTYgMCBSXQovUGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29u dGVudHMgMjE3IDAgUgovTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUmVzb3VyY2VzIDw8Ci9Gb250 IDIxOCAwIFIKL1Byb2NTZXQgWy9QREYgL1RleHRdCi9FeHRHU3RhdGUgMjE5IDAgUgo+Pgo+Pgpl bmRvYmoKMzAgMCBvYmoKPDwKL1R5cGUgL1BhZ2UKL0Fubm90cyBbMjIwIDAgUiAyMjEgMCBSXQov UGFyZW50IDQgMCBSCi9Sb3RhdGUgMAovQ29udGVudHMgMjIyIDAgUgovTWVkaWFCb3ggWzAgMCA1 OTUgODQyXQovUmVzb3VyY2VzIDw8Ci9Gb250IDIyMyAwIFIKL1Byb2NTZXQgWy9QREYgL1RleHRd Ci9FeHRHU3RhdGUgMjI0IDAgUgo+Pgo+PgplbmRvYmoKMzEgMCBvYmoKPDwKL1R5cGUgL1BhZ2UK L0Fubm90cyBbMjI1IDAgUl0KL1BhcmVudCA0IDAgUgovUm90YXRlIDAKL0NvbnRlbnRzIDIyNiAw IFIKL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1Jlc291cmNlcyA8PAovRm9udCAyMjcgMCBSCi9Q cm9jU2V0IFsvUERGIC9UZXh0XQovRXh0R1N0YXRlIDIyOCAwIFIKPj4KPj4KZW5kb2JqCjMyIDAg b2JqCjw8Ci9BIDw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9iY3A3 OCkKPj4KL1JlY3QgWzE2MS44IDM1OC4xNSAxOTYuMiAzNjguMDVdCi9UeXBlIC9Bbm5vdAovQm9y ZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjMzIDAgb2JqCjw8Ci9BIDw8Ci9T IC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9iY3A3OSkKPj4KL1JlY3QgWzIy MS4yIDM1OC4xNSAyNTUuNiAzNjguMDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1 YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjM0IDAgb2JqCjw8Ci9BIDw8Ci9TIC9VUkkKL1VSSSAoaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50LykKPj4KL1JlY3QgWzE1Ni40 IDMwNC4xNSAzOTAuNiAzMTQuMDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5 cGUgL0xpbmsKPj4KZW5kb2JqCjM1IDAgb2JqCjw8Ci9GaWx0ZXIgWy9GbGF0ZURlY29kZV0KL0xl bmd0aCAxMTg4Cj4+CnN0cmVhbQp4nJ1WTXPbNhC961fs5NAmMxYtKf6Ic3P8NZ5GiRur00OnBwhc kqhJggZAy87N/uV9C5GSrXjqxtSMSFHYt2933y5wTaNkTCP5dHddDba/7VPuB2OSj8sHu/sj2h+P aOfgYER7O/hyPMgG0Yq+nXUPWHg9GC+fu5uu6NMMcAd0QLNssHQwBhbtHewmE5pVg7fH0yn9ad2V qXM6c7Zt6GeuaUKfDc+9Lt7N/oH35APNPg/enteBXc1heOxUFn4KcX19OTl69+sSq045JR9UaP1H ugyqTpVLPc2c0lcvwVwkdMkmsGCd3DbGMTAOG2dKmuxu0WQ03vkv869O1TkPT3HTTDMuWdtKsF4Z Fa6zhH5TTuVG1bXxr8X6ozY37LwJd2Qzmi24Xsb4WlZfdbBzdjSZxKS8B9b7SbIT67ladGx8cGbe BtRjauemFPdTVaucKxCgISFRFS8gKPqFDmtV3vkY4koaT52moo9huZTQMK2qYdbbD1VnPRxNknAb ADIZJ3sR5HAOGkqHLt7IhMk27FSwzpO2tTcpggkFU9pzNraWVFU9b1S0kNXBbhDkWs0FL8tKq1Lp DG8rJrjMMqMpc7YSZOPgyDFB6EI4IZoVfQleStQ9+u5ho/GMJ1PfsA8mVwGvOyiJwVQNwhX2KWvY O1Wa74BexVKtoYMlvoV7AW6cDVbbsoPytoxp8Fu0KCRlQUX/poaR0tq2sF9wWcJNZmo4cHzdomUE eGmETl9iKUQOqzlTxYHmSCdlbWjxtvcSE4KgUqvbyAyV0K337AnRdzCtFwJiW2sxUiWtJACA0/Xr kzqYYFjqRb5tGuuC4JDqWygSVx6cM3Ys7dpYRObBMSyYa8mk52chEUwHAgNn01YjdowZ5MFr1JHT ZXXXv58lTKos7aLn80R4AqbtsLRa9UJ8lgiWzVtTwvujJCmnC4wwHdMbChVQ76ALyQU4PfkXuOpG mTIquC+/Tzqgy1YXUq/Cpra0+R2x8j1K126CMIcISbfOSdUa6TSjsWxhQl99xzlGsJTiUR6EfO+S ctVEt6umvYzzW+CDqGLKle3Aoko29gy88e28MkE6yNRwg+KirzPrqjiKhYwQ3+hd+L8xXjQunj4d XdD+h0gsPh48YYTlT71GIdCi68petx1nXi1GuXJ0B7tlkz52P1P+ik6tA8H785PZ6QN088WGrmoW KI5y6XaPEqJnSm/XOuk1+CMBtZkf3+mxhK3Q64u1WtXPoWVYyCbcFyE0H7e3U4VKyNbJLjEcssS6 fDtOYr/d4Wz/nzxFk0ckbzCU0BfWQbuVujVVWwk1b24xp+pQbO4DUhVJAkZI24AUp1vQVVMqLU+A sXOMEhYBYLwsc/coJQEAd/2MNBUjI+dhOURVAxlgi1chzqjW848BPJoTHQh6CiWFjuEaVtrEsnHV uUYFazF7EzsdkoSPHKcJn7zZSNZzel4Y6Jfj+YPQ/k8PILE9j2xz50xeBBGMWbFav77XD3FnJhEW Dj+tDzGHIk1sfV40j10PoyQzMr581x477+WsB2rdUW2LIGFVJuttuDsXvXQs+usCewyN/wbmyWzw Ow6eOb7/BVLwNk4KZW5kc3RyZWFtCmVuZG9iagozNiAwIG9iago8PAovUjkgMjI5IDAgUgo+Pgpl bmRvYmoKMzcgMCBvYmoKPDwKL1I3IDIzMCAwIFIKPj4KZW5kb2JqCjM4IDAgb2JqCjw8Ci9EZXN0 IC8yCi9SZWN0IFs3MCA2OTIuOTUgNzcuNCA3MDIuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFsw IDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjM5IDAgb2JqCjw8Ci9BIDw8Ci9TIC9VUkkK L1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9iY3A3OCkKPj4KL1JlY3QgWzIzNy40IDYy OC4xNSAyNzEuOCA2MzguMDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUg L0xpbmsKPj4KZW5kb2JqCjQwIDAgb2JqCjw8Ci9BIDw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3Ry dXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKQo+PgovUmVjdCBbOTEuNiA2MDYuNTUgMjg4IDYx Ni40NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRv YmoKNDEgMCBvYmoKPDwKL0Rlc3QgLzE1Ci9SZWN0IFszNjcgNTYzLjM1IDQxNy42IDU3My4yNV0K L1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKNDIg MCBvYmoKPDwKL0Rlc3QgLzQKL1JlY3QgWzg2LjIgNDg3Ljc1IDkzLjYgNDk3LjY1XQovVHlwZSAv QW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iago0MyAwIG9iago8 PAovRGVzdCAvMwovUmVjdCBbNDUzLjQgNDg3Ljc1IDQ2MC44IDQ5Ny42NV0KL1R5cGUgL0Fubm90 Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKNDQgMCBvYmoKPDwKL0Rl c3QgLzcKL1JlY3QgWzg2LjIgNDc2Ljk1IDkzLjYgNDg2Ljg1XQovVHlwZSAvQW5ub3QKL0JvcmRl ciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iago0NSAwIG9iago8PAovRGVzdCAvNgov UmVjdCBbNDUzLjQgNDc2Ljk1IDQ2MC44IDQ4Ni44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAg MCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKNDYgMCBvYmoKPDwKL0Rlc3QgLzkKL1JlY3Qg Wzg2LjIgNDY2LjE1IDkzLjYgNDc2LjA1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9T dWJ0eXBlIC9MaW5rCj4+CmVuZG9iago0NyAwIG9iago8PAovRGVzdCAvOAovUmVjdCBbNDUzLjQg NDY2LjE1IDQ2MC44IDQ3Ni4wNV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlw ZSAvTGluawo+PgplbmRvYmoKNDggMCBvYmoKPDwKL0Rlc3QgLzE1Ci9SZWN0IFs4Ni4yIDQ1NS4z NSA5My42IDQ2NS4yNV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGlu awo+PgplbmRvYmoKNDkgMCBvYmoKPDwKL0Rlc3QgLzE0Ci9SZWN0IFs0NDggNDU1LjM1IDQ2MC44 IDQ2NS4yNV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+Pgpl bmRvYmoKNTAgMCBvYmoKPDwKL0Rlc3QgLzE0Ci9SZWN0IFs0NDggNDMzLjc1IDQ2MC44IDQ0My42 NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoK NTEgMCBvYmoKPDwKL0Rlc3QgLzE4Ci9SZWN0IFs5NyA0MjIuOTUgMTE1LjIgNDMyLjg1XQovVHlw ZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iago1MiAwIG9i ago8PAovRGVzdCAvMTcKL1JlY3QgWzQ0OCA0MjIuOTUgNDYwLjggNDMyLjg1XQovVHlwZSAvQW5u b3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iago1MyAwIG9iago8PAov RGVzdCAvMjEKL1JlY3QgWzg2LjIgNDEyLjE1IDkzLjYgNDIyLjA1XQovVHlwZSAvQW5ub3QKL0Jv cmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iago1NCAwIG9iago8PAovRGVzdCAv MjAKL1JlY3QgWzQ0OCA0MTIuMTUgNDYwLjggNDIyLjA1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBb MCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iago1NSAwIG9iago8PAovRGVzdCAvMjMKL1Jl Y3QgWzg2LjIgNDAxLjM1IDkzLjYgNDExLjI1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFd Ci9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iago1NiAwIG9iago8PAovRGVzdCAvMjIKL1JlY3QgWzQ0 OCA0MDEuMzUgNDYwLjggNDExLjI1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0 eXBlIC9MaW5rCj4+CmVuZG9iago1NyAwIG9iago8PAovRGVzdCAvMjUKL1JlY3QgWzg2LjIgMzkw LjU1IDkzLjYgNDAwLjQ1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9M aW5rCj4+CmVuZG9iago1OCAwIG9iago8PAovRGVzdCAvMjQKL1JlY3QgWzQ0OCAzOTAuNTUgNDYw LjggNDAwLjQ1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+ CmVuZG9iago1OSAwIG9iago8PAovRGVzdCAvMjYKL1JlY3QgWzk3IDM3OS43NSAxMTUuMiAzODku NjVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2Jq CjYwIDAgb2JqCjw8Ci9EZXN0IC8yNAovUmVjdCBbNDQ4IDM3OS43NSA0NjAuOCAzODkuNjVdCi9U eXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjYxIDAg b2JqCjw8Ci9EZXN0IC8zMgovUmVjdCBbOTcgMzY4Ljk1IDExNS4yIDM3OC44NV0KL1R5cGUgL0Fu bm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKNjIgMCBvYmoKPDwK L0Rlc3QgLzI0Ci9SZWN0IFs0NDggMzY4Ljk1IDQ2MC44IDM3OC44NV0KL1R5cGUgL0Fubm90Ci9C b3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKNjMgMCBvYmoKPDwKL0Rlc3Qg LzM2Ci9SZWN0IFs4Ni4yIDM1OC4xNSAxNDIuMiAzNjguMDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVy IFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjY0IDAgb2JqCjw8Ci9EZXN0IC8zNQov UmVjdCBbNDQ4IDM0Ny4zNSA0NjAuOCAzNTcuMjVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAg MV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjY1IDAgb2JqCjw8Ci9EZXN0IC8zNwovUmVjdCBb OTcgMzM2LjU1IDExNS4yIDM0Ni40NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3Vi dHlwZSAvTGluawo+PgplbmRvYmoKNjYgMCBvYmoKPDwKL0Rlc3QgLzM1Ci9SZWN0IFs0NDggMzM2 LjU1IDQ2MC44IDM0Ni40NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAv TGluawo+PgplbmRvYmoKNjcgMCBvYmoKPDwKL0Rlc3QgLzM4Ci9SZWN0IFs5NyAzMjUuNzUgMTE1 LjIgMzM1LjY1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+ CmVuZG9iago2OCAwIG9iago8PAovRGVzdCAvMzUKL1JlY3QgWzQ0OCAzMjUuNzUgNDYwLjggMzM1 LjY1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9i ago2OSAwIG9iago8PAovRGVzdCAvMzkKL1JlY3QgWzk3IDMxNC45NSAxMTUuMiAzMjQuODVdCi9U eXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjcwIDAg b2JqCjw8Ci9EZXN0IC8zNQovUmVjdCBbNDQ4IDMxNC45NSA0NjAuOCAzMjQuODVdCi9UeXBlIC9B bm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjcxIDAgb2JqCjw8 Ci9EZXN0IC80MQovUmVjdCBbOTcgMzA0LjE1IDExNS4yIDMxNC4wNV0KL1R5cGUgL0Fubm90Ci9C b3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKNzIgMCBvYmoKPDwKL0Rlc3Qg LzQwCi9SZWN0IFs0NDggMzA0LjE1IDQ2MC44IDMxNC4wNV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIg WzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKNzMgMCBvYmoKPDwKL0Rlc3QgLzQ1Ci9S ZWN0IFs4Ni4yIDI5My4zNSAxNDIuMiAzMDMuMjVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAg MV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjc0IDAgb2JqCjw8Ci9EZXN0IC80NAovUmVjdCBb NDQ4IDI5My4zNSA0NjAuOCAzMDMuMjVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1 YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjc1IDAgb2JqCjw8Ci9EZXN0IC81MAovUmVjdCBbODYuMiAy ODIuNTUgMTQyLjIgMjkyLjQ1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBl IC9MaW5rCj4+CmVuZG9iago3NiAwIG9iago8PAovRGVzdCAvNDkKL1JlY3QgWzQ0OCAyODIuNTUg NDYwLjggMjkyLjQ1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5r Cj4+CmVuZG9iago3NyAwIG9iago8PAovRGVzdCAvNTEKL1JlY3QgWzQ0OCAyNzEuNzUgNDYwLjgg MjgxLjY1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVu ZG9iago3OCAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggOTcxCj4+CnN0 cmVhbQp4nJ2WUXOjNhDH3/kU25fmbiZHDHbs+N5wnFwz41zdmLdOH2RYQFchcZJw4sf2k3cF2MVu nZwDMxiD9qfdv/6S+A4DP4CBO7vfpPSuniaQGy8Ad+rcu54MYBIMYDSdDmA8ootGL/OaKHj60t1Q w+9e0N53P0kJs5hwU5hCnHltBwGxYDy99kOIS+8DfIy/UZh/A/HC+/AgLWqJ9tNcs8zC/pg/PsK9 ZiU+K/0n/AyRZGJruIHe8Wti1Ro1hINg+PHCG4b+qGHSq1QldYnSAqttobTxASIhQPO8sIaqMag3 mPoUFQb+eBcVF9TBPpTuTb3+hokFq2B2u4TJDTCZgi0QHu7ie4h1beyFgQXmTBBrXxWxllptuOFK GnhCwSyXucM0cfOuC0Mxru1fhbXV56sr63iIPkeb+UrnV4InKA1+4jJTfwOXgFnm8lGySSJlFkFl HaWq19SeeqK3KqMGvWKo/qVAZpBq33B8duH0Jz1KJGEas1qI7SUw49psIUWTaL5G2Kpa7wR0KpCI VvPENiU+c1u4JxVl17Go2OMUblWKdCkrJV2ngC9Ws8RiCplW5WFzKEmLDsVlImoKXfGyEjzjFDBb zWHRqgOWOC7fXaqpU2qFTWow8nsSOdGaQWuHrD9IriSqHir3KCWGK0nVFp6Z1kzaLfXQUQ76ccj/ z8vvezJma+ESofLJ8a3ifesFJA/NBa3Sus3bP/uE4ZEFw0ZyuaHu9iXGqEsulVD5Fn6Eed3VPKT7 +1o2uZFwkU4KbknimiTLlG7m66quKqXtKS6MO9aI7uecnKzdOFOGZHohWJskSdTr545StxzNMTMI OpajBW2dqRM9hTlWQm2dhT7Do1pzwWnsaKCtSpSAW3pOrt1Ht8dKibrt/mzVDzJpFVcVaqpmgwe5 zLmbL+va2f1Avh4r7FjXxCED19rl7gQiR2p2VobBqGONnbOir9E7OQ1r54IJsZ6wGbiEBuV8jxJr vNdr0ozcV6XLVq2zyQessJlB2Xtpe1ZUVShT/gIRAX9RzVJJ69NuK0qYpG2hNTqDnFU0rdqt6acj U3XOKpHWOUYLBBr/h0Wa7FnRSXtDbdym0nicNqTlZvw2K3ydRdPkZfsK8YA1PGn2jrZ4WC1P2+yA NXqLxWdfXmPdHA/e7I316rEWljZL2gn6K5djhcEx69YlVzCZI5nV/ncxOn2Gu4kTtZ8hFxClKW2T 5h2TJ3QGDSZht74vOK5NUlwCkg+F/6/j7l4qTl1Q+poLyuDSfR+Njn0Jvy8Z1RP+QdC72PuNvuly uv4DxYCtEAplbmRzdHJlYW0KZW5kb2JqCjc5IDAgb2JqCjw8Ci9SOSAyMjkgMCBSCj4+CmVuZG9i ago4MCAwIG9iago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKODEgMCBvYmoKPDwKL0Rlc3QgLzMK L1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcwMi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAx XQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKODIgMCBvYmoKPDwKL0Rlc3QgLzQKL1JlY3QgWzcw IDY0OS43NSA3Ny40IDY1OS42NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlw ZSAvTGluawo+PgplbmRvYmoKODMgMCBvYmoKPDwKL0Rlc3QgLzMzCi9SZWN0IFsyNTkgNDAxLjM1 IDMxNSA0MTEuMjVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsK Pj4KZW5kb2JqCjg0IDAgb2JqCjw8Ci9EZXN0IC8zNgovUmVjdCBbMzE4LjQgMTUyLjk1IDM3NC40 IDE2Mi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+Pgpl bmRvYmoKODUgMCBvYmoKPDwKL0MgWzEgMSAwXQovRiAyOAovTSAoRDoyMDEzMTEwMjE4MjEyNCsw MScwMCcpCi9QIDggMCBSCi9UIChjamJjKQovQVAgPDwKL04gMjMxIDAgUgo+PgovTk0gKDQ5OTg1 ZDA5LTE0ZDgtNDU5Yy1iYjU3NmIzMWZiYjhhNTk2KQovUkMgKDw/eG1sIHZlcnNpb249IjEuMCI/ Pjxib2R5IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxuczp4ZmE9Imh0 dHA6Ly93d3cueGZhLm9yZy9zY2hlbWEveGZhLWRhdGEvMS4wLyIgeGZhOkFQSVZlcnNpb249IkFj cm9iYXQ6Ny4wLjgiIHhmYTpzcGVjPSIyLjAuMiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7dGV4 dC1hbGlnbjpsZWZ0O2NvbG9yOiMwMDAwMDA7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZvbnQtc3R5bGU6 bm9ybWFsO2ZvbnQtZmFtaWx5OkFyaWFsO2ZvbnQtc3RyZXRjaDpub3JtYWwiPjxwPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpBcmlhbDtmb250LXNpemU6MTIuMHB0Ij5Eb3dubGluayBhbmQgYWxz byB1cGxpbmssIHJpZ2h0PyBcKHVubGVzcyBpbmdyZXNzIGZpbHRlcmluZyBpcyBub3QgY29uc2lk ZXJlZFwpPC9zcGFuPjwvcD48L2JvZHk+KQovTmFtZSAvQ29tbWVudAovUmVjdCBbMjcwLjExOTg3 NyAzNTMuMzA4MTk3IDI5MC4xMTk4NzcgMzcxLjMwODE5N10KL1N1YmogKFN0aWNreSBOb3RlKQov UG9wdXAgODYgMCBSCi9TdWJ0eXBlIC9UZXh0Ci9Db250ZW50cyAoRG93bmxpbmsgYW5kIGFsc28g dXBsaW5rLCByaWdodD8gXCh1bmxlc3MgaW5ncmVzcyBmaWx0ZXJpbmcgaXMgbm90IGNvbnNpZGVy ZWRcKSkKL0NyZWF0aW9uRGF0ZSAoRDoyMDEzMTEwMjE4MTIwNCswMScwMCcpCj4+CmVuZG9iago4 NiAwIG9iago8PAovRiAyNQovTSAoRDoyMDEzMTEwMjE4MTMwNSswMScwMCcpCi9QIDggMCBSCi9O TSAoNTFhNDY0YzMtODhlOS00MjAzLTg1YTE2MDdkNDc2MDEyNjgpCi9PcGVuIGZhbHNlCi9SZWN0 IFs1OTUgNDcxLjIxMDkyOSA3NDUgNTUxLjIxMDkyOV0KL1BhcmVudCA4NSAwIFIKL1N1YnR5cGUg L1BvcHVwCj4+CmVuZG9iago4NyAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5n dGggMTQwOAo+PgpzdHJlYW0KeJyNV01z2zYQvetX7KlOZmRVcmzHPqa1nWYmnqapeuhkcoBAUERN AgwAWlZv9i/vWxD8iKkktceWLQIPu2/fvoW+0HKxoiV/p1dZzX7++Jq2frYi/nbb2dnrJb1eLen0 8nJJ56f45dQsn8Vd9PFt+gMLv8xW7d/pRVb0yxpwl3RJ63zWHrACFp1fni1OaF3NXtDL9T/Ytrig 9fvZi3cmKGdUOL5yIg/Uf13d3tKNE5XaWXdHP9EbI8q9155GX7/LYDfK0cly9erl0ezVyeI0Yq4W RMB1Nmtk0Nbg2clqcR6fYdu6UCStkaoOZHO60j44vWmCyujWbnSpw55uhRFbVSkT6BGhPBFO3giP JdZQKBQg+xQAmXUYOI0xqw5HGFlY5ynYnXCZ560kpFTeE5Lm3PgZ0BildvZeZ6rdrcjYTHna6VBQ aaUoezBhMlJGbLDG1kFX+l/E5SxON9sEhRgCCM21JLGx9yrtpVLdqxIn4v893WkAYaVX7h5bqbba hDmpxXaRYLIRN6AsMB9SyEL5ReKxtNg9zVc4FYPGxgSFM8d5zSMVlcU6MX5w5KlAfggZqGIPlpgs HYDUATGFeGtrYnkQv8Cq3fMYEOCviFibht+Lq9pjEkw67N0HElnmuCCgZ/Rf7VSuHxLPcZ3nQFBf 2cPOExYIIukUYmwrjEJiU8WnprJQZnem1OaOaiHvVOCqJwamMcnGOU5tmtGVznMVn3lbRrW1agAf VuoR2+oBtfLxOQ5C8D1WNSgbYQYrbdmWa6NinNrLxrPQe1lWArLAz6RQI07Qu1MZwDWiBrCgY0ob WTYZHzQkEAoR2gi6BlMP0F1UZBfhYtLDaMjMyiYmkqFUBtwLyhsTWx7dkvfukSMU9hNmCtKTUDQv Ns+aWBsdNDZ6FVW1U2WZkLMxLg7EOgA83lw/zWlXaFlw+ClDp7402kX+yDd1bV0Yy2oQD0VGkwvE Nj/QdM8bCxr4TcRmhVEAKdd8EnTUBciRK3Rowrq5hjbaVPDax6bZdXOB1kLZw04pg5WgpCztDrx2 KksgiNkHQIi2XjgBi+ETCBlF3+yx4LgtNOIC14Mb4n+sqTo7uTlQHe73e1YfYvBNtMa8Kcs9NSwG poV5YqNqgkfSI4ND2u+u1zdz3ldwfvGd9V/Ha/oUX/7GZLj43P19sTz9PB+VZeQnAdzaZguQbswA f2iPraiTEU+VybENFpdsmTGhNHhU9FeUO77da55buVGdB0hb1SWQo0+NomLNdlbCDAwt4+EiCtqL g4xZcS0Hg+Z7oFq4oGVTCke64rShJBVbooYErKs4G0FvRT3MWGi67Ex2mCltUm0/sFp4ijhZ6KBk aFybhjWQTWTvR0xtGl1mB6jpu3XkBmMvE+SB2lsmFldNGTQI/MaR3wryoKVg7PjURTHdeCnR6S4R HQZhYagmj4hNE7P62kgm3QUwrzrWfmgLSL8zTFYdlJ/c2ddKah7qSTmxR75n7T1MdCmLkschtYEx 74b589WMWY/cZNyoCQltBhTsZQNu6fH9cSS2xqIGMvVktHbNdwb0cF2jqxH44+opYR2YAXhLYdl0 FIxn2Dck9XjyNIJsU96iUB3fubMVZpc5ngJNxaBGzdRdAuLVY+QQU8EdJUVH+GeyGFW+m0bJcGMv RPPsr3OTfjiohxKrQztrvipmXw+OJl7W/rQVN4hgp/EJq0gaGBLlOnUx8pNuyLRDPN5nuhHSHXHw wtET8z1tcu+Kkq//QMe1dD/ymf9RMj4neWzvIgNPA3+I2+8xv6p0+WWVdbcAnoT0pq6VyXDXe8Mq OGs/Q7zXauNlgSkHXZaL4UPH9UON/D12OV3SydmcP36c0vOvTx+QLr36DMTr9ewPfGTa4vd/mkWC gQplbmRzdHJlYW0KZW5kb2JqCjg4IDAgb2JqCjw8Ci9SOSAyMjkgMCBSCj4+CmVuZG9iago4OSAw IG9iago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKOTAgMCBvYmoKPDwKL0Rlc3QgLzUKL1JlY3Qg WzcwIDY5Mi45NSA3Ny40IDcwMi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3Vi dHlwZSAvTGluawo+PgplbmRvYmoKOTEgMCBvYmoKPDwKL0Rlc3QgLzQ1Ci9SZWN0IFs4Ni4yIDY0 OS43NSAxNDIuMiA2NTkuNjVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUg L0xpbmsKPj4KZW5kb2JqCjkyIDAgb2JqCjw8Ci9GaWx0ZXIgWy9GbGF0ZURlY29kZV0KL0xlbmd0 aCAzMjYKPj4Kc3RyZWFtCnicXZFNT8MwDIbv+RXvCTZplLZrGT1u2kBIm4CpN8QhS9M20KZdkmrj 3+Nu1fiwJduK48d2sofvBfB7Hbyo2e12hsKyAL2agsUzH7PAR5QkPu4iMkaynJ2qsH0cArq4Z8E5 HpyosUgJlyBBmrNzg4BYuEtiL0RasxHG6QeVefdI12z0pJ00WrqbpeG5w0WWmw0eDK/loTGfuMJc 8+rLKotf8ixcs5MGoR9Mx9dsGnrRiUmpedtKnakjFshkrrS04Bo8y5RTDaFgpUOTI++0GE6kdpSU doJDqURJwMuQBJSa7yqi1F3llODWwXZt2xgHpU/Dcp1BUA/R1G0la6LBlRL5ZYe8McQcDbt1+g/F o1QcJv0TUb+1kjsrygloSF55Pxuvjq0yNMW8NapCGE/63SP8l7cXXkhE7wRdpeyV/qsg+w3Q4IY3 CmVuZHN0cmVhbQplbmRvYmoKOTMgMCBvYmoKPDwKL1I5IDIyOSAwIFIKPj4KZW5kb2JqCjk0IDAg b2JqCjw8Ci9SNyAyMzAgMCBSCj4+CmVuZG9iago5NSAwIG9iago8PAovRGVzdCAvNgovUmVjdCBb NzAgNjkyLjk1IDc3LjQgNzAyLjg1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0 eXBlIC9MaW5rCj4+CmVuZG9iago5NiAwIG9iago8PAovRGVzdCAvNwovUmVjdCBbNzAgNjQ5Ljc1 IDc3LjQgNjU5LjY1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5r Cj4+CmVuZG9iago5NyAwIG9iago8PAovQSA8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5p ZXRmLm9yZy9wZGYvcmZjMjExOSkKPj4KL1JlY3QgWzM0NS40IDYwNi41NSAzODUuMiA2MTYuNDVd Ci9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjk4 IDAgb2JqCjw8Ci9GaWx0ZXIgWy9GbGF0ZURlY29kZV0KL0xlbmd0aCAzODIKPj4Kc3RyZWFtCnic XZFBb6MwEIXv/hVPOey2UpZiGpLlSBO6GwlCS53DquqBgEO8DSa1abv59zsElFYdS56H/OYzM36B 63C43RpyUbOrbIbKMo5umYr5Mxcz7mISBC6mE9qMZFt2qkL2axBkfGG810MqatwIwgUIILasv4AT C9PAdzyIml3gUvylMucnRMwulrqVRsv2x8Lk2xbnWCQJbk1ey/fGPOMbQp3vj1ZZfIq0aJuNNPBc fn35nV17zuTE9Bxg3ug3qVvVaItclxDS1Eo3+6Y6ktXjzvRkJYrYSTzLI+ii0mKUrB/EaNxnrNKT zqL79TKLFp1++B3G8Vn0DiKeGyIiHaXreHB36oMzT5MkWi16VBL+odT93Si9E8t0FcYjKI12pywh O1TZFK819YHcSLQNNpIMNLGDka0skVuU0hZGbeiDKh+z27nHefDkUL3vzoYuYyU3ttiNIQm0dz4m GP07KCMtwoNRe3j+uJvlBF/j8S6vJPwngkaC3dP7V7T/B5m/kVMKZW5kc3RyZWFtCmVuZG9iago5 OSAwIG9iago8PAovUjkgMjI5IDAgUgo+PgplbmRvYmoKMTAwIDAgb2JqCjw8Ci9SNyAyMzAgMCBS Cj4+CmVuZG9iagoxMDEgMCBvYmoKPDwKL0Rlc3QgLzgKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcw Mi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRv YmoKMTAyIDAgb2JqCjw8Ci9EZXN0IC85Ci9SZWN0IFs3MCA2NDkuNzUgNzcuNCA2NTkuNjVdCi9U eXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjEwMyAw IG9iago8PAovRGVzdCAvMjcKL1JlY3QgWzI3NS4yIDU5NS43NSA0MTIuMiA2MDUuNjVdCi9UeXBl IC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjEwNCAwIG9i ago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMTIzOQo+PgpzdHJlYW0KeJydVk1z GjkQvfMr+rROqgCDP+PciI1jqkzC2nBKpVJC0wPanRlhSWPM0f7l+6T5YIKJk1pcNpSZfv36db+W HqjX7VPP/5TvMm0d3p3Twrb65H/MonV63qPzfo9OLi56dHaCP4ZbcStE0d3n8gMefGj1i8/lm0zp 0xRwF3RB07hVJOgDi84uTrtHNE1b7+j99B+EdT/Q9Lb1bpQ5Nhm7zpURsaP6dTUe07URKa+1+Zf+ okEmko1Vlhqvr9LpORs66vWP3x+0jo+6JwHzuEt0nWfSKY0oGhi5VI6lyw1TrE3Avs9XK20cwo76 3bMQBsTpEk/UWVXmjI5yyRZhuSERRarEjLfwnDn8F888Xw9fgFeXBrz1UsklCeQ1nPCjyBxJna4S ThFF/KSsU9mCUj1XiXKbDoksImdEZktyHgTqeDqWnEYyMU84VGCLCkJFeaaksM6HxrGSBYymlLkC YWs9UfD1sYYfcmUCC0vC0goqfht1rrqKXdyJ0rTTfOJ7G8nkskTC44GFJ+44BQdhNjSaeHkM0qBC JMpy1ENoKZBFUSBTpiOmhXY1klWLjCM8kPG6VgHs5VKb0ETjlgC4HlpKxYbmgGCOONpKUUFFEFfi i5iF77MtKHuyVqV54kTGOreUWyYdIwMpz9whouBWae0Z3ugBQdSbL5MgosAc4Jd0ttC+6Eg4QRaV ov82SF3wL8JKIAS3y/ZjaEWSaCl8tvmGUFJTkAO7r/qqriDgEkn0I3tJBtsZ9Kr40cq0n6rMqogN MoCpWyKn4UflKZZIqNonjrzN2jTPEQMVoGg95RGxsCrZeIQ4D25BzqLKIrqEChih8EZaP4Y+wafL CUXKyjzoE55aiBXeC/929zlOQ561l7YqSebGYPLApZHBD17lmK3/dhxXuxGdm+cqibZyvzZYZa2P O6Q0Rm/44+5jc4sMPfAmDA9ZjFMkTOSn/k7nvkWHdL9WrjZJgTAe/LjcBzKuej0IvW7TpfZNSGiS YE53IWZ/BDGzYLEnfvYGBS6iLhMF2d5kMXuDxQ7KKyK+xQn6FlafUXAOJFxwxgabygT5Dm0Qr25r kB+dE+7A7jQ4rD1brIBtg1+1FFYZORgH5tK0EsYpmSeislWdp0hBdsVS+cUJUOzHwh9Yihjq1AaO fuiElNpEYe9pEiVUgrXAKG5lOFZP2BaoA8mveJXoTVjzNbjwn1xjNXnm2Ehbh44mh+PJ7X279vXz ht3LPncHD+4zU22Acv7CxJeDhJ0Amv4gKFJnqY7AzLu3FGRX7XJrbJdT4yyFbq9X9iirhmI0eTxr l6UBA4u3Vn2tc/QNu0fqTrUYMQDLkOtGp0yDRZglVDsx+mlTwjSRdzDt26C3+EfSRNlah55vx4OX grogyUniB8Vb+/lyNHkpz5mIIu1PgjLvzhz9JnsRCr0ASJ/x3Vpsftu7WaN3s1e9qzdh7u0mg/d2 eleTa4cxx5EFtMDN9yBf4Rwr9uTPHd528k9UD9t6T8ll0BcccNUQrHGU44Spm/q/gH/mNJDS3zh+ Iem9pliYdsMwFMGkWXWfg9M7tTlx9FQHdnkwsvKXD2CeHPurKzBvFc+tXLaJcfwl3e1NdPi0wmXJ 0gD7LaGj07a/k57Q7uvbRCyYzr4Dczht/Y179AJ//wMFNbefCmVuZHN0cmVhbQplbmRvYmoKMTA1 IDAgb2JqCjw8Ci9SOSAyMjkgMCBSCj4+CmVuZG9iagoxMDYgMCBvYmoKPDwKL1I3IDIzMCAwIFIK Pj4KZW5kb2JqCjEwNyAwIG9iago8PAovRGVzdCAvMTAKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcw Mi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRv YmoKMTA4IDAgb2JqCjw8Ci9DIFsxIDEgMF0KL0YgMjgKL00gKEQ6MjAxMzExMDIxOTExNDQrMDEn MDAnKQovUCAxMiAwIFIKL1QgKGNqYmMpCi9BUCA8PAovTiAyMzIgMCBSCj4+Ci9OTSAoOTgwOTQw YTEtNWY0ZS00ODYzLTlkMjczZWU2MmEyMDBhYzgpCi9SQyAoPD94bWwgdmVyc2lvbj0iMS4wIj8+ PGJvZHkgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbG5zOnhmYT0iaHR0 cDovL3d3dy54ZmEub3JnL3NjaGVtYS94ZmEtZGF0YS8xLjAvIiB4ZmE6QVBJVmVyc2lvbj0iQWNy b2JhdDo3LjAuOCIgeGZhOnNwZWM9IjIuMC4yIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDt0ZXh0 LWFsaWduOmxlZnQ7Y29sb3I6IzAwMDAwMDtmb250LXdlaWdodDpub3JtYWw7Zm9udC1zdHlsZTpu b3JtYWw7Zm9udC1mYW1pbHk6QXJpYWw7Zm9udC1zdHJldGNoOm5vcm1hbCI+PHA+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OkFyaWFsO2ZvbnQtc2l6ZToxMi4wcHQiPkRvZXNuJmFwb3M7dCB0aGlz IGFzc3VtZSBhbHJlYWR5IGFuIElQIG1vYmlsaXR5IGJhc2VkIHNvbHV0aW9uPyBBIHJvdXRpbmct YmFzZWQgc29sdXRpb24gd291bGQgbm90IGhhdmUgYSBiaW5kaW5nLWNhY2hlIFwodGhvdWdoIGNv bmNlcHR1YWxseSBpdCB3b3VsZCBoYXZlIHNvbWV0aGluZyBzaW1pbGFyXCk8L3NwYW4+PC9wPjwv Ym9keT4pCi9OYW1lIC9Db21tZW50Ci9SZWN0IFs0MDQuOTQ5NzMgNDUzLjYxMjAyMiA0MjQuOTQ5 NzMgNDcxLjYxMjAyMl0KL1N1YmogKFN0aWNreSBOb3RlKQovUG9wdXAgMTA5IDAgUgovU3VidHlw ZSAvVGV4dAovQ29udGVudHMgKERvZXNuJ3QgdGhpcyBhc3N1bWUgYWxyZWFkeSBhbiBJUCBtb2Jp bGl0eSBiYXNlZCBzb2x1dGlvbj8gQSByb3V0aW5nLWJhc2VkIHNvbHV0aW9uIHdvdWxkIG5vdCBo YXZlIGEgYmluZGluZy1jYWNoZSBcKHRob3VnaCBjb25jZXB0dWFsbHkgaXQgd291bGQgaGF2ZSBz b21ldGhpbmcgc2ltaWxhclwpKQovQ3JlYXRpb25EYXRlIChEOjIwMTMxMTAyMTkxMDM2KzAxJzAw JykKPj4KZW5kb2JqCjEwOSAwIG9iago8PAovRiAyNQovTSAoRDoyMDEzMTEwMjE5MTAzNiswMScw MCcpCi9QIDEyIDAgUgovTk0gKDI4OWVkM2Q0LWYyYTAtNDVjZS1hZThmZGIzNGFkOTRhY2RiKQov T3BlbiB0cnVlCi9SZWN0IFs1OTUgMzkxLjYxMjAyMiA3NDUgNDcxLjYxMjAyMl0KL1BhcmVudCAx MDggMCBSCi9TdWJ0eXBlIC9Qb3B1cAo+PgplbmRvYmoKMTEwIDAgb2JqCjw8Ci9GaWx0ZXIgWy9G bGF0ZURlY29kZV0KL0xlbmd0aCAxMzA0Cj4+CnN0cmVhbQp4nIVWYU8bRxD97l8xn5pEMgYTEkq+ 0cQ0SCGlkaVWqqpqfTe2t9ztXnb3MP4Iv7xvdvfOh+M0IGHgdt7MvPdm9r7SyWRKJ/KdP4t6dPzl nFZ+NCX5dqvRm/MTOp+e0NnFxQm9PcMPx6PlKEbRl1/zLzj4dTRNv+ePoqZf5oC7oAuaL0cpwRRY 9PbizeSU5vXoJb2a/4uwyc80/zR6eW0CO8Ph6INTy0D914ebG7pyquaNdXf0E10aVW299jT4+q0I dsGOTk+mr1+9GL0+nZxFTDwqtQ9OL9rAJVlHhT2qbKHkr40Oa+IHPNdmRVczT3ZJYc1U24WudNge IQBofYVAc7aNp5tKGZ4gsWFBra3jLnppq8puOkiFB0XrHJtQbQEmIMr7tkYBwZIq04fZFbLLrgwe OmV8Y10gUBMZCDbDsFGLiiM/vm3imSVqub4VVMfeo1kDyBZg7xBzOp287fqwhOr+uXk///MdXbWm CNqCVprhfNjSTS6B3gOAHwLNpYolu5w5RV8fCr02q5gaTUlhkadnUbNDUbMUBAYPB13P3h8Ki+2m hMcZQip2tsrRn23gd/hJqqqSwg4GRiNsCqbGahM8LUAss4nPa7XF3zhT8b0ykdA9Bygp8ShxX5K3 VSs1QXkVCKZcKC9GG+jZOBtsYSuf9FzzzgW20NGJyhVrHbgIrRNT/bHWxZqWud3kob4iEFvYuqm4 hqU6qAPpYrYhMJXcsCk9xWqZdAkAvdTIv1KNn+w5ZI4jQfm7ztbZLtIjSuCH6Le+qoU2pWQvVBEb HDKmDVislfQyhlPRmvK7OWMytuQXnj7aS5Hn4+fbMS2drQdHcpv5YOP4XtvW95OCVos1Qh+bm8sn Kls3HKP8MEOgYJn+qJjtJujgxBCWELsfwkCuq9ahVCc7YJw2QFZOXGc3nnQtZA2LyjBFHq+syHM+ DG/2syPZdcSCZqDrGFx1Y7KEMQfxWG5wPJwcHCeL+Z3gLnrDWHMk6yxT0FkpE/EIlpf64WkcI4PY aoGTWyotozYbMCoBUkrdw0p7R0q96KKnW6ceg21sZVfbQ7x1FiuUyTDIeo+ydzx0jEG8HIHVEDeo UE13zI3wjGe+cw3y6UKj6LYphYoxbeJ8pQhYc6Nc9C44bFRxx8F38DefX/hOqm6HUysDvi/MgeHp XSBFZqsl3+u8IzE7XElaGR7H6fRiSzVj2+4NEU6VsL2KNurHwwcoifJ395LCnTa8xjo75TZKuzGV Nnddpx0ZhXJue3goxWVZvQ6EZdUkWQezA2dVZU6u4z20ZlWyuHaetRpI6xjXMggYrofUmIoqY4nv KHxMQj/FofViWe3XGei5gt+2sKepamCqxsnijZcNRy06rGHC2ZOYdIeO2mWi5NLhByUrmFQRdzGK gScW4obdJIXWGMib06Y0fYJxz1q84Kt+JSn6/kwisZWJSQb5kedmoLhgfQ/T7auONqKNUm+p9PDN 3hZ2Oqs+M/OYeLKaxCCMb3QC0NRQidT8JDcwT1YF43nTdV4QPns95Y1oje5XaasM0h93bzyrfkkf tofsNVxQcURBZt54UZfBLGdeyp4OCSu5wv+cpK6H899N/nduAkmNW0c2c39PzqSG/RfNbsFdpl2X 023lqMpYch77oGHXXS17mLJ2/wc3mgNYZ6/lBRsiftK88MUaegWsu8nufXn20GDheLrEIFR0+mYs b85ntP/1161aMZ3/DczZfPQ73vZX+PkfRjzytgplbmRzdHJlYW0KZW5kb2JqCjExMSAwIG9iago8 PAovUjkgMjI5IDAgUgo+PgplbmRvYmoKMTEyIDAgb2JqCjw8Ci9SNyAyMzAgMCBSCj4+CmVuZG9i agoxMTMgMCBvYmoKPDwKL0Rlc3QgLzExCi9SZWN0IFs3MCA2OTIuOTUgNzcuNCA3MDIuODVdCi9U eXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjExNCAw IG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMTIwNQo+PgpzdHJlYW0KeJyN Vl1v2zYUffevuE9rCziqneajecwapzDQoFlhYA/DMNDUlcWFIhWSsuO9Nb9895KibKvFMBmwZYn3 85x7yGeYFXOY8af/lc3k/bdr2PjJHPjjNpPL6xlcz2dwcXMzg6sL+nI4qSbRCr597m9o4fNknu77 H9nArytydwM3sKomKcCcfMHVzWVxDqtm8hberf4ms+IjrL5M3i5NQGcwnN05UQUYrruHB7h3osGd dU/wC9waofdeeTi6vspg1+jgfDb/8O7N5MN5cRF90quAsjbquUM/Bd/JGoSH2vpw5mwX0IN1aYnV drMfVnxt0dxru4NG7GGN5HPIk3x2HksIFkrUakthQ43QCvmEwfNj/tvYtdIIxpb4xoPsnEMT0lMV 9uSP/Qgja+sKgGVFKwNIe6atFIG871Soo6P7xV8Pt9N8uwAq3Hdta/sUYm7sKxtKTa/+O4vosiC7 83lxlWta0fKqMzIoa3jFcvGJsG4dejLxICg5E5zVwyLOSQRAH8RaK19Tg8dtakvBLRamJFeN3dJ9 a7WSim6+t+jOGAhGYENgtFi+gjK50iWb9bUNxVNZQjMslXU74UplNmArSu600NLujFbmKYOS3Vi2 8f8Dn4zMT3p0arh8BFGW1CQuyGGlXl4ZISmcUwRGX463nZNjEmW7SqEuuQpe2bVHeRcckfGO5oOB 4gq6Q1EtU1dJasyeAkpLpcgANEPEzNNsa2opocCM+71GQ9n3TuIsOJ+zGNpQ2kZQDaWN9BRtSyEq pWktd15IChYxCPYIqdN0ee5OquLuGOItjZnvmszimAIRCYfRKCkm+BalqpQES3QRkZtUvsPnTjks x/jQGI16dUiWzHhsp2SscSsI7Fy0waNROkaI+mhNpTadSwvwRequxJ/w54gGlbPNIWzub6fRpzmP CnOSFlVGdOZOrPeZygcO8niI3s2jsy97eEihl4/bq3x/KyXH/kzjtiPB+v5w+/l1GiVBjzUnjy+B HcnpcWiEr21HVOzziWUG4Z+49KNW8PMjzdF9MalGHswMdyAdJ+jGIEXm9e+Ir6ViujKwQnsbOcby 0AtYcjUFLDZFhMD0HDnGaa0GJ5RO6IwhXY6spPU+pUxKNagCc6vPkQQqNzezU2hqoecMaVJ8QtvT 9kO5bhjh97hJQOdGTpM2HeQqqtehz9JGY8qm1QROavthJkJNxLjLuY2UL3peY3RBUVuucos0hTlk MjjxWSShSn9OUkqi6X/Qy9HeFX1HHfGtNT8OeHmSbOxtTXsmbxSDq2H/OomUhzsrWUq7pD1EmTTd J6rYVxLDsGhEhjgMpK1bPEpIGSZschDnL+8hi09j9t0nDs9Bad15Apk3qJp2FDapSDz4vHE2yM79 IuLXamyouhHv8EVx4pu4aiydwsla0ckiULhUB3Fp7PtI7EgNrVRxCz9oXY+r4qNRJWjGiQthhxgf N72QZo1BodU/SUWGzFpng5VWE0nxJdA0REYmnBuWFoO7w6IisyU3yWMrUosiTjQszGGDhy7nU0F8 zPbzi1l/+PqicO1lTZFp69DF4bS2eGlpXj3ctk5pOL+c8rntAsbXH49ig/DxT3K6WE1+o7Pmhr7/ BcMHc94KZW5kc3RyZWFtCmVuZG9iagoxMTUgMCBvYmoKPDwKL1I5IDIyOSAwIFIKPj4KZW5kb2Jq CjExNiAwIG9iago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKMTE3IDAgb2JqCjw8Ci9EZXN0IC8x MgovUmVjdCBbNzAgNjkyLjk1IDc3LjQgNzAyLjg1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAw IDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxMTggMCBvYmoKPDwKL0ZpbHRlciBbL0ZsYXRl RGVjb2RlXQovTGVuZ3RoIDg2MAo+PgpzdHJlYW0KeJy1Vt9vGjkQft+/Yp6urUj2gJCkoHuhZLki NSmlRIpUXZBZZsHXXZvYhqTSvjR/ecf7k+z2AjkpBrFmPd8342/GGt9B021B036ypx85f07OYamd FtiPWjqn5004bzWh0+024axDPwqdwElQMPk7m5DhndNK59nDj+DDlOi60IVp4KQOWsQFZ91Ttw3T yHkL76b/Esx9D9NPztuRMKgEmuMLxQIDxbi4vIShYhHeS/Ud/oC+YOEPzTXsjM++kXNU0G62Tt69 cU7abifhhMoYSGGUDGEcMoG9/G0xuWCGZWvEUkRWZfn9sJBDTYtZvLAu18z/jub/4LcQSAWRnPMQ QcgF1kkaxzQa6XwyGw0qJOlyHRYPvdko/uu4GI0nsHT5eW+p4UHeKhSNCszy/DeIdjWKraeXgOzY 2u/2ZaDGrhqHghK1vEH8+p4AbpNvBbTdk6m4SNQhdeHldUHweDK7GcCTuvCeqYvJzBtkDg/xVh3b 2s72ydEoy/dwkN3F5WB6E7+6J7i9zTP2TLZ2qFPWOM9Y7+l6FZhspD8bFAmL0+OVA7P161qYOx4p wX3rjJ43+z3WRp7pl4jyO9BeUaqg50W5LkUpGXq76/tEud5ZeakoJbDWroZ8uVEIrR58YJr7oNGA DCDYCN9wSc0PUBhuOGr4OfQegYkFcNs7A+bTOyP3tS4UbE7dYjQ+ZouFQq3Bp7bIxYabH8RkGy5R tFvuWU4xXSH1/QAVCh9hLcmdhjmae0QBQ88SRGvFNYIhy0CGobznYgkBMkN70XlrlGkx9cBLQtCJ eXbUKHDyYRTHLaYNzYZjI8MHQ2FRn4uYFaC+vUDJqKDqW7Hsn8urN7okYsJfSeUCfN34qwpdRsOF H24WFJVtqfjAonWIJdNHGSH0M8F+fpT9RyCz5O0VKUF3k5JpTGLxB7K6Gj+Sy5FIaERq9iQ+gffV GI/saslV0T3LXk26tZJbvsD6zkumXEuytlZMa+lzZnCR6mb9MlI6Wktl9IFERS1BvZbcShWl2b9+ texnt6CNpougH3I6JQmBve/lh+eo8EnH37WJWUltL16dE3snJc5PHOfaXx0BnToWuuWp8R7WnDYI fSr0ENqnR/ay2akdrm9jtkTo/kOc3tT5QhfkJf3+ArVAe6kKZW5kc3RyZWFtCmVuZG9iagoxMTkg MCBvYmoKPDwKL1I5IDIyOSAwIFIKPj4KZW5kb2JqCjEyMCAwIG9iago8PAovUjcgMjMwIDAgUgo+ PgplbmRvYmoKMTIxIDAgb2JqCjw8Ci9EZXN0IC8xMwovUmVjdCBbNzAgNjkyLjk1IDc3LjQgNzAy Ljg1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9i agoxMjIgMCBvYmoKPDwKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoIDkwNAo+PgpzdHJl YW0KeJydVV2P2zYQfNev2KcmARzV9n3VeUsvTnFAnDZXPxxQFAFFrS32aFLHj/O5v75DSmf5fC4K VAIsGdwd7c7skA80Lic0Tnf/lJvix9srWvtiQul26+LiakxXkzGdz2ZjujzHj+NiVeQsuv2lf0Hg QzHp3vuH3NDPS8DNaEbLVdF9YAIsupxdlFNaboq39G75F9LKn2j5pXh7YwI7w+H9JydWgfbXp8WC Pjux4a119/QDfTRC77zydHD9KoOt2NF0PDl796Y4m5bnGbNb3dhKaRV2tBFGrHnDJowoNIBYRSOD sobwrq0UgWvCv9AwLVIS01db8wiQ+zI7yG1jSdqoa/Kxba0LuUzbshMZr9qRsUGtdsqsM9zn+ffF 9fIO787GdQPEHinX4XjFjo1kaq0yocTydFJePn/QEt1+v7v7QHMjKs0+I9bKsQwUnDAe2WRXJAwt vr7xQ8PSgtSn8Lr+isOWGZ1u7Z4E/1zkCO0p2ZBwTGHXKim03u35UZmfoQFIlpXB9zNvqYDW8aOy 0aOiGgHboSJhZGMdGvYtqlePrHcnu725ftktSruZX1OwwLaPqk5MaSVVWrb7iL7y1/2mVqJH9Qhe WbcVrh6qre3WaGXuqRXynkNCTAF+iEALQ8PHvaQeU6Tw3kqVOUIt85KWDfuDOiXkqQ6I6xupDxtI 7CIsGp+zEhaG1iR5XZpMxw+RfUjz9UKElHuSx/n/4XH+3zyKsA9OiQAyadxRoGSoWg9cNgitWNtk BEvioH/hgpJRCweSM4s1a+S6hJyI26vxQog9/wNSJ0RJ9HvE2A6EZ4MqI3WEiZPuxE9i02r8CRGs amJTZ8cNWMogbpNdjBRtt8+9wQbZ2i4mLpMcqModr6KNg7rqGoPu0x6Qs077+kAhZVRQQqu/92AU 2xoj9eyuXj5R2Rj6CThS6OQGgNmkLWudnl2uArEyOmw6oXN2/p4fancME3ssQ8tu2jqxO/ufdH2P 969OOW30mw+0iDooyAJwHxCb+M27Wd9u5xyMR6vtrjNMFRW0Fa/7T/uwcLKBd2SIDlJzuS5TSq18 cKqKYFNbUWd2PfY2Trshzp4RRB1qP4gOwt/7Q3tvVWiO3MRZQfDdnwGPB+aEl2PeYDMBZ1c9A18U V142KBD66HI4zeZPLfZ2Tx9bpzRNL0bpXDuno+uP33CW4bj9E6DzZfENZ/Eav/8ATHpg1QplbmRz dHJlYW0KZW5kb2JqCjEyMyAwIG9iago8PAovUjkgMjI5IDAgUgo+PgplbmRvYmoKMTI0IDAgb2Jq Cjw8Ci9SNyAyMzAgMCBSCj4+CmVuZG9iagoxMjUgMCBvYmoKPDwKL0Rlc3QgLzE0Ci9SZWN0IFs3 MCA2OTIuOTUgNzcuNCA3MDIuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5 cGUgL0xpbmsKPj4KZW5kb2JqCjEyNiAwIG9iago8PAovRGVzdCAvMTUKL1JlY3QgWzcwIDY0OS43 NSA3Ny40IDY1OS42NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGlu awo+PgplbmRvYmoKMTI3IDAgb2JqCjw8Ci9EZXN0IC8xNgovUmVjdCBbNzAgNDk4LjU1IDg4LjIg NTA4LjQ1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVu ZG9iagoxMjggMCBvYmoKPDwKL0MgWzEgMSAwXQovRiAyOAovTSAoRDoyMDEzMTEwMjE5MTkzOCsw MScwMCcpCi9QIDE2IDAgUgovVCAoY2piYykKL0FQIDw8Ci9OIDIzMyAwIFIKPj4KL05NICgxOGM1 MGJlZi01MzE5LTQ2NjctODJkYTBmMzhiOThiY2FiYikKL1JDICg8P3htbCB2ZXJzaW9uPSIxLjAi Pz48Ym9keSB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94aHRtbCIgeG1sbnM6eGZhPSJo dHRwOi8vd3d3LnhmYS5vcmcvc2NoZW1hL3hmYS1kYXRhLzEuMC8iIHhmYTpBUElWZXJzaW9uPSJB Y3JvYmF0OjcuMC44IiB4ZmE6c3BlYz0iMi4wLjIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O3Rl eHQtYWxpZ246bGVmdDtjb2xvcjojMDAwMDAwO2ZvbnQtd2VpZ2h0Om5vcm1hbDtmb250LXN0eWxl Om5vcm1hbDtmb250LWZhbWlseTpBcmlhbDtmb250LXN0cmV0Y2g6bm9ybWFsIj48cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6QXJpYWw7Zm9udC1zaXplOjEyLjBwdCI+SSBkb24mYXBvczt0IHNl ZSB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGVzZSB0d28gbW9kZWxzIHF1aXRlIGNsZWFybHk8 L3NwYW4+PC9wPjwvYm9keT4pCi9OYW1lIC9Db21tZW50Ci9SZWN0IFs4MC45ODk5NDYgMzc3LjY5 Mzk5IDEwMC45ODk5NDYgMzk1LjY5Mzk5XQovU3ViaiAoU3RpY2t5IE5vdGUpCi9Qb3B1cCAxMjkg MCBSCi9TdWJ0eXBlIC9UZXh0Ci9Db250ZW50cyAoSSBkb24ndCBzZWUgdGhlIGRpZmZlcmVuY2Vz IGJldHdlZW4gdGhlc2UgdHdvIG1vZGVscyBxdWl0ZSBjbGVhcmx5KQovQ3JlYXRpb25EYXRlIChE OjIwMTMxMTAyMTkxOTEyKzAxJzAwJykKPj4KZW5kb2JqCjEyOSAwIG9iago8PAovRiAyNQovTSAo RDoyMDEzMTEwMjE5MTkzOCswMScwMCcpCi9QIDE2IDAgUgovTk0gKGVmZDAwYjc0LTU5NTctNDlj Ni1hYWE4YjA0NTU3NjBkY2YyKQovT3BlbiBmYWxzZQovUmVjdCBbNTk1IDMxNS42OTM5OSA3NDUg Mzk1LjY5Mzk5XQovUGFyZW50IDEyOCAwIFIKL1N1YnR5cGUgL1BvcHVwCj4+CmVuZG9iagoxMzAg MCBvYmoKPDwKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoIDExMzgKPj4Kc3RyZWFtCnic jVZNc9s2EL3rV+ypSWZkVfJnnJsb22lm4tRNNe2h0wMILiXUIMAAoGUd21/etyAo27IPpWYkkth9 u/v2YaHvNJ8taC6f8qvbyY/fzmgVJwuST1hNTs7mdLaY0/H5+ZxOj/EVeNJMshd9+1RuYPh9shju y49u6acl4M7pnJbNZAiwABadnp/MDmnZTt7Su+XfcJu9p+WXydvPLnFwnA4ug2oS7a7Lmxu6Dqrl jQ939ANdOGW30UR6cv2ik6840OF8cfTuzeTocHacMY9n8DdNw4Fdoo/excTWqmRwR76h695peVCW rlwyyXCE++FidprdgbxcM9XcGMc1XV9F0spRxbQKvu/wygeqTUzBVH3CY/JU9cbWpCRtQO2qA5QK em0S69QHprRWiTTSMDWHSI43z9e1bzvvkHWUGNnaSG4CVKkood0zo4b4AZkYt6Iu+OS1txHVX0Tk EpMKw4o3Lk0Bt8OKnAlAjZ3RwFGuxn3UqIgjpY2XFeu3rRB4r4JRiDalzdroNbTQWPgXqASqdB8y 1b2TshLQJCySk8U/PtHab3JDte/BEohUWoqwJq65Ljh9FJ8X1VDsWJvG6NI+FTMRqPH3klaJE3lM 6Hn2ra/ZZjrxZALbbaa9vFYgvfMxmspyZmHodIFSdT20t+lze+5R3SgiYZNqr3uJMtvTz1ef+ANU BJORatwal6vmNIRyzHUEdED2AYtdn6S99ajcPSG9rElAxuY8y+B4tgBBEH7NTkRzuXP9QDe+Mtak Ld2ODH/E+2A0/eZtn0ku1e8sd73QxTKOlqRMSxApPyREym/AlrpXxiowuldBuw+YrdmJqegDAjNp 7UFDxaIBVMxSQqZFuW3JS4IFbN4pOe8OdqC7bZF5GUOAh8+30sjAMcrWg7p6mBcsdCVtsQeUhS4Y 0q0GUUrErGw4BFTeWeWYqu1epTApQC9qk2V43/MW+dDN1zeRnqSKqfeQMleixn0M5fTah2kupCRS q6Qes5A3u2yzJKBIVWAaHzYq5C2YeufYgs60YXb7AXIJUJKBriHljbPG3RWQTuk7xuZqgm9zOB/M yrjMk8J+Wclo3MMrjORiC0yZDHDq4ysOGPkIXR6wN/2wzWfF+8LmTickaLfT1xspLRwkVAszwxhp e5tMZ180Z6w7GrEAmb6PgrzBDmSMFsk+GzO0VTN69vn2cRZI5H84/otMW2VcQUNc7ADxTL7z1q+K mrRH6ToVq5FWGcWzfMBETIEOalEa92XXYwpkJMuoeJju/1NuwzQo7rHvOh+yKDSHJLk2rGSExaKn pzBDrVN4YbgXEp4SJK0TqJHUXfCRmUKqJABpeG2UnIo/+5bpYmCN41DzltbqniVN7NbWj9lWBwXK d8m0OJZxzg6ngErrKb3amFGvlPDHAedDGafJj8dAUDKueeCzCGs8kx6VJMfda217XTkizMX7ozJm vxiuokaCjC7LpBmvq4fOCNcXXTCWDk+m8hflmPauP2/Vimmx+AugV8vJr/hbtcL3f5XHLLEKZW5k c3RyZWFtCmVuZG9iagoxMzEgMCBvYmoKPDwKL1I5IDIyOSAwIFIKPj4KZW5kb2JqCjEzMiAwIG9i ago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKMTMzIDAgb2JqCjw8Ci9EZXN0IC8xNwovUmVjdCBb NzAgNjkyLjk1IDc3LjQgNzAyLjg1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0 eXBlIC9MaW5rCj4+CmVuZG9iagoxMzQgMCBvYmoKPDwKL0Rlc3QgLzE4Ci9SZWN0IFs3MCAyODIu NTUgODguMiAyOTIuNDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xp bmsKPj4KZW5kb2JqCjEzNSAwIG9iago8PAovQyBbMSAxIDBdCi9GIDI4Ci9NIChEOjIwMTMxMTAy MTkyNjEyKzAxJzAwJykKL1AgMTcgMCBSCi9UIChjamJjKQovQVAgPDwKL04gMjM0IDAgUgo+Pgov Tk0gKDE2YTA2YTI5LWQzMDEtNGFjOC04Y2I3MWUzMWIyMGJkMDIxKQovUkMgKDw/eG1sIHZlcnNp b249IjEuMCI/Pjxib2R5IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxu czp4ZmE9Imh0dHA6Ly93d3cueGZhLm9yZy9zY2hlbWEveGZhLWRhdGEvMS4wLyIgeGZhOkFQSVZl cnNpb249IkFjcm9iYXQ6Ny4wLjgiIHhmYTpzcGVjPSIyLjAuMiIgc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7dGV4dC1hbGlnbjpsZWZ0O2NvbG9yOiMwMDAwMDA7Zm9udC13ZWlnaHQ6bm9ybWFsO2Zv bnQtc3R5bGU6bm9ybWFsO2ZvbnQtZmFtaWx5OkFyaWFsO2ZvbnQtc3RyZXRjaDpub3JtYWwiPjxw PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDtmb250LXNpemU6MTIuMHB0Ij5Ob3QgY29t cGxldGVseSBjbGVhciB0byBtZSB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGlzIGRlcGxveW1l bnQgbW9kZWwgYW5kIHRoZSBmb3JtZXIuIFRoZSBmaWd1cmVzLCBkdWUgdG8gdGhlIGhlYXZ5IHVz ZSBvZiBhY3JvbnltcyBhbmQgdGhlIHZhcmlvdXMgRkVzLCBhcmUgbm90IHRoYXQgZWFzeSB0byBm b2xsb3cuLi48L3NwYW4+PC9wPjwvYm9keT4pCi9OYW1lIC9Db21tZW50Ci9SZWN0IFs5OC40NzY0 MTIgMTY5LjcyNDU5MSAxMTguNDc2NDEyIDE4Ny43MjQ1OTFdCi9TdWJqIChTdGlja3kgTm90ZSkK L1BvcHVwIDEzNiAwIFIKL1N1YnR5cGUgL1RleHQKL0NvbnRlbnRzIChOb3QgY29tcGxldGVseSBj bGVhciB0byBtZSB0aGUgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGlzIGRlcGxveW1lbnQgbW9kZWwg YW5kIHRoZSBmb3JtZXIuIFRoZSBmaWd1cmVzLCBkdWUgdG8gdGhlIGhlYXZ5IHVzZSBvZiBhY3Jv bnltcyBhbmQgdGhlIHZhcmlvdXMgRkVzLCBhcmUgbm90IHRoYXQgZWFzeSB0byBmb2xsb3cuLi4p Ci9DcmVhdGlvbkRhdGUgKEQ6MjAxMzExMDIxOTIyMjkrMDEnMDAnKQo+PgplbmRvYmoKMTM2IDAg b2JqCjw8Ci9GIDI1Ci9NIChEOjIwMTMxMTAyMTkyNDA5KzAxJzAwJykKL1AgMTcgMCBSCi9OTSAo NDc5ZTI0MTctOGQ2ZC00Y2RhLTlmMmVhZWNkYjBmZGI5NDcpCi9PcGVuIGZhbHNlCi9SZWN0IFs1 OTUgNTIuMTI2Nzc2IDc0NSAxOTYuOTI2Nzc2XQovUGFyZW50IDEzNSAwIFIKL1N1YnR5cGUgL1Bv cHVwCj4+CmVuZG9iagoxMzcgMCBvYmoKPDwKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQovTGVuZ3Ro IDc0OAo+PgpzdHJlYW0KeJzFVmtP2zAU/Z5fcT8NUEnWhAIr0iZ1fUxIhDGWSZOmCbmJ23pL7GI7 BaR82X75rlMT+ggtQ0O7kRLr5vjc45PH9TU0PR+a5rDXOHNeXx7DWDk+mEOOncPjJhz7TWi12004 auFJUmfklLPg8oMdIPDa8edje4kzeB8hXRvaEI2ceQEfueCofegFEGXOLuxFP3Ca9waiM2f3lGsq OdVuT5KRhip6YQgDSTJ6I+RPeAUdTtI7xRQsxMdYiyGVEDT9g70d5yDwWiUnLEeREE0goUozThME VsVXgDPQAjIxZCkFLhIKv8Lz34hfxjVcjMZauhj0ry6Lp6IR/x9yRszMXYoGrEbDXYtV/YVd1lJq NepAazzGtdPCdd8+Gq77zoD6xUaef6Vn2YNGPY/NLoAe4ymX1+8WG3kWQC+tZ1OqWM9u04O1tusx oE3+hN3oa7HNHwt6rp7ZFj3VrWpQw1MDWuUppXauuveDL0UNz8O9Cv1Ceuo+5TUeAyo2f+8A4fmO gqmkMyZyBWFnjcVqssg4l5JyjcCav9KTYvbMiY36v+1TogjP636if1E18L2jqrEM2DiXFIIT6Aqe UK5oAj06TcVdhtacQGgaDdN3cCGFFrFIoYt5yWL4LNJcM8GVUdPyAg+QQkypJJrN6BJJjymcMsw1 kndkPGGaxhrL2nV0IFkAkAUAxMjPEirNY7X1bQnBYUj1DaV8pVcucg36ah8IyxgfA9FAyoatrHDQ E6LxNcB2SiAlckyB3moUbGUx9GNKjSkaxAjRdN52jRtLIglPKnmeWc4ol4iWlmcsSAqsrIPdnQxT pia4Cs0yzEuBWlDdlOiJgpGQZZ3y9dS41xih0bjjqLiqmw9KeDzBWROi0A/KcQ+UipiURqKs0wsg SSKpUsZKrJTjHMuV5UrjHCN9hh4nXmnk3MczRocqnuwDRdfMou6jfztlSAedqWQpBIf7Zl/TWn3T vl0QdNMPviNlP3I+4V5sjOc/soocFgplbmRzdHJlYW0KZW5kb2JqCjEzOCAwIG9iago8PAovUjkg MjI5IDAgUgo+PgplbmRvYmoKMTM5IDAgb2JqCjw8Ci9SNyAyMzAgMCBSCj4+CmVuZG9iagoxNDAg MCBvYmoKPDwKL0Rlc3QgLzE5Ci9SZWN0IFs3MCA2OTIuOTUgNzcuNCA3MDIuODVdCi9UeXBlIC9B bm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE0MSAwIG9iago8 PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggNTE5Cj4+CnN0cmVhbQp4nMVVXW+bMBR9 9684T2srGgbkq+lblo+pUsm2iEmTpqkixEm8hY8aJ10kv2y/fIZQaIFEbfOwgwQX7r3nHGyw72Ho JozkyK6eT95Pu1jGxERy8CVpdw10TQOtXs9Ap6VOnJIFSbsw/ZgFqvCemPs4u3g+PjiKrocenAXZ C5iKC51eW7fg+OQcF85P1aZfwbkl5zeBoDygojHk7kIgx9C2MeauTx9C/gvv0A/c9S5mMZ7gkyfC GeWwDLN5cUaalt5KOVGBnLvCxZzGggV0rmpz/WrtFiKEH87YmiII5xR/7Mlf1VIp1RoKWl1Gjkd3 U/m6HtVV/3j7eu0b2Xghain25FUn9ThguwotkzyBIn250UD+XxdH/FUptJpBP1awPTAtslyvQZYK iszjFNb4yZuSsbQHzjdZ4SkyaTiSR3lO9ZNX5UGZp3pbx5O67t8NHoOvssRT2CmU3uInF0Kh9IZ5 f6GfBPbkLEbE6ZaFm7icLAnJA99PgnRVY2JXzeQq3oZzGogDyw7gBt4q5PUEzwW0gzaO46mCtCcn /5WZD8vUO89W/DFbbjhF8xqDMIwodwXbUgxptA53vhqCawxZLDibbQSdo8+9FRPUE6onYWtdZZvN LaOz2Ftdggq4a73QHf2OGKcx+hFna1jty2SfapXdff/sLinM5g9FOnLIF7W3LtX5HyzQan4KZW5k c3RyZWFtCmVuZG9iagoxNDIgMCBvYmoKPDwKL1I5IDIyOSAwIFIKPj4KZW5kb2JqCjE0MyAwIG9i ago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKMTQ0IDAgb2JqCjw8Ci9EZXN0IC8yMAovUmVjdCBb NzAgNjkyLjk1IDc3LjQgNzAyLjg1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0 eXBlIC9MaW5rCj4+CmVuZG9iagoxNDUgMCBvYmoKPDwKL0Rlc3QgLzIxCi9SZWN0IFs3MCA2NDku NzUgNzcuNCA2NTkuNjVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xp bmsKPj4KZW5kb2JqCjE0NiAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGgg NTI5Cj4+CnN0cmVhbQp4nF1TyW7bMBC96yvm1CSAo0reUh/T2ikCJGib+lb0QFEjaxqKVMghHPfr M5RldyEBkQQf3zKkXqDISyhSH0fdZe+fbmAXshJS97tscVPATVnAfLUqYDmXj8esyYZT8PR5nAjw JSuP83HQHXzcCt0KVrBtsqNAKVywXC3yKWy77BKutr/kWP4Btg/Z5b1l9Bb5eu1Vw3Bu68dHuPOq w73zz/AObq0yh0AB/mpfNLsKPUyLcnZ1kc2m+XzgXOQA31FHT3yAT84GqtErJpkJbFrmywGWVKhp 0KNl0LLJaMwRBq6Bu2h1WigDG8vEhAE6dQBljNtLQa5jQMEJ4zmMMOIrBSa7g947dtqZcAHh5KVD 3SpLoQvAbkCg5iHqCS1sicX1o2FJcm+hV55JR6M8kAUFtWh4qiJjDZ2r0UzA4l72pJaN0sloDDxy VXhSwnoCmO/yJK5dTGgl+tGqyK3z9FvoeqWfkSVeTR6H/AmtRq76VK8J9C4EqoyEUoY0uSiiriKT ciqrhU+8r5EVmQCqcvHk51wNbj0qDrAnY5LLwLEmsbBvUURbsW0kS5du55/rGHnOl9I4LzUJaIaI MhnwvUexKjmgxt64w8AzFCuImHYdhpGoUxw95rKaL2bj23ggrIJupV4sF57/eXOb114KE+C292Rg upik1zeH/9qPr2qHUM5/Culmm32TP2Yn3zcSFgznCmVuZHN0cmVhbQplbmRvYmoKMTQ3IDAgb2Jq Cjw8Ci9SOSAyMjkgMCBSCj4+CmVuZG9iagoxNDggMCBvYmoKPDwKL1I3IDIzMCAwIFIKPj4KZW5k b2JqCjE0OSAwIG9iago8PAovRGVzdCAvMjIKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcwMi44NV0K L1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKMTUw IDAgb2JqCjw8Ci9EZXN0IC8yMwovUmVjdCBbNzAgNjQ5Ljc1IDc3LjQgNjU5LjY1XQovVHlwZSAv QW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxNTEgMCBvYmoK PDwKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoIDMxNQo+PgpzdHJlYW0KeJxdkU9PwzAM xe/5FO8EmzRK07XdeixsoEkbf6beEIcsTbtC23RJEPDt8bpqIGwp9sHv52flAN/j8I85VNmw6+0M pWUcxzQli2Y+ZtxHmCQ+4pAeo1jBehW290NDgwfGT/1QZIObjHAJEmQFOy3gxEKcRF6ArGEjjLM3 knlzZGs2WrVOmVa5q4URhcM5FpsN7oxo1Kc277hA2or621YWf+JROr1TBoHPp+NLNg28sGfGHrBK H1Lc6tZWuTLCVdTRSMC9uB8hdWrh9gTMtfxoVOvoxs4oS52FQHHeLdocrUZntNNS10Q5myeK7ZSs ikr2KyZEVEaBqKRolcpRaHPyImRvwiN9xOeD03WldlbuJ1AOovZ+T1t+dRWZQdqZqkYQTY5HhvgX L0+iVODRK0GXGXumjynp/QHka3vSCmVuZHN0cmVhbQplbmRvYmoKMTUyIDAgb2JqCjw8Ci9SOSAy MjkgMCBSCj4+CmVuZG9iagoxNTMgMCBvYmoKPDwKL1I3IDIzMCAwIFIKPj4KZW5kb2JqCjE1NCAw IG9iago8PAovRGVzdCAvMjQKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcwMi44NV0KL1R5cGUgL0Fu bm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKMTU1IDAgb2JqCjw8 Ci9EZXN0IC8yNQovUmVjdCBbNzAgNjQ5Ljc1IDc3LjQgNjU5LjY1XQovVHlwZSAvQW5ub3QKL0Jv cmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxNTYgMCBvYmoKPDwKL0Rlc3Qg LzI2Ci9SZWN0IFs3MCA2MjguMTUgODguMiA2MzguMDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFsw IDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE1NyAwIG9iago8PAovQSA8PAovUyAvVVJJ Ci9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvZHJhZnQtaWV0Zi1kbW0tcmVxdWlyZW1l bnRzLTA5KQo+PgovUmVjdCBbMTQ1LjYgNTc0LjE1IDMwOS42IDU4NC4wNV0KL1R5cGUgL0Fubm90 Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKMTU4IDAgb2JqCjw8Ci9B IDw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL3BkZi9iY3AxNCkKPj4KL1Jl Y3QgWzI1OSA1MzAuOTUgMjkzLjQgNTQwLjg1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFd Ci9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxNTkgMCBvYmoKPDwKL0EgPDwKL1MgL1VSSQovVVJJ IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL3JmYzIxMTkpCj4+Ci9SZWN0IFszMDIuMiA1MzAu OTUgMzQ3LjQgNTQwLjg1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9M aW5rCj4+CmVuZG9iagoxNjAgMCBvYmoKPDwKL0EgPDwKL1MgL1VSSQovVVJJIChodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcGRmL3JmYzQ2MDEpCj4+Ci9SZWN0IFszMzQuNiA0ODcuNzUgMzc5LjggNDk3 LjY1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9i agoxNjEgMCBvYmoKPDwKL0EgPDwKL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcv cGRmL3JmYzQ2MDUpCj4+Ci9SZWN0IFsyNzUuMiA0MzMuNzUgMzIwLjQgNDQzLjY1XQovVHlwZSAv QW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxNjIgMCBvYmoK PDwKL0EgPDwKL1MgL1VSSQovVVJJIChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL3JmYzYyMjQp Cj4+Ci9SZWN0IFsyNzUuMiAzOTAuNTUgMzIwLjQgNDAwLjQ1XQovVHlwZSAvQW5ub3QKL0JvcmRl ciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxNjMgMCBvYmoKPDwKL0Rlc3QgLzMy Ci9SZWN0IFs3MCAzNjguOTUgODguMiAzNzguODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAg MV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE2NCAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVE ZWNvZGVdCi9MZW5ndGggOTAzCj4+CnN0cmVhbQp4nIVVwXLiOBC9+yu6fNjNVNmOTQiEvQ1hQpjB WQbY2kpNzUHYDWhjS44kk3CEL9+WcYAMSUZU2Uq51f3e66fOI4RBBKH91e8kd87HbVhoJwL7Uwvn sh1COwqh2emE0GrSQ6Ezd6pTMO7XGwp8dKLdvn4lOXSnlK4DHZjOnV2BiHJBq3MZNGCaO2fwafof HQuuYDp0zgbCoBJo/J5icwP71YtjuFEsxyepHuAP+CxYttZcw9H6OzFyhgoaYXTx6U/nohE0q5zt AGCMc1QoEtT0pREFrfpLRN/upMqZ4St8HXVGKX8M/F7A0cz9NM99hY8lV5ijMPonRexRw6t1vWTC g8+BB0NeetCjzQS5QQ9GtL2XD9IwD25pz0QKXwP4JtVSChReXfVoueOjmjCXCnpcG8VnpcEUYjnj GTdriJlgiyrIfSNJarX036Thhx3YVJpyAYWSC4Vab9/IMcHCYP4ib3CsotVpfHPdiKLOT4CuYqlA RZyJoPsN10Dp0x32UqOtQ8EajISBSHnCDL4v5RF7GOIKM+160L0eQdT0bBqwRT2ir5IlRJ1O+y1g zVYYEbAbFBWuLuG6JeUzXNNJ+4fMZkrKh0NPBrYnJZVj2nsfnDtS0shEZpYIFkgPghmXmSFW2oAP k4IpohzLFGEzGsT+JN7+dartPs+kwITPrSZcCtiMccU1plt3x9XyIF+Vi5KSN8Kw9Q7Zy1/J4o7Z LaP25dab3ZrnbQATZpvw8BHNlzsJfSXL4shrB+CbQT8ebeH8wP6U5ZCMiwTKOjiRK1Rr2MTD3tbv Mm29vNftRqonplIuFqdJNq6tdE7nbPHnNQW5R/pc/lafVqPRJH0myTLnqfFgSlL8y3CZEajlzg9W mQk5QHG9FFYu1yJ8X6AeFplcV4JYkx+I7BlPyqKQyljvV6h3FxdP6Q1GqxY5JbbvLfRkzrjQNT2L nOgVimf2DkbB60nWoEk2EPOPZtn0H396T0evPhhebhUF94GN8w4TJj903eqTSGEUNX7+MpNPudgw ey9p8iWmVAhP3CxJAbNEuOvfgVFM6EoWGmjMlLl70q8a8VXY/D3i70HUDtvnBJzCPehb4XlyAAhy DnnN5hTsET3bQ4HPBhY2xe4qkvttDl1BjK4uaoxDjrPKNnQ5WBYc0n15Lmhs6ZdukS1Jzib8sn6M qCZELUvuy9T5Tv9IF/T8H/5zCC4KZW5kc3RyZWFtCmVuZG9iagoxNjUgMCBvYmoKPDwKL1I5IDIy OSAwIFIKPj4KZW5kb2JqCjE2NiAwIG9iago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKMTY3IDAg b2JqCjw8Ci9EZXN0IC8zNQovUmVjdCBbNzAgNjkyLjk1IDc3LjQgNzAyLjg1XQovVHlwZSAvQW5u b3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxNjggMCBvYmoKPDwK L0Rlc3QgLzM2Ci9SZWN0IFs3MCA2NDkuNzUgMTI2IDY1OS42NV0KL1R5cGUgL0Fubm90Ci9Cb3Jk ZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKMTY5IDAgb2JqCjw8Ci9EZXN0IC8x NQovUmVjdCBbMjg2IDYwNi41NSAzMzYuNiA2MTYuNDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFsw IDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE3MCAwIG9iago8PAovRGVzdCAvMzcKL1Jl Y3QgWzcwIDQ1NS4zNSA4OC4yIDQ2NS4yNV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQov U3VidHlwZSAvTGluawo+PgplbmRvYmoKMTcxIDAgb2JqCjw8Ci9EZXN0IC8zOAovUmVjdCBbNzAg MzM2LjU1IDg4LjIgMzQ2LjQ1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBl IC9MaW5rCj4+CmVuZG9iagoxNzIgMCBvYmoKPDwKL0Rlc3QgLzM5Ci9SZWN0IFs3MCAyMDYuOTUg ODguMiAyMTYuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsK Pj4KZW5kb2JqCjE3MyAwIG9iago8PAovQyBbMSAxIDBdCi9GIDI4Ci9NIChEOjIwMTMxMTAyMTkz NjMwKzAxJzAwJykKL1AgMjIgMCBSCi9UIChjamJjKQovQVAgPDwKL04gMjM1IDAgUgo+PgovTk0g KGZjZmE4ZDFiLTY1NWYtNDUzOS05N2RiMWUzZmU0MGMyMDljKQovUkMgKDw/eG1sIHZlcnNpb249 IjEuMCI/Pjxib2R5IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIiB4bWxuczp4 ZmE9Imh0dHA6Ly93d3cueGZhLm9yZy9zY2hlbWEveGZhLWRhdGEvMS4wLyIgeGZhOkFQSVZlcnNp b249IkFjcm9iYXQ6Ny4wLjgiIHhmYTpzcGVjPSIyLjAuMiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7dGV4dC1hbGlnbjpsZWZ0O2NvbG9yOiMwMDAwMDA7Zm9udC13ZWlnaHQ6bm9ybWFsO2ZvbnQt c3R5bGU6bm9ybWFsO2ZvbnQtZmFtaWx5OkFyaWFsO2ZvbnQtc3RyZXRjaDpub3JtYWwiPjxwPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbDtmb250LXNpemU6MTIuMHB0Ij5JIHRoaW5rIGl0 JmFwb3M7ZCBoZWxwIHRvIGFkZCBhIGNsZWFyIG1hcHBpbmcgYmV0d2VlbiB0aGUgZGlmZmVyZW50 IEZFcyBkZWZpbmVkIGFuZCB0aGUgZnVuY3Rpb25zL2VudGl0aWVzIHBsYXkgdGhhdCBwbGF5IHRo YXQgcm9sZSBpbiB0aGUgZGlmZmVyZW50IHByb3RvY29scyBcKE1JUHY2LCBQTUlQdjYsIGV0Yy5c KS4gVGhhdCB3b3VsZCBoZWxwIGNoZWNraW5nIGlmIHRoZSBtb2RlbCBjYXB0dXJlcyBhbGwgZXhp c3RpbmcgcHJvdG9jb2wgdmFyaWFudHMgYW5kIHdoZXRoZXIgdGhlIG1vZGVsIGhlbHBzIHRvIGlk ZW50aWZ5IGV4aXN0aW5nIGdhcHMgdG8gbWVldCBETU0gcmVxdWlyZW1lbnRzLjwvc3Bhbj48L3A+ PC9ib2R5PikKL05hbWUgL0NvbW1lbnQKL1JlY3QgWzQ2MC4xNzAxNDcgMjg3LjUxMjU2OSA0ODAu MTcwMTQ3IDMwNS41MTI1NjldCi9TdWJqIChTdGlja3kgTm90ZSkKL1BvcHVwIDE3NCAwIFIKL1N1 YnR5cGUgL1RleHQKL0NvbnRlbnRzIChJIHRoaW5rIGl0J2QgaGVscCB0byBhZGQgYSBjbGVhciBt YXBwaW5nIGJldHdlZW4gdGhlIGRpZmZlcmVudCBGRXMgZGVmaW5lZCBhbmQgdGhlIGZ1bmN0aW9u cy9lbnRpdGllcyBwbGF5IHRoYXQgcGxheSB0aGF0IHJvbGUgaW4gdGhlIGRpZmZlcmVudCBwcm90 b2NvbHMgXChNSVB2NiwgUE1JUHY2LCBldGMuXCkuIFRoYXQgd291bGQgaGVscCBjaGVja2luZyBp ZiB0aGUgbW9kZWwgY2FwdHVyZXMgYWxsIGV4aXN0aW5nIHByb3RvY29sIHZhcmlhbnRzIGFuZCB3 aGV0aGVyIHRoZSBtb2RlbCBoZWxwcyB0byBpZGVudGlmeSBleGlzdGluZyBnYXBzIHRvIG1lZXQg RE1NIHJlcXVpcmVtZW50cy4pCi9DcmVhdGlvbkRhdGUgKEQ6MjAxMzExMDIxOTMzNTQrMDEnMDAn KQo+PgplbmRvYmoKMTc0IDAgb2JqCjw8Ci9GIDI1Ci9NIChEOjIwMTMxMTAyMTkzNjMwKzAxJzAw JykKL1AgMjIgMCBSCi9OTSAoMzFjYWMzN2YtMWNkYS00YTk1LWFhNjk5OWNkYTk4OWE5MzgpCi9P cGVuIGZhbHNlCi9SZWN0IFs1OTUgNzQuMzEyNTY5IDc0NSAzMDUuNTEyNTY5XQovUGFyZW50IDE3 MyAwIFIKL1N1YnR5cGUgL1BvcHVwCj4+CmVuZG9iagoxNzUgMCBvYmoKPDwKL0ZpbHRlciBbL0Zs YXRlRGVjb2RlXQovTGVuZ3RoIDEyMzcKPj4Kc3RyZWFtCniczVbBUuNGEL37KzqXLFsFim0MhL15 A8u6CjYEfEhVKoexNLInK81oZ0YY7w2+PK9HIyFs2CK3mCos0Mzr7tdv3vQ3GiYjGvJP/E7LwS83 J7R0gxHxj10Ojk6GdDIa0uT0dEjHE/yycpAPwi66uYgPWPhtMGqe41da0sc54E7plOb5oAkwAhYd nx4lY5qXgz16P/8H25JfaX452JtpL62W/uDMitxT9zm7uqJPVpRybexX+pmmWhQbpxz1Pr+n3iyk pfFwdPj+3eBwnEwC5rSqpM7UPU0Tos9mTX4lKe/AUqHJ1VVlrCdBS1GRiOA/0a0pJaC69PrhSN6L siqkSxIsGY+S43bJlC56KCHAQlIlbW5sKTMSaWpspvSSvKFM5bm0UnvKZFWYTYnHrZClyWThAJjR nbBKaI8/HJIuS/z5HYhK061MvTKaJgkn4GrlxaKQ5KQnkwNwr2XxvMuoFGAm4ySYEWHTlfJAqa3E FpSnnOckK2u8SQ0yyK0pI9Ra+RWiGgugjUFmDDG7Rq4LVSi/6XaRM0UdMnOVSCVHC8x8lxGJy1IZ qlb5hul3XA2jpSvjpO6Fx9auUdhkKq9KlM9lRSwDkgUHc2BhvgL5LtIClDtEAXGUy3XXOxILU/sQ jtlAuS1S3rGFsLtV8QtOQht98OLbJAL9ZsoS8ZdGFKQCmNShMwwfy9knCTohXVQudoNFpBQcWZUi Ua2xlqnfUCmFdpytgJIc3i9qzxLrNXMfx7XYcCeNjlBcb59K4ZxJleCdiFeAlIbG0OaXa4xIea0D wW4fgOmKdWnBKKKxDt0T0dB+CNvLshXAs1x5zaVJhTf2YNbIQqHa2wrR6bol+OFydnv9GHLHhgik Pl5c00rcSWgSwqldI+7It4ej5KBPwQtsVEVUWsw4wlSF0JKFASB+601lCrNUKTpYyDtZMN19sjtu hIZmrXvmB9NklLAKNGrhhM66U44EuSlXvJvPzt1xTOCL8fIDDnEmvcCrrCWRtJRZkBAOr8iy5uAL /Pveo8d3yqGmVndn0qVWVVzmh551RpUHXtoD3svgWTOSLR+ay3SlAw0AsUag3axoUCQdu41yq1BX UCP6vRbR5WoIthXMQvq1DMcaCZva0edpc5BwKvH41C+YCWq00sGvDGSg60Bxjguicw6mm9XNeuHa IbmtzKKzqGYBp1Yq53rNbhXVCZk5fcYIi7gCI6CbDTAc3Ha1aMviKF7JYMwwIcRm88G2p9hPpeV1 UfTP/5Zgxj8WDA7B/eZ/IJuX8ujL5ZmU/pt6WnPZ1tCuei6vnuTDz339tDJ5RUVv0U/rLK+p6BX9 7FADWbRC+YGW3qaiTnFv0dJh0FK8F2FoO2piI42I4cJsRQNHLHC5urCA5g39M70MVN7AMKV19DCf 3Twy53G42VJA8HLeXoZ5CIrUKZ7AWSozHjOCfzfQGA6+Su/aaSR4aku/xgD0Dg2sbRiUtvyWHj6p JaNNHsOt325ut+0IQTG/mJ7QBHb+QGNj9yinsXgGmt10kxJfXpGYiNUMa3xfFphSwlTThm3INpZD /3nN93S3pn11YNY63H+TQx6DwdalkguXrjAJ4Ebm8O3n/L7CdeUgTKsKGh/t83w7oa3PX9diKWl0 8jcwz+eDPzCTL/H7X7ju3KAKZW5kc3RyZWFtCmVuZG9iagoxNzYgMCBvYmoKPDwKL1I5IDIyOSAw IFIKPj4KZW5kb2JqCjE3NyAwIG9iago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKMTc4IDAgb2Jq Cjw8Ci9EZXN0IC80MAovUmVjdCBbNzAgNjkyLjk1IDc3LjQgNzAyLjg1XQovVHlwZSAvQW5ub3QK L0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxNzkgMCBvYmoKPDwKL0Rl c3QgLzQxCi9SZWN0IFs3MCAyMDYuOTUgODguMiAyMTYuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVy IFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE4MCAwIG9iago8PAovRmlsdGVyIFsv RmxhdGVEZWNvZGVdCi9MZW5ndGggMTExMQo+PgpzdHJlYW0KeJydV21v2zYQ/q5fcZ+WFo5cO3GS usACJLZTGIizzFOBAcNQ0BRtcZVIlaScuNCHJb98R+rFjqy8dGfEpsS7517Ju3yHXrcPPfspf2ni fZifwUp7fbAftfJOznpw1u/BYDjswekAvxTzlp6TgvnncoGM371+sS5/aAKXAcINYQjB0isU9BEL Tocn3SMIEu8dvA/+QbHuRwiuvXdTYZgSzPhjRZYGahrPZnClSMLupPoGv8CFIPFGcw079Bs1csEU HPX6x+8PvOOj7sBh4pZBtCWnoGWmKNOHoDMaAdFAIJELHjMYSdQsDIxZzNdMbeCGGafrYTS+eewC XCBkbSZCBtP5IdxFHHEUowyFNITEEEgJ/cYMPjBtuGAhGAkmYpUiIUN2CJQIxLM4VAqdxcaxXE// uIUZSVMuVjBGsAXRDB7Gl48WRDEt4zVrgh3oEml6CyQMkUsDF8jP0QiaKWXdiiUlRqrKYgzccyil RLyBTKPxjoWbDRBBI6kwEEEluH0LEYbSuslUwgUxrMSqfTKZECwGUrgZFE+TlbN1LjOUg4dgMn+E ZSao4VIgcFiCLKW6Iyp0kk8CvB/Xg4bDCFSCEEqlCm1YS6nMoAM/dh1MiCArlljhVEkjqYxt2isE HuIOX3IUWZEUI4y1o5nJUrjjJircLMMabgRJsNqyFO1lIJf2bQmzl110tDCoZiaxYiTcANYPWcRc R6gSl4bZvNq6q1KFT9RC7Eeh8t4lhkZErBBjqWQCUmyzV8WmyCEGhgiJWGov6cg4OLbntSj9BuUu K1W5N45Jg9ZWzY6t8DC7eSzteEIdH6nTtpNjBD7k9SMTlKR4gjA+YXXOW8WuJl+nuf/r26jTqrow av9VQZ0Gd563YRT0L/4lWEYFY10Ul3mD7yWMXd3nKGgdnIxQ5mcwdnDOf8aXL0W5ouUwEUZtmkpb qM2OHZW+n7eofsKALHl7WeRN/k75ahT8WTJsd9wSf1rsqXFsucxQOPcbdL7dOc/xzspfxmnas2V4 mz01V71o4uw/tuE4qy++jqrFl7yBszVnq+n/2FMrgq2mV/LeVnJvtMfS7AZvvFSxNZeZbm4268dv rx9L9a3XSk5L1V1g3Q5RXqXP0K6CzrNmvEy7GvLZzWtH+1Uq7Tjqd09bruwrvsoUg8EnmNyTJI3Z JzeJcRFyHHqKRm2K3lf1pYvuANvmSMqUKexBOK+MWRrLjWusmbbXHL/8fFvaHUTYM1mBXfXkoola Jtss6i4ICOhHUhtA/1dKYuctumKj42BXdLLKzRXaNdhqhiCNPlmNEpFM/cUG0VMoBqe3DkNlgE6w /aWcGqttV7ubDepBz3dtGXHwYEycXfbKLkY7N0E+nW/cZCB35x9dTRGNEUiwe2N92B9zrBn20UXK DrwYxCr+dUu/5myhaXQIzODw0d2mf3KfYp41XKSKx3B0cmhn60GzhP66xbkJ+h//RsxJ4P2O/w+s 8Ps/1swdIgplbmRzdHJlYW0KZW5kb2JqCjE4MSAwIG9iago8PAovUjkgMjI5IDAgUgo+PgplbmRv YmoKMTgyIDAgb2JqCjw8Ci9SNyAyMzAgMCBSCj4+CmVuZG9iagoxODMgMCBvYmoKPDwKL0Rlc3Qg LzQyCi9SZWN0IFs3MCA2OTIuOTUgNzcuNCA3MDIuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFsw IDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE4NCAwIG9iago8PAovRmlsdGVyIFsvRmxh dGVEZWNvZGVdCi9MZW5ndGggNjM4Cj4+CnN0cmVhbQp4nHVUXU/cMBB8z6/YpwLSNb0cd9B7hHJQ JFApvbeqqhxnk7gkdrAd0euv79gJae/UOpKdj/Hs7Ow6zzRPM5qHa1xlm7x7PKfKJRmFy1bJ6nxO 59mcluv1nM6WmCwnZRJ30ePNeAPgc5IN9+MiW7rcgm5Na9qWyRAgAxedrVfpgrZtckwn2x/Ylr6n 7V1yfKs9W83+7ZUVpadpXN3f07UVLb8Y+0Rv6EKLZueUo7/GJ+lNzpYW8+z05Cg5XaTLyIlPfVcI zynRtma63ny/3XwgKTTljFQ6y44Rt6B8Rx4AdXnzQNK0ndF4T96AbVIINtYibzhCHfu+I1NSoZy3 Ku8DjTW9V7oi5xHUkdJ7XwM7CANRALJ1iACEZekjZ2tyBXptCj5yBOGCOiGf2EegwiJ7a6FsZIl4 5XcktKyNRZYfWUueRbIxWTi1p0GTaJr/SJGmaURuLMQH4F6atXF+wLrRzdfoI8+gIajkpqS2B1y1 XcNtcDIaGyPoUUp4CgEmccroiakY63YQeEacVimhP1DsA8NI1kJXIUPv/m0PvdQBfPtAoihQeRfV KN0HSNSLpnB91xkLp5DkFwUzR66YQC0cMIyqslOVRjAk0VnTiSqIPah+rO3k/L7bMzK6QVSloQsM 3sB7qkTnqBW7IEQV8E2VaqwZQnoB+cXk0XAMIPOSdwaO7bHMqOwtHLIkXIf2cqR5kAvquPfXRAV6 18t6KPUsuIQHpN70cLVRrUI6KE5sZycFOuTV1aHhXy0aS9Zg0nKX4u1ykYWzjrNzpzh3skYBPfov /XN0Nz879L+ji86qhharWTjESzoYXx9ExZStv4F0s00+48dTYf4NT5B6mwplbmRzdHJlYW0KZW5k b2JqCjE4NSAwIG9iago8PAovUjkgMjI5IDAgUgo+PgplbmRvYmoKMTg2IDAgb2JqCjw8Ci9SNyAy MzAgMCBSCj4+CmVuZG9iagoxODcgMCBvYmoKPDwKL0Rlc3QgLzQzCi9SZWN0IFs3MCA2OTIuOTUg NzcuNCA3MDIuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsK Pj4KZW5kb2JqCjE4OCAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggNzA5 Cj4+CnN0cmVhbQp4nM1WbW/aMBD+nl9xn9ZWKYxQXgqqkCgNbaXCOpRVk6atCsFQbySmjnmplC/t L58TTN5wQtp92UVKbJ/vee7sc87PUClrUPEf8bVs5fOoCTNX0cB/6EypNyvQ1CpQa7Uq0KjxF0XK VAmsYHQtGnzis6Jt2+Jj2XBpcLgWtMCYKlsCjWNBo1UvV8GwlWM4MX5zs/I5GHfK8a3DEHUQK11R c8oglKvBAPrUtNGa0D/wCbqOOX9xsQsx+WIxMkYUqhXt7ORIOauWawEmJAVfXt/DiCw5EbyOjNEb rDF72jLobptbht5AnqgliajcPN/MC+zUBIrqxc2wYxEbOzOYmMwEAdzx+vqj7sV7t15I2ylKK5xW BS30CV2bdBJQHcYQH59b7+16wAgM0YbBDVkUhdi5IQaLmgWm0eBBs9gWRc3DWxRHeM/kh21uLShh xCJzIAtETYaJk5ONIo6clPOCNJggl2EHTeT+rPxNsMkYzxE4ZILgdTB8k01NJt++Rmbj+VFFuRZJ R6qRY/CDFt/FAxrp1grfL9RAfOptS+1Io8pKj18yLzIUWRgRV4pasrSZGLsYxDJeJGJKSJETkrnA O8cKHhdpchTHOCT/NYbkl67mTFiVHuT57qXnq2KoZ3wXEyLNbtkl/oQ4/i93wI33TmEn0og0ysVJ +xNNiPkjUikPJ2so0cuJK2QLGzk4oivDCaLvPvZ2jW9eCicKK2L6iD8hEURMH8ifgv74MhgeubyU oBUmSzetTBEFaZFRqoKqgNnLviZksZaUIofftlZyCNOxngiVAyQJ1HeWVxmDNxj+8/EWflS1cmOv qvbxbEkR1Nugb0x7MUft4O6HnQmmyPLLNZhsW8lpcEt0OdJ5Q5TvO4zGrvV0CoiBOS9HsPpmwe1d 6C4onkO1furfQ2tpx37cmzPENT85pm4oX/ndecbffwHNjhWuCmVuZHN0cmVhbQplbmRvYmoKMTg5 IDAgb2JqCjw8Ci9SOSAyMjkgMCBSCj4+CmVuZG9iagoxOTAgMCBvYmoKPDwKL1I3IDIzMCAwIFIK Pj4KZW5kb2JqCjE5MSAwIG9iago8PAovRGVzdCAvNDQKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcw Mi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRv YmoKMTkyIDAgb2JqCjw8Ci9EZXN0IC80NQovUmVjdCBbNzAgNjQ5Ljc1IDEyNiA2NTkuNjVdCi9U eXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE5MyAw IG9iago8PAovRGVzdCAvOQovUmVjdCBbMjkxLjQgNjE3LjM1IDM0MiA2MjcuMjVdCi9UeXBlIC9B bm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE5NCAwIG9iago8 PAovRGVzdCAvOQovUmVjdCBbMjY0LjQgNTg0Ljk1IDMxNSA1OTQuODVdCi9UeXBlIC9Bbm5vdAov Qm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjE5NSAwIG9iago8PAovQSA8 PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvcmZjNDYwMSkKPj4KL1Jl Y3QgWzE0MC4yIDQzMy43NSAxODAgNDQzLjY1XQovVHlwZSAvQW5ub3QKL0JvcmRlciBbMCAwIDFd Ci9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoxOTYgMCBvYmoKPDwKL0EgPDwKL1MgL1VSSQovVVJJ IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcGRmL3JmYzQ2MDUpCj4+Ci9SZWN0IFszMjkuMiAzOTAu NTUgMzY5IDQwMC40NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGlu awo+PgplbmRvYmoKMTk3IDAgb2JqCjw8Ci9BIDw8Ci9TIC9VUkkKL1VSSSAoaHR0cDovL3Rvb2xz LmlldGYub3JnL3BkZi9yZmM2MjI0KQo+PgovUmVjdCBbNDA0LjggMzkwLjU1IDQ0NC42IDQwMC40 NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoK MTk4IDAgb2JqCjw8Ci9DIFsxIDEgMF0KL0YgMjgKL00gKEQ6MjAxMzExMDIxOTQwNTUrMDEnMDAn KQovUCAyNiAwIFIKL1QgKGNqYmMpCi9BUCA8PAovTiAyMzYgMCBSCj4+Ci9OTSAoYzU3NzdlZjIt OWU3OC00ZTVhLTkyNjg0MWNmMzlkMzI5YzYpCi9SQyAoPD94bWwgdmVyc2lvbj0iMS4wIj8+PGJv ZHkgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiIHhtbG5zOnhmYT0iaHR0cDov L3d3dy54ZmEub3JnL3NjaGVtYS94ZmEtZGF0YS8xLjAvIiB4ZmE6QVBJVmVyc2lvbj0iQWNyb2Jh dDo3LjAuOCIgeGZhOnNwZWM9IjIuMC4yIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDt0ZXh0LWFs aWduOmxlZnQ7Y29sb3I6IzAwMDAwMDtmb250LXdlaWdodDpub3JtYWw7Zm9udC1zdHlsZTpub3Jt YWw7Zm9udC1mYW1pbHk6QXJpYWw7Zm9udC1zdHJldGNoOm5vcm1hbCI+PHA+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OkFyaWFsO2ZvbnQtc2l6ZToxMi4wcHQiPkluIHRoZSBtdWx0aWNhc3QgcGFy dCwgSSBiZWxpZXZlIHRoZSBrZXkgZGlmZmVyZW5jZSBpcyB0aGF0IHRoZSBhbmNob3IgaXMgbm90 IGRlZmluZWQgYnkgdGhlIElQIGFkZHJlc3MgdXNlZCBieSB0aGUgbW9iaWxlIG5vZGUsIGJ1dCBi eSB0aGUgZW50aXR5IHBlcmZvcm1pbmcgdGhlIGdyb3VwIHN1YnNjcmlwdGlvbiBcKHRoZSBhY3R1 YWwgSVAgYWRkcmVzcyBvZiB0aGUgTU4gZG9lcyBub3QgcmVhbGx5IHBsYXkgYSByb2xlIGluIG11 bHRpY2FzdFwpLiBJJmFwb3M7bSBub3Qgc3VyZSB0aGUgdGV4dCBvZiB0aGlzIHNlY3Rpb24gY2Fw dHVyZXMgdGhpczwvc3Bhbj48L3A+PC9ib2R5PikKL05hbWUgL0NvbW1lbnQKL1JlY3QgWzQwNS44 NzAwNyA2NDUuOTM3NzA1IDQyNS44NzAwNyA2NjMuOTM3NzA1XQovU3ViaiAoU3RpY2t5IE5vdGUp Ci9Qb3B1cCAxOTkgMCBSCi9TdWJ0eXBlIC9UZXh0Ci9Db250ZW50cyAoSW4gdGhlIG11bHRpY2Fz dCBwYXJ0LCBJIGJlbGlldmUgdGhlIGtleSBkaWZmZXJlbmNlIGlzIHRoYXQgdGhlIGFuY2hvciBp cyBub3QgZGVmaW5lZCBieSB0aGUgSVAgYWRkcmVzcyB1c2VkIGJ5IHRoZSBtb2JpbGUgbm9kZSwg YnV0IGJ5IHRoZSBlbnRpdHkgcGVyZm9ybWluZyB0aGUgZ3JvdXAgc3Vic2NyaXB0aW9uIFwodGhl IGFjdHVhbCBJUCBhZGRyZXNzIG9mIHRoZSBNTiBkb2VzIG5vdCByZWFsbHkgcGxheSBhIHJvbGUg aW4gbXVsdGljYXN0XCkuIEknbSBub3Qgc3VyZSB0aGUgdGV4dCBvZiB0aGlzIHNlY3Rpb24gY2Fw dHVyZXMgdGhpcykKL0NyZWF0aW9uRGF0ZSAoRDoyMDEzMTEwMjE5Mzg0MSswMScwMCcpCj4+CmVu ZG9iagoxOTkgMCBvYmoKPDwKL0YgMjUKL00gKEQ6MjAxMzExMDIxOTM4NDErMDEnMDAnKQovUCAy NiAwIFIKL05NICg3YThhZDFiZi0yOWU3LTQ3OTEtOWJlOTY4NmM2MDdiZTFiOSkKL09wZW4gdHJ1 ZQovUmVjdCBbNTk1IDU2OS42NzQzMTcgNzQ1IDY0OS42NzQzMTddCi9QYXJlbnQgMTk4IDAgUgov U3VidHlwZSAvUG9wdXAKPj4KZW5kb2JqCjIwMCAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNv ZGVdCi9MZW5ndGggMTAzNQo+PgpzdHJlYW0KeJydVttu4kgQffdX1NPujOR4gJBkMm8EyCpS0LIE pJFGEWrsMvSucXu620nYt+TLt6p946pNxkjY4O5T55y62D+hFbShxZ/yHK69L5MrWBqvDfzRS+/i qgVX7RZ0r69bcNmlL41e7LldMPmjvKCFP712cV2ewjXcTAnuGq5hGntFgDZhweX1RdCB6dr7BJ+n f9O24CtM771Pd6lFnaI9G2gRW6iPwWgEt1qs8Vnpf+A36KUi2RhpYOv4M7RqgRo6rfb559+9807Q dZi9LMM0ki9wEwDc5mlopaLt0NPhSloMba4RYqVhlCdWhsJYF+4hzzKlLSF12sGlQ6Ig0xWtrYnw rvXOLlPsAqJm5FomQoNVYLd3EWKtlxAZI0+PIKRWqygPMaJLeEBHG87hWdqVA1wLmRIWY0QyjlFj GiLdEdbdFlEkS6VbUDEK1mtAkOgUMaL/rCphqtAOvZYVKt6egEgjyA0ZnCUixYC9IJW1LL8C2ZWt UjwlxW9uEI7KNes/q2AyDGUsQ39X8DGpBuF2WCgSiwQ5sqmTx1iNFktl5UBlaiyKCFRcm1/eI2G9 xjoGXsvlqoJa1K4tcluYqJxFRkZEywm07IvGJ2lYJkVg8hEXtM+7SqRQpIy25Q0KI5MNI8S5K8on 1AxhdjA4DxVEE5ariJfc9MdkkQlz44JzzpYio3PRL8GxclZJop5luqxdDHNNDlvishVBGMAXaSwv rA3dq+WFMLRyq8cIhZyk9FJOFrlMoiKRaiETaTdnjh/5npqtbFH7cz1926OqqHmH89Hk2zb+kPE3 7I8AYwlN6Girj+/GMFE5jRT4sseUjgcqrHBV1fHtsMlIqDTxEdb1xk5XxHVoClvyZW4cf0JTBv99 UrmBsaK0wutk/OYUutsDNHKZOtCS0+tg8uaDQWyAMFgGPvyY3Pa7l6324366Sg/uB2fjj9hwT2nD FPWhBwMqFUVltoGxVi8beB3dPxD4Gze6E59p9UQFABSzzC5V2jPBUxn4De+mhlzPZ0jucf1FGMu0 6IodaRePzhj+ddnpdE8J7c3789ExpaOyguhBEK6U9qFfDqkxzyafSR6KZWpVMsmqg6lwisPsnRxm PBwbAhzvkMTHCczm/ZPhsQjaTyR12i+5UE0/TscBIWqOu5T6giasiptsH6xzoCVX10ZFBSAPjWax 4QbRW/NrByopi/REKczms/e68NE8vN+CncFX+Xlgwew9FhyDOmVBMaXL52P1YHTTumrTSs1hZmie 74l3Uej5hdSxJ8zuT7//T81zpeGLhSkPb3og+wWVX+o7JnFRvKvdS1yYcOUDUjqSoHm5G75kkl9b epmWCXQufH7N68Le8WMslgid9iMhDqfeX/RquqTv/wB5+mPcCmVuZHN0cmVhbQplbmRvYmoKMjAx IDAgb2JqCjw8Ci9SOSAyMjkgMCBSCj4+CmVuZG9iagoyMDIgMCBvYmoKPDwKL1I3IDIzMCAwIFIK Pj4KZW5kb2JqCjIwMyAwIG9iago8PAovRGVzdCAvNDYKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcw Mi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRv YmoKMjA0IDAgb2JqCjw8Ci9EZXN0IC85Ci9SZWN0IFs4Ni4yIDUzMC45NSAxMzYuOCA1NDAuODVd Ci9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjIw NSAwIG9iago8PAovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggNjQzCj4+CnN0cmVhbQp4 nLVUXW/TMBR9z6+4T7BJWdakH6O8jS1FlVZtjDwgITQ5zk1qSOzMdmjLG/xyrp2o3cqExANO5US2 7znnnnvrRxhFMYzcM7x5E5zfX0Blghjco6tgejGCi3gEk/l8BLMJTRqDMvBRcP9++KCDj0Hcfw8v 3sC7jODmMIesDHqCmLBgNp9GCWRNcAKn2VcKi95AdhOcLKVFLdGeXWtWWtiP69UKFpo1uFH6G7yC S8nqnREGnoxbblWOGpJRPD59HYyTaOIxaUsBLNKH5cPqLSw6ya1QFA+ptMLuYCkrjcaAVZ6mrZnE EDqDBZRKg10joe0V9lyma1ulLagSmq62gjNjwZLmUvCIjidxNHtOnr5MnvbchPMfuZfp1cvsjmNI /3xQcqWk1ao+iPhTAKn6JxHZGg2SDrOPMqIRNdNQIrMd0QIzHlVJ3B8i9nz3ggOUz+oq+xT6xPyc hkOSjiOk5jQtUqLfsd6FUKDhWuSEJiQhOYSP6G2AcQgbYdeeuWFCQiHKEjVKjrTGrNvYAdN4XJCT 51Xw8XsTeG8gMFm4ON0XlXQJaSyyYogYYDr516hjKxeiIr9gRmm1gtvetZwZwcGgF1MeioyuyIIc /blIfznkIyeF+7OVjKPvfZQsrxGWd2esKHwrOE1Cdq5RyJxDhsRHdlC/RkMSVGByp9Nu7cyZL6gL fMFdOiRRaKqwUVwwV1bVoma+AvQ7WPFETo52g+g3G+BM0gKVldXiR98VuBWGpFXQamUVV7UJBxDc WpSGsH1OPp7KJnFzOOpUjyfTwdQbgbnh6xDIPlZHh+sk3bbCteZlq0UNyTR0F8sEjsbnO1YhJMkX Ak2z4ANdhhXNvwEn8ZmyCmVuZHN0cmVhbQplbmRvYmoKMjA2IDAgb2JqCjw8Ci9SOSAyMjkgMCBS Cj4+CmVuZG9iagoyMDcgMCBvYmoKPDwKL1I3IDIzMCAwIFIKPj4KZW5kb2JqCjIwOCAwIG9iago8 PAovRGVzdCAvNDcKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcwMi44NV0KL1R5cGUgL0Fubm90Ci9C b3JkZXIgWzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKMjA5IDAgb2JqCjw8Ci9EZXN0 IC85Ci9SZWN0IFsyOTYuOCAxNTIuOTUgMzQ3LjQgMTYyLjg1XQovVHlwZSAvQW5ub3QKL0JvcmRl ciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoyMTAgMCBvYmoKPDwKL0ZpbHRlciBb L0ZsYXRlRGVjb2RlXQovTGVuZ3RoIDg4MAo+PgpzdHJlYW0KeJy1Vltv2jAUfs+vOE+7iEC5tR3V XjouG1LROgZSpWmNTHDAW0gy29Ah5WX75Tt2nJSEZg2TdkDEJP6+79ySnB/QbLSgqT7m6G6ss+kl rITVAvXhK+v8sgmXrSZ0e70mXHTxh1PLszQKpu/NAjf+sFrJ2hzcDbybIV0PejDzrESghVxw0Ttv tGG2sV7B69k3hDXewOzGejUOJOUBlfUBJ56EzAaTCYw42dCHkH+HF3AdEH8vmIAD++jKcEE5tJut zuuXVqfd6GpOKFo/DCQPfbj1SUCv0rPZYkAkMdeQJnPtiOZpU5jKe7NVvFSiEXG/U/lPBDvwQg6b cMF8CkG4pEcstbq2WvJv6oz7ziTHkm44QsajoTN2JvHbema1HDLd8IxmsreaZt5qiiOPVFSlKIxO +aPUTkAltlPf3UmoWj4tFVE6a8O+9vN/aym7198CavdczeKsZJX6ZPjYJ8gQT5071WZX+Q3lmlNn mLRlVc1j2x3F+JfMZNlMPa6EUnFM+rO75AaK/6uWKpqq3H1av1JUvnC68+M4rV8pSscyBVM0qIg6 KNjdB0xDNVTRTtLKQjshrptB/daEBidrYWgDFdrpcZVoFe+1YmDHqHzLHHZPgUpHe+30D+6+OHlq plRmx9yZnOmKn6X5KcZSSMG1ri4u7rL7uLJXT+UlXZySzKdQpQ+ux7dNAVUr9VLnZu70szdcLY80 1+elDy4FwBTN0zfqk5rtVuPicZIYsdWWU7i4gndEMBcElRB64G0DV7IQxxuggWSSUQG/RsPfQIIl MDUdecTFczIsm01oQBY4A4xv62S55FQIcHHeYcGWyT0ywGbrS+YSIWFBBF2q0arg3GxNccLzKKeB SyEKUVbAgsoHSgMYDQUQdFysw4dA8aWBNADGQcGpiHDU2vqEg0RSjxKJe5VHm4gzpb7Y6ytHcknn 2SbhSW5t04a2mV5s87rQ581RvfftxEG2YVo4VAqGKAxQXWyjKOTyGXXNOk80E8VE78CnfqJoI4GI KNZtR/29DUsqXM4WVBUMPlNdT+jY8MDkWustmWcEDZdcE6mu7LXnW5UYdNv4qSHFqrlmho3UnKpc 6nbUQI1pv2F0Idy1DdhQxG88NsbwZ8RU8q8x9T60z201KXeLt9qXW7Ki0O58Rc7hzPqE0/0Kf/8A EYCAtwplbmRzdHJlYW0KZW5kb2JqCjIxMSAwIG9iago8PAovUjkgMjI5IDAgUgo+PgplbmRvYmoK MjEyIDAgb2JqCjw8Ci9SNyAyMzAgMCBSCj4+CmVuZG9iagoyMTMgMCBvYmoKPDwKL0Rlc3QgLzQ4 Ci9SZWN0IFs3MCA2OTIuOTUgNzcuNCA3MDIuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAg MV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5kb2JqCjIxNCAwIG9iago8PAovQSA8PAovUyAvVVJJCi9V UkkgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9wZGYvcmZjNDYwMSkKPj4KL1JlY3QgWzEwNy44IDU3 NC4xNSAxNDcuNiA1ODQuMDVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUg L0xpbmsKPj4KZW5kb2JqCjIxNSAwIG9iago8PAovQSA8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly90 b29scy5pZXRmLm9yZy9wZGYvcmZjNDYwNSkKPj4KL1JlY3QgWzI1My42IDUzMC45NSAyOTMuNCA1 NDAuODVdCi9UeXBlIC9Bbm5vdAovQm9yZGVyIFswIDAgMV0KL1N1YnR5cGUgL0xpbmsKPj4KZW5k b2JqCjIxNiAwIG9iago8PAovQSA8PAovUyAvVVJJCi9VUkkgKGh0dHA6Ly90b29scy5pZXRmLm9y Zy9wZGYvcmZjNjIyNCkKPj4KL1JlY3QgWzMyOS4yIDUzMC45NSAzNjkgNTQwLjg1XQovVHlwZSAv QW5ub3QKL0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoyMTcgMCBvYmoK PDwKL0ZpbHRlciBbL0ZsYXRlRGVjb2RlXQovTGVuZ3RoIDQ4Mgo+PgpzdHJlYW0KeJyNk11vmzAU hu/5Fe/V1kopA0KSpnddk2yTgtYhLipVVeTAgXgDm9pO0/77HUj6sXSTZkv+kPFz3vccc4/ADxF0 /TDnjfcpnaCyXoium8obTQJMwgDxdBpgHPNgyCu9/hbSL4cFf3jvhfv1YcobfM4YN8UUWentA4TM wng68iNkjXeC0+wnX/PPkS29k2/KkVHkzmZGlA4vbZYkWBjR0E6bX/iASyXqJyst3rTvudNrMoiC cHj60RtGftwz+Ugq60gU0CXstm21cVJVcBvCVslcWIe1sFQg18oZXaOthSKfIVHoj58h2U5DFIV0 UnN0zkFJhlROaLVUzkIY6s4Z4zbC9dtcN62R9hCMeS9GmVfquta77qwk4baG7MVRRA2kq5uvq+QC cyXWNdle82K+Sq6ym1UCp1mGM5IeCEkKo7e9sd7MUbQ+C6U2jej0ozS66UHpGx0dXLdk9p8UVErF bqQC+ZU/YOABdJsuruJxEN4dp2gvePafgre12yd/Kbk8isx7yTNpc/1A5olVmp0wRSfzrz6Ws7Pr P6286v23p2crozsIVfS7cRTFvbF4GPVKlpLWNt8MQFzU2n99cPPHVnLVcMk1rhGNBt3Ti3HUbq9F RWAmI+eZ94N/l4rH3xEz+SsKZW5kc3RyZWFtCmVuZG9iagoyMTggMCBvYmoKPDwKL1I5IDIyOSAw IFIKPj4KZW5kb2JqCjIxOSAwIG9iago8PAovUjcgMjMwIDAgUgo+PgplbmRvYmoKMjIwIDAgb2Jq Cjw8Ci9EZXN0IC80OQovUmVjdCBbNzAgNjkyLjk1IDc3LjQgNzAyLjg1XQovVHlwZSAvQW5ub3QK L0JvcmRlciBbMCAwIDFdCi9TdWJ0eXBlIC9MaW5rCj4+CmVuZG9iagoyMjEgMCBvYmoKPDwKL0Rl c3QgLzUwCi9SZWN0IFs3MCA2NDkuNzUgMTI2IDY1OS42NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIg WzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKMjIyIDAgb2JqCjw8Ci9GaWx0ZXIgWy9G bGF0ZURlY29kZV0KL0xlbmd0aCA0ODgKPj4Kc3RyZWFtCnicpVNNb9QwEL3nV7wTtFI3JOl+clt2 C0LqQqnCCXHwOpPENLFT26Fbfj3j7BeqkDhgS7ajeX7veWbyiCROkYR52GUbvbmfoXJRijBtFU1m CWZpgvFikWA65sVSVEbDLdx/OBwY+Bil+/Nhky3e5Uy3wAJ5Ge0FUubCdDGJM+RtdIHL/Adfi+fI b6OLj9qT1eRHaytKj9NYbzZ4b0VLT8Y+4BWWWjTPTjn8MT5Lb7ZkkSXp9eXr6DqLxwPnsutIF2qH VQysaqErwifjyTEoS+PpAMIx5KA0fpJ1ymgk6VsGhaAB2Js1RS+pQNlr6RkgGriuUR5b8k9EGrRT zitdYWO2igPP7FTWxjLL6Y17tysT6JoRhC7w1ZEd3TVC0wtP/5A15VmxDYqEnqkgG0Xa/4fosihY r2cR/QBr+kFBGu1UQVYED0OeQlmElbXyJH1v6ZysNTlpVReQwaVAqazzw4VN33glBX+Vp4oyl68J x1KdefZGaCfaruHaeDPgxLGkYsveUJunEOGnD9Ezbfm3zAtUouMMHDoopIJxw82CnKoGw4att+oX awfLzjT98OjQV/P5ge5W0dbJ+grkIZr43Ik3u05ZdrvsrGqQTa5CT47xYny7E9yJ2eQ7k97k0Rf+ jypefwM7hgZ/CmVuZHN0cmVhbQplbmRvYmoKMjIzIDAgb2JqCjw8Ci9SOSAyMjkgMCBSCj4+CmVu ZG9iagoyMjQgMCBvYmoKPDwKL1I3IDIzMCAwIFIKPj4KZW5kb2JqCjIyNSAwIG9iago8PAovRGVz dCAvNTEKL1JlY3QgWzcwIDY5Mi45NSA3Ny40IDcwMi44NV0KL1R5cGUgL0Fubm90Ci9Cb3JkZXIg WzAgMCAxXQovU3VidHlwZSAvTGluawo+PgplbmRvYmoKMjI2IDAgb2JqCjw8Ci9GaWx0ZXIgWy9G bGF0ZURlY29kZV0KL0xlbmd0aCA1NDUKPj4Kc3RyZWFtCnicbVNNU9swEL37V+ypwDRxLX8Fc0oI LmUIhYJ76vSg2BtHRZbCSobm31eOHZrJsJqRNHrap7cfeoHAZxB0Y1jLxvvyOIHaeAy6QbWXTAKY sADiLAsgjd1E6K28nRc8Xg8bd/HFY/1+WMoGLgtHl0EGxcrrH2COC9Is8UMoGu8Uzoo/zs0/h2Lh nd4oi6TQjq+Iryy829XdHXwl3uCbpmf4BDPF5dYIAwd2X1q9RIIwYNHZiReFfrzjnLV2rcmcwKyq CI1B49CQ+ekOdY53nEoNC4FLU64d9q7GYd/zOSz4UhO3mgQayFvSG3S39mh/AAtb+cPpbUurFslY VOOZkrxGiNIBuxqnGWMJfENRoXRy69GAXCM1XG2PtD2stcIL+BxnkIYhgziKQxanRyrzhgt5AbIP YaqwlHzpY3uYho5MIJEon+EJhcUjjnviqsaxy7IqEQqUWOpm0BaPgFqEqoW51AbmuiWLcgSXD5Cx MNwHN3fZ1Wr8hK+iVjhyJ1GSsHBAe+YP4/s4nM0g1zed3KnuBa5sTbrd+L26w/CuUVMtnL5bTrwW XClhjph/KvHqKiPsFvQKijdUdl/LWQ65ctnDaqd8kgTBvspo10iSq+q4c/bViRgkEcTnWRxk2cfB PA+apqXxW7t72Fey44smA+HQgSNAC1z6/zs7/7sRrnNhtiEhIUxGXY/HcGS/HrpOC9PfjjQvvB/u X9Zu/geFAP/tCmVuZHN0cmVhbQplbmRvYmoKMjI3IDAgb2JqCjw8Ci9SOSAyMjkgMCBSCj4+CmVu ZG9iagoyMjggMCBvYmoKPDwKL1I3IDIzMCAwIFIKPj4KZW5kb2JqCjIyOSAwIG9iago8PAovVHlw ZSAvRm9udAovU3VidHlwZSAvVHlwZTEKL0Jhc2VGb250IC9Db3VyaWVyCi9FbmNvZGluZyAyMzcg MCBSCj4+CmVuZG9iagoyMzAgMCBvYmoKPDwKL09QTSAxCi9UeXBlIC9FeHRHU3RhdGUKPj4KZW5k b2JqCjIzMSAwIG9iago8PAovQkJveCBbMCAwIDIwIDE4XQovRmlsdGVyIFsvRmxhdGVEZWNvZGVd Ci9MZW5ndGggMzE5Ci9NYXRyaXggWzEgMCAwIDEgMCAwXQovU3VidHlwZSAvRm9ybQovRm9ybVR5 cGUgMQovUmVzb3VyY2VzIDw8Ci9Qcm9jU2V0IFsvUERGXQo+Pgo+PgpzdHJlYW0KeNpNkTlSBDEM RXOfQidQWd6dkhCRcAVXsVWTkHB95C956Jrk/R4tz7aQUKSf9xBp/16fg9BXKPQSIjf61c+fQSa3 RJ1rom8PlXsiGSyJCqdG0jgNwxUmx7650hUKz0yRc1JuHLPVXCFzPyg8mrHWNRsNwsYVwFI4dy22 0Fg6oU86t0x7mtEKpmJJh8PRkql7szGmrvsJr0Af4cmvQ+8l8+i7rogeHnvAmStQVx0U0UkWMs9q Utq+i8dB+ImHC7LnL+Ui3uvsQx9pH8w6IGGjgOsuijO8+RfhlI862BSFzyHifqJjHrk3M492sePg MY9+seaB5H7offDM/+Z7mTdAwSYB113zLj44VvcGwq/zlEO9Hmt9uAHpzqWaM0j3Jx7FgipnjmJB Uar1HcS4EyYeQqux2qYA103Obf8AQYuctAplbmRzdHJlYW0KZW5kb2JqCjIzMiAwIG9iago8PAov QkJveCBbMCAwIDIwIDE4XQovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMzE5Ci9NYXRy aXggWzEgMCAwIDEgMCAwXQovU3VidHlwZSAvRm9ybQovRm9ybVR5cGUgMQovUmVzb3VyY2VzIDw8 Ci9Qcm9jU2V0IFsvUERGXQo+Pgo+PgpzdHJlYW0KeNpNkTlSBDEMRXOfQidQWd6dkhCRcAVXsVWT kHB95C956Jrk/R4tz7aQUKSf9xBp/16fg9BXKPQSIjf61c+fQSa3RJ1rom8PlXsiGSyJCqdG0jgN wxUmx7650hUKz0yRc1JuHLPVXCFzPyg8mrHWNRsNwsYVwFI4dy220Fg6oU86t0x7mtEKpmJJh8PR kql7szGmrvsJr0Af4cmvQ+8l8+i7rogeHnvAmStQVx0U0UkWMs9qUtq+i8dB+ImHC7LnL+Ui3uvs Qx9pH8w6IGGjgOsuijO8+RfhlI862BSFzyHifqJjHrk3M492sePgMY9+seaB5H7offDM/+Z7mTdA wSYB113zLj44VvcGwq/zlEO9Hmt9uAHpzqWaM0j3Jx7FgipnjmJBUar1HcS4EyYeQqux2qYA103O bf8AQYuctAplbmRzdHJlYW0KZW5kb2JqCjIzMyAwIG9iago8PAovQkJveCBbMCAwIDIwIDE4XQov RmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMzE5Ci9NYXRyaXggWzEgMCAwIDEgMCAwXQov U3VidHlwZSAvRm9ybQovRm9ybVR5cGUgMQovUmVzb3VyY2VzIDw8Ci9Qcm9jU2V0IFsvUERGXQo+ Pgo+PgpzdHJlYW0KeNpNkTlSBDEMRXOfQidQWd6dkhCRcAVXsVWTkHB95C956Jrk/R4tz7aQUKSf 9xBp/16fg9BXKPQSIjf61c+fQSa3RJ1rom8PlXsiGSyJCqdG0jgNwxUmx7650hUKz0yRc1JuHLPV XCFzPyg8mrHWNRsNwsYVwFI4dy220Fg6oU86t0x7mtEKpmJJh8PRkql7szGmrvsJr0Af4cmvQ+8l 8+i7rogeHnvAmStQVx0U0UkWMs9qUtq+i8dB+ImHC7LnL+Ui3uvsQx9pH8w6IGGjgOsuijO8+Rfh lI862BSFzyHifqJjHrk3M492sePgMY9+seaB5H7offDM/+Z7mTdAwSYB113zLj44VvcGwq/zlEO9 Hmt9uAHpzqWaM0j3Jx7FgipnjmJBUar1HcS4EyYeQqux2qYA103Obf8AQYuctAplbmRzdHJlYW0K ZW5kb2JqCjIzNCAwIG9iago8PAovQkJveCBbMCAwIDIwIDE4XQovRmlsdGVyIFsvRmxhdGVEZWNv ZGVdCi9MZW5ndGggMzE5Ci9NYXRyaXggWzEgMCAwIDEgMCAwXQovU3VidHlwZSAvRm9ybQovRm9y bVR5cGUgMQovUmVzb3VyY2VzIDw8Ci9Qcm9jU2V0IFsvUERGXQo+Pgo+PgpzdHJlYW0KeNpNkTlS BDEMRXOfQidQWd6dkhCRcAVXsVWTkHB95C956Jrk/R4tz7aQUKSf9xBp/16fg9BXKPQSIjf61c+f QSa3RJ1rom8PlXsiGSyJCqdG0jgNwxUmx7650hUKz0yRc1JuHLPVXCFzPyg8mrHWNRsNwsYVwFI4 dy220Fg6oU86t0x7mtEKpmJJh8PRkql7szGmrvsJr0Af4cmvQ+8l8+i7rogeHnvAmStQVx0U0UkW Ms9qUtq+i8dB+ImHC7LnL+Ui3uvsQx9pH8w6IGGjgOsuijO8+RfhlI862BSFzyHifqJjHrk3M492 sePgMY9+seaB5H7offDM/+Z7mTdAwSYB113zLj44VvcGwq/zlEO9Hmt9uAHpzqWaM0j3Jx7Fgipn jmJBUar1HcS4EyYeQqux2qYA103Obf8AQYuctAplbmRzdHJlYW0KZW5kb2JqCjIzNSAwIG9iago8 PAovQkJveCBbMCAwIDIwIDE4XQovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMzE5Ci9N YXRyaXggWzEgMCAwIDEgMCAwXQovU3VidHlwZSAvRm9ybQovRm9ybVR5cGUgMQovUmVzb3VyY2Vz IDw8Ci9Qcm9jU2V0IFsvUERGXQo+Pgo+PgpzdHJlYW0KeNpNkTlSBDEMRXOfQidQWd6dkhCRcAVX sVWTkHB95C956Jrk/R4tz7aQUKSf9xBp/16fg9BXKPQSIjf61c+fQSa3RJ1rom8PlXsiGSyJCqdG 0jgNwxUmx7650hUKz0yRc1JuHLPVXCFzPyg8mrHWNRsNwsYVwFI4dy220Fg6oU86t0x7mtEKpmJJ h8PRkql7szGmrvsJr0Af4cmvQ+8l8+i7rogeHnvAmStQVx0U0UkWMs9qUtq+i8dB+ImHC7LnL+Ui 3uvsQx9pH8w6IGGjgOsuijO8+RfhlI862BSFzyHifqJjHrk3M492sePgMY9+seaB5H7offDM/+Z7 mTdAwSYB113zLj44VvcGwq/zlEO9Hmt9uAHpzqWaM0j3Jx7FgipnjmJBUar1HcS4EyYeQqux2qYA 103Obf8AQYuctAplbmRzdHJlYW0KZW5kb2JqCjIzNiAwIG9iago8PAovQkJveCBbMCAwIDIwIDE4 XQovRmlsdGVyIFsvRmxhdGVEZWNvZGVdCi9MZW5ndGggMzE5Ci9NYXRyaXggWzEgMCAwIDEgMCAw XQovU3VidHlwZSAvRm9ybQovRm9ybVR5cGUgMQovUmVzb3VyY2VzIDw8Ci9Qcm9jU2V0IFsvUERG XQo+Pgo+PgpzdHJlYW0KeNpNkTlSBDEMRXOfQidQWd6dkhCRcAVXsVWTkHB95C956Jrk/R4tz7aQ UKSf9xBp/16fg9BXKPQSIjf61c+fQSa3RJ1rom8PlXsiGSyJCqdG0jgNwxUmx7650hUKz0yRc1Ju HLPVXCFzPyg8mrHWNRsNwsYVwFI4dy220Fg6oU86t0x7mtEKpmJJh8PRkql7szGmrvsJr0Af4cmv Q+8l8+i7rogeHnvAmStQVx0U0UkWMs9qUtq+i8dB+ImHC7LnL+Ui3uvsQx9pH8w6IGGjgOsuijO8 +RfhlI862BSFzyHifqJjHrk3M492sePgMY9+seaB5H7offDM/+Z7mTdAwSYB113zLj44VvcGwq/z lEO9Hmt9uAHpzqWaM0j3Jx7FgipnjmJBUar1HcS4EyYeQqux2qYA103Obf8AQYuctAplbmRzdHJl YW0KZW5kb2JqCjIzNyAwIG9iago8PAovVHlwZSAvRW5jb2RpbmcKL0RpZmZlcmVuY2VzIFsxMjgg L2JhY2tzbGFzaCAvcGFyZW5sZWZ0IC9wYXJlbnJpZ2h0XQo+PgplbmRvYmoKeHJlZgowIDIzOAow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMTUgMDAwMDAgbg0KMDAwMDAwMDQzMiAwMDAwMCBu DQowMDAwMDAwNTEwIDAwMDAwIG4NCjAwMDAwMDIxNDQgMDAwMDAgbg0KMDAwMDAwMjM3NCAwMDAw MCBuDQowMDAwMDA2MDExIDAwMDAwIG4NCjAwMDAwMDYyMTAgMDAwMDAgbg0KMDAwMDAwNjY2OCAw MDAwMCBuDQowMDAwMDA2ODg4IDAwMDAwIG4NCjAwMDAwMDcwODAgMDAwMDAgbg0KMDAwMDAwNzI4 MSAwMDAwMCBuDQowMDAwMDA3NDg3IDAwMDAwIG4NCjAwMDAwMDc2OTMgMDAwMDAgbg0KMDAwMDAw Nzg4MyAwMDAwMCBuDQowMDAwMDA4MDczIDAwMDAwIG4NCjAwMDAwMDgyNjMgMDAwMDAgbg0KMDAw MDAwODQ4NSAwMDAwMCBuDQowMDAwMDA4Njk5IDAwMDAwIG4NCjAwMDAwMDg4ODkgMDAwMDAgbg0K MDAwMDAwOTA4NyAwMDAwMCBuDQowMDAwMDA5Mjg1IDAwMDAwIG4NCjAwMDAwMDk1NDcgMDAwMDAg bg0KMDAwMDAwOTc5MyAwMDAwMCBuDQowMDAwMDA5OTkxIDAwMDAwIG4NCjAwMDAwMTAxODEgMDAw MDAgbg0KMDAwMDAxMDM3MSAwMDAwMCBuDQowMDAwMDEwNjI1IDAwMDAwIG4NCjAwMDAwMTA4MjMg MDAwMDAgbg0KMDAwMDAxMTAyMSAwMDAwMCBuDQowMDAwMDExMjM1IDAwMDAwIG4NCjAwMDAwMTE0 MzMgMDAwMDAgbg0KMDAwMDAxMTYyMyAwMDAwMCBuDQowMDAwMDExNzc5IDAwMDAwIG4NCjAwMDAw MTE5MzUgMDAwMDAgbg0KMDAwMDAxMjEwMyAwMDAwMCBuDQowMDAwMDEzMzY3IDAwMDAwIG4NCjAw MDAwMTM0MDEgMDAwMDAgbg0KMDAwMDAxMzQzNSAwMDAwMCBuDQowMDAwMDEzNTQwIDAwMDAwIG4N CjAwMDAwMTM2OTYgMDAwMDAgbg0KMDAwMDAxMzg1NCAwMDAwMCBuDQowMDAwMDEzOTYyIDAwMDAw IG4NCjAwMDAwMTQwNjkgMDAwMDAgbg0KMDAwMDAxNDE3OCAwMDAwMCBuDQowMDAwMDE0Mjg1IDAw MDAwIG4NCjAwMDAwMTQzOTQgMDAwMDAgbg0KMDAwMDAxNDUwMSAwMDAwMCBuDQowMDAwMDE0NjEw IDAwMDAwIG4NCjAwMDAwMTQ3MTggMDAwMDAgbg0KMDAwMDAxNDgyNiAwMDAwMCBuDQowMDAwMDE0 OTM0IDAwMDAwIG4NCjAwMDAwMTUwNDEgMDAwMDAgbg0KMDAwMDAxNTE0OSAwMDAwMCBuDQowMDAw MDE1MjU3IDAwMDAwIG4NCjAwMDAwMTUzNjUgMDAwMDAgbg0KMDAwMDAxNTQ3MyAwMDAwMCBuDQow MDAwMDE1NTgxIDAwMDAwIG4NCjAwMDAwMTU2ODkgMDAwMDAgbg0KMDAwMDAxNTc5NyAwMDAwMCBu DQowMDAwMDE1OTA0IDAwMDAwIG4NCjAwMDAwMTYwMTIgMDAwMDAgbg0KMDAwMDAxNjExOSAwMDAw MCBuDQowMDAwMDE2MjI3IDAwMDAwIG4NCjAwMDAwMTYzMzYgMDAwMDAgbg0KMDAwMDAxNjQ0NCAw MDAwMCBuDQowMDAwMDE2NTUxIDAwMDAwIG4NCjAwMDAwMTY2NTkgMDAwMDAgbg0KMDAwMDAxNjc2 NiAwMDAwMCBuDQowMDAwMDE2ODc0IDAwMDAwIG4NCjAwMDAwMTY5ODEgMDAwMDAgbg0KMDAwMDAx NzA4OSAwMDAwMCBuDQowMDAwMDE3MTk2IDAwMDAwIG4NCjAwMDAwMTczMDQgMDAwMDAgbg0KMDAw MDAxNzQxMyAwMDAwMCBuDQowMDAwMDE3NTIxIDAwMDAwIG4NCjAwMDAwMTc2MzAgMDAwMDAgbg0K MDAwMDAxNzczOCAwMDAwMCBuDQowMDAwMDE3ODQ2IDAwMDAwIG4NCjAwMDAwMTg4OTIgMDAwMDAg bg0KMDAwMDAxODkyNiAwMDAwMCBuDQowMDAwMDE4OTYwIDAwMDAwIG4NCjAwMDAwMTkwNjUgMDAw MDAgbg0KMDAwMDAxOTE3MCAwMDAwMCBuDQowMDAwMDE5Mjc2IDAwMDAwIG4NCjAwMDAwMTkzODYg MDAwMDAgbg0KMDAwMDAyMDIzNCAwMDAwMCBuDQowMDAwMDIwNDIzIDAwMDAwIG4NCjAwMDAwMjE5 MDcgMDAwMDAgbg0KMDAwMDAyMTk0MSAwMDAwMCBuDQowMDAwMDIxOTc1IDAwMDAwIG4NCjAwMDAw MjIwODAgMDAwMDAgbg0KMDAwMDAyMjE4OSAwMDAwMCBuDQowMDAwMDIyNTkwIDAwMDAwIG4NCjAw MDAwMjI2MjQgMDAwMDAgbg0KMDAwMDAyMjY1OCAwMDAwMCBuDQowMDAwMDIyNzYzIDAwMDAwIG4N CjAwMDAwMjI4NjggMDAwMDAgbg0KMDAwMDAyMzAyNiAwMDAwMCBuDQowMDAwMDIzNDgzIDAwMDAw IG4NCjAwMDAwMjM1MTcgMDAwMDAgbg0KMDAwMDAyMzU1MiAwMDAwMCBuDQowMDAwMDIzNjU4IDAw MDAwIG4NCjAwMDAwMjM3NjQgMDAwMDAgbg0KMDAwMDAyMzg3NSAwMDAwMCBuDQowMDAwMDI1MTkx IDAwMDAwIG4NCjAwMDAwMjUyMjYgMDAwMDAgbg0KMDAwMDAyNTI2MSAwMDAwMCBuDQowMDAwMDI1 MzY4IDAwMDAwIG4NCjAwMDAwMjY0MDQgMDAwMDAgbg0KMDAwMDAyNjU5NSAwMDAwMCBuDQowMDAw MDI3OTc2IDAwMDAwIG4NCjAwMDAwMjgwMTEgMDAwMDAgbg0KMDAwMDAyODA0NiAwMDAwMCBuDQow MDAwMDI4MTUzIDAwMDAwIG4NCjAwMDAwMjk0MzUgMDAwMDAgbg0KMDAwMDAyOTQ3MCAwMDAwMCBu DQowMDAwMDI5NTA1IDAwMDAwIG4NCjAwMDAwMjk2MTIgMDAwMDAgbg0KMDAwMDAzMDU0OCAwMDAw MCBuDQowMDAwMDMwNTgzIDAwMDAwIG4NCjAwMDAwMzA2MTggMDAwMDAgbg0KMDAwMDAzMDcyNSAw MDAwMCBuDQowMDAwMDMxNzA1IDAwMDAwIG4NCjAwMDAwMzE3NDAgMDAwMDAgbg0KMDAwMDAzMTc3 NSAwMDAwMCBuDQowMDAwMDMxODgyIDAwMDAwIG4NCjAwMDAwMzE5ODkgMDAwMDAgbg0KMDAwMDAz MjA5NiAwMDAwMCBuDQowMDAwMDMyOTIzIDAwMDAwIG4NCjAwMDAwMzMxMTMgMDAwMDAgbg0KMDAw MDAzNDMyOCAwMDAwMCBuDQowMDAwMDM0MzYzIDAwMDAwIG4NCjAwMDAwMzQzOTggMDAwMDAgbg0K MDAwMDAzNDUwNSAwMDAwMCBuDQowMDAwMDM0NjEyIDAwMDAwIG4NCjAwMDAwMzU2NzYgMDAwMDAg bg0KMDAwMDAzNTg2NyAwMDAwMCBuDQowMDAwMDM2NjkxIDAwMDAwIG4NCjAwMDAwMzY3MjYgMDAw MDAgbg0KMDAwMDAzNjc2MSAwMDAwMCBuDQowMDAwMDM2ODY4IDAwMDAwIG4NCjAwMDAwMzc0NjMg MDAwMDAgbg0KMDAwMDAzNzQ5OCAwMDAwMCBuDQowMDAwMDM3NTMzIDAwMDAwIG4NCjAwMDAwMzc2 NDAgMDAwMDAgbg0KMDAwMDAzNzc0NyAwMDAwMCBuDQowMDAwMDM4MzUyIDAwMDAwIG4NCjAwMDAw MzgzODcgMDAwMDAgbg0KMDAwMDAzODQyMiAwMDAwMCBuDQowMDAwMDM4NTI5IDAwMDAwIG4NCjAw MDAwMzg2MzYgMDAwMDAgbg0KMDAwMDAzOTAyNyAwMDAwMCBuDQowMDAwMDM5MDYyIDAwMDAwIG4N CjAwMDAwMzkwOTcgMDAwMDAgbg0KMDAwMDAzOTIwNCAwMDAwMCBuDQowMDAwMDM5MzExIDAwMDAw IG4NCjAwMDAwMzk0MTggMDAwMDAgbg0KMDAwMDAzOTYwMCAwMDAwMCBuDQowMDAwMDM5NzU1IDAw MDAwIG4NCjAwMDAwMzk5MTQgMDAwMDAgbg0KMDAwMDA0MDA3MyAwMDAwMCBuDQowMDAwMDQwMjMy IDAwMDAwIG4NCjAwMDAwNDAzOTEgMDAwMDAgbg0KMDAwMDA0MDQ5OCAwMDAwMCBuDQowMDAwMDQx NDc3IDAwMDAwIG4NCjAwMDAwNDE1MTIgMDAwMDAgbg0KMDAwMDA0MTU0NyAwMDAwMCBuDQowMDAw MDQxNjU0IDAwMDAwIG4NCjAwMDAwNDE3NjAgMDAwMDAgbg0KMDAwMDA0MTg2OSAwMDAwMCBuDQow MDAwMDQxOTc2IDAwMDAwIG4NCjAwMDAwNDIwODMgMDAwMDAgbg0KMDAwMDA0MjE5MCAwMDAwMCBu DQowMDAwMDQzNTYwIDAwMDAwIG4NCjAwMDAwNDM3NTEgMDAwMDAgbg0KMDAwMDA0NTA2NSAwMDAw MCBuDQowMDAwMDQ1MTAwIDAwMDAwIG4NCjAwMDAwNDUxMzUgMDAwMDAgbg0KMDAwMDA0NTI0MiAw MDAwMCBuDQowMDAwMDQ1MzQ5IDAwMDAwIG4NCjAwMDAwNDY1MzcgMDAwMDAgbg0KMDAwMDA0NjU3 MiAwMDAwMCBuDQowMDAwMDQ2NjA3IDAwMDAwIG4NCjAwMDAwNDY3MTQgMDAwMDAgbg0KMDAwMDA0 NzQyOCAwMDAwMCBuDQowMDAwMDQ3NDYzIDAwMDAwIG4NCjAwMDAwNDc0OTggMDAwMDAgbg0KMDAw MDA0NzYwNSAwMDAwMCBuDQowMDAwMDQ4MzkwIDAwMDAwIG4NCjAwMDAwNDg0MjUgMDAwMDAgbg0K MDAwMDA0ODQ2MCAwMDAwMCBuDQowMDAwMDQ4NTY3IDAwMDAwIG4NCjAwMDAwNDg2NzMgMDAwMDAg bg0KMDAwMDA0ODc4MSAwMDAwMCBuDQowMDAwMDQ4ODg5IDAwMDAwIG4NCjAwMDAwNDkwNDYgMDAw MDAgbg0KMDAwMDA0OTIwMyAwMDAwMCBuDQowMDAwMDQ5MzYyIDAwMDAwIG4NCjAwMDAwNTA2Nzgg MDAwMDAgbg0KMDAwMDA1MDg2OSAwMDAwMCBuDQowMDAwMDUxOTgxIDAwMDAwIG4NCjAwMDAwNTIw MTYgMDAwMDAgbg0KMDAwMDA1MjA1MSAwMDAwMCBuDQowMDAwMDUyMTU4IDAwMDAwIG4NCjAwMDAw NTIyNjcgMDAwMDAgbg0KMDAwMDA1Mjk4NiAwMDAwMCBuDQowMDAwMDUzMDIxIDAwMDAwIG4NCjAw MDAwNTMwNTYgMDAwMDAgbg0KMDAwMDA1MzE2MyAwMDAwMCBuDQowMDAwMDUzMjczIDAwMDAwIG4N CjAwMDAwNTQyMjkgMDAwMDAgbg0KMDAwMDA1NDI2NCAwMDAwMCBuDQowMDAwMDU0Mjk5IDAwMDAw IG4NCjAwMDAwNTQ0MDYgMDAwMDAgbg0KMDAwMDA1NDU2NSAwMDAwMCBuDQowMDAwMDU0NzI0IDAw MDAwIG4NCjAwMDAwNTQ4ODEgMDAwMDAgbg0KMDAwMDA1NTQzOSAwMDAwMCBuDQowMDAwMDU1NDc0 IDAwMDAwIG4NCjAwMDAwNTU1MDkgMDAwMDAgbg0KMDAwMDA1NTYxNiAwMDAwMCBuDQowMDAwMDU1 NzIyIDAwMDAwIG4NCjAwMDAwNTYyODYgMDAwMDAgbg0KMDAwMDA1NjMyMSAwMDAwMCBuDQowMDAw MDU2MzU2IDAwMDAwIG4NCjAwMDAwNTY0NjMgMDAwMDAgbg0KMDAwMDA1NzA4NCAwMDAwMCBuDQow MDAwMDU3MTE5IDAwMDAwIG4NCjAwMDAwNTcxNTQgMDAwMDAgbg0KMDAwMDA1NzI0MiAwMDAwMCBu DQowMDAwMDU3Mjg5IDAwMDAwIG4NCjAwMDAwNTc3ODQgMDAwMDAgbg0KMDAwMDA1ODI3OSAwMDAw MCBuDQowMDAwMDU4Nzc0IDAwMDAwIG4NCjAwMDAwNTkyNjkgMDAwMDAgbg0KMDAwMDA1OTc2NCAw MDAwMCBuDQowMDAwMDYwMjU5IDAwMDAwIG4NCnRyYWlsZXIKPDwKL0lEIFs8QzhEMzMyNTQxRTMz RTkxRUY4NEY3QzY1NzA3RERENzE+IDxDOEQzMzI1NDFFMzNFOTFFRjg0RjdDNjU3MDdEREQ3MT5d Ci9JbmZvIDEgMCBSCi9Sb290IDIgMCBSCi9TaXplIDIzOAo+PgpzdGFydHhyZWYKNjAzNTEKJSVF T0YK --=-iJolKQdIisAQUthTp5qu-- From alper.yegin@yegin.org Tue Nov 5 08:25:20 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A0021E8183 for ; Tue, 5 Nov 2013 08:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G15P1gXAdygx for ; Tue, 5 Nov 2013 08:24:57 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 05DB811E81A3 for ; Tue, 5 Nov 2013 08:24:55 -0800 (PST) Received: from [10.119.8.3] (178-211-44-68.turkrdns.com [178.211.44.68]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MGRxI-1VQY9j3uMK-00DfDY; Tue, 05 Nov 2013 11:24:54 -0500 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_AA903A5B-6A5E-4DD0-A49B-4421897DBF39" Date: Tue, 5 Nov 2013 18:24:48 +0200 Message-Id: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> To: dmm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:3YBF5Wbmz78OIRHAQ1VCdNX7EQnksjB3Crk2guphdBl 6e/nGiYQxSQEQeH+5MO48XrOmNJd/TBJ9ThQSMZwRgSJj2cJZ3 1wJ1tpvQc5+cd433+uqPno/m1zkZ4rp5AGZVzrbk4CFekvm0g7 s0zketiUuY9y6nu2XbQoaIKtRxStTCSyYwT7TgSPC9+98uJJZC 6zk+8EdAmsJSqhUs8RjwWUTDVK3zqmMPcvFvAY8C9pEaNUxS5I Oz0y5sHx5m/+PIiLpciBnliUAa7FCBjrKc7+lEkpn/W6fscoDe qr5zxoPrHPXP58r4dqEhHury4csy2zOkAR2XHGPAI8ASVRZL8z e5Yr/TnLn+sAM57xdLOWQXlAae4c41P6Fk5QPUQA1 Subject: [DMM] Req#1 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:25:21 -0000 --Apple-Mail=_AA903A5B-6A5E-4DD0-A49B-4421897DBF39 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello folks, REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. The real issue is not the "central location of the anchor", but = "off-path location of the anchor". The triangular route is caused by forcing the packets to traverse an = anchor node that is not on the direct IP path between the MN and the CN. See the CNet-Homing proposal. = http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-01.txt. We place the = anchor in corresponding network, or the ISP serving that network. = Therefore, the path going via that anchor does not cause triangulation. = Some people may perceive that as locating the anchor in a central = location (though this time it's not an "absolute/unchanging" center as = implied in the current text). Therefore I recommend the following revision: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic is not forced to traverse off-path mobility anchors and thereby avoid non-optimal routes. Alper --Apple-Mail=_AA903A5B-6A5E-4DD0-A49B-4421897DBF39 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 
Hello folks,

   REQ1:  Distributed =
processing

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic does not need to traverse centrally deployed
          mobility anchors and thereby avoid non-optimal =
routes.

The real issue is not the "central = location of the anchor", but "off-path location of the = anchor".

The triangular route is caused by = forcing the packets to traverse an anchor node that is not on the direct = IP path between the MN and the CN.

See the = CNet-Homing proposal. http://= www.ietf.org/id/draft-yegin-dmm-cnet-homing-01.txt. We place the = anchor in corresponding network, or the ISP serving that network. = Therefore, the path going via that anchor does not cause triangulation. = Some people may perceive that as locating the anchor in a central = location (though this time it's not an "absolute/unchanging" center as = implied in the current text).

Therefore I = recommend the following revision:

   REQ1:  Distributed processing

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic is not forced to traverse off-path
          mobility anchors and thereby avoid non-optimal =
routes.

Alper


=


= --Apple-Mail=_AA903A5B-6A5E-4DD0-A49B-4421897DBF39-- From alper.yegin@yegin.org Tue Nov 5 08:47:30 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E125321E825C for ; Tue, 5 Nov 2013 08:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiUH0kqBsXif for ; Tue, 5 Nov 2013 08:47:22 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 703DD11E82AF for ; Tue, 5 Nov 2013 08:46:12 -0800 (PST) Received: from [10.119.8.3] (178-211-44-68.turkrdns.com [178.211.44.68]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MDiSs-1VPzCD2Q7q-00Gk5A; Tue, 05 Nov 2013 11:46:10 -0500 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_F57716F3-88EC-4A19-823A-CAA9C2680BBD" Date: Tue, 5 Nov 2013 18:46:04 +0200 Message-Id: To: dmm Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:bw0hgn4IXIkEo2Cx5NMXI5q2XXjfpykZkFxhO04Hp+I U0VPFF9/hW/G+iOl4pCmosshqk1fBBXXBLCKwo6yWi4UIS7XiV IKY01UG3govw6PafF14zXJqbLrWGqYhbe8RwtYkF23pH8u6+8R iJ4X8D0iiHdXp90Lt1gtXrmdKsxSgN/QxY85y+K4hWgpEIoZ1F /p8CQz9yJY04BObA10yrtYl/p9+pVcFmHQ0731m8I5+7KOVAeq +v0i5s+afVxM7s8cm6wajREAew1jwwhE/8o+EwWBYPqYYqe+I8 E+EqaC8bHx1NnnyGW+z/QqCZu/pKiFpkYa1cHhYhNo7HGlbWfA VCBFyGnc3922WYkLewHS2lMN9SFtl2TFEU6rllDap Subject: [DMM] Gap analysis comments X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:47:30 -0000 --Apple-Mail=_F57716F3-88EC-4A19-823A-CAA9C2680BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Please see below for my comments on this document. The present document analyses deplyment practices of existing mobility protocols in a distributed mobility management environment. Are the protocols mentioned in this document all deployed?? I don't = think so. It looks more like "protocols with specifications" that can be = envisioned to be used in DMM style. Correct? 1. Anchoring function (AF): allocation to a mobile node of an IP addres/prefix (e.g., a HoA or HNP) topologically anchored by the delegating node (i.e., the anchor node is able to advertise a connected route into the routing infrastructure for the delegated IP prefixes). 2. Mobility Routing (MR) function: packets interception and forwarding to/from the IP address/prefix delegated to the MN, based on the internetwork location information, either to the destination or to some other network element that knows how to forward the packets to their destination; 3. Internetwork Location Management (LM) function: managing and keeping track of the internetwork location of an MN, which includes a mapping of the IP delegated address/prefix (e.g., HoA or HNP) to the mobility anchoring point where the MN is anchored to; 4. Location Update (LU): provisioning of MN location information to the LM function; I perceive AF and MR are inseparable. Also, LU is part of LM. (if we really want to break LU out of LM, then we also need to enumerate = the part that deals with encap/decap functionality) Typically, the a connection manager together with the operating system configure the source address selection mechanism of the IP stack.=20 Does the CM really do that? I don't think so. CM selects the network to = attach to. Whatever IP addresses are configured gets selected by the Src = Address Selection algorithm, which does not interface with the CM as far = as I know. IP flows of applications which do not need a constant IP address should not be handled by DMM. The term "constant IP address" is vague. We should mention both "IP = session continuity" and "IP address reachability (of permanent IP = address)", and state that providing the former is in the scope of DMM = but not the latter. Note that both of these features deal with somewhat = "constant" IP address, though with varying lifetime. In IP session = continuity, the IP address is constant throughout out the IP session, = and may change afterwards. In IP address reachability, the IP address is = constant even when there is no IP session (you know, it's used for = things like running a server on the MN, which needs to accept incoming = connections at the published IP address). The draft also mentions MOBIKE. But note that MOBIKE by itself does not = give us a DMM solution. It provides a MM solution, and in a special = setup it can be used for a DMM solution (e.g., by dynamically allocating = the VPN server, etc.) o Multiple (distributed) anchoring: ability to anchor different sessions of a single mobile node at different anchors. In order to make this feature "DMM-friendly", some anchors might need to be placed closer to the mobile node. What matters is placing the anchor closer to the direct IP path between = the MN and the CN. Closure to that direct path can be achieved by placing the anchor near = the MN, and also near the CN. So, I'd propose the following revision: o Multiple (distributed) anchoring: ability to anchor different sessions of a single mobile node at different anchors. In order to make this feature "DMM-friendly", some anchors might need to be placed closer to the mobile node or the corresponding node. Or, if we don't want to get in this level of detail, we can say the = following: o Multiple (distributed) anchoring: ability to anchor different sessions of a single mobile node at different anchors. In order to make this feature "DMM-friendly", some anchors need to be placed closer to direct IP path between the mobile node and the = corresponding node. This for example implies having the knowledge of which sessions are active at the mobile node, which is something typically known only by the MN e.g., by its connection manager). =20 Again, I don't think CM knows about the active IP sessions. Cheers, Alper --Apple-Mail=_F57716F3-88EC-4A19-823A-CAA9C2680BBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii    mobility protocols in a distributed = mobility management environment.

Are the = protocols mentioned in this document all deployed?? I don't think = so.
It looks more like "protocols with specifications" that = can be envisioned to be used in DMM style. = Correct?



       addres/prefix (e.g., a = HoA or HNP) topologically anchored by the
       = delegating node (i.e., the anchor node is able to advertise a
       IP = prefixes).

       forwarding to/from the = IP address/prefix delegated to the MN,
       = based on the internetwork location information, either to the
       forward = the packets to their destination;


   3.  Internetwork = Location Management (LM) function: managing and
       includes a mapping of = the IP delegated address/prefix (e.g., HoA
       = or HNP) to the mobility anchoring point where the MN is = anchored
       to;

   4.  Location = Update (LU): provisioning of MN location information to
       with the operating = system configure the source address selection
       IP flows = of
       be handled by = DMM.

The term "constant IP address" is = vague. We should mention both "IP session continuity" and "IP address = reachability (of permanent IP address)", and state that providing the = former is in the scope of DMM but not the latter. Note that both of = these features deal with somewhat "constant" IP address, though with = varying lifetime. In IP session continuity, the IP address is constant = throughout out the IP session, and may change afterwards. In IP address = reachability, the IP address is constant even when there is no IP = session (you know, it's used for things like running a server on the MN, = which needs to accept incoming connections at the published IP = address).


The draft also = mentions MOBIKE. But note that MOBIKE by itself does not give us a DMM = solution. It provides a MM solution, and in a special setup it can be = used for a DMM solution (e.g., by dynamically allocating the VPN server, = etc.)


   o  = Multiple (distributed) anchoring: ability to anchor different
      to make this = feature "DMM-friendly", some anchors might need to be
What matters is placing the anchor closer to the = direct IP path between the MN and the CN.
Closure to that direct path = can be achieved by placing the anchor near the MN, and also near the = CN.
So, I'd propose the following revision:
   o  Multiple (distributed) = anchoring: ability to anchor different
    =   sessions of a single mobile node at different = anchors.  In order
      to make = this feature "DMM-friendly", some anchors might need to be

Or, if we don't want to get in this = level of detail, we can say the following:

      sessions of a single = mobile node at different anchors.  In order
      placed closer to direct = IP path between the mobile node and the corresponding = node.



   having the = knowledge of which sessions are active at the mobile node,
   connection manager). =  

Cheers,

Alper







List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:18:58 -0000 --_000_6E31144C030982429702B11D6746B98C370D7705szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding: "When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be considered to be eliminated." My understanding of the intention is that it is sufficient to apply the exi= sting security mechanisms/protocols to protect the DMM entities. Ideally, we don't want DMM to add new security risks. Yet, DMM can introduce new DMM entities, which can be vulnerable to securit= y risks, and it is necessary to protect the new DMM entities. So we basically don't want DMM to introduce new security risks that cannot = be handled with the existing security mechanisms. If the wording "considered to be eliminated" does not clarify the above, ho= w about the following: "When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be eliminated." Or, can you come up with better text prior to Friday. I am trying to close = all requirements issues prior to the meeting on Friday to enable the wg to = move to the next step. Regarding your comment on the helpful references, I understand that there a= re many other individual drafts in the solution space. I did recently accep= t a prior comment to add the coloring reference. Yet now if we continue to = respond to requests to add references to the individual drafts, it will not= end. With the many individual drafts in the solution space, I hope the wg = will have drafts that will merge/incorporate many solution drafts in future= . May I now ask all the authors of the individual drafts to kindly wait for= such future wg draft to consider what solutions to include/exclude? H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper= Yegin Sent: Monday, November 04, 2013 10:20 AM To: dmm Subject: [DMM] Requirements Hello folks, Here I have two comments on this document. "When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be considered to be eliminated." I don't quite understand what that means. "Infrequent node mobility coupled with application intelligence suggest that mobility support could be provided selectively such as in [I-D.bhandari-dhc-class-based- prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing the amount of context maintained in the network." Two more related work references that are complementary to the ones already= provided are: - draft-yegin-dmm-ondemand-mobility-00 - draft-liu-dmm-mobility-api-01 I recommend we include these references as well. Alper --_000_6E31144C030982429702B11D6746B98C370D7705szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding:

= "When the existing security mechanisms/protocols are=

= applied to protect the DMM entities, the security risks that

= may be introduced by DMM MUST be considered to be eliminated."

My understanding of the i= ntention is that it is sufficient to apply the existing security mechanisms= /protocols to protect the DMM entities.

Ideally, we don’t w= ant DMM to add new security risks.

Yet, DMM can introduce ne= w DMM entities, which can be vulnerable to security risks, and it is necess= ary to protect the new DMM entities.

So we basically don’= ;t want DMM to introduce new security risks that cannot be handled with the= existing security mechanisms.

 <= /p>

If the wording “con= sidered to be eliminated” does not clarify the above, how about the f= ollowing:

= "When the existing security mechanisms/protocols are=

= applied to protect the DMM entities, the security risks that

= may be introduced by DMM MUST be eliminated."

 <= /p>

Or, can you come up with = better text prior to Friday. I am trying to close all requirements issues p= rior to the meeting on Friday to enable the wg to move to the next step.

 <= /p>

Regarding your comment on= the helpful references, I understand that there are many other individual = drafts in the solution space. I did recently accept a prior comment to add the coloring reference. Yet now if we continue to respond t= o requests to add references to the individual drafts, it will not end. Wit= h the many individual drafts in the solution space, I hope the wg will have= drafts that will merge/incorporate many solution drafts in future. May I now ask all the authors of the indiv= idual drafts to kindly wait for such future wg draft to consider what solut= ions to include/exclude?

 <= /p>

H Anthony Chan=

 <= /p>

From: dmm-boun= ces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Monday, November 04, 2013 10:20 AM
To: dmm
Subject: [DMM] Requirements

 

Hello folks,

 

Here I have two comments on this document.

 

= "When the existing security mechanisms/protocols are=

= applied to protect the DMM entities, the security risks that

= may be introduced by DMM MUST be considered to be eliminated."

=  

= I don't quite understand what that means. 

=  

= "Infrequent node mobility coupled with

= application intelligence suggest that mobility support could be<= /span>

= provided selectively such as in [I-D.bhandari-dhc-class-based-

= prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing=

= the amount of context maintained in the network."

=  

= Two more related work references that are complementary to the ones already= provided are:

= - draft-yegin-dmm-ondemand-mobility-00

= - draft-liu-dmm-mobility-api-01

=  

= I recommend we include these references as well.

=  

= Alper

=  

=  

 

--_000_6E31144C030982429702B11D6746B98C370D7705szxeml557mbxchi_-- From h.anthony.chan@huawei.com Tue Nov 5 14:21:16 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE0211E81BA for ; Tue, 5 Nov 2013 14:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwuBRModYuQm for ; Tue, 5 Nov 2013 14:21:12 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 129BB11E818E for ; Tue, 5 Nov 2013 14:21:10 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO71737; Tue, 05 Nov 2013 22:21:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 22:20:27 +0000 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 22:21:08 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.63]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 06:21:04 +0800 From: h chan To: Alper Yegin , dmm Thread-Topic: [DMM] Req#1 Thread-Index: AQHO2kOmGaJkc2GAEkSKP6f44GqUGpoXJ/1Q Date: Tue, 5 Nov 2013 22:21:04 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> In-Reply-To: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.209] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370D770Bszxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Req#1 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:21:16 -0000 --_000_6E31144C030982429702B11D6746B98C370D770Bszxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is the following also acceptable: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid traversing mobility anchors that are in non-optimal routes. I am trying to write it in simple wording and not getting into a new term s= uch as "off path" H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper= Yegin Sent: Tuesday, November 05, 2013 8:25 AM To: dmm Subject: [DMM] Req#1 Hello folks, REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. The real issue is not the "central location of the anchor", but "off-path l= ocation of the anchor". The triangular route is caused by forcing the packets to traverse an anchor= node that is not on the direct IP path between the MN and the CN. See the CNet-Homing proposal. http://www.ietf.org/id/draft-yegin-dmm-cnet-h= oming-01.txt. We place the anchor in corresponding network, or the ISP serv= ing that network. Therefore, the path going via that anchor does not cause = triangulation. Some people may perceive that as locating the anchor in a ce= ntral location (though this time it's not an "absolute/unchanging" center a= s implied in the current text). Therefore I recommend the following revision: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic is not forced to traverse off-path mobility anchors and thereby avoid non-optimal routes. Alper --_000_6E31144C030982429702B11D6746B98C370D770Bszxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is the following also acc= eptable:

   REQ1:  Distributed proce=
ssing
 
        =
;  IP mobility, network access and routing solutions provided by<=
o:p>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic can avoid traversing 
       =
   mobility anchors that are in non-optimal routes.

 <= /p>

I am trying to write it i= n simple wording and not getting into a new term such as “off path= 221;

H Anthony Chan=

 <= /p>

From: dmm-boun= ces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Tuesday, November 05, 2013 8:25 AM
To: dmm
Subject: [DMM] Req#1

 

Hello folks,
 
   RE=
Q1:  Distributed processing
 
        =
;  IP mobility, network access and routing solutions provided by<=
o:p>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic does not need to traverse centrally deployed
       =
   mobility anchors and thereby avoid non-optimal routes.

 

The real issue is not the "central location of = the anchor", but "off-path location of the anchor".

 

The triangular route is caused by forcing the packet= s to traverse an anchor node that is not on the direct IP path between the = MN and the CN.

 

See the CNet-Homing proposal. http://www.ietf.org/id= /draft-yegin-dmm-cnet-homing-01.txt. We place the anchor in correspondi= ng network, or the ISP serving that network. Therefore, the path going via that anchor does not cause triangulation. So= me people may perceive that as locating the anchor in a central location (t= hough this time it's not an "absolute/unchanging" center as impli= ed in the current text).

 

Therefore I recommend the following revision:

 

   RE=
Q1:  Distributed processing
 
       =
   IP mobility, network access and routing solutions provided by<=
o:p>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic is not forced to traverse off-path<=
/span>
       =
   mobility anchors and thereby avoid non-optimal routes.

 

Alper

 

 

 

 

--_000_6E31144C030982429702B11D6746B98C370D770Bszxeml557mbxchi_-- From h.anthony.chan@huawei.com Tue Nov 5 14:31:47 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1348F21F9C90 for ; Tue, 5 Nov 2013 14:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLI5Mu77OnlA for ; Tue, 5 Nov 2013 14:31:42 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC1921F9DAA for ; Tue, 5 Nov 2013 14:31:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO72177; Tue, 05 Nov 2013 22:31:31 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 22:30:49 +0000 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Nov 2013 22:31:29 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.63]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 06:31:23 +0800 From: h chan To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt Thread-Index: AQHOogjoa3/L9muNGkS5wozrKtEQEpnXRZkQgABo14CAAJoKEIADLS4wgAAEQpCAPC2PUA== Date: Tue, 5 Nov 2013 22:31:23 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370D7725@szxeml557-mbx.china.huawei.com> References: <1377486056.79906.YahooMailNeo@web163805.mail.gq1.yahoo.com> <24C0F3E22276D9438D6F366EB89FAEA8116A4D4F@xmb-aln-x03.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.149.209] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370D7725szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 22:31:47 -0000 X-List-Received-Date: Tue, 05 Nov 2013 22:31:47 -0000 --_000_6E31144C030982429702B11D6746B98C370D7725szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable May I request anyone with any more comments or un-closed issue on the requi= rements to please speak up with suggested text changes to agree on now. I c= an do one more revision by Thursday to enable the wg to move to the next st= ep before the Friday DMM meeting. The gap analysis draft is waiting for the requirements draft to complete. And the future interesting work of this wg (including yours) are waiting fo= r the gap analysis draft to complete. H Anthony Chan From: h chan Sent: Saturday, September 28, 2013 8:28 AM To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org' Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt Sri, It appears that version 09 has attempted to address all your comments. Plea= se check. H Anthony Chan From: h chan Sent: Saturday, September 28, 2013 10:25 AM To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org' Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt Sri, We have revised the Introduction Section and PS1 in version 09. Our respons= es are in-line. The following have contributed to the above revisions in draft 09: Pierrick= , Dapeng, and Jouni From: dmm-bounces@ietf.org [mailto:dmm-bounces= @ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Sunday, August 25, 2013 10:04 PM To: dmm@ietf.org Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt Please see inline for some comments. Regards Sri ....... 4. Problem Statement The problems that can be addressed with DMM are summarized in the following: PS1: Non-optimal routes Routing via a centralized anchor often results in a longer route. [Sri] "longer route" ? I assume this is about routing/tx delay. Please re-= word. Accept and revised in version 08 The problem is manifested, for example, when accessing a local server or servers of a Content Delivery Network (CDN), or when receiving locally available IP multicast or sending IP multicast packets. [Sri] Does RFC 6705, or RFC 6909 does not address this issue ? May be the C= DN example is incorrect. RFC6909 is clarified further in the Introduction Section in version 09. (1) Mobile users are, more than ever, consuming Internet content; such traffic imposes new requirements on mobile core networks for data traffic delivery. The presence of content providers closer to Internet Service Providers (ISP) network requires taking into account local Content Delivery Networks (CDNs) while providing mobility services. Moreover, when the traffic demand exceeds available capacity, service providers need to implement new strategies such as selective IPv4 traffic offload (e.g. [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through alternative access networks (e.g. WLAN) [Paper- Mobile.Data.Offloading]. RFC6705 is clarified under PS1 in version 09 PS1: Non-optimal routes Routing via a centralized anchor often results in non-optimal routes, thereby increasing the end-to-end delay. The problem is manifested, for example, when accessing a nearby server or servers of a Content Delivery Network (CDN), or when receiving locally available IP multicast or sending IP multicast packets. (Existing route optimization is only a host-based solution. On the other hand, localized routing with PMIPv6 [RFC6705] addresses only a part of the problem where both the MN and the CN are located in the PMIP domain and attached to a MAG, and is not applicable when the CN is outside the PMIP domain or does not behave like an MN.) PS2: Divergence from other evolutionary trends in network architectures such as distribution of content delivery. Centralized mobility management can become non-optimal with a flat network architecture. [Sri] How is this making the case of DMM ? We want the MN to access content= locally in the access network and we want localized routing. We have that = in the form of 6705 and 6909. The other approach is give localized IP addre= sses and have the content locally accessed. There are simply two many consi= derations and points may be valid, but when we bring all those assumptions.= We are bringing these points in a less logical manner without stating the = assumptions. Our response is similar to that in PS1. Also PS2 is referring to flat mobil= e network. PS3: Low scalability of centralized tunnel management and mobility context maintenance Setting up tunnels through a central anchor and maintaining mobility context for each MN usually requires more concentrated resources in a centralized design, thus reducing scalability. Distributing the tunnel maintenance function and the mobility context maintenance function among different network entities with proper signaling protocol design can increase scalability. PS4: Single point of failure and attack Centralized anchoring designs may be more vulnerable to single points of failures and attacks than a distributed system. The impact of a successful attack on a system with centralized mobility management can be far greater as well. PS5: Unnecessarily reserving resources to provide mobility support to nodes that do not need such support IP mobility support is not always required, and not every parameter of mobility context is always used. For example, some applications do not need a stable IP address during a handover to maintain session continuity. Sometimes, the entire application session runs while the terminal does not change the point of attachment. Besides, some sessions, e.g. SIP-based sessions, can handle mobility at the application layer and hence do not need IP mobility support; it is then more efficient to deactivate IP mobility support for such sessions. [Sri] Mobility systems today do support the aspect of service for the subs= criber, as "Simple IP", or "Mobile IP". A PDSN can assign a local IP addres= s and it does not have to be the home address. Network does have this intel= ligence, but what is missing is the client's ability to pick the correct ty= pe of IP address, among different IP addresses. The network is also the mis= sing the aspect of marking those addresses with proper properties. The curr= ently active drafts in IETF are to address this issue. We should talk about= these missing semantics. draft-bhandari-dhc-class-based-prefix-05 draft-korhonen-6man-prefix-properties-02 These references have been added in the Introduction Section in version 09 (2) Today's mobile networks present service providers with new challenges. Mobility patterns indicate that mobile nodes often remain attached to the same point of attachment for considerable periods of time [Paper-Locating.User]. Specific IP mobility management support is not required for applications that launch and complete their sessions while the mobile node is connected to the same point of attachment. However, currently, IP mobility support is designed for always-on operation, maintaining all parameters of the context for each mobile subscriber for as long as they are connected to the network. This can result in a waste of resources and unnecessary costs for the service provider. Infrequent node mobility coupled with application intelligence suggest that mobility support could be provided selectively such as in [I-D.bhandari-dhc-class-based- prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing the amount of context maintained in the network. --_000_6E31144C030982429702B11D6746B98C370D7725szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

May I request anyone with= any more comments or un-closed issue on the requirements to please speak u= p with suggested text changes to agree on now. I can do one more revision by Thursday to enable the wg to move to the next step before the Friday DMM meeting.

 <= /p>

The gap analysis draft is= waiting for the requirements draft to complete.

 <= /p>

And the future interestin= g work of this wg (including yours) are waiting for the gap analysis draft = to complete.

 <= /p>

H Anthony Chan=

 <= /p>

From: h chan
Sent: Saturday, September 28, 2013 8:28 AM
To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

 

Sri,

It appears that version 0= 9 has attempted to address all your comments. Please check.

 <= /p>

H Anthony Chan=

 <= /p>

From: h chan
Sent: Saturday, September 28, 2013 10:25 AM
To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

 

Sri,

 <= /p>

We have revised the Intro= duction Section and PS1 in version 09. Our responses are in-line.

 <= /p>

The following have contri= buted to the above revisions in draft 09: Pierrick, Dapeng, and Jouni<= /o:p>

 <= /p>

 <= /p>

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Sunday, August 25, 2013 10:04 PM
To: dmm@ietf.org
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

 

Please see inline for some comments.

 

Regards

Sri

 

…….
 
4.  Problem St=
atement
 
   The pr=
oblems that can be addressed with DMM are summarized in the
   follow=
ing:
 
   PS1:&n=
bsp; Non-optimal routes
 
   &=
nbsp;     Routing via a centralized anchor often result=
s in a longer
   &=
nbsp;     route.  
[Sri] "longer route" ?&=
nbsp; I assume this is about routing/tx delay. Please re-word.
 
Accept and revised in=
 version 08
 
The problem is mani=
fested, for example, when accessing
   &=
nbsp;     a local server or servers of a Content Delive=
ry Network (CDN),
   &=
nbsp;     or when receiving locally available IP multic=
ast or sending IP
   &=
nbsp;     multicast packets.
 
[Sri] Does RFC 67=
05, or RFC 6909 does not address this issue ? May be the CDN example is inc=
orrect. 
 
RFC6909 is clarified =
further in the Introduction Section in version 09.  =

   (1)  Mobile users are, more than ever, c= onsuming Internet content;

        such traffic im= poses new requirements on mobile core networks

        for data traffi= c delivery.  The presence of content providers

        closer to Inter= net Service Providers (ISP) network requires

        taking into acc= ount local Content Delivery Networks (CDNs) while

        providing mobil= ity services.  Moreover, when the traffic demand

        exceeds availab= le capacity, service providers need to implement

        new strategies = such as selective IPv4 traffic offload (e.g.

        [RFC6909], 3GPP= work items LIPA/SIPTO [TS.23.401]) through

        alternative acc= ess networks (e.g.  WLAN) [Paper-

        =
Mobile.Data.Offloading].  
 =

RFC6705 is clarified=
 under PS1 in version 09

   PS1:  Non-optimal routes

 

         Routing v= ia a centralized anchor often results in non-optimal

         routes, t= hereby increasing the end-to-end delay.  The problem=

         is manife= sted, for example, when accessing a nearby server or

         servers o= f a Content Delivery Network (CDN), or when receiving

         locally a= vailable IP multicast or sending IP multicast packets.

        = (Existing route optimization is only a host-based solution.  On<= /o:p>

        = the other hand, localized routing with PMIPv6 [RFC6705]<= /p>

        = addresses only a part of the problem where both the MN and the<= /span>

        = CN are located in the PMIP domain and attached to a MAG, and is=

        = not applicable when the CN is outside the PMIP domain or does

        = not behave like an MN.)

 
 
 
   PS2:&n=
bsp; Divergence from other evolutionary trends in network=

   &=
nbsp;     architectures such as distribution of content=
 delivery.
 
   &=
nbsp;     Centralized mobility management can become no=
n-optimal with a
   &=
nbsp;     flat network architecture.<=
/pre>

 


[Sri] How is this=
 making the case of DMM ? We want the MN to access content locally in the a=
ccess network and we want localized routing. We have that in the form of 67=
05 and 6909. The other approach is give localized IP addresses and have the=
 content locally accessed. There are simply two many considerations and poi=
nts may be valid, but when we bring all those assumptions. We are bringing =
these points in a less logical manner without stating the assumptions.


 =



Our response is simi=
lar to that in PS1. Also PS2 is referring to flat mobile network. 


 


   PS3:&n=
bsp; Low scalability of centralized tunnel management and mobility


   &=
nbsp;     context maintenance


 


   &=
nbsp;     Setting up tunnels through a central anchor a=
nd maintaining


   &=
nbsp;     mobility context for each MN usually requires=
 more concentrated


   &=
nbsp;     resources in a centralized design, thus reduc=
ing scalability.


   &=
nbsp;     Distributing the tunnel maintenance function =
and the mobility


   &=
nbsp;     context maintenance function among different =
network entities


   &=
nbsp;     with proper signaling protocol design can inc=
rease scalability.


 


   PS4:&n=
bsp; Single point of failure and attack


 


   &=
nbsp;     Centralized anchoring designs may be more vul=
nerable to single


   &=
nbsp;     points of failures and attacks than a distrib=
uted system.  The


   &=
nbsp;     impact of a successful attack on a system wit=
h centralized


   &=
nbsp;     mobility management can be far greater as wel=
l.


 


   PS5:&n=
bsp; Unnecessarily reserving resources to provide mobility support


   &=
nbsp;     to nodes that do not need such support


 


   &=
nbsp;     IP mobility support is not always required, a=
nd not every


   &=
nbsp;     parameter of mobility context is always used.=
  For example,


   &=
nbsp;     some applications do not need a stable IP add=
ress during a


   &=
nbsp;     handover to maintain session continuity. =
; Sometimes, the entire


   &=
nbsp;     application session runs while the terminal d=
oes not change the


   &=
nbsp;     point of attachment.  Besides, some sess=
ions, e.g.  SIP-based


   &=
nbsp;     sessions, can handle mobility at the applicat=
ion layer and


   &=
nbsp;     hence do not need IP mobility support; it is =
then more


   &=
nbsp;     efficient to deactivate IP mobility support f=
or such sessions.


 


[Sri]  Mobility systems toda=
y do support the aspect of service for the subscriber, as "Simple IP&q=
uot;, or "Mobile IP". A PDSN can assign a local IP address and it=
 does not have to be the home address. Network does have this intelligence,=
 but what is missing is the client's ability to pick the correct type of IP=
 address, among different IP addresses. The network is also the missing the=
 aspect of marking those addresses with proper properties. The currently ac=
tive drafts in IETF are to address this issue. We should talk about these m=
issing semantics.<=
/pre>

draft-bhandari-dhc-class-based-prefix-05  


draft-korhonen-6man-prefix-properties-02<=
/span>


 


These references have=
 been added in the Introduction Section in version 09

 


   (2)  Today's mobile networks present ser=
vice providers with new


        challenges.&nbs=
p; Mobility patterns indicate that mobile nodes often


        remain attached=
 to the same point of attachment for considerable


        periods of time=
 [Paper-Locating.User].  Specific IP mobility


        management supp=
ort is not required for applications that launch


        and complete th=
eir sessions while the mobile node is connected


        to the same poi=
nt of attachment.  However, currently, IP


        mobility suppor=
t is designed for always-on operation,


        maintaining all=
 parameters of the context for each mobile


        subscriber for =
as long as they are connected to the network.


        This can result=
 in a waste of resources and unnecessary costs


        for the service=
 provider.  Infrequent node mobility coupled with

        application int=
elligence suggest that mobility support could be


        provided select=
ively
such as in [I-D.bhandari-dhc-class-based-


        prefi=
x] and [I-D.korhonen-6man-prefix-properties], thus reducing


        the amount of c=
ontext maintained in the network.


 

 

--_000_6E31144C030982429702B11D6746B98C370D7725szxeml557mbxchi_-- From alper.yegin@yegin.org Tue Nov 5 16:32:38 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F0311E8196 for ; Tue, 5 Nov 2013 16:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SLdBoNRKsFb for ; Tue, 5 Nov 2013 16:32:34 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 128F721F9D2E for ; Tue, 5 Nov 2013 16:32:34 -0800 (PST) Received: from [10.119.8.3] (178-211-44-68.turkrdns.com [178.211.44.68]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0LfTF3-1VxHl30oWn-00otvS; Tue, 05 Nov 2013 19:32:29 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_46C7146C-2F9C-4D35-8EE3-804E74A579A2" From: Alper Yegin In-Reply-To: <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> Date: Wed, 6 Nov 2013 02:32:20 +0200 Message-Id: <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org> References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:baNH7PxJ/Xso+HM8uWJpY1U50dvRI869vTlzqHMrItN LNpnqcKFQnag0ZL3oJeaRSKLHzgy6mMkbrTrlO8A1SbHsNLKBk rhjATNieC9cRjj5Ztf3HhqsNxzVWwX4Nzz1HWfVhBQYqiVrtXb OmvCIpEeclgmlQMPxwinW07MZFn/4Gkm60g0+7oMhZNovdUT8/ d006rpZiodtnUJv+14x+TjFu08/w+MZo1QqQ+L6plR8noI7xBa s+FrXaIzwi5UV7Ja1vIpN8wZerKONlWsElEGCDc97zZTtoMTnM IEV+ACBJV+9tkE3cQuJqEm0ckElasDhJaY4cHV6vuCdIcJORR0 hlffpQd7wixlZHP9pPkoi1fW48hoEWZO4Ca/pEeE5 Cc: dmm Subject: Re: [DMM] Req#1 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 00:32:39 -0000 --Apple-Mail=_46C7146C-2F9C-4D35-8EE3-804E74A579A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Works for me. Alper On Nov 6, 2013, at 12:21 AM, h chan wrote: > Is the following also acceptable: > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic can avoid traversing=20 > mobility anchors that are in non-optimal routes. > =20 > I am trying to write it in simple wording and not getting into a new = term such as =93off path=94 > H Anthony Chan > =20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Alper Yegin > Sent: Tuesday, November 05, 2013 8:25 AM > To: dmm > Subject: [DMM] Req#1 > =20 > Hello folks, > =20 > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic does not need to traverse centrally deployed > mobility anchors and thereby avoid non-optimal routes. > =20 > The real issue is not the "central location of the anchor", but = "off-path location of the anchor". > =20 > The triangular route is caused by forcing the packets to traverse an = anchor node that is not on the direct IP path between the MN and the CN. > =20 > See the CNet-Homing proposal. = http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-01.txt. We place the = anchor in corresponding network, or the ISP serving that network. = Therefore, the path going via that anchor does not cause triangulation. = Some people may perceive that as locating the anchor in a central = location (though this time it's not an "absolute/unchanging" center as = implied in the current text). > =20 > Therefore I recommend the following revision: > =20 > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic is not forced to traverse off-path > mobility anchors and thereby avoid non-optimal routes. > =20 > Alper > =20 > =20 > =20 --Apple-Mail=_46C7146C-2F9C-4D35-8EE3-804E74A579A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Works for = me.

Alper

On Nov 6, 2013, at = 12:21 AM, h chan wrote:

Is = the following also acceptable:
   REQ1:  Distributed =
processing
I am =
trying to write it in simple wording and not getting into a new term =
such as =93off path=94
H Anthony Chan
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]=  On Behalf Of Alper = Yegin
Sent: Tuesday, November 05, 2013 = 8:25 AM
To: dmm
Subject: [DMM] = Req#1
Hello = folks,
 
   REQ1:  Distributed =
processing
The real issue is not the =
"central location of the anchor", but "off-path location of the =
anchor".
The triangular route is = caused by forcing the packets to traverse an anchor node that is not on = the direct IP path between the MN and the = CN.
See the CNet-Homing = proposal. 
   REQ1:  Distributed = processing

In-Reply-To: <6E31144C030982429702B11D6746B98C370D7705@szxeml557-mbx.china.huawei.com>
Date: Wed, 6 Nov 2013 03:07:56 +0200
Message-Id: 
References: <660E41D7-7F6A-47B4-86CE-C00ECA136DA8@yegin.org> <6E31144C030982429702B11D6746B98C370D7705@szxeml557-mbx.china.huawei.com>
To: h chan 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:+PwDFaIlwkrWVAxMAdBJbOurARhcYsrsLyLRe6CIjXX 9dyUy0hlihQY1H8cFrIe8ijq7Ntkh93DT8mJO0iiWlaJzpvIX1 LC/INoZAboucAfVBCaECzZSNhgUbEV9ujl/5hz7cx/vMML8NyO wLWq0gbVSF0m9IJDke75DaObzTi89PKN/1tfJmdvtCuPDTDaBk jvLuVBd8op8Jnr1PvJdo0ufzD7puNZ0jh1i3zKqmWH2L4Y88LQ urCopAaOSmqfm0w4FemMkqZvNuJF5eq2MrduNIF+2dBRc8OwXi VoT3Xw2v1HeHOovi8WBIBg0IOWDuhJXmfpN+EMvIww081UhdFs FjU1PvmIPashaYYiDndHa3aZ6jhTVpNKTzSRMz9m1
Cc: dmm 
Subject: Re: [DMM] Requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2013 01:10:59 -0000

--Apple-Mail=_8A66DCD4-B07C-4E5A-8524-DCA1663C9DD3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Hello Anthony,



> Regarding:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
> My understanding of the intention is that it is sufficient to apply =
the existing security mechanisms/protocols to protect the DMM entities.
> Ideally, we don=92t want DMM to add new security risks.
> Yet, DMM can introduce new DMM entities, which can be vulnerable to =
security risks, and it is necessary to protect the new DMM entities.
> So we basically don=92t want DMM to introduce new security risks that =
cannot be handled with the existing security mechanisms.
> =20
> If the wording =93considered to be eliminated=94 does not clarify the =
above, how about the following:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be eliminated."
> =20
> Or, can you come up with better text prior to Friday. I am trying to =
close all requirements issues prior to the meeting on Friday to enable =
the wg to move to the next step.

I recommend we delete that sentence. It's not easy to understand. And if =
I try hard to understand, what I understand does not make sense.
It sounds like the following:
- There are already security solutions applied to =
legacy/existing/non-DMM solutions.
- Those solutions must be sufficient for securing DMM solutions.
- In other words, DMM solutions must be designed in such a way that they =
must not require any new security solutions.

That does not make sense, IMHO.
Obviously, we'd like to minimize the work. We prefer not having to =
design additional stuff to secure DMM solutions.
But we cannot mandate that.
We shall not block solutions that may require additional security =
mechanisms. We can discourage that, but not prohibit.


> =20
> Regarding your comment on the helpful references, I understand that =
there are many other individual drafts in the solution space. I did =
recently accept a prior comment to add the coloring reference. Yet now =
if we continue to respond to requests to add references to the =
individual drafts, it will not end. With the many individual drafts in =
the solution space, I hope the wg will have drafts that will =
merge/incorporate many solution drafts in future. May I now ask all the =
authors of the individual drafts to kindly wait for such future wg draft =
to consider what solutions to include/exclude?

I'm fine with that.
I saw two drafts referenced in the I-D which are complemented by two =
other drafts, hence I proposed them. It's OK if you don't add them.

Alper





> =20
> H Anthony Chan
> =20
> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
Alper Yegin
> Sent: Monday, November 04, 2013 10:20 AM
> To: dmm
> Subject: [DMM] Requirements
> =20
> Hello folks,
> =20
> Here I have two comments on this document.
> =20
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
> =20
> I don't quite understand what that means.=20
> =20
> "Infrequent node mobility coupled with
> application intelligence suggest that mobility support could be
> provided selectively such as in [I-D.bhandari-dhc-class-based-
> prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
> the amount of context maintained in the network."
> =20
> Two more related work references that are complementary to the ones =
already provided are:
> - draft-yegin-dmm-ondemand-mobility-00
> - draft-liu-dmm-mobility-api-01
> =20
> I recommend we include these references as well.
> =20
> Alper
> =20
> =20


--Apple-Mail=_8A66DCD4-B07C-4E5A-8524-DCA1663C9DD3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Hello =
Anthony,



"When the existing security =
mechanisms/protocols are
applied to protect the =
DMM entities, the security risks that
My =
understanding of the intention is that it is sufficient to apply the =
existing security mechanisms/protocols to protect the DMM =
entities.
Yet, =
DMM can introduce new DMM entities, which can be vulnerable to security =
risks, and it is necessary to protect the new DMM =
entities.
So we =
basically don=92t want DMM to introduce new security risks that cannot =
be handled with the existing security =
mechanisms.
If =
the wording =93considered to be eliminated=94 does not clarify the =
above, how about the following:
applied to protect the DMM entities, the =
security risks that
may be introduced by =
DMM MUST be eliminated."
 
Or, can you come up with better =
text prior to Friday. I am trying to close all requirements issues prior =
to the meeting on Friday to enable the wg to move to the next =
step.
H =
Anthony Chan
From: dmm-bounces@ietf.org =
[mailto:dmm-bounces@ietf.org] On Behalf Of Alper =
Yegin
Sent: Monday, November 04, 2013 =
10:20 AM
To: dmm
Subject: [DMM] =
Requirements
Hello =
folks,
Here I have two comments =
on this document.
"When the existing security =
mechanisms/protocols are
may be introduced by DMM MUST be considered =
to be eliminated."
I don't quite =
understand what that means. 
"Infrequent node =
mobility coupled with
provided selectively such as in =
[I-D.bhandari-dhc-class-based-
the amount of context =
maintained in the network."
Two more related work =
references that are complementary to the ones already provided =
are:
- =
draft-yegin-dmm-ondemand-mobility-00
I recommend we include =
these references as well.

Subject: Re: [DMM] Requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2013 01:46:59 -0000

--_000_6E31144C030982429702B11D6746B98C370D776Eszxeml557mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Alper,
The sentence in question is not in the requirement but rather one of the se=
ntences in the motivation of the requirement. When deleting that sentence, =
it affects the rest of the motivation and the requirement, which will not f=
low.

The security requirement is:
A DMM solution MUST not introduce new security risks
or amplify existing security risks
against which the existing security mechanisms/protocols
cannot offer sufficient protection.

This text was agreed upon by Byoung-Jo Kim.
Do you have problem with it? Or do you have better wording?

My understanding is that a design that increases security risks is indeed a=
 problem. Is that right?

H Anthony Chan

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, November 05, 2013 5:08 PM
To: h chan
Cc: dmm
Subject: Re: [DMM] Requirements

Hello Anthony,



Regarding:
"When the existing security mechanisms/protocols are
applied to protect the DMM entities, the security risks that
may be introduced by DMM MUST be considered to be eliminated."
My understanding of the intention is that it is sufficient to apply the exi=
sting security mechanisms/protocols to protect the DMM entities.
Ideally, we don't want DMM to add new security risks.
Yet, DMM can introduce new DMM entities, which can be vulnerable to securit=
y risks, and it is necessary to protect the new DMM entities.
So we basically don't want DMM to introduce new security risks that cannot =
be handled with the existing security mechanisms.

If the wording "considered to be eliminated" does not clarify the above, ho=
w about the following:
"When the existing security mechanisms/protocols are
applied to protect the DMM entities, the security risks that
may be introduced by DMM MUST be eliminated."

Or, can you come up with better text prior to Friday. I am trying to close =
all requirements issues prior to the meeting on Friday to enable the wg to =
move to the next step.

I recommend we delete that sentence. It's not easy to understand. And if I =
try hard to understand, what I understand does not make sense.
It sounds like the following:
- There are already security solutions applied to legacy/existing/non-DMM s=
olutions.
- Those solutions must be sufficient for securing DMM solutions.
- In other words, DMM solutions must be designed in such a way that they mu=
st not require any new security solutions.

That does not make sense, IMHO.
Obviously, we'd like to minimize the work. We prefer not having to design a=
dditional stuff to secure DMM solutions.
But we cannot mandate that.
We shall not block solutions that may require additional security mechanism=
s. We can discourage that, but not prohibit.



Regarding your comment on the helpful references, I understand that there a=
re many other individual drafts in the solution space. I did recently accep=
t a prior comment to add the coloring reference. Yet now if we continue to =
respond to requests to add references to the individual drafts, it will not=
 end. With the many individual drafts in the solution space, I hope the wg =
will have drafts that will merge/incorporate many solution drafts in future=
. May I now ask all the authors of the individual drafts to kindly wait for=
 such future wg draft to consider what solutions to include/exclude?

I'm fine with that.
I saw two drafts referenced in the I-D which are complemented by two other =
drafts, hence I proposed them. It's OK if you don't add them.

Alper







H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Alper Yegin
Sent: Monday, November 04, 2013 10:20 AM
To: dmm
Subject: [DMM] Requirements

Hello folks,

Here I have two comments on this document.

"When the existing security mechanisms/protocols are
applied to protect the DMM entities, the security risks that
may be introduced by DMM MUST be considered to be eliminated."

I don't quite understand what that means.

"Infrequent node mobility coupled with
application intelligence suggest that mobility support could be
provided selectively such as in [I-D.bhandari-dhc-class-based-
prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
the amount of context maintained in the network."

Two more related work references that are complementary to the ones already=
 provided are:
- draft-yegin-dmm-ondemand-mobility-00
- draft-liu-dmm-mobility-api-01

I recommend we include these references as well.

Alper




--_000_6E31144C030982429702B11D6746B98C370D776Eszxeml557mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Alper,<=
/p>

The sentence in question =
is not in the requirement but rather one of the sentences in the motivation=
 of the requirement. When deleting that sentence, it affects
 the rest of the motivation and the requirement, which will not flow. =



 <=
/p>

The security requirement =
is:


A DMM solution MUST not intr=
oduce new security risks



or amplify existing security=
 risks



against which the existing s=
ecurity mechanisms/protocols


cannot offer sufficient prot=
ection.



 <=
/p>

This text was agreed upon=
 by Byoung-Jo Kim.



Do you have problem with =
it? Or do you have better wording?


 <=
/p>

My understanding is that =
a design that increases security risks is indeed a problem. Is that right?<=
o:p>


 <=
/p>



H Anthony Chan=





 <=
/p>





From: Alper Ye=
gin [mailto:alper.yegin@yegin.org]


Sent: Tuesday, November 05, 2013 5:08 PM

To: h chan

Cc: dmm

Subject: Re: [DMM] Requirements






 


Hello Anthony,




 






 






 














Regarding:






=
"When the existing security mechanisms/protocols are=







=
applied to protect the DMM entities, the security risks that






=
may be introduced by DMM MUST be considered to be eliminated."<=
o:p>






My understanding of the i=
ntention is that it is sufficient to apply the existing security mechanisms=
/protocols to protect the DMM entities.






Ideally, we don’t w=
ant DMM to add new security risks.






Yet, DMM can introduce ne=
w DMM entities, which can be vulnerable to security risks, and it is necess=
ary to protect the new DMM entities.








So we basically don’=
;t want DMM to introduce new security risks that cannot be handled with the=
 existing security mechanisms.






 <=
/p>





If the wording “con=
sidered to be eliminated” does not clarify the above, how about the f=
ollowing:






=
"When the existing security mechanisms/protocols are=







=
applied to protect the DMM entities, the security risks that






=
may be introduced by DMM MUST be eliminated."






 <=
/p>





Or, can you come up with =
better text prior to Friday. I am trying to close all requirements issues p=
rior to the meeting on Friday to enable the wg to move to
 the next step.












 






I recommend we delete that sentence. It's not easy t=
o understand. And if I try hard to understand, what I understand does not m=
ake sense.






It sounds like the following:






- There are already security solutions applied to le=
gacy/existing/non-DMM solutions.






- Those solutions must be sufficient for securing DM=
M solutions.






- In other words, DMM solutions must be designed in =
such a way that they must not require any new security solutions.






 






That does not make sense, IMHO.






Obviously, we'd like to minimize the work. We prefer=
 not having to design additional stuff to secure DMM solutions.<=
/p>





But we cannot mandate that.






We shall not block solutions that may require additi=
onal security mechanisms. We can discourage that, but not prohibit.






 






 












 <=
/p>





Regarding your comment on=
 the helpful references, I understand that there are many other individual =
drafts in the solution space. I did recently accept a prior
 comment to add the coloring reference. Yet now if we continue to respond t=
o requests to add references to the individual drafts, it will not end. Wit=
h the many individual drafts in the solution space, I hope the wg will have=
 drafts that will merge/incorporate
 many solution drafts in future. May I now ask all the authors of the indiv=
idual drafts to kindly wait for such future wg draft to consider what solut=
ions to include/exclude?












 






I'm fine with that.






I saw two drafts referenced in the I-D which are com=
plemented by two other drafts, hence I proposed them. It's OK if you don't =
add them.






 






Alper






 






 






 






 

















 <=
/p>





H Anthony Chan








 <=
/p>









From: dmm-bounces@ietf.org
 [mailto:dmm-bounces@ietf.org]<=
span class=3D"apple-converted-space"> On Behalf Of Alper Yegin

Sent: Monday, Nove=
mber 04, 2013 10:20 AM

To: dmm

Subject: [DMM] Req=
uirements










 






Hello folks,








 










Here I have two comments on this document.










 












=
"When the existing security mechanisms/protocols are=











=
applied to protect the DMM entities, the security risks that










=
may be introduced by DMM MUST be considered to be eliminated."<=
o:p>












=
 










=
I don't quite understand what that means. 










=
 












=
"Infrequent node mobility coupled with










=
application intelligence suggest that mobility support could be=











=
provided selectively such as in [I-D.bhandari-dhc-class-based-<=
/o:p>










=
prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing










=
the amount of context maintained in the network."









=
 










=
Two more related work references that are complementary to the ones already=
 provided are:










=
- draft-yegin-dmm-ondemand-mobility-00










=
- draft-liu-dmm-mobility-api-01










=
 










=
I recommend we include these references as well.










=
 










=
Alper










=
 










=
 












 








--_000_6E31144C030982429702B11D6746B98C370D776Eszxeml557mbxchi_--

From h.anthony.chan@huawei.com  Tue Nov  5 18:01:50 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B1011E8163 for ; Tue,  5 Nov 2013 18:01:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7IR41N6Zrxx for ; Tue,  5 Nov 2013 18:01:45 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1921F9FF6 for ; Tue,  5 Nov 2013 18:01:42 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO81307; Wed, 06 Nov 2013 02:01:41 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 02:01:03 +0000
Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 02:01:40 +0000
Received: from szxeml557-mbx.china.huawei.com ([169.254.5.63]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 10:01:33 +0800
From: h chan 
To: Alper Yegin 
Thread-Topic: [DMM] Req#1
Thread-Index: AQHO2oeyjSxSFhMWSkWymCmvo/2qTJoXcDUA
Date: Wed, 6 Nov 2013 02:01:31 +0000
Message-ID: <6E31144C030982429702B11D6746B98C370D7785@szxeml557-mbx.china.huawei.com>
References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org>
In-Reply-To: <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.128.47]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370D7785szxeml557mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: dmm 
Subject: Re: [DMM] Req#1
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2013 02:01:50 -0000

--_000_6E31144C030982429702B11D6746B98C370D7785szxeml557mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Alper

I check the draft again. The draft does talk about distributed mobility man=
agement versus centralized mobility management. Dropping "centralized ancho=
rs" entirely in the requirement is going to produce a domino effect in othe=
r places.

Now I think an alternative is to say that only those centralized anchors th=
at are not in non-optimal route are an issue.


   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid traversing centrally deployed

          mobility anchors when such anchors are in non-optimal routes.

That means you have no problem of using centralized anchors as long as they=
 are not in non-optimal routes. That should also accommodate your proposed =
solution. Are you okay with this compromised wording.

H Anthony Chan

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, November 05, 2013 4:32 PM
To: h chan
Cc: dmm
Subject: Re: [DMM] Req#1

Works for me.

Alper

On Nov 6, 2013, at 12:21 AM, h chan wrote:


Is the following also acceptable:

   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid traversing

          mobility anchors that are in non-optimal routes.

I am trying to write it in simple wording and not getting into a new term s=
uch as "off path"
H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Alper Yegin
Sent: Tuesday, November 05, 2013 8:25 AM
To: dmm
Subject: [DMM] Req#1


Hello folks,



   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic does not need to traverse centrally deployed

          mobility anchors and thereby avoid non-optimal routes.

The real issue is not the "central location of the anchor", but "off-path l=
ocation of the anchor".

The triangular route is caused by forcing the packets to traverse an anchor=
 node that is not on the direct IP path between the MN and the CN.

See the CNet-Homing proposal. http://www.ietf.org/id/draft-yegin-dmm-cnet-h=
oming-01.txt. We place the anchor in corresponding network, or the ISP serv=
ing that network. Therefore, the path going via that anchor does not cause =
triangulation. Some people may perceive that as locating the anchor in a ce=
ntral location (though this time it's not an "absolute/unchanging" center a=
s implied in the current text).

Therefore I recommend the following revision:


   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic is not forced to traverse off-path

          mobility anchors and thereby avoid non-optimal routes.

Alper





--_000_6E31144C030982429702B11D6746B98C370D7785szxeml557mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Alper

 <=
/p>

I check the draft again. =
The draft does talk about distributed mobility management versus centralize=
d mobility management. Dropping “centralized anchors” entirely
 in the requirement is going to produce a domino effect in other places. 


 <=
/p>

Now I think an alternativ=
e is to say that only those centralized anchors that are not in non-optimal=
 route are an issue.



 <=
/p>

   REQ1:  Distributed proce=
ssing


 


        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid traversing centrally deployed=



       =
   mobility anchors when such anchors are in non-optimal rou=
tes.


 <=
/p>

That means you have no pr=
oblem of using centralized anchors as long as they are not in non-optimal r=
outes. That should also accommodate your proposed solution.
 Are you okay with this compromised wording.


 <=
/p>



H Anthony Chan=





 <=
/p>





From: Alper Ye=
gin [mailto:alper.yegin@yegin.org]


Sent: Tuesday, November 05, 2013 4:32 PM

To: h chan

Cc: dmm

Subject: Re: [DMM] Req#1






 


Works for me.




 






Alper






 






On Nov 6, 2013, at 12:21 AM, h chan wrote:















Is the following also acc=
eptable:




   REQ1:  Distributed proce=
ssing


 


        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid traversing 


       =
   mobility anchors that are in non-optimal routes.




 <=
/p>







I am trying to write it i=
n simple wording and not getting into a new term such as “off path=
221;






H Anthony Chan








 <=
/p>









From: dmm-bounces@ietf.org [mailto:d=
mm-bounces@ietf.org] =
On
 Behalf Of Alper Yegi=
n

Sent: Tuesday, Nov=
ember 05, 2013 8:25 AM

To: dmm

Subject: [DMM] Req=
#1










 




Hello folks,


 


   RE=
Q1:  Distributed processing


 


        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic does not need to traverse centrally deployed


       =
   mobility anchors and thereby avoid non-optimal routes.<=
o:p>






 










The real issue is not the "central location of =
the anchor", but "off-path location of the anchor".










 










The triangular route is caused by forcing the packet=
s to traverse an anchor node that is not on the direct IP path between the =
MN and the CN.










 










See the CNet-Homing proposal. http://www.ietf.org/id=
/draft-yegin-dmm-cnet-homing-01.txt. We place the anchor in correspondi=
ng network, or the ISP serving that network.
 Therefore, the path going via that anchor does not cause triangulation. So=
me people may perceive that as locating the anchor in a central location (t=
hough this time it's not an "absolute/unchanging" center as impli=
ed in the current text).










 










Therefore I recommend the following revision:










 








   RE=
Q1:  Distributed processing


 


       =
   IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic is not forced to traverse off-path=



       =
   mobility anchors and thereby avoid non-optimal routes.<=
o:p>






 












Alper










 










 










 










 








--_000_6E31144C030982429702B11D6746B98C370D7785szxeml557mbxchi_--

From alper.yegin@yegin.org  Tue Nov  5 18:19:15 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8674811E81EC for ; Tue,  5 Nov 2013 18:19:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mh2HtdQt1DJE for ; Tue,  5 Nov 2013 18:19:10 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0A07011E81D3 for ; Tue,  5 Nov 2013 18:19:06 -0800 (PST)
Received: from [10.119.8.3] (178-211-44-68.turkrdns.com [178.211.44.68]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LaXQt-1W3HiA3lXD-00mFos; Tue, 05 Nov 2013 21:19:03 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E208AC28-F52B-4F84-A662-BF6CB6EDB055"
From: Alper Yegin 
In-Reply-To: <6E31144C030982429702B11D6746B98C370D7785@szxeml557-mbx.china.huawei.com>
Date: Wed, 6 Nov 2013 04:18:58 +0200
Message-Id: 
References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org> <6E31144C030982429702B11D6746B98C370D7785@szxeml557-mbx.china.huawei.com>
To: h chan 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:0CarUqgUCm6YzeoYQVKdlsDe3/V7h7WlIQpntlnI7Ky R1LbCk71FU7Fo8KMk46PwtyycGeM670VoqeXM0HSYf5yJ4gc9h WhWo5mtJBX+matXHVWGwJ86hW0PN/wi9Il+rJ1rGNDBsDY++K2 I7tzr0HoOh0eaThfyhSdwZbh2N666gegyeuG28uIdY8y255Ten ujUsZ0sZDnk3NzHfynveefRpoVhs+H9v/GH7pCztGa5bcJ1JEt 0iOic74h7sNcqxA+eFhlDg6vmH7gf937dzO+yG8GPa7vUyGV4S kXaSSueANp3H4X1faynRGQYWpCbzAT6TZTIG/uvT7pSl7ejbsE pFXXK6NOj7Xrpo217QGoF+i4R2TThcXI9wOdWaepT
Cc: dmm 
Subject: Re: [DMM] Req#1
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2013 02:19:15 -0000

--Apple-Mail=_E208AC28-F52B-4F84-A662-BF6CB6EDB055
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Anthony,

The harmful type of "centralized" anchor is the one that is in =
single/fixed location typically far from the MN, which naturally causes =
sub-optimal route for most, if not all, end2end data-paths.
That's what we are trying to avoid with the DMM solutions.
Though, it'd take considerable effort to elaborate on that in the I-D at =
this 11th hour.
So, instead, let's go with your text. It's sufficient.

Alper




On Nov 6, 2013, at 4:01 AM, h chan wrote:

> Alper
> =20
> I check the draft again. The draft does talk about distributed =
mobility management versus centralized mobility management. Dropping =
=93centralized anchors=94 entirely in the requirement is going to =
produce a domino effect in other places.
> =20
> Now I think an alternative is to say that only those centralized =
anchors that are not in non-optimal route are an issue.
> =20
>    REQ1:  Distributed processing
> =20
>           IP mobility, network access and routing solutions provided =
by
>           DMM MUST enable distributed processing for mobility =
management
>           so that traffic can avoid traversing centrally deployed
>           mobility anchors when such anchors are in non-optimal =
routes.
> =20
> That means you have no problem of using centralized anchors as long as =
they are not in non-optimal routes. That should also accommodate your =
proposed solution. Are you okay with this compromised wording.
> =20
> H Anthony Chan
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Tuesday, November 05, 2013 4:32 PM
> To: h chan
> Cc: dmm
> Subject: Re: [DMM] Req#1
> =20
> Works for me.
> =20
> Alper
> =20
> On Nov 6, 2013, at 12:21 AM, h chan wrote:
>=20
>=20
> Is the following also acceptable:
>    REQ1:  Distributed processing
> =20
>           IP mobility, network access and routing solutions provided =
by
>           DMM MUST enable distributed processing for mobility =
management
>           so that traffic can avoid traversing=20
>           mobility anchors that are in non-optimal routes.
> =20
> I am trying to write it in simple wording and not getting into a new =
term such as =93off path=94
> H Anthony Chan
> =20
> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
Alper Yegin
> Sent: Tuesday, November 05, 2013 8:25 AM
> To: dmm
> Subject: [DMM] Req#1
> =20
> Hello folks,
> =20
>    REQ1:  Distributed processing
> =20
>           IP mobility, network access and routing solutions provided =
by
>           DMM MUST enable distributed processing for mobility =
management
>           so that traffic does not need to traverse centrally deployed
>           mobility anchors and thereby avoid non-optimal routes.
> =20
> The real issue is not the "central location of the anchor", but =
"off-path location of the anchor".
> =20
> The triangular route is caused by forcing the packets to traverse an =
anchor node that is not on the direct IP path between the MN and the CN.
> =20
> See the CNet-Homing proposal. =
http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-01.txt. We place the =
anchor in corresponding network, or the ISP serving that network. =
Therefore, the path going via that anchor does not cause triangulation. =
Some people may perceive that as locating the anchor in a central =
location (though this time it's not an "absolute/unchanging" center as =
implied in the current text).
> =20
> Therefore I recommend the following revision:
> =20
>    REQ1:  Distributed processing
> =20
>           IP mobility, network access and routing solutions provided =
by
>           DMM MUST enable distributed processing for mobility =
management
>           so that traffic is not forced to traverse off-path
>           mobility anchors and thereby avoid non-optimal routes.
> =20
> Alper
> =20
> =20
> =20


--Apple-Mail=_E208AC28-F52B-4F84-A662-BF6CB6EDB055
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Anthony,

The harmful type of =
"centralized" anchor is the one that is in single/fixed location =
typically far from the MN, which naturally causes sub-optimal route for =
most, if not all, end2end data-paths.
That's what we are =
trying to avoid with the DMM solutions.
Though, it'd take =
considerable effort to elaborate on that in the I-D at this 11th =
hour.
So, instead, let's go with your text. It's =
sufficient.

Alper




On Nov 6, 2013, at 4:01 AM, h chan =
wrote:

I =
check the draft again. The draft does talk about distributed mobility =
management versus centralized mobility management. Dropping =93centralized=
 anchors=94 entirely in the requirement is going to produce a domino =
effect in other places.
 
Now I think an alternative is to =
say that only those centralized anchors that are not in non-optimal =
route are an issue.
 
   REQ1:  Distributed =
processing
That =
means you have no problem of using centralized anchors as long as they =
are not in non-optimal routes. That should also accommodate your =
proposed solution. Are you okay with this compromised =
wording.
H =
Anthony Chan
From: Alper Yegin =
[mailto:alper.yegin@yegin.org] 
Sent: Tuesday, November 05, 2013 =
4:32 PM
To: h =
chan
Cc: dmm
Subject: Re: [DMM] =
Req#1
Works for =
me.
On Nov 6, 2013, at 12:21 =
AM, h chan wrote:
Is =
the following also acceptable:
   REQ1:  Distributed =
processing
I am trying to write it in simple wording and not =
getting into a new term such as =93off =
path=94
H =
Anthony Chan
 [mailto:dmm-bounces@ietf.org] On Behalf Of Alper =
Yegin
Sent: Tuesday, November 05, 2013 =
8:25 AM
To: dmm
Subject: [DMM] =
Req#1
 
Hello folks,
   REQ1:  Distributed =
processing
The real issue =
is not the "central location of the anchor", but "off-path location of =
the anchor".
 
The triangular route is caused by forcing the packets =
to traverse an anchor node that is not on the direct IP path between the =
MN and the CN.
 
See the CNet-Homing proposal. 
Alper

In-Reply-To: <6E31144C030982429702B11D6746B98C370D776E@szxeml557-mbx.china.huawei.com> Date: Wed, 6 Nov 2013 04:31:37 +0200 Message-Id: <101C778B-D174-40D6-BA06-54AC51B97A32@yegin.org> References: <660E41D7-7F6A-47B4-86CE-C00ECA136DA8@yegin.org> <6E31144C030982429702B11D6746B98C370D7705@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C370D776E@szxeml557-mbx.china.huawei.com> To: h chan X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:B3CT1tc7wYoBlikANg202CJKuCiP9CeJCrKwTkJy5fa bQLB8ZG8Ryi2oIzKv1mIV2V+eZqX28VqjRg2+H5VZBWvj36oZQ C9KOQh3RKQ+9KP1E7PcG5rwlT5d8oicIeBpZ6pPWLk3eXs/dhG +CXoFfrvtBiSlc7U+zmT7zQqZ3/uBrSwqwe3pNFaI/xcdpfc0R AmK7w6TKqJAshMuiD4eUlE/wn/AfsStf7lciXfYefNcWkTwntX 2YYBGq8D3wH5QNht7g17PTK7XyhtDbxgOP1Imr/y259QPwEEcQ pI4SCDIzJ+4SDX6QBOIgg3QNj3QD8cd5BQc7JDTAWYb20nhrCC ZmtycTrPcO5vxqvOzFRghhYoRyRurepgCrtZ3eTgS Cc: dmm Subject: Re: [DMM] Requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 02:31:59 -0000 --Apple-Mail=_35DD3948-4B52-4B62-9F66-4F35CBB94EE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Anthony, > Alper, > The sentence in question is not in the requirement but rather one of = the sentences in the motivation of the requirement. Unfortunately it's using normative language. Hence it reads like a = requirement.=20 When the existing security mechanisms/protocols are applied to protect = the DMM entities, the security risks that may be introduced by DMM MUST = be considered to be eliminated. [1] > When deleting that sentence, it affects the rest of the motivation and = the requirement, which will not flow. > =20 > The security requirement is: > [2] A DMM solution MUST not introduce new security risks > or amplify existing security risks > against which the existing security mechanisms/protocols > cannot offer sufficient protection. > =20 This is a good requirement. We shall keep that. No problem with that. My problem was with another statement ([1]) > This text was agreed upon by Byoung-Jo Kim. > Do you have problem with it? Or do you have better wording? > =20 > My understanding is that a design that increases security risks is = indeed a problem. Is that right? > =20 No problem with [2]. [1] seems to be broken, like I explained.=20 Alper > H Anthony Chan > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Tuesday, November 05, 2013 5:08 PM > To: h chan > Cc: dmm > Subject: Re: [DMM] Requirements > =20 > Hello Anthony, > =20 > =20 > =20 > Regarding: > "When the existing security mechanisms/protocols are > applied to protect the DMM entities, the security risks that > may be introduced by DMM MUST be considered to be eliminated." > My understanding of the intention is that it is sufficient to apply = the existing security mechanisms/protocols to protect the DMM entities. > Ideally, we don=92t want DMM to add new security risks. > Yet, DMM can introduce new DMM entities, which can be vulnerable to = security risks, and it is necessary to protect the new DMM entities. > So we basically don=92t want DMM to introduce new security risks that = cannot be handled with the existing security mechanisms. > =20 > If the wording =93considered to be eliminated=94 does not clarify the = above, how about the following: > "When the existing security mechanisms/protocols are > applied to protect the DMM entities, the security risks that > may be introduced by DMM MUST be eliminated." > =20 > Or, can you come up with better text prior to Friday. I am trying to = close all requirements issues prior to the meeting on Friday to enable = the wg to move to the next step. > =20 > I recommend we delete that sentence. It's not easy to understand. And = if I try hard to understand, what I understand does not make sense. > It sounds like the following: > - There are already security solutions applied to = legacy/existing/non-DMM solutions. > - Those solutions must be sufficient for securing DMM solutions. > - In other words, DMM solutions must be designed in such a way that = they must not require any new security solutions. > =20 > That does not make sense, IMHO. > Obviously, we'd like to minimize the work. We prefer not having to = design additional stuff to secure DMM solutions. > But we cannot mandate that. > We shall not block solutions that may require additional security = mechanisms. We can discourage that, but not prohibit. > =20 > =20 > =20 > Regarding your comment on the helpful references, I understand that = there are many other individual drafts in the solution space. I did = recently accept a prior comment to add the coloring reference. Yet now = if we continue to respond to requests to add references to the = individual drafts, it will not end. With the many individual drafts in = the solution space, I hope the wg will have drafts that will = merge/incorporate many solution drafts in future. May I now ask all the = authors of the individual drafts to kindly wait for such future wg draft = to consider what solutions to include/exclude? > =20 > I'm fine with that. > I saw two drafts referenced in the I-D which are complemented by two = other drafts, hence I proposed them. It's OK if you don't add them. > =20 > Alper > =20 > =20 > =20 > =20 >=20 >=20 > =20 > H Anthony Chan > =20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Alper Yegin > Sent: Monday, November 04, 2013 10:20 AM > To: dmm > Subject: [DMM] Requirements > =20 > Hello folks, > =20 > Here I have two comments on this document. > =20 > "When the existing security mechanisms/protocols are > applied to protect the DMM entities, the security risks that > may be introduced by DMM MUST be considered to be eliminated." > =20 > I don't quite understand what that means.=20 > =20 > "Infrequent node mobility coupled with > application intelligence suggest that mobility support could be > provided selectively such as in [I-D.bhandari-dhc-class-based- > prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing > the amount of context maintained in the network." > =20 > Two more related work references that are complementary to the ones = already provided are: > - draft-yegin-dmm-ondemand-mobility-00 > - draft-liu-dmm-mobility-api-01 > =20 > I recommend we include these references as well. > =20 > Alper > =20 > =20 --Apple-Mail=_35DD3948-4B52-4B62-9F66-4F35CBB94EE0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Anthony,




The = sentence in question is not in the requirement but rather one of the = sentences in the motivation of the requirement. =

Unfortuna= tely it's using normative language. Hence it reads like a = requirement. 

 When the existing security mechanisms/protocols are = applied to protect the DMM entities, the = security risks that may be introduced by DMM MUST be considered = to be eliminated. [1]



When = deleting that sentence, it affects the rest of the motivation and the = requirement, which will not flow.
The = security requirement is:
[2] A DMM = solution MUST not introduce new security = risks
or amplify existing security = risks
against which the existing security = mechanisms/protocols
cannot offer = sufficient protection.
This text was agreed upon by = Byoung-Jo Kim.
Do = you have problem with it? Or do you have better = wording?
My understanding is that a design = that increases security risks is indeed a problem. Is that = right?
H = Anthony Chan
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Tuesday, November 05, 2013 = 5:08 PM
To: h = chan
Cc: dmm
Subject: Re: [DMM] = Requirements
Hello = Anthony,
"When the existing = security mechanisms/protocols are
may be introduced by DMM MUST be considered = to be eliminated."
My understanding of the intention = is that it is sufficient to apply the existing security = mechanisms/protocols to protect the DMM = entities.
Ideally, we don=92t want DMM to add new security = risks.
Yet, = DMM can introduce new DMM entities, which can be vulnerable to security = risks, and it is necessary to protect the new DMM = entities.
So we basically don=92t want DMM to introduce new = security risks that cannot be handled with the existing security = mechanisms.
 
If the wording =93considered to = be eliminated=94 does not clarify the above, how about the = following:
"When the existing = security mechanisms/protocols are
may be introduced by DMM MUST be = eliminated."
 
Or, can you come up with better = text prior to Friday. I am trying to close all requirements issues prior = to the meeting on Friday to enable the wg to move to the next = step.
 
I recommend we delete that sentence. It's not easy to = understand. And if I try hard to understand, what I understand does not = make sense.
It sounds like the = following:
- There are already = security solutions applied to legacy/existing/non-DMM = solutions.
- Those solutions must be = sufficient for securing DMM solutions.
- In other words, DMM solutions must be designed in = such a way that they must not require any new security = solutions.
That does not make sense, = IMHO.
Obviously, we'd like to = minimize the work. We prefer not having to design additional stuff to = secure DMM solutions.
But we cannot = mandate that.
We shall not block = solutions that may require additional security mechanisms. We can = discourage that, but not prohibit.
 
 
Regarding your comment on the helpful references, I = understand that there are many other individual drafts in the solution = space. I did recently accept a prior comment to add the coloring = reference. Yet now if we continue to respond to requests to add = references to the individual drafts, it will not end. With the many = individual drafts in the solution space, I hope the wg will have drafts = that will merge/incorporate many solution drafts in future. May I now = ask all the authors of the individual drafts to kindly wait for such = future wg draft to consider what solutions to = include/exclude?
 
I'm fine with that.
I saw two drafts referenced in the I-D which are = complemented by two other drafts, hence I proposed them. It's OK if you = don't add them.
H Anthony = Chan
 [mailto:dmm-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Monday, November 04, 2013 = 10:20 AM
To: dmm
Subject: [DMM] = Requirements
 
Hello folks,
 
Here I have two comments on this = document.
applied to protect the = DMM entities, the security risks = that
provided selectively = such as in = [I-D.bhandari-dhc-class-based-
Subject: Re: [DMM] Requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 02:47:42 -0000 --_000_6E31144C030982429702B11D6746B98C370D77CDszxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on, may be launched in a DMM deployment. For instance, an illegitimate node may attempt to access a network providing DMM. Another example is that a malicious node can forge a number of signaling messages thus redirecting traffic from its legitimate path. Consequently, the specific node is under a denial of service attack, whereas other nodes do not receive their traffic. Accordingly, security mechanisms/protocols providing access control, integrity, authentication, authorization, confidentiality, etc. can be used to protect the DMM entities as they are already used to protect against existing networks and existing mobility protocols defined in IETF. H Anthony Chan From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, November 05, 2013 6:32 PM To: h chan Cc: dmm Subject: Re: [DMM] Requirements Anthony, Alper, The sentence in question is not in the requirement but rather one of the se= ntences in the motivation of the requirement. Unfortunately it's using normative language. Hence it reads like a requirem= ent. When the existing security mechanisms/protocols are applied to protect the= DMM entities, the security risks that may be introduced by DMM MUST be con= sidered to be eliminated. [1] When deleting that sentence, it affects the rest of the motivation and the = requirement, which will not flow. The security requirement is: [2] A DMM solution MUST not introduce new security risks or amplify existing security risks against which the existing security mechanisms/protocols cannot offer sufficient protection. This is a good requirement. We shall keep that. No problem with that. My problem was with another statement ([1]) This text was agreed upon by Byoung-Jo Kim. Do you have problem with it? Or do you have better wording? My understanding is that a design that increases security risks is indeed a= problem. Is that right? No problem with [2]. [1] seems to be broken, like I explained. Alper H Anthony Chan From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, November 05, 2013 5:08 PM To: h chan Cc: dmm Subject: Re: [DMM] Requirements Hello Anthony, Regarding: "When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be considered to be eliminated." My understanding of the intention is that it is sufficient to apply the exi= sting security mechanisms/protocols to protect the DMM entities. Ideally, we don't want DMM to add new security risks. Yet, DMM can introduce new DMM entities, which can be vulnerable to securit= y risks, and it is necessary to protect the new DMM entities. So we basically don't want DMM to introduce new security risks that cannot = be handled with the existing security mechanisms. If the wording "considered to be eliminated" does not clarify the above, ho= w about the following: "When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be eliminated." Or, can you come up with better text prior to Friday. I am trying to close = all requirements issues prior to the meeting on Friday to enable the wg to = move to the next step. I recommend we delete that sentence. It's not easy to understand. And if I = try hard to understand, what I understand does not make sense. It sounds like the following: - There are already security solutions applied to legacy/existing/non-DMM s= olutions. - Those solutions must be sufficient for securing DMM solutions. - In other words, DMM solutions must be designed in such a way that they mu= st not require any new security solutions. That does not make sense, IMHO. Obviously, we'd like to minimize the work. We prefer not having to design a= dditional stuff to secure DMM solutions. But we cannot mandate that. We shall not block solutions that may require additional security mechanism= s. We can discourage that, but not prohibit. Regarding your comment on the helpful references, I understand that there a= re many other individual drafts in the solution space. I did recently accep= t a prior comment to add the coloring reference. Yet now if we continue to = respond to requests to add references to the individual drafts, it will not= end. With the many individual drafts in the solution space, I hope the wg = will have drafts that will merge/incorporate many solution drafts in future= . May I now ask all the authors of the individual drafts to kindly wait for= such future wg draft to consider what solutions to include/exclude? I'm fine with that. I saw two drafts referenced in the I-D which are complemented by two other = drafts, hence I proposed them. It's OK if you don't add them. Alper H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces= @ietf.org] On Behalf Of Alper Yegin Sent: Monday, November 04, 2013 10:20 AM To: dmm Subject: [DMM] Requirements Hello folks, Here I have two comments on this document. "When the existing security mechanisms/protocols are applied to protect the DMM entities, the security risks that may be introduced by DMM MUST be considered to be eliminated." I don't quite understand what that means. "Infrequent node mobility coupled with application intelligence suggest that mobility support could be provided selectively such as in [I-D.bhandari-dhc-class-based- prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing the amount of context maintained in the network." Two more related work references that are complementary to the ones already= provided are: - draft-yegin-dmm-ondemand-mobility-00 - draft-liu-dmm-mobility-api-01 I recommend we include these references as well. Alper --_000_6E31144C030982429702B11D6746B98C370D77CDszxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Motivation:

Various attacks such as impe= rsonation, denial of service,

man-in-the-middle attacks, a= nd so on,

may be launched in a DMM dep= loyment.

For instance,

an illegitimate node

may attempt to access a netw= ork providing DMM.

Another example is that

a malicious node can forge a= number of signaling messages

thus redirecting traffic fro= m its legitimate path.

Consequently,

the specific node is under a= denial of service attack,

whereas other nodes do not r= eceive their traffic.

Accordingly,

security mechanisms/protocol= s providing access control,

integrity, authentication, a= uthorization,

confidentiality, etc.

can be used to protect the D= MM entities

as they are already used to = protect

against existing networks

and existing mobility protoc= ols defined in IETF.

 <= /p>

 <= /p>

H Anthony Chan=

 <= /p>

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, November 05, 2013 6:32 PM
To: h chan
Cc: dmm
Subject: Re: [DMM] Requirements

 

Anthony,

 

 

 

Alper,<= /p>

The sentence in question = is not in the requirement but rather one of the sentences in the motivation= of the requirement.

 

Unfortunately it's using normative language. Hence i= t reads like a requirement. 

 

 When the existing security mechani= sms/protocols are applied to protect the DMM entities, the security risks t= hat may be introduced by DMM MUST be considered to be eliminated. [1]

=

 



When deleting that senten= ce, it affects the rest of the motivation and the requirement, which will n= ot flow.

 <= /p>

The security requirement = is:

[2] A DMM solution MUST not introduce new security risks

or amplify existing security risks

against which the existing security mechanisms/protocols

cannot offer sufficient protection.

 <= /p>

 

This is a good requirement. We shall keep that. No p= roblem with that.

 

My problem was with another statement ([1])

 

 



This text was agreed upon= by Byoung-Jo Kim.

Do you have problem with = it? Or do you have better wording?

 <= /p>

My understanding is that = a design that increases security risks is indeed a problem. Is that right?<= /span>

 <= /p>

 

 

No problem with [2].

 

[1] seems to be broken, like I explained. =

 

Alper

 

 

 



H Anthony Chan

 <= /p>

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Tuesday, Nov= ember 05, 2013 5:08 PM
To: h chan
Cc: dmm
Subject: Re: [DMM]= Requirements

 

Hello Anthony,

 

 

 

Regarding:

= "When the existing security mechanisms/protocols are=

= applied to protect the DMM entities, the security risks that

= may be introduced by DMM MUST be considered to be eliminated."<= o:p>

My understanding of the i= ntention is that it is sufficient to apply the existing security mechanisms= /protocols to protect the DMM entities.

Ideally, we don’t w= ant DMM to add new security risks.

Yet, DMM can introduce ne= w DMM entities, which can be vulnerable to security risks, and it is necess= ary to protect the new DMM entities.

So we basically don’= ;t want DMM to introduce new security risks that cannot be handled with the= existing security mechanisms.

 <= /p>

If the wording “con= sidered to be eliminated” does not clarify the above, how about the f= ollowing:

= "When the existing security mechanisms/protocols are=

= applied to protect the DMM entities, the security risks that

= may be introduced by DMM MUST be eliminated."

 <= /p>

Or, can you come up with = better text prior to Friday. I am trying to close all requirements issues p= rior to the meeting on Friday to enable the wg to move to the next step.

 

I recommend we delete that sentence. It's not easy t= o understand. And if I try hard to understand, what I understand does not m= ake sense.

It sounds like the following:

- There are already security solutions applied to le= gacy/existing/non-DMM solutions.

- Those solutions must be sufficient for securing DM= M solutions.

- In other words, DMM solutions must be designed in = such a way that they must not require any new security solutions.

 

That does not make sense, IMHO.

Obviously, we'd like to minimize the work. We prefer= not having to design additional stuff to secure DMM solutions.<= /p>

But we cannot mandate that.

We shall not block solutions that may require additi= onal security mechanisms. We can discourage that, but not prohibit.

 

 

 <= /p>

Regarding your comment on= the helpful references, I understand that there are many other individual = drafts in the solution space. I did recently accept a prior comment to add the coloring reference. Yet now if we continue to respond t= o requests to add references to the individual drafts, it will not end. Wit= h the many individual drafts in the solution space, I hope the wg will have= drafts that will merge/incorporate many solution drafts in future. May I now ask all the authors of the indiv= idual drafts to kindly wait for such future wg draft to consider what solut= ions to include/exclude?

 

I'm fine with that.

I saw two drafts referenced in the I-D which are com= plemented by two other drafts, hence I proposed them. It's OK if you don't = add them.

 

Alper

 

 

 

 




 <= /p>

H Anthony Chan

 <= /p>

From: dmm-bounces@ietf.org [mailto:d= mm-bounces@ietf.org] = On Behalf Of Alper Yegi= n
Sent: Monday, Nove= mber 04, 2013 10:20 AM
To: dmm
Subject: [DMM] Req= uirements

 

Hello folks,

 

Here I have two comments on this document.

 

= "When the existing security mechanisms/protocols are=

= applied to protect the DMM entities, the security risks that

= may be introduced by DMM MUST be considered to be eliminated."<= o:p>

=  

= I don't quite understand what that means. 

=  

= "Infrequent node mobility coupled with

= application intelligence suggest that mobility support could be=

= provided selectively such as in [I-D.bhandari-dhc-class-based-<= /o:p>

= prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing

= the amount of context maintained in the network."

=  

= Two more related work references that are complementary to the ones already= provided are:

= - draft-yegin-dmm-ondemand-mobility-00

= - draft-liu-dmm-mobility-api-01

=  

= I recommend we include these references as well.

=  

= Alper

=  

=  

 

--_000_6E31144C030982429702B11D6746B98C370D77CDszxeml557mbxchi_-- From h.anthony.chan@huawei.com Tue Nov 5 21:52:15 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FAC11E80F8 for ; Tue, 5 Nov 2013 21:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gq6sQoIA5-Zi for ; Tue, 5 Nov 2013 21:52:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9308A21F9ED1 for ; Tue, 5 Nov 2013 21:52:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXO95613; Wed, 06 Nov 2013 05:52:07 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 05:51:23 +0000 Received: from SZXEML419-HUB.china.huawei.com (10.82.67.158) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 05:52:04 +0000 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.63]) by szxeml419-hub.china.huawei.com ([10.82.67.158]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 13:51:58 +0800 From: h chan To: Alper Yegin Thread-Topic: [DMM] Req#1 Thread-Index: AQHO2paVpwgs0pIgTE+vbiD6BPu1cJoXrRTg Date: Wed, 6 Nov 2013 05:51:57 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370D780C@szxeml557-mbx.china.huawei.com> References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org> <6E31144C030982429702B11D6746B98C370D7785@szxeml557-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.58] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370D780Cszxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dmm Subject: Re: [DMM] Req#1 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 05:52:15 -0000 --_000_6E31144C030982429702B11D6746B98C370D780Cszxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for your kind understanding to avoid extensive editing at the 11t= h hour. I may perhaps make another attempt at this 10th hour by trying to u= se some of your wording. REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid the non-optimal routes that are caused by traversing a centrally deployed mobility anchor in a single/fixed location. H Anthony Chan From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, November 05, 2013 6:19 PM To: h chan Cc: dmm Subject: Re: [DMM] Req#1 Anthony, The harmful type of "centralized" anchor is the one that is in single/fixed= location typically far from the MN, which naturally causes sub-optimal rou= te for most, if not all, end2end data-paths. That's what we are trying to avoid with the DMM solutions. Though, it'd take considerable effort to elaborate on that in the I-D at th= is 11th hour. So, instead, let's go with your text. It's sufficient. Alper On Nov 6, 2013, at 4:01 AM, h chan wrote: Alper I check the draft again. The draft does talk about distributed mobility man= agement versus centralized mobility management. Dropping "centralized ancho= rs" entirely in the requirement is going to produce a domino effect in othe= r places. Now I think an alternative is to say that only those centralized anchors th= at are not in non-optimal route are an issue. REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid traversing centrally deployed mobility anchors when such anchors are in non-optimal routes. That means you have no problem of using centralized anchors as long as they= are not in non-optimal routes. That should also accommodate your proposed = solution. Are you okay with this compromised wording. H Anthony Chan From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, November 05, 2013 4:32 PM To: h chan Cc: dmm Subject: Re: [DMM] Req#1 Works for me. Alper On Nov 6, 2013, at 12:21 AM, h chan wrote: Is the following also acceptable: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid traversing mobility anchors that are in non-optimal routes. I am trying to write it in simple wording and not getting into a new term s= uch as "off path" H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces= @ietf.org] On Behalf Of Alper Yegin Sent: Tuesday, November 05, 2013 8:25 AM To: dmm Subject: [DMM] Req#1 Hello folks, REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. The real issue is not the "central location of the anchor", but "off-path l= ocation of the anchor". The triangular route is caused by forcing the packets to traverse an anchor= node that is not on the direct IP path between the MN and the CN. See the CNet-Homing proposal. http://www.ietf.org/id/draft-yegin-dmm-cnet-h= oming-01.txt. We place the anchor in corresponding network, or the ISP serv= ing that network. Therefore, the path going via that anchor does not cause = triangulation. Some people may perceive that as locating the anchor in a ce= ntral location (though this time it's not an "absolute/unchanging" center a= s implied in the current text). Therefore I recommend the following revision: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic is not forced to traverse off-path mobility anchors and thereby avoid non-optimal routes. Alper --_000_6E31144C030982429702B11D6746B98C370D780Cszxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for your kind u= nderstanding to avoid extensive editing at the 11th hour. I may perhaps mak= e another attempt at this 10th hour by trying to use some of your wording.

 <= /p> 

   REQ1:  Distributed proce=
ssing
 
        =
;  IP mobility, network access and routing solutions provided by<=
/span>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic can avoid the non-optimal routes that are=

       =
   caused by traversing a centrally deployed mobility anchor=
 
       =
   in a single/fixed location.

 <= /p>

 <= /p>

H Anthony Chan=

 <= /p>

From: Alper Ye= gin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, November 05, 2013 6:19 PM
To: h chan
Cc: dmm
Subject: Re: [DMM] Req#1

 

Anthony,

 

The harmful type of "centralized" anchor i= s the one that is in single/fixed location typically far from the MN, which= naturally causes sub-optimal route for most, if not all, end2end data-path= s.

That's what we are trying to avoid with the DMM solu= tions.

Though, it'd take considerable effort to elaborate o= n that in the I-D at this 11th hour.

So, instead, let's go with your text. It's sufficien= t.

 

Alper

 

 

 

 

On Nov 6, 2013, at 4:01 AM, h chan wrote:=



Alper

 <= /p>

I check the draft again. = The draft does talk about distributed mobility management versus centralize= d mobility management. Dropping “centralized anchors” entirely in the requirement is going to produce a domino effect in other places.

 <= /p>

Now I think an alternativ= e is to say that only those centralized anchors that are not in non-optimal= route are an issue.

 <= /p> 

   REQ1:  Distributed proce=
ssing
 
        =
;  IP mobility, network access and routing solutions provided by<=
/span>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic can avoid traversing centrally deployed=

       =
   mobility anchors when such anchors are in non-optimal rou=
tes.

 <= /p>

That means you have no pr= oblem of using centralized anchors as long as they are not in non-optimal r= outes. That should also accommodate your proposed solution. Are you okay with this compromised wording.

 <= /p>

H Anthony Chan

 <= /p>

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Tuesday, Nov= ember 05, 2013 4:32 PM
To: h chan
Cc: dmm
Subject: Re: [DMM]= Req#1

 

Works for me.

 

Alper

 

On Nov 6, 2013, at 12:21 AM, h chan wrote:




Is the following also acc= eptable:

   REQ1:  Distributed proce=
ssing
 
        =
;  IP mobility, network access and routing solutions provided by<=
/span>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic can avoid traversing 
       =
   mobility anchors that are in non-optimal routes.

 <= /p>

I am trying to write it i= n simple wording and not getting into a new term such as “off path= 221;

H Anthony Chan

 <= /p>

From: dmm-bounces@ietf.org [mailto:d= mm-bounces@ietf.org] = On Behalf Of Alper Yegi= n
Sent: Tuesday, Nov= ember 05, 2013 8:25 AM
To: dmm
Subject: [DMM] Req= #1

 

Hello folks,
 
   RE=
Q1:  Distributed processing
 
        =
;  IP mobility, network access and routing solutions provided by<=
/span>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic does not need to traverse centrally deployed
       =
   mobility anchors and thereby avoid non-optimal routes.<=
o:p>

 

The real issue is not the "central location of = the anchor", but "off-path location of the anchor".

 

The triangular route is caused by forcing the packet= s to traverse an anchor node that is not on the direct IP path between the = MN and the CN.

 

See the CNet-Homing proposal. http://www.ietf.org/id= /draft-yegin-dmm-cnet-homing-01.txt. We place the anchor in correspondi= ng network, or the ISP serving that network. Therefore, the path going via that anchor does not cause triangulation. So= me people may perceive that as locating the anchor in a central location (t= hough this time it's not an "absolute/unchanging" center as impli= ed in the current text).

 

Therefore I recommend the following revision:

 

   RE=
Q1:  Distributed processing
 
       =
   IP mobility, network access and routing solutions provided by<=
/span>
       =
   DMM MUST enable distributed processing for mobility management=

       =
   so that traffic is not forced to traverse off-path=

       =
   mobility anchors and thereby avoid non-optimal routes.<=
o:p>

 

Alper

 

 

 

 

--_000_6E31144C030982429702B11D6746B98C370D780Cszxeml557mbxchi_-- From Marco.Liebsch@neclab.eu Wed Nov 6 00:48:17 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6DF921E80F9 for ; Wed, 6 Nov 2013 00:48:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXrDklwEj-2v for ; Wed, 6 Nov 2013 00:48:13 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAFF21E80ED for ; Wed, 6 Nov 2013 00:48:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B99B2105F3A; Wed, 6 Nov 2013 09:42:01 +0100 (CET) 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 4ELmVGvuCsSL; Wed, 6 Nov 2013 09:42:01 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 999B2105F38; Wed, 6 Nov 2013 09:41:51 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.11]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 6 Nov 2013 09:47:40 +0100 From: Marco Liebsch To: "Dirk.von-Hugo@telekom.de" , "dmm@ietf.org" Thread-Topic: DMM framework Thread-Index: Ac7TVrzOCDHkmqfmRFa7YSUJAA32CwC9c6VwAR9FDLA= Date: Wed, 6 Nov 2013 08:47:40 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D637435B0@PALLENE.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D553ACE36@DAPHNIS.office.hd> <05C81A773E48DD49B181B04BA21A342A2C759E30B3@HE113484.emea1.cds.t-internal.com> In-Reply-To: <05C81A773E48DD49B181B04BA21A342A2C759E30B3@HE113484.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.204] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] DMM framework X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 08:48:17 -0000 Dear Dirk, thanks a lot for your review and for your comments. Please see inline for m= y response. >-----Original Message----- >From: Dirk.von-Hugo@telekom.de [mailto:Dirk.von-Hugo@telekom.de] >Sent: Donnerstag, 31. Oktober 2013 16:59 >To: Marco Liebsch; dmm@ietf.org >Subject: RE: DMM framework > >Dear Marco, all, > >I think the idea of describing mobility management functions in a generic = and >modular way can help to allow for fair comparison of different existing >approaches and new extensions towards fulfillment of DMM requirements. As >your draft shows also routing-protocol based approaches as LISP can be >described by this nomenclature. With the new functional entities - and th= e >defined reference points in between - and the abstraction of the mobility = related >ones it thus should help to analyse general network architectures and func= tional >decompositions for both fixed and mobile sessions - in a similar fashion a= s >SDN/NFV (Software Defined Networks/Network Function Virtualization) concep= ts >proceed. That was a key idea behind the framework to allow building a DMM solution that allows exposing relevant states to the dataplane, e.g. routers, SDN co= ntrollers, etc, and to enable inter-working, aiming at an optimized routing path to the MN'= s current anchor The specifications of the DMM group could take such framework to specify th= e hooks between the mobility control plane and e.g. a transport network control plane without i= nterfering with other WGs or SDOs. =20 > >As usually the network analysis will focus on the performance parameters >denoted below. I think therefore the framework activities are valuable wo= rk >from an operators point of view which we should intensify - thus perhaps h= elping >the resulting protocol proposals to be deployed in reality one day. Yes, support for building a DMM solution that integrates well with an opera= tor's architecture is a valid point. The framework could also be used to identify gaps in available protocols an= d architectures, not only mobility protocols, but also transport network related components,= e.g. BGP, SDN technology, LISP, MPLS, etc. Closing these gaps and interfacing the mobility control plane with the tran= sport network control plane enables suitable solutions for DMM. > >Perhaps one could add in sect. 4.1/4.2 that within MN in Fig. 2 and Fig.3 = the >corresponding FEs FE_MU_U and FE_MU_C are not included since for PMIP6 >they reside in MAG ... this surely will become clear from the appendices A= 1/A2 >later on. True, the mobile host components have not been captured in these two figure= s as the focus was on the placement of the DMM-specific functions. But you ha= ve a point here, we should at least clarify this in the test. Thanks for spott= ing this. > >If I remember correctly it was agreed that both framework documents (i.e. >compared to http://tools.ietf.org/id/draft-chan-dmm-framework-03.txt) with >their different way of abstraction can complement each other and should >continue, right? Yes, they can be considered complementary. Hope both can be useful and supp= ort the specifications of the DMM group by identifying required protocol functi= ons and interfaces for both, mobility protocols and transport network technology.=20 Thanks again for your feedback, marco > >Thanks! > >Best regards >Dirk > >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >Marco Liebsch >Sent: Sonntag, 27. Oktober 2013 22:02 >To: dmm@ietf.org >Subject: [DMM] DMM framework > >Folks, > >during my presentation at last IETF about http://www.ietf.org/id/draft-lie= bsch- >dmm-framework-analysis-02.txt, >around 20 people indicated interest in working on a framework. > >We think this framework, the described functional entities and associated >reference points to enable unicast DMM is mature. The original idea of thi= s >framework was to be mobility protocol-agnostic and identify components of >available transport network technology, including SDN technology, to >complement mobility protocols and enable optimized DMM operation. Such >optimization we see in terms of transport costs, routing path, latency, et= c. > >We'd appreciate any comments and contributions to the framework. Please al= so >refer to the slides from last meeting to recall the status of the work. > >http://www.ietf.org/proceedings/87/slides/slides-87-dmm-11.pdf > >marco > > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From pierrick.seite@orange.com Wed Nov 6 05:42:04 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11D711E81AC for ; Wed, 6 Nov 2013 05:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MLqS476xNOa for ; Wed, 6 Nov 2013 05:42:00 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id A8CE311E81A9 for ; Wed, 6 Nov 2013 05:41:59 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 66D3D1905B9; Wed, 6 Nov 2013 14:41:58 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3BB4915804E; Wed, 6 Nov 2013 14:41:58 +0100 (CET) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 14:41:58 +0100 From: To: h chan , Alper Yegin Thread-Topic: [DMM] Req#1 Thread-Index: AQHO2kOjiyk1+OK37keiXYJcpaQEEJoXJVYAgAAkrQCAABjrgIAABOAAgAA7goCAAI4OEA== Date: Wed, 6 Nov 2013 13:41:57 +0000 Message-ID: <30273_1383745318_527A4726_30273_2114_1_81C77F07008CA24F9783A98CFD706F71165CB0@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org> <6E31144C030982429702B11D6746B98C370D7785@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C370D780C@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C370D780C@szxeml557-mbx.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71165CB0PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.6.113015 Cc: dmm Subject: Re: [DMM] Req#1 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:42:04 -0000 --_000_81C77F07008CA24F9783A98CFD706F71165CB0PEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable By definition an IP mobility anchor leads to non-optimal route. Actually, t= he idea behind req#1 is to avoid using mobility anchor far from the optimal= route; and, effectively, this anchor is usually far from both the MN and = the CN Alper, does the following rewording address your concern? REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid traversing single mobility anchor far f= rom the optimal route. De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de h chan Envoy=E9 : mercredi 6 novembre 2013 06:52 =C0 : Alper Yegin Cc : dmm Objet : Re: [DMM] Req#1 Thank you for your kind understanding to avoid extensive editing at the 11t= h hour. I may perhaps make another attempt at this 10th hour by trying to u= se some of your wording. REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid the non-optimal routes that are caused by traversing a centrally deployed mobility anchor in a single/fixed location. H Anthony Chan From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, November 05, 2013 6:19 PM To: h chan Cc: dmm Subject: Re: [DMM] Req#1 Anthony, The harmful type of "centralized" anchor is the one that is in single/fixed= location typically far from the MN, which naturally causes sub-optimal rou= te for most, if not all, end2end data-paths. That's what we are trying to avoid with the DMM solutions. Though, it'd take considerable effort to elaborate on that in the I-D at th= is 11th hour. So, instead, let's go with your text. It's sufficient. Alper On Nov 6, 2013, at 4:01 AM, h chan wrote: Alper I check the draft again. The draft does talk about distributed mobility man= agement versus centralized mobility management. Dropping "centralized ancho= rs" entirely in the requirement is going to produce a domino effect in othe= r places. Now I think an alternative is to say that only those centralized anchors th= at are not in non-optimal route are an issue. REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid traversing centrally deployed mobility anchors when such anchors are in non-optimal routes. That means you have no problem of using centralized anchors as long as they= are not in non-optimal routes. That should also accommodate your proposed = solution. Are you okay with this compromised wording. H Anthony Chan From: Alper Yegin [mailto:alper.yegin@yegin.org] Sent: Tuesday, November 05, 2013 4:32 PM To: h chan Cc: dmm Subject: Re: [DMM] Req#1 Works for me. Alper On Nov 6, 2013, at 12:21 AM, h chan wrote: Is the following also acceptable: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic can avoid traversing mobility anchors that are in non-optimal routes. I am trying to write it in simple wording and not getting into a new term s= uch as "off path" H Anthony Chan From: dmm-bounces@ietf.org [mailto:dmm-bounces= @ietf.org] On Behalf Of Alper Yegin Sent: Tuesday, November 05, 2013 8:25 AM To: dmm Subject: [DMM] Req#1 Hello folks, REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic does not need to traverse centrally deployed mobility anchors and thereby avoid non-optimal routes. The real issue is not the "central location of the anchor", but "off-path l= ocation of the anchor". The triangular route is caused by forcing the packets to traverse an anchor= node that is not on the direct IP path between the MN and the CN. See the CNet-Homing proposal. http://www.ietf.org/id/draft-yegin-dmm-cnet-h= oming-01.txt. We place the anchor in corresponding network, or the ISP serv= ing that network. Therefore, the path going via that anchor does not cause = triangulation. Some people may perceive that as locating the anchor in a ce= ntral location (though this time it's not an "absolute/unchanging" center a= s implied in the current text). Therefore I recommend the following revision: REQ1: Distributed processing IP mobility, network access and routing solutions provided by DMM MUST enable distributed processing for mobility management so that traffic is not forced to traverse off-path mobility anchors and thereby avoid non-optimal routes. Alper ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F71165CB0PEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 <= /p>

By definit= ion an IP mobility anchor leads to non-optimal route. Actually, the idea be= hind req#1 is to avoid using mobility anchor far from the optimal route; and,  effectively, this anchor is usually far from bot= h the MN and the CN

Alper, doe= s the following rewording address your concern?

 = ;

REQ1:  Distributed pro=
cessing
 
     &n=
bsp;    IP mobility, network access and routing solutio=
ns provided by
    &nb=
sp;     DMM MUST enable distributed processing for mobi=
lity management
    &nb=
sp;     so that traffic can avoid traversing single mob=
ility anchor far from the optimal route.

 = ;

De : dmm-= bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de h chan
Envoy=E9 : mercredi 6 novembre 2013 06:52
=C0 : Alper Yegin
Cc : dmm
Objet : Re: [DMM] Req#1

 

Thank you = for your kind understanding to avoid extensive editing at the 11th hour. I = may perhaps make another attempt at this 10th hour by trying to use some of your wording.

 = ;

   REQ1:  Di=
stributed processing
 
     &n=
bsp;    IP mobility, network access and routing solutio=
ns provided by
    &nb=
sp;     DMM MUST enable distributed processing for mobi=
lity management
    &nb=
sp;     so that traffic can avoid the non-optimal route=
s that are
    &nb=
sp;     caused by traversing a centrally deployed =
mobility anchor 
    &nb=
sp;     in a single/fixed location.

 = ;

 = ;

H Anthony = Chan

 = ;

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, November 05, 2013 6:19 PM
To: h chan
Cc: dmm
Subject: Re: [DMM] Req#1

 

Anthony,

 

The harmful type of "centr= alized" anchor is the one that is in single/fixed location typically f= ar from the MN, which naturally causes sub-optimal route for most, if not a= ll, end2end data-paths.

That's what we are trying to av= oid with the DMM solutions.

Though, it'd take considerable = effort to elaborate on that in the I-D at this 11th hour.=

So, instead, let's go with your= text. It's sufficient.

 

Alper

 

 

 

 

On Nov 6, 2013, at 4:01 AM, h c= han wrote:

=  

Alper

 

I check th= e draft again. The draft does talk about distributed mobility management ve= rsus centralized mobility management. Dropping “centralized anchors” entirely in the requirement is going to produce a domino ef= fect in other places.

 

Now I thin= k an alternative is to say that only those centralized anchors that are not= in non-optimal route are an issue.<= /span>

 

   REQ1:  Di=
stributed processing
 
     &n=
bsp;    IP mobility, network access and routing solutio=
ns provided by
    &nb=
sp;     DMM MUST enable distributed processing for mobi=
lity management
    &nb=
sp;     so that traffic can avoid traversing centrally =
deployed
    &nb=
sp;     mobility anchors when such anchors are in =
non-optimal routes.

 

That means= you have no problem of using centralized anchors as long as they are not i= n non-optimal routes. That should also accommodate your proposed solution. Are you okay with this compromised wording.

 

H Anthony = Chan

 

From: Alper Yegin [mailto:alper.yegin@yegin.o= rg] 
Sent: Tuesday, Nov= ember 05, 2013 4:32 PM
To: h chan
Cc: dmm
Subject: Re: [DMM]= Req#1

 

Works for me.=

 

Alper

 

On Nov 6, 2013, at 12:21 AM, h = chan wrote:

=

Is the fol= lowing also acceptable:

   REQ1:  Di=
stributed processing
 
     &n=
bsp;    IP mobility, network access and routing solutio=
ns provided by
    &nb=
sp;     DMM MUST enable distributed processing for mobi=
lity management
    &nb=
sp;     so that traffic can avoid traversing 
    &nb=
sp;     mobility anchors that are in non-optimal r=
outes.

 

I am tryin= g to write it in simple wording and not getting into a new term such as = 220;off path”

H Anthony = Chan

 

From: dmm-= bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegi= n
Sent: Tuesday, Nov= ember 05, 2013 8:25 AM
To: dmm
Subject: [DMM] Req= #1

 

Hello folks,
=
 
=
   REQ1:  Distributed processing=

 
     &n=
bsp;    IP mobility, network access and routing solutio=
ns provided by
    &nb=
sp;     DMM MUST enable distributed processing for mobi=
lity management
    &nb=
sp;     so that traffic does not need to traverse centr=
ally deployed
    &nb=
sp;     mobility anchors and thereby avoid non-optimal =
routes.

 

The real issue is not the "= ;central location of the anchor", but "off-path location of the a= nchor".

 

The triangular route is caused = by forcing the packets to traverse an anchor node that is not on the direct= IP path between the MN and the CN.

 

See the CNet-Homing proposal.&n= bsp;h= ttp://www.ietf.org/id/draft-yegin-dmm-cnet-homing-01.txt. We place the = anchor in corresponding network, or the ISP serving that network. Therefore, the path going via that anchor does not c= ause triangulation. Some people may perceive that as locating the anchor in= a central location (though this time it's not an "absolute/unchanging= " center as implied in the current text).

 

Therefore I recommend the follo= wing revision:

 

=
   REQ1:  Distributed processing=

 
    &nb=
sp;     IP mobility, network access and routing solutio=
ns provided by
    &nb=
sp;     DMM MUST enable distributed processing for mobi=
lity management
    &nb=
sp;     so that traffic is not forced to traverse off-p=
ath
    &nb=
sp;     mobility anchors and thereby avoid non-optimal =
routes.

 

Alper

 

 

 

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F71165CB0PEXCVZYM12corpora_-- From alper.yegin@yegin.org Wed Nov 6 06:03:18 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD46A11E8102 for ; Wed, 6 Nov 2013 06:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JstVma3PZ0CH for ; Wed, 6 Nov 2013 06:03:13 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6C90E11E81BF for ; Wed, 6 Nov 2013 06:03:13 -0800 (PST) Received: from vpn-cust-10-119-8-1.witopia.net (213-128-81-68.turkrdns.com [213.128.81.68]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MWCcT-1V7JMe1z6P-00XGaA; Wed, 06 Nov 2013 09:03:12 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9F2386CE-21A0-483F-90A1-68FB438DEC8A" From: Alper Yegin In-Reply-To: <30273_1383745318_527A4726_30273_2114_1_81C77F07008CA24F9783A98CFD706F71165CB0@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Wed, 6 Nov 2013 16:03:04 +0200 Message-Id: <85D6E121-CD12-4BCC-B07C-934932CCF06C@yegin.org> References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org> <6E31144C030982429702B11D6746B98C370D7785@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C370D780C@szxeml557-mbx.china.huawei.com> <30273_1383745318_527A4726_30273_2114_1_81C77F07008CA24F9783A98CFD706F71165CB0@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:dDiq/ctiH606JXG9ls58YQwvtP9hH+RIHrXt9yGVnOG z10fqZq1+64R+BsFN3AHZzYA7klmVmczJWK+Qd0o/6hAR7hmKB glup1RXAr6yvDxFCfiFyv3sZMSH9FIdJR3oKu8UVZFaPD2JwTa jezNymEF3tLeUDEgtsb2xpsUrMJZ9aho6lMNaP9+Jm+Dz86igP kkObEc2vL+Lfp8Kb8KZ8noCLoHAFXq7w/sNTpYtWXaWrZlZ1jZ CbnzzbrjCVFFinFKEr0dXzNDNwTojGfE2uej2dOF6EpLJRfQiv x8zGrzLT1qlupmjv3RLGC8kY17yvqtefzN0U0RYS9dM0kguAye tt86tO83pU/wXMyo9nIVNfN2Ci/iwFenvv+LCKw0u32N64wZAC V7M++uy047iAtx67ivGhf+h67NDUfqQ8J0= Cc: dmm Subject: Re: [DMM] Req#1 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 14:03:18 -0000 --Apple-Mail=_9F2386CE-21A0-483F-90A1-68FB438DEC8A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Pierrick, both your and Anthony's latest text address my concern. Thanks. Alper On Nov 6, 2013, at 3:41 PM, wrote: > =20 > By definition an IP mobility anchor leads to non-optimal route. = Actually, the idea behind req#1 is to avoid using mobility anchor far = from the optimal route; and, effectively, this anchor is usually far = from both the MN and the CN > Alper, does the following rewording address your concern? > =20 > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic can avoid traversing single mobility anchor = far from the optimal route.=20 > =20 > De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de = h chan > Envoy=E9 : mercredi 6 novembre 2013 06:52 > =C0 : Alper Yegin > Cc : dmm > Objet : Re: [DMM] Req#1 > =20 > Thank you for your kind understanding to avoid extensive editing at = the 11th hour. I may perhaps make another attempt at this 10th hour by = trying to use some of your wording. > =20 > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic can avoid the non-optimal routes that are > caused by traversing a centrally deployed mobility anchor=20 > in a single/fixed location.=20 > =20 > =20 > H Anthony Chan > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Tuesday, November 05, 2013 6:19 PM > To: h chan > Cc: dmm > Subject: Re: [DMM] Req#1 > =20 > Anthony, > =20 > The harmful type of "centralized" anchor is the one that is in = single/fixed location typically far from the MN, which naturally causes = sub-optimal route for most, if not all, end2end data-paths. > That's what we are trying to avoid with the DMM solutions. > Though, it'd take considerable effort to elaborate on that in the I-D = at this 11th hour. > So, instead, let's go with your text. It's sufficient. > =20 > Alper > =20 > =20 > =20 > =20 > On Nov 6, 2013, at 4:01 AM, h chan wrote: > =20 >=20 > Alper > =20 > I check the draft again. The draft does talk about distributed = mobility management versus centralized mobility management. Dropping = =93centralized anchors=94 entirely in the requirement is going to = produce a domino effect in other places. > =20 > Now I think an alternative is to say that only those centralized = anchors that are not in non-optimal route are an issue. > =20 > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic can avoid traversing centrally deployed > mobility anchors when such anchors are in non-optimal = routes. > =20 > That means you have no problem of using centralized anchors as long as = they are not in non-optimal routes. That should also accommodate your = proposed solution. Are you okay with this compromised wording. > =20 > H Anthony Chan > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Tuesday, November 05, 2013 4:32 PM > To: h chan > Cc: dmm > Subject: Re: [DMM] Req#1 > =20 > Works for me. > =20 > Alper > =20 > On Nov 6, 2013, at 12:21 AM, h chan wrote: >=20 >=20 >=20 > Is the following also acceptable: > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic can avoid traversing=20 > mobility anchors that are in non-optimal routes. > =20 > I am trying to write it in simple wording and not getting into a new = term such as =93off path=94 > H Anthony Chan > =20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Alper Yegin > Sent: Tuesday, November 05, 2013 8:25 AM > To: dmm > Subject: [DMM] Req#1 > =20 > Hello folks, > =20 > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic does not need to traverse centrally deployed > mobility anchors and thereby avoid non-optimal routes. > =20 > The real issue is not the "central location of the anchor", but = "off-path location of the anchor". > =20 > The triangular route is caused by forcing the packets to traverse an = anchor node that is not on the direct IP path between the MN and the CN. > =20 > See the CNet-Homing proposal. = http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-01.txt. We place the = anchor in corresponding network, or the ISP serving that network. = Therefore, the path going via that anchor does not cause triangulation. = Some people may perceive that as locating the anchor in a central = location (though this time it's not an "absolute/unchanging" center as = implied in the current text). > =20 > Therefore I recommend the following revision: > =20 > REQ1: Distributed processing > =20 > IP mobility, network access and routing solutions provided = by > DMM MUST enable distributed processing for mobility = management > so that traffic is not forced to traverse off-path > mobility anchors and thereby avoid non-optimal routes. > =20 > Alper > =20 > =20 > =20 > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. --Apple-Mail=_9F2386CE-21A0-483F-90A1-68FB438DEC8A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello Pierrick, both your and Anthony's latest text = address my = concern.

Thanks.

Alper

On Nov 6, 2013, at 3:41 PM, <pierrick.seite@orange.com>= ; wrote:

By definition an IP mobility anchor leads to = non-optimal route. Actually, the idea behind req#1 is to avoid using = mobility anchor far from the optimal route; and,  effectively, this = anchor is usually far from both the MN and the = CN
Alper, does the following = rewording address your concern?
REQ1:  Distributed processing
 
     =
     IP mobility, network access and routing =
solutions provided by
          DMM MUST =
enable distributed processing for mobility management
          so that =
traffic can avoid traversing single mobility anchor far from the optimal =
route.
 
 dmm-bounces@ietf.org = [mailto:dmm-bounces@ietf.org] De la part de h = chan
Envoy=E9 : mercredi 6 novembre 2013 = 06:52
=C0 : Alper = Yegin
Cc : dmm
Objet : Re: [DMM] = Req#1
Thank you for your kind understanding to avoid = extensive editing at the 11th hour. I may perhaps make another attempt = at this 10th hour by trying to use some of your = wording.
 
   REQ1:  =
Distributed processing
 
     =
     IP mobility, network access and routing =
solutions provided by
          DMM MUST =
enable distributed processing for mobility management
          so that =
traffic can avoid the non-optimal routes that =
are
          caused =
by traversing a centrally deployed mobility anchor =

          in =
a single/fixed location.
 
H Anthony Chan
From: Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Tuesday, November 05, 2013 = 6:19 PM
To: h = chan
Cc: dmm
Subject: Re: [DMM] = Req#1
 
Anthony,
 
The harmful type of "centralized" = anchor is the one that is in single/fixed location typically far from = the MN, which naturally causes sub-optimal route for most, if not all, = end2end data-paths.
That's what we are trying to avoid = with the DMM solutions.
Though, it'd take considerable = effort to elaborate on that in the I-D at this 11th = hour.
So, = instead, let's go with your text. It's = sufficient.
 
Alper
 
 
 
 
On Nov 6, 2013, at 4:01 AM, h chan = wrote:

 

I check the = draft again. The draft does talk about distributed mobility management = versus centralized mobility management. Dropping =93centralized anchors=94= entirely in the requirement is going to produce a domino effect in = other places.
Now I think = an alternative is to say that only those centralized anchors that are = not in non-optimal route are an issue.
   REQ1:  =
Distributed processing
 
     =
     IP mobility, network access and routing =
solutions provided by
          DMM MUST =
enable distributed processing for mobility management
          so that =
traffic can avoid traversing centrally deployed
 
That means = you have no problem of using centralized anchors as long as they are not = in non-optimal routes. That should also accommodate your proposed = solution. Are you okay with this compromised wording.
H Anthony = Chan
 Alper Yegin [mailto:alper.yegin@yegin.org] 
Sent: Tuesday, November 05, 2013 = 4:32 PM
To: h = chan
Cc: dmm
Subject: Re: [DMM] Req#1
 
Works for = me.
 
Alper
 
On Nov 6, 2013, at 12:21 AM, h = chan wrote:



Is the = following also acceptable:
   REQ1:  =
Distributed processing
 
     =
     IP mobility, network access and routing =
solutions provided by
          DMM MUST =
enable distributed processing for mobility management
          so that =
traffic can avoid traversing
 
I am trying = to write it in simple wording and not getting into a new term such as = =93off path=94
H Anthony = Chan
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Tuesday, November 05, 2013 = 8:25 AM
To: dmm
Subject: [DMM] Req#1
<= div style=3D"margin-top: 0cm; margin-right: 0cm; margin-left: 0cm; = margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New = Roman', serif; "> 
Hello folks,
 
   REQ1:  =
Distributed processing
 
     =
     IP mobility, network access and routing =
solutions provided by
          DMM MUST =
enable distributed processing for mobility management
          so that =
traffic does not need to traverse centrally deployed
          mobility =
anchors and thereby avoid non-optimal routes.
 
<= div>
The real issue is not the "central = location of the anchor", but "off-path location of the = anchor".
 
<= div>
The triangular route is caused by = forcing the packets to traverse an anchor node that is not on the direct = IP path between the MN and the = CN.
 
<= div>
See the CNet-Homing = proposal. 
In-Reply-To: <6E31144C030982429702B11D6746B98C370D77CD@szxeml557-mbx.china.huawei.com>
Date: Wed, 6 Nov 2013 16:07:10 +0200
Message-Id: <00A21EA3-6531-4E4D-AF80-3CCCCC9309C5@yegin.org>
References: <660E41D7-7F6A-47B4-86CE-C00ECA136DA8@yegin.org> <6E31144C030982429702B11D6746B98C370D7705@szxeml557-mbx.china.huawei.com>  <6E31144C030982429702B11D6746B98C370D776E@szxeml557-mbx.china.huawei.com> <101C778B-D174-40D6-BA06-54AC51B97A32@yegin.org> <6E31144C030982429702B11D6746B98C370D77CD@szxeml557-mbx.china.huawei.com>
To: h chan 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:NGukXmi7E4pgwVYCYssOFGtAf+wg9ZY1E/EwJO3uaHS eiMdJMAiavraSOL5jaJjqEBhKSmrWZiOWE+8EFhg36xydBrjJB jDEIj237Rck5r6uBJ9Ooqtt84kgbNblYGeZlIlDudx8gvouI0l /i6s0MEVpa/pdMe4LkcAAQKLfHwKsBNVzuhRRDi9AOSxs4dJ6e G9o7nyt15qWljmg2a9plJV2DMKQNIHBBL8YkrDxvt1NWRuFI9+ 0LqwdwnSB2l2mo1ug6rYKQZtQlRjVqwa7nb52jhaJwHPfEtk8b NPfb/yJW1+Q0mGN/TElMNTSNdkywTxZeNsRgEa4Fc4BNpHK/Fc 6HX+aaDDd3MeRJsljXqRaUOS6CU024nZa7EBg0tEuRvlQUoZGt Sa0QT3kudPHvh9qxUxy876h9u0caziWcA8=
Cc: dmm 
Subject: Re: [DMM] Requirements
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 06 Nov 2013 14:07:28 -0000

--Apple-Mail=_EEECB8E8-FE3E-4844-8841-81291A51168D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Looks good, thank you Anthony.

Alper

On Nov 6, 2013, at 4:47 AM, h chan wrote:

> Motivation:
> Various attacks such as impersonation, denial of service,
> man-in-the-middle attacks, and so on,
> may be launched in a DMM deployment.
> For instance,
> an illegitimate node
> may attempt to access a network providing DMM.
> Another example is that
> a malicious node can forge a number of signaling messages
> thus redirecting traffic from its legitimate path.
> Consequently,
> the specific node is under a denial of service attack,
> whereas other nodes do not receive their traffic.
> Accordingly,
> security mechanisms/protocols providing access control,
> integrity, authentication, authorization,
> confidentiality, etc.
> can be used to protect the DMM entities
> as they are already used to protect
> against existing networks
> and existing mobility protocols defined in IETF.
> =20
> =20
> H Anthony Chan
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Tuesday, November 05, 2013 6:32 PM
> To: h chan
> Cc: dmm
> Subject: Re: [DMM] Requirements
> =20
> Anthony,
> =20
> =20
> =20
> Alper,
> The sentence in question is not in the requirement but rather one of =
the sentences in the motivation of the requirement.
> =20
> Unfortunately it's using normative language. Hence it reads like a =
requirement.=20
> =20
>  When the existing security mechanisms/protocols are applied to =
protect the DMM entities, the security risks that may be introduced by =
DMM MUSTbe considered to be eliminated. [1]
>=20
>=20
> =20
>=20
>=20
> When deleting that sentence, it affects the rest of the motivation and =
the requirement, which will not flow.
> =20
> The security requirement is:
> [2] A DMM solution MUST not introduce new security risks
> or amplify existing security risks
> against which the existing security mechanisms/protocols
> cannot offer sufficient protection.
> =20
> =20
> This is a good requirement. We shall keep that. No problem with that.
> =20
> My problem was with another statement ([1])
> =20
> =20
>=20
>=20
> This text was agreed upon by Byoung-Jo Kim.
> Do you have problem with it? Or do you have better wording?
> =20
> My understanding is that a design that increases security risks is =
indeed a problem. Is that right?
> =20
> =20
> =20
> No problem with [2].
> =20
> [1] seems to be broken, like I explained.=20
> =20
> Alper
> =20
> =20
> =20
>=20
>=20
> H Anthony Chan
> =20
> From: Alper Yegin [mailto:alper.yegin@yegin.org]=20
> Sent: Tuesday, November 05, 2013 5:08 PM
> To: h chan
> Cc: dmm
> Subject: Re: [DMM] Requirements
> =20
> Hello Anthony,
> =20
> =20
> =20
> Regarding:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
> My understanding of the intention is that it is sufficient to apply =
the existing security mechanisms/protocols to protect the DMM entities.
> Ideally, we don=92t want DMM to add new security risks.
> Yet, DMM can introduce new DMM entities, which can be vulnerable to =
security risks, and it is necessary to protect the new DMM entities.
> So we basically don=92t want DMM to introduce new security risks that =
cannot be handled with the existing security mechanisms.
> =20
> If the wording =93considered to be eliminated=94 does not clarify the =
above, how about the following:
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be eliminated."
> =20
> Or, can you come up with better text prior to Friday. I am trying to =
close all requirements issues prior to the meeting on Friday to enable =
the wg to move to the next step.
> =20
> I recommend we delete that sentence. It's not easy to understand. And =
if I try hard to understand, what I understand does not make sense.
> It sounds like the following:
> - There are already security solutions applied to =
legacy/existing/non-DMM solutions.
> - Those solutions must be sufficient for securing DMM solutions.
> - In other words, DMM solutions must be designed in such a way that =
they must not require any new security solutions.
> =20
> That does not make sense, IMHO.
> Obviously, we'd like to minimize the work. We prefer not having to =
design additional stuff to secure DMM solutions.
> But we cannot mandate that.
> We shall not block solutions that may require additional security =
mechanisms. We can discourage that, but not prohibit.
> =20
> =20
> =20
> Regarding your comment on the helpful references, I understand that =
there are many other individual drafts in the solution space. I did =
recently accept a prior comment to add the coloring reference. Yet now =
if we continue to respond to requests to add references to the =
individual drafts, it will not end. With the many individual drafts in =
the solution space, I hope the wg will have drafts that will =
merge/incorporate many solution drafts in future. May I now ask all the =
authors of the individual drafts to kindly wait for such future wg draft =
to consider what solutions to include/exclude?
> =20
> I'm fine with that.
> I saw two drafts referenced in the I-D which are complemented by two =
other drafts, hence I proposed them. It's OK if you don't add them.
> =20
> Alper
> =20
> =20
> =20
> =20
>=20
>=20
>=20
> =20
> H Anthony Chan
> =20
> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of =
Alper Yegin
> Sent: Monday, November 04, 2013 10:20 AM
> To: dmm
> Subject: [DMM] Requirements
> =20
> Hello folks,
> =20
> Here I have two comments on this document.
> =20
> "When the existing security mechanisms/protocols are
> applied to protect the DMM entities, the security risks that
> may be introduced by DMM MUST be considered to be eliminated."
> =20
> I don't quite understand what that means.=20
> =20
> "Infrequent node mobility coupled with
> application intelligence suggest that mobility support could be
> provided selectively such as in [I-D.bhandari-dhc-class-based-
> prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
> the amount of context maintained in the network."
> =20
> Two more related work references that are complementary to the ones =
already provided are:
> - draft-yegin-dmm-ondemand-mobility-00
> - draft-liu-dmm-mobility-api-01
> =20
> I recommend we include these references as well.
> =20
> Alper
> =20
> =20


--Apple-Mail=_EEECB8E8-FE3E-4844-8841-81291A51168D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Looks good, thank you =
Anthony.

Alper

On Nov 6, =
2013, at 4:47 AM, h chan wrote:

Various attacks such as =
impersonation, denial of service,
man-in-the-middle attacks, and so =
on,
may be launched in a DMM =
deployment.
For =
instance,
an illegitimate =
node
may attempt to access a network providing =
DMM.
Another example is =
that
a malicious node can forge a number of =
signaling messages
thus redirecting traffic from its =
legitimate path.
the specific node is under a denial =
of service attack,
whereas other nodes do not receive =
their traffic.
security mechanisms/protocols =
providing access control,
integrity, =
authentication, authorization,
confidentiality, etc.
can be used to protect the DMM =
entities
as they are already used to =
protect
against existing =
networks
and existing mobility protocols =
defined in IETF.
H =
Anthony Chan
From: Alper Yegin =
[mailto:alper.yegin@yegin.org] 
Sent: Tuesday, November 05, 2013 =
6:32 PM
To: h =
chan
Cc: dmm
Subject: Re: [DMM] =
Requirements
The sentence in question is not in the requirement =
but rather one of the sentences in the motivation of the =
requirement.
 
Unfortunately it's using normative language. Hence it =
reads like a requirement. 
 
 When the existing security =
mechanisms/protocols are applied to protect the DMM entities, the =
security risks that may be introduced by DMM MUSTbe considered to =
be eliminated. [1]
 
When =
deleting that sentence, it affects the rest of the motivation and the =
requirement, which will not flow.
The security requirement =
is:
[2] A DMM solution MUST not =
introduce new security risks
or amplify existing security =
risks
against which the existing security =
mechanisms/protocols
cannot offer sufficient =
protection.
 
 
This is a good requirement. We shall keep that. No =
problem with that.
My problem was with =
another statement ([1])
 
 
This =
text was agreed upon by Byoung-Jo =
Kim.
Do =
you have problem with it? Or do you have better =
wording?
My understanding is that a design =
that increases security risks is indeed a problem. Is that =
right?
 
 
No problem with [2].
 
[1] seems to be broken, like I =
explained. 
H =
Anthony Chan
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper =
Yegin
Sent: Monday, November 04, 2013 =
10:20 AM
To: dmm
Subject: [DMM] =
Requirements
 
Hello =
folks,
Here I have two comments on this =
document.
prefix] and [I-D.korhonen-6man-prefix-properties], thus =
reducing
- =
draft-liu-dmm-mobility-api-01
 

Thread-Topic: [DMM] Req#1
Thread-Index: AQHO2kOjiyk1+OK37keiXYJcpaQEEJoXJVYAgAAkrQCAABjrgIAABOAAgAA7goCAAI4OEP//hdAAgAFYGbA=
Date: Thu, 7 Nov 2013 02:35:24 +0000
Message-ID: <6E31144C030982429702B11D6746B98C370D7943@szxeml557-mbx.china.huawei.com>
References: <26DC10F7-A878-4E7D-B9C2-CD396CE7C9CA@yegin.org> <6E31144C030982429702B11D6746B98C370D770B@szxeml557-mbx.china.huawei.com> <7E33FF9E-C31A-4E8D-AB1E-D10B83DF312D@yegin.org> <6E31144C030982429702B11D6746B98C370D7785@szxeml557-mbx.china.huawei.com>  <6E31144C030982429702B11D6746B98C370D780C@szxeml557-mbx.china.huawei.com> <30273_1383745318_527A4726_30273_2114_1_81C77F07008CA24F9783A98CFD706F71165CB0@PEXCVZYM12.corporate.adroot.infra.ftgroup> <85D6E121-CD12-4BCC-B07C-934932CCF06C@yegin.org>
In-Reply-To: <85D6E121-CD12-4BCC-B07C-934932CCF06C@yegin.org>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.150.171]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370D7943szxeml557mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: dmm 
Subject: Re: [DMM] Req#1
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2013 02:35:41 -0000

--_000_6E31144C030982429702B11D6746B98C370D7943szxeml557mbxchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I will take Pierrick's text.

H Anthony Chan

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Wednesday, November 06, 2013 6:03 AM
To: pierrick.seite@orange.com
Cc: h chan; dmm
Subject: Re: [DMM] Req#1

Hello Pierrick, both your and Anthony's latest text address my concern.

Thanks.

Alper

On Nov 6, 2013, at 3:41 PM, > wrote:



By definition an IP mobility anchor leads to non-optimal route. Actually, t=
he idea behind req#1 is to avoid using mobility anchor far from the optimal=
 route; and,  effectively, this anchor is usually far from both the MN and =
the CN
Alper, does the following rewording address your concern?


REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid traversing single mobility anchor far f=
rom the optimal route.

De : dmm-bounces@ietf.org [mailto:dmm-bounces@=
ietf.org] De la part de h chan
Envoy=E9 : mercredi 6 novembre 2013 06:52
=C0 : Alper Yegin
Cc : dmm
Objet : Re: [DMM] Req#1

Thank you for your kind understanding to avoid extensive editing at the 11t=
h hour. I may perhaps make another attempt at this 10th hour by trying to u=
se some of your wording.


   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid the non-optimal routes that are

          caused by traversing a centrally deployed mobility anchor

          in a single/fixed location.


H Anthony Chan

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, November 05, 2013 6:19 PM
To: h chan
Cc: dmm
Subject: Re: [DMM] Req#1

Anthony,

The harmful type of "centralized" anchor is the one that is in single/fixed=
 location typically far from the MN, which naturally causes sub-optimal rou=
te for most, if not all, end2end data-paths.
That's what we are trying to avoid with the DMM solutions.
Though, it'd take considerable effort to elaborate on that in the I-D at th=
is 11th hour.
So, instead, let's go with your text. It's sufficient.

Alper




On Nov 6, 2013, at 4:01 AM, h chan wrote:

Alper

I check the draft again. The draft does talk about distributed mobility man=
agement versus centralized mobility management. Dropping "centralized ancho=
rs" entirely in the requirement is going to produce a domino effect in othe=
r places.

Now I think an alternative is to say that only those centralized anchors th=
at are not in non-optimal route are an issue.


   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid traversing centrally deployed

          mobility anchors when such anchors are in non-optimal routes.

That means you have no problem of using centralized anchors as long as they=
 are not in non-optimal routes. That should also accommodate your proposed =
solution. Are you okay with this compromised wording.

H Anthony Chan

From: Alper Yegin [mailto:alper.yegin@yegin.org]
Sent: Tuesday, November 05, 2013 4:32 PM
To: h chan
Cc: dmm
Subject: Re: [DMM] Req#1

Works for me.

Alper

On Nov 6, 2013, at 12:21 AM, h chan wrote:



Is the following also acceptable:

   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid traversing

          mobility anchors that are in non-optimal routes.

I am trying to write it in simple wording and not getting into a new term s=
uch as "off path"
H Anthony Chan

From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Alper Yegin
Sent: Tuesday, November 05, 2013 8:25 AM
To: dmm
Subject: [DMM] Req#1


Hello folks,



   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic does not need to traverse centrally deployed

          mobility anchors and thereby avoid non-optimal routes.

The real issue is not the "central location of the anchor", but "off-path l=
ocation of the anchor".

The triangular route is caused by forcing the packets to traverse an anchor=
 node that is not on the direct IP path between the MN and the CN.

See the CNet-Homing proposal. http://www.ietf.org/id/draft-yegin-dmm-cnet-h=
oming-01.txt. We place the anchor in corresponding network, or the ISP serv=
ing that network. Therefore, the path going via that anchor does not cause =
triangulation. Some people may perceive that as locating the anchor in a ce=
ntral location (though this time it's not an "absolute/unchanging" center a=
s implied in the current text).

Therefore I recommend the following revision:


   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic is not forced to traverse off-path

          mobility anchors and thereby avoid non-optimal routes.

Alper





___________________________________________________________________________=
______________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.



This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and dele=
te this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.

Thank you.


--_000_6E31144C030982429702B11D6746B98C370D7943szxeml557mbxchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I will take Pierrick̵=
7;s text.



 <=
/p>



H Anthony Chan=





 <=
/p>





From: Alper Ye=
gin [mailto:alper.yegin@yegin.org]


Sent: Wednesday, November 06, 2013 6:03 AM

To: pierrick.seite@orange.com

Cc: h chan; dmm

Subject: Re: [DMM] Req#1






 


Hello Pierrick, both your and Anthony's latest text =
address my concern.




 






Thanks.






 






Alper






 






On Nov 6, 2013, at 3:41 PM, <pierrick.seite@orange.com> wrote:















 =







By definition an IP mobil=
ity anchor leads to non-optimal route. Actually, the idea behind req#1 is t=
o avoid using mobility anchor far from the optimal route;
 and,  effectively, this anchor is usually far from both the MN and th=
e CN






Alper, does the following=
 rewording address your concern?=







 




REQ1:  Distributed processing<=
span lang=3D"FR">


 =



        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid traversing single mobility anchor fa=
r from the optimal route. 




 










De : dmm-bounc=
es@ietf.org
 [mailto:dmm-bounces@ietf.org]<=
span class=3D"apple-converted-space"> De la part de h chan

Envoy=E9 : me=
rcredi 6 novembre 2013 06:52

=C0 : Alper Y=
egin

Cc : dmm

Objet : Re: [=
DMM] Req#1










 






Thank you for your kind u=
nderstanding to avoid extensive editing at the 11th hour. I may perhaps mak=
e another attempt at this 10th hour by trying to use some
 of your wording.






 




   REQ1:  Distributed proce=
ssing


 =



        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid the non-optimal routes that are


       =
   caused by traversing a centrally deployed mobility anchor=
 


       =
   in a single/fixed location. 




 






 








H Anthony Chan








 










From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Tuesday, Nov=
ember 05, 2013 6:19 PM

To: h chan

Cc: dmm

Subject: Re: [DMM]=
 Req#1










 






Anthony,








 










The harmful type of "centralized" anchor i=
s the one that is in single/fixed location typically far from the MN, which=
 naturally causes sub-optimal route for most, if not all, end2end data-path=
s.










That's what we are trying to avoid with the DMM solu=
tions.










Though, it'd take considerable effort to elaborate o=
n that in the I-D at this 11th hour.









So, instead, let's go with your text. It's sufficien=
t.










 










Alper










 










 










 










 










On Nov 6, 2013, at 4:01 AM, h chan wrote:






 








Alper










 










I check the draft again. =
The draft does talk about distributed mobility management versus centralize=
d mobility management. Dropping “centralized anchors” entirely
 in the requirement is going to produce a domino effect in other places.










 










Now I think an alternativ=
e is to say that only those centralized anchors that are not in non-optimal=
 route are an issue.










 






   REQ1:  Distributed proce=
ssing


 =



        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid traversing centrally deployed=



       =
   mobility anchors when such anchors are in non-optimal rou=
tes.






 










That means you have no pr=
oblem of using centralized anchors as long as they are not in non-optimal r=
outes. That should also accommodate your proposed solution.
 Are you okay with this compromised wording.<=
/o:p>










 












H Anthony Chan












 














From: Alper
 Yegin [mailto:alper.yegin@yegin.o=
rg] 

Sent: Tuesday, Nov=
ember 05, 2013 4:32 PM

To: h chan

Cc: dmm

Subject: Re: [DMM]=
 Req#1














 










Works for me.











 














Alper














 














On Nov 6, 2013, at 12:21 AM, h chan wrote:





























Is the following also acc=
eptable:








   REQ1:  Distributed proce=
ssing


 =



        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid traversing =



       =
   mobility anchors that are in non-optimal routes.








 
















I am trying to write it i=
n simple wording and not getting into a new term such as “off path=
221;














H Anthony Chan
















 


















From: dmm-bounces@ietf.org [mailto:d=
mm-bounces@ietf.org] =
On
 Behalf Of Alper Yegi=
n

Sent: Tuesday, Nov=
ember 05, 2013 8:25 AM

To: dmm

Subject: [DMM] Req=
#1


















 








Hello folks,=



 


   RE=
Q1:  Distributed processing=



 =



        =
;  IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic does not need to traverse centrally deployed


       =
   mobility anchors and thereby avoid non-optimal routes.<=
span lang=3D"FR">










 


















The real issue is not the "central location of =
the anchor", but "off-path location of the anchor".


















 


















The triangular route is caused by forcing the packet=
s to traverse an anchor node that is not on the direct IP path between the =
MN and the CN.


















 


















See the CNet-Homing proposal. http://www.ietf.org/id=
/draft-yegin-dmm-cnet-homing-01.txt. We place the anchor in correspondi=
ng network, or the ISP serving that network.
 Therefore, the path going via that anchor does not cause triangulation. So=
me people may perceive that as locating the anchor in a central location (t=
hough this time it's not an "absolute/unchanging" center as impli=
ed in the current text).


















 


















Therefore I recommend the following revision:


















 












   RE=
Q1:  Distributed processing=



 =



       =
   IP mobility, network access and routing solutions provided by<=
/span>


       =
   DMM MUST enable distributed processing for mobility management=



       =
   so that traffic is not forced to traverse off-path


       =
   mobility anchors and thereby avoid non-optimal routes.<=
span lang=3D"FR">










 




















Alper


















 


















 


















 






















 






____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






 








--_000_6E31144C030982429702B11D6746B98C370D7943szxeml557mbxchi_--

From internet-drafts@ietf.org  Thu Nov  7 14:21:21 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1B911E8127; Thu,  7 Nov 2013 14:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.572
X-Spam-Level: 
X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZ902A1wD0JO; Thu,  7 Nov 2013 14:21:21 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EE221E80B6; Thu,  7 Nov 2013 14:21:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131107222120.21909.4219.idtracker@ietfa.amsl.com>
Date: Thu, 07 Nov 2013 14:21:20 -0800
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-10.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 07 Nov 2013 22:21:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Distributed Mobility Management Working G=
roup of the IETF.

	Title           : Requirements for Distributed Mobility Management
	Author(s)       : H Anthony Chan
                          Dapeng Liu
                          Pierrick Seite
                          Hidetoshi Yokota
                          Jouni Korhonen
	Filename        : draft-ietf-dmm-requirements-10.txt
	Pages           : 20
	Date            : 2013-11-07

Abstract:
   This document defines the requirements for Distributed Mobility
   Management (DMM).  The hierarchical structure in traditional wireless
   networks has led primarily to centralized deployment models.  As some
   wireless networks are evolving away from the hierarchical structure,
   such as in moving the content delivery servers closer to the users, a
   distributed model for mobility management can be useful to them.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-requirements-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-requirements-10


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 Peter.McCann@huawei.com  Sun Nov 10 15:14:13 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E36121E8178 for ; Sun, 10 Nov 2013 15:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIowoKwp4OU8 for ; Sun, 10 Nov 2013 15:14:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2AA21E817C for ; Sun, 10 Nov 2013 15:14:00 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAC72147; Sun, 10 Nov 2013 23:13:59 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 10 Nov 2013 23:13:06 +0000
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 10 Nov 2013 23:13:56 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Sun, 10 Nov 2013 15:13:45 -0800
From: Peter McCann 
To: "Sri Gundavelli (sgundave)" 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: Ac7Y3bqUR0J96RB8SmOZDtKQ9LtNUQADREFAABnu6gAAIMb+gAAAJPSAAAu8+IAAAIZpgAAFP1cAAFBGo4AAAmslAAA5YikAAA/fl8AAFGnLAAAQoWLQAFZl+QAAAMtAAAAAT0YAAA0Dp4D//7zUAIAAWAQg
Date: Sun, 10 Nov 2013 23:13:44 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485CF@dfweml511-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.246.215]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 10 Nov 2013 23:14:13 -0000

Hi, Sri,

I think you will agree that PMIP is a control protocol for setting up
tunnels.  A tunnel implies that we are not using the destination IP
of the inner packet for routing and by definition will lead to a non-optima=
l
route and a bit of state on some box that can fail and lose that state.

I hope that DMM can consider other approaches such as injecting routes
from the latest L2-attachment point into the access network, which is
a truly Distributed Mobility Management protocol for getting the packets
to the mobile node.  It will lead to more optimal routes and more robust
fault-tolerant operation of the network.

I think we can continue to use the term MAG to apply to that first-hop
router which is hopefully co-located with the L2 termination point (it
may not be so in every technology depending on the extent to which that
technology has evolved to support truly Distributed operation).  Anything
that happens below the MAG (between the MAG and the L2 termination point)
should be out of scope and we should not define any protocol there and we
should discourage any separation between the two.

However, we should not require the MAG to run any form of PMIP because=20
tunnels should not be required in the architecture.  We should not require
an LMA, because this would imply a central point of state maintenance and
possibility of failure.

It is fine to consider a split between CP and DP but I thought we had agree=
d
that any discussion of the protocol to use on such an interface would be
out of scope for this WG.  IMHO we should leave that to the Wireless & Mobi=
le
Working Group of ONF.

Now, the proponents of OpenFlow and other CP/DP splits have argued that it =
is
better to centralize the algorithms such as routing protocols on a logicall=
y
centralized server or servers with a synchronized global view of the networ=
k.
I have no problem with that, in which case this centralized controller just=
=20
needs to get notified about the MN's current attachment point, so it can in=
stall
the routes (or tunnels, if an operator wishes to use them) into the DP.  Bu=
t,
the mechanisms for doing so are out of scope for the DMM WG because we are =
not
working on a CP/DP split.  I think it would be appropriate for the DMM WG (=
which
exists in the IETF, a standards body that has a long history of developing=
=20
distributed and fault-tolerant routing protocols) to describe a more distri=
buted=20
alternative, building on foundational Internet technologies such as I-BGP, =
in
such a way that will bring down the costs, reduce the latency, and increase=
 the
robustness of wireless access networks.

I actually don't think we need to define any new extensions or IEs for BGP;=
 I
would like to read more about Ryuji's proposed extensions here.  All we nee=
d is
for the MAG to learn what IPs have been assigned to the MN, decide which of=
 those
IPs are in the scope of the local AS, and inject routes for those prefixes =
to
itself.  We could work on alternative mechanisms for discovering this list =
of
addresses - the fundamental requirement is that we use an authenticated MN =
ID
(probably an NAI) as an index to lookup the set of IPs in a distributed dat=
abase.
I've proposed using DNS for this but there are other alternatives.  We also=
 need
a way to make sure the latest UPDATE gets used by all the BGP peers.  I've =
proposed
putting a timestamp in LOCAL_PREF but there are probably other alternatives=
.

It would also be nice to have a well-defined fall-back mechanism in case th=
e MN
moves to a different AS or just too far from the original MAG, in which cas=
e the
I-BGP approach wouldn't scale.  For these cases, I think a client MIP tunne=
l to
an HA located in the original AS for each assigned IP address would be idea=
l.
The HA can behave just like the MAGs in that domain, injecting routes when =
MNs
establish tunnels to it so as to attract the packets to themselves (this wo=
uld
be the routing equivalent of the proxy-ARP or proxy-ND mechanism that works=
 on
just a single home link in MIPv4 or MIPv6).  We should work on mechanisms t=
o enable
dynamic assignment of local HAs to MNs and dynamic establishment of securit=
y associations
that don't require AAA and associated round-trips to the home network.  Bec=
ause the HA
is associated with the original MAG that assigned the address, this may inv=
olve
some DHCP extensions.  There is already a way to assign the HA IP address b=
ut we
will need new extensions to carry the HA credentials to the MN (maybe just =
an HA DNS
name so the MN can use DANE to retrieve a public key).

I think something like the path I've outlined above would make a good work =
plan
for the future of DMM.

-Pete




Sri Gundavelli (sgundave) wrote:
> Hi Pete,
>=20
> The "D" in DMM to me is "Distributed Data Plane". Your observation on
> my antithetical approach towards "D" is true for control plane. As
> that is not aligned with the current industry direction. When the CP
> is distributed, the cost of the network goes up 10-fold. Running
> policy interfaces to every distributed node is a operational
> nightmare. We bring the CP together for orchestration and enabling
> SDN. We distribute the DP for simplifying the forwarding plane and for
> realizing an optimized routing plane. I assumed you are OK with this.
>=20
>> Also, we should not require the MAG to run PMIP.
>=20
>=20
> I think there is a slight disconnect here. I suspect you want a CP/DP
> based access architecture. But, you want a OpenFlow interface between
> the CP and DP nodes, or may be piggyback the routing protocols along
> the lines of Ryuji's view. My proposal is not about mandating PMIP
> between CP and DP, but rather PMIP stays in the control plane between
> a MAG and LMA, but between MAG-CP and MAG-DP, it can be any interface.
> Between a MAG-CP and a MAG-DP, this could be CAPWAP for WLAN, OpenFlow
> in some other access, some other approach or routing approach. From
> this WG point of view, we can define high-level messaging
> structure/IE's and map them to the respective protocols. This is
> consistent with my approach for CAPWAP Split, or PMIP split approaches.
> Does this work for you ?
>=20
>=20
> Regards
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On 11/10/13 11:27 AM, "Peter McCann"  wrote:
>=20
>> Hi, Sri,
>>=20
>> I think the chain of gateways you have listed is exactly the source
>> of the problem we are trying to solve, and are antithetical to the D
>> in DMM.
>>=20
>> Perhaps we should stick with the term MAG, since that is what we use in
>> the IETF mobility work, and agree not to talk about what happens
>> between the L2-termination point and the MAG.  In my opinion the MAG
>> should be co-located on the L2-termination point and that is the model
>> I am mentally using.
>>=20
>> Also, we should not require the MAG to run PMIP.  There have been 2
>> proposals to inject routes from the attachment point instead of
>> initiating tunnels and I think those should be in-scope.
>>=20
>> -Pete




From sgundave@cisco.com  Mon Nov 11 07:30:05 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982BB11E818C for ; Mon, 11 Nov 2013 07:30:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hta08kLnb7FN for ; Mon, 11 Nov 2013 07:30:00 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 75A6521E80A1 for ; Mon, 11 Nov 2013 07:29:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5846; q=dns/txt; s=iport; t=1384183797; x=1385393397; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=krLiQuXMdAL4dNpKgXSm9SBnJRqbKpu5Aq60vGAfSTs=; b=RL9NLGsNHufR2kUn+oLuUnFP4c7qKfDav5q0EwL+19tqgytj+YVfDbt/ UaFN/3qihrrgHs7kSbaanKyDTf+uFcITHolnARU97w2vXld04s3usNTF7 UzMWvbVVfy8HIQHyK5ZV0ExJworDVgWRN3bcXnkQYx9XEPAMmFZ8TiPPS c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAFP3gFKtJV2d/2dsb2JhbABZgweBC78XgToWdIIsOj8SAQgSJEIXDgIECgQFiAG+FI9nB4QwA5gPkgqDJoIq
X-IronPort-AV: E=Sophos;i="4.93,678,1378857600"; d="scan'208";a="283316879"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 11 Nov 2013 15:29:57 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rABFTuh4029436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 15:29:56 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 09:29:56 -0600
From: "Sri Gundavelli (sgundave)" 
To: Peter McCann 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO3vLfMbtoHxXoFU2lz0O+EaSnrg==
Date: Mon, 11 Nov 2013 15:29:55 +0000
Message-ID: 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.214]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <84EA1DF6BA11F24AB1F5CB0AD4515507@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2013 15:30:05 -0000

Hi Pete,

I'm not sure, I agree with this, or understand this to be precise. I do
not know know CP (in the form of PMIP, GTP or some other protocol XYZ) can
be completely eliminated. There needs to be some interface between the
access gateway and the mobility anchor. I assumed your's, Marco's and
Ryuji's goal is for eliminating the tunnel, which I don't believe it can
be achieved, but still thought we can discuss this. IMO, its not just
about inserting a RIB route and redistributing it, but even there in DP
there is a state transfer needed  from the CP and the DP. Starting point
appears like a simple route propagation, very soon it will end up with a
bunch of state that gets moved between the two nodes.  But, may be I don't
understand the ideas clearly on eliminating CP and eliminating tunnels.
I'm not going to oppose this, I don't see this converging, IMHO.


=20

Regards
Sri



On 11/10/13 3:13 PM, "Peter McCann"  wrote:

>Hi, Sri,
>
>I think you will agree that PMIP is a control protocol for setting up
>tunnels.  A tunnel implies that we are not using the destination IP
>of the inner packet for routing and by definition will lead to a
>non-optimal
>route and a bit of state on some box that can fail and lose that state.
>
>I hope that DMM can consider other approaches such as injecting routes
>from the latest L2-attachment point into the access network, which is
>a truly Distributed Mobility Management protocol for getting the packets
>to the mobile node.  It will lead to more optimal routes and more robust
>fault-tolerant operation of the network.
>
>I think we can continue to use the term MAG to apply to that first-hop
>router which is hopefully co-located with the L2 termination point (it
>may not be so in every technology depending on the extent to which that
>technology has evolved to support truly Distributed operation).  Anything
>that happens below the MAG (between the MAG and the L2 termination point)
>should be out of scope and we should not define any protocol there and we
>should discourage any separation between the two.
>
>However, we should not require the MAG to run any form of PMIP because
>tunnels should not be required in the architecture.  We should not require
>an LMA, because this would imply a central point of state maintenance and
>possibility of failure.
>
>It is fine to consider a split between CP and DP but I thought we had
>agreed
>that any discussion of the protocol to use on such an interface would be
>out of scope for this WG.  IMHO we should leave that to the Wireless &
>Mobile
>Working Group of ONF.
>
>Now, the proponents of OpenFlow and other CP/DP splits have argued that
>it is
>better to centralize the algorithms such as routing protocols on a
>logically
>centralized server or servers with a synchronized global view of the
>network.
>I have no problem with that, in which case this centralized controller
>just=20
>needs to get notified about the MN's current attachment point, so it can
>install
>the routes (or tunnels, if an operator wishes to use them) into the DP.
>But,
>the mechanisms for doing so are out of scope for the DMM WG because we
>are not
>working on a CP/DP split.  I think it would be appropriate for the DMM WG
>(which
>exists in the IETF, a standards body that has a long history of
>developing=20
>distributed and fault-tolerant routing protocols) to describe a more
>distributed=20
>alternative, building on foundational Internet technologies such as
>I-BGP, in
>such a way that will bring down the costs, reduce the latency, and
>increase the
>robustness of wireless access networks.
>
>I actually don't think we need to define any new extensions or IEs for
>BGP; I
>would like to read more about Ryuji's proposed extensions here.  All we
>need is
>for the MAG to learn what IPs have been assigned to the MN, decide which
>of those
>IPs are in the scope of the local AS, and inject routes for those
>prefixes to
>itself.  We could work on alternative mechanisms for discovering this
>list of
>addresses - the fundamental requirement is that we use an authenticated
>MN ID
>(probably an NAI) as an index to lookup the set of IPs in a distributed
>database.
>I've proposed using DNS for this but there are other alternatives.  We
>also need
>a way to make sure the latest UPDATE gets used by all the BGP peers.
>I've proposed
>putting a timestamp in LOCAL_PREF but there are probably other
>alternatives.
>
>It would also be nice to have a well-defined fall-back mechanism in case
>the MN
>moves to a different AS or just too far from the original MAG, in which
>case the
>I-BGP approach wouldn't scale.  For these cases, I think a client MIP
>tunnel to
>an HA located in the original AS for each assigned IP address would be
>ideal.
>The HA can behave just like the MAGs in that domain, injecting routes
>when MNs
>establish tunnels to it so as to attract the packets to themselves (this
>would
>be the routing equivalent of the proxy-ARP or proxy-ND mechanism that
>works on
>just a single home link in MIPv4 or MIPv6).  We should work on mechanisms
>to enable
>dynamic assignment of local HAs to MNs and dynamic establishment of
>security associations
>that don't require AAA and associated round-trips to the home network.
>Because the HA
>is associated with the original MAG that assigned the address, this may
>involve
>some DHCP extensions.  There is already a way to assign the HA IP address
>but we
>will need new extensions to carry the HA credentials to the MN (maybe
>just an HA DNS
>name so the MN can use DANE to retrieve a public key).
>
>I think something like the path I've outlined above would make a good
>work plan
>for the future of DMM.
>
>-Pete
>


From alexandru.petrescu@gmail.com  Mon Nov 11 07:51:59 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DDD521F9FFF for ; Mon, 11 Nov 2013 07:51:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.251
X-Spam-Level: 
X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vz6m9ia0aX66 for ; Mon, 11 Nov 2013 07:51:54 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id BE52521F9C78 for ; Mon, 11 Nov 2013 07:51:50 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rABFpaNu029819; Mon, 11 Nov 2013 16:51:36 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 91AEC201D67; Mon, 11 Nov 2013 16:51:46 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 8424A201534; Mon, 11 Nov 2013 16:51:46 +0100 (CET)
Received: from [127.0.0.1] ([132.166.86.26]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rABFpQMa018825; Mon, 11 Nov 2013 16:51:35 +0100
Message-ID: <5280FCFD.103@gmail.com>
Date: Mon, 11 Nov 2013 16:51:25 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" , Peter McCann 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2013 15:51:59 -0000

Le 11/11/2013 16:29, Sri Gundavelli (sgundave) a écrit :
> Hi Pete,
>
> I'm not sure, I agree with this, or understand this to be precise. I
>  do not know know CP (in the form of PMIP, GTP or some other protocol
>  XYZ) can be completely eliminated. There needs to be some interface
>  between the access gateway and the mobility anchor. I assumed
> your's, Marco's and Ryuji's goal is for eliminating the tunnel,
> which I don't believe it can be achieved, but still thought we can
> discuss this. IMO, its not just about inserting a RIB route and
> redistributing it, but even there in DP there is a state transfer
> needed  from the CP and the DP. Starting point appears like a simple
> route propagation, very soon it will end up with a bunch of state
> that gets moved between the two nodes.  But, may be I don't
> understand the ideas clearly on eliminating CP and eliminating
> tunnels. I'm not going to oppose this, I don't see this converging,
> IMHO.

I think it may converge.

I am not sure whether we have reached a point where we can discuss
without assuming a particular protocol (i.e. neither MIP, nor BGP), but
I think we can discuss route update method vs tunnel-based method.

We can also discuss whether new functionality is needed on the mobile
entity, vs whether the first-hop router does much on its behalf
('proxy').  Which may bring in a question of whether a Mobile Host or a
Mobile Router is considered.

Effects of route updates may be too heavy on a network ('route churn')
or less so; it may depend, among several factors, on the topology and
the addressing architecture of the fixed network.

Routing protocols are highly distributed concepts, yet many include
particularly designated entities, which have particular roles (not all
routers are equal) - these could host what we expect to be more
controlling points.

Alex

>
>
>
>
> Regards Sri
>
>
>
> On 11/10/13 3:13 PM, "Peter McCann"  wrote:
>
>> Hi, Sri,
>>
>> I think you will agree that PMIP is a control protocol for setting
>>  up tunnels.  A tunnel implies that we are not using the
>> destination IP of the inner packet for routing and by definition
>> will lead to a non-optimal route and a bit of state on some box
>> that can fail and lose that state.
>>
>> I hope that DMM can consider other approaches such as injecting
>> routes from the latest L2-attachment point into the access network,
>> which is a truly Distributed Mobility Management protocol for
>> getting the packets to the mobile node.  It will lead to more
>> optimal routes and more robust fault-tolerant operation of the
>> network.
>>
>> I think we can continue to use the term MAG to apply to that
>> first-hop router which is hopefully co-located with the L2
>> termination point (it may not be so in every technology depending
>> on the extent to which that technology has evolved to support truly
>> Distributed operation).  Anything that happens below the MAG
>> (between the MAG and the L2 termination point) should be out of
>> scope and we should not define any protocol there and we should
>> discourage any separation between the two.
>>
>> However, we should not require the MAG to run any form of PMIP
>> because tunnels should not be required in the architecture.  We
>> should not require an LMA, because this would imply a central point
>> of state maintenance and possibility of failure.
>>
>> It is fine to consider a split between CP and DP but I thought we
>> had agreed that any discussion of the protocol to use on such an
>> interface would be out of scope for this WG.  IMHO we should leave
>>  that to the Wireless & Mobile Working Group of ONF.
>>
>> Now, the proponents of OpenFlow and other CP/DP splits have argued
>>  that it is better to centralize the algorithms such as routing
>> protocols on a logically centralized server or servers with a
>> synchronized global view of the network. I have no problem with
>> that, in which case this centralized controller just needs to get
>> notified about the MN's current attachment point, so it can
>> install the routes (or tunnels, if an operator wishes to use them)
>> into the DP. But, the mechanisms for doing so are out of scope for
>> the DMM WG because we are not working on a CP/DP split.  I think it
>> would be appropriate for the DMM WG (which exists in the IETF, a
>> standards body that has a long history of developing distributed
>> and fault-tolerant routing protocols) to describe a more
>> distributed alternative, building on foundational Internet
>> technologies such as I-BGP, in such a way that will bring down the
>>  costs, reduce the latency, and increase the robustness of wireless
>>  access networks.
>>
>> I actually don't think we need to define any new extensions or IEs
>>  for BGP; I would like to read more about Ryuji's proposed
>> extensions here.  All we need is for the MAG to learn what IPs have
>> been assigned to the MN, decide which of those IPs are in the scope
>> of the local AS, and inject routes for those prefixes to itself. We
>> could work on alternative mechanisms for discovering this list of
>> addresses - the fundamental requirement is that we use an
>> authenticated MN ID (probably an NAI) as an index to lookup the set
>> of IPs in a distributed database. I've proposed using DNS for this
>> but there are other alternatives.  We also need a way to make sure
>> the latest UPDATE gets used by all the BGP peers. I've proposed
>> putting a timestamp in LOCAL_PREF but there are probably other
>> alternatives.
>>
>> It would also be nice to have a well-defined fall-back mechanism in
>> case the MN moves to a different AS or just too far from the
>> original MAG, in which case the I-BGP approach wouldn't scale. For
>> these cases, I think a client MIP tunnel to an HA located in the
>> original AS for each assigned IP address would be ideal. The HA can
>> behave just like the MAGs in that domain, injecting routes when MNs
>> establish tunnels to it so as to attract the packets to themselves
>> (this would be the routing equivalent of the proxy-ARP or proxy-ND
>> mechanism that works on just a single home link in MIPv4 or MIPv6).
>> We should work on mechanisms to enable dynamic assignment of local
>> HAs to MNs and dynamic establishment of security associations that
>> don't require AAA and associated round-trips to the home network.
>> Because the HA is associated with the original MAG that assigned
>> the address, this may involve some DHCP extensions.  There is
>> already a way to assign the HA IP address but we will need new
>> extensions to carry the HA credentials to the MN (maybe just an HA
>> DNS name so the MN can use DANE to retrieve a public key).
>>
>> I think something like the path I've outlined above would make a
>> good work plan for the future of DMM.
>>
>> -Pete
>>
>
> _______________________________________________ dmm mailing list
> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>
>



From sgundave@cisco.com  Mon Nov 11 08:08:21 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B0E11E810B for ; Mon, 11 Nov 2013 08:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.561
X-Spam-Level: 
X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySr0Du3uzFgx for ; Mon, 11 Nov 2013 08:08:16 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCC421E8064 for ; Mon, 11 Nov 2013 08:08:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1314; q=dns/txt; s=iport; t=1384186096; x=1385395696; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=hzlrxTV2RfVhDuFFoFDlPJ1ZlTb0xVcB+R8x17h2A3w=; b=Mvtds0FfOfYVtpb00eZ5KrkYl/k1WLlwxjWXjK3ONUBLnydq7XlmW5I6 HFzDHwFW3grYFtjSE8Dhe2+xkj3J5fHjFSU5E479RrAuC6wjHa1cSOYXN VVseLVVMMdOvsSb6hRGoKoQ4gTmL+56RDOpeE9wdv1WgQNKJ6DfiVfgmD s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhYFAIv/gFKtJXG//2dsb2JhbABZgweBC78XgTsWdIIsOj8SAQgSJDERFw4CBAENBYdvAw+0fg2JFYx1gnIHhDADliSBa4xShTiDJoIq
X-IronPort-AV: E=Sophos;i="4.93,678,1378857600"; d="scan'208";a="283294770"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 11 Nov 2013 16:08:06 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rABG869P013457 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 16:08:06 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 10:08:06 -0600
From: "Sri Gundavelli (sgundave)" 
To: Alexandru Petrescu , Peter McCann 
Thread-Topic: [DMM] Preparing for DMM future steps and rechartering
Thread-Index: AQHO3vg0wVsaqgXwp06clCOdJOLlpQ==
Date: Mon, 11 Nov 2013 16:08:05 +0000
Message-ID: 
In-Reply-To: <5280FCFD.103@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.214]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7D088DE9E34EF9418E88FBDCB6C0C646@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2013 16:08:22 -0000

Alex - So, the proposal is to get rid of the MIP signaling plane and
piggyback on some routing updates, or over OpenFlow ? So, what is the
result, we use a generic non-MIP interfaces and make them look like MIP
interfaces ? What is the point ? This is DMM ?


Regards
Sri




On 11/11/13 7:51 AM, "Alexandru Petrescu" 
wrote:

>
>I think it may converge.
>
>I am not sure whether we have reached a point where we can discuss
>without assuming a particular protocol (i.e. neither MIP, nor BGP), but
>I think we can discuss route update method vs tunnel-based method.
>
>We can also discuss whether new functionality is needed on the mobile
>entity, vs whether the first-hop router does much on its behalf
>('proxy').  Which may bring in a question of whether a Mobile Host or a
>Mobile Router is considered.
>
>Effects of route updates may be too heavy on a network ('route churn')
>or less so; it may depend, among several factors, on the topology and
>the addressing architecture of the fixed network.
>
>Routing protocols are highly distributed concepts, yet many include
>particularly designated entities, which have particular roles (not all
>routers are equal) - these could host what we expect to be more
>controlling points.
>
>Alex
>
>>


From alexandru.petrescu@gmail.com  Mon Nov 11 08:42:20 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE58911E8163 for ; Mon, 11 Nov 2013 08:42:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.251
X-Spam-Level: 
X-Spam-Status: No, score=-10.251 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUcl2AG+jSYZ for ; Mon, 11 Nov 2013 08:42:14 -0800 (PST)
Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF8411E81B4 for ; Mon, 11 Nov 2013 08:42:13 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rABGg5P1008798; Mon, 11 Nov 2013 17:42:05 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E2F3B201C85; Mon, 11 Nov 2013 17:42:15 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id D38FC200F48; Mon, 11 Nov 2013 17:42:15 +0100 (CET)
Received: from [127.0.0.1] ([132.166.86.12]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rABGfvsg000551; Mon, 11 Nov 2013 17:42:05 +0100
Message-ID: <528108D5.50606@gmail.com>
Date: Mon, 11 Nov 2013 17:41:57 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: "Sri Gundavelli (sgundave)" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Peter McCann , "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2013 16:42:21 -0000

Sri,

Sorry if my mail was too direct.  It is not my intention to suggest
getting rid of anything.

Frankly speaking I don't know what DMM is, and I still have to review
the draft-ietf-dmm-best-practices-gap-analysis-02

Whenever one says one particular protocol I have a problem with each.
For example, but just an example, I have growing problems articulating
an explanation of the lack of MIP deployment.

Deployment, testing and prototype interest are valuable indicators.

Alex

Le 11/11/2013 17:08, Sri Gundavelli (sgundave) a écrit :
> Alex - So, the proposal is to get rid of the MIP signaling plane and
> piggyback on some routing updates, or over OpenFlow ? So, what is the
> result, we use a generic non-MIP interfaces and make them look like
> MIP interfaces ? What is the point ? This is DMM ?
>
>
> Regards Sri
>
>
>
>
> On 11/11/13 7:51 AM, "Alexandru Petrescu"
>  wrote:
>
>>
>> I think it may converge.
>>
>> I am not sure whether we have reached a point where we can discuss
>> without assuming a particular protocol (i.e. neither MIP, nor BGP),
>> but I think we can discuss route update method vs tunnel-based
>> method.
>>
>> We can also discuss whether new functionality is needed on the
>> mobile entity, vs whether the first-hop router does much on its
>> behalf ('proxy').  Which may bring in a question of whether a
>> Mobile Host or a Mobile Router is considered.
>>
>> Effects of route updates may be too heavy on a network ('route
>> churn') or less so; it may depend, among several factors, on the
>> topology and the addressing architecture of the fixed network.
>>
>> Routing protocols are highly distributed concepts, yet many
>> include particularly designated entities, which have particular
>> roles (not all routers are equal) - these could host what we expect
>> to be more controlling points.
>>
>> Alex
>>
>>>
>
>
>



From sarikaya2012@gmail.com  Mon Nov 11 12:10:18 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A9921E813A for ; Mon, 11 Nov 2013 12:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.292
X-Spam-Level: 
X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enFm3CRrpFh3 for ; Mon, 11 Nov 2013 12:10:17 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 84A1B21E8248 for ; Mon, 11 Nov 2013 12:10:08 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id n7so3300459lam.2 for ; Mon, 11 Nov 2013 12:10:07 -0800 (PST)
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=A4nn6zHreZDeLM/Nai/mMQFOt2btXh0WnF50m13d6zc=; b=E6dEcChw5tVdaLiM/BkIVbB7jch1l+zjVLe2VMp3OZg4yxUzasyo3DDSK+v3GVK/Vq W/ZgSSeof4JXMvIw72OmPbRHaVMKSs36pev2dyBAqNy5CNxl5jyEmdYeuO/9yRuib2yx 7iPr1OACivSEIAcrSdEjjznpozA9F1e8yJ1op+qSBJXVkVOd/w3P0o0WPpeRHCHRlG+R uZMglctQCGmcUU2aXUDsQ80/z4mRPVNbezxeJJC7ssVg0JLXsiVCXHbtzCV/1DFl6Z0w g68JUBSVo6gPmjJvlM0Gb0941dluDjNeHIPCqQcljgsGeP766CuP5a2KK0vpO3gqO7OL qU/Q==
MIME-Version: 1.0
X-Received: by 10.112.205.34 with SMTP id ld2mr6451952lbc.27.1384200607387; Mon, 11 Nov 2013 12:10:07 -0800 (PST)
Received: by 10.114.217.129 with HTTP; Mon, 11 Nov 2013 12:10:07 -0800 (PST)
In-Reply-To: 
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com> 
Date: Mon, 11 Nov 2013 14:10:07 -0600
Message-ID: 
From: Behcet Sarikaya 
To: "Sri Gundavelli (sgundave)" 
Content-Type: multipart/alternative; boundary=001a11c3d99a80552404eaec519e
Cc: Peter McCann , "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 11 Nov 2013 20:10:18 -0000

--001a11c3d99a80552404eaec519e
Content-Type: text/plain; charset=ISO-8859-1

I think we need a draft from Pete on this so we can all understand what is
being proposed.

Regards,

Behcet


On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave) <
sgundave@cisco.com> wrote:

> Hi Pete,
>
> I'm not sure, I agree with this, or understand this to be precise. I do
> not know know CP (in the form of PMIP, GTP or some other protocol XYZ) can
> be completely eliminated. There needs to be some interface between the
> access gateway and the mobility anchor. I assumed your's, Marco's and
> Ryuji's goal is for eliminating the tunnel, which I don't believe it can
> be achieved, but still thought we can discuss this. IMO, its not just
> about inserting a RIB route and redistributing it, but even there in DP
> there is a state transfer needed  from the CP and the DP. Starting point
> appears like a simple route propagation, very soon it will end up with a
> bunch of state that gets moved between the two nodes.  But, may be I don't
> understand the ideas clearly on eliminating CP and eliminating tunnels.
> I'm not going to oppose this, I don't see this converging, IMHO.
>
>
>
>
> Regards
> Sri
>
>
>
> On 11/10/13 3:13 PM, "Peter McCann"  wrote:
>
> >Hi, Sri,
> >
> >I think you will agree that PMIP is a control protocol for setting up
> >tunnels.  A tunnel implies that we are not using the destination IP
> >of the inner packet for routing and by definition will lead to a
> >non-optimal
> >route and a bit of state on some box that can fail and lose that state.
> >
> >I hope that DMM can consider other approaches such as injecting routes
> >from the latest L2-attachment point into the access network, which is
> >a truly Distributed Mobility Management protocol for getting the packets
> >to the mobile node.  It will lead to more optimal routes and more robust
> >fault-tolerant operation of the network.
> >
> >I think we can continue to use the term MAG to apply to that first-hop
> >router which is hopefully co-located with the L2 termination point (it
> >may not be so in every technology depending on the extent to which that
> >technology has evolved to support truly Distributed operation).  Anything
> >that happens below the MAG (between the MAG and the L2 termination point)
> >should be out of scope and we should not define any protocol there and we
> >should discourage any separation between the two.
> >
> >However, we should not require the MAG to run any form of PMIP because
> >tunnels should not be required in the architecture.  We should not require
> >an LMA, because this would imply a central point of state maintenance and
> >possibility of failure.
> >
> >It is fine to consider a split between CP and DP but I thought we had
> >agreed
> >that any discussion of the protocol to use on such an interface would be
> >out of scope for this WG.  IMHO we should leave that to the Wireless &
> >Mobile
> >Working Group of ONF.
> >
> >Now, the proponents of OpenFlow and other CP/DP splits have argued that
> >it is
> >better to centralize the algorithms such as routing protocols on a
> >logically
> >centralized server or servers with a synchronized global view of the
> >network.
> >I have no problem with that, in which case this centralized controller
> >just
> >needs to get notified about the MN's current attachment point, so it can
> >install
> >the routes (or tunnels, if an operator wishes to use them) into the DP.
> >But,
> >the mechanisms for doing so are out of scope for the DMM WG because we
> >are not
> >working on a CP/DP split.  I think it would be appropriate for the DMM WG
> >(which
> >exists in the IETF, a standards body that has a long history of
> >developing
> >distributed and fault-tolerant routing protocols) to describe a more
> >distributed
> >alternative, building on foundational Internet technologies such as
> >I-BGP, in
> >such a way that will bring down the costs, reduce the latency, and
> >increase the
> >robustness of wireless access networks.
> >
> >I actually don't think we need to define any new extensions or IEs for
> >BGP; I
> >would like to read more about Ryuji's proposed extensions here.  All we
> >need is
> >for the MAG to learn what IPs have been assigned to the MN, decide which
> >of those
> >IPs are in the scope of the local AS, and inject routes for those
> >prefixes to
> >itself.  We could work on alternative mechanisms for discovering this
> >list of
> >addresses - the fundamental requirement is that we use an authenticated
> >MN ID
> >(probably an NAI) as an index to lookup the set of IPs in a distributed
> >database.
> >I've proposed using DNS for this but there are other alternatives.  We
> >also need
> >a way to make sure the latest UPDATE gets used by all the BGP peers.
> >I've proposed
> >putting a timestamp in LOCAL_PREF but there are probably other
> >alternatives.
> >
> >It would also be nice to have a well-defined fall-back mechanism in case
> >the MN
> >moves to a different AS or just too far from the original MAG, in which
> >case the
> >I-BGP approach wouldn't scale.  For these cases, I think a client MIP
> >tunnel to
> >an HA located in the original AS for each assigned IP address would be
> >ideal.
> >The HA can behave just like the MAGs in that domain, injecting routes
> >when MNs
> >establish tunnels to it so as to attract the packets to themselves (this
> >would
> >be the routing equivalent of the proxy-ARP or proxy-ND mechanism that
> >works on
> >just a single home link in MIPv4 or MIPv6).  We should work on mechanisms
> >to enable
> >dynamic assignment of local HAs to MNs and dynamic establishment of
> >security associations
> >that don't require AAA and associated round-trips to the home network.
> >Because the HA
> >is associated with the original MAG that assigned the address, this may
> >involve
> >some DHCP extensions.  There is already a way to assign the HA IP address
> >but we
> >will need new extensions to carry the HA credentials to the MN (maybe
> >just an HA DNS
> >name so the MN can use DANE to retrieve a public key).
> >
> >I think something like the path I've outlined above would make a good
> >work plan
> >for the future of DMM.
> >
> >-Pete
> >
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>

--001a11c3d99a80552404eaec519e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


I think we need a draft from Pete on this so we =
can all understand what is being proposed.

Regards,

Behcet



On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave) <sgundave@cisc=
o.com> wrote:

Hi Pete,



I'm not sure, I agree with this, or understand this to be precise. I do=


not know know CP (in the form of PMIP, GTP or some other protocol XYZ) can<=
br>
be completely eliminated. There needs to be some interface between the

access gateway and the mobility anchor. I assumed your's, Marco's a=
nd

Ryuji's goal is for eliminating the tunnel, which I don't believe i=
t can

be achieved, but still thought we can discuss this. IMO, its not just

about inserting a RIB route and redistributing it, but even there in DP

there is a state transfer needed =A0from the CP and the DP. Starting point<=
br>
appears like a simple route propagation, very soon it will end up with a
bunch of state that gets moved between the two nodes. =A0But, may be I don&=
#39;t

understand the ideas clearly on eliminating CP and eliminating tunnels.

I'm not going to oppose this, I don't see this converging, IMHO.








Regards

Sri








On 11/10/13 3:13 PM, "Peter McCann" <Peter.McCann@huawei.com> wrote:



>Hi, Sri,

>


>I think you will agree th=
at PMIP is a control protocol for setting up

>tunnels. =A0A tunnel implies that we are not using the destination IP
>of the inner packet for routing and by definition will lead to a

>non-optimal

>route and a bit of state on some box that can fail and lose that state.=


>

>I hope that DMM can consider other approaches such as injecting routes<=
br>
>from the latest L2-attachment point into the access network, which is
>a truly Distributed Mobility Management protocol for getting the packet=
s

>to the mobile node. =A0It will lead to more optimal routes and more rob=
ust

>fault-tolerant operation of the network.

>

>I think we can continue to use the term MAG to apply to that first-hop<=
br>
>router which is hopefully co-located with the L2 termination point (it<=
br>
>may not be so in every technology depending on the extent to which that=


>technology has evolved to support truly Distributed operation). =A0Anyt=
hing

>that happens below the MAG (between the MAG and the L2 termination poin=
t)

>should be out of scope and we should not define any protocol there and =
we

>should discourage any separation between the two.

>

>However, we should not require the MAG to run any form of PMIP because<=
br>
>tunnels should not be required in the architecture. =A0We should not re=
quire

>an LMA, because this would imply a central point of state maintenance a=
nd

>possibility of failure.

>

>It is fine to consider a split between CP and DP but I thought we had
>agreed

>that any discussion of the protocol to use on such an interface would b=
e

>out of scope for this WG. =A0IMHO we should leave that to the Wireless =
&

>Mobile

>Working Group of ONF.

>

>Now, the proponents of OpenFlow and other CP/DP splits have argued that=


>it is

>better to centralize the algorithms such as routing protocols on a

>logically

>centralized server or servers with a synchronized global view of the
>network.

>I have no problem with that, in which case this centralized controller<=
br>
>just

>needs to get notified about the MN's current attachment point, so i=
t can

>install

>the routes (or tunnels, if an operator wishes to use them) into the DP.=


>But,

>the mechanisms for doing so are out of scope for the DMM WG because we<=
br>
>are not

>working on a CP/DP split. =A0I think it would be appropriate for the DM=
M WG

>(which

>exists in the IETF, a standards body that has a long history of

>developing

>distributed and fault-tolerant routing protocols) to describe a more
>distributed

>alternative, building on foundational Internet technologies such as

>I-BGP, in

>such a way that will bring down the costs, reduce the latency, and

>increase the

>robustness of wireless access networks.

>

>I actually don't think we need to define any new extensions or IEs =
for

>BGP; I

>would like to read more about Ryuji's proposed extensions here. =A0=
All we

>need is

>for the MAG to learn what IPs have been assigned to the MN, decide whic=
h

>of those

>IPs are in the scope of the local AS, and inject routes for those

>prefixes to

>itself. =A0We could work on alternative mechanisms for discovering this=


>list of

>addresses - the fundamental requirement is that we use an authenticated=


>MN ID

>(probably an NAI) as an index to lookup the set of IPs in a distributed=


>database.

>I've proposed using DNS for this but there are other alternatives. =
=A0We

>also need

>a way to make sure the latest UPDATE gets used by all the BGP peers.
>I've proposed

>putting a timestamp in LOCAL_PREF but there are probably other

>alternatives.

>

>It would also be nice to have a well-defined fall-back mechanism in cas=
e

>the MN

>moves to a different AS or just too far from the original MAG, in which=


>case the

>I-BGP approach wouldn't scale. =A0For these cases, I think a client=
 MIP

>tunnel to

>an HA located in the original AS for each assigned IP address would be<=
br>
>ideal.

>The HA can behave just like the MAGs in that domain, injecting routes
>when MNs

>establish tunnels to it so as to attract the packets to themselves (thi=
s

>would

>be the routing equivalent of the proxy-ARP or proxy-ND mechanism that
>works on

>just a single home link in MIPv4 or MIPv6). =A0We should work on mechan=
isms

>to enable

>dynamic assignment of local HAs to MNs and dynamic establishment of

>security associations

>that don't require AAA and associated round-trips to the home netwo=
rk.

>Because the HA

>is associated with the original MAG that assigned the address, this may=


>involve

>some DHCP extensions. =A0There is already a way to assign the HA IP add=
ress

>but we

>will need new extensions to carry the HA credentials to the MN (maybe
>just an HA DNS

>name so the MN can use DANE to retrieve a public key).

>

>I think something like the path I've outlined above would make a go=
od

>work plan

>for the future of DMM.

>

>-Pete

>




_______________________=
________________________

dmm mailing list

dmm@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/dmm





--001a11c3d99a80552404eaec519e--

From Peter.McCann@huawei.com  Mon Nov 11 13:17:54 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D9711E817D for ; Mon, 11 Nov 2013 13:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpXhI0rFlUxa for ; Mon, 11 Nov 2013 13:17:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4489011E8145 for ; Mon, 11 Nov 2013 13:17:46 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAD70365; Mon, 11 Nov 2013 21:17:43 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:17:31 +0000
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:17:42 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 13:17:38 -0800
From: Peter McCann 
To: "Sri Gundavelli (sgundave)" 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: Ac7Y3bqUR0J96RB8SmOZDtKQ9LtNUQADREFAABnu6gAAIMb+gAAAJPSAAAu8+IAAAIZpgAAFP1cAAFBGo4AAAmslAAA5YikAAA/fl8AAFGnLAAAQoWLQAFZl+QAAAMtAAAAAT0YAAA0Dp4D//7zUAIAAWAQggADyaICAACee0A==
Date: Mon, 11 Nov 2013 21:17:37 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.245.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2013 21:17:54 -0000

Hi, Sri,

Sri Gundavelli (sgundave) wrote:
> Hi Pete,
>=20
> I'm not sure, I agree with this, or understand this to be precise. I do
> not know know CP (in the form of PMIP, GTP or some other protocol XYZ)
> can be completely eliminated. There needs to be some interface between
> the access gateway and the mobility anchor.=20

As I said in jabber during the meeting we need to carefully define these
terms.

Let's try to use the term MAG consistently.  It means the first node that
can see IP packets from the MN.  In my mind this should be co-located with
the L2 termination point.

As for "mobility anchor" I am not sure what is your definition of that term=
.
If you mean some router in the network that the packets for a given MN's
assigned IP address are delivered, then that entity can change over the=20
period of time the address is assigned to a given MN.  IMHO when the addres=
s
is assigned, that node should be the MAG to which the MN is attached at the
time of assignment.  You can do this by choosing the pool of addresses that
are normally routed to the MAG.  When the MN moves, the "mobility anchor"
can be changed if the routing tables are updated.

> I assumed your's, Marco's
> and Ryuji's goal is for eliminating the tunnel, which I don't believe it
> can be achieved, but still thought we can discuss this.=20

If we can change the "mobility anchor" to always be the current MAG while
the MN is in the same domain (or perhaps the same part of a domain) then
there will not be a need for tunnels during that period of time.  You need
a tunnel when you move outside the domain under which routing protocols are
scalable.  This can be a client-MIP tunnel because there won't be much need
to update it, assuming the new CoA is managed in the same way by whatever
network the MN is on at that time.

> IMO, its not
> just about inserting a RIB route and redistributing it, but even there
> in DP there is a state transfer needed  from the CP and the DP. Starting
> point appears like a simple route propagation, very soon it will end up
> with a bunch of state that gets moved between the two nodes. =20

MAG authenticates the MN when it attaches/moves in.  Authentication gives
an MN ID.  MN ID is used to lookup IP addresses currently assigned.  UPDATE
is generated for those IPs to attract packets to the current MAG.  Mission
accomplished.

> But, may
> be I don't understand the ideas clearly on eliminating CP and
> eliminating tunnels. I'm not going to oppose this, I don't see this
> converging, IMHO.

I think you mean the discussion will not converge, when Alex interpreted=20
this to mean the routing tables won't converge... anyway, I hope we can
consider routing protocols as one way to accomplish localized mobility
management.

-Pete

>=20
>=20
>=20
>=20
> Regards
> Sri
>=20
>=20
>=20
> On 11/10/13 3:13 PM, "Peter McCann"  wrote:
>=20
>> Hi, Sri,
>>=20
>> I think you will agree that PMIP is a control protocol for setting up
>> tunnels.  A tunnel implies that we are not using the destination IP of
>> the inner packet for routing and by definition will lead to a
>> non-optimal route and a bit of state on some box that can fail and lose
>> that state.
>>=20
>> I hope that DMM can consider other approaches such as injecting routes
>> from the latest L2-attachment point into the access network, which is a
>> truly Distributed Mobility Management protocol for getting the packets
>> to the mobile node.  It will lead to more optimal routes and more
>> robust fault-tolerant operation of the network.
>>=20
>> I think we can continue to use the term MAG to apply to that first-hop
>> router which is hopefully co-located with the L2 termination point (it
>> may not be so in every technology depending on the extent to which that
>> technology has evolved to support truly Distributed operation).
>> Anything that happens below the MAG (between the MAG and the L2
>> termination point) should be out of scope and we should not define any
>> protocol there and we should discourage any separation between the two.
>>=20
>> However, we should not require the MAG to run any form of PMIP because
>> tunnels should not be required in the architecture.  We should not
>> require an LMA, because this would imply a central point of state
>> maintenance and possibility of failure.
>>=20
>> It is fine to consider a split between CP and DP but I thought we had
>> agreed that any discussion of the protocol to use on such an interface
>> would be out of scope for this WG.  IMHO we should leave that to the
>> Wireless & Mobile Working Group of ONF.
>>=20
>> Now, the proponents of OpenFlow and other CP/DP splits have argued that
>> it is better to centralize the algorithms such as routing protocols on
>> a logically centralized server or servers with a synchronized global
>> view of the network. I have no problem with that, in which case this
>> centralized controller just needs to get notified about the MN's
>> current attachment point, so it can install the routes (or tunnels, if
>> an operator wishes to use them) into the DP. But, the mechanisms for
>> doing so are out of scope for the DMM WG because we are not working on
>> a CP/DP split.  I think it would be appropriate for the DMM WG (which
>> exists in the IETF, a standards body that has a long history of
>> developing distributed and fault-tolerant routing protocols) to
>> describe a more distributed alternative, building on foundational
>> Internet technologies such as I-BGP, in such a way that will bring down
>> the costs, reduce the latency, and increase the robustness of wireless
>> access networks.
>>=20
>> I actually don't think we need to define any new extensions or IEs for
>> BGP; I would like to read more about Ryuji's proposed extensions here.=20
>> All we need is for the MAG to learn what IPs have been assigned to the
>> MN, decide which of those IPs are in the scope of the local AS, and
>> inject routes for those prefixes to itself.  We could work on
>> alternative mechanisms for discovering this list of addresses - the
>> fundamental requirement is that we use an authenticated MN ID (probably
>> an NAI) as an index to lookup the set of IPs in a distributed database.
>> I've proposed using DNS for this but there are other alternatives.  We
>> also need a way to make sure the latest UPDATE gets used by all the BGP
>> peers. I've proposed putting a timestamp in LOCAL_PREF but there are
>> probably other alternatives.
>>=20
>> It would also be nice to have a well-defined fall-back mechanism in
>> case the MN moves to a different AS or just too far from the original
>> MAG, in which case the I-BGP approach wouldn't scale.  For these cases,
>> I think a client MIP tunnel to an HA located in the original AS for
>> each assigned IP address would be ideal. The HA can behave just like
>> the MAGs in that domain, injecting routes when MNs establish tunnels to
>> it so as to attract the packets to themselves (this would be the
>> routing equivalent of the proxy-ARP or proxy-ND mechanism that works on
>> just a single home link in MIPv4 or MIPv6).  We should work on
>> mechanisms to enable dynamic assignment of local HAs to MNs and dynamic
>> establishment of security associations that don't require AAA and
>> associated round-trips to the home network. Because the HA is
>> associated with the original MAG that assigned the address, this may
>> involve some DHCP extensions.  There is already a way to assign the HA
>> IP address but we will need new extensions to carry the HA credentials
>> to the MN (maybe just an HA DNS name so the MN can use DANE to retrieve
>> a public key).
>>=20
>> I think something like the path I've outlined above would make a good
>> work plan
>> for the future of DMM.
>>=20
>> -Pete
>>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm




From Peter.McCann@huawei.com  Mon Nov 11 13:22:51 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2721511E8103 for ; Mon, 11 Nov 2013 13:22:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8WgXw87tF2S for ; Mon, 11 Nov 2013 13:22:46 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9CF11E8114 for ; Mon, 11 Nov 2013 13:22:45 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAD70563; Mon, 11 Nov 2013 21:22:44 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:22:32 +0000
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:22:43 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 13:22:34 -0800
From: Peter McCann 
To: Alexandru Petrescu , "Sri Gundavelli (sgundave)" 
Thread-Topic: [DMM] Preparing for DMM future steps and rechartering
Thread-Index: AQHO3vXxu0AbZ8DtiEyWER4fydZmKpoguJiAgAAJd4D//8cVcA==
Date: Mon, 11 Nov 2013 21:22:34 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE717948764@dfweml511-mbs.china.huawei.com>
References:  <528108D5.50606@gmail.com>
In-Reply-To: <528108D5.50606@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.245.95]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2013 21:22:51 -0000

Hi, Alex,

When it comes to injecting routes into the routing infrastructure,=20
I think we have to use the "proxy" model.  It doesn't make sense for
the MN to be speaking to the access network's routing protocol.  This
means the MAG will need to authenticate the MN and check that the
IP addresses assigned to that MN ID were in fact really assigned to
that MN.  I think it can be done easily with forward/reverse DNS
lookups.

Sri, if we can make the tunnels a fall-back mechanism for use only
when the MN has moved too far to make the routing update scalable,
then yes, we can eliminate the PMIP signaling from the access network.
I think client MIP should be used when we need to fall back - especially
because there is likely to be no relationship between the previous and
new domains, other than the fact that they are both connected to the
Internet.

-Pete


Alexandru Petrescu wrote:
> Sri,
>=20
> Sorry if my mail was too direct.  It is not my intention to suggest
> getting rid of anything.
>=20
> Frankly speaking I don't know what DMM is, and I still have to review
> the draft-ietf-dmm-best-practices-gap-analysis-02
>=20
> Whenever one says one particular protocol I have a problem with each.
> For example, but just an example, I have growing problems articulating
> an explanation of the lack of MIP deployment.
>=20
> Deployment, testing and prototype interest are valuable indicators.
>=20
> Alex
>=20
> Le 11/11/2013 17:08, Sri Gundavelli (sgundave) a =E9crit :
>> Alex - So, the proposal is to get rid of the MIP signaling plane and
>> piggyback on some routing updates, or over OpenFlow ? So, what is
>> the result, we use a generic non-MIP interfaces and make them look
>> like MIP interfaces ? What is the point ? This is DMM ?
>>=20
>>=20
>> Regards Sri
>>=20
>>=20
>>=20
>>=20
>> On 11/11/13 7:51 AM, "Alexandru Petrescu"
>>  wrote:
>>=20
>>>=20
>>> I think it may converge.
>>>=20
>>> I am not sure whether we have reached a point where we can discuss
>>> without assuming a particular protocol (i.e. neither MIP, nor BGP),
>>> but I think we can discuss route update method vs tunnel-based
>>> method.
>>>=20
>>> We can also discuss whether new functionality is needed on the mobile
>>> entity, vs whether the first-hop router does much on its behalf
>>> ('proxy').  Which may bring in a question of whether a Mobile Host or
>>> a Mobile Router is considered.
>>>=20
>>> Effects of route updates may be too heavy on a network ('route
>>> churn') or less so; it may depend, among several factors, on the
>>> topology and the addressing architecture of the fixed network.
>>>=20
>>> Routing protocols are highly distributed concepts, yet many include
>>> particularly designated entities, which have particular roles (not
>>> all routers are equal) - these could host what we expect to be more
>>> controlling points.
>>>=20
>>> Alex
>>>=20
>>>>=20
>>=20
>>=20
>>=20
>




From Peter.McCann@huawei.com  Mon Nov 11 13:44:15 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB1711E8112 for ; Mon, 11 Nov 2013 13:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIVXdJQ9fCZS for ; Mon, 11 Nov 2013 13:44:11 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A6B4911E80F9 for ; Mon, 11 Nov 2013 13:44:10 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXT84140; Mon, 11 Nov 2013 21:44:03 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:43:49 +0000
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 21:44:00 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 13:43:52 -0800
From: Peter McCann 
To: "sarikaya@ieee.org" , "Sri Gundavelli (sgundave)" 
Thread-Topic: [DMM] Preparing for DMM future steps and rechartering
Thread-Index: AQHO3xoEu0AbZ8DtiEyWER4fydZmKpogj8Qg
Date: Mon, 11 Nov 2013 21:43:50 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7179487B4@dfweml511-mbs.china.huawei.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.245.95]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 11 Nov 2013 21:44:15 -0000

http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00

-Pete

Behcet Sarikaya wrote:
> I think we need a draft from Pete on this so we can all understand
> what is being proposed.
>=20
>=20
> Regards,
>=20
>=20
> Behcet
>=20
>=20
>=20
> On Mon, Nov 11, 2013 at 9:29 AM, Sri Gundavelli (sgundave)
>  wrote:
>=20
>=20
> 	Hi Pete,
>=20
> 	I'm not sure, I agree with this, or understand this to be precise. I do
> 	not know know CP (in the form of PMIP, GTP or some other protocol XYZ)
> can 	be completely eliminated. There needs to be some interface between
> the 	access gateway and the mobility anchor. I assumed your's, Marco's
> and 	Ryuji's goal is for eliminating the tunnel, which I don't believe
> it can 	be achieved, but still thought we can discuss this. IMO, its not
> just 	about inserting a RIB route and redistributing it, but even there
> in DP 	there is a state transfer needed  from the CP and the DP.
> Starting point 	appears like a simple route propagation, very soon it
> will end up with a 	bunch of state that gets moved between the two
> nodes.  But, may be I don't 	understand the ideas clearly on eliminating
> CP and eliminating tunnels. 	I'm not going to oppose this, I don't see
> this converging, IMHO.
>=20
>=20
>=20
>=20
> 	Regards
> 	Sri
>=20
>=20
>=20
>=20
> 	On 11/10/13 3:13 PM, "Peter McCann"  wrote:
>=20
> 	>Hi, Sri,
> 	>
>=20
> 	>I think you will agree that PMIP is a control protocol for setting up
> 	>tunnels.  A tunnel implies that we are not using the destination IP
> 	>of the inner packet for routing and by definition will lead to a
> 	>non-optimal 	>route and a bit of state on some box that can fail and
> lose that state. 	> 	>I hope that DMM can consider other approaches such
> as injecting routes 	>from the latest L2-attachment point into the
> access network, which is 	>a truly Distributed Mobility Management
> protocol for getting the packets 	>to the mobile node.  It will lead to
> more optimal routes and more robust 	>fault-tolerant operation of the
> network. 	> 	>I think we can continue to use the term MAG to apply to
> that first-hop 	>router which is hopefully co-located with the L2
> termination point (it 	>may not be so in every technology depending on
> the extent to which that 	>technology has evolved to support truly
> Distributed operation). Anything 	>that happens below the MAG (between
> the MAG and the L2 termination point) 	>should be out of scope and we
> should not define any protocol there and we 	>should discourage any
> separation between the two. 	> 	>However, we should not require the MAG
> to run any form of PMIP because 	>tunnels should not be required in the
> architecture.  We should not require 	>an LMA, because this would imply
> a central point of state maintenance and 	>possibility of failure. 	>
> 	>It is fine to consider a split between CP and DP but I thought we had
> 	>agreed 	>that any discussion of the protocol to use on such an
> interface would be 	>out of scope for this WG.  IMHO we should leave
> that to the Wireless & 	>Mobile 	>Working Group of ONF. 	> 	>Now, the
> proponents of OpenFlow and other CP/DP splits have argued that 	>it is
> 	>better to centralize the algorithms such as routing protocols on a
> 	>logically 	>centralized server or servers with a synchronized global
> view of the 	>network. 	>I have no problem with that, in which case this
> centralized controller 	>just 	>needs to get notified about the MN's
> current attachment point, so it can 	>install 	>the routes (or tunnels,
> if an operator wishes to use them) into the DP. 	>But, 	>the mechanisms
> for doing so are out of scope for the DMM WG because we 	>are not
> 	>working on a CP/DP split.  I think it would be appropriate for the DMM
> WG 	>(which 	>exists in the IETF, a standards body that has a long
> history of 	>developing 	>distributed and fault-tolerant routing
> protocols) to describe a more 	>distributed 	>alternative, building on
> foundational Internet technologies such as 	>I-BGP, in 	>such a way that
> will bring down the costs, reduce the latency, and 	>increase the
> 	>robustness of wireless access networks. 	> 	>I actually don't think we
> need to define any new extensions or IEs for 	>BGP; I 	>would like to
> read more about Ryuji's proposed extensions here. All we 	>need is 	>for
> the MAG to learn what IPs have been assigned to the MN, decide which
> 	>of those 	>IPs are in the scope of the local AS, and inject routes for
> those 	>prefixes to 	>itself.  We could work on alternative mechanisms
> for discovering this 	>list of 	>addresses - the fundamental requirement
> is that we use an authenticated 	>MN ID 	>(probably an NAI) as an index
> to lookup the set of IPs in a distributed 	>database. 	>I've proposed
> using DNS for this but there are other alternatives. We 	>also need 	>a
> way to make sure the latest UPDATE gets used by all the BGP peers.
> 	>I've proposed 	>putting a timestamp in LOCAL_PREF but there are
> probably other 	>alternatives. 	> 	>It would also be nice to have a
> well-defined fall-back mechanism in case 	>the MN 	>moves to a different
> AS or just too far from the original MAG, in which 	>case the 	>I-BGP
> approach wouldn't scale.  For these cases, I think a client MIP 	>tunnel
> to 	>an HA located in the original AS for each assigned IP address would
> be 	>ideal. 	>The HA can behave just like the MAGs in that domain,
> injecting routes 	>when MNs 	>establish tunnels to it so as to attract
> the packets to themselves (this 	>would 	>be the routing equivalent of
> the proxy-ARP or proxy-ND mechanism that 	>works on 	>just a single home
> link in MIPv4 or MIPv6).  We should work on mechanisms 	>to enable
> 	>dynamic assignment of local HAs to MNs and dynamic establishment of
> 	>security associations 	>that don't require AAA and associated
> round-trips to the home network. 	>Because the HA 	>is associated with
> the original MAG that assigned the address, this may 	>involve 	>some
> DHCP extensions.  There is already a way to assign the HA IP address
> 	>but we 	>will need new extensions to carry the HA credentials to the
> MN (maybe 	>just an HA DNS 	>name so the MN can use DANE to retrieve a
> public key). 	> 	>I think something like the path I've outlined above
> would make a good 	>work plan 	>for the future of DMM. 	> 	>-Pete 	>
>=20
>=20
> 	_______________________________________________
> 	dmm mailing list
> 	dmm@ietf.org
> 	https://www.ietf.org/mailman/listinfo/dmm
>=20
>




From sgundave@cisco.com  Mon Nov 11 22:13:22 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B40A11E810E for ; Mon, 11 Nov 2013 22:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.569
X-Spam-Level: 
X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StLo-H1G0ekL for ; Mon, 11 Nov 2013 22:13:16 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4048421E8099 for ; Mon, 11 Nov 2013 22:13:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9992; q=dns/txt; s=iport; t=1384236795; x=1385446395; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oV4Z4MbeMHuPExLrq6EwbcR8z7ig6XLM4ubN/BGh20o=; b=HaQnFt8Jv2k0rqkWXbpaU1ZVx2OLvG9CZ8DKh7/XOpVqvt2BdGP0m+Zp m2Pet6ZZwdYH/0/55iNs8H544UiLUa+znYfbw6BoXKOrCTlQZ9vAFuAT3 FdfZfLX+APfy7qzJYKx4JUZI6TckgCS9m95sx/o4y6UCgHl1j+DoAz8qf E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ag0FAH/GgVKtJV2a/2dsb2JhbABZgwc4U78agToWdIIlAQEBBAEBAWsLEgEIEgZVCxcOAgQKBAWIAQ2+JwSPWgeEMAOYD5IKgyaCKg
X-IronPort-AV: E=Sophos;i="4.93,682,1378857600"; d="scan'208";a="283350265"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2013 06:13:14 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAC6DEMO003645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 06:13:14 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 00:13:14 -0600
From: "Sri Gundavelli (sgundave)" 
To: Peter McCann 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO325EMbtoHxXoFU2lz0O+EaSnrg==
Date: Tue, 12 Nov 2013 06:13:12 +0000
Message-ID: 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.214]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2013 06:13:22 -0000

Hi Pete,

>As for "mobility anchor" I am not sure what is your definition of that
>term. If you mean some router in the network that the packets for a given
>MN's


My definition of a "mobility anchor" is the traditional definition that we
are familiar with. Its the entity that's hosting the subscriber session
and that is HA in CDMA, HA in WiMAX, GGSN/PGW in GSM networks and LMA in
generic PMIP-based architectures. Now, if that entity is in the routing
path is one aspect, or relocation of the subscriber state between two such
nodes is another aspect, but eliminating that function entirely from the
network is interesting :). Probably, if the view that mobile architecture
is all about IP address continuity and hence just a routing problem, then
that may be it.=20

The proposals on the table fail to acknowledge the existence of the core
service functions in mobility architecture such as Charging, LI, DPI,
Policy =8A and when such constraints are removed, sure, its a host route
that does all the magic. The assumption that there will be a single node
mobility architecture and that node is nothing but either a base station
or a cell-site router is interesting, but it is fine with me.

On a lighter note, In 80's I grew up watching the old StarTrek series and
most of my pre-teen years I lived in Star ship enterprise in Andromeda
Galaxy. That first-hand experience with "Transporter", "Beam Us Up",
"Phasers", "Telepresence" =8A today makes me accept any new technology that
gets beamed at me. Anchor-less mobile network is another in that list that
I can accept and live with :) :)




Regards
Sri
 =20









On 11/11/13 1:17 PM, "Peter McCann"  wrote:

>Hi, Sri,
>
>Sri Gundavelli (sgundave) wrote:
>> Hi Pete,
>>=20
>> I'm not sure, I agree with this, or understand this to be precise. I do
>> not know know CP (in the form of PMIP, GTP or some other protocol XYZ)
>> can be completely eliminated. There needs to be some interface between
>> the access gateway and the mobility anchor.
>
>As I said in jabber during the meeting we need to carefully define these
>terms.
>
>Let's try to use the term MAG consistently.  It means the first node that
>can see IP packets from the MN.  In my mind this should be co-located with
>the L2 termination point.
>
>As for "mobility anchor" I am not sure what is your definition of that
>term.
>If you mean some router in the network that the packets for a given MN's
>assigned IP address are delivered, then that entity can change over the
>period of time the address is assigned to a given MN.  IMHO when the
>address
>is assigned, that node should be the MAG to which the MN is attached at
>the
>time of assignment.  You can do this by choosing the pool of addresses
>that
>are normally routed to the MAG.  When the MN moves, the "mobility anchor"
>can be changed if the routing tables are updated.
>
>> I assumed your's, Marco's
>> and Ryuji's goal is for eliminating the tunnel, which I don't believe it
>> can be achieved, but still thought we can discuss this.
>
>If we can change the "mobility anchor" to always be the current MAG while
>the MN is in the same domain (or perhaps the same part of a domain) then
>there will not be a need for tunnels during that period of time.  You need
>a tunnel when you move outside the domain under which routing protocols
>are
>scalable.  This can be a client-MIP tunnel because there won't be much
>need
>to update it, assuming the new CoA is managed in the same way by whatever
>network the MN is on at that time.
>
>> IMO, its not
>> just about inserting a RIB route and redistributing it, but even there
>> in DP there is a state transfer needed  from the CP and the DP. Starting
>> point appears like a simple route propagation, very soon it will end up
>> with a bunch of state that gets moved between the two nodes.
>
>MAG authenticates the MN when it attaches/moves in.  Authentication gives
>an MN ID.  MN ID is used to lookup IP addresses currently assigned.
>UPDATE
>is generated for those IPs to attract packets to the current MAG.  Mission
>accomplished.
>
>> But, may
>> be I don't understand the ideas clearly on eliminating CP and
>> eliminating tunnels. I'm not going to oppose this, I don't see this
>> converging, IMHO.
>
>I think you mean the discussion will not converge, when Alex interpreted
>this to mean the routing tables won't converge... anyway, I hope we can
>consider routing protocols as one way to accomplish localized mobility
>management.
>
>-Pete
>
>>=20
>>=20
>>=20
>>=20
>> Regards
>> Sri
>>=20
>>=20
>>=20
>> On 11/10/13 3:13 PM, "Peter McCann"  wrote:
>>=20
>>> Hi, Sri,
>>>=20
>>> I think you will agree that PMIP is a control protocol for setting up
>>> tunnels.  A tunnel implies that we are not using the destination IP of
>>> the inner packet for routing and by definition will lead to a
>>> non-optimal route and a bit of state on some box that can fail and lose
>>> that state.
>>>=20
>>> I hope that DMM can consider other approaches such as injecting routes
>>> from the latest L2-attachment point into the access network, which is a
>>> truly Distributed Mobility Management protocol for getting the packets
>>> to the mobile node.  It will lead to more optimal routes and more
>>> robust fault-tolerant operation of the network.
>>>=20
>>> I think we can continue to use the term MAG to apply to that first-hop
>>> router which is hopefully co-located with the L2 termination point (it
>>> may not be so in every technology depending on the extent to which that
>>> technology has evolved to support truly Distributed operation).
>>> Anything that happens below the MAG (between the MAG and the L2
>>> termination point) should be out of scope and we should not define any
>>> protocol there and we should discourage any separation between the two.
>>>=20
>>> However, we should not require the MAG to run any form of PMIP because
>>> tunnels should not be required in the architecture.  We should not
>>> require an LMA, because this would imply a central point of state
>>> maintenance and possibility of failure.
>>>=20
>>> It is fine to consider a split between CP and DP but I thought we had
>>> agreed that any discussion of the protocol to use on such an interface
>>> would be out of scope for this WG.  IMHO we should leave that to the
>>> Wireless & Mobile Working Group of ONF.
>>>=20
>>> Now, the proponents of OpenFlow and other CP/DP splits have argued that
>>> it is better to centralize the algorithms such as routing protocols on
>>> a logically centralized server or servers with a synchronized global
>>> view of the network. I have no problem with that, in which case this
>>> centralized controller just needs to get notified about the MN's
>>> current attachment point, so it can install the routes (or tunnels, if
>>> an operator wishes to use them) into the DP. But, the mechanisms for
>>> doing so are out of scope for the DMM WG because we are not working on
>>> a CP/DP split.  I think it would be appropriate for the DMM WG (which
>>> exists in the IETF, a standards body that has a long history of
>>> developing distributed and fault-tolerant routing protocols) to
>>> describe a more distributed alternative, building on foundational
>>> Internet technologies such as I-BGP, in such a way that will bring down
>>> the costs, reduce the latency, and increase the robustness of wireless
>>> access networks.
>>>=20
>>> I actually don't think we need to define any new extensions or IEs for
>>> BGP; I would like to read more about Ryuji's proposed extensions here.
>>> All we need is for the MAG to learn what IPs have been assigned to the
>>> MN, decide which of those IPs are in the scope of the local AS, and
>>> inject routes for those prefixes to itself.  We could work on
>>> alternative mechanisms for discovering this list of addresses - the
>>> fundamental requirement is that we use an authenticated MN ID (probably
>>> an NAI) as an index to lookup the set of IPs in a distributed database.
>>> I've proposed using DNS for this but there are other alternatives.  We
>>> also need a way to make sure the latest UPDATE gets used by all the BGP
>>> peers. I've proposed putting a timestamp in LOCAL_PREF but there are
>>> probably other alternatives.
>>>=20
>>> It would also be nice to have a well-defined fall-back mechanism in
>>> case the MN moves to a different AS or just too far from the original
>>> MAG, in which case the I-BGP approach wouldn't scale.  For these cases,
>>> I think a client MIP tunnel to an HA located in the original AS for
>>> each assigned IP address would be ideal. The HA can behave just like
>>> the MAGs in that domain, injecting routes when MNs establish tunnels to
>>> it so as to attract the packets to themselves (this would be the
>>> routing equivalent of the proxy-ARP or proxy-ND mechanism that works on
>>> just a single home link in MIPv4 or MIPv6).  We should work on
>>> mechanisms to enable dynamic assignment of local HAs to MNs and dynamic
>>> establishment of security associations that don't require AAA and
>>> associated round-trips to the home network. Because the HA is
>>> associated with the original MAG that assigned the address, this may
>>> involve some DHCP extensions.  There is already a way to assign the HA
>>> IP address but we will need new extensions to carry the HA credentials
>>> to the MN (maybe just an HA DNS name so the MN can use DANE to retrieve
>>> a public key).
>>>=20
>>> I think something like the path I've outlined above would make a good
>>> work plan
>>> for the future of DMM.
>>>=20
>>> -Pete
>>>=20
>>=20
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
>
>


From Peter.McCann@huawei.com  Tue Nov 12 13:30:02 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB611E810C for ; Tue, 12 Nov 2013 13:30:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8PwZ+7SXSzQ for ; Tue, 12 Nov 2013 13:29:56 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B669721F9D7A for ; Tue, 12 Nov 2013 13:29:55 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU85754; Tue, 12 Nov 2013 21:29:54 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 21:28:55 +0000
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 21:29:50 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 13:29:43 -0800
From: Peter McCann 
To: "Sri Gundavelli (sgundave)" 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: Ac7Y3bqUR0J96RB8SmOZDtKQ9LtNUQADREFAABnu6gAAIMb+gAAAJPSAAAu8+IAAAIZpgAAFP1cAAFBGo4AAAmslAAA5YikAAA/fl8AAFGnLAAAQoWLQAFZl+QAAAMtAAAAAT0YAAA0Dp4D//7zUAIAAWAQggADyaICAACee0IAAzysA//+HtVA=
Date: Tue, 12 Nov 2013 21:29:43 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.244.81]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 12 Nov 2013 21:30:02 -0000

Hi, Sri,

Even if we agree that those services are necessary (and I would point out
once again that most of them are not beneficial to the end-user) I don't
think we should be architecting the network in such a way that we lose the
basic benefits of IP (shortest path routing and fault-tolerance).  We can
implement those services without taking all the packets to a central locati=
on;
maybe just the first packet or meta-information about the first packet can
be taken to an SDN controller that can make some decision and pass it down
to the user plane.

I really don't think this is such fantastic science-fiction. ;)

-Pete

Sri Gundavelli (sgundave) wrote:
> Hi Pete,
>=20
>> As for "mobility anchor" I am not sure what is your definition of that
>> term. If you mean some router in the network that the packets for a
>> given MN's
>=20
>=20
> My definition of a "mobility anchor" is the traditional definition that
> we are familiar with. Its the entity that's hosting the subscriber
> session and that is HA in CDMA, HA in WiMAX, GGSN/PGW in GSM networks
> and LMA in generic PMIP-based architectures. Now, if that entity is in
> the routing path is one aspect, or relocation of the subscriber state
> between two such nodes is another aspect, but eliminating that function
> entirely from the network is interesting :). Probably, if the view that
> mobile architecture is all about IP address continuity and hence just a
> routing problem, then that may be it.
>=20
> The proposals on the table fail to acknowledge the existence of the core
> service functions in mobility architecture such as Charging, LI, DPI,
> Policy =A9 and when such constraints are removed, sure, its a host route
> that does all the magic. The assumption that there will be a single node
> mobility architecture and that node is nothing but either a base station
> or a cell-site router is interesting, but it is fine with me.
>=20
> On a lighter note, In 80's I grew up watching the old StarTrek series
> and most of my pre-teen years I lived in Star ship enterprise in
> Andromeda Galaxy. That first-hand experience with "Transporter", "Beam
> Us Up", "Phasers", "Telepresence" =A9 today makes me accept any new
> technology that gets beamed at me. Anchor-less mobile network is another
> in that list that I can accept and live with :) :)
>=20
>=20
>=20
>=20
> Regards
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On 11/11/13 1:17 PM, "Peter McCann"  wrote:
>=20
>> Hi, Sri,
>>=20
>> Sri Gundavelli (sgundave) wrote:
>>> Hi Pete,
>>>=20
>>> I'm not sure, I agree with this, or understand this to be precise. I
>>> do not know know CP (in the form of PMIP, GTP or some other protocol
>>> XYZ) can be completely eliminated. There needs to be some interface
>>> between the access gateway and the mobility anchor.
>>=20
>> As I said in jabber during the meeting we need to carefully define
>> these terms.
>>=20
>> Let's try to use the term MAG consistently.  It means the first node
>> that can see IP packets from the MN.  In my mind this should be
>> co-located with the L2 termination point.
>>=20
>> As for "mobility anchor" I am not sure what is your definition of that
>> term. If you mean some router in the network that the packets for a
>> given MN's assigned IP address are delivered, then that entity can
>> change over the period of time the address is assigned to a given MN.=20
>> IMHO when the address is assigned, that node should be the MAG to which
>> the MN is attached at the time of assignment.  You can do this by
>> choosing the pool of addresses that are normally routed to the MAG.=20
>> When the MN moves, the "mobility anchor" can be changed if the routing
>> tables are updated.
>>=20
>>> I assumed your's, Marco's and Ryuji's goal is for eliminating the
>>> tunnel, which I don't believe it can be achieved, but still thought we
>>> can discuss this.
>>=20
>> If we can change the "mobility anchor" to always be the current MAG
>> while the MN is in the same domain (or perhaps the same part of a
>> domain) then there will not be a need for tunnels during that period of
>> time.  You need a tunnel when you move outside the domain under which
>> routing protocols are scalable.  This can be a client-MIP tunnel
>> because there won't be much need to update it, assuming the new CoA is
>> managed in the same way by whatever network the MN is on at that time.
>>=20
>>> IMO, its not just about inserting a RIB route and redistributing it,
>>> but even there in DP there is a state transfer needed  from the CP and
>>> the DP. Starting point appears like a simple route propagation, very
>>> soon it will end up with a bunch of state that gets moved between the
>>> two nodes.
>>=20
>> MAG authenticates the MN when it attaches/moves in.  Authentication
>> gives an MN ID.  MN ID is used to lookup IP addresses currently
>> assigned. UPDATE is generated for those IPs to attract packets to the
>> current MAG. Mission accomplished.
>>=20
>>> But, may
>>> be I don't understand the ideas clearly on eliminating CP and
>>> eliminating tunnels. I'm not going to oppose this, I don't see this
>>> converging, IMHO.
>>=20
>> I think you mean the discussion will not converge, when Alex
>> interpreted this to mean the routing tables won't converge... anyway, I
>> hope we can consider routing protocols as one way to accomplish
>> localized mobility management.
>>=20
>> -Pete
>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> Regards
>>> Sri
>>>=20
>>>=20
>>>=20
>>> On 11/10/13 3:13 PM, "Peter McCann"  wrote:
>>>=20
>>>> Hi, Sri,
>>>>=20
>>>> I think you will agree that PMIP is a control protocol for setting up
>>>> tunnels.  A tunnel implies that we are not using the destination IP
>>>> of the inner packet for routing and by definition will lead to a
>>>> non-optimal route and a bit of state on some box that can fail and
>>>> lose that state.
>>>>=20
>>>> I hope that DMM can consider other approaches such as injecting
>>>> routes from the latest L2-attachment point into the access network,
>>>> which is a truly Distributed Mobility Management protocol for getting
>>>> the packets to the mobile node.  It will lead to more optimal routes
>>>> and more robust fault-tolerant operation of the network.
>>>>=20
>>>> I think we can continue to use the term MAG to apply to that first-
>>>> hop router which is hopefully co-located with the L2 termination
>>>> point (it may not be so in every technology depending on the extent
>>>> to which that technology has evolved to support truly Distributed
>>>> operation). Anything that happens below the MAG (between the MAG and
>>>> the L2 termination point) should be out of scope and we should not
>>>> define any protocol there and we should discourage any separation
>>>> between the two.
>>>>=20
>>>> However, we should not require the MAG to run any form of PMIP
>>>> because tunnels should not be required in the architecture.  We
>>>> should not require an LMA, because this would imply a central point
>>>> of state maintenance and possibility of failure.
>>>>=20
>>>> It is fine to consider a split between CP and DP but I thought we had
>>>> agreed that any discussion of the protocol to use on such an
>>>> interface would be out of scope for this WG.  IMHO we should leave
>>>> that to the Wireless & Mobile Working Group of ONF.
>>>>=20
>>>> Now, the proponents of OpenFlow and other CP/DP splits have argued
>>>> that it is better to centralize the algorithms such as routing
>>>> protocols on a logically centralized server or servers with a
>>>> synchronized global view of the network. I have no problem with that,
>>>> in which case this centralized controller just needs to get notified
>>>> about the MN's current attachment point, so it can install the routes
>>>> (or tunnels, if an operator wishes to use them) into the DP. But, the
>>>> mechanisms for doing so are out of scope for the DMM WG because we
>>>> are not working on a CP/DP split.  I think it would be appropriate
>>>> for the DMM WG (which exists in the IETF, a standards body that has a
>>>> long history of developing distributed and fault-tolerant routing
>>>> protocols) to describe a more distributed alternative, building on
>>>> foundational Internet technologies such as I-BGP, in such a way that
>>>> will bring down the costs, reduce the latency, and increase the
>>>> robustness of wireless access networks.
>>>>=20
>>>> I actually don't think we need to define any new extensions or IEs
>>>> for BGP; I would like to read more about Ryuji's proposed extensions
>>>> here. All we need is for the MAG to learn what IPs have been assigned
>>>> to the MN, decide which of those IPs are in the scope of the local
>>>> AS, and inject routes for those prefixes to itself.  We could work on
>>>> alternative mechanisms for discovering this list of addresses - the
>>>> fundamental requirement is that we use an authenticated MN ID
>>>> (probably an NAI) as an index to lookup the set of IPs in a
>>>> distributed database. I've proposed using DNS for this but there are
>>>> other alternatives. We also need a way to make sure the latest UPDATE
>>>> gets used by all the BGP peers. I've proposed putting a timestamp in
>>>> LOCAL_PREF but there are probably other alternatives.
>>>>=20
>>>> It would also be nice to have a well-defined fall-back mechanism in
>>>> case the MN moves to a different AS or just too far from the original
>>>> MAG, in which case the I-BGP approach wouldn't scale.  For these
>>>> cases, I think a client MIP tunnel to an HA located in the original
>>>> AS for each assigned IP address would be ideal. The HA can behave
>>>> just like the MAGs in that domain, injecting routes when MNs
>>>> establish tunnels to it so as to attract the packets to themselves
>>>> (this would be the routing equivalent of the proxy-ARP or proxy-ND
>>>> mechanism that works on just a single home link in MIPv4 or MIPv6).=20
>>>> We should work on mechanisms to enable dynamic assignment of local
>>>> HAs to MNs and dynamic establishment of security associations that
>>>> don't require AAA and associated round-trips to the home network.
>>>> Because the HA is associated with the original MAG that assigned the
>>>> address, this may involve some DHCP extensions.  There is already a
>>>> way to assign the HA IP address but we will need new extensions to
>>>> carry the HA credentials to the MN (maybe just an HA DNS name so the
>>>> MN can use DANE to retrieve a public key).
>>>>=20
>>>> I think something like the path I've outlined above would make a good
>>>> work plan for the future of DMM.
>>>>=20
>>>> -Pete
>>>>=20




From Marco.Liebsch@neclab.eu  Wed Nov 13 02:10:57 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C7C11E8110 for ; Wed, 13 Nov 2013 02:10:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYeuxpwGoij5 for ; Wed, 13 Nov 2013 02:10:53 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B63E721F9E43 for ; Wed, 13 Nov 2013 02:10:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 68A60106021; Wed, 13 Nov 2013 11:04:08 +0100 (CET)
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 4pHDWjKpxAiz; Wed, 13 Nov 2013 11:04:08 +0100 (CET)
Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 4359D106020; Wed, 13 Nov 2013 11:03:53 +0100 (CET)
Received: from PALLENE.office.hd ([169.254.1.11]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 13 Nov 2013 11:10:36 +0100
From: Marco Liebsch 
To: "Sri Gundavelli (sgundave)" , Peter McCann 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO2N32tX9akckQbkC/oEY66nusCZoUE9cAgABImwCAAQY4gIAAASiAgABd6ICAABT2rIAAGTgAgAKCNYCAABNZAIAByxEAgAEHGQCAABsyAIAAAfoAgAM2QQCAAAZaAIAAAnoAgAAfUgCAAAWgAIAAOa4AgAEQvoCAAtigQA==
Date: Wed, 13 Nov 2013 10:10:36 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com> 
In-Reply-To: 
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
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 10:10:57 -0000

Hi Sri, all,
let me step in here (with some delay..) to clarify one point you raised.
Please see inline.

>-----Original Message-----
>From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Sri
>Gundavelli (sgundave)
>Sent: Montag, 11. November 2013 16:30
>To: Peter McCann
>Cc: dmm@ietf.org
>Subject: Re: [DMM] Preparing for DMM future steps and rechartering
>
>Hi Pete,
>
>I'm not sure, I agree with this, or understand this to be precise. I do no=
t know
>know CP (in the form of PMIP, GTP or some other protocol XYZ) can be
>completely eliminated. There needs to be some interface between the access
>gateway and the mobility anchor. I assumed your's, Marco's and Ryuji's goa=
l is
>for eliminating the tunnel, which I don't believe it can be achieved, but =
still
>thought we can discuss this.

My intention is not to eliminate a tunnel that exists in any of the tunnel =
management
protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes to=
pological
anchor point for the MN's IP address(es). Forget about the C-plane for now.
Tunnels apply solely below (well, towards access) such anchor.
If we distribute them to an extreme, they are placed on radio access points=
 and
the tunnel disappears. Then we arrive at Pete's model. If anchor points are=
 somewhere
above, say in the backhaul, the tunnel remains at least between the anchor =
and some node in
the access (network based mobility mgmnt) or the MN (host based mobility mg=
mnt).

I think none of the proposals wants to discuss away the tunnels as per MIP/=
PMIP. But above
anchor level, regular routing applies to plain data packets of the U-Plane.
A key component for DMM, IMO, is how to accomplish that routing towards
the MN's current anchor point, even if the anchored IP address is topologic=
ally incorrect.
To accomplish this, my intent is to not introduce tunnels above anchor leve=
l.
So, it's not about eliminating tunnels, but it is about not introducing tun=
nels
where never have been tunnels before :-)

marco

> IMO, its not just about inserting a RIB route and
>redistributing it, but even there in DP there is a state transfer needed  =
from the
>CP and the DP. Starting point appears like a simple route propagation, ver=
y soon
>it will end up with a bunch of state that gets moved between the two nodes=
.  But,
>may be I don't understand the ideas clearly on eliminating CP and eliminat=
ing
>tunnels.
>I'm not going to oppose this, I don't see this converging, IMHO.
>
>
>
>
>Regards
>Sri
>
>
>
>On 11/10/13 3:13 PM, "Peter McCann"  wrote:
>
>>Hi, Sri,
>>
>>I think you will agree that PMIP is a control protocol for setting up
>>tunnels.  A tunnel implies that we are not using the destination IP of
>>the inner packet for routing and by definition will lead to a
>>non-optimal route and a bit of state on some box that can fail and lose
>>that state.
>>
>>I hope that DMM can consider other approaches such as injecting routes
>>from the latest L2-attachment point into the access network, which is a
>>truly Distributed Mobility Management protocol for getting the packets
>>to the mobile node.  It will lead to more optimal routes and more
>>robust fault-tolerant operation of the network.
>>
>>I think we can continue to use the term MAG to apply to that first-hop
>>router which is hopefully co-located with the L2 termination point (it
>>may not be so in every technology depending on the extent to which that
>>technology has evolved to support truly Distributed operation).
>>Anything that happens below the MAG (between the MAG and the L2
>>termination point) should be out of scope and we should not define any
>>protocol there and we should discourage any separation between the two.
>>
>>However, we should not require the MAG to run any form of PMIP because
>>tunnels should not be required in the architecture.  We should not
>>require an LMA, because this would imply a central point of state
>>maintenance and possibility of failure.
>>
>>It is fine to consider a split between CP and DP but I thought we had
>>agreed that any discussion of the protocol to use on such an interface
>>would be out of scope for this WG.  IMHO we should leave that to the
>>Wireless & Mobile Working Group of ONF.
>>
>>Now, the proponents of OpenFlow and other CP/DP splits have argued that
>>it is better to centralize the algorithms such as routing protocols on
>>a logically centralized server or servers with a synchronized global
>>view of the network.
>>I have no problem with that, in which case this centralized controller
>>just needs to get notified about the MN's current attachment point, so
>>it can install the routes (or tunnels, if an operator wishes to use
>>them) into the DP.
>>But,
>>the mechanisms for doing so are out of scope for the DMM WG because we
>>are not working on a CP/DP split.  I think it would be appropriate for
>>the DMM WG (which exists in the IETF, a standards body that has a long
>>history of developing distributed and fault-tolerant routing protocols)
>>to describe a more distributed alternative, building on foundational
>>Internet technologies such as I-BGP, in such a way that will bring down
>>the costs, reduce the latency, and increase the robustness of wireless
>>access networks.
>>
>>I actually don't think we need to define any new extensions or IEs for
>>BGP; I would like to read more about Ryuji's proposed extensions here.
>>All we need is for the MAG to learn what IPs have been assigned to the
>>MN, decide which of those IPs are in the scope of the local AS, and
>>inject routes for those prefixes to itself.  We could work on
>>alternative mechanisms for discovering this list of addresses - the
>>fundamental requirement is that we use an authenticated MN ID (probably
>>an NAI) as an index to lookup the set of IPs in a distributed database.
>>I've proposed using DNS for this but there are other alternatives.  We
>>also need a way to make sure the latest UPDATE gets used by all the BGP
>>peers.
>>I've proposed
>>putting a timestamp in LOCAL_PREF but there are probably other
>>alternatives.
>>
>>It would also be nice to have a well-defined fall-back mechanism in
>>case the MN moves to a different AS or just too far from the original
>>MAG, in which case the I-BGP approach wouldn't scale.  For these cases,
>>I think a client MIP tunnel to an HA located in the original AS for
>>each assigned IP address would be ideal.
>>The HA can behave just like the MAGs in that domain, injecting routes
>>when MNs establish tunnels to it so as to attract the packets to
>>themselves (this would be the routing equivalent of the proxy-ARP or
>>proxy-ND mechanism that works on just a single home link in MIPv4 or
>>MIPv6).  We should work on mechanisms to enable dynamic assignment of
>>local HAs to MNs and dynamic establishment of security associations
>>that don't require AAA and associated round-trips to the home network.
>>Because the HA
>>is associated with the original MAG that assigned the address, this may
>>involve some DHCP extensions.  There is already a way to assign the HA
>>IP address but we will need new extensions to carry the HA credentials
>>to the MN (maybe just an HA DNS name so the MN can use DANE to retrieve
>>a public key).
>>
>>I think something like the path I've outlined above would make a good
>>work plan for the future of DMM.
>>
>>-Pete
>>
>
>_______________________________________________
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm

From cjbc@it.uc3m.es  Wed Nov 13 02:51:36 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1518921E80A7 for ; Wed, 13 Nov 2013 02:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.962
X-Spam-Level: 
X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNuObfiFs5vl for ; Wed, 13 Nov 2013 02:51:31 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id 0518E21E80B6 for ; Wed, 13 Nov 2013 02:51:30 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0B41F11BE721; Wed, 13 Nov 2013 11:51:30 +0100 (CET)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [163.117.95.165] (unknown [163.117.95.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id CFF0E11BF54A; Wed, 13 Nov 2013 11:51:29 +0100 (CET)
Message-ID: <1384339889.4137.13.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: Marco Liebsch 
Date: Wed, 13 Nov 2013 11:51:29 +0100
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>  <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20288.003
X-TM-AS-Result: No--33.553-7.0-31-1
X-imss-scan-details: No--33.553-7.0-31-1
Cc: Peter McCann , "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 10:51:36 -0000

Hi,

I'm also jumping into the discussion a bit late.

Without going into all the detailed discussions that have taken place
recently, I just want to share my view on the MIP-based vs routing-based
approach.

IMHO, we probably need to further look at both approaches in this group,
but with enough energy level (otherwise we risk to end up with nothing
after several years). I personally have my doubts that a distributed
routing-based approach scales in a moderately large domain (we also saw
many years ago proposals of doing mobility with routing that did not
take off because of convergence, scalability and administrative issues).
I think a MIP-based approach (network or host based) would work, though
it would imply keeping multiple anchors active for a given MN.

We believe this routing-based vs MIP-based comparison is quite
interesting, and we are actually working at UC3M on experimentally
evaluating both, so we can make a more educated statement on pros and
cons of each of them.

My two cents,

Carlos

On Wed, 2013-11-13 at 10:10 +0000, Marco Liebsch wrote:
> Hi Sri, all,
> let me step in here (with some delay..) to clarify one point you raised.
> Please see inline.
> 
> >-----Original Message-----
> >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Sri
> >Gundavelli (sgundave)
> >Sent: Montag, 11. November 2013 16:30
> >To: Peter McCann
> >Cc: dmm@ietf.org
> >Subject: Re: [DMM] Preparing for DMM future steps and rechartering
> >
> >Hi Pete,
> >
> >I'm not sure, I agree with this, or understand this to be precise. I do not know
> >know CP (in the form of PMIP, GTP or some other protocol XYZ) can be
> >completely eliminated. There needs to be some interface between the access
> >gateway and the mobility anchor. I assumed your's, Marco's and Ryuji's goal is
> >for eliminating the tunnel, which I don't believe it can be achieved, but still
> >thought we can discuss this.
> 
> My intention is not to eliminate a tunnel that exists in any of the tunnel management
> protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes topological
> anchor point for the MN's IP address(es). Forget about the C-plane for now.
> Tunnels apply solely below (well, towards access) such anchor.
> If we distribute them to an extreme, they are placed on radio access points and
> the tunnel disappears. Then we arrive at Pete's model. If anchor points are somewhere
> above, say in the backhaul, the tunnel remains at least between the anchor and some node in
> the access (network based mobility mgmnt) or the MN (host based mobility mgmnt).
> 
> I think none of the proposals wants to discuss away the tunnels as per MIP/PMIP. But above
> anchor level, regular routing applies to plain data packets of the U-Plane.
> A key component for DMM, IMO, is how to accomplish that routing towards
> the MN's current anchor point, even if the anchored IP address is topologically incorrect.
> To accomplish this, my intent is to not introduce tunnels above anchor level.
> So, it's not about eliminating tunnels, but it is about not introducing tunnels
> where never have been tunnels before :-)
> 
> marco
> 
> > IMO, its not just about inserting a RIB route and
> >redistributing it, but even there in DP there is a state transfer needed  from the
> >CP and the DP. Starting point appears like a simple route propagation, very soon
> >it will end up with a bunch of state that gets moved between the two nodes.  But,
> >may be I don't understand the ideas clearly on eliminating CP and eliminating
> >tunnels.
> >I'm not going to oppose this, I don't see this converging, IMHO.
> >
> >
> >
> >
> >Regards
> >Sri
> >
> >
> >
> >On 11/10/13 3:13 PM, "Peter McCann"  wrote:
> >
> >>Hi, Sri,
> >>
> >>I think you will agree that PMIP is a control protocol for setting up
> >>tunnels.  A tunnel implies that we are not using the destination IP of
> >>the inner packet for routing and by definition will lead to a
> >>non-optimal route and a bit of state on some box that can fail and lose
> >>that state.
> >>
> >>I hope that DMM can consider other approaches such as injecting routes
> >>from the latest L2-attachment point into the access network, which is a
> >>truly Distributed Mobility Management protocol for getting the packets
> >>to the mobile node.  It will lead to more optimal routes and more
> >>robust fault-tolerant operation of the network.
> >>
> >>I think we can continue to use the term MAG to apply to that first-hop
> >>router which is hopefully co-located with the L2 termination point (it
> >>may not be so in every technology depending on the extent to which that
> >>technology has evolved to support truly Distributed operation).
> >>Anything that happens below the MAG (between the MAG and the L2
> >>termination point) should be out of scope and we should not define any
> >>protocol there and we should discourage any separation between the two.
> >>
> >>However, we should not require the MAG to run any form of PMIP because
> >>tunnels should not be required in the architecture.  We should not
> >>require an LMA, because this would imply a central point of state
> >>maintenance and possibility of failure.
> >>
> >>It is fine to consider a split between CP and DP but I thought we had
> >>agreed that any discussion of the protocol to use on such an interface
> >>would be out of scope for this WG.  IMHO we should leave that to the
> >>Wireless & Mobile Working Group of ONF.
> >>
> >>Now, the proponents of OpenFlow and other CP/DP splits have argued that
> >>it is better to centralize the algorithms such as routing protocols on
> >>a logically centralized server or servers with a synchronized global
> >>view of the network.
> >>I have no problem with that, in which case this centralized controller
> >>just needs to get notified about the MN's current attachment point, so
> >>it can install the routes (or tunnels, if an operator wishes to use
> >>them) into the DP.
> >>But,
> >>the mechanisms for doing so are out of scope for the DMM WG because we
> >>are not working on a CP/DP split.  I think it would be appropriate for
> >>the DMM WG (which exists in the IETF, a standards body that has a long
> >>history of developing distributed and fault-tolerant routing protocols)
> >>to describe a more distributed alternative, building on foundational
> >>Internet technologies such as I-BGP, in such a way that will bring down
> >>the costs, reduce the latency, and increase the robustness of wireless
> >>access networks.
> >>
> >>I actually don't think we need to define any new extensions or IEs for
> >>BGP; I would like to read more about Ryuji's proposed extensions here.
> >>All we need is for the MAG to learn what IPs have been assigned to the
> >>MN, decide which of those IPs are in the scope of the local AS, and
> >>inject routes for those prefixes to itself.  We could work on
> >>alternative mechanisms for discovering this list of addresses - the
> >>fundamental requirement is that we use an authenticated MN ID (probably
> >>an NAI) as an index to lookup the set of IPs in a distributed database.
> >>I've proposed using DNS for this but there are other alternatives.  We
> >>also need a way to make sure the latest UPDATE gets used by all the BGP
> >>peers.
> >>I've proposed
> >>putting a timestamp in LOCAL_PREF but there are probably other
> >>alternatives.
> >>
> >>It would also be nice to have a well-defined fall-back mechanism in
> >>case the MN moves to a different AS or just too far from the original
> >>MAG, in which case the I-BGP approach wouldn't scale.  For these cases,
> >>I think a client MIP tunnel to an HA located in the original AS for
> >>each assigned IP address would be ideal.
> >>The HA can behave just like the MAGs in that domain, injecting routes
> >>when MNs establish tunnels to it so as to attract the packets to
> >>themselves (this would be the routing equivalent of the proxy-ARP or
> >>proxy-ND mechanism that works on just a single home link in MIPv4 or
> >>MIPv6).  We should work on mechanisms to enable dynamic assignment of
> >>local HAs to MNs and dynamic establishment of security associations
> >>that don't require AAA and associated round-trips to the home network.
> >>Because the HA
> >>is associated with the original MAG that assigned the address, this may
> >>involve some DHCP extensions.  There is already a way to assign the HA
> >>IP address but we will need new extensions to carry the HA credentials
> >>to the MN (maybe just an HA DNS name so the MN can use DANE to retrieve
> >>a public key).
> >>
> >>I think something like the path I've outlined above would make a good
> >>work plan for the future of DMM.
> >>
> >>-Pete
> >>
> >
> >_______________________________________________
> >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 Marco.Liebsch@neclab.eu  Wed Nov 13 03:24:32 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 680AB21E80E7 for ; Wed, 13 Nov 2013 03:24:32 -0800 (PST)
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=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58VLa21H45uh for ; Wed, 13 Nov 2013 03:24:28 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D094111E80F1 for ; Wed, 13 Nov 2013 03:24:26 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id D6E31106021; Wed, 13 Nov 2013 12:17:42 +0100 (CET)
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 N9rfXtKYDIj2; Wed, 13 Nov 2013 12:17:42 +0100 (CET)
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 B3D99106020; Wed, 13 Nov 2013 12:17:22 +0100 (CET)
Received: from HYDRA.office.hd ([169.254.4.178]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 13 Nov 2013 12:23:54 +0100
From: Marco Liebsch 
To: "cjbc@it.uc3m.es" 
Thread-Topic: [DMM] Preparing for DMM future steps and rechartering
Thread-Index: AQHO2N32tX9akckQbkC/oEY66nusCZoUE9cAgABImwCAAQY4gIAAASiAgABd6ICAABT2rIAAGTgAgAKCNYCAABNZAIAByxEAgAEHGQCAABsyAIAAAfoAgAM2QQCAAAZaAIAAAnoAgAAfUgCAAAWgAIAAOa4AgAEQvoCAAtigQP///j6AgAAUkwA=
Date: Wed, 13 Nov 2013 11:23:43 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D6374AEF3@Hydra.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>  <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd> <1384339889.4137.13.camel@acorde.it.uc3m.es>
In-Reply-To: <1384339889.4137.13.camel@acorde.it.uc3m.es>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Peter McCann , "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 11:24:32 -0000

Q2FybG9zLCANCg0KanVzdCB0byBjbGFyaWZ5IG15IHZpZXcgaGVyZTogSSBkbyBub3Qgc2VlIHRo
ZW0gYXMgZGlmZmVyZW50IGFwcHJvYWNoZXMsDQpidXQgaW4gYSB3YXkgdGhhdCB0aGUgcm91dGlu
ZyBhcHByb2FjaCBjYW4gY29tcGxlbWVudCBtb2JpbGl0eSBhbmNob3ItYmFzZWQNCmFwcHJvYWNo
ZXMgKE1JUC1saWtlIHByb3RvY29scykuIEFuZCBzdWNoIHJvdXRpbmcgc3VwcG9ydCBpcyBuZWVk
ZWQgb25seQ0KaW4gY2VydGFpbiBkZXBsb3ltZW50cywgaS5lLiBpbiBjYXNlIG9mIGEgcnVudGlt
ZSBjaGFuZ2Ugb2YgdGhlIE1OJ3MgYW5jaG9yDQp3aGlsZSB0aGUgbmV3IGFuY2hvciBpbXBvcnRz
IHRoZSBNTidzIElQIGFkZHJlc3MgKGJpbmRpbmcpIGNvbnRleHQgdG8gZW5hYmxlIElQIGFkZHJl
c3MNCmNvbnRpbnVpdHkuIFRvIGVuYWJsZSByb3V0aW5nIHRoZSBNTidzIGRvd25saW5rIGRhdGEg
dG8gaXRzIGN1cnJlbnQgYW5jaG9yDQppbiB0aGUgdHJhbnNwb3J0IG5ldHdvcmsgYWJvdmUgYW5j
aG9yIGxldmVsLCBlLmcuIGhvc3Qgcm91dGVzIGNhbiBiZSB1c2VkLg0KDQpXZSBlbmQgdXAgaW4g
YSByb3V0aW5nLW9ubHkgYXBwcm9hY2ggaWYgdGhlc2UgYW5jaG9ycyB3aWxsIGJlIGRpc3RyaWJ1
dGVkIHRvIGFuIGV4dHJlbWUNCmFuZCBwbGFjZWQgZS5nLiBvbiByYWRpbyBhY2Nlc3MgcG9pbnRz
IGFuZCB0aGUgYXBwcm9hY2ggdXNlcyBzb21ldGhpbmcgZWxzZSB0aGFuDQpNSVAgcHJvdG9jb2xz
IHRvIHRyYW5zZmVyIElQIGFkZHJlc3MgY29udGV4dCBiZXR3ZWVuIHRoZXNlIGFjY2VzcyBwb2lu
dHMuIFRoZW4gd2UNCmhhdmUgUGV0ZSdzIERNTSBkZXBsb3ltZW50IG1vZGVsLiANCg0KRG8geW91
IGFncmVlIHRvIHRoYXQgdmlldz8NCg0KSSB0aGluayB0aGVyZSBpcyBjb21tb24gdW5kZXJzdGFu
ZGluZyB0aGF0IERNTSBpcyBhIGxvdCBhYm91dCBkZXBsb3ltZW50Lg0KQW55IG9mIHRob3NlIGRl
cGxveW1lbnQgbW9kZWxzIGFyZSB2YWxpZC4gV2hlcmVhcyB0aGUgRE1NIFdHIGNhbm5vdCB3b3Jr
IG9uIGFsbA0KZXh0ZW5zaW9ucyBuZWVkZWQgdG8gZW5hYmxlIGFsbCBtb2RlbHMsIHdlIHNob3Vs
ZCBjb252ZXJnZSBvbiBhIHJlYXNvbmFibGUNCnNldCBvZiBmaXJzdCB3b3JrIGl0ZW1zIHRvIGFs
bG93IG9wZXJhdG9ycyB0byBlbmFibGUgRE1NIGluIHRoZWlyIG5ldHdvcmsuDQoNCm1hcmNvDQoN
Cg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogQ2FybG9zIEplc8O6cyBCZXJu
YXJkb3MgQ2FubyBbbWFpbHRvOmNqYmNAaXQudWMzbS5lc10NCj5TZW50OiBNaXR0d29jaCwgMTMu
IE5vdmVtYmVyIDIwMTMgMTE6NTENCj5UbzogTWFyY28gTGllYnNjaA0KPkNjOiBTcmkgR3VuZGF2
ZWxsaSAoc2d1bmRhdmUpOyBQZXRlciBNY0Nhbm47IGRtbUBpZXRmLm9yZw0KPlN1YmplY3Q6IFJl
OiBbRE1NXSBQcmVwYXJpbmcgZm9yIERNTSBmdXR1cmUgc3RlcHMgYW5kIHJlY2hhcnRlcmluZw0K
Pg0KPkhpLA0KPg0KPkknbSBhbHNvIGp1bXBpbmcgaW50byB0aGUgZGlzY3Vzc2lvbiBhIGJpdCBs
YXRlLg0KPg0KPldpdGhvdXQgZ29pbmcgaW50byBhbGwgdGhlIGRldGFpbGVkIGRpc2N1c3Npb25z
IHRoYXQgaGF2ZSB0YWtlbiBwbGFjZSByZWNlbnRseSwgSQ0KPmp1c3Qgd2FudCB0byBzaGFyZSBt
eSB2aWV3IG9uIHRoZSBNSVAtYmFzZWQgdnMgcm91dGluZy1iYXNlZCBhcHByb2FjaC4NCj4NCj5J
TUhPLCB3ZSBwcm9iYWJseSBuZWVkIHRvIGZ1cnRoZXIgbG9vayBhdCBib3RoIGFwcHJvYWNoZXMg
aW4gdGhpcyBncm91cCwgYnV0DQo+d2l0aCBlbm91Z2ggZW5lcmd5IGxldmVsIChvdGhlcndpc2Ug
d2UgcmlzayB0byBlbmQgdXAgd2l0aCBub3RoaW5nIGFmdGVyIHNldmVyYWwNCj55ZWFycykuIEkg
cGVyc29uYWxseSBoYXZlIG15IGRvdWJ0cyB0aGF0IGEgZGlzdHJpYnV0ZWQgcm91dGluZy1iYXNl
ZCBhcHByb2FjaA0KPnNjYWxlcyBpbiBhIG1vZGVyYXRlbHkgbGFyZ2UgZG9tYWluICh3ZSBhbHNv
IHNhdyBtYW55IHllYXJzIGFnbyBwcm9wb3NhbHMgb2YNCj5kb2luZyBtb2JpbGl0eSB3aXRoIHJv
dXRpbmcgdGhhdCBkaWQgbm90IHRha2Ugb2ZmIGJlY2F1c2Ugb2YgY29udmVyZ2VuY2UsDQo+c2Nh
bGFiaWxpdHkgYW5kIGFkbWluaXN0cmF0aXZlIGlzc3VlcykuDQo+SSB0aGluayBhIE1JUC1iYXNl
ZCBhcHByb2FjaCAobmV0d29yayBvciBob3N0IGJhc2VkKSB3b3VsZCB3b3JrLCB0aG91Z2ggaXQN
Cj53b3VsZCBpbXBseSBrZWVwaW5nIG11bHRpcGxlIGFuY2hvcnMgYWN0aXZlIGZvciBhIGdpdmVu
IE1OLg0KPg0KPldlIGJlbGlldmUgdGhpcyByb3V0aW5nLWJhc2VkIHZzIE1JUC1iYXNlZCBjb21w
YXJpc29uIGlzIHF1aXRlIGludGVyZXN0aW5nLCBhbmQNCj53ZSBhcmUgYWN0dWFsbHkgd29ya2lu
ZyBhdCBVQzNNIG9uIGV4cGVyaW1lbnRhbGx5IGV2YWx1YXRpbmcgYm90aCwgc28gd2UgY2FuDQo+
bWFrZSBhIG1vcmUgZWR1Y2F0ZWQgc3RhdGVtZW50IG9uIHByb3MgYW5kIGNvbnMgb2YgZWFjaCBv
ZiB0aGVtLg0KPg0KPk15IHR3byBjZW50cywNCj4NCj5DYXJsb3MNCj4NCj5PbiBXZWQsIDIwMTMt
MTEtMTMgYXQgMTA6MTAgKzAwMDAsIE1hcmNvIExpZWJzY2ggd3JvdGU6DQo+PiBIaSBTcmksIGFs
bCwNCj4+IGxldCBtZSBzdGVwIGluIGhlcmUgKHdpdGggc29tZSBkZWxheS4uKSB0byBjbGFyaWZ5
IG9uZSBwb2ludCB5b3UgcmFpc2VkLg0KPj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+Pg0KPj4gPi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogZG1tLWJvdW5jZXNAaWV0Zi5vcmcg
W21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+PiA+U3JpIEd1bmRh
dmVsbGkgKHNndW5kYXZlKQ0KPj4gPlNlbnQ6IE1vbnRhZywgMTEuIE5vdmVtYmVyIDIwMTMgMTY6
MzANCj4+ID5UbzogUGV0ZXIgTWNDYW5uDQo+PiA+Q2M6IGRtbUBpZXRmLm9yZw0KPj4gPlN1Ympl
Y3Q6IFJlOiBbRE1NXSBQcmVwYXJpbmcgZm9yIERNTSBmdXR1cmUgc3RlcHMgYW5kIHJlY2hhcnRl
cmluZw0KPj4gPg0KPj4gPkhpIFBldGUsDQo+PiA+DQo+PiA+SSdtIG5vdCBzdXJlLCBJIGFncmVl
IHdpdGggdGhpcywgb3IgdW5kZXJzdGFuZCB0aGlzIHRvIGJlIHByZWNpc2UuIEkNCj4+ID5kbyBu
b3Qga25vdyBrbm93IENQIChpbiB0aGUgZm9ybSBvZiBQTUlQLCBHVFAgb3Igc29tZSBvdGhlciBw
cm90b2NvbA0KPj4gPlhZWikgY2FuIGJlIGNvbXBsZXRlbHkgZWxpbWluYXRlZC4gVGhlcmUgbmVl
ZHMgdG8gYmUgc29tZSBpbnRlcmZhY2UNCj4+ID5iZXR3ZWVuIHRoZSBhY2Nlc3MgZ2F0ZXdheSBh
bmQgdGhlIG1vYmlsaXR5IGFuY2hvci4gSSBhc3N1bWVkIHlvdXIncywNCj4+ID5NYXJjbydzIGFu
ZCBSeXVqaSdzIGdvYWwgaXMgZm9yIGVsaW1pbmF0aW5nIHRoZSB0dW5uZWwsIHdoaWNoIEkgZG9u
J3QNCj4+ID5iZWxpZXZlIGl0IGNhbiBiZSBhY2hpZXZlZCwgYnV0IHN0aWxsIHRob3VnaHQgd2Ug
Y2FuIGRpc2N1c3MgdGhpcy4NCj4+DQo+PiBNeSBpbnRlbnRpb24gaXMgbm90IHRvIGVsaW1pbmF0
ZSBhIHR1bm5lbCB0aGF0IGV4aXN0cyBpbiBhbnkgb2YgdGhlDQo+PiB0dW5uZWwgbWFuYWdlbWVu
dCBwcm90b2NvbHMgKGFrYSBNSVA2LCBQTUlQNiwgLi4pLiBNeSBwaWN0dXJlIG9mIERNTQ0KPj4g
cHJpbWFyaWx5IGRpc3RyaWJ1dGVzIHRvcG9sb2dpY2FsIGFuY2hvciBwb2ludCBmb3IgdGhlIE1O
J3MgSVAgYWRkcmVzcyhlcykuDQo+Rm9yZ2V0IGFib3V0IHRoZSBDLXBsYW5lIGZvciBub3cuDQo+
PiBUdW5uZWxzIGFwcGx5IHNvbGVseSBiZWxvdyAod2VsbCwgdG93YXJkcyBhY2Nlc3MpIHN1Y2gg
YW5jaG9yLg0KPj4gSWYgd2UgZGlzdHJpYnV0ZSB0aGVtIHRvIGFuIGV4dHJlbWUsIHRoZXkgYXJl
IHBsYWNlZCBvbiByYWRpbyBhY2Nlc3MNCj4+IHBvaW50cyBhbmQgdGhlIHR1bm5lbCBkaXNhcHBl
YXJzLiBUaGVuIHdlIGFycml2ZSBhdCBQZXRlJ3MgbW9kZWwuIElmDQo+PiBhbmNob3IgcG9pbnRz
IGFyZSBzb21ld2hlcmUgYWJvdmUsIHNheSBpbiB0aGUgYmFja2hhdWwsIHRoZSB0dW5uZWwNCj4+
IHJlbWFpbnMgYXQgbGVhc3QgYmV0d2VlbiB0aGUgYW5jaG9yIGFuZCBzb21lIG5vZGUgaW4gdGhl
IGFjY2VzcyAobmV0d29yaw0KPmJhc2VkIG1vYmlsaXR5IG1nbW50KSBvciB0aGUgTU4gKGhvc3Qg
YmFzZWQgbW9iaWxpdHkgbWdtbnQpLg0KPj4NCj4+IEkgdGhpbmsgbm9uZSBvZiB0aGUgcHJvcG9z
YWxzIHdhbnRzIHRvIGRpc2N1c3MgYXdheSB0aGUgdHVubmVscyBhcyBwZXINCj4+IE1JUC9QTUlQ
LiBCdXQgYWJvdmUgYW5jaG9yIGxldmVsLCByZWd1bGFyIHJvdXRpbmcgYXBwbGllcyB0byBwbGFp
biBkYXRhDQo+cGFja2V0cyBvZiB0aGUgVS1QbGFuZS4NCj4+IEEga2V5IGNvbXBvbmVudCBmb3Ig
RE1NLCBJTU8sIGlzIGhvdyB0byBhY2NvbXBsaXNoIHRoYXQgcm91dGluZw0KPj4gdG93YXJkcyB0
aGUgTU4ncyBjdXJyZW50IGFuY2hvciBwb2ludCwgZXZlbiBpZiB0aGUgYW5jaG9yZWQgSVAgYWRk
cmVzcyBpcw0KPnRvcG9sb2dpY2FsbHkgaW5jb3JyZWN0Lg0KPj4gVG8gYWNjb21wbGlzaCB0aGlz
LCBteSBpbnRlbnQgaXMgdG8gbm90IGludHJvZHVjZSB0dW5uZWxzIGFib3ZlIGFuY2hvciBsZXZl
bC4NCj4+IFNvLCBpdCdzIG5vdCBhYm91dCBlbGltaW5hdGluZyB0dW5uZWxzLCBidXQgaXQgaXMg
YWJvdXQgbm90DQo+PiBpbnRyb2R1Y2luZyB0dW5uZWxzIHdoZXJlIG5ldmVyIGhhdmUgYmVlbiB0
dW5uZWxzIGJlZm9yZSA6LSkNCj4+DQo+PiBtYXJjbw0KPj4NCj4+ID4gSU1PLCBpdHMgbm90IGp1
c3QgYWJvdXQgaW5zZXJ0aW5nIGEgUklCIHJvdXRlIGFuZCByZWRpc3RyaWJ1dGluZyBpdCwNCj4+
ID5idXQgZXZlbiB0aGVyZSBpbiBEUCB0aGVyZSBpcyBhIHN0YXRlIHRyYW5zZmVyIG5lZWRlZCAg
ZnJvbSB0aGUgQ1ANCj4+ID5hbmQgdGhlIERQLiBTdGFydGluZyBwb2ludCBhcHBlYXJzIGxpa2Ug
YSBzaW1wbGUgcm91dGUgcHJvcGFnYXRpb24sDQo+PiA+dmVyeSBzb29uIGl0IHdpbGwgZW5kIHVw
IHdpdGggYSBidW5jaCBvZiBzdGF0ZSB0aGF0IGdldHMgbW92ZWQNCj4+ID5iZXR3ZWVuIHRoZSB0
d28gbm9kZXMuICBCdXQsIG1heSBiZSBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIGlkZWFzDQo+PiA+
Y2xlYXJseSBvbiBlbGltaW5hdGluZyBDUCBhbmQgZWxpbWluYXRpbmcgdHVubmVscy4NCj4+ID5J
J20gbm90IGdvaW5nIHRvIG9wcG9zZSB0aGlzLCBJIGRvbid0IHNlZSB0aGlzIGNvbnZlcmdpbmcs
IElNSE8uDQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+DQo+PiA+UmVnYXJkcw0KPj4gPlNyaQ0KPj4g
Pg0KPj4gPg0KPj4gPg0KPj4gPk9uIDExLzEwLzEzIDM6MTMgUE0sICJQZXRlciBNY0Nhbm4iIDxQ
ZXRlci5NY0Nhbm5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+PiA+DQo+PiA+PkhpLCBTcmksDQo+PiA+
Pg0KPj4gPj5JIHRoaW5rIHlvdSB3aWxsIGFncmVlIHRoYXQgUE1JUCBpcyBhIGNvbnRyb2wgcHJv
dG9jb2wgZm9yIHNldHRpbmcNCj4+ID4+dXAgdHVubmVscy4gIEEgdHVubmVsIGltcGxpZXMgdGhh
dCB3ZSBhcmUgbm90IHVzaW5nIHRoZSBkZXN0aW5hdGlvbg0KPj4gPj5JUCBvZiB0aGUgaW5uZXIg
cGFja2V0IGZvciByb3V0aW5nIGFuZCBieSBkZWZpbml0aW9uIHdpbGwgbGVhZCB0byBhDQo+PiA+
Pm5vbi1vcHRpbWFsIHJvdXRlIGFuZCBhIGJpdCBvZiBzdGF0ZSBvbiBzb21lIGJveCB0aGF0IGNh
biBmYWlsIGFuZA0KPj4gPj5sb3NlIHRoYXQgc3RhdGUuDQo+PiA+Pg0KPj4gPj5JIGhvcGUgdGhh
dCBETU0gY2FuIGNvbnNpZGVyIG90aGVyIGFwcHJvYWNoZXMgc3VjaCBhcyBpbmplY3RpbmcNCj4+
ID4+cm91dGVzIGZyb20gdGhlIGxhdGVzdCBMMi1hdHRhY2htZW50IHBvaW50IGludG8gdGhlIGFj
Y2VzcyBuZXR3b3JrLA0KPj4gPj53aGljaCBpcyBhIHRydWx5IERpc3RyaWJ1dGVkIE1vYmlsaXR5
IE1hbmFnZW1lbnQgcHJvdG9jb2wgZm9yDQo+PiA+PmdldHRpbmcgdGhlIHBhY2tldHMgdG8gdGhl
IG1vYmlsZSBub2RlLiAgSXQgd2lsbCBsZWFkIHRvIG1vcmUNCj4+ID4+b3B0aW1hbCByb3V0ZXMg
YW5kIG1vcmUgcm9idXN0IGZhdWx0LXRvbGVyYW50IG9wZXJhdGlvbiBvZiB0aGUgbmV0d29yay4N
Cj4+ID4+DQo+PiA+PkkgdGhpbmsgd2UgY2FuIGNvbnRpbnVlIHRvIHVzZSB0aGUgdGVybSBNQUcg
dG8gYXBwbHkgdG8gdGhhdA0KPj4gPj5maXJzdC1ob3Agcm91dGVyIHdoaWNoIGlzIGhvcGVmdWxs
eSBjby1sb2NhdGVkIHdpdGggdGhlIEwyDQo+PiA+PnRlcm1pbmF0aW9uIHBvaW50IChpdCBtYXkg
bm90IGJlIHNvIGluIGV2ZXJ5IHRlY2hub2xvZ3kgZGVwZW5kaW5nIG9uDQo+PiA+PnRoZSBleHRl
bnQgdG8gd2hpY2ggdGhhdCB0ZWNobm9sb2d5IGhhcyBldm9sdmVkIHRvIHN1cHBvcnQgdHJ1bHkg
RGlzdHJpYnV0ZWQNCj5vcGVyYXRpb24pLg0KPj4gPj5Bbnl0aGluZyB0aGF0IGhhcHBlbnMgYmVs
b3cgdGhlIE1BRyAoYmV0d2VlbiB0aGUgTUFHIGFuZCB0aGUgTDINCj4+ID4+dGVybWluYXRpb24g
cG9pbnQpIHNob3VsZCBiZSBvdXQgb2Ygc2NvcGUgYW5kIHdlIHNob3VsZCBub3QgZGVmaW5lDQo+
PiA+PmFueSBwcm90b2NvbCB0aGVyZSBhbmQgd2Ugc2hvdWxkIGRpc2NvdXJhZ2UgYW55IHNlcGFy
YXRpb24gYmV0d2VlbiB0aGUNCj50d28uDQo+PiA+Pg0KPj4gPj5Ib3dldmVyLCB3ZSBzaG91bGQg
bm90IHJlcXVpcmUgdGhlIE1BRyB0byBydW4gYW55IGZvcm0gb2YgUE1JUA0KPj4gPj5iZWNhdXNl
IHR1bm5lbHMgc2hvdWxkIG5vdCBiZSByZXF1aXJlZCBpbiB0aGUgYXJjaGl0ZWN0dXJlLiAgV2UN
Cj4+ID4+c2hvdWxkIG5vdCByZXF1aXJlIGFuIExNQSwgYmVjYXVzZSB0aGlzIHdvdWxkIGltcGx5
IGEgY2VudHJhbCBwb2ludA0KPj4gPj5vZiBzdGF0ZSBtYWludGVuYW5jZSBhbmQgcG9zc2liaWxp
dHkgb2YgZmFpbHVyZS4NCj4+ID4+DQo+PiA+Pkl0IGlzIGZpbmUgdG8gY29uc2lkZXIgYSBzcGxp
dCBiZXR3ZWVuIENQIGFuZCBEUCBidXQgSSB0aG91Z2h0IHdlDQo+PiA+PmhhZCBhZ3JlZWQgdGhh
dCBhbnkgZGlzY3Vzc2lvbiBvZiB0aGUgcHJvdG9jb2wgdG8gdXNlIG9uIHN1Y2ggYW4NCj4+ID4+
aW50ZXJmYWNlIHdvdWxkIGJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBXRy4gIElNSE8gd2Ugc2hv
dWxkIGxlYXZlDQo+PiA+PnRoYXQgdG8gdGhlIFdpcmVsZXNzICYgTW9iaWxlIFdvcmtpbmcgR3Jv
dXAgb2YgT05GLg0KPj4gPj4NCj4+ID4+Tm93LCB0aGUgcHJvcG9uZW50cyBvZiBPcGVuRmxvdyBh
bmQgb3RoZXIgQ1AvRFAgc3BsaXRzIGhhdmUgYXJndWVkDQo+PiA+PnRoYXQgaXQgaXMgYmV0dGVy
IHRvIGNlbnRyYWxpemUgdGhlIGFsZ29yaXRobXMgc3VjaCBhcyByb3V0aW5nDQo+PiA+PnByb3Rv
Y29scyBvbiBhIGxvZ2ljYWxseSBjZW50cmFsaXplZCBzZXJ2ZXIgb3Igc2VydmVycyB3aXRoIGEN
Cj4+ID4+c3luY2hyb25pemVkIGdsb2JhbCB2aWV3IG9mIHRoZSBuZXR3b3JrLg0KPj4gPj5JIGhh
dmUgbm8gcHJvYmxlbSB3aXRoIHRoYXQsIGluIHdoaWNoIGNhc2UgdGhpcyBjZW50cmFsaXplZA0K
Pj4gPj5jb250cm9sbGVyIGp1c3QgbmVlZHMgdG8gZ2V0IG5vdGlmaWVkIGFib3V0IHRoZSBNTidz
IGN1cnJlbnQNCj4+ID4+YXR0YWNobWVudCBwb2ludCwgc28gaXQgY2FuIGluc3RhbGwgdGhlIHJv
dXRlcyAob3IgdHVubmVscywgaWYgYW4NCj4+ID4+b3BlcmF0b3Igd2lzaGVzIHRvIHVzZQ0KPj4g
Pj50aGVtKSBpbnRvIHRoZSBEUC4NCj4+ID4+QnV0LA0KPj4gPj50aGUgbWVjaGFuaXNtcyBmb3Ig
ZG9pbmcgc28gYXJlIG91dCBvZiBzY29wZSBmb3IgdGhlIERNTSBXRyBiZWNhdXNlDQo+PiA+Pndl
IGFyZSBub3Qgd29ya2luZyBvbiBhIENQL0RQIHNwbGl0LiAgSSB0aGluayBpdCB3b3VsZCBiZQ0K
Pj4gPj5hcHByb3ByaWF0ZSBmb3IgdGhlIERNTSBXRyAod2hpY2ggZXhpc3RzIGluIHRoZSBJRVRG
LCBhIHN0YW5kYXJkcw0KPj4gPj5ib2R5IHRoYXQgaGFzIGEgbG9uZyBoaXN0b3J5IG9mIGRldmVs
b3BpbmcgZGlzdHJpYnV0ZWQgYW5kDQo+PiA+PmZhdWx0LXRvbGVyYW50IHJvdXRpbmcgcHJvdG9j
b2xzKSB0byBkZXNjcmliZSBhIG1vcmUgZGlzdHJpYnV0ZWQNCj4+ID4+YWx0ZXJuYXRpdmUsIGJ1
aWxkaW5nIG9uIGZvdW5kYXRpb25hbCBJbnRlcm5ldCB0ZWNobm9sb2dpZXMgc3VjaCBhcw0KPj4g
Pj5JLUJHUCwgaW4gc3VjaCBhIHdheSB0aGF0IHdpbGwgYnJpbmcgZG93biB0aGUgY29zdHMsIHJl
ZHVjZSB0aGUNCj4+ID4+bGF0ZW5jeSwgYW5kIGluY3JlYXNlIHRoZSByb2J1c3RuZXNzIG9mIHdp
cmVsZXNzIGFjY2VzcyBuZXR3b3Jrcy4NCj4+ID4+DQo+PiA+PkkgYWN0dWFsbHkgZG9uJ3QgdGhp
bmsgd2UgbmVlZCB0byBkZWZpbmUgYW55IG5ldyBleHRlbnNpb25zIG9yIElFcw0KPj4gPj5mb3Ig
QkdQOyBJIHdvdWxkIGxpa2UgdG8gcmVhZCBtb3JlIGFib3V0IFJ5dWppJ3MgcHJvcG9zZWQgZXh0
ZW5zaW9ucyBoZXJlLg0KPj4gPj5BbGwgd2UgbmVlZCBpcyBmb3IgdGhlIE1BRyB0byBsZWFybiB3
aGF0IElQcyBoYXZlIGJlZW4gYXNzaWduZWQgdG8NCj4+ID4+dGhlIE1OLCBkZWNpZGUgd2hpY2gg
b2YgdGhvc2UgSVBzIGFyZSBpbiB0aGUgc2NvcGUgb2YgdGhlIGxvY2FsIEFTLA0KPj4gPj5hbmQg
aW5qZWN0IHJvdXRlcyBmb3IgdGhvc2UgcHJlZml4ZXMgdG8gaXRzZWxmLiAgV2UgY291bGQgd29y
ayBvbg0KPj4gPj5hbHRlcm5hdGl2ZSBtZWNoYW5pc21zIGZvciBkaXNjb3ZlcmluZyB0aGlzIGxp
c3Qgb2YgYWRkcmVzc2VzIC0gdGhlDQo+PiA+PmZ1bmRhbWVudGFsIHJlcXVpcmVtZW50IGlzIHRo
YXQgd2UgdXNlIGFuIGF1dGhlbnRpY2F0ZWQgTU4gSUQNCj4+ID4+KHByb2JhYmx5IGFuIE5BSSkg
YXMgYW4gaW5kZXggdG8gbG9va3VwIHRoZSBzZXQgb2YgSVBzIGluIGEgZGlzdHJpYnV0ZWQNCj5k
YXRhYmFzZS4NCj4+ID4+SSd2ZSBwcm9wb3NlZCB1c2luZyBETlMgZm9yIHRoaXMgYnV0IHRoZXJl
IGFyZSBvdGhlciBhbHRlcm5hdGl2ZXMuDQo+PiA+PldlIGFsc28gbmVlZCBhIHdheSB0byBtYWtl
IHN1cmUgdGhlIGxhdGVzdCBVUERBVEUgZ2V0cyB1c2VkIGJ5IGFsbA0KPj4gPj50aGUgQkdQIHBl
ZXJzLg0KPj4gPj5JJ3ZlIHByb3Bvc2VkDQo+PiA+PnB1dHRpbmcgYSB0aW1lc3RhbXAgaW4gTE9D
QUxfUFJFRiBidXQgdGhlcmUgYXJlIHByb2JhYmx5IG90aGVyDQo+PiA+PmFsdGVybmF0aXZlcy4N
Cj4+ID4+DQo+PiA+Pkl0IHdvdWxkIGFsc28gYmUgbmljZSB0byBoYXZlIGEgd2VsbC1kZWZpbmVk
IGZhbGwtYmFjayBtZWNoYW5pc20gaW4NCj4+ID4+Y2FzZSB0aGUgTU4gbW92ZXMgdG8gYSBkaWZm
ZXJlbnQgQVMgb3IganVzdCB0b28gZmFyIGZyb20gdGhlDQo+PiA+Pm9yaWdpbmFsIE1BRywgaW4g
d2hpY2ggY2FzZSB0aGUgSS1CR1AgYXBwcm9hY2ggd291bGRuJ3Qgc2NhbGUuICBGb3INCj4+ID4+
dGhlc2UgY2FzZXMsIEkgdGhpbmsgYSBjbGllbnQgTUlQIHR1bm5lbCB0byBhbiBIQSBsb2NhdGVk
IGluIHRoZQ0KPj4gPj5vcmlnaW5hbCBBUyBmb3IgZWFjaCBhc3NpZ25lZCBJUCBhZGRyZXNzIHdv
dWxkIGJlIGlkZWFsLg0KPj4gPj5UaGUgSEEgY2FuIGJlaGF2ZSBqdXN0IGxpa2UgdGhlIE1BR3Mg
aW4gdGhhdCBkb21haW4sIGluamVjdGluZw0KPj4gPj5yb3V0ZXMgd2hlbiBNTnMgZXN0YWJsaXNo
IHR1bm5lbHMgdG8gaXQgc28gYXMgdG8gYXR0cmFjdCB0aGUgcGFja2V0cw0KPj4gPj50byB0aGVt
c2VsdmVzICh0aGlzIHdvdWxkIGJlIHRoZSByb3V0aW5nIGVxdWl2YWxlbnQgb2YgdGhlIHByb3h5
LUFSUA0KPj4gPj5vciBwcm94eS1ORCBtZWNoYW5pc20gdGhhdCB3b3JrcyBvbiBqdXN0IGEgc2lu
Z2xlIGhvbWUgbGluayBpbiBNSVB2NA0KPj4gPj5vciBNSVB2NikuICBXZSBzaG91bGQgd29yayBv
biBtZWNoYW5pc21zIHRvIGVuYWJsZSBkeW5hbWljDQo+PiA+PmFzc2lnbm1lbnQgb2YgbG9jYWwg
SEFzIHRvIE1OcyBhbmQgZHluYW1pYyBlc3RhYmxpc2htZW50IG9mIHNlY3VyaXR5DQo+PiA+PmFz
c29jaWF0aW9ucyB0aGF0IGRvbid0IHJlcXVpcmUgQUFBIGFuZCBhc3NvY2lhdGVkIHJvdW5kLXRy
aXBzIHRvIHRoZSBob21lDQo+bmV0d29yay4NCj4+ID4+QmVjYXVzZSB0aGUgSEENCj4+ID4+aXMg
YXNzb2NpYXRlZCB3aXRoIHRoZSBvcmlnaW5hbCBNQUcgdGhhdCBhc3NpZ25lZCB0aGUgYWRkcmVz
cywgdGhpcw0KPj4gPj5tYXkgaW52b2x2ZSBzb21lIERIQ1AgZXh0ZW5zaW9ucy4gIFRoZXJlIGlz
IGFscmVhZHkgYSB3YXkgdG8gYXNzaWduDQo+PiA+PnRoZSBIQSBJUCBhZGRyZXNzIGJ1dCB3ZSB3
aWxsIG5lZWQgbmV3IGV4dGVuc2lvbnMgdG8gY2FycnkgdGhlIEhBDQo+PiA+PmNyZWRlbnRpYWxz
IHRvIHRoZSBNTiAobWF5YmUganVzdCBhbiBIQSBETlMgbmFtZSBzbyB0aGUgTU4gY2FuIHVzZQ0K
Pj4gPj5EQU5FIHRvIHJldHJpZXZlIGEgcHVibGljIGtleSkuDQo+PiA+Pg0KPj4gPj5JIHRoaW5r
IHNvbWV0aGluZyBsaWtlIHRoZSBwYXRoIEkndmUgb3V0bGluZWQgYWJvdmUgd291bGQgbWFrZSBh
DQo+PiA+Pmdvb2Qgd29yayBwbGFuIGZvciB0aGUgZnV0dXJlIG9mIERNTS4NCj4+ID4+DQo+PiA+
Pi1QZXRlDQo+PiA+Pg0KPj4gPg0KPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+PiA+ZG1tIG1haWxpbmcgbGlzdA0KPj4gPmRtbUBpZXRmLm9yZw0K
Pj4gPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQo+PiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gZG1tIG1haWxpbmcg
bGlzdA0KPj4gZG1tQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2RtbQ0KPg0KDQo=

From cjbc@it.uc3m.es  Wed Nov 13 03:47:55 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2687B11E80E3 for ; Wed, 13 Nov 2013 03:47:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.932
X-Spam-Level: 
X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxqRkQ15ewyS for ; Wed, 13 Nov 2013 03:47:50 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by ietfa.amsl.com (Postfix) with ESMTP id D883F11E8110 for ; Wed, 13 Nov 2013 03:47:49 -0800 (PST)
Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 212B0CD2AE9; Wed, 13 Nov 2013 12:47:49 +0100 (CET)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [163.117.95.165] (unknown [163.117.95.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp01.uc3m.es) by smtp01.uc3m.es (Postfix) with ESMTPSA id 0E313CC3D50; Wed, 13 Nov 2013 12:47:48 +0100 (CET)
Message-ID: <1384343268.4137.32.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: Marco Liebsch 
Date: Wed, 13 Nov 2013 12:47:48 +0100
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D6374AEF3@Hydra.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>  <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd> <1384339889.4137.13.camel@acorde.it.uc3m.es> <69756203DDDDE64E987BC4F70B71A26D6374AEF3@Hydra.office.hd>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20288.003
Cc: Peter McCann , "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 11:47:55 -0000

Hi Marco,

On Wed, 2013-11-13 at 11:23 +0000, Marco Liebsch wrote:
> Carlos, 
> 
> just to clarify my view here: I do not see them as different approaches,
> but in a way that the routing approach can complement mobility anchor-based
> approaches (MIP-like protocols). And such routing support is needed only
> in certain deployments, i.e. in case of a runtime change of the MN's anchor
> while the new anchor imports the MN's IP address (binding) context to enable IP address
> continuity. To enable routing the MN's downlink data to its current anchor
> in the transport network above anchor level, e.g. host routes can be used.

I'm not sure I agree on this. To me this seem to already assume a
certain solution. And I'm biased because I also have some solutions in
mind :D

For example, I think we should not limit only to downlink, unless the
ingress filtering is not considered an issue (if it is not, this also
kind-of assumes a certain type of solution).

> 
> We end up in a routing-only approach if these anchors will be distributed to an extreme
> and placed e.g. on radio access points and the approach uses something else than
> MIP protocols to transfer IP address context between these access points. Then we
> have Pete's DMM deployment model. 

Agree, but a routing approach could also be applied even if the anchors
are not placed on the radio access points. That's why I see routing as
an alternative solution to IP mobility protocols.

> 
> Do you agree to that view?
> 
> I think there is common understanding that DMM is a lot about deployment.
> Any of those deployment models are valid. Whereas the DMM WG cannot work on all
> extensions needed to enable all models, we should converge on a reasonable
> set of first work items to allow operators to enable DMM in their network.

I agree. It would be helpful to get some feedback from operators on
which deployments they have more interest on.

Thanks,

Carlos

> 
> marco
> 
> 
> >-----Original Message-----
> >From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es]
> >Sent: Mittwoch, 13. November 2013 11:51
> >To: Marco Liebsch
> >Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org
> >Subject: Re: [DMM] Preparing for DMM future steps and rechartering
> >
> >Hi,
> >
> >I'm also jumping into the discussion a bit late.
> >
> >Without going into all the detailed discussions that have taken place recently, I
> >just want to share my view on the MIP-based vs routing-based approach.
> >
> >IMHO, we probably need to further look at both approaches in this group, but
> >with enough energy level (otherwise we risk to end up with nothing after several
> >years). I personally have my doubts that a distributed routing-based approach
> >scales in a moderately large domain (we also saw many years ago proposals of
> >doing mobility with routing that did not take off because of convergence,
> >scalability and administrative issues).
> >I think a MIP-based approach (network or host based) would work, though it
> >would imply keeping multiple anchors active for a given MN.
> >
> >We believe this routing-based vs MIP-based comparison is quite interesting, and
> >we are actually working at UC3M on experimentally evaluating both, so we can
> >make a more educated statement on pros and cons of each of them.
> >
> >My two cents,
> >
> >Carlos
> >
> >On Wed, 2013-11-13 at 10:10 +0000, Marco Liebsch wrote:
> >> Hi Sri, all,
> >> let me step in here (with some delay..) to clarify one point you raised.
> >> Please see inline.
> >>
> >> >-----Original Message-----
> >> >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of
> >> >Sri Gundavelli (sgundave)
> >> >Sent: Montag, 11. November 2013 16:30
> >> >To: Peter McCann
> >> >Cc: dmm@ietf.org
> >> >Subject: Re: [DMM] Preparing for DMM future steps and rechartering
> >> >
> >> >Hi Pete,
> >> >
> >> >I'm not sure, I agree with this, or understand this to be precise. I
> >> >do not know know CP (in the form of PMIP, GTP or some other protocol
> >> >XYZ) can be completely eliminated. There needs to be some interface
> >> >between the access gateway and the mobility anchor. I assumed your's,
> >> >Marco's and Ryuji's goal is for eliminating the tunnel, which I don't
> >> >believe it can be achieved, but still thought we can discuss this.
> >>
> >> My intention is not to eliminate a tunnel that exists in any of the
> >> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
> >> primarily distributes topological anchor point for the MN's IP address(es).
> >Forget about the C-plane for now.
> >> Tunnels apply solely below (well, towards access) such anchor.
> >> If we distribute them to an extreme, they are placed on radio access
> >> points and the tunnel disappears. Then we arrive at Pete's model. If
> >> anchor points are somewhere above, say in the backhaul, the tunnel
> >> remains at least between the anchor and some node in the access (network
> >based mobility mgmnt) or the MN (host based mobility mgmnt).
> >>
> >> I think none of the proposals wants to discuss away the tunnels as per
> >> MIP/PMIP. But above anchor level, regular routing applies to plain data
> >packets of the U-Plane.
> >> A key component for DMM, IMO, is how to accomplish that routing
> >> towards the MN's current anchor point, even if the anchored IP address is
> >topologically incorrect.
> >> To accomplish this, my intent is to not introduce tunnels above anchor level.
> >> So, it's not about eliminating tunnels, but it is about not
> >> introducing tunnels where never have been tunnels before :-)
> >>
> >> marco
> >>
> >> > IMO, its not just about inserting a RIB route and redistributing it,
> >> >but even there in DP there is a state transfer needed  from the CP
> >> >and the DP. Starting point appears like a simple route propagation,
> >> >very soon it will end up with a bunch of state that gets moved
> >> >between the two nodes.  But, may be I don't understand the ideas
> >> >clearly on eliminating CP and eliminating tunnels.
> >> >I'm not going to oppose this, I don't see this converging, IMHO.
> >> >
> >> >
> >> >
> >> >
> >> >Regards
> >> >Sri
> >> >
> >> >
> >> >
> >> >On 11/10/13 3:13 PM, "Peter McCann"  wrote:
> >> >
> >> >>Hi, Sri,
> >> >>
> >> >>I think you will agree that PMIP is a control protocol for setting
> >> >>up tunnels.  A tunnel implies that we are not using the destination
> >> >>IP of the inner packet for routing and by definition will lead to a
> >> >>non-optimal route and a bit of state on some box that can fail and
> >> >>lose that state.
> >> >>
> >> >>I hope that DMM can consider other approaches such as injecting
> >> >>routes from the latest L2-attachment point into the access network,
> >> >>which is a truly Distributed Mobility Management protocol for
> >> >>getting the packets to the mobile node.  It will lead to more
> >> >>optimal routes and more robust fault-tolerant operation of the network.
> >> >>
> >> >>I think we can continue to use the term MAG to apply to that
> >> >>first-hop router which is hopefully co-located with the L2
> >> >>termination point (it may not be so in every technology depending on
> >> >>the extent to which that technology has evolved to support truly Distributed
> >operation).
> >> >>Anything that happens below the MAG (between the MAG and the L2
> >> >>termination point) should be out of scope and we should not define
> >> >>any protocol there and we should discourage any separation between the
> >two.
> >> >>
> >> >>However, we should not require the MAG to run any form of PMIP
> >> >>because tunnels should not be required in the architecture.  We
> >> >>should not require an LMA, because this would imply a central point
> >> >>of state maintenance and possibility of failure.
> >> >>
> >> >>It is fine to consider a split between CP and DP but I thought we
> >> >>had agreed that any discussion of the protocol to use on such an
> >> >>interface would be out of scope for this WG.  IMHO we should leave
> >> >>that to the Wireless & Mobile Working Group of ONF.
> >> >>
> >> >>Now, the proponents of OpenFlow and other CP/DP splits have argued
> >> >>that it is better to centralize the algorithms such as routing
> >> >>protocols on a logically centralized server or servers with a
> >> >>synchronized global view of the network.
> >> >>I have no problem with that, in which case this centralized
> >> >>controller just needs to get notified about the MN's current
> >> >>attachment point, so it can install the routes (or tunnels, if an
> >> >>operator wishes to use
> >> >>them) into the DP.
> >> >>But,
> >> >>the mechanisms for doing so are out of scope for the DMM WG because
> >> >>we are not working on a CP/DP split.  I think it would be
> >> >>appropriate for the DMM WG (which exists in the IETF, a standards
> >> >>body that has a long history of developing distributed and
> >> >>fault-tolerant routing protocols) to describe a more distributed
> >> >>alternative, building on foundational Internet technologies such as
> >> >>I-BGP, in such a way that will bring down the costs, reduce the
> >> >>latency, and increase the robustness of wireless access networks.
> >> >>
> >> >>I actually don't think we need to define any new extensions or IEs
> >> >>for BGP; I would like to read more about Ryuji's proposed extensions here.
> >> >>All we need is for the MAG to learn what IPs have been assigned to
> >> >>the MN, decide which of those IPs are in the scope of the local AS,
> >> >>and inject routes for those prefixes to itself.  We could work on
> >> >>alternative mechanisms for discovering this list of addresses - the
> >> >>fundamental requirement is that we use an authenticated MN ID
> >> >>(probably an NAI) as an index to lookup the set of IPs in a distributed
> >database.
> >> >>I've proposed using DNS for this but there are other alternatives.
> >> >>We also need a way to make sure the latest UPDATE gets used by all
> >> >>the BGP peers.
> >> >>I've proposed
> >> >>putting a timestamp in LOCAL_PREF but there are probably other
> >> >>alternatives.
> >> >>
> >> >>It would also be nice to have a well-defined fall-back mechanism in
> >> >>case the MN moves to a different AS or just too far from the
> >> >>original MAG, in which case the I-BGP approach wouldn't scale.  For
> >> >>these cases, I think a client MIP tunnel to an HA located in the
> >> >>original AS for each assigned IP address would be ideal.
> >> >>The HA can behave just like the MAGs in that domain, injecting
> >> >>routes when MNs establish tunnels to it so as to attract the packets
> >> >>to themselves (this would be the routing equivalent of the proxy-ARP
> >> >>or proxy-ND mechanism that works on just a single home link in MIPv4
> >> >>or MIPv6).  We should work on mechanisms to enable dynamic
> >> >>assignment of local HAs to MNs and dynamic establishment of security
> >> >>associations that don't require AAA and associated round-trips to the home
> >network.
> >> >>Because the HA
> >> >>is associated with the original MAG that assigned the address, this
> >> >>may involve some DHCP extensions.  There is already a way to assign
> >> >>the HA IP address but we will need new extensions to carry the HA
> >> >>credentials to the MN (maybe just an HA DNS name so the MN can use
> >> >>DANE to retrieve a public key).
> >> >>
> >> >>I think something like the path I've outlined above would make a
> >> >>good work plan for the future of DMM.
> >> >>
> >> >>-Pete
> >> >>
> >> >
> >> >_______________________________________________
> >> >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 Marco.Liebsch@neclab.eu  Wed Nov 13 03:59:56 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0967A21F9ECA for ; Wed, 13 Nov 2013 03:59:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.239
X-Spam-Level: 
X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4FKUW-1rWRrA for ; Wed, 13 Nov 2013 03:59:51 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3D63321F9EAF for ; Wed, 13 Nov 2013 03:59:51 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 29D99106024; Wed, 13 Nov 2013 12:53:07 +0100 (CET)
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 UyfJ23ViCFnn; Wed, 13 Nov 2013 12:53:07 +0100 (CET)
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 EE3EC106027; Wed, 13 Nov 2013 12:52:46 +0100 (CET)
Received: from HYDRA.office.hd ([169.254.4.178]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 13 Nov 2013 12:59:30 +0100
From: Marco Liebsch 
To: "cjbc@it.uc3m.es" 
Thread-Topic: [DMM] Preparing for DMM future steps and rechartering
Thread-Index: AQHO2N32tX9akckQbkC/oEY66nusCZoUE9cAgABImwCAAQY4gIAAASiAgABd6ICAABT2rIAAGTgAgAKCNYCAABNZAIAByxEAgAEHGQCAABsyAIAAAfoAgAM2QQCAAAZaAIAAAnoAgAAfUgCAAAWgAIAAOa4AgAEQvoCAAtigQP///j6AgAAUkwD///spAIAAEgfw
Date: Wed, 13 Nov 2013 11:59:29 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D6374FF63@Hydra.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>  <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd> <1384339889.4137.13.camel@acorde.it.uc3m.es> <69756203DDDDE64E987BC4F70B71A26D6374AEF3@Hydra.office.hd> <1384343268.4137.32.camel@acorde.it.uc3m.es>
In-Reply-To: <1384343268.4137.32.camel@acorde.it.uc3m.es>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: Peter McCann , "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 11:59:56 -0000

UGxlYXNlIHNlZSBpbmxpbmUsIENhcmxvcy4NCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
DQo+RnJvbTogQ2FybG9zIEplc8O6cyBCZXJuYXJkb3MgQ2FubyBbbWFpbHRvOmNqYmNAaXQudWMz
bS5lc10NCj5TZW50OiBNaXR0d29jaCwgMTMuIE5vdmVtYmVyIDIwMTMgMTI6NDgNCj5UbzogTWFy
Y28gTGllYnNjaA0KPkNjOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpOyBQZXRlciBNY0Nhbm47
IGRtbUBpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbRE1NXSBQcmVwYXJpbmcgZm9yIERNTSBmdXR1
cmUgc3RlcHMgYW5kIHJlY2hhcnRlcmluZw0KPg0KPkhpIE1hcmNvLA0KPg0KPk9uIFdlZCwgMjAx
My0xMS0xMyBhdCAxMToyMyArMDAwMCwgTWFyY28gTGllYnNjaCB3cm90ZToNCj4+IENhcmxvcywN
Cj4+DQo+PiBqdXN0IHRvIGNsYXJpZnkgbXkgdmlldyBoZXJlOiBJIGRvIG5vdCBzZWUgdGhlbSBh
cyBkaWZmZXJlbnQNCj4+IGFwcHJvYWNoZXMsIGJ1dCBpbiBhIHdheSB0aGF0IHRoZSByb3V0aW5n
IGFwcHJvYWNoIGNhbiBjb21wbGVtZW50DQo+PiBtb2JpbGl0eSBhbmNob3ItYmFzZWQgYXBwcm9h
Y2hlcyAoTUlQLWxpa2UgcHJvdG9jb2xzKS4gQW5kIHN1Y2gNCj4+IHJvdXRpbmcgc3VwcG9ydCBp
cyBuZWVkZWQgb25seSBpbiBjZXJ0YWluIGRlcGxveW1lbnRzLCBpLmUuIGluIGNhc2Ugb2YNCj4+
IGEgcnVudGltZSBjaGFuZ2Ugb2YgdGhlIE1OJ3MgYW5jaG9yIHdoaWxlIHRoZSBuZXcgYW5jaG9y
IGltcG9ydHMgdGhlDQo+PiBNTidzIElQIGFkZHJlc3MgKGJpbmRpbmcpIGNvbnRleHQgdG8gZW5h
YmxlIElQIGFkZHJlc3MgY29udGludWl0eS4gVG8NCj4+IGVuYWJsZSByb3V0aW5nIHRoZSBNTidz
IGRvd25saW5rIGRhdGEgdG8gaXRzIGN1cnJlbnQgYW5jaG9yIGluIHRoZSB0cmFuc3BvcnQNCj5u
ZXR3b3JrIGFib3ZlIGFuY2hvciBsZXZlbCwgZS5nLiBob3N0IHJvdXRlcyBjYW4gYmUgdXNlZC4N
Cj4NCj5JJ20gbm90IHN1cmUgSSBhZ3JlZSBvbiB0aGlzLiBUbyBtZSB0aGlzIHNlZW0gdG8gYWxy
ZWFkeSBhc3N1bWUgYSBjZXJ0YWluDQo+c29sdXRpb24uIEFuZCBJJ20gYmlhc2VkIGJlY2F1c2Ug
SSBhbHNvIGhhdmUgc29tZSBzb2x1dGlvbnMgaW4gbWluZCA6RA0KDQpOb3QgYSBzb2x1dGlvbiwg
YnV0IGEgZGVwbG95bWVudCBtb2RlbC4gVGhlIHNvbHV0aW9uIHdvdWxkIGRpZyBpbnRvIHRoZQ0K
cHJvdG9jb2wgYml0cyBvZiBhIHNlbGVjdGVkIHByb3RvY29sIGUuZy4gQkdQIHRvIHNvbHZlIHRo
YXQuIFRoYXQncyBub3Qgd2hhdA0KSSBhbSB3cml0aW5nIGFib3V0LiBJIHdyaXRlIHRoaXMgb25s
eSB0byBhYnN0cmFjdCB0aGUgYXZhaWxhYmxlIHNvbHV0aW9ucyB0bw0KZGVwbG95bWVudCBtb2Rl
bHMgYW5kIHNlZSB3aGVyZSB0aGUgRE1NIGdyb3VwIGNhbiBkbyBzb21lIHdvcmsgdG8NCmVuYWJs
ZSBhIHZhcmlldHkgb2YgdGhlbS4NCg0KPg0KPkZvciBleGFtcGxlLCBJIHRoaW5rIHdlIHNob3Vs
ZCBub3QgbGltaXQgb25seSB0byBkb3dubGluaywgdW5sZXNzIHRoZSBpbmdyZXNzDQo+ZmlsdGVy
aW5nIGlzIG5vdCBjb25zaWRlcmVkIGFuIGlzc3VlIChpZiBpdCBpcyBub3QsIHRoaXMgYWxzbyBr
aW5kLW9mIGFzc3VtZXMgYSBjZXJ0YWluDQo+dHlwZSBvZiBzb2x1dGlvbikuDQoNCg0KRm9yIHN1
cmUgbm90LiBJIHJlZnJhaW5lZCBmcm9tIGRlc2NyaWJpbmcgdGhlIGNvbXBsZXRlIHNlcXVlbmNl
LCBhcyBpdCdzIG5vdA0KcmVsZXZhbnQgZm9yIHRoaXMgZGlzY3Vzc2lvbi4gSnVzdCB0cnlpbmcg
dG8gZHJhdyBzb21lIG1vZGVscyBhbmQgc2VlIHdoaWNoDQpnYXBzIERNTSBjYW4gY2xvc2UuDQoN
Cj4NCj4+DQo+PiBXZSBlbmQgdXAgaW4gYSByb3V0aW5nLW9ubHkgYXBwcm9hY2ggaWYgdGhlc2Ug
YW5jaG9ycyB3aWxsIGJlDQo+PiBkaXN0cmlidXRlZCB0byBhbiBleHRyZW1lIGFuZCBwbGFjZWQg
ZS5nLiBvbiByYWRpbyBhY2Nlc3MgcG9pbnRzIGFuZA0KPj4gdGhlIGFwcHJvYWNoIHVzZXMgc29t
ZXRoaW5nIGVsc2UgdGhhbiBNSVAgcHJvdG9jb2xzIHRvIHRyYW5zZmVyIElQDQo+PiBhZGRyZXNz
IGNvbnRleHQgYmV0d2VlbiB0aGVzZSBhY2Nlc3MgcG9pbnRzLiBUaGVuIHdlIGhhdmUgUGV0ZSdz
IERNTQ0KPmRlcGxveW1lbnQgbW9kZWwuDQo+DQo+QWdyZWUsIGJ1dCBhIHJvdXRpbmcgYXBwcm9h
Y2ggY291bGQgYWxzbyBiZSBhcHBsaWVkIGV2ZW4gaWYgdGhlIGFuY2hvcnMgYXJlIG5vdA0KPnBs
YWNlZCBvbiB0aGUgcmFkaW8gYWNjZXNzIHBvaW50cy4gVGhhdCdzIHdoeSBJIHNlZSByb3V0aW5n
IGFzIGFuIGFsdGVybmF0aXZlDQo+c29sdXRpb24gdG8gSVAgbW9iaWxpdHkgcHJvdG9jb2xzLg0K
DQpTdXJlLiBCdXQgSSBhbSBub3Qgc3VyZSB0aGF0IGl0IHNob3VsZCBiZSB0aGUgRE1NIGdyb3Vw
IHRoYXQgYnVpbGRzIGEgbmV3DQphbHRlcm5hdGl2ZSB0byBJUCBtb2JpbGl0eS4gV2hhdCdzIHRo
ZSBnYXAgYW5hbHlzaXMgdGhlbiBhYm91dD8NCkludGVyZXN0aW5nIHRvIHJlc2VhcmNoIGFib3V0
LCB0aG91Z2guDQoNCj4NCj4+DQo+PiBEbyB5b3UgYWdyZWUgdG8gdGhhdCB2aWV3Pw0KPj4NCj4+
IEkgdGhpbmsgdGhlcmUgaXMgY29tbW9uIHVuZGVyc3RhbmRpbmcgdGhhdCBETU0gaXMgYSBsb3Qg
YWJvdXQgZGVwbG95bWVudC4NCj4+IEFueSBvZiB0aG9zZSBkZXBsb3ltZW50IG1vZGVscyBhcmUg
dmFsaWQuIFdoZXJlYXMgdGhlIERNTSBXRyBjYW5ub3QNCj4+IHdvcmsgb24gYWxsIGV4dGVuc2lv
bnMgbmVlZGVkIHRvIGVuYWJsZSBhbGwgbW9kZWxzLCB3ZSBzaG91bGQgY29udmVyZ2UNCj4+IG9u
IGEgcmVhc29uYWJsZSBzZXQgb2YgZmlyc3Qgd29yayBpdGVtcyB0byBhbGxvdyBvcGVyYXRvcnMg
dG8gZW5hYmxlIERNTSBpbg0KPnRoZWlyIG5ldHdvcmsuDQo+DQo+SSBhZ3JlZS4gSXQgd291bGQg
YmUgaGVscGZ1bCB0byBnZXQgc29tZSBmZWVkYmFjayBmcm9tIG9wZXJhdG9ycyBvbiB3aGljaA0K
PmRlcGxveW1lbnRzIHRoZXkgaGF2ZSBtb3JlIGludGVyZXN0IG9uLg0KDQoNCkdvb2QuDQoNClRo
YW5rcywNCm1hcmNvDQoNCj4NCj5UaGFua3MsDQo+DQo+Q2FybG9zDQo+DQo+Pg0KPj4gbWFyY28N
Cj4+DQo+Pg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogQ2FybG9z
IEplc8O6cyBCZXJuYXJkb3MgQ2FubyBbbWFpbHRvOmNqYmNAaXQudWMzbS5lc10NCj4+ID5TZW50
OiBNaXR0d29jaCwgMTMuIE5vdmVtYmVyIDIwMTMgMTE6NTENCj4+ID5UbzogTWFyY28gTGllYnNj
aA0KPj4gPkNjOiBTcmkgR3VuZGF2ZWxsaSAoc2d1bmRhdmUpOyBQZXRlciBNY0Nhbm47IGRtbUBp
ZXRmLm9yZw0KPj4gPlN1YmplY3Q6IFJlOiBbRE1NXSBQcmVwYXJpbmcgZm9yIERNTSBmdXR1cmUg
c3RlcHMgYW5kIHJlY2hhcnRlcmluZw0KPj4gPg0KPj4gPkhpLA0KPj4gPg0KPj4gPkknbSBhbHNv
IGp1bXBpbmcgaW50byB0aGUgZGlzY3Vzc2lvbiBhIGJpdCBsYXRlLg0KPj4gPg0KPj4gPldpdGhv
dXQgZ29pbmcgaW50byBhbGwgdGhlIGRldGFpbGVkIGRpc2N1c3Npb25zIHRoYXQgaGF2ZSB0YWtl
biBwbGFjZQ0KPj4gPnJlY2VudGx5LCBJIGp1c3Qgd2FudCB0byBzaGFyZSBteSB2aWV3IG9uIHRo
ZSBNSVAtYmFzZWQgdnMgcm91dGluZy1iYXNlZA0KPmFwcHJvYWNoLg0KPj4gPg0KPj4gPklNSE8s
IHdlIHByb2JhYmx5IG5lZWQgdG8gZnVydGhlciBsb29rIGF0IGJvdGggYXBwcm9hY2hlcyBpbiB0
aGlzDQo+PiA+Z3JvdXAsIGJ1dCB3aXRoIGVub3VnaCBlbmVyZ3kgbGV2ZWwgKG90aGVyd2lzZSB3
ZSByaXNrIHRvIGVuZCB1cCB3aXRoDQo+PiA+bm90aGluZyBhZnRlciBzZXZlcmFsIHllYXJzKS4g
SSBwZXJzb25hbGx5IGhhdmUgbXkgZG91YnRzIHRoYXQgYQ0KPj4gPmRpc3RyaWJ1dGVkIHJvdXRp
bmctYmFzZWQgYXBwcm9hY2ggc2NhbGVzIGluIGEgbW9kZXJhdGVseSBsYXJnZQ0KPj4gPmRvbWFp
biAod2UgYWxzbyBzYXcgbWFueSB5ZWFycyBhZ28gcHJvcG9zYWxzIG9mIGRvaW5nIG1vYmlsaXR5
IHdpdGgNCj4+ID5yb3V0aW5nIHRoYXQgZGlkIG5vdCB0YWtlIG9mZiBiZWNhdXNlIG9mIGNvbnZl
cmdlbmNlLCBzY2FsYWJpbGl0eSBhbmQNCj5hZG1pbmlzdHJhdGl2ZSBpc3N1ZXMpLg0KPj4gPkkg
dGhpbmsgYSBNSVAtYmFzZWQgYXBwcm9hY2ggKG5ldHdvcmsgb3IgaG9zdCBiYXNlZCkgd291bGQg
d29yaywNCj4+ID50aG91Z2ggaXQgd291bGQgaW1wbHkga2VlcGluZyBtdWx0aXBsZSBhbmNob3Jz
IGFjdGl2ZSBmb3IgYSBnaXZlbiBNTi4NCj4+ID4NCj4+ID5XZSBiZWxpZXZlIHRoaXMgcm91dGlu
Zy1iYXNlZCB2cyBNSVAtYmFzZWQgY29tcGFyaXNvbiBpcyBxdWl0ZQ0KPj4gPmludGVyZXN0aW5n
LCBhbmQgd2UgYXJlIGFjdHVhbGx5IHdvcmtpbmcgYXQgVUMzTSBvbiBleHBlcmltZW50YWxseQ0K
Pj4gPmV2YWx1YXRpbmcgYm90aCwgc28gd2UgY2FuIG1ha2UgYSBtb3JlIGVkdWNhdGVkIHN0YXRl
bWVudCBvbiBwcm9zIGFuZA0KPmNvbnMgb2YgZWFjaCBvZiB0aGVtLg0KPj4gPg0KPj4gPk15IHR3
byBjZW50cywNCj4+ID4NCj4+ID5DYXJsb3MNCj4+ID4NCj4+ID5PbiBXZWQsIDIwMTMtMTEtMTMg
YXQgMTA6MTAgKzAwMDAsIE1hcmNvIExpZWJzY2ggd3JvdGU6DQo+PiA+PiBIaSBTcmksIGFsbCwN
Cj4+ID4+IGxldCBtZSBzdGVwIGluIGhlcmUgKHdpdGggc29tZSBkZWxheS4uKSB0byBjbGFyaWZ5
IG9uZSBwb2ludCB5b3UgcmFpc2VkLg0KPj4gPj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+PiA+Pg0K
Pj4gPj4gPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+RnJvbTogZG1tLWJvdW5j
ZXNAaWV0Zi5vcmcgW21haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+PiA+
PiA+T2YgU3JpIEd1bmRhdmVsbGkgKHNndW5kYXZlKQ0KPj4gPj4gPlNlbnQ6IE1vbnRhZywgMTEu
IE5vdmVtYmVyIDIwMTMgMTY6MzANCj4+ID4+ID5UbzogUGV0ZXIgTWNDYW5uDQo+PiA+PiA+Q2M6
IGRtbUBpZXRmLm9yZw0KPj4gPj4gPlN1YmplY3Q6IFJlOiBbRE1NXSBQcmVwYXJpbmcgZm9yIERN
TSBmdXR1cmUgc3RlcHMgYW5kIHJlY2hhcnRlcmluZw0KPj4gPj4gPg0KPj4gPj4gPkhpIFBldGUs
DQo+PiA+PiA+DQo+PiA+PiA+SSdtIG5vdCBzdXJlLCBJIGFncmVlIHdpdGggdGhpcywgb3IgdW5k
ZXJzdGFuZCB0aGlzIHRvIGJlIHByZWNpc2UuDQo+PiA+PiA+SSBkbyBub3Qga25vdyBrbm93IENQ
IChpbiB0aGUgZm9ybSBvZiBQTUlQLCBHVFAgb3Igc29tZSBvdGhlcg0KPj4gPj4gPnByb3RvY29s
DQo+PiA+PiA+WFlaKSBjYW4gYmUgY29tcGxldGVseSBlbGltaW5hdGVkLiBUaGVyZSBuZWVkcyB0
byBiZSBzb21lDQo+PiA+PiA+aW50ZXJmYWNlIGJldHdlZW4gdGhlIGFjY2VzcyBnYXRld2F5IGFu
ZCB0aGUgbW9iaWxpdHkgYW5jaG9yLiBJDQo+PiA+PiA+YXNzdW1lZCB5b3VyJ3MsIE1hcmNvJ3Mg
YW5kIFJ5dWppJ3MgZ29hbCBpcyBmb3IgZWxpbWluYXRpbmcgdGhlDQo+PiA+PiA+dHVubmVsLCB3
aGljaCBJIGRvbid0IGJlbGlldmUgaXQgY2FuIGJlIGFjaGlldmVkLCBidXQgc3RpbGwgdGhvdWdo
dCB3ZSBjYW4NCj5kaXNjdXNzIHRoaXMuDQo+PiA+Pg0KPj4gPj4gTXkgaW50ZW50aW9uIGlzIG5v
dCB0byBlbGltaW5hdGUgYSB0dW5uZWwgdGhhdCBleGlzdHMgaW4gYW55IG9mIHRoZQ0KPj4gPj4g
dHVubmVsIG1hbmFnZW1lbnQgcHJvdG9jb2xzIChha2EgTUlQNiwgUE1JUDYsIC4uKS4gTXkgcGlj
dHVyZSBvZg0KPj4gPj4gRE1NIHByaW1hcmlseSBkaXN0cmlidXRlcyB0b3BvbG9naWNhbCBhbmNo
b3IgcG9pbnQgZm9yIHRoZSBNTidzIElQDQo+YWRkcmVzcyhlcykuDQo+PiA+Rm9yZ2V0IGFib3V0
IHRoZSBDLXBsYW5lIGZvciBub3cuDQo+PiA+PiBUdW5uZWxzIGFwcGx5IHNvbGVseSBiZWxvdyAo
d2VsbCwgdG93YXJkcyBhY2Nlc3MpIHN1Y2ggYW5jaG9yLg0KPj4gPj4gSWYgd2UgZGlzdHJpYnV0
ZSB0aGVtIHRvIGFuIGV4dHJlbWUsIHRoZXkgYXJlIHBsYWNlZCBvbiByYWRpbw0KPj4gPj4gYWNj
ZXNzIHBvaW50cyBhbmQgdGhlIHR1bm5lbCBkaXNhcHBlYXJzLiBUaGVuIHdlIGFycml2ZSBhdCBQ
ZXRlJ3MNCj4+ID4+IG1vZGVsLiBJZiBhbmNob3IgcG9pbnRzIGFyZSBzb21ld2hlcmUgYWJvdmUs
IHNheSBpbiB0aGUgYmFja2hhdWwsDQo+PiA+PiB0aGUgdHVubmVsIHJlbWFpbnMgYXQgbGVhc3Qg
YmV0d2VlbiB0aGUgYW5jaG9yIGFuZCBzb21lIG5vZGUgaW4gdGhlDQo+PiA+PiBhY2Nlc3MgKG5l
dHdvcmsNCj4+ID5iYXNlZCBtb2JpbGl0eSBtZ21udCkgb3IgdGhlIE1OIChob3N0IGJhc2VkIG1v
YmlsaXR5IG1nbW50KS4NCj4+ID4+DQo+PiA+PiBJIHRoaW5rIG5vbmUgb2YgdGhlIHByb3Bvc2Fs
cyB3YW50cyB0byBkaXNjdXNzIGF3YXkgdGhlIHR1bm5lbHMgYXMNCj4+ID4+IHBlciBNSVAvUE1J
UC4gQnV0IGFib3ZlIGFuY2hvciBsZXZlbCwgcmVndWxhciByb3V0aW5nIGFwcGxpZXMgdG8NCj4+
ID4+IHBsYWluIGRhdGENCj4+ID5wYWNrZXRzIG9mIHRoZSBVLVBsYW5lLg0KPj4gPj4gQSBrZXkg
Y29tcG9uZW50IGZvciBETU0sIElNTywgaXMgaG93IHRvIGFjY29tcGxpc2ggdGhhdCByb3V0aW5n
DQo+PiA+PiB0b3dhcmRzIHRoZSBNTidzIGN1cnJlbnQgYW5jaG9yIHBvaW50LCBldmVuIGlmIHRo
ZSBhbmNob3JlZCBJUA0KPj4gPj4gYWRkcmVzcyBpcw0KPj4gPnRvcG9sb2dpY2FsbHkgaW5jb3Jy
ZWN0Lg0KPj4gPj4gVG8gYWNjb21wbGlzaCB0aGlzLCBteSBpbnRlbnQgaXMgdG8gbm90IGludHJv
ZHVjZSB0dW5uZWxzIGFib3ZlIGFuY2hvciBsZXZlbC4NCj4+ID4+IFNvLCBpdCdzIG5vdCBhYm91
dCBlbGltaW5hdGluZyB0dW5uZWxzLCBidXQgaXQgaXMgYWJvdXQgbm90DQo+PiA+PiBpbnRyb2R1
Y2luZyB0dW5uZWxzIHdoZXJlIG5ldmVyIGhhdmUgYmVlbiB0dW5uZWxzIGJlZm9yZSA6LSkNCj4+
ID4+DQo+PiA+PiBtYXJjbw0KPj4gPj4NCj4+ID4+ID4gSU1PLCBpdHMgbm90IGp1c3QgYWJvdXQg
aW5zZXJ0aW5nIGEgUklCIHJvdXRlIGFuZCByZWRpc3RyaWJ1dGluZw0KPj4gPj4gPml0LCBidXQg
ZXZlbiB0aGVyZSBpbiBEUCB0aGVyZSBpcyBhIHN0YXRlIHRyYW5zZmVyIG5lZWRlZCAgZnJvbQ0K
Pj4gPj4gPnRoZSBDUCBhbmQgdGhlIERQLiBTdGFydGluZyBwb2ludCBhcHBlYXJzIGxpa2UgYSBz
aW1wbGUgcm91dGUNCj4+ID4+ID5wcm9wYWdhdGlvbiwgdmVyeSBzb29uIGl0IHdpbGwgZW5kIHVw
IHdpdGggYSBidW5jaCBvZiBzdGF0ZSB0aGF0DQo+PiA+PiA+Z2V0cyBtb3ZlZCBiZXR3ZWVuIHRo
ZSB0d28gbm9kZXMuICBCdXQsIG1heSBiZSBJIGRvbid0IHVuZGVyc3RhbmQNCj4+ID4+ID50aGUg
aWRlYXMgY2xlYXJseSBvbiBlbGltaW5hdGluZyBDUCBhbmQgZWxpbWluYXRpbmcgdHVubmVscy4N
Cj4+ID4+ID5JJ20gbm90IGdvaW5nIHRvIG9wcG9zZSB0aGlzLCBJIGRvbid0IHNlZSB0aGlzIGNv
bnZlcmdpbmcsIElNSE8uDQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+
PiA+UmVnYXJkcw0KPj4gPj4gPlNyaQ0KPj4gPj4gPg0KPj4gPj4gPg0KPj4gPj4gPg0KPj4gPj4g
Pk9uIDExLzEwLzEzIDM6MTMgUE0sICJQZXRlciBNY0Nhbm4iIDxQZXRlci5NY0Nhbm5AaHVhd2Vp
LmNvbT4NCj53cm90ZToNCj4+ID4+ID4NCj4+ID4+ID4+SGksIFNyaSwNCj4+ID4+ID4+DQo+PiA+
PiA+PkkgdGhpbmsgeW91IHdpbGwgYWdyZWUgdGhhdCBQTUlQIGlzIGEgY29udHJvbCBwcm90b2Nv
bCBmb3INCj4+ID4+ID4+c2V0dGluZyB1cCB0dW5uZWxzLiAgQSB0dW5uZWwgaW1wbGllcyB0aGF0
IHdlIGFyZSBub3QgdXNpbmcgdGhlDQo+PiA+PiA+PmRlc3RpbmF0aW9uIElQIG9mIHRoZSBpbm5l
ciBwYWNrZXQgZm9yIHJvdXRpbmcgYW5kIGJ5IGRlZmluaXRpb24NCj4+ID4+ID4+d2lsbCBsZWFk
IHRvIGEgbm9uLW9wdGltYWwgcm91dGUgYW5kIGEgYml0IG9mIHN0YXRlIG9uIHNvbWUgYm94DQo+
PiA+PiA+PnRoYXQgY2FuIGZhaWwgYW5kIGxvc2UgdGhhdCBzdGF0ZS4NCj4+ID4+ID4+DQo+PiA+
PiA+PkkgaG9wZSB0aGF0IERNTSBjYW4gY29uc2lkZXIgb3RoZXIgYXBwcm9hY2hlcyBzdWNoIGFz
IGluamVjdGluZw0KPj4gPj4gPj5yb3V0ZXMgZnJvbSB0aGUgbGF0ZXN0IEwyLWF0dGFjaG1lbnQg
cG9pbnQgaW50byB0aGUgYWNjZXNzDQo+PiA+PiA+Pm5ldHdvcmssIHdoaWNoIGlzIGEgdHJ1bHkg
RGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudA0KPj4gPj4gPj5wcm90b2NvbCBmb3IgZ2V0
dGluZyB0aGUgcGFja2V0cyB0byB0aGUgbW9iaWxlIG5vZGUuICBJdCB3aWxsDQo+PiA+PiA+Pmxl
YWQgdG8gbW9yZSBvcHRpbWFsIHJvdXRlcyBhbmQgbW9yZSByb2J1c3QgZmF1bHQtdG9sZXJhbnQg
b3BlcmF0aW9uIG9mDQo+dGhlIG5ldHdvcmsuDQo+PiA+PiA+Pg0KPj4gPj4gPj5JIHRoaW5rIHdl
IGNhbiBjb250aW51ZSB0byB1c2UgdGhlIHRlcm0gTUFHIHRvIGFwcGx5IHRvIHRoYXQNCj4+ID4+
ID4+Zmlyc3QtaG9wIHJvdXRlciB3aGljaCBpcyBob3BlZnVsbHkgY28tbG9jYXRlZCB3aXRoIHRo
ZSBMMg0KPj4gPj4gPj50ZXJtaW5hdGlvbiBwb2ludCAoaXQgbWF5IG5vdCBiZSBzbyBpbiBldmVy
eSB0ZWNobm9sb2d5IGRlcGVuZGluZw0KPj4gPj4gPj5vbiB0aGUgZXh0ZW50IHRvIHdoaWNoIHRo
YXQgdGVjaG5vbG9neSBoYXMgZXZvbHZlZCB0byBzdXBwb3J0DQo+PiA+PiA+PnRydWx5IERpc3Ry
aWJ1dGVkDQo+PiA+b3BlcmF0aW9uKS4NCj4+ID4+ID4+QW55dGhpbmcgdGhhdCBoYXBwZW5zIGJl
bG93IHRoZSBNQUcgKGJldHdlZW4gdGhlIE1BRyBhbmQgdGhlIEwyDQo+PiA+PiA+PnRlcm1pbmF0
aW9uIHBvaW50KSBzaG91bGQgYmUgb3V0IG9mIHNjb3BlIGFuZCB3ZSBzaG91bGQgbm90DQo+PiA+
PiA+PmRlZmluZSBhbnkgcHJvdG9jb2wgdGhlcmUgYW5kIHdlIHNob3VsZCBkaXNjb3VyYWdlIGFu
eSBzZXBhcmF0aW9uDQo+PiA+PiA+PmJldHdlZW4gdGhlDQo+PiA+dHdvLg0KPj4gPj4gPj4NCj4+
ID4+ID4+SG93ZXZlciwgd2Ugc2hvdWxkIG5vdCByZXF1aXJlIHRoZSBNQUcgdG8gcnVuIGFueSBm
b3JtIG9mIFBNSVANCj4+ID4+ID4+YmVjYXVzZSB0dW5uZWxzIHNob3VsZCBub3QgYmUgcmVxdWly
ZWQgaW4gdGhlIGFyY2hpdGVjdHVyZS4gIFdlDQo+PiA+PiA+PnNob3VsZCBub3QgcmVxdWlyZSBh
biBMTUEsIGJlY2F1c2UgdGhpcyB3b3VsZCBpbXBseSBhIGNlbnRyYWwNCj4+ID4+ID4+cG9pbnQg
b2Ygc3RhdGUgbWFpbnRlbmFuY2UgYW5kIHBvc3NpYmlsaXR5IG9mIGZhaWx1cmUuDQo+PiA+PiA+
Pg0KPj4gPj4gPj5JdCBpcyBmaW5lIHRvIGNvbnNpZGVyIGEgc3BsaXQgYmV0d2VlbiBDUCBhbmQg
RFAgYnV0IEkgdGhvdWdodCB3ZQ0KPj4gPj4gPj5oYWQgYWdyZWVkIHRoYXQgYW55IGRpc2N1c3Np
b24gb2YgdGhlIHByb3RvY29sIHRvIHVzZSBvbiBzdWNoIGFuDQo+PiA+PiA+PmludGVyZmFjZSB3
b3VsZCBiZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgV0cuICBJTUhPIHdlIHNob3VsZA0KPj4gPj4g
Pj5sZWF2ZSB0aGF0IHRvIHRoZSBXaXJlbGVzcyAmIE1vYmlsZSBXb3JraW5nIEdyb3VwIG9mIE9O
Ri4NCj4+ID4+ID4+DQo+PiA+PiA+Pk5vdywgdGhlIHByb3BvbmVudHMgb2YgT3BlbkZsb3cgYW5k
IG90aGVyIENQL0RQIHNwbGl0cyBoYXZlDQo+PiA+PiA+PmFyZ3VlZCB0aGF0IGl0IGlzIGJldHRl
ciB0byBjZW50cmFsaXplIHRoZSBhbGdvcml0aG1zIHN1Y2ggYXMNCj4+ID4+ID4+cm91dGluZyBw
cm90b2NvbHMgb24gYSBsb2dpY2FsbHkgY2VudHJhbGl6ZWQgc2VydmVyIG9yIHNlcnZlcnMNCj4+
ID4+ID4+d2l0aCBhIHN5bmNocm9uaXplZCBnbG9iYWwgdmlldyBvZiB0aGUgbmV0d29yay4NCj4+
ID4+ID4+SSBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGF0LCBpbiB3aGljaCBjYXNlIHRoaXMgY2Vu
dHJhbGl6ZWQNCj4+ID4+ID4+Y29udHJvbGxlciBqdXN0IG5lZWRzIHRvIGdldCBub3RpZmllZCBh
Ym91dCB0aGUgTU4ncyBjdXJyZW50DQo+PiA+PiA+PmF0dGFjaG1lbnQgcG9pbnQsIHNvIGl0IGNh
biBpbnN0YWxsIHRoZSByb3V0ZXMgKG9yIHR1bm5lbHMsIGlmIGFuDQo+PiA+PiA+Pm9wZXJhdG9y
IHdpc2hlcyB0byB1c2UNCj4+ID4+ID4+dGhlbSkgaW50byB0aGUgRFAuDQo+PiA+PiA+PkJ1dCwN
Cj4+ID4+ID4+dGhlIG1lY2hhbmlzbXMgZm9yIGRvaW5nIHNvIGFyZSBvdXQgb2Ygc2NvcGUgZm9y
IHRoZSBETU0gV0cNCj4+ID4+ID4+YmVjYXVzZSB3ZSBhcmUgbm90IHdvcmtpbmcgb24gYSBDUC9E
UCBzcGxpdC4gIEkgdGhpbmsgaXQgd291bGQgYmUNCj4+ID4+ID4+YXBwcm9wcmlhdGUgZm9yIHRo
ZSBETU0gV0cgKHdoaWNoIGV4aXN0cyBpbiB0aGUgSUVURiwgYSBzdGFuZGFyZHMNCj4+ID4+ID4+
Ym9keSB0aGF0IGhhcyBhIGxvbmcgaGlzdG9yeSBvZiBkZXZlbG9waW5nIGRpc3RyaWJ1dGVkIGFu
ZA0KPj4gPj4gPj5mYXVsdC10b2xlcmFudCByb3V0aW5nIHByb3RvY29scykgdG8gZGVzY3JpYmUg
YSBtb3JlIGRpc3RyaWJ1dGVkDQo+PiA+PiA+PmFsdGVybmF0aXZlLCBidWlsZGluZyBvbiBmb3Vu
ZGF0aW9uYWwgSW50ZXJuZXQgdGVjaG5vbG9naWVzIHN1Y2gNCj4+ID4+ID4+YXMgSS1CR1AsIGlu
IHN1Y2ggYSB3YXkgdGhhdCB3aWxsIGJyaW5nIGRvd24gdGhlIGNvc3RzLCByZWR1Y2UNCj4+ID4+
ID4+dGhlIGxhdGVuY3ksIGFuZCBpbmNyZWFzZSB0aGUgcm9idXN0bmVzcyBvZiB3aXJlbGVzcyBh
Y2Nlc3MgbmV0d29ya3MuDQo+PiA+PiA+Pg0KPj4gPj4gPj5JIGFjdHVhbGx5IGRvbid0IHRoaW5r
IHdlIG5lZWQgdG8gZGVmaW5lIGFueSBuZXcgZXh0ZW5zaW9ucyBvcg0KPj4gPj4gPj5JRXMgZm9y
IEJHUDsgSSB3b3VsZCBsaWtlIHRvIHJlYWQgbW9yZSBhYm91dCBSeXVqaSdzIHByb3Bvc2VkIGV4
dGVuc2lvbnMNCj5oZXJlLg0KPj4gPj4gPj5BbGwgd2UgbmVlZCBpcyBmb3IgdGhlIE1BRyB0byBs
ZWFybiB3aGF0IElQcyBoYXZlIGJlZW4gYXNzaWduZWQNCj4+ID4+ID4+dG8gdGhlIE1OLCBkZWNp
ZGUgd2hpY2ggb2YgdGhvc2UgSVBzIGFyZSBpbiB0aGUgc2NvcGUgb2YgdGhlDQo+PiA+PiA+Pmxv
Y2FsIEFTLCBhbmQgaW5qZWN0IHJvdXRlcyBmb3IgdGhvc2UgcHJlZml4ZXMgdG8gaXRzZWxmLiAg
V2UNCj4+ID4+ID4+Y291bGQgd29yayBvbiBhbHRlcm5hdGl2ZSBtZWNoYW5pc21zIGZvciBkaXNj
b3ZlcmluZyB0aGlzIGxpc3Qgb2YNCj4+ID4+ID4+YWRkcmVzc2VzIC0gdGhlIGZ1bmRhbWVudGFs
IHJlcXVpcmVtZW50IGlzIHRoYXQgd2UgdXNlIGFuDQo+PiA+PiA+PmF1dGhlbnRpY2F0ZWQgTU4g
SUQgKHByb2JhYmx5IGFuIE5BSSkgYXMgYW4gaW5kZXggdG8gbG9va3VwIHRoZQ0KPj4gPj4gPj5z
ZXQgb2YgSVBzIGluIGEgZGlzdHJpYnV0ZWQNCj4+ID5kYXRhYmFzZS4NCj4+ID4+ID4+SSd2ZSBw
cm9wb3NlZCB1c2luZyBETlMgZm9yIHRoaXMgYnV0IHRoZXJlIGFyZSBvdGhlciBhbHRlcm5hdGl2
ZXMuDQo+PiA+PiA+PldlIGFsc28gbmVlZCBhIHdheSB0byBtYWtlIHN1cmUgdGhlIGxhdGVzdCBV
UERBVEUgZ2V0cyB1c2VkIGJ5DQo+PiA+PiA+PmFsbCB0aGUgQkdQIHBlZXJzLg0KPj4gPj4gPj5J
J3ZlIHByb3Bvc2VkDQo+PiA+PiA+PnB1dHRpbmcgYSB0aW1lc3RhbXAgaW4gTE9DQUxfUFJFRiBi
dXQgdGhlcmUgYXJlIHByb2JhYmx5IG90aGVyDQo+PiA+PiA+PmFsdGVybmF0aXZlcy4NCj4+ID4+
ID4+DQo+PiA+PiA+Pkl0IHdvdWxkIGFsc28gYmUgbmljZSB0byBoYXZlIGEgd2VsbC1kZWZpbmVk
IGZhbGwtYmFjayBtZWNoYW5pc20NCj4+ID4+ID4+aW4gY2FzZSB0aGUgTU4gbW92ZXMgdG8gYSBk
aWZmZXJlbnQgQVMgb3IganVzdCB0b28gZmFyIGZyb20gdGhlDQo+PiA+PiA+Pm9yaWdpbmFsIE1B
RywgaW4gd2hpY2ggY2FzZSB0aGUgSS1CR1AgYXBwcm9hY2ggd291bGRuJ3Qgc2NhbGUuDQo+PiA+
PiA+PkZvciB0aGVzZSBjYXNlcywgSSB0aGluayBhIGNsaWVudCBNSVAgdHVubmVsIHRvIGFuIEhB
IGxvY2F0ZWQgaW4NCj4+ID4+ID4+dGhlIG9yaWdpbmFsIEFTIGZvciBlYWNoIGFzc2lnbmVkIElQ
IGFkZHJlc3Mgd291bGQgYmUgaWRlYWwuDQo+PiA+PiA+PlRoZSBIQSBjYW4gYmVoYXZlIGp1c3Qg
bGlrZSB0aGUgTUFHcyBpbiB0aGF0IGRvbWFpbiwgaW5qZWN0aW5nDQo+PiA+PiA+PnJvdXRlcyB3
aGVuIE1OcyBlc3RhYmxpc2ggdHVubmVscyB0byBpdCBzbyBhcyB0byBhdHRyYWN0IHRoZQ0KPj4g
Pj4gPj5wYWNrZXRzIHRvIHRoZW1zZWx2ZXMgKHRoaXMgd291bGQgYmUgdGhlIHJvdXRpbmcgZXF1
aXZhbGVudCBvZg0KPj4gPj4gPj50aGUgcHJveHktQVJQIG9yIHByb3h5LU5EIG1lY2hhbmlzbSB0
aGF0IHdvcmtzIG9uIGp1c3QgYSBzaW5nbGUNCj4+ID4+ID4+aG9tZSBsaW5rIGluIE1JUHY0IG9y
IE1JUHY2KS4gIFdlIHNob3VsZCB3b3JrIG9uIG1lY2hhbmlzbXMgdG8NCj4+ID4+ID4+ZW5hYmxl
IGR5bmFtaWMgYXNzaWdubWVudCBvZiBsb2NhbCBIQXMgdG8gTU5zIGFuZCBkeW5hbWljDQo+PiA+
PiA+PmVzdGFibGlzaG1lbnQgb2Ygc2VjdXJpdHkgYXNzb2NpYXRpb25zIHRoYXQgZG9uJ3QgcmVx
dWlyZSBBQUEgYW5kDQo+PiA+PiA+PmFzc29jaWF0ZWQgcm91bmQtdHJpcHMgdG8gdGhlIGhvbWUN
Cj4+ID5uZXR3b3JrLg0KPj4gPj4gPj5CZWNhdXNlIHRoZSBIQQ0KPj4gPj4gPj5pcyBhc3NvY2lh
dGVkIHdpdGggdGhlIG9yaWdpbmFsIE1BRyB0aGF0IGFzc2lnbmVkIHRoZSBhZGRyZXNzLA0KPj4g
Pj4gPj50aGlzIG1heSBpbnZvbHZlIHNvbWUgREhDUCBleHRlbnNpb25zLiAgVGhlcmUgaXMgYWxy
ZWFkeSBhIHdheSB0bw0KPj4gPj4gPj5hc3NpZ24gdGhlIEhBIElQIGFkZHJlc3MgYnV0IHdlIHdp
bGwgbmVlZCBuZXcgZXh0ZW5zaW9ucyB0byBjYXJyeQ0KPj4gPj4gPj50aGUgSEEgY3JlZGVudGlh
bHMgdG8gdGhlIE1OIChtYXliZSBqdXN0IGFuIEhBIEROUyBuYW1lIHNvIHRoZSBNTg0KPj4gPj4g
Pj5jYW4gdXNlIERBTkUgdG8gcmV0cmlldmUgYSBwdWJsaWMga2V5KS4NCj4+ID4+ID4+DQo+PiA+
PiA+PkkgdGhpbmsgc29tZXRoaW5nIGxpa2UgdGhlIHBhdGggSSd2ZSBvdXRsaW5lZCBhYm92ZSB3
b3VsZCBtYWtlIGENCj4+ID4+ID4+Z29vZCB3b3JrIHBsYW4gZm9yIHRoZSBmdXR1cmUgb2YgRE1N
Lg0KPj4gPj4gPj4NCj4+ID4+ID4+LVBldGUNCj4+ID4+ID4+DQo+PiA+PiA+DQo+PiA+PiA+X19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID5kbW0g
bWFpbGluZyBsaXN0DQo+PiA+PiA+ZG1tQGlldGYub3JnDQo+PiA+PiA+aHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiBkbW0gbWFpbGluZyBsaXN0DQo+PiA+PiBk
bW1AaWV0Zi5vcmcNCj4+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZG1tDQo+PiA+DQo+Pg0KPg0KDQo=

From brian@innovationslab.net  Wed Nov 13 07:26:33 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70921E80AE for ; Wed, 13 Nov 2013 07:26:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNSAWukC9hoa for ; Wed, 13 Nov 2013 07:26:26 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 96A1411E8110 for ; Wed, 13 Nov 2013 07:26:26 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6FDAB880F3 for ; Wed, 13 Nov 2013 07:26:25 -0800 (PST)
Received: from 10252612.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2D3B213680B7 for ; Wed, 13 Nov 2013 07:26:25 -0800 (PST)
Message-ID: <52839A22.5090301@innovationslab.net>
Date: Wed, 13 Nov 2013 10:26:26 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: dmm@ietf.org
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>	 <5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5Se2DSFHnSwpmSs5xxE7mUNXAWMP5LVcW"
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 15:26:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--5Se2DSFHnSwpmSs5xxE7mUNXAWMP5LVcW
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Pete,
     Speaking with no hat on...

On 11/12/13 4:29 PM, Peter McCann wrote:
> Hi, Sri,
>=20
> Even if we agree that those services are necessary (and I would point o=
ut
> once again that most of them are not beneficial to the end-user) I don'=
t
> think we should be architecting the network in such a way that we lose =
the
> basic benefits of IP (shortest path routing and fault-tolerance).  We c=
an
> implement those services without taking all the packets to a central lo=
cation;
> maybe just the first packet or meta-information about the first packet =
can
> be taken to an SDN controller that can make some decision and pass it d=
own
> to the user plane.
>=20
> I really don't think this is such fantastic science-fiction. ;)

The degree to which this is science fiction really depends on what scope
you think these host routes will have in the routing system.

* Are you assuming mobility within a single enterprise or Autonomous Syst=
em?

* Limited mobility within a consortium of networks?

* Is this global mobility for any/all nodes?

Regards,
Brian


--5Se2DSFHnSwpmSs5xxE7mUNXAWMP5LVcW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSg5oiAAoJEBOZRqCi7goqCLMH/0iv0yw+av7eZ7KwJ3mrEgpz
x4OBzOuUqUVz8p7Bes0wzfqEnULhDBHydm75P8SyS0wn2rK6xVP8oNoeKfrx0qRf
Amm9aDj0ttZImMdpZOcNA0evZA2pwb7deySeb9k/bVV/9Nm+d/HF2Th7tZ6DehAG
4YayDCHAoRFF+wZ2Ju8ZQszEbbCw5hs8gCahUNe00Jxx2VN3dvyHIMbmHfIJlT3d
MHsx6OPnj7DpjuAt8Zn1sIVVN3SV/+7RkkmlJz8rZwWr5AWqTLfz8XzNfq+kZlFK
7Uh7030urfDD3XLt9ecph+eEtaw4hrIcSv1Dj995PUf4efI8fl1I2FppjAEcnQU=
=bfEo
-----END PGP SIGNATURE-----

--5Se2DSFHnSwpmSs5xxE7mUNXAWMP5LVcW--

From Peter.McCann@huawei.com  Wed Nov 13 07:40:23 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC5121E812E for ; Wed, 13 Nov 2013 07:40:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHY-tr0HeZTi for ; Wed, 13 Nov 2013 07:40:18 -0800 (PST)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1928D21E80C7 for ; Wed, 13 Nov 2013 07:40:18 -0800 (PST)
Received: from 172.18.9.243 (EHLO lhreml204-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AOM44119; Wed, 13 Nov 2013 09:40:17 -0600 (CST)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 15:38:54 +0000
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 15:39:52 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 07:39:46 -0800
From: Peter McCann 
To: Brian Haberman , "dmm@ietf.org" 
Thread-Topic: [DMM] Preparing for DMM future steps and rechartering
Thread-Index: Ac7Y3bqUR0J96RB8SmOZDtKQ9LtNUQADREFAABnu6gAAIMb+gAAAJPSAAAu8+IAAAIZpgAAFP1cAAFBGo4AAAmslAAA5YikAAA/fl8AAFGnLAAAQoWLQAFZl+QAAAMtAAAAAT0YAAA0Dp4D//7zUAIAAWAQggADyaICAACee0IAAzysA//+HtVCAAqUyAIAAhEeQ
Date: Wed, 13 Nov 2013 15:39:46 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com> <52839A22.5090301@innovationslab.net>
In-Reply-To: <52839A22.5090301@innovationslab.net>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.125.91]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 15:40:23 -0000

Hi, Brian,

Brian Haberman wrote:
> Hi Pete,
>      Speaking with no hat on...
> On 11/12/13 4:29 PM, Peter McCann wrote:
>> Hi, Sri,
>>=20
>> Even if we agree that those services are necessary (and I would point=20
>> out once again that most of them are not beneficial to the end-user)=20
>> I don't think we should be architecting the network in such a way=20
>> that we lose the basic benefits of IP (shortest path routing and=20
>> fault-tolerance).  We can implement those services without taking all=20
>> the packets to a central location; maybe just the first packet or=20
>> meta-information about the first packet can be taken to an SDN=20
>> controller that can make some decision and pass it down to the user=20
>> plane.
>>=20
>> I really don't think this is such fantastic science-fiction. ;)
>=20
> The degree to which this is science fiction really depends on what=20
> scope you think these host routes will have in the routing system.
>=20
> * Are you assuming mobility within a single enterprise or Autonomous=20
> System?

Yes, at the most this will be one AS.

> * Limited mobility within a consortium of networks?

No.  At the most this will be one AS, possibly less depending on scalabilit=
y.

> * Is this global mobility for any/all nodes?

No.  I think global mobility should be handled with client MIP because we
should not assume any relationship between previous/next visited networks.

The Boeing experiment (not science fiction, but also not scalable) tried
global mobility with BGP:

Dul, A., "Global IP Network Mobility using Border Gateway Protocol (BGP)," =
Available at: http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pd=
f

This obviously wouldn't work for billions of MNs.  But, with DMM people
are starting to realize that MNs don't need completely stable global addres=
ses
that live forever.  So I think DMM should focus on localized mobility manag=
ement.

> Regards,
> Brian

-Pete



From alexandru.petrescu@gmail.com  Wed Nov 13 08:03:03 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AA411E815F for ; Wed, 13 Nov 2013 08:03:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.247
X-Spam-Level: 
X-Spam-Status: No, score=-10.247 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFydZHmTru8g for ; Wed, 13 Nov 2013 08:02:58 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id D801811E8110 for ; Wed, 13 Nov 2013 08:02:57 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rADG2d7B025509; Wed, 13 Nov 2013 17:02:39 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A397C2061B4; Wed, 13 Nov 2013 17:02:52 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 962402060E7; Wed, 13 Nov 2013 17:02:52 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rADG2Xe3029470; Wed, 13 Nov 2013 17:02:39 +0100
Message-ID: <5283A299.9030003@gmail.com>
Date: Wed, 13 Nov 2013 17:02:33 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Peter McCann , Brian Haberman , "dmm@ietf.org" 
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>		<5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com>	<52839A22.5090301@innovationslab.net> <5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 16:03:03 -0000

Le 13/11/2013 16:39, Peter McCann a écrit :
> Hi, Brian,
>
> Brian Haberman wrote:
>> Hi Pete, Speaking with no hat on... On 11/12/13 4:29 PM, Peter
>> McCann wrote:
>>> Hi, Sri,
>>>
>>> Even if we agree that those services are necessary (and I would
>>> point out once again that most of them are not beneficial to the
>>>  end-user) I don't think we should be architecting the network in
>>>  such a way that we lose the basic benefits of IP (shortest path
>>>  routing and fault-tolerance).  We can implement those services
>>> without taking all the packets to a central location; maybe just
>>>  the first packet or meta-information about the first packet can
>>>  be taken to an SDN controller that can make some decision and
>>> pass it down to the user plane.
>>>
>>> I really don't think this is such fantastic science-fiction. ;)
>>
>> The degree to which this is science fiction really depends on what
>> scope you think these host routes will have in the routing system.
>>
>> * Are you assuming mobility within a single enterprise or
>> Autonomous System?
>
> Yes, at the most this will be one AS.

I agree.

In search of a qualifying metric the number of ASes is very good.

If need to go in further detail (sci-fi?) one may also consider metrics
such as the level of aggregation of prefixes in the addressing
architecture, and the IP distance between two Access Routers (not the
geographical distance).

I assume with fully hierarchical addressing, and small IP distance
between ARs may lead to acceptance of route updates on that scale.

(in the Connexion by Boeing test case the IP distance between ARs is
known to be very low although spanning wide geographical areas - no
route churn).

Alex

>> * Limited mobility within a consortium of networks?
>
> No.  At the most this will be one AS, possibly less depending on
> scalability.
>
>> * Is this global mobility for any/all nodes?
>
> No.  I think global mobility should be handled with client MIP
> because we should not assume any relationship between previous/next
> visited networks.
>
> The Boeing experiment (not science fiction, but also not scalable)
> tried global mobility with BGP:
>
> Dul, A., "Global IP Network Mobility using Border Gateway Protocol
> (BGP)," Available at:
> http://quark.net/docs/Global_IP_Network_Mobility_using_BGP.pdf
>
> This obviously wouldn't work for billions of MNs.  But, with DMM
> people are starting to realize that MNs don't need completely stable
>  global addresses that live forever.  So I think DMM should focus on
>  localized mobility management.
>
>> Regards, Brian
>
> -Pete
>
>
> _______________________________________________ dmm mailing list
> dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
>
>



From sarikaya2012@gmail.com  Wed Nov 13 12:44:05 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6315111E8136 for ; Wed, 13 Nov 2013 12:44:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.338
X-Spam-Level: 
X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.261,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtjnRdA16rJ7 for ; Wed, 13 Nov 2013 12:44:05 -0800 (PST)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 194F611E817E for ; Wed, 13 Nov 2013 12:43:40 -0800 (PST)
Received: by mail-la0-f52.google.com with SMTP id ev20so803744lab.25 for ; Wed, 13 Nov 2013 12:43:40 -0800 (PST)
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:content-type; bh=iUI+ZHELvGffiNy8YNFe0GqP969A0IvAoWkUjQmzDPY=; b=OnobFGVBn1M0CQ9Am91U0VGZjnTPOCnSmlNfriNmez2gLeMyYyW5iJ0jqbQDlSwv87 EsWUvjfO5lYBycqx/UM+rqgDIMsj+4dWloap/85jFr+z6dptalL68KwTYyHA7W3rP31v 0omBv5xv5rRlXAfermxRB7bIXDghsB9jIxQm3z9jofN6qfL33Yi6ePwdXiSnyt3mC3+l kzMyJuSgyI0j/hHk7/14xBizaizv2uhHlMAIrbe7jH9VsuSbm3MEbM+0zsMJXe+9/7Pr 5FmEOojOUu36sht1hXWzrchEigbJ4L9kLoGp0DcSvocQA2GuA8zBRiC/p3Qm8cBPqwYW QPRw==
MIME-Version: 1.0
X-Received: by 10.112.13.202 with SMTP id j10mr13578091lbc.29.1384375419951; Wed, 13 Nov 2013 12:43:39 -0800 (PST)
Received: by 10.114.217.129 with HTTP; Wed, 13 Nov 2013 12:43:39 -0800 (PST)
In-Reply-To: <5283A299.9030003@gmail.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com> <52839A22.5090301@innovationslab.net> <5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com> <5283A299.9030003@gmail.com>
Date: Wed, 13 Nov 2013 14:43:39 -0600
Message-ID: 
From: Behcet Sarikaya 
To: "dmm@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3cd842461d004eb1505c2
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Nov 2013 20:44:05 -0000

--001a11c3cd842461d004eb1505c2
Content-Type: text/plain; charset=ISO-8859-1

As for the next steps, my suggestion is that Jouni posts a draft charter
based on the slide he showed in Vancouver where different pieces of a dmm
solution was listed.

We can have email discussions based on that proposal and hopefully come to
a consensus in a reasonable amount of time.

However, Jouni did not post his slides in the proceedings, I checked all
the presentations and the chair's slides are not there. So maybe the first
step should be that Jouni posts his slides so we can have a look.

Regards,

Behcet

--001a11c3cd842461d004eb1505c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


As for the next steps, my suggestion i=
s that Jouni posts a draft charter based on the slide he showed in Vancouve=
r where different pieces of a dmm solution was listed.

We can =
have email discussions based on that proposal and hopefully come to a conse=
nsus in a reasonable amount of time.



However, Jouni did not post his slides in the proceedings, I chec=
ked all the presentations and the chair's slides are not there. So mayb=
e the first step should be that Jouni posts his slides so we can have a loo=
k.



Regards,

Behcet





--001a11c3cd842461d004eb1505c2--

From brian@innovationslab.net  Wed Nov 13 12:53:37 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA0B11E8120 for ; Wed, 13 Nov 2013 12:53:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WswkJJQfD1XU for ; Wed, 13 Nov 2013 12:53:32 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE6B21F9D1E for ; Wed, 13 Nov 2013 12:53:32 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id C1A23880A9 for ; Wed, 13 Nov 2013 12:53:31 -0800 (PST)
Received: from 10252612.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 79EC413680B7 for ; Wed, 13 Nov 2013 12:53:31 -0800 (PST)
Message-ID: <5283E6C8.4070102@innovationslab.net>
Date: Wed, 13 Nov 2013 15:53:28 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: dmm@ietf.org
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>		<5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com>	<52839A22.5090301@innovationslab.net>	<5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com>	<5283A299.9030003@gmail.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ixjPrWOHxmGEuaw40sIJb987gwdw6fIAc"
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 20:53:37 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ixjPrWOHxmGEuaw40sIJb987gwdw6fIAc
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Rather than sink into a re-chartering discussion, I would like the WG to
focus on completing the existing work items.  It was suggested that an
interim (or 2) get set up to work on these items.  Please focus on this
rather than re-chartering.

Regards,
Your friendly AD

On 11/13/13 3:43 PM, Behcet Sarikaya wrote:
> As for the next steps, my suggestion is that Jouni posts a draft charte=
r
> based on the slide he showed in Vancouver where different pieces of a d=
mm
> solution was listed.
>=20
> We can have email discussions based on that proposal and hopefully come=
 to
> a consensus in a reasonable amount of time.
>=20
> However, Jouni did not post his slides in the proceedings, I checked al=
l
> the presentations and the chair's slides are not there. So maybe the fi=
rst
> step should be that Jouni posts his slides so we can have a look.
>=20
> Regards,
>=20
> Behcet
>=20
>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>=20


--ixjPrWOHxmGEuaw40sIJb987gwdw6fIAc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSg+bNAAoJEBOZRqCi7goq5VEH/1lDOLWDaOmBvF6T1dA7O+so
7NzLAXjB/oaJBbp/NShyvcaW3rxbiB2J5n8VxGBfKU5SUP2HxGdOl5BWhk8C6w13
nox05QDD/PeVYGwWEjnBmnKq3LpTVpxG8Wu22cljdJPc2jIbbHSFnZCy4V8HkTf0
Ys31d+N8RqgddyTgwqnZOWvDVFkPz4Db3PIY2wI6WdVpqucGyaV7WGE7viP2BJPR
WAMHcAe3q4uFQqO3rScPLOFg0QPxnZnmyeh5IW0bKTxYXcojqT3umepMOANv8O4f
dCOXVXHD/yvvy7ab2SorerAHn2CDqo3hKXYrEcuJMUKCiKCTt/+73+ff4q2h8ig=
=RINN
-----END PGP SIGNATURE-----

--ixjPrWOHxmGEuaw40sIJb987gwdw6fIAc--

From sarikaya2012@gmail.com  Wed Nov 13 13:01:42 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6E021E80CA for ; Wed, 13 Nov 2013 13:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level: 
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.249,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gD88+q0lcght for ; Wed, 13 Nov 2013 13:01:41 -0800 (PST)
Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8A021E80C3 for ; Wed, 13 Nov 2013 13:01:41 -0800 (PST)
Received: by mail-la0-f45.google.com with SMTP id eh20so862409lab.18 for ; Wed, 13 Nov 2013 13:01:40 -0800 (PST)
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=ik/234oB66d0ufb1vTZ4LiYmmuXJe2MDsfQkCRh6f1o=; b=iz3kyvucFkJxTbWdyRk/LsBCelqpBO53w9nwxLKaNRcWRM+BQLOsMo2thuO/9DqloH ZHcZB/LJM41Ju255UGvgYTeBSOxoAbijB4hHCkIoeaRKy8+BA3Z6qIzZe0+MyoNq6eZ/ tJ4VgXqrlHlLcuAl3IPtO28quwaapyQySh9/ue66IWp8kE4KZ89DFT81+8qUbkyrYFJf PtznfH3/czMv0/XPR4U9PNNZaBUuztSWpTJZfmYGUpDzfgPwDdM6n7S/Uw0io6Myg0JS aO+YkFcmAlCnki89k747gzHk2+rs/30V3Lv+5K2nucWyrrczhYvICbmkxo20Wfkh33E9 4gng==
MIME-Version: 1.0
X-Received: by 10.152.116.46 with SMTP id jt14mr7789106lab.31.1384376500144; Wed, 13 Nov 2013 13:01:40 -0800 (PST)
Received: by 10.114.217.129 with HTTP; Wed, 13 Nov 2013 13:01:40 -0800 (PST)
In-Reply-To: <5283E6C8.4070102@innovationslab.net>
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com> <52839A22.5090301@innovationslab.net> <5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com> <5283A299.9030003@gmail.com>  <5283E6C8.4070102@innovationslab.net>
Date: Wed, 13 Nov 2013 15:01:40 -0600
Message-ID: 
From: Behcet Sarikaya 
To: Brian Haberman 
Content-Type: multipart/alternative; boundary=001a11c3562486cdef04eb1545c2
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
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, 13 Nov 2013 21:01:42 -0000

--001a11c3562486cdef04eb1545c2
Content-Type: text/plain; charset=ISO-8859-1

Hi Brian,

I personally think that Interim(s) would not work for dmm. Only a few
people could go to such meetings. Most of us already have a heavy travel
schedule, squeezing another trip seems not so reasonable.

Regards,

Behcet


On Wed, Nov 13, 2013 at 2:53 PM, Brian Haberman wrote:

> Rather than sink into a re-chartering discussion, I would like the WG to
> focus on completing the existing work items.  It was suggested that an
> interim (or 2) get set up to work on these items.  Please focus on this
> rather than re-chartering.
>
> Regards,
> Your friendly AD
>
> On 11/13/13 3:43 PM, Behcet Sarikaya wrote:
> > As for the next steps, my suggestion is that Jouni posts a draft charter
> > based on the slide he showed in Vancouver where different pieces of a dmm
> > solution was listed.
> >
> > We can have email discussions based on that proposal and hopefully come
> to
> > a consensus in a reasonable amount of time.
> >
> > However, Jouni did not post his slides in the proceedings, I checked all
> > the presentations and the chair's slides are not there. So maybe the
> first
> > step should be that Jouni posts his slides so we can have a look.
> >
> > Regards,
> >
> > Behcet
> >
> >
> >
> > _______________________________________________
> > 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
>
>

--001a11c3562486cdef04eb1545c2
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Brian,

I personally think t=
hat Interim(s) would not work for dmm. Only a few people could go to such m=
eetings. Most of us already have a heavy travel schedule, squeezing another=
 trip seems not so reasonable.


Regards,

Behcet


On Wed, Nov 13, 2013 at 2:53 PM=
, Brian Haberman <brian@innovationslab.net> wrote:

Rather than sink into a re-chartering discus=
sion, I would like the WG to

focus on completing the existing work items. =A0It was suggested that an
interim (or 2) get set up to work on these items. =A0Please focus on this
rather than re-chartering.



Regards,

Your friendly AD




On 11/13/13 3:43 PM, Behcet Sarikaya wrote:

> As for the next steps, my suggestion is that Jouni posts a draft chart=
er

> based on the slide he showed in Vancouver where different pieces of a =
dmm

> solution was listed.

>

> We can have email discussions based on that proposal and hopefully com=
e to

> a consensus in a reasonable amount of time.

>

> However, Jouni did not post his slides in the proceedings, I checked a=
ll

> the presentations and the chair's slides are not there. So maybe t=
he first

> step should be that Jouni posts his slides so we can have a look.

>

> Regards,

>

> Behcet

>

>

>


> __________________=
_____________________________

> dmm mailing list

> dmm@ietf.org

> https://www.ietf.org/mailman/listinfo/dmm

>





_______________________________________________

dmm mailing list

dmm@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/dmm





--001a11c3562486cdef04eb1545c2--

From brian@innovationslab.net  Wed Nov 13 13:04:43 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C6321E80C3 for ; Wed, 13 Nov 2013 13:04:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdvB3QVY89MN for ; Wed, 13 Nov 2013 13:04:38 -0800 (PST)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D4A7611E8179 for ; Wed, 13 Nov 2013 13:04:38 -0800 (PST)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AB632880A9; Wed, 13 Nov 2013 13:04:38 -0800 (PST)
Received: from 10252612.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 5C36213680B7; Wed, 13 Nov 2013 13:04:38 -0800 (PST)
Message-ID: <5283E960.5040007@innovationslab.net>
Date: Wed, 13 Nov 2013 16:04:32 -0500
From: Brian Haberman 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: Behcet Sarikaya 
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>		<5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com>	<52839A22.5090301@innovationslab.net>	<5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com>	<5283A299.9030003@gmail.com>		<5283E6C8.4070102@innovationslab.net> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TMtTnkQbi99FAp92jTDl50u1CguqIXNGf"
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 13 Nov 2013 21:04:44 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--TMtTnkQbi99FAp92jTDl50u1CguqIXNGf
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I never said they had to be face-to-face meetings.  It is completely
acceptable to hold virtual (on-line) meetings.

Regards,
Brian

On 11/13/13 4:01 PM, Behcet Sarikaya wrote:
> Hi Brian,
>=20
> I personally think that Interim(s) would not work for dmm. Only a few
> people could go to such meetings. Most of us already have a heavy trave=
l
> schedule, squeezing another trip seems not so reasonable.
>=20
> Regards,
>=20
> Behcet
>=20
>=20
> On Wed, Nov 13, 2013 at 2:53 PM, Brian Haberman wrote:
>=20
>> Rather than sink into a re-chartering discussion, I would like the WG =
to
>> focus on completing the existing work items.  It was suggested that an=

>> interim (or 2) get set up to work on these items.  Please focus on thi=
s
>> rather than re-chartering.
>>
>> Regards,
>> Your friendly AD
>>
>> On 11/13/13 3:43 PM, Behcet Sarikaya wrote:
>>> As for the next steps, my suggestion is that Jouni posts a draft char=
ter
>>> based on the slide he showed in Vancouver where different pieces of a=
 dmm
>>> solution was listed.
>>>
>>> We can have email discussions based on that proposal and hopefully co=
me
>> to
>>> a consensus in a reasonable amount of time.
>>>
>>> However, Jouni did not post his slides in the proceedings, I checked =
all
>>> the presentations and the chair's slides are not there. So maybe the
>> first
>>> step should be that Jouni posts his slides so we can have a look.
>>>
>>> Regards,
>>>
>>> Behcet
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>=20


--TMtTnkQbi99FAp92jTDl50u1CguqIXNGf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJSg+llAAoJEBOZRqCi7goqPkgIALEQjGYhkIHF2CXXwot0n5yk
MGc8mSSBGX/cwEwYUwgFUhIY1XL8LcnlNi2yNH48IqTlOiNVAutdUE9/RGoJ/ijE
kdVfnYXWzDKqN2F4680dxHOVi3l8tIXhAsNSREaCnZKZjzrcyOqLBX/MlA504rpE
rJvtqvJjPN9xNT73Tn8TwhlsTXXxuV4n6YEVLkt3IF7iYsXXAGgMDtvPM7ipB7sI
+devOlLo93LWF5lQC6/kVFPbFgwk8KdQ0XM54I/wZDtdC0GLHOVa/gLAwbqx9ueA
BVgG1CInIKXtkylDhSe3PWl3Lf9vhM8GM0NZ9RPFOe9wF3oW3Z+BZ5x5OkFi2NQ=
=aqjI
-----END PGP SIGNATURE-----

--TMtTnkQbi99FAp92jTDl50u1CguqIXNGf--

From cjbc@it.uc3m.es  Wed Nov 13 16:02:55 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1572821E80CA for ; Wed, 13 Nov 2013 16:02:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nROwwmVlLWmc for ; Wed, 13 Nov 2013 16:02:50 -0800 (PST)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id B695621E8094 for ; Wed, 13 Nov 2013 16:02:49 -0800 (PST)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3B7A211C56CD; Thu, 14 Nov 2013 01:02:48 +0100 (CET)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [192.168.1.3] (82.158.201.225.dyn.user.ono.com [82.158.201.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id EAE379D3302; Thu, 14 Nov 2013 01:02:47 +0100 (CET)
Message-ID: <1384387367.4058.6.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano 
To: Marco Liebsch 
Date: Thu, 14 Nov 2013 01:02:47 +0100
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D6374FF63@Hydra.office.hd>
References: <5963DDF1F751474D8DEEFDCDBEE43AE7179485FC@dfweml511-mbs.china.huawei.com>  <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd> <1384339889.4137.13.camel@acorde.it.uc3m.es> <69756203DDDDE64E987BC4F70B71A26D6374AEF3@Hydra.office.hd> <1384343268.4137.32.camel@acorde.it.uc3m.es> <69756203DDDDE64E987BC4F70B71A26D6374FF63@Hydra.office.hd>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20290.003
X-TM-AS-Result: No--43.075-7.0-31-1
X-imss-scan-details: No--43.075-7.0-31-1
Cc: Peter McCann , "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: cjbc@it.uc3m.es
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Nov 2013 00:02:55 -0000

Hi Marco,

Thanks for the discussion. Please see inline below.

On Wed, 2013-11-13 at 11:59 +0000, Marco Liebsch wrote:
> Please see inline, Carlos.
> 
> >-----Original Message-----
> >From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es]
> >Sent: Mittwoch, 13. November 2013 12:48
> >To: Marco Liebsch
> >Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org
> >Subject: Re: [DMM] Preparing for DMM future steps and rechartering
> >
> >Hi Marco,
> >
> >On Wed, 2013-11-13 at 11:23 +0000, Marco Liebsch wrote:
> >> Carlos,
> >>
> >> just to clarify my view here: I do not see them as different
> >> approaches, but in a way that the routing approach can complement
> >> mobility anchor-based approaches (MIP-like protocols). And such
> >> routing support is needed only in certain deployments, i.e. in case of
> >> a runtime change of the MN's anchor while the new anchor imports the
> >> MN's IP address (binding) context to enable IP address continuity. To
> >> enable routing the MN's downlink data to its current anchor in the transport
> >network above anchor level, e.g. host routes can be used.
> >
> >I'm not sure I agree on this. To me this seem to already assume a certain
> >solution. And I'm biased because I also have some solutions in mind :D
> 
> Not a solution, but a deployment model. The solution would dig into the
> protocol bits of a selected protocol e.g. BGP to solve that. That's not what
> I am writing about. I write this only to abstract the available solutions to
> deployment models and see where the DMM group can do some work to
> enable a variety of them.

Well, I'm not sure about that. To me, keeping always a single anchor by
effectively moving the it using a routing approach is a different
solution that using multiple distributed anchors, and keeping old ones
while there active communications ongoing (and using more "optimal" ones
for new communications).

> 
> >
> >For example, I think we should not limit only to downlink, unless the ingress
> >filtering is not considered an issue (if it is not, this also kind-of assumes a certain
> >type of solution).
> 
> 
> For sure not. I refrained from describing the complete sequence, as it's not
> relevant for this discussion. Just trying to draw some models and see which
> gaps DMM can close.

OK.

> 
> >
> >>
> >> We end up in a routing-only approach if these anchors will be
> >> distributed to an extreme and placed e.g. on radio access points and
> >> the approach uses something else than MIP protocols to transfer IP
> >> address context between these access points. Then we have Pete's DMM
> >deployment model.
> >
> >Agree, but a routing approach could also be applied even if the anchors are not
> >placed on the radio access points. That's why I see routing as an alternative
> >solution to IP mobility protocols.
> 
> Sure. But I am not sure that it should be the DMM group that builds a new
> alternative to IP mobility. What's the gap analysis then about?
> Interesting to research about, though.

Agree.


> >
> >>
> >> Do you agree to that view?
> >>
> >> I think there is common understanding that DMM is a lot about deployment.
> >> Any of those deployment models are valid. Whereas the DMM WG cannot
> >> work on all extensions needed to enable all models, we should converge
> >> on a reasonable set of first work items to allow operators to enable DMM in
> >their network.
> >
> >I agree. It would be helpful to get some feedback from operators on which
> >deployments they have more interest on.

Thanks,

Carlos

> 
> 
> Good.
> 
> Thanks,
> marco
> 
> >
> >Thanks,
> >
> >Carlos
> >
> >>
> >> marco
> >>
> >>
> >> >-----Original Message-----
> >> >From: Carlos Jesús Bernardos Cano [mailto:cjbc@it.uc3m.es]
> >> >Sent: Mittwoch, 13. November 2013 11:51
> >> >To: Marco Liebsch
> >> >Cc: Sri Gundavelli (sgundave); Peter McCann; dmm@ietf.org
> >> >Subject: Re: [DMM] Preparing for DMM future steps and rechartering
> >> >
> >> >Hi,
> >> >
> >> >I'm also jumping into the discussion a bit late.
> >> >
> >> >Without going into all the detailed discussions that have taken place
> >> >recently, I just want to share my view on the MIP-based vs routing-based
> >approach.
> >> >
> >> >IMHO, we probably need to further look at both approaches in this
> >> >group, but with enough energy level (otherwise we risk to end up with
> >> >nothing after several years). I personally have my doubts that a
> >> >distributed routing-based approach scales in a moderately large
> >> >domain (we also saw many years ago proposals of doing mobility with
> >> >routing that did not take off because of convergence, scalability and
> >administrative issues).
> >> >I think a MIP-based approach (network or host based) would work,
> >> >though it would imply keeping multiple anchors active for a given MN.
> >> >
> >> >We believe this routing-based vs MIP-based comparison is quite
> >> >interesting, and we are actually working at UC3M on experimentally
> >> >evaluating both, so we can make a more educated statement on pros and
> >cons of each of them.
> >> >
> >> >My two cents,
> >> >
> >> >Carlos
> >> >
> >> >On Wed, 2013-11-13 at 10:10 +0000, Marco Liebsch wrote:
> >> >> Hi Sri, all,
> >> >> let me step in here (with some delay..) to clarify one point you raised.
> >> >> Please see inline.
> >> >>
> >> >> >-----Original Message-----
> >> >> >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf
> >> >> >Of Sri Gundavelli (sgundave)
> >> >> >Sent: Montag, 11. November 2013 16:30
> >> >> >To: Peter McCann
> >> >> >Cc: dmm@ietf.org
> >> >> >Subject: Re: [DMM] Preparing for DMM future steps and rechartering
> >> >> >
> >> >> >Hi Pete,
> >> >> >
> >> >> >I'm not sure, I agree with this, or understand this to be precise.
> >> >> >I do not know know CP (in the form of PMIP, GTP or some other
> >> >> >protocol
> >> >> >XYZ) can be completely eliminated. There needs to be some
> >> >> >interface between the access gateway and the mobility anchor. I
> >> >> >assumed your's, Marco's and Ryuji's goal is for eliminating the
> >> >> >tunnel, which I don't believe it can be achieved, but still thought we can
> >discuss this.
> >> >>
> >> >> My intention is not to eliminate a tunnel that exists in any of the
> >> >> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of
> >> >> DMM primarily distributes topological anchor point for the MN's IP
> >address(es).
> >> >Forget about the C-plane for now.
> >> >> Tunnels apply solely below (well, towards access) such anchor.
> >> >> If we distribute them to an extreme, they are placed on radio
> >> >> access points and the tunnel disappears. Then we arrive at Pete's
> >> >> model. If anchor points are somewhere above, say in the backhaul,
> >> >> the tunnel remains at least between the anchor and some node in the
> >> >> access (network
> >> >based mobility mgmnt) or the MN (host based mobility mgmnt).
> >> >>
> >> >> I think none of the proposals wants to discuss away the tunnels as
> >> >> per MIP/PMIP. But above anchor level, regular routing applies to
> >> >> plain data
> >> >packets of the U-Plane.
> >> >> A key component for DMM, IMO, is how to accomplish that routing
> >> >> towards the MN's current anchor point, even if the anchored IP
> >> >> address is
> >> >topologically incorrect.
> >> >> To accomplish this, my intent is to not introduce tunnels above anchor level.
> >> >> So, it's not about eliminating tunnels, but it is about not
> >> >> introducing tunnels where never have been tunnels before :-)
> >> >>
> >> >> marco
> >> >>
> >> >> > IMO, its not just about inserting a RIB route and redistributing
> >> >> >it, but even there in DP there is a state transfer needed  from
> >> >> >the CP and the DP. Starting point appears like a simple route
> >> >> >propagation, very soon it will end up with a bunch of state that
> >> >> >gets moved between the two nodes.  But, may be I don't understand
> >> >> >the ideas clearly on eliminating CP and eliminating tunnels.
> >> >> >I'm not going to oppose this, I don't see this converging, IMHO.
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> >Regards
> >> >> >Sri
> >> >> >
> >> >> >
> >> >> >
> >> >> >On 11/10/13 3:13 PM, "Peter McCann" 
> >wrote:
> >> >> >
> >> >> >>Hi, Sri,
> >> >> >>
> >> >> >>I think you will agree that PMIP is a control protocol for
> >> >> >>setting up tunnels.  A tunnel implies that we are not using the
> >> >> >>destination IP of the inner packet for routing and by definition
> >> >> >>will lead to a non-optimal route and a bit of state on some box
> >> >> >>that can fail and lose that state.
> >> >> >>
> >> >> >>I hope that DMM can consider other approaches such as injecting
> >> >> >>routes from the latest L2-attachment point into the access
> >> >> >>network, which is a truly Distributed Mobility Management
> >> >> >>protocol for getting the packets to the mobile node.  It will
> >> >> >>lead to more optimal routes and more robust fault-tolerant operation of
> >the network.
> >> >> >>
> >> >> >>I think we can continue to use the term MAG to apply to that
> >> >> >>first-hop router which is hopefully co-located with the L2
> >> >> >>termination point (it may not be so in every technology depending
> >> >> >>on the extent to which that technology has evolved to support
> >> >> >>truly Distributed
> >> >operation).
> >> >> >>Anything that happens below the MAG (between the MAG and the L2
> >> >> >>termination point) should be out of scope and we should not
> >> >> >>define any protocol there and we should discourage any separation
> >> >> >>between the
> >> >two.
> >> >> >>
> >> >> >>However, we should not require the MAG to run any form of PMIP
> >> >> >>because tunnels should not be required in the architecture.  We
> >> >> >>should not require an LMA, because this would imply a central
> >> >> >>point of state maintenance and possibility of failure.
> >> >> >>
> >> >> >>It is fine to consider a split between CP and DP but I thought we
> >> >> >>had agreed that any discussion of the protocol to use on such an
> >> >> >>interface would be out of scope for this WG.  IMHO we should
> >> >> >>leave that to the Wireless & Mobile Working Group of ONF.
> >> >> >>
> >> >> >>Now, the proponents of OpenFlow and other CP/DP splits have
> >> >> >>argued that it is better to centralize the algorithms such as
> >> >> >>routing protocols on a logically centralized server or servers
> >> >> >>with a synchronized global view of the network.
> >> >> >>I have no problem with that, in which case this centralized
> >> >> >>controller just needs to get notified about the MN's current
> >> >> >>attachment point, so it can install the routes (or tunnels, if an
> >> >> >>operator wishes to use
> >> >> >>them) into the DP.
> >> >> >>But,
> >> >> >>the mechanisms for doing so are out of scope for the DMM WG
> >> >> >>because we are not working on a CP/DP split.  I think it would be
> >> >> >>appropriate for the DMM WG (which exists in the IETF, a standards
> >> >> >>body that has a long history of developing distributed and
> >> >> >>fault-tolerant routing protocols) to describe a more distributed
> >> >> >>alternative, building on foundational Internet technologies such
> >> >> >>as I-BGP, in such a way that will bring down the costs, reduce
> >> >> >>the latency, and increase the robustness of wireless access networks.
> >> >> >>
> >> >> >>I actually don't think we need to define any new extensions or
> >> >> >>IEs for BGP; I would like to read more about Ryuji's proposed extensions
> >here.
> >> >> >>All we need is for the MAG to learn what IPs have been assigned
> >> >> >>to the MN, decide which of those IPs are in the scope of the
> >> >> >>local AS, and inject routes for those prefixes to itself.  We
> >> >> >>could work on alternative mechanisms for discovering this list of
> >> >> >>addresses - the fundamental requirement is that we use an
> >> >> >>authenticated MN ID (probably an NAI) as an index to lookup the
> >> >> >>set of IPs in a distributed
> >> >database.
> >> >> >>I've proposed using DNS for this but there are other alternatives.
> >> >> >>We also need a way to make sure the latest UPDATE gets used by
> >> >> >>all the BGP peers.
> >> >> >>I've proposed
> >> >> >>putting a timestamp in LOCAL_PREF but there are probably other
> >> >> >>alternatives.
> >> >> >>
> >> >> >>It would also be nice to have a well-defined fall-back mechanism
> >> >> >>in case the MN moves to a different AS or just too far from the
> >> >> >>original MAG, in which case the I-BGP approach wouldn't scale.
> >> >> >>For these cases, I think a client MIP tunnel to an HA located in
> >> >> >>the original AS for each assigned IP address would be ideal.
> >> >> >>The HA can behave just like the MAGs in that domain, injecting
> >> >> >>routes when MNs establish tunnels to it so as to attract the
> >> >> >>packets to themselves (this would be the routing equivalent of
> >> >> >>the proxy-ARP or proxy-ND mechanism that works on just a single
> >> >> >>home link in MIPv4 or MIPv6).  We should work on mechanisms to
> >> >> >>enable dynamic assignment of local HAs to MNs and dynamic
> >> >> >>establishment of security associations that don't require AAA and
> >> >> >>associated round-trips to the home
> >> >network.
> >> >> >>Because the HA
> >> >> >>is associated with the original MAG that assigned the address,
> >> >> >>this may involve some DHCP extensions.  There is already a way to
> >> >> >>assign the HA IP address but we will need new extensions to carry
> >> >> >>the HA credentials to the MN (maybe just an HA DNS name so the MN
> >> >> >>can use DANE to retrieve a public key).
> >> >> >>
> >> >> >>I think something like the path I've outlined above would make a
> >> >> >>good work plan for the future of DMM.
> >> >> >>
> >> >> >>-Pete
> >> >> >>
> >> >> >
> >> >> >_______________________________________________
> >> >> >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 sgundave@cisco.com  Wed Nov 13 21:22:16 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C542321E81B0 for ; Wed, 13 Nov 2013 21:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-0-UKccCkzi for ; Wed, 13 Nov 2013 21:22:11 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 38EB021E81B3 for ; Wed, 13 Nov 2013 21:22:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2400; q=dns/txt; s=iport; t=1384406531; x=1385616131; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dWUuCw3bRCg9KDGQTCZFornq4zBl2uEOVPVRTd40+dg=; b=a0peve2iUmrn2r4LDgyiap0dE89dMoCWhvf/UaSPuol6DM3TexQWQfeT lY5hZYpg1vv57r2uJjy/SEeoa5WHkSHJebPCMdvxeYz1pk84sMSRPFUKi VrXVL4zDfn48dmEctCRfAYNJDdFcBHKXKykBg0m3HamkygZFwX4akKO1L A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFANpchFKtJV2a/2dsb2JhbABZgweBC78rgSkWdIIsOj8SAQg2QiUCBAENiAa/VI9fB4QxA5gQkgyDKIIq
X-IronPort-AV: E=Sophos;i="4.93,697,1378857600"; d="scan'208";a="284580709"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 14 Nov 2013 05:22:10 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAE5M9u6018469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 05:22:09 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 23:22:09 -0600
From: "Sri Gundavelli (sgundave)" 
To: Marco Liebsch , Peter McCann 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO4Pl2MbtoHxXoFU2lz0O+EaSnrg==
Date: Thu, 14 Nov 2013 05:22:08 +0000
Message-ID: 
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.212]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8134225629F6E64FBEB2722A41D2A834@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Nov 2013 05:22:16 -0000

Hi Marco,


>
>My intention is not to eliminate a tunnel that exists in any of the
>tunnel management
>protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes
>topological
>anchor point for the MN's IP address(es). Forget about the C-plane for
>now.
>Tunnels apply solely below (well, towards access) such anchor.
>If we distribute them to an extreme, they are placed on radio access
>points and
>the tunnel disappears. Then we arrive at Pete's model. If anchor points
>are somewhere
>above, say in the backhaul, the tunnel remains at least between the
>anchor and some node in
>the access (network based mobility mgmnt) or the MN (host based mobility
>mgmnt).


Ok.=20

Distributing topological anchor points at the access edge can be done
today without any new standards extensions. This is more about deployment
and selection of a gateway at the access edge. But, any time the MN moves
and attaches to a different point in the network, that tunnel and the CP
is expected to be there between the previous home-anchor and the current
access-anchor. But, here, the proposals hide the tunnel (at the initial
attachment point and what can be argued as a home link and which is fine),
but when the MN moves the session is re-anchored to a different gateway
with a churn in the routing infrastructure and with major impact to policy
plane. So, there is no tunnel and there is no CP in this model.


>
>I think none of the proposals wants to discuss away the tunnels as per
>MIP/PMIP. But above
>anchor level, regular routing applies to plain data packets of the
>U-Plane.
>A key component for DMM, IMO, is how to accomplish that routing towards
>the MN's current anchor point, even if the anchored IP address is
>topologically incorrect.
>To accomplish this, my intent is to not introduce tunnels above anchor
>level.
>So, it's not about eliminating tunnels, but it is about not introducing
>tunnels
>where never have been tunnels before :-)


:) If you can show this working without re-anchoring the session to a
different gateway, then I will agree. You see this from the point of view
of IP routing, but I'm looking for that subscriber session which I'm not
able to find.
=20
Tunnels hide the topology and make that reachability work; it gives me a
stable anchor point that my operator can manage my session.


Regards
Sri



From Peter.McCann@huawei.com  Thu Nov 14 05:19:42 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F40F21E80C8 for ; Thu, 14 Nov 2013 05:19:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxkR5XQkbgDe for ; Thu, 14 Nov 2013 05:19:38 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 99C2721E8090 for ; Thu, 14 Nov 2013 05:19:37 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAG91327; Thu, 14 Nov 2013 13:19:35 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 13:19:14 +0000
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 13:19:33 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 05:19:22 -0800
From: Peter McCann 
To: "Sri Gundavelli (sgundave)" , Marco Liebsch 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: Ac7Y3bqUR0J96RB8SmOZDtKQ9LtNUZoUE9cAgABImwCAAQY4gIAAASiAgABd6ICAABT2rIAAGTgAgAKCNYCAABNZAIAByxEAgAEHGQCAABsyAIAAAfoAgAM2QQCAAAZaAIAAAnoAgAAfUgCAAAWgAIAAOa4AgAEQvoCAAtigQOXtwbUAgAACenA=
Date: Thu, 14 Nov 2013 13:19:22 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE717948D75@dfweml511-mbs.china.huawei.com>
References: <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.246.30]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Nov 2013 13:19:42 -0000

Hi, Marco, Sri,

I think that Marco's analysis works, in the sense that it places both
classes of solutions within a cohesive framework.  I am more doubtful,
however, that the two kinds of solutions would co-exist in the same
access network, as they both seem to implement a kind of local mobility
management.

Yes, Sri, I think this is a "re-anchoring" if we define the anchor as
the point to which IP packets are delivered by the routing infrastructure.
I don't see why you say there is no control plane; I can still have an
SDN-style network with a separate controller making policy decisions.
It is true that there is no single router that handles the user's traffic
for the life of the IP session, but I thought the point of DMM was to get
rid of such scalability and fault bottlenecks.

I am a little confused as to what is your definition of a control plane.
It seems you apply this term to the LMA, but in today's specs the LMA
is a combined CP/DP entity.

-Pete

Sri Gundavelli (sgundave) wrote:
> Hi Marco,
>=20
>=20
>>=20
>> My intention is not to eliminate a tunnel that exists in any of the
>> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
>> primarily distributes topological anchor point for the MN's IP
>> address(es). Forget about the C-plane for now.
>> Tunnels apply solely below (well, towards access) such anchor.
>> If we distribute them to an extreme, they are placed on radio access
>> points and the tunnel disappears. Then we arrive at Pete's model. If
>> anchor points are somewhere above, say in the backhaul, the tunnel
>> remains at least between the anchor and some node in the access
>> (network based mobility mgmnt) or the MN (host based mobility mgmnt).
>=20
>=20
> Ok.
>=20
> Distributing topological anchor points at the access edge can be done
> today without any new standards extensions. This is more about
> deployment and selection of a gateway at the access edge. But, any
> time the MN moves and attaches to a different point in the network,
> that tunnel and the CP is expected to be there between the previous
> home- anchor and the current access-anchor. But, here, the proposals
> hide the tunnel (at the initial attachment point and what can be
> argued as a home link and which is fine), but when the MN moves the
> session is re- anchored to a different gateway with a churn in the
> routing infrastructure and with major impact to policy plane. So,
> there is no tunnel and there is no CP in this model.
>=20
>=20
>>=20
>> I think none of the proposals wants to discuss away the tunnels as per
>> MIP/PMIP. But above anchor level, regular routing applies to plain data
>> packets of the U-Plane. A key component for DMM, IMO, is how to
>> accomplish that routing towards the MN's current anchor point, even if
>> the anchored IP address is topologically incorrect. To accomplish this,
>> my intent is to not introduce tunnels above anchor level. So, it's not
>> about eliminating tunnels, but it is about not introducing tunnels
>> where never have been tunnels before :-)
>=20
>=20
> :) If you can show this working without re-anchoring the session to a
> different gateway, then I will agree. You see this from the point of
> view of IP routing, but I'm looking for that subscriber session which
> I'm not able to find.
>=20
> Tunnels hide the topology and make that reachability work; it gives me
> a stable anchor point that my operator can manage my session.
>=20
>=20
> Regards
> Sri
>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm




From sgundave@cisco.com  Thu Nov 14 07:28:51 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF45A21F9D0F for ; Thu, 14 Nov 2013 07:28:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.574
X-Spam-Level: 
X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtluzuVgFsvP for ; Thu, 14 Nov 2013 07:28:47 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8465921E80E8 for ; Thu, 14 Nov 2013 07:28:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4626; q=dns/txt; s=iport; t=1384442915; x=1385652515; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=iTQMsjhnpQ60yt5buaoW5GC/0Y3BdoYTX2R2mrIOUjk=; b=ABnnq4XbhB6mC051Ica/KBuRcfTcBX1eG/X1G/Y/zqTBVgMIvoXCA3Pe 66KnKzP9NlW+DsmfqCyQHkjqYd3dZOgshxlP0V1XEZPZPk1m709FWcyDR R2+K8r9ueP0j8XLg5wOlHztOw+H4rktAc8Wr35vkLxP7SDOuEI897hX5F Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFAOHqhFKtJV2a/2dsb2JhbABagwc4U78hgR8WdIIlAQEBAwEBAQE3NAsFDQEIGB43CyUCBAENBRkCh2AGDcAeBI9fB4QxA5gQkgyDKIIq
X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284872214"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 14 Nov 2013 15:28:35 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAEFSYSJ020107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 15:28:34 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 09:28:34 -0600
From: "Sri Gundavelli (sgundave)" 
To: Peter McCann , Marco Liebsch 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO4U4uMbtoHxXoFU2lz0O+EaSnrg==
Date: Thu, 14 Nov 2013 15:28:34 +0000
Message-ID: 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE717948D75@dfweml511-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.214]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14C1042F026901478B57C64F47590763@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Nov 2013 15:28:51 -0000

Hi Pete,


My definition of CP is between the AG and the MA, what is out there today.
Now, if there is a functional split of CP and DP on any entity, and if
there is a interface between those two in the form of some CP interface,
then I don't have a term for that interface. We can probably agree that
CP/DP split approaches are outside the scope of this discussions.


> I can still have an SDN-style network with a separate controller making
>policy decisions.

Ok. I understand now. Only the DP is moved, but the session CP state is
anchored on a central node ? I call that central node as a mobility
anchor, now if that anchor is in the data path or not is one
consideration. But, functionally, there is still a mobility anchor.




Regards
Sri



On 11/14/13 5:19 AM, "Peter McCann"  wrote:

>Hi, Marco, Sri,
>
>I think that Marco's analysis works, in the sense that it places both
>classes of solutions within a cohesive framework.  I am more doubtful,
>however, that the two kinds of solutions would co-exist in the same
>access network, as they both seem to implement a kind of local mobility
>management.
>
>Yes, Sri, I think this is a "re-anchoring" if we define the anchor as
>the point to which IP packets are delivered by the routing infrastructure.
>I don't see why you say there is no control plane; I can still have an
>SDN-style network with a separate controller making policy decisions.
>It is true that there is no single router that handles the user's traffic
>for the life of the IP session, but I thought the point of DMM was to get
>rid of such scalability and fault bottlenecks.
>
>I am a little confused as to what is your definition of a control plane.
>It seems you apply this term to the LMA, but in today's specs the LMA
>is a combined CP/DP entity.
>
>-Pete
>
>Sri Gundavelli (sgundave) wrote:
>> Hi Marco,
>>=20
>>=20
>>>=20
>>> My intention is not to eliminate a tunnel that exists in any of the
>>> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
>>> primarily distributes topological anchor point for the MN's IP
>>> address(es). Forget about the C-plane for now.
>>> Tunnels apply solely below (well, towards access) such anchor.
>>> If we distribute them to an extreme, they are placed on radio access
>>> points and the tunnel disappears. Then we arrive at Pete's model. If
>>> anchor points are somewhere above, say in the backhaul, the tunnel
>>> remains at least between the anchor and some node in the access
>>> (network based mobility mgmnt) or the MN (host based mobility mgmnt).
>>=20
>>=20
>> Ok.
>>=20
>> Distributing topological anchor points at the access edge can be done
>> today without any new standards extensions. This is more about
>> deployment and selection of a gateway at the access edge. But, any
>> time the MN moves and attaches to a different point in the network,
>> that tunnel and the CP is expected to be there between the previous
>> home- anchor and the current access-anchor. But, here, the proposals
>> hide the tunnel (at the initial attachment point and what can be
>> argued as a home link and which is fine), but when the MN moves the
>> session is re- anchored to a different gateway with a churn in the
>> routing infrastructure and with major impact to policy plane. So,
>> there is no tunnel and there is no CP in this model.
>>=20
>>=20
>>>=20
>>> I think none of the proposals wants to discuss away the tunnels as per
>>> MIP/PMIP. But above anchor level, regular routing applies to plain data
>>> packets of the U-Plane. A key component for DMM, IMO, is how to
>>> accomplish that routing towards the MN's current anchor point, even if
>>> the anchored IP address is topologically incorrect. To accomplish this,
>>> my intent is to not introduce tunnels above anchor level. So, it's not
>>> about eliminating tunnels, but it is about not introducing tunnels
>>> where never have been tunnels before :-)
>>=20
>>=20
>> :) If you can show this working without re-anchoring the session to a
>> different gateway, then I will agree. You see this from the point of
>> view of IP routing, but I'm looking for that subscriber session which
>> I'm not able to find.
>>=20
>> Tunnels hide the topology and make that reachability work; it gives me
>> a stable anchor point that my operator can manage my session.
>>=20
>>=20
>> Regards
>> Sri
>>=20
>>=20
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
>
>


From Marco.Liebsch@neclab.eu  Fri Nov 15 01:57:13 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83E6811E80EC for ; Fri, 15 Nov 2013 01:57:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z4E7nDPMxoD for ; Fri, 15 Nov 2013 01:57:07 -0800 (PST)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B236111E8109 for ; Fri, 15 Nov 2013 01:56:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C12E3106098; Fri, 15 Nov 2013 10:50:05 +0100 (CET)
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 JoonjSvj2k9Q; Fri, 15 Nov 2013 10:50:05 +0100 (CET)
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 A2490106096; Fri, 15 Nov 2013 10:49:50 +0100 (CET)
Received: from HYDRA.office.hd ([169.254.4.178]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 15 Nov 2013 10:56:43 +0100
From: Marco Liebsch 
To: "Sri Gundavelli (sgundave)" , Peter McCann 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO2N32tX9akckQbkC/oEY66nusCZoUE9cAgABImwCAAQY4gIAAASiAgABd6ICAABT2rIAAGTgAgAKCNYCAABNZAIAByxEAgAEHGQCAABsyAIAAAfoAgAM2QQCAAAZaAIAAAnoAgAAfUgCAAAWgAIAAOa4AgAEQvoCAAtigQIABNI4AgAHqd7A=
Date: Fri, 15 Nov 2013 09:56:42 +0000
Message-ID: <69756203DDDDE64E987BC4F70B71A26D6375FA41@Hydra.office.hd>
References: <69756203DDDDE64E987BC4F70B71A26D63749BC6@PALLENE.office.hd> 
In-Reply-To: 
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
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 09:57:13 -0000

Hi Sri,

>-----Original Message-----
>From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
>Sent: Donnerstag, 14. November 2013 06:22
>To: Marco Liebsch; Peter McCann
>Cc: dmm@ietf.org
>Subject: Re: Preparing for DMM future steps and rechartering
>
>Hi Marco,
>
>
>>
>>My intention is not to eliminate a tunnel that exists in any of the
>>tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
>>primarily distributes topological anchor point for the MN's IP
>>address(es). Forget about the C-plane for now.
>>Tunnels apply solely below (well, towards access) such anchor.
>>If we distribute them to an extreme, they are placed on radio access
>>points and the tunnel disappears. Then we arrive at Pete's model. If
>>anchor points are somewhere above, say in the backhaul, the tunnel
>>remains at least between the anchor and some node in the access
>>(network based mobility mgmnt) or the MN (host based mobility mgmnt).
>
>
>Ok.
>
>Distributing topological anchor points at the access edge can be done toda=
y
>without any new standards extensions. This is more about deployment and
>selection of a gateway at the access edge. But, any time the MN moves and
>attaches to a different point in the network, that tunnel and the CP is ex=
pected
>to be there between the previous home-anchor and the current access-anchor=
.
>But, here, the proposals hide the tunnel (at the initial attachment point =
and what
>can be argued as a home link and which is fine), but when the MN moves the
>session is re-anchored to a different gateway with a churn in the routing
>infrastructure and with major impact to policy plane. So, there is no tunn=
el and
>there is no CP in this model.

Depends. I assume that the session you describe is a mobility session (bind=
ing ID-Locator),
not a data session. If the mobility session remains anchored at the previou=
s attachment point,
there will be a tunnel towards the new attachment point, which may serve
as MAG. Optionally, the new attachment point may provide a new anchor and a=
n additional
mobility session, hence an additional HoA, which depend on the MN to handle=
 multiple
IPs. Other approach would imply moving the MN's mobility session from the p=
revious anchor/point of attachment
to the new one. Then there is at least no tunnel needed to forward packets =
from the previous
anchor to the new one. But the anchored HoA or HNP at the new anchor is top=
ologically
incorrect. That means the routing plane above anchors can take care about d=
elivering
downlink packets to the MN's current anchor. Agree that that's an impact to=
 the routing policy
plane, but a valid approach to achieve more optimal routes.=20

>
>
>>
>>I think none of the proposals wants to discuss away the tunnels as per
>>MIP/PMIP. But above anchor level, regular routing applies to plain data
>>packets of the U-Plane.
>>A key component for DMM, IMO, is how to accomplish that routing towards
>>the MN's current anchor point, even if the anchored IP address is
>>topologically incorrect.
>>To accomplish this, my intent is to not introduce tunnels above anchor
>>level.
>>So, it's not about eliminating tunnels, but it is about not introducing
>>tunnels where never have been tunnels before :-)
>
>
>:) If you can show this working without re-anchoring the session to a diff=
erent
>gateway, then I will agree. You see this from the point of view of IP rout=
ing, but
>I'm looking for that subscriber session which I'm not able to find.

Without re-anchoring the previous mobility session at the new anchor means
the previous anchor remains involved in the packet delivery. I was talking =
about
the case where the previous mobility session will be transferred and anchor=
ed at the new
mobility anchor. Only that enables short delivery paths, as the anchor poin=
ts of the
MN's IP address is close to the MN. But in that case the routing plane need=
s
to support packet delivery for that MN. So, either by introducing tunnels i=
n the
routing plane (e.g. according to LISP), which I'd like to avoid. Or by usin=
g per-host routes.
Or by using address translation to a routable address, which delivers the p=
acket
to the mobile's current anchor.=20

>
>Tunnels hide the topology and make that reachability work; it gives me a s=
table
>anchor point that my operator can manage my session.

Sure, anchors as well as tunnels from that anchor to a locator should be ke=
pt. After
anchor relocation, the new anchor takes care about tunnel management to
deliver packets to the current MN's location. However, the routing plane ab=
ove
anchor level may take care about delivering packets to the current anchor, =
which
is a prerequisite to allow the new anchor doing his job.

Greetings,
marco

>
>
>Regards
>Sri
>


From jouni.nospam@gmail.com  Fri Nov 15 02:26:16 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20FD11E8172 for ; Fri, 15 Nov 2013 02:26:16 -0800 (PST)
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=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiaLbjVh+2yh for ; Fri, 15 Nov 2013 02:26:16 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id C40B121F9399 for ; Fri, 15 Nov 2013 02:26:03 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id c11so2588490lbj.3 for ; Fri, 15 Nov 2013 02:26:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=bJTBCWv52ZQGBAP4tgfJPLWrVrCR0bdh224NGfQCxQ4=; b=bIKf2QSC0Kh9yKidsyhQuQP9JaEHYqZoshBU/KdlDLc0KA9sW+/Sih6XadeNruKtBl cSuuJHoKi/NCuyhP6iiHnE1dS97moyJx7ZoX3bMt/LTBVhs4aJYkabpCBKL9AN9EyIeU e8trybqXMEPMLDACKpKCux9BS3WqjsNQOIGszt+bxyxfi3Qrt9pk7MzKpziBf9eBueFf xlRIkGNO0GrMa88OhMyKeSEtKDo1+tS/S6DLvJgmTsMGh9Uv1BrCGL6Q+3W2Ss3MGYDz KScWxZwjEO9lMcPW6A2MSrWoxCXJCdh3V78p+jHuBSZPBpmpGRhIpKlpZdI30uDxU6o8 ppjw==
X-Received: by 10.112.25.66 with SMTP id a2mr68664lbg.48.1384511162736; Fri, 15 Nov 2013 02:26:02 -0800 (PST)
Received: from [192.168.250.24] ([194.100.71.98]) by mx.google.com with ESMTPSA id bf4sm1696557lbc.10.2013.11.15.02.26.02 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Nov 2013 02:26:02 -0800 (PST)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: 
Date: Fri, 15 Nov 2013 12:26:01 +0200
To: "dmm@ietf.org" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Subject: [DMM] meeting minutes have been uploaded
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 10:26:16 -0000

and huge thanks for Carlos & Anthony for taking & _merging_ minutes!

- JOuni & Dapeng

From h.anthony.chan@huawei.com  Fri Nov 15 08:13:13 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B906A21F9A97 for ; Fri, 15 Nov 2013 08:13:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zK9yAMmElpgR for ; Fri, 15 Nov 2013 08:13:09 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1011B11E80DC for ; Fri, 15 Nov 2013 08:11:18 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX94814; Fri, 15 Nov 2013 16:11:17 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 16:10:13 +0000
Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 16:11:16 +0000
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.92]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.03.0158.001; Sat, 16 Nov 2013 00:11:08 +0800
From: h chan 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: draft-ietf-dmm-requirements-10.txt
Thread-Index: AQHOogjoa3/L9muNGkS5wozrKtEQEpnXRZkQgABo14CAAJoKEIADLS4wgAAEQpCAPC2PUIAPRcXA
Date: Fri, 15 Nov 2013 16:11:07 +0000
Message-ID: <6E31144C030982429702B11D6746B98C370DD1D8@szxeml557-mbs.china.huawei.com>
References: <1377486056.79906.YahooMailNeo@web163805.mail.gq1.yahoo.com> <24C0F3E22276D9438D6F366EB89FAEA8116A4D4F@xmb-aln-x03.cisco.com> 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.135.21]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370DD1D8szxeml557mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: [DMM] draft-ietf-dmm-requirements-10.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 16:13:13 -0000

--_000_6E31144C030982429702B11D6746B98C370DD1D8szxeml557mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

May I propose to complete the requirements draft with the following schedul=
e:

Sri mentioned there are editorial issues during the IETF meeting and will r=
espond by end of coming Sunday.
If anyone else have further comments, please keep to this deadline of Sunda=
y November 17.

I don't mean to suggest a deadline in short notice, but the WGLC had alread=
y closed about half year ago. I do thank all of you for all the comments re=
ceived both before and after WGLC, which have contributed so much to improv=
e the requirements draft.

Also, if there are additional comments, I hope to finish resolving them wit=
hin next week.

So when you make these late comments, please also provide suggested text ch=
anges. That will shorten the cycles to go back and forth to resolve these c=
omments.

The requirements draft can then proceed with the next step.

Completing the existing items of requirements and gap analyses are helpful =
as we look forward to new interesting work items.

Thanks to all of you.

H Anthony Chan

From: h chan
Sent: Tuesday, November 05, 2013 4:31 PM
To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

May I request anyone with any more comments or un-closed issue on the requi=
rements to please speak up with suggested text changes to agree on now. I c=
an do one more revision by Thursday to enable the wg to move to the next st=
ep before the Friday DMM meeting.

The gap analysis draft is waiting for the requirements draft to complete.

And the future interesting work of this wg (including yours) are waiting fo=
r the gap analysis draft to complete.

H Anthony Chan

From: h chan
Sent: Saturday, September 28, 2013 8:28 AM
To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Sri,
It appears that version 09 has attempted to address all your comments. Plea=
se check.

H Anthony Chan

From: h chan
Sent: Saturday, September 28, 2013 10:25 AM
To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Sri,

We have revised the Introduction Section and PS1 in version 09. Our respons=
es are in-line.

The following have contributed to the above revisions in draft 09: Pierrick=
, Dapeng, and Jouni


From: dmm-bounces@ietf.org [mailto:dmm-bounces=
@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Sunday, August 25, 2013 10:04 PM
To: dmm@ietf.org
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Please see inline for some comments.

Regards
Sri


.......



4.  Problem Statement



   The problems that can be addressed with DMM are summarized in the

   following:



   PS1:  Non-optimal routes



         Routing via a centralized anchor often results in a longer

         route.

[Sri] "longer route" ?  I assume this is about routing/tx delay. Please re-=
word.



Accept and revised in version 08



The problem is manifested, for example, when accessing

         a local server or servers of a Content Delivery Network (CDN),

         or when receiving locally available IP multicast or sending IP

         multicast packets.



[Sri] Does RFC 6705, or RFC 6909 does not address this issue ? May be the C=
DN example is incorrect.



RFC6909 is clarified further in the Introduction Section in version 09.
   (1)  Mobile users are, more than ever, consuming Internet content;
        such traffic imposes new requirements on mobile core networks
        for data traffic delivery.  The presence of content providers
        closer to Internet Service Providers (ISP) network requires
        taking into account local Content Delivery Networks (CDNs) while
        providing mobility services.  Moreover, when the traffic demand
        exceeds available capacity, service providers need to implement
        new strategies such as selective IPv4 traffic offload (e.g.
        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
        alternative access networks (e.g.  WLAN) [Paper-

        Mobile.Data.Offloading].



RFC6705 is clarified under PS1 in version 09
   PS1:  Non-optimal routes

         Routing via a centralized anchor often results in non-optimal
         routes, thereby increasing the end-to-end delay.  The problem
         is manifested, for example, when accessing a nearby server or
         servers of a Content Delivery Network (CDN), or when receiving
         locally available IP multicast or sending IP multicast packets.
         (Existing route optimization is only a host-based solution.  On
         the other hand, localized routing with PMIPv6 [RFC6705]
         addresses only a part of the problem where both the MN and the
         CN are located in the PMIP domain and attached to a MAG, and is
         not applicable when the CN is outside the PMIP domain or does
         not behave like an MN.)







   PS2:  Divergence from other evolutionary trends in network

         architectures such as distribution of content delivery.



         Centralized mobility management can become non-optimal with a

         flat network architecture.



[Sri] How is this making the case of DMM ? We want the MN to access content=
 locally in the access network and we want localized routing. We have that =
in the form of 6705 and 6909. The other approach is give localized IP addre=
sses and have the content locally accessed. There are simply two many consi=
derations and points may be valid, but when we bring all those assumptions.=
 We are bringing these points in a less logical manner without stating the =
assumptions.



Our response is similar to that in PS1. Also PS2 is referring to flat mobil=
e network.



   PS3:  Low scalability of centralized tunnel management and mobility

         context maintenance



         Setting up tunnels through a central anchor and maintaining

         mobility context for each MN usually requires more concentrated

         resources in a centralized design, thus reducing scalability.

         Distributing the tunnel maintenance function and the mobility

         context maintenance function among different network entities

         with proper signaling protocol design can increase scalability.



   PS4:  Single point of failure and attack



         Centralized anchoring designs may be more vulnerable to single

         points of failures and attacks than a distributed system.  The

         impact of a successful attack on a system with centralized

         mobility management can be far greater as well.



   PS5:  Unnecessarily reserving resources to provide mobility support

         to nodes that do not need such support



         IP mobility support is not always required, and not every

         parameter of mobility context is always used.  For example,

         some applications do not need a stable IP address during a

         handover to maintain session continuity.  Sometimes, the entire

         application session runs while the terminal does not change the

         point of attachment.  Besides, some sessions, e.g.  SIP-based

         sessions, can handle mobility at the application layer and

         hence do not need IP mobility support; it is then more

         efficient to deactivate IP mobility support for such sessions.



[Sri]  Mobility systems today do support the aspect of service for the subs=
criber, as "Simple IP", or "Mobile IP". A PDSN can assign a local IP addres=
s and it does not have to be the home address. Network does have this intel=
ligence, but what is missing is the client's ability to pick the correct ty=
pe of IP address, among different IP addresses. The network is also the mis=
sing the aspect of marking those addresses with proper properties. The curr=
ently active drafts in IETF are to address this issue. We should talk about=
 these missing semantics.

draft-bhandari-dhc-class-based-prefix-05

draft-korhonen-6man-prefix-properties-02



These references have been added in the Introduction Section in version 09


   (2)  Today's mobile networks present service providers with new
        challenges.  Mobility patterns indicate that mobile nodes often
        remain attached to the same point of attachment for considerable
        periods of time [Paper-Locating.User].  Specific IP mobility
        management support is not required for applications that launch
        and complete their sessions while the mobile node is connected
        to the same point of attachment.  However, currently, IP
        mobility support is designed for always-on operation,
        maintaining all parameters of the context for each mobile
        subscriber for as long as they are connected to the network.
        This can result in a waste of resources and unnecessary costs
        for the service provider.  Infrequent node mobility coupled with
        application intelligence suggest that mobility support could be
        provided selectively such as in [I-D.bhandari-dhc-class-based-
        prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
        the amount of context maintained in the network.




--_000_6E31144C030982429702B11D6746B98C370DD1D8szxeml557mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











May I propose to complete=
 the requirements draft with the following schedule:


 <=
/p>

Sri mentioned there are e=
ditorial issues during the IETF meeting and will respond by end of coming S=
unday.



If anyone else have furth=
er comments, please keep to this deadline of Sunday November 17.=



 <=
/p>

I don’t mean to sug=
gest a deadline in short notice, but the WGLC had already closed about half=
 year ago. I do thank all of you for all the comments received
 both before and after WGLC, which have contributed so much to improve the =
requirements draft.



 <=
/p>

Also, if there are additi=
onal comments, I hope to finish resolving them within next week.



 <=
/p>

So when you make these la=
te comments, please also provide suggested text changes. That will shorten =
the cycles to go back and forth to resolve these comments.



 <=
/p>

The requirements draft ca=
n then proceed with the next step.



 <=
/p>

Completing the existing i=
tems of requirements and gap analyses are helpful as we look forward to new=
 interesting work items.



 <=
/p>

Thanks to all of you.



 <=
/p>



H Anthony Chan=





 <=
/p>





From: h chan


Sent: Tuesday, November 05, 2013 4:31 PM

To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'

Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 


May I request anyone with=
 any more comments or un-closed issue on the requirements to please speak u=
p
with suggested text changes to agree on now. I can do one more revision by Thursday to
 enable the wg to move to the next step before the Friday DMM meeting. 


 <=
/p>

The gap analysis draft is=
 waiting for the requirements draft to complete.



 <=
/p>

And the future interestin=
g work of this wg (including yours) are waiting for the gap analysis draft =
to complete.



 <=
/p>



H Anthony Chan=





 <=
/p>





From: h chan


Sent: Saturday, September 28, 2013 8:28 AM

To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'

Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 


Sri,

It appears that version 0=
9 has attempted to address all your comments. Please check.



 <=
/p>



H Anthony Chan=





 <=
/p>





From: h chan


Sent: Saturday, September 28, 2013 10:25 AM

To: 'Sri Gundavelli (sgundave)'; 'dmm@ietf.org'

Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 


Sri,

 <=
/p>

We have revised the Intro=
duction Section and PS1 in version 09. Our responses are in-line.



 <=
/p>

The following have contri=
buted to the above revisions in draft 09: Pierrick, Dapeng, and Jouni<=
/o:p>


 <=
/p>

 <=
/p>





From:
dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org]
On Behalf Of Sri Gundavelli (sgundave)

Sent: Sunday, August 25, 2013 10:04 PM

To: dmm@ietf.org

Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 




Please see inline for some comments.






 






Regards






Sri






 
























…….


 


4.  Problem St=
atement


 


   The pr=
oblems that can be addressed with DMM are summarized in the


   follow=
ing:


 


   PS1:&n=
bsp; Non-optimal routes


 


   &=
nbsp;     Routing via a centralized anchor often result=
s in a longer


   &=
nbsp;     route.  


[Sri] "longer route" ?&=
nbsp; I assume this is about routing/tx delay. Please re-word.


 


Accept and revised in=
 version 08


 


The problem is mani=
fested, for example, when accessing


   &=
nbsp;     a local server or servers of a Content Delive=
ry Network (CDN),


   &=
nbsp;     or when receiving locally available IP multic=
ast or sending IP


   &=
nbsp;     multicast packets.


 


[Sri] Does RFC 67=
05, or RFC 6909 does not address this issue ? May be the CDN example is inc=
orrect. 


 


RFC6909 is clarified =
further in the Introduction Section in version 09.  =



   (1)  Mobile users are, more than ever, c=
onsuming Internet content;


        such traffic im=
poses new requirements on mobile core networks


        for data traffi=
c delivery.  The presence of content providers


        closer to Inter=
net Service Providers (ISP) network requires


        taking into acc=
ount local Content Delivery Networks (CDNs) while


        providing mobil=
ity services.  Moreover, when the traffic demand


        exceeds availab=
le capacity, service providers need to implement


        new strategies =
such as selective
IPv4 traffic offload (e.g.


        [RFC6909], 3GPP=
 work items LIPA/SIPTO [TS.23.401]) through


        alternative acc=
ess networks (e.g.  WLAN) [Paper-


        =
Mobile.Data.Offloading].  


 =



RFC6705 is clarified=
 under PS1 in version 09


   PS1:  Non-optimal routes


 


         Routing v=
ia a centralized anchor often results in non-optimal


         routes, t=
hereby increasing the end-to-end delay.  The problem=



         is manife=
sted, for example, when accessing a nearby server or


         servers o=
f a Content Delivery Network (CDN), or when receiving


         locally a=
vailable IP multicast or sending IP multicast packets.

        =
 (Existing route optimization is only a host-based solution.  On<=
/o:p>


        =
 the other hand, localized routing with PMIPv6 [RFC6705]<=
/p>

        =
 addresses only a part of the problem where both the MN and the<=
/span>


        =
 CN are located in the PMIP domain and attached to a MAG, and is=



        =
 not applicable when the CN is outside the PMIP domain or does


        =
 not behave like an MN.)


 


 


 


   PS2:&n=
bsp; Divergence from other evolutionary trends in network=



   &=
nbsp;     architectures such as distribution of content=
 delivery.


 


   &=
nbsp;     Centralized mobility management can become no=
n-optimal with a


   &=
nbsp;     flat network architecture.<=
/pre>

 


[Sri] How is this=
 making the case of DMM ? We want the MN to access content locally in the a=
ccess network and we want localized routing. We have that in the form of 67=
05 and 6909. The other approach is give localized IP addresses and have the=
 content locally accessed. There are simply two many considerations and poi=
nts may be valid, but when we bring all those assumptions. We are bringing =
these points in a less logical manner without stating the assumptions.


 =



Our response is simi=
lar to that in PS1. Also PS2 is referring to flat mobile network. 


 


   PS3:&n=
bsp; Low scalability of centralized tunnel management and mobility


   &=
nbsp;     context maintenance


 


   &=
nbsp;     Setting up tunnels through a central anchor a=
nd maintaining


   &=
nbsp;     mobility context for each MN usually requires=
 more concentrated


   &=
nbsp;     resources in a centralized design, thus reduc=
ing scalability.


   &=
nbsp;     Distributing the tunnel maintenance function =
and the mobility


   &=
nbsp;     context maintenance function among different =
network entities


   &=
nbsp;     with proper signaling protocol design can inc=
rease scalability.


 


   PS4:&n=
bsp; Single point of failure and attack


 


   &=
nbsp;     Centralized anchoring designs may be more vul=
nerable to single


   &=
nbsp;     points of failures and attacks than a distrib=
uted system.  The


   &=
nbsp;     impact of a successful attack on a system wit=
h centralized


   &=
nbsp;     mobility management can be far greater as wel=
l.


 


   PS5:&n=
bsp; Unnecessarily reserving resources to provide mobility support


   &=
nbsp;     to nodes that do not need such support


 


   &=
nbsp;     IP mobility support is not always required, a=
nd not every


   &=
nbsp;     parameter of mobility context is always used.=
  For example,


   &=
nbsp;     some applications do not need a stable IP add=
ress during a


   &=
nbsp;     handover to maintain session continuity. =
; Sometimes, the entire


   &=
nbsp;     application session runs while the terminal d=
oes not change the


   &=
nbsp;     point of attachment.  Besides, some sess=
ions, e.g.  SIP-based


   &=
nbsp;     sessions, can handle mobility at the applicat=
ion layer and


   &=
nbsp;     hence do not need IP mobility support; it is =
then more


   &=
nbsp;     efficient to deactivate IP mobility support f=
or such sessions.


 


[Sri]  Mobility systems toda=
y do support the aspect of service for the subscriber, as "Simple IP&q=
uot;, or "Mobile IP". A PDSN can assign a local IP address and it=
 does not have to be the home address. Network does have this intelligence,=
 but what is missing is the client's ability to pick the correct type of IP=
 address, among different IP addresses. The network is also the missing the=
 aspect of marking those addresses with proper properties. The currently ac=
tive drafts in IETF are to address this issue. We should talk about these m=
issing semantics.<=
/pre>

draft-bhandari-dhc-class-based-prefix-05  


draft-korhonen-6man-prefix-properties-02<=
/span>


 


These references have=
 been added in the Introduction Section in version 09

 


   (2)  Today's mobile networks present ser=
vice providers with new


        challenges.&nbs=
p; Mobility patterns indicate that mobile nodes often


        remain attached=
 to the same point of attachment for considerable


        periods of time=
 [Paper-Locating.User].  Specific IP mobility


        management supp=
ort is not required for applications that launch


        and complete th=
eir sessions while the mobile node is connected


        to the same poi=
nt of attachment.  However, currently, IP


        mobility suppor=
t is designed for always-on operation,


        maintaining all=
 parameters of the context for each mobile


        subscriber for =
as long as they are connected to the network.


        This can result=
 in a waste of resources and unnecessary costs


        for the service=
 provider.  Infrequent node mobility coupled with

        application int=
elligence suggest that mobility support could be


        provided select=
ively
such as in [I-D.bhandari-dhc-class-based-


        prefi=
x] and [I-D.korhonen-6man-prefix-properties], thus reducing


        the amount of c=
ontext maintained in the network.


 










 


















--_000_6E31144C030982429702B11D6746B98C370DD1D8szxeml557mbschi_--

From Peter.McCann@huawei.com  Fri Nov 15 12:13:28 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29A2311E815C for ; Fri, 15 Nov 2013 12:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTTF3+DaaEUN for ; Fri, 15 Nov 2013 12:13:22 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4D85C21F9D15 for ; Fri, 15 Nov 2013 12:13:22 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAI58751; Fri, 15 Nov 2013 20:13:21 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 20:12:57 +0000
Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 20:13:20 +0000
Received: from dfweml511-mbs.china.huawei.com ([169.254.15.141]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 12:13:14 -0800
From: Peter McCann 
To: "Sri Gundavelli (sgundave)" , Marco Liebsch 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: Ac7Y3bqUR0J96RB8SmOZDtKQ9LtNUZoUE9cAgABImwCAAQY4gIAAASiAgABd6ICAABT2rIAAGTgAgAKCNYCAABNZAIAByxEAgAEHGQCAABsyAIAAAfoAgAM2QQCAAAZaAIAAAnoAgAAfUgCAAAWgAIAAOa4AgAEQvoCAAtigQOXtwbUAgAACenCAAKb1AP/+plGw
Date: Fri, 15 Nov 2013 20:13:12 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE717949163@dfweml511-mbs.china.huawei.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948D75@dfweml511-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.125.141]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Nov 2013 20:13:28 -0000

Hi, Sri,


Sri Gundavelli (sgundave) wrote:
> Hi Pete,
>=20
>=20
> My definition of CP is between the AG and the MA, what is out there
> today.=20

The "control plane" is an abstract term for a collection of entities,
one of which exists in each AG and MA.

> Now, if there is a functional split of CP and DP on any entity,
> and if there is a interface between those two in the form of some CP
> interface, then I don't have a term for that interface. We can probably
> agree that CP/DP split approaches are outside the scope of this
> discussions.

I would call that a CP-DP interface and I agree it's out of scope of
DMM.

In particular, PMIP is not a CP-DP interface protocol.

>> I can still have an SDN-style network with a separate controller
>> making policy decisions.
>=20
> Ok. I understand now. Only the DP is moved, but the session CP state
> is anchored on a central node ? I call that central node as a mobility
> anchor, now if that anchor is in the data path or not is one
> consideration. But, functionally, there is still a mobility anchor.

There can be (but does not have to be) a centralized control plane
element that has a global view of all the MNs currently attached
and keeps track of which MAG they are currently on.  From the point
of view of DMM, that's just an operational detail of a particular
deployment.  We certainly should not require the data plane traffic
to go through that node, and we should allow for mechanisms other
than tunneling to redirect packets to the new MAG after a mobility
event.  The centralized control plane (if it exists) can be involved
in setting up that redirection state, or a distributed routing=20
protocol can take care of it.

-Pete



>=20
>=20
>=20
>=20
> Regards
> Sri
>=20
>=20
>=20
> On 11/14/13 5:19 AM, "Peter McCann"  wrote:
>=20
>> Hi, Marco, Sri,
>>=20
>> I think that Marco's analysis works, in the sense that it places both
>> classes of solutions within a cohesive framework.  I am more doubtful,
>> however, that the two kinds of solutions would co-exist in the same
>> access network, as they both seem to implement a kind of local mobility
>> management.
>>=20
>> Yes, Sri, I think this is a "re-anchoring" if we define the anchor as
>> the point to which IP packets are delivered by the routing
>> infrastructure. I don't see why you say there is no control plane; I
>> can still have an SDN-style network with a separate controller making
>> policy decisions. It is true that there is no single router that
>> handles the user's traffic for the life of the IP session, but I
>> thought the point of DMM was to get rid of such scalability and fault
>> bottlenecks.
>>=20
>> I am a little confused as to what is your definition of a control
>> plane. It seems you apply this term to the LMA, but in today's specs
>> the LMA is a combined CP/DP entity.
>>=20
>> -Pete
>>=20
>> Sri Gundavelli (sgundave) wrote:
>>> Hi Marco,
>>>=20
>>>=20
>>>>=20
>>>> My intention is not to eliminate a tunnel that exists in any of the
>>>> tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM
>>>> primarily distributes topological anchor point for the MN's IP
>>>> address(es). Forget about the C-plane for now. Tunnels apply solely
>>>> below (well, towards access) such anchor. If we distribute them to an
>>>> extreme, they are placed on radio access points and the tunnel
>>>> disappears. Then we arrive at Pete's model. If anchor points are
>>>> somewhere above, say in the backhaul, the tunnel remains at least
>>>> between the anchor and some node in the access (network based
>>>> mobility mgmnt) or the MN (host based mobility
> mgmnt).
>>>=20
>>>=20
>>> Ok.
>>>=20
>>> Distributing topological anchor points at the access edge can be done
>>> today without any new standards extensions. This is more about
>>> deployment and selection of a gateway at the access edge. But, any
>>> time the MN moves and attaches to a different point in the network,
>>> that tunnel and the CP is expected to be there between the previous
>>> home- anchor and the current access-anchor. But, here, the proposals
>>> hide the tunnel (at the initial attachment point and what can be
>>> argued as a home link and which is fine), but when the MN moves the
>>> session is re- anchored to a different gateway with a churn in the
>>> routing infrastructure and with major impact to policy plane. So,
>>> there is no tunnel and there is no CP in this model.
>>>=20
>>>=20
>>>>=20
>>>> I think none of the proposals wants to discuss away the tunnels as
>>>> per MIP/PMIP. But above anchor level, regular routing applies to
>>>> plain data packets of the U-Plane. A key component for DMM, IMO,
>>>> is how to accomplish that routing towards the MN's current anchor
>>>> point, even if the anchored IP address is topologically incorrect.
>>>> To accomplish this, my intent is to not introduce tunnels above
>>>> anchor level. So, it's not about eliminating tunnels, but it is
>>>> about not introducing tunnels where never have been tunnels before
>>>> :-)
>>>=20
>>>=20
>>> :) If you can show this working without re-anchoring the session to a
>>> different gateway, then I will agree. You see this from the point of
>>> view of IP routing, but I'm looking for that subscriber session which
>>> I'm not able to find.
>>>=20
>>> Tunnels hide the topology and make that reachability work; it gives
>>> me a stable anchor point that my operator can manage my session.
>>>=20
>>>=20
>>> Regards
>>> Sri
>>>=20


From sgundave@cisco.com  Sun Nov 17 14:27:19 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8A611E81EB for ; Sun, 17 Nov 2013 14:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.991
X-Spam-Level: 
X-Spam-Status: No, score=-6.991 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_ASCII_ART_SPACINGc=0.833, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Huvnpr0ZTmie for ; Sun, 17 Nov 2013 14:27:14 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5111E80E3 for ; Sun, 17 Nov 2013 14:27:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=135279; q=dns/txt; s=iport; t=1384727232; x=1385936832; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=RDw5zwKI+rbdofD3DDYIw6Sl02AIyFUtm8kqOXac4Ro=; b=Rgj4rFr8VavjdmyCEYuS7TgRwPZh821n7E7vnzb+4RiWJ6/mqczTi6UT cp2ezx7x/mLRb+NklnqWXW3dlMvaDYeUiJ+sWZJ0Hxzs2JYXi0cX6p/+w 2HsuRnESkpvvg/SKSev6+dI04esRU2kJlB2JGLBPFMrTfOpVALpPf/uKC k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgwFAAZCiVKtJXG+/2dsb2JhbABZgkNEOFO/LoEQFnSCJQECBBgCAQIQOwQFAQICFQEIEQECAQIOCAsBBigRFAMGCAIEARIbh1QDDw23Uw2JOReMc4EfAQkBCgcBgQQlDAMDBgYEhCcDi0oCilmBa4EviyaFOIMogWgJFyI
X-IronPort-AV: E=Sophos;i="4.93,720,1378857600";  d="scan'208,217";a="285785979"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 17 Nov 2013 22:27:09 +0000
Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAHMR98r011397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Nov 2013 22:27:09 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 16:27:08 -0600
From: "Sri Gundavelli (sgundave)" 
To: h chan , "dmm@ietf.org" 
Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
Thread-Index: AQHO4+QmJlal5lHHLUm+Lx6MsJ7x3w==
Date: Sun, 17 Nov 2013 22:27:08 +0000
Message-ID: 
In-Reply-To: <6E31144C030982429702B11D6746B98C370CBC1C@szxeml557-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.212]
Content-Type: multipart/alternative; boundary="_000_CEAE6597E98DBsgundaveciscocom_"
MIME-Version: 1.0
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 17 Nov 2013 22:27:19 -0000

--_000_CEAE6597E98DBsgundaveciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Anthony,

Thanks for revising the draft. Following are some more comments on the docu=
ment. I'm not holding this document any more. What ever comments you can ad=
dress =85 or you can choose not to revise =85

Please see inline.

Regards
Sri


From: h chan >
Date: Wednesday, September 25, 2013 9:49 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt


Sri,

Thanks for the comments. We are replying under different sections in separa=
te emails.





Network Working Group                                      H. Chan (Ed.)
Internet-Draft                                 Huawei Technologies (more
Intended status: Informational                      co-authors on P. 17)
Expires: May 11, 2014                                             D. Liu
                                                            China Mobile
                                                                P. Seite
                                                                  Orange
                                                               H. Yokota
                                                                KDDI Lab
                                                             J. Korhonen
                                                          Renesas Mobile
                                                        November 7, 2013


            Requirements for Distributed Mobility Management
                     draft-ietf-dmm-requirements-10

Abstract

   This document defines the requirements for Distributed Mobility
   Management (DMM).  The hierarchical structure in traditional wireless
   networks has led primarily to centralized deployment models.  As some
   wireless networks are evolving away from the hierarchical structure,
   such as in moving the content delivery servers closer to the users, a
   distributed model for mobility management can be useful to them.



[Sri] Not sure, what the "hierarchical structure in traditional wireless" m=
eans.

There are two aspects here:


1.) There is the aspect of distributed mobility deployment model for all th=
e reasons that the document talks about

2.) There is the other aspect of hosting content servers closer to the subs=
criber


I'm not able to draw the relation between "moving content to the access" an=
d the shift from centralized to distributed model. I understand you want to=
 say today there are central anchors where subscriber sessions are hosted. =
All the traffic from the mobile node's is brought to the central location/a=
nchor for service enablement and including content access. An alternative m=
odel is to distribute the anchors, localize the traffic and enable the asso=
ciated services to local anchors. You may want to re-write the text if you =
want to get that right.







Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 RFC 2119
   [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Chan (Ed.), et al.        Expires May 11, 2014                  [Page 1]

Internet-Draft                  DMM-Reqs                   November 2013


   This Internet-Draft will expire on May 11, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



































Chan (Ed.), et al.        Expires May 11, 2014                  [Page 2]

Internet-Draft                  DMM-Reqs                   November 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  6
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Centralized versus distributed mobility management . . . . . .  7
     3.1.  Centralized mobility management  . . . . . . . . . . . . .  7
     3.2.  Distributed mobility management  . . . . . . . . . . . . .  8
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Distributed processing . . . . . . . . . . . . . . . . . . 11
     5.2.  Transparency to Upper Layers when needed . . . . . . . . . 11
     5.3.  IPv6 deployment  . . . . . . . . . . . . . . . . . . . . . 12
     5.4.  Existing mobility protocols  . . . . . . . . . . . . . . . 12
     5.5.  Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13
     5.6.  Security considerations  . . . . . . . . . . . . . . . . . 13
     5.7.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Co-authors and Contributors  . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17



























Chan (Ed.), et al.        Expires May 11, 2014                  [Page 3]

Internet-Draft                  DMM-Reqs                   November 2013


1.  Introduction

   In the past decade a fair number of mobility protocols have been
   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
   Although the protocols differ in terms of functions and associated
   message formats, they all employ a mobility anchor to allow a mobile
   node to remain reachable after it has moved to a different network.
   The anchor point, among other tasks, ensures connectivity by
   forwarding packets destined to, or sent from, the mobile node.  It is
   a centrally deployed mobility anchor in the sense that the deployed
   architectures today have a small number of these anchors and the
   traffic of millions of mobile nodes in an operator network are
   typically managed by the same anchor.

   Distributed mobility management (DMM) is an alternative to the above
   centralized deployment.  The background behind the interests to study
   DMM are primarily in the following.

   (1)  Mobile users are, more than ever, consuming Internet content;
        such traffic imposes new requirements on mobile core networks
        for data traffic delivery.  The presence of content providers
        closer to Internet Service Providers (ISP) network requires
        taking into account local Content Delivery Networks (CDNs) while
        providing mobility services.  Moreover, when the traffic demand
        exceeds available capacity, service providers need to implement
        new strategies such as selective IPv4 traffic offload (e.g.
        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
        alternative access networks (e.g.  WLAN) [Paper-
        Mobile.Data.Offloading].  A gateway selection mechanism also
        takes the user proximity into account within EPC [TS.29303].
        These mechanisms were not pursued in the past owing to charging
        and billing reasons.  Assigning a gateway anchor node from a
        visited network in roaming scenario has until recently been done
        and are limited to voice services only.  Charging and billing
        require solutions beyond the mobility protocol.



[Sri] Some valid points above. But, IMHO, its not organized correctly.

My only comment with this document is that this has text from multiple peop=
le with different goals, but is not organized poorly.


Reminds me of some SDO documents. There the document starts with a blank te=
mplate, every company spits a line or two and in no time, the document grow=
s like a monster, but there is no relation between two lines of text in the=
 same paragraph. No offense.




        Both traffic offloading and CDN mechanisms could benefit from
        the development of mobile architectures with fewer levels of
        routing hierarchy introduced into the data path by the mobility
        management system.  This trend towards so-called "flat networks"
        works best for direct communications among peers in the same
        geographical area.  Distributed mobility management in a truly
        flat mobile architecture would anchor the traffic closer to the
        point of attachment of the user.







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 4]

Internet-Draft                  DMM-Reqs                   November 2013


   (2)  Today's mobile networks present service providers with new
        challenges.  Mobility patterns indicate that mobile nodes often
        remain attached to the same point of attachment for considerable
        periods of time [Paper-Locating.User].  Specific IP mobility
        management support is not required for applications that launch
        and complete their sessions while the mobile node is connected
        to the same point of attachment.  However, currently, IP
        mobility support is designed for always-on operation,
        maintaining all parameters of the context for each mobile
        subscriber for as long as they are connected to the network.
        This can result in a waste of resources and unnecessary costs
        for the service provider.  Infrequent node mobility coupled with
        application intelligence suggest that mobility support could be
        provided selectively such as in [I-D.bhandari-dhc-class-based-
        prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
        the amount of context maintained in the network.




   In addition, considerations in the study of DMM are in the following.

   (1)  To optimize handovers from the perspective of mobile nodes, the
        base protocols have been extended to efficiently handle packet
        forwarding between the previous and new points of attachment.
        These extensions are necessary when applications have stringent
        requirements in terms of delay.  Notions of localization and
        distribution of local agents have been introduced to reduce
        signaling overhead at the centralized routing anchor point
        [Paper-Distributed.Centralized.Mobility].  Unfortunately, such
        protocols have not been deployed today.

   (2)  Most existing mobility protocols have not been designed for
        multiple-interface hosts which are capable to use multiple
        interfaces simultaneously.  Retrofitting the required
        functionality can result in an unnecessary increase in the
        protocol complexity.



RFC5648.

Not sure. I agree about the complexity. Any case, this is not a DMM require=
ment




   (3)  IP multicast support, including optimizations, have been
        introduced as an effective transport method for multimedia data
        delivery, but by "patching-up" procedure after completing the
        design of reference mobility protocol, leading to network
        inefficiency and non-optimal routing.



I dont understand this.



   The distributed mobility management (DMM) charter addresses two
   complementary aspects of mobility management procedures: the
   distribution of mobility anchors in the data-plane towards a more
   flat network and the selective activation/deactivation of mobility
   protocol support as an enabler to distributed mobility management.
   The former aims at positioning mobility anchors (e.g., HA, LMA)
   closer to the user; ideally, mobility agents could be collocated with



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 5]

Internet-Draft                  DMM-Reqs                   November 2013


   the first-hop router.  The latter, facilitated by the distribution of
   mobility anchors, identifies when mobility support must be activated
   and when sessions do not require mobility management support -- thus
   reducing the amount of state information that must be maintained in
   various mobility agents of the mobile network.  It can then avoid the
   unnecessary establishment of mechanisms to forward traffic from an
   old to a new mobility anchor.

   This document compares distributed mobility management with
   centralized mobility management in Section 3.  The problems that can
   be addressed with DMM are summarized in Section 4.  The mandatory
   requirements as well as the optional requirements are given in
   Section 5.  Finally, security considerations are discussed in Section
   6.

   The problem statement and the use cases [I-D.yokota-dmm-scenario] can
   be found in [Paper-Distributed.Mobility.Review].


2.  Conventions used in this document

2.1.  Terminology

   All the general mobility-related terms and their acronyms used in
   this document are to be interpreted as defined in the Mobile IPv6
   base specification [RFC6275], in the Proxy mobile IPv6 specification
   [RFC5213], and in Mobility Related Terminology [RFC3753].  These
   terms include the following: mobile node (MN), correspondent node
   (CN), and home agent (HA) as per [RFC6275]; local mobility anchor
   (LMA) and mobile access gateway (MAG) as per [RFC5213], and context
   as per [RFC3753].

   In addition, this draft introduces the following terms.

   Centrally deployed mobility anchors

      refer to the mobility management deployments in which there are
      very few mobility anchors and the traffic of millions of mobile
      nodes in an operator network are managed by the same anchor.

   Centralized mobility management

      makes use of centrally deployed mobility anchors.

   Distributed mobility management

      is not centralized so that traffic does not need to traverse
      centrally deployed mobility anchors.



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 6]

Internet-Draft                  DMM-Reqs                   November 2013


   Flat mobile network

      has few levels of routing hierarchy introduced into the data path
      by the mobility management system.




   Mobility context

      is the collection of information required to provide mobility
      management support for a given mobile node.



You can improve the terminology section



3.  Centralized versus distributed mobility management

   Mobility management functions may be implemented at different layers
   of the protocol stack.  At the IP (network) layer, mobility
   management can be client-based or network-based.

   An IP-layer mobility management protocol is typically based on the
   principle of distinguishing between session identifier and routing
   address and maintaining a mapping between the two.  In Mobile IP, the
   home address serves as the session identifier whereas the care-of-
   address (CoA) takes the role of the routing address.  The binding
   between these two is maintained at the home agent (mobility anchor).
   If packets addressed to the home address of a mobile node can be
   continuously delivered to the node, then all sessions using that home
   address are unaffected even though the routing address (CoA) changes.

   The next two subsections explain centralized and distributed mobility
   management functions in the network.

3.1.  Centralized mobility management

   In centralized mobility management, the mapping information between
   the session identifier and the locator IP address of a mobile node
   (MN) is kept at a single mobility anchor.  At the same time, packets
   destined to the MN are routed via this anchor.  In other words, such
   mobility management systems are centralized in both the control plane
   and the data plane (mobile node IP traffic).

   Many existing mobility management deployments make use of centralized
   mobility anchoring in a hierarchical network architecture, as shown
   in Figure 1.  Examples of such centralized mobility anchors are the
   home agent (HA) and local mobility anchor (LMA) in Mobile IPv6
   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.  Current
   cellular networks such as the Third Generation Partnership Project
   (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System
   (EPS) networks employ centralized mobility management too.  In
   particular, the Gateway GPRS Support Node (GGSN), Serving GPRS



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 7]

Internet-Draft                  DMM-Reqs                   November 2013


   Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP
   GPRS hierarchical network, and the Packet Data Network Gateway (P-GW)
   and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors
   in a hierarchy.


         3G GPRS                 3GPP EPS                MIP/PMIP
         +------+                +------+                +------+
         | GGSN |                | P-GW |                |HA/LMA|
         +------+                +------+                +------+
            /\                      /\                      /\
           /  \                    /  \                    /  \
          /    \                  /    \                  /    \
         /      \                /      \                /      \
        /        \              /        \              /        \
       /          \            /          \            /          \
      /            \          /            \          /            \
  +------+      +------+  +------+      +------+  +------+      +------+
  | SGSN |      | SGSN |  | S-GW |      | S-GW |  |MN/MAG|      |MN/MAG|
  +------+      +------+  +------+      +------+  +------+      +------+
     /\            /\
    /  \          /  \
   /    \        /    \
+---+  +---+  +---+  +---+
|RNC|  |RNC|  |RNC|  |RNC|
+---+  +---+  +---+  +---+

   Figure 1.  Centralized mobility management.

3.2.  Distributed mobility management

   Mobility management functions may also be distributed to multiple
   networks as shown in Figure 2, so that a mobile node in any of these
   networks may be served by a nearby mobility function (MF).


                    +------+  +------+  +------+  +------+
                    |  MF  |  |  MF  |  |  MF  |  |  MF  |
                    +------+  +------+  +------+  +------+
                                           |
                                         +----+
                                         | MN |
                                         +----+

   Figure 2.  Distributed mobility management.

   Mobility management may be partially or fully distributed
   [I-D.yokota-dmm-scenario].  In the former case only the data plane is



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 8]

Internet-Draft                  DMM-Reqs                   November 2013


   distributed, implicitly assuming separation of data and control
   planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion].
   Fully distributed mobility management implies that both the data
   plane and the control plane are distributed.  While mobility
   management can be distributed, it is not necessary for other
   functions such as subscription management, subscription database, and
   network access authentication to be similarly distributed.

   A distributed mobility management scheme for a flat mobile network of
   access nodes is proposed in [Paper-Distributed.Dynamic.Mobility].
   Its benefits over centralized mobility management are shown through
   simulations in [Paper-Distributed.Centralized.Mobility].  Moreover,
   the (re)use and extension of existing protocols in the design of both
   fully distributed mobility management [Paper-Migrating.Home.Agents]
   [Paper-Distributed.Mobility.SAE] and partially distributed mobility
   management [Paper-Distributed.Mobility.PMIP] [Paper-
   Distributed.Mobility.MIP] have been reported in the literature.
   Therefore, before designing new mobility management protocols for a
   future distributed architecture, it is recommended to first consider
   whether existing mobility management protocols can be extended.


4.  Problem Statement

   The problems that can be addressed with DMM are summarized in the
   following:

   PS1:  Non-optimal routes

         Routing via a centralized anchor often results in non-optimal
         routes, thereby increasing the end-to-end delay.  The problem
         is manifested, for example, when accessing a nearby server or
         servers of a Content Delivery Network (CDN), or when receiving
         locally available IP multicast or sending IP multicast packets.
         (Existing route optimization is only a host-based solution.  On
         the other hand, localized routing with PMIPv6 [RFC6705]
         addresses only a part of the problem where both the MN and the
         CN are located in the PMIP domain and attached to a MAG, and is
         not applicable when the CN is outside the PMIP domain or does
         not behave like an MN.)


You argue for optimized route when accessing a CDN server in the local netw=
ork. But you say that the localized routing schemes don't work when the CN =
is outside the PMIP domain. What is the point ? When the CN is outside the =
PMIP domain, where is optimized route possibility ?


So, PS1 is about optimized routing requirement in DMM. Even though the docu=
ment fails to make the case that the current models have an issue, I'm OK w=
ith optimized routing goal for DMM in general terms.





   PS2:  Divergence from other evolutionary trends in network
         architectures such as distribution of content delivery.



         Centralized mobility management can become non-optimal with a
         flat network architecture.




So, this is "non-optimizal" because traffic has to hit the central anchor ?=
 Is it not same as PS1 ? Please add few lines of text





Chan (Ed.), et al.        Expires May 11, 2014                  [Page 9]

Internet-Draft                  DMM-Reqs                   November 2013


   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN usually requires more concentrated
         resources in a centralized design, thus reducing scalability.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can increase scalability.



Its not scalable because it requires lot of "concentrated resources" ? But,=
 distributing them allows it to scale. Not very convincing argument



   PS4:  Single point of failure and attack

         Centralized anchoring designs may be more vulnerable to single
         points of failures and attacks than a distributed system.  The
         impact of a successful attack on a system with centralized
         mobility management can be far greater as well.




   PS5:  Unnecessary mobility support to nodes that do not need it

         IP mobility support is not always required, and not every
         parameter of mobility context is always used.  For example,
         some applications do not need a stable IP address during a
         handover to maintain session continuity.  Sometimes, the entire
         application session runs while the terminal does not change the
         point of attachment.  Besides, some sessions, e.g.  SIP-based
         sessions, can handle mobility at the application layer and
         hence do not need IP mobility support; it is then more
         efficient to deactivate IP mobility support for such sessions.



PS5 is about enabling mobility support only to clients that need it ?



   PS6:  (Related problem) Mobility signaling overhead with peer-to-peer
         communication

         Wasting resources when mobility signaling (e.g., maintenance of
         the tunnel, keep alive signaling, etc.) is not turned off for
         peer-to-peer communication.  Peer-to-peer communications have
         particular traffic patterns that often do not benefit from
         mobility support from the network.  Thus, the associated
         mobility support signaling (e.g., maintenance of the tunnel,
         keep alive signaling, etc.) wastes network resources for no
         application gain.


So, the problem is about signaling load in the network. You want to minimiz=
e the signaling load in the mobility network because of the Peer-to-Peer ap=
plication traffic ? Ok.



   PS7:  (Related problem) Deployment with multiple mobility solutions

         There are already many variants and extensions of MIP.
         Deployment of new mobility management solutions can be
         challenging, and debugging difficult, when they must co-exist
         with solutions already in the field.



You mean to say, "protocols" or "solutions" ?


So, this is a section on "Problem Statement". Why is this talking about a r=
equirement ?




Chan (Ed.), et al.        Expires May 11, 2014                 [Page 10]

Internet-Draft                  DMM-Reqs                   November 2013


   PS8:  Duplicate multicast traffic

         IP multicast distribution over architectures using IP mobility
         solutions (e.g., [RFC6224]) may lead to convergence of
         duplicated multicast subscriptions towards the downstream
         tunnel entity (e.g.  MAG in PMIPv6).  Concretely, when
         multicast subscription for individual mobile nodes is coupled
         with mobility tunnels (e.g.  PMIPv6 tunnel), duplicate
         multicast subscription(s) is prone to be received through
         different upstream paths.  This problem may also exist or be
         more severe in a distributed mobility environment.


5.  Requirements

   After comparing distributed mobility management against centralized
   deployment in Section 3, this section identifies the following
   requirements:

5.1.  Distributed processing

   REQ1:  Distributed processing

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic can avoid traversing single mobility anchor
          far from the optimal route.

          Motivation: This requirement is motivated by current trends in
          network evolution: (a) it is cost- and resource-effective to
          cache and distribute content by combining distributed mobility
          anchors with caching systems (e.g., CDN); (b) the
          significantly larger number of mobile nodes and flows call for
          improved scalability; (c) single points of failure are avoided
          in a distributed system; (d) threats against centrally
          deployed anchors, e.g., home agent and local mobility anchor,
          are mitigated in a distributed system.

   This requirement addresses the problems PS1, PS2, PS3, and PS4
   described in Section 4.

5.2.  Transparency to Upper Layers when needed

   REQ2:  Transparency to Upper Layers when needed

          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for
          example, when, upon change of point of attachment to the



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 11]

Internet-Draft                  DMM-Reqs                   November 2013


          network, an application flow cannot cope with a change in the
          IP address.  However, it is not always necessary to maintain a
          stable home IP address or prefix for every application or at
          all times for a mobile node.

          Motivation: The motivation of this requirement is to enable
          more efficient routing and more efficient use of network
          resources by selecting an IP address or prefix according to
          whether mobility support is needed and by not maintaining
          context at the mobility anchor when there is no such need.

   This requirement addresses the problem PS5 as well as the related
   problem PS6 stated in Section 4.

5.3.  IPv6 deployment

   REQ3:  IPv6 deployment

          DMM solutions SHOULD target IPv6 as the primary deployment
          environment and SHOULD NOT be tailored specifically to support
          IPv4, in particular in situations where private IPv4 addresses
          and/or NATs are used.

          Motivation: This requirement conforms to the general
          orientation of IETF work.  DMM deployment is foreseen in mid-
          to long-term horizon, when IPv6 is expected to be far more
          common than today.

   This requirement avoids the unnecessarily complexity in solving the
   problems in Section 4 for IPv4, which will not be able to use some of
   the IPv6-specific features.






5.4.  Existing mobility protocols

   REQ4:  Existing mobility protocols

          A DMM solution SHOULD first consider reusing and extending
          IETF-standardized protocols before specifying new protocols.

          Motivation: Reuse of existing IETF work is more efficient and
          less error-prone.

   This requirement attempts to avoid the need of new protocols
   development and therefore their potential problems of being time-
   consuming and error-prone.






Chan (Ed.), et al.        Expires May 11, 2014                 [Page 12]

Internet-Draft                  DMM-Reqs                   November 2013


5.5.  Co-existence

   REQ5:  Co-existence with deployed networks and hosts

          The DMM solution MUST be able to co-exist with existing
          network deployments and end hosts.  For example, depending on
          the environment in which DMM is deployed, DMM solutions may
          need to be compatible with other deployed mobility protocols
          or may need to co-exist with a network or mobile hosts/routers
          that do not support DMM protocols.  The mobile node may also
          move between different access networks, where some of them may
          support neither DMM nor another mobility protocol.
          Furthermore, a DMM solution SHOULD work across different
          networks, possibly operated as separate administrative
          domains, when allowed by the trust relationship between them.

          Motivation: (a) to preserve backwards compatibility so that
          existing networks and hosts are not affected and continue to
          function as usual, and (b) enable inter-domain operation if
          desired.

   This requirement addresses the related problem PS7 described in
   Section 4.

5.6.  Security considerations

   REQ6:  Security considerations

          A DMM solution MUST not introduce new security risks or
          amplify existing security risks against which the existing
          security mechanisms/protocols cannot offer sufficient
          protection.

          Motivation: Various attacks such as impersonation, denial of
          service, man-in-the-middle attacks, and so on, may be launched
          in a DMM deployment.  For instance, an illegitimate node may
          attempt to access a network providing DMM.  Another example is
          that a malicious node can forge a number of signaling messages
          thus redirecting traffic from its legitimate path.
          Consequently, the specific node is under a denial of service
          attack, whereas other nodes do not receive their traffic.
          Accordingly, security mechanisms/protocols providing access
          control, integrity, authentication, authorization,
          confidentiality, etc. can be used to protect the DMM entities
          as they are already used to protect against existing networks
          and existing mobility protocols defined in IETF.

   This requirement prevents a DMM solution from introducing



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 13]

Internet-Draft                  DMM-Reqs                   November 2013


   uncontrollable problems of potentially insecure mobility management
   protocols which make deployment infeasible because platforms
   conforming to the protocols are at risk for data loss and numerous
   other dangers, including financial harm to the users.






5.7.  Multicast

   REQ7:  Multicast considerations

          DMM SHOULD consider multicast early so that solutions can be
          developed not only to provide IP mobility support when it is
          needed, but also to avoid network inefficiency issues in
          multicast traffic delivery (such as duplicate multicast
          subscriptions towards the downstream tunnel entities).  The
          multicast solutions should therefore avoid restricting the
          management of all IP multicast traffic to a single host
          through a dedicated (tunnel) interface on multicast-capable
          access routers.

          Motivation: Existing multicast deployment have been introduced
          after completing the design of the reference mobility
          protocol, then optimization and extensions have been followed
          by "patching-up" procedure, thus leading to network
          inefficiency and non-optimal routing.  The multicast solutions
          should therefore be required to consider efficiency nature in
          multicast traffic delivery.


[Sri] Considering multicast at a design phase is not technical requirement =
for DMM.

What is "patching up" procedure ?




   This requirement addresses the problems PS1 and PS8 described in
   Section 4.


6.  Security Considerations

   Please refer to the discussion under Security requirement in Section
   5.6.


7.  IANA Considerations

   None


8.  Co-authors and Contributors

   This problem statement document is a joint effort among the numerous
   participants.  Each individual has made significant contributions to
   this work and have been listed as co-authors.




Chan (Ed.), et al.        Expires May 11, 2014                 [Page 14]

Internet-Draft                  DMM-Reqs                   November 2013


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [I-D.bhandari-dhc-class-based-prefix]
              Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,
              Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
              based prefix", draft-bhandari-dhc-class-based-prefix-05
              (work in progress), July 2013.

   [I-D.korhonen-6man-prefix-properties]
              Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
              Liu, "IPv6 Prefix Properties",
              draft-korhonen-6man-prefix-properties-02 (work in
              progress), July 2013.

   [I-D.wakikawa-netext-pmip-cp-up-separation]
              Wakikawa, R., Pazhyannur, R., and S. Gundavelli,
              "Separation of Control and User Plane for Proxy Mobile
              IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00
              (work in progress), July 2013.

   [I-D.yokota-dmm-scenario]
              Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case
              scenarios  for Distributed Mobility Management",
              draft-yokota-dmm-scenario-00 (work in progress),
              October 2010.

   [Paper-Distributed.Centralized.Mobility]
              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              or Centralized Mobility",  Proceedings of Global
              Communications Conference  (GlobeCom), December 2009.

   [Paper-Distributed.Dynamic.Mobility]
              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              Dynamic Mobility Management Scheme  Designed for Flat IP
              Architectures",  Proceedings of 3rd International
              Conference  on New Technologies, Mobility and Security
              (NTMS), 2008.

   [Paper-Distributed.Mobility.MIP]
              Chan, H., "Distributed Mobility Management with Mobile
              IP",  Proceedings of  IEEE International Communication



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 15]

Internet-Draft                  DMM-Reqs                   November 2013


              Conference (ICC)  Workshop on Telecommunications:  from
              Research to Standards, June 2012.

   [Paper-Distributed.Mobility.PMIP]
              Chan, H., "Proxy Mobile IP  with Distributed Mobility
              Anchors",  Proceedings of GlobeCom Workshop  on Seamless
              Wireless Mobility, December 2010.

   [Paper-Distributed.Mobility.Review]
              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
              "Distributed and Dynamic Mobility Management  in Mobile
              Internet: Current Approaches and Issues, Journal of
              Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.",
               Proceedings of GlobeCom Workshop  on Seamless Wireless
              Mobility, February 2011.

   [Paper-Distributed.Mobility.SAE]
              Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M.
              Schlager, "A Distributed IP Mobility Approach for 3G SAE",
               Proceedings of the 19th International Symposium  on
              Personal, Indoor and Mobile Radio Communications (PIMRC),
              2008.

   [Paper-Locating.User]
              Kirby, G., "Locating the User",  Communication
              International, 1995.

   [Paper-Migrating.Home.Agents]
              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
              Agents  Towards Internet-scale Mobility Deployments",
               Proceedings of the ACM 2nd CoNEXT Conference  on Future
              Networking Technologies, December 2006.

   [Paper-Mobile.Data.Offloading]
              Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile
              Data Offloading: How Much Can WiFi Deliver?",  SIGCOMM
              2010, 2010.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.




Chan (Ed.), et al.        Expires May 11, 2014                 [Page 16]

Internet-Draft                  DMM-Reqs                   November 2013


   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",
              RFC 5944, November 2010.

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6301]  Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility
              Support in the Internet", RFC 6301, July 2011.

   [RFC6705]  Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6",
              RFC 6705, September 2012.

   [RFC6909]  Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.
              Koodli, "IPv4 Traffic Offload Selector Option for Proxy
              Mobile IPv6", RFC 6909, April 2013.

   [TS.23.401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013.

   [TS.29303]
              3GPP, "Domain Name System Procedures; Stage 3", 3GPP
              TR 23.303 11.2.0, September 2012.


Authors' Addresses

   H Anthony Chan (editor)
   Huawei Technologies (more co-authors on P. 17)
   5340 Legacy Dr. Building 3, Plano, TX 75024, USA
   Email: h.a.chan@ieee.org


   Dapeng Liu
   China Mobile
   Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
   Email: liudapeng@chinamobile.com








Chan (Ed.), et al.        Expires May 11, 2014                 [Page 17]

Internet-Draft                  DMM-Reqs                   November 2013


   Pierrick Seite
   Orange
   4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France
   Email: pierrick.seite@orange.com


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan
   Email: yokota@kddilabs.jp


   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24, FIN-00180 Helsinki, Finland
   Email: jouni.korhonen@nsn.com
   -
   Charles E. Perkins
   Huawei Technologies
   Email: charliep@computer.org
   -
   Melia Telemaco
   Alcatel-Lucent Bell Labs
   Email: telemaco.melia@alcatel-lucent.com
   -
   Elena Demaria
   Telecom Italia
   via G. Reiss Romoli, 274, TORINO, 10148, Italy
   Email: elena.demaria@telecomitalia.it
   -
   Jong-Hyouk Lee
   Sangmyung University
   Email: hurryon@gmail.com
   -
   Kostas Pentikousis
   EICT GmbH
   Email: k.pentikousis@eict.de
   -
   Tricci So
   ZTE
   Email: tso@zteusa.com
   -
   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30, Leganes, Madrid 28911, Spain
   Email: cjbc@it.uc3m.es
   -
   Peter McCann



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 18]

Internet-Draft                  DMM-Reqs                   November 2013


   Huawei Technologies
   Email: PeterMcCann@huawei.com
   -
   Seok Joo Koh
   Kyungpook National University, Korea
   Email: sjkoh@knu.ac.kr
   -
   Wen Luo
   ZTE
   No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China
   Email: luo.wen@zte.com.cn
   -
   Sri Gundavelli
   Cisco
   sgundave@cisco.com
   -
   Marco Liebsch
   NEC Laboratories Europe
   Email: liebsch@neclab.eu
   -
   Carl Williams
   MCSR Labs
   Email: carlw@mcsr-labs.org
   -
   Seil Jeon
   Instituto de Telecomunicacoes, Aveiro
   Email: seiljeon@av.it.pt
   -
   Sergio Figueiredo
   Universidade de Aveiro
   Email: sfigueiredo@av.it.pt
   -
   Stig Venaas
   Email: stig@venaas.com
   -
   Luis Miguel Contreras Murillo
   Telefonica I+D
   Email: lmcm@tid.es
   -
   Juan Carlos Zuniga
   InterDigital
   Email: JuanCarlos.Zuniga@InterDigital.com
   -
   Alexandru Petrescu
   Email: alexandru.petrescu@gmail.com
   -
   Georgios Karagiannis
   University of Twente



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 19]

Internet-Draft                  DMM-Reqs                   November 2013


   Email: g.karagiannis@utwente.nl
   -
   Julien Laganier
   Juniper
   jlaganier@juniper.net
   -
   Wassim Michel Haddad
   Ericsson
   Wassam.Haddad@ericsson.com
   -
   Dirk von Hugo
   Deutsche Telekom Laboratories
   Dirk.von-Hugo@telekom.de
   -
   Ahmad Muhanna
   Award Solutions
   amuhanna@awardsolutions.com
   -
   Byoung-Jo Kim
   ATT Labs
   macsbug@research.att.com
   -
   Hassan Ali-Ahmad
   Orange
   hassan.aliahmad@orange.com
   -
   Alper Yegin
   Samsung
   alper.yegin@partner.samsung.com
   -















--_000_CEAE6597E98DBsgundaveciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <1E12CAF20C076D4D95C248785F6BDB03@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable







Hi Anthony,







Thanks for revising the draft. Followi=
ng are some more comments on the document. I'm not holding this document an=
y more. What ever comments you can address =85 or you can choose not to rev=
ise =85







Please see inline.







Regards


Sri














From: h chan <h.anthony.chan@huawei.com>

Date: Wednesday, September 25, 2013=
 9:49 PM

To: Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>

Subject: RE: [DMM] I-D Action: draf=
t-ietf-dmm-requirements-07.txt

















 


Sri,


 


Thanks for the comments. We are re=
plying under different sections in separate emails.























Network Working Group                                      H. Chan (Ed.)
Internet-Draft                                 Huawei Technologies (more
Intended status: Informational                      co-authors on P. 17)
Expires: May 11, 2014                                             D. Liu
                                                            China Mobile
                                                                P. Seite
                                                                  Orange
                                                               H. Yokota
                                                                KDDI Lab
                                                             J. Korhonen
                                                          Renesas Mobile
                                                        November 7, 2013


            Requirements for Distributed Mobility Management
                     draft-ietf-dmm-requirements-10

Abstract

   This document defines the requirements for Distributed Mobility
   Management (DMM).  The hierarchical structure in traditional wireless
   networks has led primarily to centralized deployment models.  As some
   wireless networks are evolving away from the hierarchical structure,
   such as in moving the content delivery servers closer to the users, a
   distributed model for mobility management can be useful to them.






[Sri] Not sure, what the "hier=
archical structure in traditional wireless" means.


There are two aspects here:<=
/pre>




1.) There is the aspect of distribu=
ted mobility deployment model for all the reasons that the document talks a=
bout


2.) There is the other aspect of hosting content serv=
ers closer to the subscriber

<=
/pre>

I'm not able to draw the relation b=
etween "moving content to the access" and the shift from centrali=
zed to distributed model. I understand you want to say today there are cent=
ral anchors where subscriber sessions are hosted. All the traffic from the =
mobile node's is brought to the central location/anchor for service enablem=
ent and including content access. An alternative model is to distribute the=
 anchors, localize the traffic and enable the associated services to local =
anchors. You may want to re-write the text if you want to get that right.

















Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED&quo=
t;, "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", &qu=
ot;MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 RFC 2119
   [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Chan (Ed.), et al.        Expires May 11, 2014                  [Page 1]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   This Internet-Draft will expire on May 11, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



































Chan (Ed.), et al.        Expires May 11, 2014                  [Page 2]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  6
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Centralized versus distributed mobility management . . . . . .  7
     3.1.  Centralized mobility management  . . . . . . . . . . . . .  7
     3.2.  Distributed mobility management  . . . . . . . . . . . . .  8
   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Distributed processing . . . . . . . . . . . . . . . . . . 11
     5.2.  Transparency to Upper Layers when needed . . . . . . . . . 11
     5.3.  IPv6 deployment  . . . . . . . . . . . . . . . . . . . . . 12
     5.4.  Existing mobility protocols  . . . . . . . . . . . . . . . 12
     5.5.  Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13
     5.6.  Security considerations  . . . . . . . . . . . . . . . . . 13
     5.7.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Co-authors and Contributors  . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17



























Chan (Ed.), et al.        Expires May 11, 2014                  [Page 3]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


1.  Introduction

   In the past decade a fair number of mobility protocols have been
   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].
   Although the protocols differ in terms of functions and associated
   message formats, they all employ a mobility anchor to allow a mobile
   node to remain reachable after it has moved to a different network.
   The anchor point, among other tasks, ensures connectivity by
   forwarding packets destined to, or sent from, the mobile node.  It is
   a centrally deployed mobility anchor in the sense that the deployed
   architectures today have a small number of these anchors and the
   traffic of millions of mobile nodes in an operator network are
   typically managed by the same anchor.

   Distributed mobility management (DMM) is an alternative to the above
   centralized deployment.  The background behind the interests to study
   DMM are primarily in the following.

   (1)  Mobile users are, more than ever, consuming Internet content;
        such traffic imposes new requirements on mobile core networks
        for data traffic delivery.  The presence of content providers
        closer to Internet Service Providers (ISP) network requires
        taking into account local Content Delivery Networks (CDNs) while
        providing mobility services.  Moreover, when the traffic demand
        exceeds available capacity, service providers need to implement
        new strategies such as selective IPv4 traffic offload (e.g.
        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
        alternative access networks (e.g.  WLAN) [Paper-
        Mobile.Data.Offloading].  A gateway selection mechanism also
        takes the user proximity into account within EPC [TS.29303].
        These mechanisms were not pursued in the past owing to charging
        and billing reasons.  Assigning a gateway anchor node from a
        visited network in roaming scenario has until recently been done
        and are limited to voice services only.  Charging and billing
        require solutions beyond the mobility protocol.






[Sri] Some valid points above=
. But, IMHO, its not organized correctly. 


My only comment wit=
h this document is that this has text from multiple people with different g=
oals, but is not organized poorly.





Reminds me of some =
SDO documents. There the document starts with a blank template, every compa=
ny spits a line or two and in no time, the document grows like a monster, b=
ut there is no relation between two lines of text in the same paragraph. No=
 offense.








        Both traffic offloading and CDN mechanisms could benefit from
        the development of mobile architectures with fewer levels of
        routing hierarchy introduced into the data path by the mobility
        management system.  This trend towards so-called "flat network=
s"
        works best for direct communications among peers in the same
        geographical area.  Distributed mobility management in a truly
        flat mobile architecture would anchor the traffic closer to the
        point of attachment of the user.







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 4]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   (2)  Today's mobile networks present service providers with new
        challenges.  Mobility patterns indicate that mobile nodes often
        remain attached to the same point of attachment for considerable
        periods of time [Paper-Locating.User].  Specific IP mobility
        management support is not required for applications that launch
        and complete their sessions while the mobile node is connected
        to the same point of attachment.  However, currently, IP
        mobility support is designed for always-on operation,
        maintaining all parameters of the context for each mobile
        subscriber for as long as they are connected to the network.
        This can result in a waste of resources and unnecessary costs
        for the service provider.  Infrequent node mobility coupled with
        application intelligence suggest that mobility support could be
        provided selectively such as in [I-D.bhandari-dhc-class-based-
        prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing
        the amount of context maintained in the network.






   In addition, considerations in the study of DMM are in the following.

   (1)  To optimize handovers from the perspective of mobile nodes, the
        base protocols have been extended to efficiently handle packet
        forwarding between the previous and new points of attachment.
        These extensions are necessary when applications have stringent
        requirements in terms of delay.  Notions of localization and
        distribution of local agents have been introduced to reduce
        signaling overhead at the centralized routing anchor point
        [Paper-Distributed.Centralized.Mobility].  Unfortunately, such
        protocols have not been deployed today.

   (2)  Most existing mobility protocols have not been designed for
        multiple-interface hosts which are capable to use multiple
        interfaces simultaneously.  Retrofitting the required
        functionality can result in an unnecessary increase in the
        protocol complexity.






RFC5648.


Not sure. I agree about the complexity. Any case, this is=
 not a DMM requirement








   (3)  IP multicast support, including optimizations, have been
        introduced as an effective transport method for multimedia data
        delivery, but by "patching-up" procedure after completing=
 the
        design of reference mobility protocol, leading to network
        inefficiency and non-optimal routing.






I dont understand this.





   The distributed mobility management (DMM) charter addresses two
   complementary aspects of mobility management procedures: the
   distribution of mobility anchors in the data-plane towards a more
   flat network and the selective activation/deactivation of mobility
   protocol support as an enabler to distributed mobility management.
   The former aims at positioning mobility anchors (e.g., HA, LMA)
   closer to the user; ideally, mobility agents could be collocated with



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 5]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   the first-hop router.  The latter, facilitated by the distribution of
   mobility anchors, identifies when mobility support must be activated
   and when sessions do not require mobility management support -- thus
   reducing the amount of state information that must be maintained in
   various mobility agents of the mobile network.  It can then avoid the
   unnecessary establishment of mechanisms to forward traffic from an
   old to a new mobility anchor.

   This document compares distributed mobility management with
   centralized mobility management in Section 3.  The problems that can
   be addressed with DMM are summarized in Section 4.  The mandatory
   requirements as well as the optional requirements are given in
   Section 5.  Finally, security considerations are discussed in Section
   6.

   The problem statement and the use cases [I-D.yokota-dmm-scenario] can
   be found in [Paper-Distributed.Mobility.Review].


2.  Conventions used in this document

2.1.  Terminology

   All the general mobility-related terms and their acronyms used in
   this document are to be interpreted as defined in the Mobile IPv6
   base specification [RFC6275], in the Proxy mobile IPv6 specification
   [RFC5213], and in Mobility Related Terminology [RFC3753].  These
   terms include the following: mobile node (MN), correspondent node
   (CN), and home agent (HA) as per [RFC6275]; local mobility anchor
   (LMA) and mobile access gateway (MAG) as per [RFC5213], and context
   as per [RFC3753].

   In addition, this draft introduces the following terms.

   Centrally deployed mobility anchors

      refer to the mobility management deployments in which there are
      very few mobility anchors and the traffic of millions of mobile
      nodes in an operator network are managed by the same anchor.

   Centralized mobility management

      makes use of centrally deployed mobility anchors.

   Distributed mobility management

      is not centralized so that traffic does not need to traverse
      centrally deployed mobility anchors.



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 6]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   Flat mobile network

      has few levels of routing hierarchy introduced into the data path
      by the mobility management system.








   Mobility context

      is the collection of information required to provide mobility
      management support for a given mobile node.






You can improve the terminology section



3.  Centralized versus distributed mobility management

   Mobility management functions may be implemented at different layers
   of the protocol stack.  At the IP (network) layer, mobility
   management can be client-based or network-based.

   An IP-layer mobility management protocol is typically based on the
   principle of distinguishing between session identifier and routing
   address and maintaining a mapping between the two.  In Mobile IP, the
   home address serves as the session identifier whereas the care-of-
   address (CoA) takes the role of the routing address.  The binding
   between these two is maintained at the home agent (mobility anchor).
   If packets addressed to the home address of a mobile node can be
   continuously delivered to the node, then all sessions using that home
   address are unaffected even though the routing address (CoA) changes.

   The next two subsections explain centralized and distributed mobility
   management functions in the network.

3.1.  Centralized mobility management

   In centralized mobility management, the mapping information between
   the session identifier and the locator IP address of a mobile node
   (MN) is kept at a single mobility anchor.  At the same time, packets
   destined to the MN are routed via this anchor.  In other words, such
   mobility management systems are centralized in both the control plane
   and the data plane (mobile node IP traffic).

   Many existing mobility management deployments make use of centralized
   mobility anchoring in a hierarchical network architecture, as shown
   in Figure 1.  Examples of such centralized mobility anchors are the
   home agent (HA) and local mobility anchor (LMA) in Mobile IPv6
   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.  Current
   cellular networks such as the Third Generation Partnership Project
   (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System
   (EPS) networks employ centralized mobility management too.  In
   particular, the Gateway GPRS Support Node (GGSN), Serving GPRS



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 7]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP
   GPRS hierarchical network, and the Packet Data Network Gateway (P-GW)
   and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors
   in a hierarchy.


         3G GPRS                 3GPP EPS                MIP/PMIP
         +------+                +------+                &#=
43;------+
         | GGSN |                | P-GW |                |HA/LMA|
         +------+                +------+                &#=
43;------+
            /\                      /\                      /\
           /  \                    /  \                    /  \
          /    \                  /    \                  /    \
         /      \                /      \                /      \
        /        \              /        \              /        \
       /          \            /          \            /          \
      /            \          /            \          /            \
  +------+      +------+  +------+      +------=
+  +------+      +------+
  | SGSN |      | SGSN |  | S-GW |      | S-GW |  |MN/MAG|      |MN/MAG|
  +------+      +------+  +------+      +------=
+  +------+      +------+
     /\            /\
    /  \          /  \
   /    \        /    \
+---+  +---+  +---+  +---+
|RNC|  |RNC|  |RNC|  |RNC|
+---+  +---+  +---+  +---+

   Figure 1.  Centralized mobility management.

3.2.  Distributed mobility management

   Mobility management functions may also be distributed to multiple
   networks as shown in Figure 2, so that a mobile node in any of these
   networks may be served by a nearby mobility function (MF).


                    +------+  +------+  +------+  &=
#43;------+
                    |  MF  |  |  MF  |  |  MF  |  |  MF  |
                    +------+  +------+  +------+  &=
#43;------+
                                           |
                                         +----+
                                         | MN |
                                         +----+

   Figure 2.  Distributed mobility management.

   Mobility management may be partially or fully distributed
   [I-D.yokota-dmm-scenario].  In the former case only the data plane is



Chan (Ed.), et al.        Expires May 11, 2014                  [Page 8]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   distributed, implicitly assuming separation of data and control
   planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion].
   Fully distributed mobility management implies that both the data
   plane and the control plane are distributed.  While mobility
   management can be distributed, it is not necessary for other
   functions such as subscription management, subscription database, and
   network access authentication to be similarly distributed.

   A distributed mobility management scheme for a flat mobile network of
   access nodes is proposed in [Paper-Distributed.Dynamic.Mobility].
   Its benefits over centralized mobility management are shown through
   simulations in [Paper-Distributed.Centralized.Mobility].  Moreover,
   the (re)use and extension of existing protocols in the design of both
   fully distributed mobility management [Paper-Migrating.Home.Agents]
   [Paper-Distributed.Mobility.SAE] and partially distributed mobility
   management [Paper-Distributed.Mobility.PMIP] [Paper-
   Distributed.Mobility.MIP] have been reported in the literature.
   Therefore, before designing new mobility management protocols for a
   future distributed architecture, it is recommended to first consider
   whether existing mobility management protocols can be extended.


4.  Problem Statement

   The problems that can be addressed with DMM are summarized in the
   following:

   PS1:  Non-optimal routes

         Routing via a centralized anchor often results in non-optimal
         routes, thereby increasing the end-to-end delay.  The problem
         is manifested, for example, when accessing a nearby server or
         servers of a Content Delivery Network (CDN), or when receiving
         locally available IP multicast or sending IP multicast packets.
         (Existing route optimization is only a host-based solution.  On
         the other hand, localized routing with PMIPv6 [RFC6705]
         addresses only a part of the problem where both the MN and the
         CN are located in the PMIP domain and attached to a MAG, and is
         not applicable when the CN is outside the PMIP domain or does
         not behave like an MN.)



You argue for optimized route when accessing a CDN server=
 in the local network. But you say that the localized routing schemes don't=
 work when the CN is outside the PMIP domain. What is the point ? When the =
CN is outside the PMIP domain, where is optimized route possibility ? =






So, PS1 is about optimized routing requirement in DMM. Ev=
en though the document fails to make the case that the current models have =
an issue, I'm OK with optimized routing goal for DMM in general terms.











   PS2:  Divergence from other evolutionary trends in network
         architectures such as distribution of content delivery.



         Centralized mobility management can become non-optimal with a
         flat network architecture.



So, this is "non-optimizal&q=
uot; because traffic has to hit the central anchor ? Is it not same as PS1 =
? Please add few lines of text





Chan (Ed.), et al.        Expires May 11, 2014                  [Page 9]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN usually requires more concentrated
         resources in a centralized design, thus reducing scalability.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can increase scalability.






Its not scalable because it requires lot of "concent=
rated resources" ? But, distributing them allows it to scale. Not very=
 convincing argument





   PS4:  Single point of failure and attack

         Centralized anchoring designs may be more vulnerable to single
         points of failures and attacks than a distributed system.  The
         impact of a successful attack on a system with centralized
         mobility management can be far greater as well.






   PS5:  Unnecessary mobility support to nodes that do not need it

         IP mobility support is not always required, and not every
         parameter of mobility context is always used.  For example,
         some applications do not need a stable IP address during a
         handover to maintain session continuity.  Sometimes, the entire
         application session runs while the terminal does not change the
         point of attachment.  Besides, some sessions, e.g.  SIP-based
         sessions, can handle mobility at the application layer and
         hence do not need IP mobility support; it is then more
         efficient to deactivate IP mobility support for such sessions.






PS5 is about enabling mobility support only to clients th=
at need it ?






   PS6:  (Related problem) Mobility signaling overhead with peer-to-peer
         communication

         Wasting resources when mobility signaling (e.g., maintenance of
         the tunnel, keep alive signaling, etc.) is not turned off for
         peer-to-peer communication.  Peer-to-peer communications have
         particular traffic patterns that often do not benefit from
         mobility support from the network.  Thus, the associated
         mobility support signaling (e.g., maintenance of the tunnel,
         keep alive signaling, etc.) wastes network resources for no
         application gain.



So, the problem is about signaling load in the network. <=
/font>Yo=
u want to minimize the signaling load in the mobility network because of th=
e Peer-to-Peer application traffic ? Ok.





   PS7:  (Related problem) Deployment with multiple mobility solutions

         There are already many variants and extensions of MIP.
         Deployment of new mobility management solutions can be
         challenging, and debugging difficult, when they must co-exist
         with solutions already in the field.




You mean to say, "protocols" or "solut=
ions" ? 

So, this is a section on "Problem Statement=
". Why is this talking about a requirement ?




Chan (Ed.), et al.        Expires May 11, 2014                 [Page 10]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   PS8:  Duplicate multicast traffic

         IP multicast distribution over architectures using IP mobility
         solutions (e.g., [RFC6224]) may lead to convergence of
         duplicated multicast subscriptions towards the downstream
         tunnel entity (e.g.  MAG in PMIPv6).  Concretely, when
         multicast subscription for individual mobile nodes is coupled
         with mobility tunnels (e.g.  PMIPv6 tunnel), duplicate
         multicast subscription(s) is prone to be received through
         different upstream paths.  This problem may also exist or be
         more severe in a distributed mobility environment.


5.  Requirements

   After comparing distributed mobility management against centralized
   deployment in Section 3, this section identifies the following
   requirements:

5.1.  Distributed processing

   REQ1:  Distributed processing

          IP mobility, network access and routing solutions provided by
          DMM MUST enable distributed processing for mobility management
          so that traffic can avoid traversing single mobility anchor
          far from the optimal route.

          Motivation: This requirement is motivated by current trends in
          network evolution: (a) it is cost- and resource-effective to
          cache and distribute content by combining distributed mobility
          anchors with caching systems (e.g., CDN); (b) the
          significantly larger number of mobile nodes and flows call for
          improved scalability; (c) single points of failure are avoided
          in a distributed system; (d) threats against centrally
          deployed anchors, e.g., home agent and local mobility anchor,
          are mitigated in a distributed system.

   This requirement addresses the problems PS1, PS2, PS3, and PS4
   described in Section 4.

5.2.  Transparency to Upper Layers when needed

   REQ2:  Transparency to Upper Layers when needed

          DMM solutions MUST provide transparent mobility support above
          the IP layer when needed.  Such transparency is needed, for
          example, when, upon change of point of attachment to the



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 11]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


          network, an application flow cannot cope with a change in the
          IP address.  However, it is not always necessary to maintain a
          stable home IP address or prefix for every application or at
          all times for a mobile node.

          Motivation: The motivation of this requirement is to enable
          more efficient routing and more efficient use of network
          resources by selecting an IP address or prefix according to
          whether mobility support is needed and by not maintaining
          context at the mobility anchor when there is no such need.

   This requirement addresses the problem PS5 as well as the related
   problem PS6 stated in Section 4.

5.3.  IPv6 deployment

   REQ3:  IPv6 deployment

          DMM solutions SHOULD target IPv6 as the primary deployment
          environment and SHOULD NOT be tailored specifically to support
          IPv4, in particular in situations where private IPv4 addresses
          and/or NATs are used.

          Motivation: This requirement conforms to the general
          orientation of IETF work.  DMM deployment is foreseen in mid-
          to long-term horizon, when IPv6 is expected to be far more
          common than today.

   This requirement avoids the unnecessarily complexity in solving the
   problems in Section 4 for IPv4, which will not be able to use some of
   the IPv6-specific features.












5.4.  Existing mobility protocols

   REQ4:  Existing mobility protocols

          A DMM solution SHOULD first consider reusing and extending
          IETF-standardized protocols before specifying new protocols.

          Motivation: Reuse of existing IETF work is more efficient and
          less error-prone.

   This requirement attempts to avoid the need of new protocols
   development and therefore their potential problems of being time-
   consuming and error-prone.






Chan (Ed.), et al.        Expires May 11, 2014                 [Page 12]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


5.5.  Co-existence

   REQ5:  Co-existence with deployed networks and hosts

          The DMM solution MUST be able to co-exist with existing
          network deployments and end hosts.  For example, depending on
          the environment in which DMM is deployed, DMM solutions may
          need to be compatible with other deployed mobility protocols
          or may need to co-exist with a network or mobile hosts/routers
          that do not support DMM protocols.  The mobile node may also
          move between different access networks, where some of them may
          support neither DMM nor another mobility protocol.
          Furthermore, a DMM solution SHOULD work across different
          networks, possibly operated as separate administrative
          domains, when allowed by the trust relationship between them.

          Motivation: (a) to preserve backwards compatibility so that
          existing networks and hosts are not affected and continue to
          function as usual, and (b) enable inter-domain operation if
          desired.

   This requirement addresses the related problem PS7 described in
   Section 4.

5.6.  Security considerations

   REQ6:  Security considerations

          A DMM solution MUST not introduce new security risks or
          amplify existing security risks against which the existing
          security mechanisms/protocols cannot offer sufficient
          protection.

          Motivation: Various attacks such as impersonation, denial of
          service, man-in-the-middle attacks, and so on, may be launched
          in a DMM deployment.  For instance, an illegitimate node may
          attempt to access a network providing DMM.  Another example is
          that a malicious node can forge a number of signaling messages
          thus redirecting traffic from its legitimate path.
          Consequently, the specific node is under a denial of service
          attack, whereas other nodes do not receive their traffic.
          Accordingly, security mechanisms/protocols providing access
          control, integrity, authentication, authorization,
          confidentiality, etc. can be used to protect the DMM entities
          as they are already used to protect against existing networks
          and existing mobility protocols defined in IETF.

   This requirement prevents a DMM solution from introducing



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 13]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   uncontrollable problems of potentially insecure mobility management
   protocols which make deployment infeasible because platforms
   conforming to the protocols are at risk for data loss and numerous
   other dangers, including financial harm to the users.












5.7.  Multicast

   REQ7:  Multicast considerations

          DMM SHOULD consider multicast early so that solutions can be
          developed not only to provide IP mobility support when it is
          needed, but also to avoid network inefficiency issues in
          multicast traffic delivery (such as duplicate multicast
          subscriptions towards the downstream tunnel entities).  The
          multicast solutions should therefore avoid restricting the
          management of all IP multicast traffic to a single host
          through a dedicated (tunnel) interface on multicast-capable
          access routers.

          Motivation: Existing multicast deployment have been introduced
          after completing the design of the reference mobility
          protocol, then optimization and extensions have been followed
          by "patching-up" procedure, thus leading to network
          inefficiency and non-optimal routing.  The multicast solutions
          should therefore be required to consider efficiency nature in
          multicast traffic delivery.



[Sri] Considering multicast at a design phase is not tech=
nical requirement for DMM.


What is "patching up" procedure ? 








   This requirement addresses the problems PS1 and PS8 described in
   Section 4.


6.  Security Considerations

   Please refer to the discussion under Security requirement in Section
   5.6.


7.  IANA Considerations

   None


8.  Co-authors and Contributors

   This problem statement document is a joint effort among the numerous
   participants.  Each individual has made significant contributions to
   this work and have been listed as co-authors.




Chan (Ed.), et al.        Expires May 11, 2014                 [Page 14]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

9.2.  Informative References

   [I-D.bhandari-dhc-class-based-prefix]
              Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,
              Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class
              based prefix", draft-bhandari-dhc-class-based-prefix-05
              (work in progress), July 2013.

   [I-D.korhonen-6man-prefix-properties]
              Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.
              Liu, "IPv6 Prefix Properties",
              draft-korhonen-6man-prefix-properties-02 (work in
              progress), July 2013.

   [I-D.wakikawa-netext-pmip-cp-up-separation]
              Wakikawa, R., Pazhyannur, R., and S. Gundavelli,
              "Separation of Control and User Plane for Proxy Mobile
              IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00
              (work in progress), July 2013.

   [I-D.yokota-dmm-scenario]
              Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use cas=
e
              scenarios  for Distributed Mobility Management",
              draft-yokota-dmm-scenario-00 (work in progress),
              October 2010.

   [Paper-Distributed.Centralized.Mobility]
              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              or Centralized Mobility",  Proceedings of Global
              Communications Conference  (GlobeCom), December 2009.

   [Paper-Distributed.Dynamic.Mobility]
              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed
              Dynamic Mobility Management Scheme  Designed for Flat IP
              Architectures",  Proceedings of 3rd International
              Conference  on New Technologies, Mobility and Security
              (NTMS), 2008.

   [Paper-Distributed.Mobility.MIP]
              Chan, H., "Distributed Mobility Management with Mobile
              IP",  Proceedings of  IEEE International Communication



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 15]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


              Conference (ICC)  Workshop on Telecommunications:  from
              Research to Standards, June 2012.

   [Paper-Distributed.Mobility.PMIP]
              Chan, H., "Proxy Mobile IP  with Distributed Mobility
              Anchors",  Proceedings of GlobeCom Workshop  on Seamless
              Wireless Mobility, December 2010.

   [Paper-Distributed.Mobility.Review]
              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,
              "Distributed and Dynamic Mobility Management  in Mobile
              Internet: Current Approaches and Issues, Journal of
              Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.",
               Proceedings of GlobeCom Workshop  on Seamless Wireless
              Mobility, February 2011.

   [Paper-Distributed.Mobility.SAE]
              Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M.
              Schlager, "A Distributed IP Mobility Approach for 3G SAE=
",
               Proceedings of the 19th International Symposium  on
              Personal, Indoor and Mobile Radio Communications (PIMRC),
              2008.

   [Paper-Locating.User]
              Kirby, G., "Locating the User",  Communication
              International, 1995.

   [Paper-Migrating.Home.Agents]
              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home
              Agents  Towards Internet-scale Mobility Deployments",
               Proceedings of the ACM 2nd CoNEXT Conference  on Future
              Networking Technologies, December 2006.

   [Paper-Mobile.Data.Offloading]
              Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobil=
e
              Data Offloading: How Much Can WiFi Deliver?",  SIGCOMM
              2010, 2010.

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology&qu=
ot;,
              RFC 3753, June 2004.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August=
 2008.

   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.
              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility
              Management", RFC 5380, October 2008.




Chan (Ed.), et al.        Expires May 11, 2014                 [Page 16]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised"=
;,
              RFC 5944, November 2010.

   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base
              Deployment for Multicast Listener Support in Proxy Mobile
              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Suppor=
t
              in IPv6", RFC 6275, July 2011.

   [RFC6301]  Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobili=
ty
              Support in the Internet", RFC 6301, July 2011.

   [RFC6705]  Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.
              Dutta, "Localized Routing for Proxy Mobile IPv6",
              RFC 6705, September 2012.

   [RFC6909]  Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.
              Koodli, "IPv4 Traffic Offload Selector Option for Proxy
              Mobile IPv6", RFC 6909, April 2013.

   [TS.23.401]
              3GPP, "General Packet Radio Service (GPRS) enhancements
              for Evolved Universal Terrestrial Radio Access Network
              (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013.

   [TS.29303]
              3GPP, "Domain Name System Procedures; Stage 3", 3GP=
P
              TR 23.303 11.2.0, September 2012.


Authors' Addresses

   H Anthony Chan (editor)
   Huawei Technologies (more co-authors on P. 17)
   5340 Legacy Dr. Building 3, Plano, TX 75024, USA
   Email: h.a.chan@ieee.org


   Dapeng Liu
   China Mobile
   Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China
   Email: liudapeng@chinamobile.com








Chan (Ed.), et al.        Expires May 11, 2014                 [Page 17]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   Pierrick Seite
   Orange
   4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France
   Email: pierrick.seite@orange.com


   Hidetoshi Yokota
   KDDI Lab
   2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan
   Email: yokota@kddilabs.jp


   Jouni Korhonen
   Renesas Mobile
   Porkkalankatu 24, FIN-00180 Helsinki, Finland
   Email: jouni.korhonen@nsn.com
   -
   Charles E. Perkins
   Huawei Technologies
   Email: charliep@computer.org
   -
   Melia Telemaco
   Alcatel-Lucent Bell Labs
   Email: telemaco.melia@alcatel-lucent.com
   -
   Elena Demaria
   Telecom Italia
   via G. Reiss Romoli, 274, TORINO, 10148, Italy
   Email: elena.demaria@telecomitalia.it
   -
   Jong-Hyouk Lee
   Sangmyung University
   Email: hurryon@gmail.com
   -
   Kostas Pentikousis
   EICT GmbH
   Email: k.pentikousis@eict.de
   -
   Tricci So
   ZTE
   Email: tso@zteusa.com
   -
   Carlos J. Bernardos
   Universidad Carlos III de Madrid
   Av. Universidad, 30, Leganes, Madrid 28911, Spain
   Email: cjbc@it.uc3m.es
   -
   Peter McCann



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 18]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   Huawei Technologies
   Email: PeterMcCann@huawei.com
   -
   Seok Joo Koh
   Kyungpook National University, Korea
   Email: sjkoh@knu.ac.kr
   -
   Wen Luo
   ZTE
   No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China
   Email: luo.wen@zte.com.cn
   -
   Sri Gundavelli
   Cisco
   sgundave@cisco.com
   -
   Marco Liebsch
   NEC Laboratories Europe
   Email: liebsch@neclab.eu
   -
   Carl Williams
   MCSR Labs
   Email: carlw@mcsr-labs.org
   -
   Seil Jeon
   Instituto de Telecomunicacoes, Aveiro
   Email: seiljeon@av.it.pt
   -
   Sergio Figueiredo
   Universidade de Aveiro
   Email: sfigueiredo@av.it.pt
   -
   Stig Venaas
   Email: stig@venaas.com
   -
   Luis Miguel Contreras Murillo
   Telefonica I+D
   Email: lmcm@tid.es
   -
   Juan Carlos Zuniga
   InterDigital
   Email: JuanCarlos.Zuniga@InterDigital.com
   -
   Alexandru Petrescu
   Email: alexandru.petrescu@gmail.com
   -
   Georgios Karagiannis
   University of Twente



Chan (Ed.), et al.        Expires May 11, 2014                 [Page 19]
=0C
Internet-Draft                  DMM-Reqs                   November 2013


   Email: g.karagiannis@utwente.nl
   -
   Julien Laganier
   Juniper
   jlaganier@juniper.net
   -
   Wassim Michel Haddad
   Ericsson
   Wassam.Haddad@ericsson.com
   -
   Dirk von Hugo
   Deutsche Telekom Laboratories
   Dirk.von-Hugo@telekom.de
   -
   Ahmad Muhanna
   Award Solutions
   amuhanna@awardsolutions.com
   -
   Byoung-Jo Kim
   ATT Labs
   macsbug@research.att.com
   -
   Hassan Ali-Ahmad
   Orange
   hassan.aliahmad@orange.com
   -
   Alper Yegin
   Samsung
   alper.yegin@partner.samsung.com
   -




















--_000_CEAE6597E98DBsgundaveciscocom_--

From sgundave@cisco.com  Sun Nov 17 17:22:04 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FE611E8101 for ; Sun, 17 Nov 2013 17:22:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id quUbr9l9-dNW for ; Sun, 17 Nov 2013 17:21:59 -0800 (PST)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 220EF11E80EA for ; Sun, 17 Nov 2013 17:21:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2890; q=dns/txt; s=iport; t=1384737719; x=1385947319; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IU1l/VboybJtkobwZyaKROvGS4AubinQeN9uYGRFSqM=; b=HEYOSgpnOJApUG2JASBc2K0+lPp1TR1EbJYwzy/4K8h7cnvjh1gLJnx3 TtK58ed6BQWyksKMB533ErTR/EFJjUoH9O6YxqInUb+wX2KvbN6xOHzHY KUZgh0a9QyFyF6ROFk73tuaiKQjWDx/BhAKtmWp3aHO2r2hCa58N4hyxs E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgkFABVriVKtJXHB/2dsb2JhbABZgwc4U78rgREWdIIsOj8SAQg2QiUCBAEJBAUJh3gNwTWOLgEBgTkCBYQxA5gQkg2DKIFxOQ
X-IronPort-AV: E=Sophos;i="4.93,720,1378857600"; d="scan'208";a="285797321"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 18 Nov 2013 01:21:59 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAI1LwHq000660 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 01:21:58 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 19:21:58 -0600
From: "Sri Gundavelli (sgundave)" 
To: Marco Liebsch , Peter McCann 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO4/ySMbtoHxXoFU2lz0O+EaSnrg==
Date: Mon, 18 Nov 2013 01:21:57 +0000
Message-ID: 
In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D6375FA41@Hydra.office.hd>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.212]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Nov 2013 01:22:04 -0000

Hi Marco,



On 11/15/13 1:56 AM, "Marco Liebsch"  wrote:

>
>Depends. I assume that the session you describe is a mobility session
>(binding ID-Locator),
>not a data session. If the mobility session remains anchored at the
>previous attachment point,
>there will be a tunnel towards the new attachment point, which may serve
>as MAG. Optionally, the new attachment point may provide a new anchor and
>an additional
>mobility session, hence an additional HoA, which depend on the MN to
>handle multiple
>IPs. Other approach would imply moving the MN's mobility session from the
>previous anchor/point of attachment
>to the new one. Then there is at least no tunnel needed to forward
>packets from the previous
>anchor to the new one. But the anchored HoA or HNP at the new anchor is
>topologically
>incorrect. That means the routing plane above anchors can take care about
>delivering
>downlink packets to the MN's current anchor. Agree that that's an impact
>to the routing policy
>plane, but a valid approach to achieve more optimal routes.



Dated: 01/Aug/2011, reflecting our progress.

http://www.ietf.org/mail-archive/web/mext/current/msg04766.html

IMO, one can realize DMM by the the ways of a.) Adopting improved Gateway
Selection approaches b.) Carrying property meta-data in PIO options and
evolving the client.
Additionally, aggregating the control plane and distribute the DP is
another consideration. With this, one can realize a flat network with
optimized data plane.

We can get there with incremental extensions to the current protocols.
With the approach of allocating short lived sessions, can we not avoid
session re-anchoring and avoid impact to data plane ?


Will this work ?



>
>Without re-anchoring the previous mobility session at the new anchor means
>the previous anchor remains involved in the packet delivery. I was
>talking about
>the case where the previous mobility session will be transferred and
>anchored at the new
>mobility anchor. Only that enables short delivery paths, as the anchor
>points of the
>MN's IP address is close to the MN. But in that case the routing plane
>needs
>to support packet delivery for that MN. So, either by introducing tunnels
>in the
>routing plane (e.g. according to LISP), which I'd like to avoid. Or by
>using per-host routes.
>Or by using address translation to a routable address, which delivers the
>packet
>to the mobile's current anchor.


But, if the approach is to allocate short lived sessions, then why deal
with re-anchoring issue ? We can completely avoid RIB impact, avoid host
route pollution, or exporting modified locator Id to EID mapping. The
non-optimized DP lives there for a very short period after a MN migration
and for certain sessions and for reasons of global reachability.


Regards
Sri


From sgundave@cisco.com  Sun Nov 17 17:29:54 2013
Return-Path: 
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF6C11E8105 for ; Sun, 17 Nov 2013 17:29:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.795
X-Spam-Level: 
X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[AWL=-2.196, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEzSBWUV-+Ge for ; Sun, 17 Nov 2013 17:29:48 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 62A4F11E8101 for ; Sun, 17 Nov 2013 17:29:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1100; q=dns/txt; s=iport; t=1384738188; x=1385947788; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8iJQhZOnfYic2Ud2K10ji5wtG7h7jVp4c7r4WMfCWGI=; b=FWfq/KhYxFYwr/s+JeLSskUxGbvUvH6shhqNRl3Dh9JudSCx2GuqPgI4 St39f0nB2yFEtYEZA18eEoXdxzHjFrVqr994wfGGkfh5WWHkOLSbiWit5 IazTHQtKmlKiQB8ukImOo+KM3IAKm/g/bI8H8dZN7zFkvIc7DKb65Pdyp M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AggFAEFsiVKtJXG8/2dsb2JhbABZgweBC78rgREWdIIlAQEBBDo/EgEIGB5CJQIEAQ0FG4dmwSwXj2kHhDEDmBCSDYMogio
X-IronPort-AV: E=Sophos;i="4.93,720,1378857600";  d="scan'208";a="215540"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by alln-iport-7.cisco.com with ESMTP; 18 Nov 2013 01:29:47 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAI1Tll8000782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 01:29:47 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 19:29:47 -0600
From: "Sri Gundavelli (sgundave)" 
To: Peter McCann , Marco Liebsch 
Thread-Topic: Preparing for DMM future steps and rechartering
Thread-Index: AQHO4/2qMbtoHxXoFU2lz0O+EaSnrg==
Date: Mon, 18 Nov 2013 01:29:47 +0000
Message-ID: 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE717949163@dfweml511-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.212]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <71AB95FB1142394688B9CF064931E220@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and rechartering
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 18 Nov 2013 01:29:54 -0000

Hi Pete,


On 11/15/13 12:13 PM, "Peter McCann"  wrote:
>
>There can be (but does not have to be) a centralized control plane
>element that has a global view of all the MNs currently attached
>and keeps track of which MAG they are currently on.  From the point
>of view of DMM, that's just an operational detail of a particular
>deployment.  We certainly should not require the data plane traffic
>to go through that node, and we should allow for mechanisms other
>than tunneling to redirect packets to the new MAG after a mobility
>event.  The centralized control plane (if it exists) can be involved
>in setting up that redirection state, or a distributed routing
>protocol can take care of it.


The goal of shifting / stitching the flows on the forward path that we
choose sounds perfectly fine from the view of realizing optimized data
plane. But, we still have to show how an operator can manage the
subscriber session and enforce the policies. Without such considerations,
we cannot meaningfully evaluate the solution, IMHO




Regards
Sri


From h.anthony.chan@huawei.com  Tue Nov 19 18:12:18 2013
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 9BA6B1AE26F for ; Tue, 19 Nov 2013 18:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.425
X-Spam-Level: 
X-Spam-Status: No, score=-1.425 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 eoDiHm1ivk3y for ; Tue, 19 Nov 2013 18:11:56 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 997371AE2CF for ; Tue, 19 Nov 2013 18:11:54 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYC19544; Wed, 20 Nov 2013 02:11:47 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 02:11:35 +0000
Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 02:11:41 +0000
Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 10:11:37 +0800
From: h chan 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
Thread-Index: AQHO4+QmJlal5lHHLUm+Lx6MsJ7x35otWlgA
Date: Wed, 20 Nov 2013 02:11:36 +0000
Message-ID: <6E31144C030982429702B11D6746B98C370E6FAE@szxeml557-mbx.china.huawei.com>
References: <6E31144C030982429702B11D6746B98C370CBC1C@szxeml557-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.232]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370E6FAEszxeml557mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
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, 20 Nov 2013 02:12:18 -0000

--_000_6E31144C030982429702B11D6746B98C370E6FAEszxeml557mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Sri,
Suggested revisions are shown in blue below.
Not sure about what improvements are desired for the definitions though.

H Anthony Chan

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Sunday, November 17, 2013 4:27 PM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Hi Anthony,

Thanks for revising the draft. Following are some more comments on the docu=
ment. I'm not holding this document any more. What ever comments you can ad=
dress ... or you can choose not to revise ...

Please see inline.

Regards
Sri


From: h chan >
Date: Wednesday, September 25, 2013 9:49 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt


Sri,

Thanks for the comments. We are replying under different sections in separa=
te emails.







Network Working Group                                      H. Chan (Ed.)

Internet-Draft                                 Huawei Technologies (more

Intended status: Informational                      co-authors on P. 17)

Expires: May 11, 2014                                             D. Liu

                                                            China Mobile

                                                                P. Seite

                                                                  Orange

                                                               H. Yokota

                                                                KDDI Lab

                                                             J. Korhonen

                                                          Renesas Mobile

                                                        November 7, 2013





            Requirements for Distributed Mobility Management

                     draft-ietf-dmm-requirements-10



Abstract



   This document defines the requirements for Distributed Mobility

   Management (DMM).  The hierarchical structure in traditional wireless

   networks has led primarily to centralized deployment models.  As some

   wireless networks are evolving away from the hierarchical structure,

   such as in moving the content delivery servers closer to the users, a

   distributed model for mobility management can be useful to them.





[Sri] Not sure, what the "hierarchical structure in traditional wireless" m=
eans.

There are two aspects here:



1.) There is the aspect of distributed mobility deployment model for all th=
e reasons that the document talks about

2.) There is the other aspect of hosting content servers closer to the subs=
criber



I'm not able to draw the relation between "moving content to the access" an=
d the shift from centralized to distributed model. I understand you want to=
 say today there are central anchors where subscriber sessions are hosted. =
All the traffic from the mobile node's is brought to the central location/a=
nchor for service enablement and including content access. An alternative m=
odel is to distribute the anchors, localize the traffic and enable the asso=
ciated services to local anchors. You may want to re-write the text if you =
want to get that right.



Let us delete "such as in moving the content delivery servers closer to the=
 users,"

Then the abstract becomes:

Abstract



   This document defines the requirements for Distributed Mobility

   Management (DMM).  The hierarchical structure in traditional wireless

   networks has led primarily to centralized deployment models.  As some

   wireless networks are evolving away from the hierarchical structure,

   a

   distributed model for mobility management can be useful to them.











Requirements Language



   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   document are to be interpreted as described in RFC 2119 RFC 2119

   [RFC2119].



Status of this Memo



   This Internet-Draft is submitted in full conformance with the

   provisions of BCP 78 and BCP 79.



   Internet-Drafts are working documents of the Internet Engineering

   Task Force (IETF).  Note that other groups may also distribute

   working documents as Internet-Drafts.  The list of current Internet-

   Drafts is at http://datatracker.ietf.org/drafts/current/.



   Internet-Drafts are draft documents valid for a maximum of six months

   and may be updated, replaced, or obsoleted by other documents at any

   time.  It is inappropriate to use Internet-Drafts as reference

   material or to cite them other than as "work in progress."









Chan (Ed.), et al.        Expires May 11, 2014                  [Page 1]



Internet-Draft                  DMM-Reqs                   November 2013





   This Internet-Draft will expire on May 11, 2014.



Copyright Notice



   Copyright (c) 2013 IETF Trust and the persons identified as the

   document authors.  All rights reserved.



   This document is subject to BCP 78 and the IETF Trust's Legal

   Provisions Relating to IETF Documents

   (http://trustee.ietf.org/license-info) in effect on the date of

   publication of this document.  Please review these documents

   carefully, as they describe your rights and restrictions with respect

   to this document.  Code Components extracted from this document must

   include Simplified BSD License text as described in Section 4.e of

   the Trust Legal Provisions and are provided without warranty as

   described in the Simplified BSD License.







































































Chan (Ed.), et al.        Expires May 11, 2014                  [Page 2]



Internet-Draft                  DMM-Reqs                   November 2013





Table of Contents



   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Conventions used in this document  . . . . . . . . . . . . . .  6

     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Centralized versus distributed mobility management . . . . . .  7

     3.1.  Centralized mobility management  . . . . . . . . . . . . .  7

     3.2.  Distributed mobility management  . . . . . . . . . . . . .  8

   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  9

   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11

     5.1.  Distributed processing . . . . . . . . . . . . . . . . . . 11

     5.2.  Transparency to Upper Layers when needed . . . . . . . . . 11

     5.3.  IPv6 deployment  . . . . . . . . . . . . . . . . . . . . . 12

     5.4.  Existing mobility protocols  . . . . . . . . . . . . . . . 12

     5.5.  Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13

     5.6.  Security considerations  . . . . . . . . . . . . . . . . . 13

     5.7.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 14

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

   8.  Co-authors and Contributors  . . . . . . . . . . . . . . . . . 14

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15

     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15

     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17























































Chan (Ed.), et al.        Expires May 11, 2014                  [Page 3]



Internet-Draft                  DMM-Reqs                   November 2013





1.  Introduction



   In the past decade a fair number of mobility protocols have been

   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].

   Although the protocols differ in terms of functions and associated

   message formats, they all employ a mobility anchor to allow a mobile

   node to remain reachable after it has moved to a different network.

   The anchor point, among other tasks, ensures connectivity by

   forwarding packets destined to, or sent from, the mobile node.  It is

   a centrally deployed mobility anchor in the sense that the deployed

   architectures today have a small number of these anchors and the

   traffic of millions of mobile nodes in an operator network are

   typically managed by the same anchor.



   Distributed mobility management (DMM) is an alternative to the above

   centralized deployment.  The background behind the interests to study

   DMM are primarily in the following.



   (1)  Mobile users are, more than ever, consuming Internet content;

        such traffic imposes new requirements on mobile core networks

        for data traffic delivery.  The presence of content providers

        closer to Internet Service Providers (ISP) network requires

        taking into account local Content Delivery Networks (CDNs) while

        providing mobility services.  Moreover, when the traffic demand

        exceeds available capacity, service providers need to implement

        new strategies such as selective IPv4 traffic offload (e.g.

        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through

        alternative access networks (e.g.  WLAN) [Paper-

        Mobile.Data.Offloading].  A gateway selection mechanism also

        takes the user proximity into account within EPC [TS.29303].

        These mechanisms were not pursued in the past owing to charging

        and billing reasons.  Assigning a gateway anchor node from a

        visited network in roaming scenario has until recently been done

        and are limited to voice services only.  Charging and billing

        require solutions beyond the mobility protocol.





[Sri] Some valid points above. But, IMHO, its not organized correctly.

My only comment with this document is that this has text from multiple peop=
le with different goals, but is not organized poorly.



Reminds me of some SDO documents. There the document starts with a blank te=
mplate, every company spits a line or two and in no time, the document grow=
s like a monster, but there is no relation between two lines of text in the=
 same paragraph. No offense.



Rearrange as follows:


   (1)  Mobile users are, more than ever, consuming Internet content
        including that of local Content Delivery Networks (CDNs) which
        had not taken mobility service into account before.  Such
        traffic imposes new requirements on mobile core networks for
        data traffic delivery.  To prevent exceeding the available core
        network capacity, service providers need to implement new
        strategies such as selective IPv4 traffic offload (e.g.
        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
        alternative access networks (e.g.  WLAN) [Paper-
        Mobile.Data.Offloading].  In addition, a gateway selection
        mechanism takes the user proximity into account within EPC
        [TS.29303].  Yet these mechanisms were not pursued in the past
        owing to charging and billing which require solutions beyond the
        mobility protocol.  Consequently, assigning a gateway anchor
        node from a visited network in roaming scenario has until
        recently been done and are limited to voice services only.







        Both traffic offloading and CDN mechanisms could benefit from

        the development of mobile architectures with fewer levels of

        routing hierarchy introduced into the data path by the mobility

        management system.  This trend towards so-called "flat networks"

        works best for direct communications among peers in the same

        geographical area.  Distributed mobility management in a truly

        flat mobile architecture would anchor the traffic closer to the

        point of attachment of the user.















Chan (Ed.), et al.        Expires May 11, 2014                  [Page 4]



Internet-Draft                  DMM-Reqs                   November 2013





   (2)  Today's mobile networks present service providers with new

        challenges.  Mobility patterns indicate that mobile nodes often

        remain attached to the same point of attachment for considerable

        periods of time [Paper-Locating.User].  Specific IP mobility

        management support is not required for applications that launch

        and complete their sessions while the mobile node is connected

        to the same point of attachment.  However, currently, IP

        mobility support is designed for always-on operation,

        maintaining all parameters of the context for each mobile

        subscriber for as long as they are connected to the network.

        This can result in a waste of resources and unnecessary costs

        for the service provider.  Infrequent node mobility coupled with

        application intelligence suggest that mobility support could be

        provided selectively such as in [I-D.bhandari-dhc-class-based-

        prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing

        the amount of context maintained in the network.





Let us delete the following, which don't seem necessary. The requirements a=
lready have the problem statements to support them.

   In addition, considerations in the study of DMM are in the following.



   (1)  To optimize handovers from the perspective of mobile nodes, the

        base protocols have been extended to efficiently handle packet

        forwarding between the previous and new points of attachment.

        These extensions are necessary when applications have stringent

        requirements in terms of delay.  Notions of localization and

        distribution of local agents have been introduced to reduce

        signaling overhead at the centralized routing anchor point

        [Paper-Distributed.Centralized.Mobility].  Unfortunately, such

        protocols have not been deployed today.



   (2)  Most existing mobility protocols have not been designed for

        multiple-interface hosts which are capable to use multiple

        interfaces simultaneously.  Retrofitting the required

        functionality can result in an unnecessary increase in the

        protocol complexity.





RFC5648.

Not sure. I agree about the complexity. Any case, this is not a DMM require=
ment







   (3)  IP multicast support, including optimizations, have been

        introduced as an effective transport method for multimedia data

        delivery, but by "patching-up" procedure after completing the

        design of reference mobility protocol, leading to network

        inefficiency and non-optimal routing.





I dont understand this.





   The distributed mobility management (DMM) charter addresses two

   complementary aspects of mobility management procedures: the

   distribution of mobility anchors in the data-plane towards a more

   flat network and the selective activation/deactivation of mobility

   protocol support as an enabler to distributed mobility management.

   The former aims at positioning mobility anchors (e.g., HA, LMA)

   closer to the user; ideally, mobility agents could be collocated with







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 5]



Internet-Draft                  DMM-Reqs                   November 2013





   the first-hop router.  The latter, facilitated by the distribution of

   mobility anchors, identifies when mobility support must be activated

   and when sessions do not require mobility management support -- thus

   reducing the amount of state information that must be maintained in

   various mobility agents of the mobile network.  It can then avoid the

   unnecessary establishment of mechanisms to forward traffic from an

   old to a new mobility anchor.



   This document compares distributed mobility management with

   centralized mobility management in Section 3.  The problems that can

   be addressed with DMM are summarized in Section 4.  The mandatory

   requirements as well as the optional requirements are given in

   Section 5.  Finally, security considerations are discussed in Section

   6.



   The problem statement and the use cases [I-D.yokota-dmm-scenario] can

   be found in [Paper-Distributed.Mobility.Review].





2.  Conventions used in this document



2.1.  Terminology



   All the general mobility-related terms and their acronyms used in

   this document are to be interpreted as defined in the Mobile IPv6

   base specification [RFC6275], in the Proxy mobile IPv6 specification

   [RFC5213], and in Mobility Related Terminology [RFC3753].  These

   terms include the following: mobile node (MN), correspondent node

   (CN), and home agent (HA) as per [RFC6275]; local mobility anchor

   (LMA) and mobile access gateway (MAG) as per [RFC5213], and context

   as per [RFC3753].



   In addition, this draft introduces the following terms.



   Centrally deployed mobility anchors



      refer to the mobility management deployments in which there are

      very few mobility anchors and the traffic of millions of mobile

      nodes in an operator network are managed by the same anchor.



   Centralized mobility management



      makes use of centrally deployed mobility anchors.



   Distributed mobility management



      is not centralized so that traffic does not need to traverse

      centrally deployed mobility anchors.







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 6]



Internet-Draft                  DMM-Reqs                   November 2013





   Flat mobile network



      has few levels of routing hierarchy introduced into the data path

      by the mobility management system.







   Mobility context



      is the collection of information required to provide mobility

      management support for a given mobile node.





You can improve the terminology section

Not sure whether you want to better define these terms or whether some defi=
nitions are missing?



3.  Centralized versus distributed mobility management



   Mobility management functions may be implemented at different layers

   of the protocol stack.  At the IP (network) layer, mobility

   management can be client-based or network-based.



   An IP-layer mobility management protocol is typically based on the

   principle of distinguishing between session identifier and routing

   address and maintaining a mapping between the two.  In Mobile IP, the

   home address serves as the session identifier whereas the care-of-

   address (CoA) takes the role of the routing address.  The binding

   between these two is maintained at the home agent (mobility anchor).

   If packets addressed to the home address of a mobile node can be

   continuously delivered to the node, then all sessions using that home

   address are unaffected even though the routing address (CoA) changes.



   The next two subsections explain centralized and distributed mobility

   management functions in the network.



3.1.  Centralized mobility management



   In centralized mobility management, the mapping information between

   the session identifier and the locator IP address of a mobile node

   (MN) is kept at a single mobility anchor.  At the same time, packets

   destined to the MN are routed via this anchor.  In other words, such

   mobility management systems are centralized in both the control plane

   and the data plane (mobile node IP traffic).



   Many existing mobility management deployments make use of centralized

   mobility anchoring in a hierarchical network architecture, as shown

   in Figure 1.  Examples of such centralized mobility anchors are the

   home agent (HA) and local mobility anchor (LMA) in Mobile IPv6

   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.  Current

   cellular networks such as the Third Generation Partnership Project

   (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System

   (EPS) networks employ centralized mobility management too.  In

   particular, the Gateway GPRS Support Node (GGSN), Serving GPRS







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 7]



Internet-Draft                  DMM-Reqs                   November 2013





   Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP

   GPRS hierarchical network, and the Packet Data Network Gateway (P-GW)

   and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors

   in a hierarchy.





         3G GPRS                 3GPP EPS                MIP/PMIP

         +------+                +------+                +------+

         | GGSN |                | P-GW |                |HA/LMA|

         +------+                +------+                +------+

            /\                      /\                      /\

           /  \                    /  \                    /  \

          /    \                  /    \                  /    \

         /      \                /      \                /      \

        /        \              /        \              /        \

       /          \            /          \            /          \

      /            \          /            \          /            \

  +------+      +------+  +------+      +------+  +------+      +------+

  | SGSN |      | SGSN |  | S-GW |      | S-GW |  |MN/MAG|      |MN/MAG|

  +------+      +------+  +------+      +------+  +------+      +------+

     /\            /\

    /  \          /  \

   /    \        /    \

+---+  +---+  +---+  +---+

|RNC|  |RNC|  |RNC|  |RNC|

+---+  +---+  +---+  +---+



   Figure 1.  Centralized mobility management.



3.2.  Distributed mobility management



   Mobility management functions may also be distributed to multiple

   networks as shown in Figure 2, so that a mobile node in any of these

   networks may be served by a nearby mobility function (MF).





                    +------+  +------+  +------+  +------+

                    |  MF  |  |  MF  |  |  MF  |  |  MF  |

                    +------+  +------+  +------+  +------+

                                           |

                                         +----+

                                         | MN |

                                         +----+



   Figure 2.  Distributed mobility management.



   Mobility management may be partially or fully distributed

   [I-D.yokota-dmm-scenario].  In the former case only the data plane is







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 8]



Internet-Draft                  DMM-Reqs                   November 2013





   distributed, implicitly assuming separation of data and control

   planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion].

   Fully distributed mobility management implies that both the data

   plane and the control plane are distributed.  While mobility

   management can be distributed, it is not necessary for other

   functions such as subscription management, subscription database, and

   network access authentication to be similarly distributed.



   A distributed mobility management scheme for a flat mobile network of

   access nodes is proposed in [Paper-Distributed.Dynamic.Mobility].

   Its benefits over centralized mobility management are shown through

   simulations in [Paper-Distributed.Centralized.Mobility].  Moreover,

   the (re)use and extension of existing protocols in the design of both

   fully distributed mobility management [Paper-Migrating.Home.Agents]

   [Paper-Distributed.Mobility.SAE] and partially distributed mobility

   management [Paper-Distributed.Mobility.PMIP] [Paper-

   Distributed.Mobility.MIP] have been reported in the literature.

   Therefore, before designing new mobility management protocols for a

   future distributed architecture, it is recommended to first consider

   whether existing mobility management protocols can be extended.





4.  Problem Statement



   The problems that can be addressed with DMM are summarized in the

   following:



   PS1:  Non-optimal routes



         Routing via a centralized anchor often results in non-optimal

         routes, thereby increasing the end-to-end delay.  The problem

         is manifested, for example, when accessing a nearby server or

         servers of a Content Delivery Network (CDN), or when receiving

         locally available IP multicast or sending IP multicast packets.

         (Existing route optimization is only a host-based solution.  On

         the other hand, localized routing with PMIPv6 [RFC6705]

         addresses only a part of the problem where both the MN and the

         CN are located in the PMIP domain and attached to a MAG, and is

         not applicable when the CN is outside the PMIP domain or does

         not behave like an MN.)



You argue for optimized route when accessing a CDN server in the local netw=
ork. But you say that the localized routing schemes don't work when the CN =
is outside the PMIP domain. What is the point ? When the CN is outside the =
PMIP domain, where is optimized route possibility ?



So, PS1 is about optimized routing requirement in DMM. Even though the docu=
ment fails to make the case that the current models have an issue, I'm OK w=
ith optimized routing goal for DMM in general terms.



Revise as follows:

         Routing via a centralized anchor often results in non-optimal
         routes, thereby increasing the end-to-end delay.  The problem
         is manifested, for example, when accessing a nearby server or
         servers of a Content Delivery Network (CDN), or when receiving
         locally available IP multicast or sending IP multicast packets.
         (Existing route optimization is only a host-based solution.  On
         the other hand, localized routing with PMIPv6 [RFC6705]
         addresses only a part of the problem where both the MN and the
         CN are attached to the same MAG, and it is not applicable when
         the CN does not behave like an MN.)







   PS2:  Divergence from other evolutionary trends in network

         architectures such as distribution of content delivery.





         Centralized mobility management can become non-optimal with a

         flat network architecture.





So, this is "non-optimizal" because traffic has to hit the central anchor ?=
 Is it not same as PS1 ? Please add few lines of text

Revise as follows:
         Mobile networks have generally been evolving towards a flat
         network.  Centralized mobility management, which is non-optimal
         with a flat network architecture, does not support this
         evolution.









Chan (Ed.), et al.        Expires May 11, 2014                  [Page 9]



Internet-Draft                  DMM-Reqs                   November 2013





   PS3:  Low scalability of centralized tunnel management and mobility

         context maintenance



         Setting up tunnels through a central anchor and maintaining

         mobility context for each MN usually requires more concentrated

         resources in a centralized design, thus reducing scalability.

         Distributing the tunnel maintenance function and the mobility

         context maintenance function among different network entities

         with proper signaling protocol design can increase scalability.





Its not scalable because it requires lot of "concentrated resources" ? But,=
 distributing them allows it to scale. Not very convincing argument



We can revise as follows:
   PS3:  Scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN usually requires more concentrated
         resources in a centralized design, thus reducing scalability.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can avoid increasing the
         concentrated resources with an increasing number of MNs.







   PS4:  Single point of failure and attack



         Centralized anchoring designs may be more vulnerable to single

         points of failures and attacks than a distributed system.  The

         impact of a successful attack on a system with centralized

         mobility management can be far greater as well.





   PS5:  Unnecessary mobility support to nodes that do not need it



         IP mobility support is not always required, and not every

         parameter of mobility context is always used.  For example,

         some applications do not need a stable IP address during a

         handover to maintain session continuity.  Sometimes, the entire

         application session runs while the terminal does not change the

         point of attachment.  Besides, some sessions, e.g.  SIP-based

         sessions, can handle mobility at the application layer and

         hence do not need IP mobility support; it is then more

         efficient to deactivate IP mobility support for such sessions.





PS5 is about enabling mobility support only to clients that need it ?

Yes.
   PS5:  Unnecessary mobility support to clients that do not need it

         IP mobility support is usually provided to all MNs.  Yet it is
         not always required, and not every parameter of mobility
         context is always used.  For example, some applications do not
         need a stable IP address during a handover to maintain session
         continuity.  Sometimes, the entire application session runs
         while the terminal does not change the point of attachment.
         Besides, some sessions, e.g.  SIP-based sessions, can handle
         mobility at the application layer and hence do not need IP
         mobility support; it is then unnecessary to provide IP mobility
         support for such sessions.





   PS6:  (Related problem) Mobility signaling overhead with peer-to-peer

         communication



         Wasting resources when mobility signaling (e.g., maintenance of

         the tunnel, keep alive signaling, etc.) is not turned off for

         peer-to-peer communication.  Peer-to-peer communications have

         particular traffic patterns that often do not benefit from

         mobility support from the network.  Thus, the associated

         mobility support signaling (e.g., maintenance of the tunnel,

         keep alive signaling, etc.) wastes network resources for no

         application gain.



So, the problem is about signaling load in the network. You want to minimiz=
e the signaling load in the mobility network because of the Peer-to-Peer ap=
plication traffic ? Ok.

Delete as shown above



   PS7:  (Related problem) Deployment with multiple mobility solutions



         There are already many variants and extensions of MIP.

         Deployment of new mobility management solutions can be

         challenging, and debugging difficult, when they must co-exist

         with solutions already in the field.





You mean to say, "protocols" or "solutions" ?



Both. A new solution may not need a new protocol whereas a given protocol c=
an be deployed in different manners.



So, this is a section on "Problem Statement". Why is this talking about a r=
equirement ?

Delete "must" which seem like a requirement.
         There are already many variants and extensions of MIP.
         Deployment of new mobility management solutions can be
         challenging, and debugging difficult, when they co-exist with
         solutions already deployed in the field.







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 10]



Internet-Draft                  DMM-Reqs                   November 2013





   PS8:  Duplicate multicast traffic



         IP multicast distribution over architectures using IP mobility

         solutions (e.g., [RFC6224]) may lead to convergence of

         duplicated multicast subscriptions towards the downstream

         tunnel entity (e.g.  MAG in PMIPv6).  Concretely, when

         multicast subscription for individual mobile nodes is coupled

         with mobility tunnels (e.g.  PMIPv6 tunnel), duplicate

         multicast subscription(s) is prone to be received through

         different upstream paths.  This problem may also exist or be

         more severe in a distributed mobility environment.





5.  Requirements



   After comparing distributed mobility management against centralized

   deployment in Section 3, this section identifies the following

   requirements:



5.1.  Distributed processing



   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid traversing single mobility anchor

          far from the optimal route.



          Motivation: This requirement is motivated by current trends in

          network evolution: (a) it is cost- and resource-effective to

          cache and distribute content by combining distributed mobility

          anchors with caching systems (e.g., CDN); (b) the

          significantly larger number of mobile nodes and flows call for

          improved scalability; (c) single points of failure are avoided

          in a distributed system; (d) threats against centrally

          deployed anchors, e.g., home agent and local mobility anchor,

          are mitigated in a distributed system.



   This requirement addresses the problems PS1, PS2, PS3, and PS4

   described in Section 4.



5.2.  Transparency to Upper Layers when needed



   REQ2:  Transparency to Upper Layers when needed



          DMM solutions MUST provide transparent mobility support above

          the IP layer when needed.  Such transparency is needed, for

          example, when, upon change of point of attachment to the







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 11]



Internet-Draft                  DMM-Reqs                   November 2013





          network, an application flow cannot cope with a change in the

          IP address.  However, it is not always necessary to maintain a

          stable home IP address or prefix for every application or at

          all times for a mobile node.



          Motivation: The motivation of this requirement is to enable

          more efficient routing and more efficient use of network

          resources by selecting an IP address or prefix according to

          whether mobility support is needed and by not maintaining

          context at the mobility anchor when there is no such need.



   This requirement addresses the problem PS5 as well as the related

   problem PS6 stated in Section 4.



5.3.  IPv6 deployment



   REQ3:  IPv6 deployment



          DMM solutions SHOULD target IPv6 as the primary deployment

          environment and SHOULD NOT be tailored specifically to support

          IPv4, in particular in situations where private IPv4 addresses

          and/or NATs are used.



          Motivation: This requirement conforms to the general

          orientation of IETF work.  DMM deployment is foreseen in mid-

          to long-term horizon, when IPv6 is expected to be far more

          common than today.



   This requirement avoids the unnecessarily complexity in solving the

   problems in Section 4 for IPv4, which will not be able to use some of

   the IPv6-specific features.











5.4.  Existing mobility protocols



   REQ4:  Existing mobility protocols



          A DMM solution SHOULD first consider reusing and extending

          IETF-standardized protocols before specifying new protocols.



          Motivation: Reuse of existing IETF work is more efficient and

          less error-prone.



   This requirement attempts to avoid the need of new protocols

   development and therefore their potential problems of being time-

   consuming and error-prone.













Chan (Ed.), et al.        Expires May 11, 2014                 [Page 12]



Internet-Draft                  DMM-Reqs                   November 2013





5.5.  Co-existence



   REQ5:  Co-existence with deployed networks and hosts



          The DMM solution MUST be able to co-exist with existing

          network deployments and end hosts.  For example, depending on

          the environment in which DMM is deployed, DMM solutions may

          need to be compatible with other deployed mobility protocols

          or may need to co-exist with a network or mobile hosts/routers

          that do not support DMM protocols.  The mobile node may also

          move between different access networks, where some of them may

          support neither DMM nor another mobility protocol.

          Furthermore, a DMM solution SHOULD work across different

          networks, possibly operated as separate administrative

          domains, when allowed by the trust relationship between them.



          Motivation: (a) to preserve backwards compatibility so that

          existing networks and hosts are not affected and continue to

          function as usual, and (b) enable inter-domain operation if

          desired.



   This requirement addresses the related problem PS7 described in

   Section 4.



5.6.  Security considerations



   REQ6:  Security considerations



          A DMM solution MUST not introduce new security risks or

          amplify existing security risks against which the existing

          security mechanisms/protocols cannot offer sufficient

          protection.



          Motivation: Various attacks such as impersonation, denial of

          service, man-in-the-middle attacks, and so on, may be launched

          in a DMM deployment.  For instance, an illegitimate node may

          attempt to access a network providing DMM.  Another example is

          that a malicious node can forge a number of signaling messages

          thus redirecting traffic from its legitimate path.

          Consequently, the specific node is under a denial of service

          attack, whereas other nodes do not receive their traffic.

          Accordingly, security mechanisms/protocols providing access

          control, integrity, authentication, authorization,

          confidentiality, etc. can be used to protect the DMM entities

          as they are already used to protect against existing networks

          and existing mobility protocols defined in IETF.



   This requirement prevents a DMM solution from introducing







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 13]



Internet-Draft                  DMM-Reqs                   November 2013





   uncontrollable problems of potentially insecure mobility management

   protocols which make deployment infeasible because platforms

   conforming to the protocols are at risk for data loss and numerous

   other dangers, including financial harm to the users.











5.7.  Multicast



   REQ7:  Multicast considerations



          DMM SHOULD consider multicast early so that solutions can be

          developed not only to provide IP mobility support when it is

          needed, but also to avoid network inefficiency issues in

          multicast traffic delivery (such as duplicate multicast

          subscriptions towards the downstream tunnel entities).  The

          multicast solutions should therefore avoid restricting the

          management of all IP multicast traffic to a single host

          through a dedicated (tunnel) interface on multicast-capable

          access routers.



          Motivation: Existing multicast deployment have been introduced

          after completing the design of the reference mobility

          protocol, then optimization and extensions have been followed

          by "patching-up" procedure, thus leading to network

          inefficiency and non-optimal routing.  The multicast solutions

          should therefore be required to consider efficiency nature in

          multicast traffic delivery.



[Sri] Considering multicast at a design phase is not technical requirement =
for DMM.

What is "patching up" procedure ?



Revise as follows:
   REQ7:  Multicast considerations

          DMM SHOULD enable multicast solutions to be developed to avoid
          network inefficiency in multicast traffic delivery.

          Motivation: Existing multicast deployment have been introduced
          after completing the design of the reference mobility
          protocol, often leading to network inefficiency and non-
          optimal routing for the multicast traffic.  Instead DMM should
          consider multicast early so that the multicast solutions can
          better consider efficiency nature in the multicast traffic
          delivery (such as duplicate multicast subscriptions towards
          the downstream tunnel entities).  The multicast solutions
          should then avoid restricting the management of all IP
          multicast traffic to a single host through a dedicated
          (tunnel) interface on multicast-capable access routers.





   This requirement addresses the problems PS1 and PS8 described in

   Section 4.





6.  Security Considerations



   Please refer to the discussion under Security requirement in Section

   5.6.





7.  IANA Considerations



   None





8.  Co-authors and Contributors



   This problem statement document is a joint effort among the numerous

   participants.  Each individual has made significant contributions to

   this work and have been listed as co-authors.









Chan (Ed.), et al.        Expires May 11, 2014                 [Page 14]



Internet-Draft                  DMM-Reqs                   November 2013





9.  References



9.1.  Normative References



   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

              Requirement Levels", BCP 14, RFC 2119, March 1997.



9.2.  Informative References



   [I-D.bhandari-dhc-class-based-prefix]

              Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,

              Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class

              based prefix", draft-bhandari-dhc-class-based-prefix-05

              (work in progress), July 2013.



   [I-D.korhonen-6man-prefix-properties]

              Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.

              Liu, "IPv6 Prefix Properties",

              draft-korhonen-6man-prefix-properties-02 (work in

              progress), July 2013.



   [I-D.wakikawa-netext-pmip-cp-up-separation]

              Wakikawa, R., Pazhyannur, R., and S. Gundavelli,

              "Separation of Control and User Plane for Proxy Mobile

              IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00

              (work in progress), July 2013.



   [I-D.yokota-dmm-scenario]

              Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case

              scenarios  for Distributed Mobility Management",

              draft-yokota-dmm-scenario-00 (work in progress),

              October 2010.



   [Paper-Distributed.Centralized.Mobility]

              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed

              or Centralized Mobility",  Proceedings of Global

              Communications Conference  (GlobeCom), December 2009.



   [Paper-Distributed.Dynamic.Mobility]

              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed

              Dynamic Mobility Management Scheme  Designed for Flat IP

              Architectures",  Proceedings of 3rd International

              Conference  on New Technologies, Mobility and Security

              (NTMS), 2008.



   [Paper-Distributed.Mobility.MIP]

              Chan, H., "Distributed Mobility Management with Mobile

              IP",  Proceedings of  IEEE International Communication







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 15]



Internet-Draft                  DMM-Reqs                   November 2013





              Conference (ICC)  Workshop on Telecommunications:  from

              Research to Standards, June 2012.



   [Paper-Distributed.Mobility.PMIP]

              Chan, H., "Proxy Mobile IP  with Distributed Mobility

              Anchors",  Proceedings of GlobeCom Workshop  on Seamless

              Wireless Mobility, December 2010.



   [Paper-Distributed.Mobility.Review]

              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,

              "Distributed and Dynamic Mobility Management  in Mobile

              Internet: Current Approaches and Issues, Journal of

              Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.",

               Proceedings of GlobeCom Workshop  on Seamless Wireless

              Mobility, February 2011.



   [Paper-Distributed.Mobility.SAE]

              Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M.

              Schlager, "A Distributed IP Mobility Approach for 3G SAE",

               Proceedings of the 19th International Symposium  on

              Personal, Indoor and Mobile Radio Communications (PIMRC),

              2008.



   [Paper-Locating.User]

              Kirby, G., "Locating the User",  Communication

              International, 1995.



   [Paper-Migrating.Home.Agents]

              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home

              Agents  Towards Internet-scale Mobility Deployments",

               Proceedings of the ACM 2nd CoNEXT Conference  on Future

              Networking Technologies, December 2006.



   [Paper-Mobile.Data.Offloading]

              Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile

              Data Offloading: How Much Can WiFi Deliver?",  SIGCOMM

              2010, 2010.



   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",

              RFC 3753, June 2004.



   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,

              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.



   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.

              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility

              Management", RFC 5380, October 2008.









Chan (Ed.), et al.        Expires May 11, 2014                 [Page 16]



Internet-Draft                  DMM-Reqs                   November 2013





   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",

              RFC 5944, November 2010.



   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base

              Deployment for Multicast Listener Support in Proxy Mobile

              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.



   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support

              in IPv6", RFC 6275, July 2011.



   [RFC6301]  Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility

              Support in the Internet", RFC 6301, July 2011.



   [RFC6705]  Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.

              Dutta, "Localized Routing for Proxy Mobile IPv6",

              RFC 6705, September 2012.



   [RFC6909]  Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.

              Koodli, "IPv4 Traffic Offload Selector Option for Proxy

              Mobile IPv6", RFC 6909, April 2013.



   [TS.23.401]

              3GPP, "General Packet Radio Service (GPRS) enhancements

              for Evolved Universal Terrestrial Radio Access Network

              (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013.



   [TS.29303]

              3GPP, "Domain Name System Procedures; Stage 3", 3GPP

              TR 23.303 11.2.0, September 2012.





Authors' Addresses



   H Anthony Chan (editor)

   Huawei Technologies (more co-authors on P. 17)

   5340 Legacy Dr. Building 3, Plano, TX 75024, USA

   Email: h.a.chan@ieee.org





   Dapeng Liu

   China Mobile

   Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China

   Email: liudapeng@chinamobile.com

















Chan (Ed.), et al.        Expires May 11, 2014                 [Page 17]



Internet-Draft                  DMM-Reqs                   November 2013





   Pierrick Seite

   Orange

   4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France

   Email: pierrick.seite@orange.com





   Hidetoshi Yokota

   KDDI Lab

   2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan

   Email: yokota@kddilabs.jp





   Jouni Korhonen

   Renesas Mobile

   Porkkalankatu 24, FIN-00180 Helsinki, Finland

   Email: jouni.korhonen@nsn.com

   -

   Charles E. Perkins

   Huawei Technologies

   Email: charliep@computer.org

   -

   Melia Telemaco

   Alcatel-Lucent Bell Labs

   Email: telemaco.melia@alcatel-lucent.com

   -

   Elena Demaria

   Telecom Italia

   via G. Reiss Romoli, 274, TORINO, 10148, Italy

   Email: elena.demaria@telecomitalia.it

   -

   Jong-Hyouk Lee

   Sangmyung University

   Email: hurryon@gmail.com

   -

   Kostas Pentikousis

   EICT GmbH

   Email: k.pentikousis@eict.de

   -

   Tricci So

   ZTE

   Email: tso@zteusa.com

   -

   Carlos J. Bernardos

   Universidad Carlos III de Madrid

   Av. Universidad, 30, Leganes, Madrid 28911, Spain

   Email: cjbc@it.uc3m.es

   -

   Peter McCann







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 18]



Internet-Draft                  DMM-Reqs                   November 2013





   Huawei Technologies

   Email: PeterMcCann@huawei.com

   -

   Seok Joo Koh

   Kyungpook National University, Korea

   Email: sjkoh@knu.ac.kr

   -

   Wen Luo

   ZTE

   No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China

   Email: luo.wen@zte.com.cn

   -

   Sri Gundavelli

   Cisco

   sgundave@cisco.com

   -

   Marco Liebsch

   NEC Laboratories Europe

   Email: liebsch@neclab.eu

   -

   Carl Williams

   MCSR Labs

   Email: carlw@mcsr-labs.org

   -

   Seil Jeon

   Instituto de Telecomunicacoes, Aveiro

   Email: seiljeon@av.it.pt

   -

   Sergio Figueiredo

   Universidade de Aveiro

   Email: sfigueiredo@av.it.pt

   -

   Stig Venaas

   Email: stig@venaas.com

   -

   Luis Miguel Contreras Murillo

   Telefonica I+D

   Email: lmcm@tid.es

   -

   Juan Carlos Zuniga

   InterDigital

   Email: JuanCarlos.Zuniga@InterDigital.com

   -

   Alexandru Petrescu

   Email: alexandru.petrescu@gmail.com

   -

   Georgios Karagiannis

   University of Twente







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 19]



Internet-Draft                  DMM-Reqs                   November 2013





   Email: g.karagiannis@utwente.nl

   -

   Julien Laganier

   Juniper

   jlaganier@juniper.net

   -

   Wassim Michel Haddad

   Ericsson

   Wassam.Haddad@ericsson.com

   -

   Dirk von Hugo

   Deutsche Telekom Laboratories

   Dirk.von-Hugo@telekom.de

   -

   Ahmad Muhanna

   Award Solutions

   amuhanna@awardsolutions.com

   -

   Byoung-Jo Kim

   ATT Labs

   macsbug@research.att.com

   -

   Hassan Ali-Ahmad

   Orange

   hassan.aliahmad@orange.com

   -

   Alper Yegin

   Samsung

   alper.yegin@partner.samsung.com

   -





























--_000_6E31144C030982429702B11D6746B98C370E6FAEszxeml557mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Sri,

Suggested revisions are s=
hown in blue below.



Not sure about what impro=
vements are desired for the definitions though.


 <=
/p>



H Anthony Chan=





 <=
/p>





From: Sri Gund=
avelli (sgundave) [mailto:sgundave@cisco.com]


Sent: Sunday, November 17, 2013 4:27 PM

To: h chan; dmm@ietf.org

Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 




Hi Anthony,






 






Thanks for revising the draf=
t. Following are some more comments on the document. I'm not holding this d=
ocument any more. What ever comments you can address … or
 you can choose not to revise …






 






Please see inline.






 






Regards





Sri






 






 






From:
h chan <h.anthony.chan@huawei.com>

Date: Wednesday, September 25, 2013 9:49 PM

To: Sri Gundavelli <sgundav=
e@cisco.com>, "dmm@ietf.org=
" <dmm@ietf.org>

Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 








 


Sri,


 


Thanks for the comments. =
We are replying under different sections in separate emails.









 






 






 


 


Network Working Group    &n=
bsp;            =
;            &n=
bsp;        H. Chan (Ed.)


Internet-Draft    &nbs=
p;            &=
nbsp;           &nbs=
p;   Huawei Technologies (more


Intended status: Informational  =
            &nb=
sp;       co-authors on P. 17)


Expires: May 11, 2014   &nb=
sp;            =
            &nb=
sp;             =
;   D. Liu


       =
            &nb=
sp;            =
            &nb=
sp;            =
   China Mobile


       =
            &nb=
sp;            =
            &nb=
sp;            =
       P. Seite


       =
            &nb=
sp;            =
            &nb=
sp;            =
         Orange

       =
            &nb=
sp;             =
;            &n=
bsp;            =
;     H. Yokota


       =
            &nb=
sp;            =
            &nb=
sp;            =
       KDDI Lab


       =
            &nb=
sp;            =
            &nb=
sp;            =
    J. Korhonen


       =
            &nb=
sp;            =
            &nb=
sp;            =
 Renesas Mobile


       =
            &nb=
sp;            =
            &nb=
sp;           November 7,=
 2013


 


 


       =
     Requirements for Distributed Mobility Management


       =
            &nb=
sp; draft-ietf-dmm-requirements-10


 


Abstract


 


   This document defines the req=
uirements for Distributed Mobility


   Management (DMM).  The h=
ierarchical structure in traditional wireless


   networks has led primarily to=
 centralized deployment models.  As some


   wireless networks are evolvin=
g away from the hierarchical structure,


   such as in moving the content=
 delivery servers closer to the users, a


   distributed model for mobilit=
y management can be useful to them.


 


 


[Sri] Not sure, w=
hat the "hierarchical structure in traditional wireless" means.


There are two asp=
ects here:


 


1.) There is the =
aspect of distributed mobility deployment model for all the reasons that th=
e document talks about=



2.) There is the other aspect of hosting content servers cl=
oser to the subscriber


 


I'm not able to d=
raw the relation between "moving content to the access" and the s=
hift from centralized to distributed model. I understand you want to say to=
day there are central anchors where subscriber sessions are hosted. All the=
 traffic from the mobile node's is brought to the central location/anchor f=
or service enablement and including content access. An alternative model is=
 to distribute the anchors, localize the traffic and enable the associated =
services to local anchors. You may want to re-write the text if you want to=
 get that right.


 


Let us delete “such as in moving the content delivery servers closer to the u=
sers,”


Then the abstract becomes:


Abstract


 


   This document defines the r=
equirements for Distributed Mobility


   Management (DMM).  The=
 hierarchical structure in traditional wireless


   networks has led primarily =
to centralized deployment models.  As some


   wireless networks are evolv=
ing away from the hierarchical structure,


   a


   distributed model for mobil=
ity management can be useful to them.


 


 


 


 


 


Requirements Language

 


   The key words "MUST"=
;, "MUST NOT", "REQUIRED", "SHALL", "SHA=
LL NOT",


   "SHOULD", "SHO=
ULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL=
" in this


   document are to be interprete=
d as described in RFC 2119 RFC 2119


   [RFC2119].<=
/pre>

 


Status of this Memo

 


   This Internet-Draft is submit=
ted in full conformance with the


   provisions of BCP 78 and BCP =
79.


 


   Internet-Drafts are working d=
ocuments of the Internet Engineering


   Task Force (IETF).  Note=
 that other groups may also distribute


   working documents as Internet=
-Drafts.  The list of current Internet-


   Drafts is at http://datatracker.ietf.org/drafts/=
current/.


 


   Internet-Drafts are draft doc=
uments valid for a maximum of six months


   and may be updated, replaced,=
 or obsoleted by other documents at any


   time.  It is inappropria=
te to use Internet-Drafts as reference


   material or to cite them othe=
r than as "work in progress."


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 1]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   This Internet-Draft will expi=
re on May 11, 2014.


 


Copyright Notice


 


   Copyright (c) 2013 IETF Trust=
 and the persons identified as the


   document authors.  All r=
ights reserved.


 


   This document is subject to B=
CP 78 and the IETF Trust's Legal


   Provisions Relating to IETF D=
ocuments


   (http://trustee.ietf.org/license-info) in effect on=
 the date of


   publication of this document.=
  Please review these documents


   carefully, as they describe y=
our rights and restrictions with respect


   to this document.  Code =
Components extracted from this document must


   include Simplified BSD Licens=
e text as described in Section 4.e of


   the Trust Legal Provisions an=
d are provided without warranty as


   described in the Simplified B=
SD License.


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 2]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


Table of Contents


 


   1.  Introduction . . . .=
 . . . . . . . . . . . . . . . . . . . . .  4


   2.  Conventions used in =
this document  . . . . . . . . . . . . . .  6

     2.1.  Termin=
ology  . . . . . . . . . . . . . . . . . . . . . . .  6


   3.  Centralized versus d=
istributed mobility management . . . . . .  7


     3.1.  Centra=
lized mobility management  . . . . . . . . . . . . .  7


     3.2.  Distri=
buted mobility management  . . . . . . . . . . . . .  8


   4.  Problem Statement&nb=
sp; . . . . . . . . . . . . . . . . . . . . . .  9

   5.  Requirements . . . .=
 . . . . . . . . . . . . . . . . . . . . . 11


     5.1.  Distri=
buted processing . . . . . . . . . . . . . . . . . . 11

     5.2.  Transp=
arency to Upper Layers when needed . . . . . . . . . 11

     5.3.  IPv6 d=
eployment  . . . . . . . . . . . . . . . . . . . . . 12


     5.4.  Existi=
ng mobility protocols  . . . . . . . . . . . . . . . 12


     5.5.  Co-exi=
stence . . . . . . . . . . . . . . . . . . . . . . . 13

     5.6.  Securi=
ty considerations  . . . . . . . . . . . . . . . . . 13


     5.7.  Multic=
ast  . . . . . . . . . . . . . . . . . . . . . . . . 14


   6.  Security Considerati=
ons  . . . . . . . . . . . . . . . . . . . 14


   7.  IANA Considerations&=
nbsp; . . . . . . . . . . . . . . . . . . . . . 14


   8.  Co-authors and Contr=
ibutors  . . . . . . . . . . . . . . . . . 14


   9.  References . . . . .=
 . . . . . . . . . . . . . . . . . . . . . 15


     9.1.  Normat=
ive References . . . . . . . . . . . . . . . . . . . 15

     9.2.  Inform=
ative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . =
. . . . . . . . . . . . . . . . . . . 17


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 3]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


1.  Introduction

 


   In the past decade a fair num=
ber of mobility protocols have been


   standardized [RFC6275] [RFC59=
44] [RFC5380] [RFC6301] [RFC5213].


   Although the protocols differ=
 in terms of functions and associated


   message formats, they all emp=
loy a mobility anchor to allow a mobile


   node to remain reachable afte=
r it has moved to a different network.


   The anchor point, among other=
 tasks, ensures connectivity by


   forwarding packets destined t=
o, or sent from, the mobile node.  It is


   a centrally deployed mobility=
 anchor in the sense that the deployed


   architectures today have a sm=
all number of these anchors and the


   traffic of millions of mobile=
 nodes in an operator network are


   typically managed by the same=
 anchor.


 


   Distributed mobility manageme=
nt (DMM) is an alternative to the above


   centralized deployment. =
 The background behind the interests to study


   DMM are primarily in the foll=
owing.


 


   (1)  Mobile users are, m=
ore than ever, consuming Internet content;


       =
 such traffic imposes new requirements on mobile core networks


       =
 for data traffic delivery.  The presence of content providers


       =
 closer to Internet Service Providers (ISP) network requires


       =
 taking into account local Content Delivery Networks (CDNs) while


       =
 providing mobility services.  Moreover, when the traffic demand<=
/o:p>


       =
 exceeds available capacity, service providers need to implement=



       =
 new strategies such as selective IPv4 traffic offload (e.g.


       =
 [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through


       =
 alternative access networks (e.g.  WLAN) [Paper-

       =
 Mobile.Data.Offloading].  A gateway selection mechanism also


       =
 takes the user proximity into account within EPC [TS.29303].


       =
 These mechanisms were not pursued in the past owing to charging=



       =
 and billing reasons.  Assigning a gateway anchor node from a


       =
 visited network in roaming scenario has until recently been done


       =
 and are limited to voice services only.  Charging and billing


       =
 require solutions beyond the mobility protocol.


 


 


[Sri] Some valid points above. But, IMHO, its not orga=
nized correctly. 


My only comment with this document is that this has text fr=
om multiple people with different goals, but is not organized poorly.


 


Reminds me of some SDO documents. There the document starts=
 with a blank template, every company spits a line or two and in no time, t=
he document grows like a monster, but there is no relation between two line=
s of text in the same paragraph. No offense.


 


Rearrange as =
follows:


 


   (1)  Mobile users are, mor=
e than ever, consuming Internet content


        i=
ncluding that of local Content Delivery Networks (CDNs) which


        h=
ad not taken mobility service into account before.  Such


        t=
raffic imposes new requirements on mobile core networks for


        d=
ata traffic delivery.  To prevent exceeding the available core


        n=
etwork capacity, service providers need to implement new<=
/p>

        s=
trategies such as selective IPv4 traffic offload (e.g.

        [=
RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through=



        a=
lternative access networks (e.g.  WLAN) [Paper-


        M=
obile.Data.Offloading].  In addition, a gateway selection


        m=
echanism takes the user proximity into account within EPC=



        [=
TS.29303].  Yet these mechanisms were not pursued in the past


        o=
wing to charging and billing which require solutions beyond the<=
/span>


        m=
obility protocol.  Consequently, assigning a gateway anchor=



        n=
ode from a visited network in roaming scenario has until<=
/p>

        r=
ecently been done and are limited to voice services only.=



 


 


 


       =
 Both traffic offloading and CDN mechanisms could benefit from


       =
 the development of mobile architectures with fewer levels of


       =
 routing hierarchy introduced into the data path by the mobility=



       =
 management system.  This trend towards so-called "flat networks&=
quot;


       =
 works best for direct communications among peers in the same


       =
 geographical area.  Distributed mobility management in a truly


       =
 flat mobile architecture would anchor the traffic closer to the=



       =
 point of attachment of the user.


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 4]=



 


Internet-Draft     &nb=
sp;            =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   (2)  Today's mobile netw=
orks present service providers with new


       =
 challenges.  Mobility patterns indicate that mobile nodes often<=
/o:p>


       =
 remain attached to the same point of attachment for considerable


       =
 periods of time [Paper-Locating.User].  Specific IP mobility


       =
 management support is not required for applications that launch=



       =
 and complete their sessions while the mobile node is connected<=
/span>


       =
 to the same point of attachment.  However, currently, IP


       =
 mobility support is designed for always-on operation,

       =
 maintaining all parameters of the context for each mobile


       =
 subscriber for as long as they are connected to the network.


       =
 This can result in a waste of resources and unnecessary costs


       =
 for the service provider.  Infrequent node mobility coupled with=



       =
 application intelligence suggest that mobility support could be=



       =
 provided selectively such as in [I-D.bhandari-dhc-class-based-<=
/span>


       =
 prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing


       =
 the amount of context maintained in the network.


 


 


Let us delete=
 the following, which don’t seem necessary. The requirements already =
have the problem statements to support them.  


   In addition, consid=
erations in the study of DMM are in the following.

 


   (1)  To optimize ha=
ndovers from the perspective of mobile nodes, the

      &=
nbsp; base protocols have been extended to efficiently handle packet


      &=
nbsp; forwarding between the previous and new points of attachment.


      &=
nbsp; These extensions are necessary when applications have stringent<=
/o:p>


      &=
nbsp; requirements in terms of delay.  Notions of localization and


      &=
nbsp; distribution of local agents have been introduced to reduce


      &=
nbsp; signaling overhead at the centralized routing anchor point=



      &=
nbsp; [Paper-Distributed.Centralized.Mobility].  Unfortunately, such


      &=
nbsp; protocols have not been deployed today.


 


   (2)  Most existing =
mobility protocols have not been designed for


      &=
nbsp; multiple-interface hosts which are capable to use multiple=



      &=
nbsp; interfaces simultaneously.  Retrofitting the required=



      &=
nbsp; functionality can result in an unnecessary increase in the=



      &=
nbsp; protocol complexity.


 


 


RFC5648.


Not sure. I agree=
 about the complexity. Any case, this is not a DMM requirement<=
/o:p>


 


 


 


   (3)  IP multicast s=
upport, including optimizations, have been


      &=
nbsp; introduced as an effective transport method for multimedia data<=
/o:p>


      &=
nbsp; delivery, but by "patching-up" procedure after completing t=
he


      &=
nbsp; design of reference mobility protocol, leading to network<=
/span>


      &=
nbsp; inefficiency and non-optimal routing.


 


 


I dont understand=
 this.


 


 


   The distributed mobility management (DMM) charter address=
es two


   complementary aspects of mobility management procedures: =
the


   distribution of mobility anchors in the data-plane toward=
s a more


   flat network and the selective activation/deactivation of=
 mobility


   protocol support as an enabler to distributed mobility ma=
nagement.


   The former aims at positioning mobility anchors (e.g., HA=
, LMA)


   closer to the user; ideally, mobility agents could be col=
located with


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 5]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            =
;   November 2013


 


 


   the first-hop router.  The latter, facilitated by th=
e distribution of


   mobility anchors, identifies when mobility support must b=
e activated


   and when sessions do not require mobility management supp=
ort -- thus


   reducing the amount of state information that must be mai=
ntained in


   various mobility agents of the mobile network.  It c=
an then avoid the


   unnecessary establishment of mechanisms to forward traffi=
c from an


   old to a new mobility anchor.


 


   This document compares distributed mobility management wi=
th


   centralized mobility management in Section 3.  The p=
roblems that can


   be addressed with DMM are summarized in Section 4.  =
The mandatory


   requirements as well as the optional requirements are giv=
en in


   Section 5.  Finally, security considerations are dis=
cussed in Section


   6.


 


   The problem statement and the use cases [I-D.yokota-dmm-s=
cenario] can


   be found in [Paper-Distributed.Mobility.Review].


 


 


2.  Conventions used in this document


 


2.1.  Terminology


 


   All the general mobility-related terms and their acronyms=
 used in


   this document are to be interpreted as defined in the Mob=
ile IPv6


   base specification [RFC6275], in the Proxy mobile IPv6 sp=
ecification


   [RFC5213], and in Mobility Related Terminology [RFC3753].=
  These


   terms include the following: mobile node (MN), correspond=
ent node


   (CN), and home agent (HA) as per [RFC6275]; local mobilit=
y anchor


   (LMA) and mobile access gateway (MAG) as per [RFC5213], a=
nd context


   as per [RFC3753].


 


   In addition, this draft introduces the following terms.


 


   Centrally deployed mobility anchors


 


      refer to the mobility management deploy=
ments in which there are


      very few mobility anchors and the traff=
ic of millions of mobile


      nodes in an operator network are manage=
d by the same anchor.


 


   Centralized mobility management


 


      makes use of centrally deployed mobilit=
y anchors.


 


   Distributed mobility management


 


      is not centralized so that traffic does=
 not need to traverse


      centrally deployed mobility anchors.


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 6]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            =
;   November 2013


 


 


   Flat mobile network


 


      has few levels of routing hierarchy int=
roduced into the data path


      by the mobility management system.=



 


 


 


   Mobility context


 


      is the collection of information requir=
ed to provide mobility


      management support for a given mobile n=
ode.


 


 


You can impr=
ove the terminology section


Not sure whet=
her you want to better define these terms or whether some definitions are m=
issing? 


 


3.  Centralized versus distributed mobility management=



 


   Mobility management functions may be implemented at diffe=
rent layers


   of the protocol stack.  At the IP (network) layer, m=
obility


   management can be client-based or network-based.


 


   An IP-layer mobility management protocol is typically bas=
ed on the


   principle of distinguishing between session identifier an=
d routing


   address and maintaining a mapping between the two.  =
In Mobile IP, the


   home address serves as the session identifier whereas the=
 care-of-


   address (CoA) takes the role of the routing address. =
; The binding


   between these two is maintained at the home agent (mobili=
ty anchor).


   If packets addressed to the home address of a mobile node=
 can be


   continuously delivered to the node, then all sessions usi=
ng that home


   address are unaffected even though the routing address (C=
oA) changes.


 


   The next two subsections explain centralized and distribu=
ted mobility


   management functions in the network.


 


3.1.  Centralized mobility management


 


   In centralized mobility management, the mapping informati=
on between


   the session identifier and the locator IP address of a mo=
bile node


   (MN) is kept at a single mobility anchor.  At the sa=
me time, packets


   destined to the MN are routed via this anchor.  In o=
ther words, such


   mobility management systems are centralized in both the c=
ontrol plane


   and the data plane (mobile node IP traffic).

 


   Many existing mobility management deployments make use of=
 centralized


   mobility anchoring in a hierarchical network architecture=
, as shown


   in Figure 1.  Examples of such centralized mobility =
anchors are the


   home agent (HA) and local mobility anchor (LMA) in Mobile=
 IPv6


   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.&=
nbsp; Current


   cellular networks such as the Third Generation Partnershi=
p Project


   (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Pac=
ket System


   (EPS) networks employ centralized mobility management too=
.  In


   particular, the Gateway GPRS Support Node (GGSN), Serving=
 GPRS


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 7]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            =
;   November 2013


 


 


   Support Node (SGSN) and Radio Network Controller (RNC) in=
 the 3GPP


   GPRS hierarchical network, and the Packet Data Network Ga=
teway (P-GW)


   and Serving Gateway (S-GW) in the 3GPP EPS network all ac=
t as anchors


   in a hierarchy.


 


 


         3G GPRS  &n=
bsp;            &nbs=
p; 3GPP EPS          =
;      MIP/PMIP


         +------+ =
;            &n=
bsp;  +------+        =
        +------+

         | GGSN |  &=
nbsp;           &nbs=
p; | P-GW |          &nbs=
p;     |HA/LMA|


         +------+ =
;            &n=
bsp;  +------+        =
        +------+

            /\&=
nbsp;           &nbs=
p;         /\   &nbs=
p;            &=
nbsp;     /\


           /  \=
            &nb=
sp;       /  \    &n=
bsp;            =
;   /  \


          /  &n=
bsp; \           &nb=
sp;      /    \   &n=
bsp;            =
;  /    \


         /   &n=
bsp;  \          &nb=
sp;     /      \  &n=
bsp;            =
; /      \


        /     &=
nbsp;  \         &nb=
sp;    /        \ &n=
bsp;            /&nb=
sp;       \


       /     &n=
bsp;    \        &nb=
sp;   /          \&n=
bsp;           / &nb=
sp;        \


      /      &n=
bsp;     \       &nb=
sp;  /          &nbs=
p; \          /  &nb=
sp;         \


  +------+      +------+=
  +------+      +------+ =
; +------+      +------+


  | SGSN |      | SGSN |  | S-GW |&=
nbsp;     | S-GW |  |MN/MAG|   &nbs=
p;  |MN/MAG|


  +------+      +------+=
  +------+      +------+ =
; +------+      +------+


     /\       &=
nbsp;    /\


    /  \       =
   /  \


   /    \      =
  /    \


+---+  +---+  +---+  +---&#=
43;


|RNC|  |RNC|  |RNC|  |RNC|


+---+  +---+  +---+  +---&#=
43;


 


   Figure 1.  Centralized mobility management.


 


3.2.  Distributed mobility management


 


   Mobility management functions may also be distributed to =
multiple


   networks as shown in Figure 2, so that a mobile node in a=
ny of these


   networks may be served by a nearby mobility function (MF)=
.


 


 


           &nbs=
p;        +------+  +--=
----+  +------+  +------+


           &nbs=
p;        |  MF  |  |&nbs=
p; MF  |  |  MF  |  |  MF  |<=
/pre>

           &nbs=
p;        +------+  +--=
----+  +------+  +------+


           &nbs=
p;            &=
nbsp;           &nbs=
p;      |


           &nbs=
p;            &=
nbsp;           &nbs=
p;    +----+


           &nbs=
p;            &=
nbsp;           &nbs=
p;    | MN |


           &nbs=
p;            &=
nbsp;           &nbs=
p;    +----+


 


   Figure 2.  Distributed mobility management.


 


   Mobility management may be partially or fully distributed=



   [I-D.yokota-dmm-scenario].  In the former case only =
the data plane is


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 8]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            &nbs=
p;  November 2013


 


 


   distributed, implicitly assuming separation of data and c=
ontrol


   planes as described in [I-D.wakikawa-netext-pmip-cp-up-se=
partion].


   Fully distributed mobility management implies that both t=
he data


   plane and the control plane are distributed.  While =
mobility


   management can be distributed, it is not necessary for ot=
her


   functions such as subscription management, subscription d=
atabase, and


   network access authentication to be similarly distributed=
.


 


   A distributed mobility management scheme for a flat mobil=
e network of


   access nodes is proposed in [Paper-Distributed.Dynamic.Mo=
bility].


   Its benefits over centralized mobility management are sho=
wn through


   simulations in [Paper-Distributed.Centralized.Mobility].&=
nbsp; Moreover,


   the (re)use and extension of existing protocols in the de=
sign of both


   fully distributed mobility management [Paper-Migrating.Ho=
me.Agents]


   [Paper-Distributed.Mobility.SAE] and partially distribute=
d mobility


   management [Paper-Distributed.Mobility.PMIP] [Paper-=



   Distributed.Mobility.MIP] have been reported in the liter=
ature.


   Therefore, before designing new mobility management proto=
cols for a


   future distributed architecture, it is recommended to fir=
st consider


   whether existing mobility management protocols can be ext=
ended.


 


 


4.  Problem Statement


 


   The problems that can be addressed with DMM are summarize=
d in the


   following:


 


   PS1:  Non-optimal routes


 


         Routing via a central=
ized anchor often results in non-optimal


         routes, thereby incre=
asing the end-to-end delay.  The problem


         is manifested, for ex=
ample, when accessing a nearby server or


         servers of a Content =
Delivery Network (CDN), or when receiving


         locally available IP =
multicast or sending IP multicast packets.


         (Existing route optim=
ization is only a host-based solution.  On


         the other hand, local=
ized routing with PMIPv6 [RFC6705]


         addresses only a part=
 of the problem where both the MN and the


         CN are located in the=
 PMIP domain and attached to a MAG, and is


         not applicable when t=
he CN is outside the PMIP domain or does


         not behave like an MN=
.)


 


You argue for opt=
imized route when accessing a CDN server in the local network. But you say =
that the localized routing schemes don't work when the CN is outside the PM=
IP domain. What is the point ? When the CN is outside the PMIP domain, wher=
e is optimized route possibility ? 


 


So, PS1 is about =
optimized routing requirement in DMM. Even though the document fails to mak=
e the case that the current models have an issue, I'm OK with optimized rou=
ting goal for DMM in general terms.


 


Revise as fol=
lows:


 


       &n=
bsp; Routing via a centralized anchor often results in non-optimal


       &n=
bsp; routes, thereby increasing the end-to-end delay.  The problem


       &n=
bsp; is manifested, for example, when accessing a nearby server or


       &n=
bsp; servers of a Content Delivery Network (CDN), or when receiving


       &n=
bsp; locally available IP multicast or sending IP multicast packets.


       &n=
bsp; (Existing route optimization is only a host-based solution.  On


       &n=
bsp; the other hand, localized routing with PMIPv6 [RFC6705]


       &n=
bsp; addresses only a part of the problem where both the MN and the


       &n=
bsp; CN are attached to the same MAG, and it is not applicable when


       &n=
bsp; the CN does not behave like an MN.)


 


 


 


   PS2:  Divergence from ot=
her evolutionary trends in network


       =
  architectures such as distribution of content delivery.


 


 


         Centralized mobility =
management can become non-optimal with a


         flat network architec=
ture.


 


 =
;


So, this is "non-optimizal" because traffic has t=
o hit the central anchor ? Is it not same as PS1 ? Please add few lines of =
text


Revise as follows:


       &n=
bsp; Mobile networks have generally been evolving towards a flat=



       &n=
bsp; network.  Centralized mobility management, which is non-optimal


       &n=
bsp; with a flat network architecture, does not support this


       &n=
bsp; evolution.


 =
;


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 9]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   PS3:  Low scalability of=
 centralized tunnel management and mobility


       =
  context maintenance


 


        =
; Setting up tunnels through a central anchor and maintaining


       =
  mobility context for each MN usually requires more concentrated=



       =
  resources in a centralized design, thus reducing scalability.


       =
  Distributing the tunnel maintenance function and the mobility


       =
  context maintenance function among different network entities


       =
  with proper signaling protocol design can increase scalability.=



 


 


Its not scalable =
because it requires lot of "concentrated resources" ? But, distri=
buting them allows it to scale. Not very convincing argument


 


We can revise=
 as follows:


   PS3:  Scalability of centr=
alized tunnel management and mobility


       &n=
bsp; context maintenance


 


       &n=
bsp; Setting up tunnels through a central anchor and maintaining=



       &n=
bsp; mobility context for each MN usually requires more concentrated


       &n=
bsp; resources in a centralized design, thus reducing scalability.


       &n=
bsp; Distributing the tunnel maintenance function and the mobility


       &n=
bsp; context maintenance function among different network entities


       &n=
bsp; with proper signaling protocol design can avoid increasing the


       &n=
bsp; concentrated resources with an increasing number of MNs.


 


 


 


   PS4:  Single point of fa=
ilure and attack


 


       =
  Centralized anchoring designs may be more vulnerable to single<=
/o:p>


       =
  points of failures and attacks than a distributed system.  The<=
o:p>


        =
; impact of a successful attack on a system with centralized


       =
  mobility management can be far greater as well.

 


 


   PS5:  Unnecessary mobili=
ty support to nodes that do not need it


 


       =
  IP mobility support is not always required, and not every=



       =
  parameter of mobility context is always used.  For example,


       =
  some applications do not need a stable IP address during a


       =
  handover to maintain session continuity.  Sometimes, the entire=



       =
  application session runs while the terminal does not change the=



       =
  point of attachment.  Besides, some sessions, e.g.  SIP-ba=
sed


       =
  sessions, can handle mobility at the application layer and


       =
  hence do not need IP mobility support; it is then more


       =
  efficient to deactivate IP mobility support for such sessions.<=
/o:p>


 


 


PS5 is about enab=
ling mobility support only to clients that need it ?

Yes.


   PS5:  Unnecessary mobility=
 support to clients that do not need it


 


       &n=
bsp; IP mobility support is usually provided to all MNs.  Yet it is


       &n=
bsp; not always required, and not every parameter of mobility


       &n=
bsp; context is always used.  For example, some applications do not


       &n=
bsp; need a stable IP address during a handover to maintain session


       &n=
bsp; continuity.  Sometimes, the entire application session runs<=
/o:p>


       &n=
bsp; while the terminal does not change the point of attachment.=



       &n=
bsp; Besides, some sessions, e.g.  SIP-based sessions, can handle=



       &n=
bsp; mobility at the application layer and hence do not need IP<=
/span>


       &n=
bsp; mobility support; it is then unnecessary to provide IP mobility


       &n=
bsp; support for such sessions.


 


 


 &nb=
sp; PS6:  (Related problem) Mobility signaling overhead with peer-to-p=
eer


 &nb=
sp;       communication


&nbs=
p;


 &nb=
sp;       Wasting resources when mobility sig=
naling (e.g., maintenance of


 &nb=
sp;       the tunnel, keep alive signaling, e=
tc.) is not turned off for


 &nb=
sp;       peer-to-peer communication.  <=
/span>Peer-to-peer communications have=



      &nbs=
p;  particular traffic patterns that often do not benefit from


      &nbs=
p;  mobility support from the network.  Thus, the associat=
ed


         mobility support s=
ignaling (e.g., maintenance of the tunnel,


         keep alive signali=
ng, etc.) wastes network resources for no


         application gain.<=
o:p>


 


So, the problem i=
s about signaling load in the network. You=
 want to minimize the signaling load in the mobility network because of the=
 Peer-to-Peer application traffic ? Ok.


Delete as sho=
wn above


 


   PS7:  (Related problem) =
Deployment with multiple mobility solutions


 


        =
; There are already many variants and extensions of MIP.


       =
  Deployment of new mobility management solutions can be


       =
  challenging, and debugging difficult, when they must co-exist


       =
  with solutions already in the field.


 


 


You mean to say, "protocols" or "solutions&q=
uot; ? 


 


Both. A ne=
w solution may not need a new protocol whereas a given protocol can be depl=
oyed in different manners.


 =
;


So, this is a section on "Problem Statement". Why=
 is this talking about a requirement ?


Delete “=
;must” which seem like a requirement.


       &n=
bsp; There are already many variants and extensions of MIP.


       &n=
bsp; Deployment of new mobility management solutions can be


       &n=
bsp; challenging, and debugging difficult, when they co-exist with


       &n=
bsp; solutions already deployed in the field.


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 10]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   PS8:  Duplicate multicas=
t traffic


 


       =
  IP multicast distribution over architectures using IP mobility<=
/o:p>


       =
  solutions (e.g., [RFC6224]) may lead to convergence of


       =
  duplicated multicast subscriptions towards the downstream=



       =
  tunnel entity (e.g.  MAG in PMIPv6).  Concretely, when


       =
  multicast subscription for individual mobile nodes is coupled


       =
  with mobility tunnels (e.g.  PMIPv6 tunnel), duplicate


       =
  multicast subscription(s) is prone to be received through=



       =
  different upstream paths.  This problem may also exist or be


       =
  more severe in a distributed mobility environment.=



 


 


5.  Requirements

 


   After comparing distributed m=
obility management against centralized


   deployment in Section 3, this=
 section identifies the following


   requirements:


 


5.1.  Distributed processing


 


   REQ1:  Distributed proce=
ssing


 


       =
   IP mobility, network access and routing solutions provided by<=
o:p>


        =
;  DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid traversing single mobility anchor


       =
   far from the optimal route.


 


       =
   Motivation: This requirement is motivated by current trends in=



        =
;  network evolution: (a) it is cost- and resource-effective to


       =
   cache and distribute content by combining distributed mobility=



       =
   anchors with caching systems (e.g., CDN); (b) the


       =
   significantly larger number of mobile nodes and flows call for=



       =
   improved scalability; (c) single points of failure are avoided=



       =
   in a distributed system; (d) threats against centrally


       =
   deployed anchors, e.g., home agent and local mobility anchor,<=
o:p>


       =
   are mitigated in a distributed system.


 


   This requirement addresses th=
e problems PS1, PS2, PS3, and PS4


   described in Section 4.<=
/o:p>


 


5.2.  Transparency to Upper Layers wh=
en needed


 


   REQ2:  Transparency to U=
pper Layers when needed


 


       =
   DMM solutions MUST provide transparent mobility support above<=
o:p>


       =
   the IP layer when needed.  Such transparency is needed, f=
or


       =
   example, when, upon change of point of attachment to the<=
/o:p>


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 11]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


       =
   network, an application flow cannot cope with a change in the<=
o:p>


       =
   IP address.  However, it is not always necessary to maint=
ain a


       =
   stable home IP address or prefix for every application or at


       =
   all times for a mobile node.


 


       =
   Motivation: The motivation of this requirement is to enable


       =
   more efficient routing and more efficient use of network<=
/o:p>


       =
   resources by selecting an IP address or prefix according to


       =
   whether mobility support is needed and by not maintaining=



       =
   context at the mobility anchor when there is no such need.


 


   This requirement addresses th=
e problem PS5 as well as the related


   problem PS6 stated in Section=
 4.


 


5.3.  IPv6 deployment


 


   REQ3:  IPv6 deployment


 


       =
   DMM solutions SHOULD target IPv6 as the primary deployment


       =
   environment and SHOULD NOT be tailored specifically to support=



       =
   IPv4, in particular in situations where private IPv4 addresses=



       =
   and/or NATs are used.


 


       =
   Motivation: This requirement conforms to the general


       =
   orientation of IETF work.  DMM deployment is foreseen in =
mid-


       =
   to long-term horizon, when IPv6 is expected to be far more


       =
   common than today.


 


   This requirement avoids the u=
nnecessarily complexity in solving the


   problems in Section 4 for IPv=
4, which will not be able to use some of


   the IPv6-specific features.


 


 


 


 


 


5.4.  Existing mobility protocols


 


   REQ4:  Existing mobility=
 protocols


 


       =
   A DMM solution SHOULD first consider reusing and extending


       =
   IETF-standardized protocols before specifying new protocols.


 


       =
   Motivation: Reuse of existing IETF work is more efficient and<=
o:p>


       =
   less error-prone.


 


   This requirement attempts to =
avoid the need of new protocols


   development and therefore the=
ir potential problems of being time-


   consuming and error-prone.


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 12]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


5.5.  Co-existence<=
/pre>

 


   REQ5:  Co-existence with=
 deployed networks and hosts


 


       =
   The DMM solution MUST be able to co-exist with existing


       =
   network deployments and end hosts.  For example, dependin=
g on


       =
   the environment in which DMM is deployed, DMM solutions may


       =
   need to be compatible with other deployed mobility protocols


       =
   or may need to co-exist with a network or mobile hosts/routers=



       =
   that do not support DMM protocols.  The mobile node may a=
lso


       =
   move between different access networks, where some of them may=



       =
   support neither DMM nor another mobility protocol.<=
/span>


       =
   Furthermore, a DMM solution SHOULD work across different<=
/o:p>


       =
   networks, possibly operated as separate administrative


       =
   domains, when allowed by the trust relationship between them.<=
o:p>


 


       =
   Motivation: (a) to preserve backwards compatibility so that


       =
   existing networks and hosts are not affected and continue to


       =
   function as usual, and (b) enable inter-domain operation if


       =
   desired.


 


   This requirement addresses th=
e related problem PS7 described in


   Section 4.<=
/pre>

 


5.6.  Security considerations


 


   REQ6:  Security consider=
ations


 


       =
   A DMM solution MUST not introduce new security risks or


       =
   amplify existing security risks against which the existing


       =
   security mechanisms/protocols cannot offer sufficient


       =
   protection.


 


       =
   Motivation: Various attacks such as impersonation, denial of


       =
   service, man-in-the-middle attacks, and so on, may be launched=



       =
   in a DMM deployment.  For instance, an illegitimate node =
may


       =
   attempt to access a network providing DMM.  Another examp=
le is


       =
   that a malicious node can forge a number of signaling messages=



       =
   thus redirecting traffic from its legitimate path.<=
/span>


       =
   Consequently, the specific node is under a denial of service


       =
   attack, whereas other nodes do not receive their traffic.=



       =
   Accordingly, security mechanisms/protocols providing access


       =
   control, integrity, authentication, authorization,<=
/span>


       =
   confidentiality, etc. can be used to protect the DMM entities<=
o:p>


       =
   as they are already used to protect against existing networks<=
o:p>


       =
   and existing mobility protocols defined in IETF.


 


   This requirement prevents a D=
MM solution from introducing


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 13]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   uncontrollable problems of po=
tentially insecure mobility management


   protocols which make deployme=
nt infeasible because platforms


   conforming to the protocols a=
re at risk for data loss and numerous


   other dangers, including fina=
ncial harm to the users.


 


 


 


 


 


5.7.  Multicast

 


   REQ7:  Multicast conside=
rations


 


       =
   DMM SHOULD consider multicast early so that solutions can be


       =
   developed not only to provide IP mobility support when it is


       =
   needed, but also to avoid network inefficiency issues in<=
/o:p>


       =
   multicast traffic delivery (such as duplicate multicast


       =
   subscriptions towards the downstream tunnel entities).  T=
he


       =
   multicast solutions should therefore avoid restricting the


       =
   management of all IP multicast traffic to a single host


       =
   through a dedicated (tunnel) interface on multicast-capable


       =
   access routers.


 


       =
   Motivation: Existing multicast deployment have been introduced=



       =
   after completing the design of the reference mobility


       =
   protocol, then optimization and extensions have been followed<=
o:p>


       =
   by "patching-up" procedure, thus leading to network<=
o:p>


       =
   inefficiency and non-optimal routing.  The multicast solu=
tions


       =
   should therefore be required to consider efficiency nature in<=
o:p>


       =
   multicast traffic delivery.


 


[Sri] Considering=
 multicast at a design phase is not technical requirement for DMM.


What is "pat=
ching up" procedure ? 


 


Revise as fol=
lows:


   REQ7:  Multicast considera=
tions


 


       &n=
bsp;  DMM SHOULD enable multicast solutions to be developed to avoid


       &n=
bsp;  network inefficiency in multicast traffic delivery.


 


       &n=
bsp;  Motivation: Existing multicast deployment have been introduced


       &n=
bsp;  after completing the design of the reference mobility=



       &n=
bsp;  protocol, often leading to network inefficiency and non-


       &n=
bsp;  optimal routing for the multicast traffic.  Instead DMM sho=
uld


       &n=
bsp;  consider multicast early so that the multicast solutions can


       &n=
bsp;  better consider efficiency nature in the multicast traffic<=
/o:p>


       &n=
bsp;  delivery (such as duplicate multicast subscriptions towards=



       &n=
bsp;  the downstream tunnel entities).  The multicast solutions


       &n=
bsp;  should then avoid restricting the management of all IP


       &n=
bsp;  multicast traffic to a single host through a dedicated


       &n=
bsp;  (tunnel) interface on multicast-capable access routers.


 


 


   This requirement addresses th=
e problems PS1 and PS8 described in


   Section 4.<=
/pre>

 


 


6.  Security Considerations


 


   Please refer to the discussio=
n under Security requirement in Section


   5.6.


 


 


7.  IANA Considerations


 


   None


 


 


8.  Co-authors and Contributors<=
/o:p>


 


   This problem statement docume=
nt is a joint effort among the numerous


   participants.  Each indi=
vidual has made significant contributions to


   this work and have been liste=
d as co-authors.


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 14]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


9.  References

 


9.1.  Normative References=



 


   [RFC2119]  Bradner, S., =
"Key words for use in RFCs to Indicate


       =
       Requirement Levels", BCP 14, RFC =
2119, March 1997.


 


9.2.  Informative References


 


   [I-D.bhandari-dhc-class-based=
-prefix]


       =
       Bhandari, S., Halwasia, G., Gundavelli=
, S., Deng, H.,


       =
       Thiebaut, L., Korhonen, J., and I. Far=
rer, "DHCPv6 class


       =
       based prefix", draft-bhandari-dhc=
-class-based-prefix-05


       =
       (work in progress), July 2013.


 


   [I-D.korhonen-6man-prefix-pro=
perties]


       =
       Korhonen, J., Patil, B., Gundavelli, S=
., Seite, P., and D.


       =
       Liu, "IPv6 Prefix Properties"=
;,


       =
       draft-korhonen-6man-prefix-properties-=
02 (work in


       =
       progress), July 2013.


 


   [I-D.wakikawa-netext-pmip-cp-=
up-separation]


       =
       Wakikawa, R., Pazhyannur, R., and S. G=
undavelli,


       =
       "Separation of Control and User P=
lane for Proxy Mobile


       =
       IPv6", draft-wakikawa-netext-pmip=
-cp-up-separation-00


       =
       (work in progress), July 2013.


 


   [I-D.yokota-dmm-scenario]


       =
       Yokota, H., Seite, P., Demaria, E., an=
d Z. Cao, "Use case


       =
       scenarios  for Distributed Mobili=
ty Management",


       =
       draft-yokota-dmm-scenario-00 (work in =
progress),


       =
       October 2010.


 


   [Paper-Distributed.Centralize=
d.Mobility]


       =
       Bertin, P., Bonjour, S., and J-M. Bonn=
in, "A Distributed


       =
       or Centralized Mobility",  P=
roceedings of Global


       =
       Communications Conference  (Globe=
Com), December 2009.


 


   [Paper-Distributed.Dynamic.Mo=
bility]


       =
       Bertin, P., Bonjour, S., and J-M. Bonn=
in, "A Distributed


       =
       Dynamic Mobility Management Scheme&nbs=
p; Designed for Flat IP


       =
       Architectures",  Proceedings=
 of 3rd International


       =
       Conference  on New Technologies, =
Mobility and Security


       =
       (NTMS), 2008.


 


   [Paper-Distributed.Mobility.M=
IP]


       =
       Chan, H., "Distributed Mobility M=
anagement with Mobile


       =
       IP",  Proceedings of  I=
EEE International Communication


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 15]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


       =
       Conference (ICC)  Workshop on Tel=
ecommunications:  from


        =
;      Research to Standards, June 2012.=



 


   [Paper-Distributed.Mobility.P=
MIP]


       =
       Chan, H., "Proxy Mobile IP  =
with Distributed Mobility


       =
       Anchors",  Proceedings of Gl=
obeCom Workshop  on Seamless


       =
       Wireless Mobility, December 2010.=



 


   [Paper-Distributed.Mobility.R=
eview]


       =
       Chan, H., Yokota, H., Xie, J., Seite, =
P., and D. Liu,


       =
       "Distributed and Dynamic Mobility=
 Management  in Mobile


       =
       Internet: Current Approaches and Issue=
s, Journal of


       =
       Communications, vol. 6, no. 1, pp. 4-1=
5, Feb 2011.",


       =
        Proceedings of GlobeCom Workshop=
  on Seamless Wireless


       =
       Mobility, February 2011.


 


   [Paper-Distributed.Mobility.S=
AE]


       =
       Fisher, M., Anderson, F., Kopsel, A., =
Schafer, G., and M.


       =
       Schlager, "A Distributed IP Mobil=
ity Approach for 3G SAE",


       =
        Proceedings of the 19th Internat=
ional Symposium  on


       =
       Personal, Indoor and Mobile Radio Comm=
unications (PIMRC),


       =
       2008.


 


   [Paper-Locating.User]


       =
       Kirby, G., "Locating the User&quo=
t;,  Communication


       =
       International, 1995.=



 


   [Paper-Migrating.Home.Agents]=



       =
       Wakikawa, R., Valadon, G., and J. Mura=
i, "Migrating Home


       =
       Agents  Towards Internet-scale Mo=
bility Deployments",


       =
        Proceedings of the ACM 2nd CoNEX=
T Conference  on Future


       =
       Networking Technologies, December 2006=
.


 


   [Paper-Mobile.Data.Offloading=
]


       =
       Lee, K., Lee, J., Yi, Y., Rhee, I., an=
d S. Chong, "Mobile


       =
       Data Offloading: How Much Can WiFi Del=
iver?",  SIGCOMM


       =
       2010, 2010.


 


   [RFC3753]  Manner, J. an=
d M. Kojo, "Mobility Related Terminology",

       =
       RFC 3753, June 2004.=



 


   [RFC5213]  Gundavelli, S=
., Leung, K., Devarapalli, V., Chowdhury, K.,


       =
       and B. Patil, "Proxy Mobile IPv6&=
quot;, RFC 5213, August 2008.


 


   [RFC5380]  Soliman, H., =
Castelluccia, C., ElMalki, K., and L.


       =
       Bellier, "Hierarchical Mobile IPv=
6 (HMIPv6) Mobility


       =
       Management", RFC 5380, October 20=
08.


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 16]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   [RFC5944]  Perkins, C., =
"IP Mobility Support for IPv4, Revised",


       =
       RFC 5944, November 2010.


 


   [RFC6224]  Schmidt, T., =
Waehlisch, M., and S. Krishnan, "Base


       =
       Deployment for Multicast Listener Supp=
ort in Proxy Mobile


       =
       IPv6 (PMIPv6) Domains", RFC 6224,=
 April 2011.


 


   [RFC6275]  Perkins, C., =
Johnson, D., and J. Arkko, "Mobility Support


       =
       in IPv6", RFC 6275, July 2011.


 


   [RFC6301]  Zhu, Z., Waki=
kawa, R., and L. Zhang, "A Survey of Mobility


       =
       Support in the Internet", RFC 630=
1, July 2011.


 


   [RFC6705]  Krishnan, S.,=
 Koodli, R., Loureiro, P., Wu, Q., and A.


       =
       Dutta, "Localized Routing for Pro=
xy Mobile IPv6",


       =
       RFC 6705, September 2012.


 


   [RFC6909]  Gundavelli, S=
., Zhou, X., Korhonen, J., Feige, G., and R.


       =
       Koodli, "IPv4 Traffic Offload Sel=
ector Option for Proxy


       =
       Mobile IPv6", RFC 6909, April 201=
3.


 


   [TS.23.401]=



       =
       3GPP, "General Packet Radio Servi=
ce (GPRS) enhancements


       =
       for Evolved Universal Terrestrial Radi=
o Access Network


       =
       (E-UTRAN) access", 3GPP TR 23.401=
 10.10.0, March 2013.


 


   [TS.29303]<=
/pre>

       =
       3GPP, "Domain Name System Procedu=
res; Stage 3", 3GPP


       =
       TR 23.303 11.2.0, September 2012.=



 


 


Authors' Addresses


 


   H Anthony Chan (editor)<=
/o:p>


   Huawei Technologies (more co-=
authors on P. 17)


   5340 Legacy Dr. Building 3, P=
lano, TX 75024, USA


   Email: h.a.chan@ieee.org


 


 


   Dapeng Liu<=
/pre>

   China Mobile


   Unit2, 28 Xuanwumenxi Ave, Xu=
anwu District, Beijing 100053, China


   Email: liudapeng@chinamobile.com

 


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 17]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   Pierrick Seite


   Orange

   4, rue du Clos Courtel, BP 91=
226, Cesson-Sevigne 35512, France


   Email: pierrick.seite@orange.com

 


 


   Hidetoshi Yokota


   KDDI Lab

   2-1-15 Ohara, Fujimino, Saita=
ma, 356-8502 Japan


   Email: yokota@kddilabs.jp


 


 


   Jouni Korhonen


   Renesas Mobile


   Porkkalankatu 24, FIN-00180 H=
elsinki, Finland


   Email: jouni.korhonen@nsn.com


   -


   Charles E. Perkins=



   Huawei Technologies


   Email: charliep@computer.org


   -


   Melia Telemaco


   Alcatel-Lucent Bell Labs=



   Email: telemaco.melia@alcatel-lucent.com


   -


   Elena Demaria


   Telecom Italia


   via G. Reiss Romoli, 274, TOR=
INO, 10148, Italy


   Email: elena.demaria@telecomitalia.it


   -


   Jong-Hyouk Lee


   Sangmyung University


   Email: hurryon@gmail.com


   -


   Kostas Pentikousis=



   EICT GmbH

   Email: k.pentikousis@eict.de


   -


   Tricci So

   ZTE


   Email: tso@zteusa.com


   -


   Carlos J. Bernardos


   Universidad Carlos III de Mad=
rid


   Av. Universidad, 30, Leganes,=
 Madrid 28911, Spain


   Email: cjbc@it.uc3m.es


   -


   Peter McCann


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 18]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   Huawei Technologies


   Email: PeterMcCann@huawei.com


   -


   Seok Joo Koh


   Kyungpook National University=
, Korea


   Email: sjkoh@knu.ac.kr


   -


   Wen Luo

   ZTE


   No.68, Zijinhua RD,Yuhuatai D=
istrict, Nanjing, Jiangsu 210012, China


   Email: luo.wen@zte.com.cn


   -


   Sri Gundavelli


   Cisco


   sgundave@cisco.com


   -


   Marco Liebsch


   NEC Laboratories Europe<=
/o:p>


   Email: liebsch@neclab.eu


   -


   Carl Williams


   MCSR Labs

   Email: carlw@mcsr-labs.org


   -


   Seil Jeon

   Instituto de Telecomunicacoes=
, Aveiro


   Email: seiljeon@av.it.pt


   -


   Sergio Figueiredo<=
/span>


   Universidade de Aveiro


   Email: sfigueiredo@av.it.pt


   -


   Stig Venaas=



   Email: stig@venaas.com


   -


   Luis Miguel Contreras Murillo=



   Telefonica I+D=



   Email: lmcm@tid.es


   -


   Juan Carlos Zuniga=



   InterDigital


   Email: JuanCarlos.Zuniga@InterDigital.com=



   -


   Alexandru Petrescu=



   Email: alexandru.petrescu@gmail.com


   -


   Georgios Karagiannis


   University of Twente


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 19]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   Email: g.karagiannis@utwente.nl


   -


   Julien Laganier


   Juniper

   jlaganier@juniper.net


   -


   Wassim Michel Haddad


   Ericsson

   Wassam.Haddad@ericsson.com


   -


   Dirk von Hugo


   Deutsche Telekom Laboratories=



   Dirk.von-Hugo@telekom.de


   -


   Ahmad Muhanna


   Award Solutions


   amuhanna@awardsolutions.com


   -


   Byoung-Jo Kim


   ATT Labs

   macsbug@research.att.com


   -


   Hassan Ali-Ahmad


   Orange

   hassan.aliahmad@orange.com


   -


   Alper Yegin=



   Samsung

   alper.yegin@partner.samsung.com=



   -


 


 


 


 


 


 


 


 


 


 


 


 


 


 








--_000_6E31144C030982429702B11D6746B98C370E6FAEszxeml557mbxchi_--


From h.anthony.chan@huawei.com  Wed Nov 20 09:58:16 2013
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 7D3801AE103 for ; Wed, 20 Nov 2013 09:58:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.125
X-Spam-Level: 
X-Spam-Status: No, score=-4.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 7nnc9t0lSxNe for ; Wed, 20 Nov 2013 09:57:58 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C49D91AE0ED for ; Wed, 20 Nov 2013 09:57:56 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAN48778; Wed, 20 Nov 2013 17:57:49 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 17:57:39 +0000
Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 20 Nov 2013 17:57:46 +0000
Received: from szxeml557-mbx.china.huawei.com ([169.254.5.240]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.03.0158.001; Thu, 21 Nov 2013 01:57:43 +0800
From: h chan 
To: "Sri Gundavelli (sgundave)" , "dmm@ietf.org" 
Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
Thread-Index: AQHO4+QmJlal5lHHLUm+Lx6MsJ7x35otWlgAgAERWaA=
Date: Wed, 20 Nov 2013 17:57:43 +0000
Message-ID: <6E31144C030982429702B11D6746B98C370E7086@szxeml557-mbx.china.huawei.com>
References: <6E31144C030982429702B11D6746B98C370CBC1C@szxeml557-mbx.china.huawei.com>  
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.192.11.200]
Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C370E7086szxeml557mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
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, 20 Nov 2013 17:58:16 -0000

--_000_6E31144C030982429702B11D6746B98C370E7086szxeml557mbxchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

After checking the definitions section, the following definition is changed=
 as follows:

   Distributed mobility management



      is not centralized so that traffic does not need to traverse

      centrally deployed mobility anchors.
Change to:
   Distributed mobility management

      is not centralized so that traffic does not need to traverse
      centrally deployed mobility anchors far from the optimal route.

H Anthony Chan

From: h chan
Sent: Tuesday, November 19, 2013 8:12 PM
To: 'Sri Gundavelli (sgundave)'; dmm@ietf.org
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Sri,
Suggested revisions are shown in blue below.
Not sure about what improvements are desired for the definitions though.

H Anthony Chan

From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]
Sent: Sunday, November 17, 2013 4:27 PM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Hi Anthony,

Thanks for revising the draft. Following are some more comments on the docu=
ment. I'm not holding this document any more. What ever comments you can ad=
dress ... or you can choose not to revise ...

Please see inline.

Regards
Sri


From: h chan >
Date: Wednesday, September 25, 2013 9:49 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt


Sri,

Thanks for the comments. We are replying under different sections in separa=
te emails.







Network Working Group                                      H. Chan (Ed.)

Internet-Draft                                 Huawei Technologies (more

Intended status: Informational                      co-authors on P. 17)

Expires: May 11, 2014                                             D. Liu

                                                            China Mobile

                                                                P. Seite

                                                                  Orange

                                                               H. Yokota

                                                                KDDI Lab

                                                             J. Korhonen

                                                          Renesas Mobile

                                                        November 7, 2013





            Requirements for Distributed Mobility Management

                     draft-ietf-dmm-requirements-10



Abstract



   This document defines the requirements for Distributed Mobility

   Management (DMM).  The hierarchical structure in traditional wireless

   networks has led primarily to centralized deployment models.  As some

   wireless networks are evolving away from the hierarchical structure,

   such as in moving the content delivery servers closer to the users, a

   distributed model for mobility management can be useful to them.





[Sri] Not sure, what the "hierarchical structure in traditional wireless" m=
eans.

There are two aspects here:



1.) There is the aspect of distributed mobility deployment model for all th=
e reasons that the document talks about

2.) There is the other aspect of hosting content servers closer to the subs=
criber



I'm not able to draw the relation between "moving content to the access" an=
d the shift from centralized to distributed model. I understand you want to=
 say today there are central anchors where subscriber sessions are hosted. =
All the traffic from the mobile node's is brought to the central location/a=
nchor for service enablement and including content access. An alternative m=
odel is to distribute the anchors, localize the traffic and enable the asso=
ciated services to local anchors. You may want to re-write the text if you =
want to get that right.



Let us delete "such as in moving the content delivery servers closer to the=
 users,"

Then the abstract becomes:

Abstract



   This document defines the requirements for Distributed Mobility

   Management (DMM).  The hierarchical structure in traditional wireless

   networks has led primarily to centralized deployment models.  As some

   wireless networks are evolving away from the hierarchical structure,

   a

   distributed model for mobility management can be useful to them.











Requirements Language



   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this

   document are to be interpreted as described in RFC 2119 RFC 2119

   [RFC2119].



Status of this Memo



   This Internet-Draft is submitted in full conformance with the

   provisions of BCP 78 and BCP 79.



   Internet-Drafts are working documents of the Internet Engineering

   Task Force (IETF).  Note that other groups may also distribute

   working documents as Internet-Drafts.  The list of current Internet-

   Drafts is at http://datatracker.ietf.org/drafts/current/.



   Internet-Drafts are draft documents valid for a maximum of six months

   and may be updated, replaced, or obsoleted by other documents at any

   time.  It is inappropriate to use Internet-Drafts as reference

   material or to cite them other than as "work in progress."









Chan (Ed.), et al.        Expires May 11, 2014                  [Page 1]



Internet-Draft                  DMM-Reqs                   November 2013





   This Internet-Draft will expire on May 11, 2014.



Copyright Notice



   Copyright (c) 2013 IETF Trust and the persons identified as the

   document authors.  All rights reserved.



   This document is subject to BCP 78 and the IETF Trust's Legal

   Provisions Relating to IETF Documents

   (http://trustee.ietf.org/license-info) in effect on the date of

   publication of this document.  Please review these documents

   carefully, as they describe your rights and restrictions with respect

   to this document.  Code Components extracted from this document must

   include Simplified BSD License text as described in Section 4.e of

   the Trust Legal Provisions and are provided without warranty as

   described in the Simplified BSD License.







































































Chan (Ed.), et al.        Expires May 11, 2014                  [Page 2]



Internet-Draft                  DMM-Reqs                   November 2013





Table of Contents



   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Conventions used in this document  . . . . . . . . . . . . . .  6

     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Centralized versus distributed mobility management . . . . . .  7

     3.1.  Centralized mobility management  . . . . . . . . . . . . .  7

     3.2.  Distributed mobility management  . . . . . . . . . . . . .  8

   4.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  9

   5.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 11

     5.1.  Distributed processing . . . . . . . . . . . . . . . . . . 11

     5.2.  Transparency to Upper Layers when needed . . . . . . . . . 11

     5.3.  IPv6 deployment  . . . . . . . . . . . . . . . . . . . . . 12

     5.4.  Existing mobility protocols  . . . . . . . . . . . . . . . 12

     5.5.  Co-existence . . . . . . . . . . . . . . . . . . . . . . . 13

     5.6.  Security considerations  . . . . . . . . . . . . . . . . . 13

     5.7.  Multicast  . . . . . . . . . . . . . . . . . . . . . . . . 14

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14

   8.  Co-authors and Contributors  . . . . . . . . . . . . . . . . . 14

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15

     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15

     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17























































Chan (Ed.), et al.        Expires May 11, 2014                  [Page 3]



Internet-Draft                  DMM-Reqs                   November 2013





1.  Introduction



   In the past decade a fair number of mobility protocols have been

   standardized [RFC6275] [RFC5944] [RFC5380] [RFC6301] [RFC5213].

   Although the protocols differ in terms of functions and associated

   message formats, they all employ a mobility anchor to allow a mobile

   node to remain reachable after it has moved to a different network.

   The anchor point, among other tasks, ensures connectivity by

   forwarding packets destined to, or sent from, the mobile node.  It is

   a centrally deployed mobility anchor in the sense that the deployed

   architectures today have a small number of these anchors and the

   traffic of millions of mobile nodes in an operator network are

   typically managed by the same anchor.



   Distributed mobility management (DMM) is an alternative to the above

   centralized deployment.  The background behind the interests to study

   DMM are primarily in the following.



   (1)  Mobile users are, more than ever, consuming Internet content;

        such traffic imposes new requirements on mobile core networks

        for data traffic delivery.  The presence of content providers

        closer to Internet Service Providers (ISP) network requires

        taking into account local Content Delivery Networks (CDNs) while

        providing mobility services.  Moreover, when the traffic demand

        exceeds available capacity, service providers need to implement

        new strategies such as selective IPv4 traffic offload (e.g.

        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through

        alternative access networks (e.g.  WLAN) [Paper-

        Mobile.Data.Offloading].  A gateway selection mechanism also

        takes the user proximity into account within EPC [TS.29303].

        These mechanisms were not pursued in the past owing to charging

        and billing reasons.  Assigning a gateway anchor node from a

        visited network in roaming scenario has until recently been done

        and are limited to voice services only.  Charging and billing

        require solutions beyond the mobility protocol.





[Sri] Some valid points above. But, IMHO, its not organized correctly.

My only comment with this document is that this has text from multiple peop=
le with different goals, but is not organized poorly.



Reminds me of some SDO documents. There the document starts with a blank te=
mplate, every company spits a line or two and in no time, the document grow=
s like a monster, but there is no relation between two lines of text in the=
 same paragraph. No offense.



Rearrange as follows:


   (1)  Mobile users are, more than ever, consuming Internet content
        including that of local Content Delivery Networks (CDNs) which
        had not taken mobility service into account before.  Such
        traffic imposes new requirements on mobile core networks for
        data traffic delivery.  To prevent exceeding the available core
        network capacity, service providers need to implement new
        strategies such as selective IPv4 traffic offload (e.g.
        [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through
        alternative access networks (e.g.  WLAN) [Paper-
        Mobile.Data.Offloading].  In addition, a gateway selection
        mechanism takes the user proximity into account within EPC
        [TS.29303].  Yet these mechanisms were not pursued in the past
        owing to charging and billing which require solutions beyond the
        mobility protocol.  Consequently, assigning a gateway anchor
        node from a visited network in roaming scenario has until
        recently been done and are limited to voice services only.







        Both traffic offloading and CDN mechanisms could benefit from

        the development of mobile architectures with fewer levels of

        routing hierarchy introduced into the data path by the mobility

        management system.  This trend towards so-called "flat networks"

        works best for direct communications among peers in the same

        geographical area.  Distributed mobility management in a truly

        flat mobile architecture would anchor the traffic closer to the

        point of attachment of the user.















Chan (Ed.), et al.        Expires May 11, 2014                  [Page 4]



Internet-Draft                  DMM-Reqs                   November 2013





   (2)  Today's mobile networks present service providers with new

        challenges.  Mobility patterns indicate that mobile nodes often

        remain attached to the same point of attachment for considerable

        periods of time [Paper-Locating.User].  Specific IP mobility

        management support is not required for applications that launch

        and complete their sessions while the mobile node is connected

        to the same point of attachment.  However, currently, IP

        mobility support is designed for always-on operation,

        maintaining all parameters of the context for each mobile

        subscriber for as long as they are connected to the network.

        This can result in a waste of resources and unnecessary costs

        for the service provider.  Infrequent node mobility coupled with

        application intelligence suggest that mobility support could be

        provided selectively such as in [I-D.bhandari-dhc-class-based-

        prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing

        the amount of context maintained in the network.





Let us delete the following, which don't seem necessary. The requirements a=
lready have the problem statements to support them.

   In addition, considerations in the study of DMM are in the following.



   (1)  To optimize handovers from the perspective of mobile nodes, the

        base protocols have been extended to efficiently handle packet

        forwarding between the previous and new points of attachment.

        These extensions are necessary when applications have stringent

        requirements in terms of delay.  Notions of localization and

        distribution of local agents have been introduced to reduce

        signaling overhead at the centralized routing anchor point

        [Paper-Distributed.Centralized.Mobility].  Unfortunately, such

        protocols have not been deployed today.



   (2)  Most existing mobility protocols have not been designed for

        multiple-interface hosts which are capable to use multiple

        interfaces simultaneously.  Retrofitting the required

        functionality can result in an unnecessary increase in the

        protocol complexity.





RFC5648.

Not sure. I agree about the complexity. Any case, this is not a DMM require=
ment







   (3)  IP multicast support, including optimizations, have been

        introduced as an effective transport method for multimedia data

        delivery, but by "patching-up" procedure after completing the

        design of reference mobility protocol, leading to network

        inefficiency and non-optimal routing.





I dont understand this.





   The distributed mobility management (DMM) charter addresses two

   complementary aspects of mobility management procedures: the

   distribution of mobility anchors in the data-plane towards a more

   flat network and the selective activation/deactivation of mobility

   protocol support as an enabler to distributed mobility management.

   The former aims at positioning mobility anchors (e.g., HA, LMA)

   closer to the user; ideally, mobility agents could be collocated with







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 5]



Internet-Draft                  DMM-Reqs                   November 2013





   the first-hop router.  The latter, facilitated by the distribution of

   mobility anchors, identifies when mobility support must be activated

   and when sessions do not require mobility management support -- thus

   reducing the amount of state information that must be maintained in

   various mobility agents of the mobile network.  It can then avoid the

   unnecessary establishment of mechanisms to forward traffic from an

   old to a new mobility anchor.



   This document compares distributed mobility management with

   centralized mobility management in Section 3.  The problems that can

   be addressed with DMM are summarized in Section 4.  The mandatory

   requirements as well as the optional requirements are given in

   Section 5.  Finally, security considerations are discussed in Section

   6.



   The problem statement and the use cases [I-D.yokota-dmm-scenario] can

   be found in [Paper-Distributed.Mobility.Review].





2.  Conventions used in this document



2.1.  Terminology



   All the general mobility-related terms and their acronyms used in

   this document are to be interpreted as defined in the Mobile IPv6

   base specification [RFC6275], in the Proxy mobile IPv6 specification

   [RFC5213], and in Mobility Related Terminology [RFC3753].  These

   terms include the following: mobile node (MN), correspondent node

   (CN), and home agent (HA) as per [RFC6275]; local mobility anchor

   (LMA) and mobile access gateway (MAG) as per [RFC5213], and context

   as per [RFC3753].



   In addition, this draft introduces the following terms.



   Centrally deployed mobility anchors



      refer to the mobility management deployments in which there are

      very few mobility anchors and the traffic of millions of mobile

      nodes in an operator network are managed by the same anchor.



   Centralized mobility management



      makes use of centrally deployed mobility anchors.



   Distributed mobility management



      is not centralized so that traffic does not need to traverse

      centrally deployed mobility anchors.







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 6]



Internet-Draft                  DMM-Reqs                   November 2013





   Flat mobile network



      has few levels of routing hierarchy introduced into the data path

      by the mobility management system.







   Mobility context



      is the collection of information required to provide mobility

      management support for a given mobile node.





You can improve the terminology section

Not sure whether you want to better define these terms or whether some defi=
nitions are missing?



3.  Centralized versus distributed mobility management



   Mobility management functions may be implemented at different layers

   of the protocol stack.  At the IP (network) layer, mobility

   management can be client-based or network-based.



   An IP-layer mobility management protocol is typically based on the

   principle of distinguishing between session identifier and routing

   address and maintaining a mapping between the two.  In Mobile IP, the

   home address serves as the session identifier whereas the care-of-

   address (CoA) takes the role of the routing address.  The binding

   between these two is maintained at the home agent (mobility anchor).

   If packets addressed to the home address of a mobile node can be

   continuously delivered to the node, then all sessions using that home

   address are unaffected even though the routing address (CoA) changes.



   The next two subsections explain centralized and distributed mobility

   management functions in the network.



3.1.  Centralized mobility management



   In centralized mobility management, the mapping information between

   the session identifier and the locator IP address of a mobile node

   (MN) is kept at a single mobility anchor.  At the same time, packets

   destined to the MN are routed via this anchor.  In other words, such

   mobility management systems are centralized in both the control plane

   and the data plane (mobile node IP traffic).



   Many existing mobility management deployments make use of centralized

   mobility anchoring in a hierarchical network architecture, as shown

   in Figure 1.  Examples of such centralized mobility anchors are the

   home agent (HA) and local mobility anchor (LMA) in Mobile IPv6

   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.  Current

   cellular networks such as the Third Generation Partnership Project

   (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Packet System

   (EPS) networks employ centralized mobility management too.  In

   particular, the Gateway GPRS Support Node (GGSN), Serving GPRS







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 7]



Internet-Draft                  DMM-Reqs                   November 2013





   Support Node (SGSN) and Radio Network Controller (RNC) in the 3GPP

   GPRS hierarchical network, and the Packet Data Network Gateway (P-GW)

   and Serving Gateway (S-GW) in the 3GPP EPS network all act as anchors

   in a hierarchy.





         3G GPRS                 3GPP EPS                MIP/PMIP

         +------+                +------+                +------+

         | GGSN |                | P-GW |                |HA/LMA|

         +------+                +------+                +------+

            /\                      /\                      /\

           /  \                    /  \                    /  \

          /    \                  /    \                  /    \

         /      \                /      \                /      \

        /        \              /        \              /        \

       /          \            /          \            /          \

      /            \          /            \          /            \

  +------+      +------+  +------+      +------+  +------+      +------+

  | SGSN |      | SGSN |  | S-GW |      | S-GW |  |MN/MAG|      |MN/MAG|

  +------+      +------+  +------+      +------+  +------+      +------+

     /\            /\

    /  \          /  \

   /    \        /    \

+---+  +---+  +---+  +---+

|RNC|  |RNC|  |RNC|  |RNC|

+---+  +---+  +---+  +---+



   Figure 1.  Centralized mobility management.



3.2.  Distributed mobility management



   Mobility management functions may also be distributed to multiple

   networks as shown in Figure 2, so that a mobile node in any of these

   networks may be served by a nearby mobility function (MF).





                    +------+  +------+  +------+  +------+

                    |  MF  |  |  MF  |  |  MF  |  |  MF  |

                    +------+  +------+  +------+  +------+

                                           |

                                         +----+

                                         | MN |

                                         +----+



   Figure 2.  Distributed mobility management.



   Mobility management may be partially or fully distributed

   [I-D.yokota-dmm-scenario].  In the former case only the data plane is







Chan (Ed.), et al.        Expires May 11, 2014                  [Page 8]



Internet-Draft                  DMM-Reqs                   November 2013





   distributed, implicitly assuming separation of data and control

   planes as described in [I-D.wakikawa-netext-pmip-cp-up-separtion].

   Fully distributed mobility management implies that both the data

   plane and the control plane are distributed.  While mobility

   management can be distributed, it is not necessary for other

   functions such as subscription management, subscription database, and

   network access authentication to be similarly distributed.



   A distributed mobility management scheme for a flat mobile network of

   access nodes is proposed in [Paper-Distributed.Dynamic.Mobility].

   Its benefits over centralized mobility management are shown through

   simulations in [Paper-Distributed.Centralized.Mobility].  Moreover,

   the (re)use and extension of existing protocols in the design of both

   fully distributed mobility management [Paper-Migrating.Home.Agents]

   [Paper-Distributed.Mobility.SAE] and partially distributed mobility

   management [Paper-Distributed.Mobility.PMIP] [Paper-

   Distributed.Mobility.MIP] have been reported in the literature.

   Therefore, before designing new mobility management protocols for a

   future distributed architecture, it is recommended to first consider

   whether existing mobility management protocols can be extended.





4.  Problem Statement



   The problems that can be addressed with DMM are summarized in the

   following:



   PS1:  Non-optimal routes



         Routing via a centralized anchor often results in non-optimal

         routes, thereby increasing the end-to-end delay.  The problem

         is manifested, for example, when accessing a nearby server or

         servers of a Content Delivery Network (CDN), or when receiving

         locally available IP multicast or sending IP multicast packets.

         (Existing route optimization is only a host-based solution.  On

         the other hand, localized routing with PMIPv6 [RFC6705]

         addresses only a part of the problem where both the MN and the

         CN are located in the PMIP domain and attached to a MAG, and is

         not applicable when the CN is outside the PMIP domain or does

         not behave like an MN.)



You argue for optimized route when accessing a CDN server in the local netw=
ork. But you say that the localized routing schemes don't work when the CN =
is outside the PMIP domain. What is the point ? When the CN is outside the =
PMIP domain, where is optimized route possibility ?



So, PS1 is about optimized routing requirement in DMM. Even though the docu=
ment fails to make the case that the current models have an issue, I'm OK w=
ith optimized routing goal for DMM in general terms.



Revise as follows:

         Routing via a centralized anchor often results in non-optimal
         routes, thereby increasing the end-to-end delay.  The problem
         is manifested, for example, when accessing a nearby server or
         servers of a Content Delivery Network (CDN), or when receiving
         locally available IP multicast or sending IP multicast packets.
         (Existing route optimization is only a host-based solution.  On
         the other hand, localized routing with PMIPv6 [RFC6705]
         addresses only a part of the problem where both the MN and the
         CN are attached to the same MAG, and it is not applicable when
         the CN does not behave like an MN.)







   PS2:  Divergence from other evolutionary trends in network

         architectures such as distribution of content delivery.





         Centralized mobility management can become non-optimal with a

         flat network architecture.





So, this is "non-optimizal" because traffic has to hit the central anchor ?=
 Is it not same as PS1 ? Please add few lines of text

Revise as follows:
         Mobile networks have generally been evolving towards a flat
         network.  Centralized mobility management, which is non-optimal
         with a flat network architecture, does not support this
         evolution.









Chan (Ed.), et al.        Expires May 11, 2014                  [Page 9]



Internet-Draft                  DMM-Reqs                   November 2013





   PS3:  Low scalability of centralized tunnel management and mobility

         context maintenance



         Setting up tunnels through a central anchor and maintaining

         mobility context for each MN usually requires more concentrated

         resources in a centralized design, thus reducing scalability.

         Distributing the tunnel maintenance function and the mobility

         context maintenance function among different network entities

         with proper signaling protocol design can increase scalability.





Its not scalable because it requires lot of "concentrated resources" ? But,=
 distributing them allows it to scale. Not very convincing argument



We can revise as follows:
   PS3:  Scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN usually requires more concentrated
         resources in a centralized design, thus reducing scalability.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can avoid increasing the
         concentrated resources with an increasing number of MNs.







   PS4:  Single point of failure and attack



         Centralized anchoring designs may be more vulnerable to single

         points of failures and attacks than a distributed system.  The

         impact of a successful attack on a system with centralized

         mobility management can be far greater as well.





   PS5:  Unnecessary mobility support to nodes that do not need it



         IP mobility support is not always required, and not every

         parameter of mobility context is always used.  For example,

         some applications do not need a stable IP address during a

         handover to maintain session continuity.  Sometimes, the entire

         application session runs while the terminal does not change the

         point of attachment.  Besides, some sessions, e.g.  SIP-based

         sessions, can handle mobility at the application layer and

         hence do not need IP mobility support; it is then more

         efficient to deactivate IP mobility support for such sessions.





PS5 is about enabling mobility support only to clients that need it ?

Yes.
   PS5:  Unnecessary mobility support to clients that do not need it

         IP mobility support is usually provided to all MNs.  Yet it is
         not always required, and not every parameter of mobility
         context is always used.  For example, some applications do not
         need a stable IP address during a handover to maintain session
         continuity.  Sometimes, the entire application session runs
         while the terminal does not change the point of attachment.
         Besides, some sessions, e.g.  SIP-based sessions, can handle
         mobility at the application layer and hence do not need IP
         mobility support; it is then unnecessary to provide IP mobility
         support for such sessions.





   PS6:  (Related problem) Mobility signaling overhead with peer-to-peer

         communication



         Wasting resources when mobility signaling (e.g., maintenance of

         the tunnel, keep alive signaling, etc.) is not turned off for

         peer-to-peer communication.  Peer-to-peer communications have

         particular traffic patterns that often do not benefit from

         mobility support from the network.  Thus, the associated

         mobility support signaling (e.g., maintenance of the tunnel,

         keep alive signaling, etc.) wastes network resources for no

         application gain.



So, the problem is about signaling load in the network. You want to minimiz=
e the signaling load in the mobility network because of the Peer-to-Peer ap=
plication traffic ? Ok.

Delete as shown above



   PS7:  (Related problem) Deployment with multiple mobility solutions



         There are already many variants and extensions of MIP.

         Deployment of new mobility management solutions can be

         challenging, and debugging difficult, when they must co-exist

         with solutions already in the field.





You mean to say, "protocols" or "solutions" ?



Both. A new solution may not need a new protocol whereas a given protocol c=
an be deployed in different manners.



So, this is a section on "Problem Statement". Why is this talking about a r=
equirement ?

Delete "must" which seem like a requirement.
         There are already many variants and extensions of MIP.
         Deployment of new mobility management solutions can be
         challenging, and debugging difficult, when they co-exist with
         solutions already deployed in the field.







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 10]



Internet-Draft                  DMM-Reqs                   November 2013





   PS8:  Duplicate multicast traffic



         IP multicast distribution over architectures using IP mobility

         solutions (e.g., [RFC6224]) may lead to convergence of

         duplicated multicast subscriptions towards the downstream

         tunnel entity (e.g.  MAG in PMIPv6).  Concretely, when

         multicast subscription for individual mobile nodes is coupled

         with mobility tunnels (e.g.  PMIPv6 tunnel), duplicate

         multicast subscription(s) is prone to be received through

         different upstream paths.  This problem may also exist or be

         more severe in a distributed mobility environment.





5.  Requirements



   After comparing distributed mobility management against centralized

   deployment in Section 3, this section identifies the following

   requirements:



5.1.  Distributed processing



   REQ1:  Distributed processing



          IP mobility, network access and routing solutions provided by

          DMM MUST enable distributed processing for mobility management

          so that traffic can avoid traversing single mobility anchor

          far from the optimal route.



          Motivation: This requirement is motivated by current trends in

          network evolution: (a) it is cost- and resource-effective to

          cache and distribute content by combining distributed mobility

          anchors with caching systems (e.g., CDN); (b) the

          significantly larger number of mobile nodes and flows call for

          improved scalability; (c) single points of failure are avoided

          in a distributed system; (d) threats against centrally

          deployed anchors, e.g., home agent and local mobility anchor,

          are mitigated in a distributed system.



   This requirement addresses the problems PS1, PS2, PS3, and PS4

   described in Section 4.



5.2.  Transparency to Upper Layers when needed



   REQ2:  Transparency to Upper Layers when needed



          DMM solutions MUST provide transparent mobility support above

          the IP layer when needed.  Such transparency is needed, for

          example, when, upon change of point of attachment to the







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 11]



Internet-Draft                  DMM-Reqs                   November 2013





          network, an application flow cannot cope with a change in the

          IP address.  However, it is not always necessary to maintain a

          stable home IP address or prefix for every application or at

          all times for a mobile node.



          Motivation: The motivation of this requirement is to enable

          more efficient routing and more efficient use of network

          resources by selecting an IP address or prefix according to

          whether mobility support is needed and by not maintaining

          context at the mobility anchor when there is no such need.



   This requirement addresses the problem PS5 as well as the related

   problem PS6 stated in Section 4.



5.3.  IPv6 deployment



   REQ3:  IPv6 deployment



          DMM solutions SHOULD target IPv6 as the primary deployment

          environment and SHOULD NOT be tailored specifically to support

          IPv4, in particular in situations where private IPv4 addresses

          and/or NATs are used.



          Motivation: This requirement conforms to the general

          orientation of IETF work.  DMM deployment is foreseen in mid-

          to long-term horizon, when IPv6 is expected to be far more

          common than today.



   This requirement avoids the unnecessarily complexity in solving the

   problems in Section 4 for IPv4, which will not be able to use some of

   the IPv6-specific features.











5.4.  Existing mobility protocols



   REQ4:  Existing mobility protocols



          A DMM solution SHOULD first consider reusing and extending

          IETF-standardized protocols before specifying new protocols.



          Motivation: Reuse of existing IETF work is more efficient and

          less error-prone.



   This requirement attempts to avoid the need of new protocols

   development and therefore their potential problems of being time-

   consuming and error-prone.













Chan (Ed.), et al.        Expires May 11, 2014                 [Page 12]



Internet-Draft                  DMM-Reqs                   November 2013





5.5.  Co-existence



   REQ5:  Co-existence with deployed networks and hosts



          The DMM solution MUST be able to co-exist with existing

          network deployments and end hosts.  For example, depending on

          the environment in which DMM is deployed, DMM solutions may

          need to be compatible with other deployed mobility protocols

          or may need to co-exist with a network or mobile hosts/routers

          that do not support DMM protocols.  The mobile node may also

          move between different access networks, where some of them may

          support neither DMM nor another mobility protocol.

          Furthermore, a DMM solution SHOULD work across different

          networks, possibly operated as separate administrative

          domains, when allowed by the trust relationship between them.



          Motivation: (a) to preserve backwards compatibility so that

          existing networks and hosts are not affected and continue to

          function as usual, and (b) enable inter-domain operation if

          desired.



   This requirement addresses the related problem PS7 described in

   Section 4.



5.6.  Security considerations



   REQ6:  Security considerations



          A DMM solution MUST not introduce new security risks or

          amplify existing security risks against which the existing

          security mechanisms/protocols cannot offer sufficient

          protection.



          Motivation: Various attacks such as impersonation, denial of

          service, man-in-the-middle attacks, and so on, may be launched

          in a DMM deployment.  For instance, an illegitimate node may

          attempt to access a network providing DMM.  Another example is

          that a malicious node can forge a number of signaling messages

          thus redirecting traffic from its legitimate path.

          Consequently, the specific node is under a denial of service

          attack, whereas other nodes do not receive their traffic.

          Accordingly, security mechanisms/protocols providing access

          control, integrity, authentication, authorization,

          confidentiality, etc. can be used to protect the DMM entities

          as they are already used to protect against existing networks

          and existing mobility protocols defined in IETF.



   This requirement prevents a DMM solution from introducing







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 13]



Internet-Draft                  DMM-Reqs                   November 2013





   uncontrollable problems of potentially insecure mobility management

   protocols which make deployment infeasible because platforms

   conforming to the protocols are at risk for data loss and numerous

   other dangers, including financial harm to the users.











5.7.  Multicast



   REQ7:  Multicast considerations



          DMM SHOULD consider multicast early so that solutions can be

          developed not only to provide IP mobility support when it is

          needed, but also to avoid network inefficiency issues in

          multicast traffic delivery (such as duplicate multicast

          subscriptions towards the downstream tunnel entities).  The

          multicast solutions should therefore avoid restricting the

          management of all IP multicast traffic to a single host

          through a dedicated (tunnel) interface on multicast-capable

          access routers.



          Motivation: Existing multicast deployment have been introduced

          after completing the design of the reference mobility

          protocol, then optimization and extensions have been followed

          by "patching-up" procedure, thus leading to network

          inefficiency and non-optimal routing.  The multicast solutions

          should therefore be required to consider efficiency nature in

          multicast traffic delivery.



[Sri] Considering multicast at a design phase is not technical requirement =
for DMM.

What is "patching up" procedure ?



Revise as follows:
   REQ7:  Multicast considerations

          DMM SHOULD enable multicast solutions to be developed to avoid
          network inefficiency in multicast traffic delivery.

          Motivation: Existing multicast deployment have been introduced
          after completing the design of the reference mobility
          protocol, often leading to network inefficiency and non-
          optimal routing for the multicast traffic.  Instead DMM should
          consider multicast early so that the multicast solutions can
          better consider efficiency nature in the multicast traffic
          delivery (such as duplicate multicast subscriptions towards
          the downstream tunnel entities).  The multicast solutions
          should then avoid restricting the management of all IP
          multicast traffic to a single host through a dedicated
          (tunnel) interface on multicast-capable access routers.





   This requirement addresses the problems PS1 and PS8 described in

   Section 4.





6.  Security Considerations



   Please refer to the discussion under Security requirement in Section

   5.6.





7.  IANA Considerations



   None





8.  Co-authors and Contributors



   This problem statement document is a joint effort among the numerous

   participants.  Each individual has made significant contributions to

   this work and have been listed as co-authors.









Chan (Ed.), et al.        Expires May 11, 2014                 [Page 14]



Internet-Draft                  DMM-Reqs                   November 2013





9.  References



9.1.  Normative References



   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate

              Requirement Levels", BCP 14, RFC 2119, March 1997.



9.2.  Informative References



   [I-D.bhandari-dhc-class-based-prefix]

              Bhandari, S., Halwasia, G., Gundavelli, S., Deng, H.,

              Thiebaut, L., Korhonen, J., and I. Farrer, "DHCPv6 class

              based prefix", draft-bhandari-dhc-class-based-prefix-05

              (work in progress), July 2013.



   [I-D.korhonen-6man-prefix-properties]

              Korhonen, J., Patil, B., Gundavelli, S., Seite, P., and D.

              Liu, "IPv6 Prefix Properties",

              draft-korhonen-6man-prefix-properties-02 (work in

              progress), July 2013.



   [I-D.wakikawa-netext-pmip-cp-up-separation]

              Wakikawa, R., Pazhyannur, R., and S. Gundavelli,

              "Separation of Control and User Plane for Proxy Mobile

              IPv6", draft-wakikawa-netext-pmip-cp-up-separation-00

              (work in progress), July 2013.



   [I-D.yokota-dmm-scenario]

              Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case

              scenarios  for Distributed Mobility Management",

              draft-yokota-dmm-scenario-00 (work in progress),

              October 2010.



   [Paper-Distributed.Centralized.Mobility]

              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed

              or Centralized Mobility",  Proceedings of Global

              Communications Conference  (GlobeCom), December 2009.



   [Paper-Distributed.Dynamic.Mobility]

              Bertin, P., Bonjour, S., and J-M. Bonnin, "A Distributed

              Dynamic Mobility Management Scheme  Designed for Flat IP

              Architectures",  Proceedings of 3rd International

              Conference  on New Technologies, Mobility and Security

              (NTMS), 2008.



   [Paper-Distributed.Mobility.MIP]

              Chan, H., "Distributed Mobility Management with Mobile

              IP",  Proceedings of  IEEE International Communication







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 15]



Internet-Draft                  DMM-Reqs                   November 2013





              Conference (ICC)  Workshop on Telecommunications:  from

              Research to Standards, June 2012.



   [Paper-Distributed.Mobility.PMIP]

              Chan, H., "Proxy Mobile IP  with Distributed Mobility

              Anchors",  Proceedings of GlobeCom Workshop  on Seamless

              Wireless Mobility, December 2010.



   [Paper-Distributed.Mobility.Review]

              Chan, H., Yokota, H., Xie, J., Seite, P., and D. Liu,

              "Distributed and Dynamic Mobility Management  in Mobile

              Internet: Current Approaches and Issues, Journal of

              Communications, vol. 6, no. 1, pp. 4-15, Feb 2011.",

               Proceedings of GlobeCom Workshop  on Seamless Wireless

              Mobility, February 2011.



   [Paper-Distributed.Mobility.SAE]

              Fisher, M., Anderson, F., Kopsel, A., Schafer, G., and M.

              Schlager, "A Distributed IP Mobility Approach for 3G SAE",

               Proceedings of the 19th International Symposium  on

              Personal, Indoor and Mobile Radio Communications (PIMRC),

              2008.



   [Paper-Locating.User]

              Kirby, G., "Locating the User",  Communication

              International, 1995.



   [Paper-Migrating.Home.Agents]

              Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home

              Agents  Towards Internet-scale Mobility Deployments",

               Proceedings of the ACM 2nd CoNEXT Conference  on Future

              Networking Technologies, December 2006.



   [Paper-Mobile.Data.Offloading]

              Lee, K., Lee, J., Yi, Y., Rhee, I., and S. Chong, "Mobile

              Data Offloading: How Much Can WiFi Deliver?",  SIGCOMM

              2010, 2010.



   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",

              RFC 3753, June 2004.



   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,

              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.



   [RFC5380]  Soliman, H., Castelluccia, C., ElMalki, K., and L.

              Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility

              Management", RFC 5380, October 2008.









Chan (Ed.), et al.        Expires May 11, 2014                 [Page 16]



Internet-Draft                  DMM-Reqs                   November 2013





   [RFC5944]  Perkins, C., "IP Mobility Support for IPv4, Revised",

              RFC 5944, November 2010.



   [RFC6224]  Schmidt, T., Waehlisch, M., and S. Krishnan, "Base

              Deployment for Multicast Listener Support in Proxy Mobile

              IPv6 (PMIPv6) Domains", RFC 6224, April 2011.



   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support

              in IPv6", RFC 6275, July 2011.



   [RFC6301]  Zhu, Z., Wakikawa, R., and L. Zhang, "A Survey of Mobility

              Support in the Internet", RFC 6301, July 2011.



   [RFC6705]  Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A.

              Dutta, "Localized Routing for Proxy Mobile IPv6",

              RFC 6705, September 2012.



   [RFC6909]  Gundavelli, S., Zhou, X., Korhonen, J., Feige, G., and R.

              Koodli, "IPv4 Traffic Offload Selector Option for Proxy

              Mobile IPv6", RFC 6909, April 2013.



   [TS.23.401]

              3GPP, "General Packet Radio Service (GPRS) enhancements

              for Evolved Universal Terrestrial Radio Access Network

              (E-UTRAN) access", 3GPP TR 23.401 10.10.0, March 2013.



   [TS.29303]

              3GPP, "Domain Name System Procedures; Stage 3", 3GPP

              TR 23.303 11.2.0, September 2012.





Authors' Addresses



   H Anthony Chan (editor)

   Huawei Technologies (more co-authors on P. 17)

   5340 Legacy Dr. Building 3, Plano, TX 75024, USA

   Email: h.a.chan@ieee.org





   Dapeng Liu

   China Mobile

   Unit2, 28 Xuanwumenxi Ave, Xuanwu District, Beijing 100053, China

   Email: liudapeng@chinamobile.com

















Chan (Ed.), et al.        Expires May 11, 2014                 [Page 17]



Internet-Draft                  DMM-Reqs                   November 2013





   Pierrick Seite

   Orange

   4, rue du Clos Courtel, BP 91226, Cesson-Sevigne 35512, France

   Email: pierrick.seite@orange.com





   Hidetoshi Yokota

   KDDI Lab

   2-1-15 Ohara, Fujimino, Saitama, 356-8502 Japan

   Email: yokota@kddilabs.jp





   Jouni Korhonen

   Renesas Mobile

   Porkkalankatu 24, FIN-00180 Helsinki, Finland

   Email: jouni.korhonen@nsn.com

   -

   Charles E. Perkins

   Huawei Technologies

   Email: charliep@computer.org

   -

   Melia Telemaco

   Alcatel-Lucent Bell Labs

   Email: telemaco.melia@alcatel-lucent.com

   -

   Elena Demaria

   Telecom Italia

   via G. Reiss Romoli, 274, TORINO, 10148, Italy

   Email: elena.demaria@telecomitalia.it

   -

   Jong-Hyouk Lee

   Sangmyung University

   Email: hurryon@gmail.com

   -

   Kostas Pentikousis

   EICT GmbH

   Email: k.pentikousis@eict.de

   -

   Tricci So

   ZTE

   Email: tso@zteusa.com

   -

   Carlos J. Bernardos

   Universidad Carlos III de Madrid

   Av. Universidad, 30, Leganes, Madrid 28911, Spain

   Email: cjbc@it.uc3m.es

   -

   Peter McCann







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 18]



Internet-Draft                  DMM-Reqs                   November 2013





   Huawei Technologies

   Email: PeterMcCann@huawei.com

   -

   Seok Joo Koh

   Kyungpook National University, Korea

   Email: sjkoh@knu.ac.kr

   -

   Wen Luo

   ZTE

   No.68, Zijinhua RD,Yuhuatai District, Nanjing, Jiangsu 210012, China

   Email: luo.wen@zte.com.cn

   -

   Sri Gundavelli

   Cisco

   sgundave@cisco.com

   -

   Marco Liebsch

   NEC Laboratories Europe

   Email: liebsch@neclab.eu

   -

   Carl Williams

   MCSR Labs

   Email: carlw@mcsr-labs.org

   -

   Seil Jeon

   Instituto de Telecomunicacoes, Aveiro

   Email: seiljeon@av.it.pt

   -

   Sergio Figueiredo

   Universidade de Aveiro

   Email: sfigueiredo@av.it.pt

   -

   Stig Venaas

   Email: stig@venaas.com

   -

   Luis Miguel Contreras Murillo

   Telefonica I+D

   Email: lmcm@tid.es

   -

   Juan Carlos Zuniga

   InterDigital

   Email: JuanCarlos.Zuniga@InterDigital.com

   -

   Alexandru Petrescu

   Email: alexandru.petrescu@gmail.com

   -

   Georgios Karagiannis

   University of Twente







Chan (Ed.), et al.        Expires May 11, 2014                 [Page 19]



Internet-Draft                  DMM-Reqs                   November 2013





   Email: g.karagiannis@utwente.nl

   -

   Julien Laganier

   Juniper

   jlaganier@juniper.net

   -

   Wassim Michel Haddad

   Ericsson

   Wassam.Haddad@ericsson.com

   -

   Dirk von Hugo

   Deutsche Telekom Laboratories

   Dirk.von-Hugo@telekom.de

   -

   Ahmad Muhanna

   Award Solutions

   amuhanna@awardsolutions.com

   -

   Byoung-Jo Kim

   ATT Labs

   macsbug@research.att.com

   -

   Hassan Ali-Ahmad

   Orange

   hassan.aliahmad@orange.com

   -

   Alper Yegin

   Samsung

   alper.yegin@partner.samsung.com

   -





























--_000_6E31144C030982429702B11D6746B98C370E7086szxeml557mbxchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











After checking the defini=
tions section, the following definition is changed as follows:


   Distributed mobility management


 


      is not centralized so that traffic does=
 not need to traverse


      centrally deployed mobility anchors.


Change to:


   Distributed mobility management


 


      is not centralized so that =
traffic does not need to traverse


      centrally deployed mobility=
 anchors far from the optimal route.


 <=
/p>



H Anthony Chan=





 <=
/p>





From: h chan


Sent: Tuesday, November 19, 2013 8:12 PM

To: 'Sri Gundavelli (sgundave)'; dmm@ietf.org

Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 


Sri,

Suggested revisions are s=
hown in blue below.



Not sure about what impro=
vements are desired for the definitions though.


 <=
/p>



H Anthony Chan=





 <=
/p>





From: Sri Gund=
avelli (sgundave) [mailto:sgundave@ci=
sco.com]


Sent: Sunday, November 17, 2013 4:27 PM

To: h chan; dmm@ietf.org

Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 




Hi Anthony,






 






Thanks for revising the draf=
t. Following are some more comments on the document. I'm not holding this d=
ocument any more. What ever comments you can address … or
 you can choose not to revise …






 






Please see inline.






 






Regards





Sri






 






 






From:
h chan <h.anthony.chan@huawei.com>

Date: Wednesday, September 25, 2013 9:49 PM

To: Sri Gundavelli <sgundav=
e@cisco.com>, "dmm@ietf.org=
" <dmm@ietf.org>

Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt






 








 


Sri,


 


Thanks for the comments. =
We are replying under different sections in separate emails.









 






 






 


 


Network Working Group    &n=
bsp;            =
;            &n=
bsp;        H. Chan (Ed.)


Internet-Draft    &nbs=
p;            &=
nbsp;           &nbs=
p;   Huawei Technologies (more


Intended status: Informational  =
            &nb=
sp;       co-authors on P. 17)


Expires: May 11, 2014   &nb=
sp;            =
            &nb=
sp;             =
;   D. Liu


       =
            &nb=
sp;            =
            &nb=
sp;            =
   China Mobile


       =
            &nb=
sp;            =
            &nb=
sp;            =
       P. Seite


       =
            &nb=
sp;            =
            &nb=
sp;            =
         Orange

       =
            &nb=
sp;             =
;            &n=
bsp;            =
;     H. Yokota


       =
            &nb=
sp;            =
            &nb=
sp;            =
       KDDI Lab


       =
            &nb=
sp;            =
            &nb=
sp;            =
    J. Korhonen


       =
            &nb=
sp;            =
            &nb=
sp;            =
 Renesas Mobile


       =
            &nb=
sp;            =
            &nb=
sp;           November 7,=
 2013


 


 


       =
     Requirements for Distributed Mobility Management


       =
            &nb=
sp; draft-ietf-dmm-requirements-10


 


Abstract


 


   This document defines the req=
uirements for Distributed Mobility


   Management (DMM).  The h=
ierarchical structure in traditional wireless


   networks has led primarily to=
 centralized deployment models.  As some


   wireless networks are evolvin=
g away from the hierarchical structure,


   such as in moving the content=
 delivery servers closer to the users, a


   distributed model for mobilit=
y management can be useful to them.


 


 


[Sri] Not sure, w=
hat the "hierarchical structure in traditional wireless" means.


There are two asp=
ects here:


 


1.) There is the =
aspect of distributed mobility deployment model for all the reasons that th=
e document talks about=



2.) There is the other aspect of hosting content servers cl=
oser to the subscriber


 


I'm not able to d=
raw the relation between "moving content to the access" and the s=
hift from centralized to distributed model. I understand you want to say to=
day there are central anchors where subscriber sessions are hosted. All the=
 traffic from the mobile node's is brought to the central location/anchor f=
or service enablement and including content access. An alternative model is=
 to distribute the anchors, localize the traffic and enable the associated =
services to local anchors. You may want to re-write the text if you want to=
 get that right.


 


Let us delete “such as in moving the content delivery servers closer to the u=
sers,”


Then the abstract becomes:


Abstract


 


   This document defines the r=
equirements for Distributed Mobility


   Management (DMM).  The=
 hierarchical structure in traditional wireless


   networks has led primarily =
to centralized deployment models.  As some


   wireless networks are evolv=
ing away from the hierarchical structure,


   a


   distributed model for mobil=
ity management can be useful to them.


 


 


 


 


 


Requirements Language

 


   The key words "MUST"=
;, "MUST NOT", "REQUIRED", "SHALL", "SHA=
LL NOT",


   "SHOULD", "SHO=
ULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL=
" in this


   document are to be interprete=
d as described in RFC 2119 RFC 2119


   [RFC2119].<=
/pre>

 


Status of this Memo

 


   This Internet-Draft is submit=
ted in full conformance with the


   provisions of BCP 78 and BCP =
79.


 


   Internet-Drafts are working d=
ocuments of the Internet Engineering


   Task Force (IETF).  Note=
 that other groups may also distribute


   working documents as Internet=
-Drafts.  The list of current Internet-


   Drafts is at http://datatracker.ietf.org/drafts/=
current/.


 


   Internet-Drafts are draft doc=
uments valid for a maximum of six months


   and may be updated, replaced,=
 or obsoleted by other documents at any


   time.  It is inappropria=
te to use Internet-Drafts as reference


   material or to cite them othe=
r than as "work in progress."


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 1]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   This Internet-Draft will expi=
re on May 11, 2014.


 


Copyright Notice


 


   Copyright (c) 2013 IETF Trust=
 and the persons identified as the


   document authors.  All r=
ights reserved.


 


   This document is subject to B=
CP 78 and the IETF Trust's Legal


   Provisions Relating to IETF D=
ocuments


   (http://trustee.ietf.org/license-info) in effect on=
 the date of


   publication of this document.=
  Please review these documents


   carefully, as they describe y=
our rights and restrictions with respect


   to this document.  Code =
Components extracted from this document must


   include Simplified BSD Licens=
e text as described in Section 4.e of


   the Trust Legal Provisions an=
d are provided without warranty as


   described in the Simplified B=
SD License.


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 2]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


Table of Contents


 


   1.  Introduction . . . .=
 . . . . . . . . . . . . . . . . . . . . .  4


   2.  Conventions used in =
this document  . . . . . . . . . . . . . .  6

     2.1.  Termin=
ology  . . . . . . . . . . . . . . . . . . . . . . .  6


   3.  Centralized versus d=
istributed mobility management . . . . . .  7


     3.1.  Centra=
lized mobility management  . . . . . . . . . . . . .  7


     3.2.  Distri=
buted mobility management  . . . . . . . . . . . . .  8


   4.  Problem Statement&nb=
sp; . . . . . . . . . . . . . . . . . . . . . .  9

   5.  Requirements . . . .=
 . . . . . . . . . . . . . . . . . . . . . 11


     5.1.  Distri=
buted processing . . . . . . . . . . . . . . . . . . 11

     5.2.  Transp=
arency to Upper Layers when needed . . . . . . . . . 11

     5.3.  IPv6 d=
eployment  . . . . . . . . . . . . . . . . . . . . . 12


     5.4.  Existi=
ng mobility protocols  . . . . . . . . . . . . . . . 12


     5.5.  Co-exi=
stence . . . . . . . . . . . . . . . . . . . . . . . 13

     5.6.  Securi=
ty considerations  . . . . . . . . . . . . . . . . . 13


     5.7.  Multic=
ast  . . . . . . . . . . . . . . . . . . . . . . . . 14


   6.  Security Considerati=
ons  . . . . . . . . . . . . . . . . . . . 14


   7.  IANA Considerations&=
nbsp; . . . . . . . . . . . . . . . . . . . . . 14


   8.  Co-authors and Contr=
ibutors  . . . . . . . . . . . . . . . . . 14


   9.  References . . . . .=
 . . . . . . . . . . . . . . . . . . . . . 15


     9.1.  Normat=
ive References . . . . . . . . . . . . . . . . . . . 15

     9.2.  Inform=
ative References . . . . . . . . . . . . . . . . . . 15

   Authors' Addresses . . . . . =
. . . . . . . . . . . . . . . . . . . 17


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 3]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


1.  Introduction

 


   In the past decade a fair num=
ber of mobility protocols have been


   standardized [RFC6275] [RFC59=
44] [RFC5380] [RFC6301] [RFC5213].


   Although the protocols differ=
 in terms of functions and associated


   message formats, they all emp=
loy a mobility anchor to allow a mobile


   node to remain reachable afte=
r it has moved to a different network.


   The anchor point, among other=
 tasks, ensures connectivity by


   forwarding packets destined t=
o, or sent from, the mobile node.  It is


   a centrally deployed mobility=
 anchor in the sense that the deployed


   architectures today have a sm=
all number of these anchors and the


   traffic of millions of mobile=
 nodes in an operator network are


   typically managed by the same=
 anchor.


 


   Distributed mobility manageme=
nt (DMM) is an alternative to the above


   centralized deployment. =
 The background behind the interests to study


   DMM are primarily in the foll=
owing.


 


   (1)  Mobile users are, m=
ore than ever, consuming Internet content;


       =
 such traffic imposes new requirements on mobile core networks


       =
 for data traffic delivery.  The presence of content providers


       =
 closer to Internet Service Providers (ISP) network requires


       =
 taking into account local Content Delivery Networks (CDNs) while


       =
 providing mobility services.  Moreover, when the traffic demand<=
/o:p>


       =
 exceeds available capacity, service providers need to implement=



       =
 new strategies such as selective IPv4 traffic offload (e.g.


       =
 [RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through


       =
 alternative access networks (e.g.  WLAN) [Paper-

       =
 Mobile.Data.Offloading].  A gateway selection mechanism also


       =
 takes the user proximity into account within EPC [TS.29303].


       =
 These mechanisms were not pursued in the past owing to charging=



       =
 and billing reasons.  Assigning a gateway anchor node from a


       =
 visited network in roaming scenario has until recently been done


       =
 and are limited to voice services only.  Charging and billing


       =
 require solutions beyond the mobility protocol.


 


 


[Sri] Some valid points above. But, IMHO, its not orga=
nized correctly. 


My only comment with this document is that this has text fr=
om multiple people with different goals, but is not organized poorly.


 


Reminds me of some SDO documents. There the document starts=
 with a blank template, every company spits a line or two and in no time, t=
he document grows like a monster, but there is no relation between two line=
s of text in the same paragraph. No offense.


 


Rearrange as =
follows:


 


   (1)  Mobile users are, mor=
e than ever, consuming Internet content


        i=
ncluding that of local Content Delivery Networks (CDNs) which


        h=
ad not taken mobility service into account before.  Such


        t=
raffic imposes new requirements on mobile core networks for


        d=
ata traffic delivery.  To prevent exceeding the available core


        n=
etwork capacity, service providers need to implement new<=
/p>

        s=
trategies such as selective IPv4 traffic offload (e.g.

        [=
RFC6909], 3GPP work items LIPA/SIPTO [TS.23.401]) through=



        a=
lternative access networks (e.g.  WLAN) [Paper-


        M=
obile.Data.Offloading].  In addition, a gateway selection


        m=
echanism takes the user proximity into account within EPC=



        [=
TS.29303].  Yet these mechanisms were not pursued in the past


        o=
wing to charging and billing which require solutions beyond the<=
/span>


        m=
obility protocol.  Consequently, assigning a gateway anchor=



        n=
ode from a visited network in roaming scenario has until<=
/p>

        r=
ecently been done and are limited to voice services only.=



 


 


 


       =
 Both traffic offloading and CDN mechanisms could benefit from


       =
 the development of mobile architectures with fewer levels of


       =
 routing hierarchy introduced into the data path by the mobility=



       =
 management system.  This trend towards so-called "flat networks&=
quot;


       =
 works best for direct communications among peers in the same


       =
 geographical area.  Distributed mobility management in a truly


       =
 flat mobile architecture would anchor the traffic closer to the=



       =
 point of attachment of the user.


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 4]=



 


Internet-Draft     &nb=
sp;            =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   (2)  Today's mobile netw=
orks present service providers with new


       =
 challenges.  Mobility patterns indicate that mobile nodes often<=
/o:p>


       =
 remain attached to the same point of attachment for considerable


       =
 periods of time [Paper-Locating.User].  Specific IP mobility


       =
 management support is not required for applications that launch=



       =
 and complete their sessions while the mobile node is connected<=
/span>


       =
 to the same point of attachment.  However, currently, IP


       =
 mobility support is designed for always-on operation,

       =
 maintaining all parameters of the context for each mobile


       =
 subscriber for as long as they are connected to the network.


       =
 This can result in a waste of resources and unnecessary costs


       =
 for the service provider.  Infrequent node mobility coupled with=



       =
 application intelligence suggest that mobility support could be=



       =
 provided selectively such as in [I-D.bhandari-dhc-class-based-<=
/span>


       =
 prefix] and [I-D.korhonen-6man-prefix-properties], thus reducing


       =
 the amount of context maintained in the network.


 


 


Let us delete=
 the following, which don’t seem necessary. The requirements already =
have the problem statements to support them.  


   In addition, consid=
erations in the study of DMM are in the following.

 


   (1)  To optimize ha=
ndovers from the perspective of mobile nodes, the

      &=
nbsp; base protocols have been extended to efficiently handle packet


      &=
nbsp; forwarding between the previous and new points of attachment.


      &=
nbsp; These extensions are necessary when applications have stringent<=
/o:p>


      &=
nbsp; requirements in terms of delay.  Notions of localization and


      &=
nbsp; distribution of local agents have been introduced to reduce


      &=
nbsp; signaling overhead at the centralized routing anchor point=



      &=
nbsp; [Paper-Distributed.Centralized.Mobility].  Unfortunately, such


      &=
nbsp; protocols have not been deployed today.


 


   (2)  Most existing =
mobility protocols have not been designed for


      &=
nbsp; multiple-interface hosts which are capable to use multiple=



      &=
nbsp; interfaces simultaneously.  Retrofitting the required=



      &=
nbsp; functionality can result in an unnecessary increase in the=



      &=
nbsp; protocol complexity.


 


 


RFC5648.


Not sure. I agree=
 about the complexity. Any case, this is not a DMM requirement<=
/o:p>


 


 


 


   (3)  IP multicast s=
upport, including optimizations, have been


      &=
nbsp; introduced as an effective transport method for multimedia data<=
/o:p>


      &=
nbsp; delivery, but by "patching-up" procedure after completing t=
he


      &=
nbsp; design of reference mobility protocol, leading to network<=
/span>


      &=
nbsp; inefficiency and non-optimal routing.


 


 


I dont understand=
 this.


 


 


   The distributed mobility management (DMM) charter address=
es two


   complementary aspects of mobility management procedures: =
the


   distribution of mobility anchors in the data-plane toward=
s a more


   flat network and the selective activation/deactivation of=
 mobility


   protocol support as an enabler to distributed mobility ma=
nagement.


   The former aims at positioning mobility anchors (e.g., HA=
, LMA)


   closer to the user; ideally, mobility agents could be col=
located with


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 5]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            =
;   November 2013


 


 


   the first-hop router.  The latter, facilitated by th=
e distribution of


   mobility anchors, identifies when mobility support must b=
e activated


   and when sessions do not require mobility management supp=
ort -- thus


   reducing the amount of state information that must be mai=
ntained in


   various mobility agents of the mobile network.  It c=
an then avoid the


   unnecessary establishment of mechanisms to forward traffi=
c from an


   old to a new mobility anchor.


 


   This document compares distributed mobility management wi=
th


   centralized mobility management in Section 3.  The p=
roblems that can


   be addressed with DMM are summarized in Section 4.  =
The mandatory


   requirements as well as the optional requirements are giv=
en in


   Section 5.  Finally, security considerations are dis=
cussed in Section


   6.


 


   The problem statement and the use cases [I-D.yokota-dmm-s=
cenario] can


   be found in [Paper-Distributed.Mobility.Review].


 


 


2.  Conventions used in this document


 


2.1.  Terminology


 


   All the general mobility-related terms and their acronyms=
 used in


   this document are to be interpreted as defined in the Mob=
ile IPv6


   base specification [RFC6275], in the Proxy mobile IPv6 sp=
ecification


   [RFC5213], and in Mobility Related Terminology [RFC3753].=
  These


   terms include the following: mobile node (MN), correspond=
ent node


   (CN), and home agent (HA) as per [RFC6275]; local mobilit=
y anchor


   (LMA) and mobile access gateway (MAG) as per [RFC5213], a=
nd context


   as per [RFC3753].


 


   In addition, this draft introduces the following terms.


 


   Centrally deployed mobility anchors


 


      refer to the mobility management deploy=
ments in which there are


      very few mobility anchors and the traff=
ic of millions of mobile


      nodes in an operator network are manage=
d by the same anchor.


 


   Centralized mobility management


 


      makes use of centrally deployed mobilit=
y anchors.


 


   Distributed mobility management


 


      is not centralized so that traffic does=
 not need to traverse


      centrally deployed mobility anchors.


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 6]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            =
;   November 2013


 


 


   Flat mobile network


 


      has few levels of routing hierarchy int=
roduced into the data path


      by the mobility management system.=



 


 


 


   Mobility context


 


      is the collection of information requir=
ed to provide mobility


      management support for a given mobile n=
ode.


 


 


You can impr=
ove the terminology section


Not sure whet=
her you want to better define these terms or whether some definitions are m=
issing? 


 


3.  Centralized versus distributed mobility management=



 


   Mobility management functions may be implemented at diffe=
rent layers


   of the protocol stack.  At the IP (network) layer, m=
obility


   management can be client-based or network-based.


 


   An IP-layer mobility management protocol is typically bas=
ed on the


   principle of distinguishing between session identifier an=
d routing


   address and maintaining a mapping between the two.  =
In Mobile IP, the


   home address serves as the session identifier whereas the=
 care-of-


   address (CoA) takes the role of the routing address. =
; The binding


   between these two is maintained at the home agent (mobili=
ty anchor).


   If packets addressed to the home address of a mobile node=
 can be


   continuously delivered to the node, then all sessions usi=
ng that home


   address are unaffected even though the routing address (C=
oA) changes.


 


   The next two subsections explain centralized and distribu=
ted mobility


   management functions in the network.


 


3.1.  Centralized mobility management


 


   In centralized mobility management, the mapping informati=
on between


   the session identifier and the locator IP address of a mo=
bile node


   (MN) is kept at a single mobility anchor.  At the sa=
me time, packets


   destined to the MN are routed via this anchor.  In o=
ther words, such


   mobility management systems are centralized in both the c=
ontrol plane


   and the data plane (mobile node IP traffic).

 


   Many existing mobility management deployments make use of=
 centralized


   mobility anchoring in a hierarchical network architecture=
, as shown


   in Figure 1.  Examples of such centralized mobility =
anchors are the


   home agent (HA) and local mobility anchor (LMA) in Mobile=
 IPv6


   [RFC6275] and Proxy Mobile IPv6 [RFC5213], respectively.&=
nbsp; Current


   cellular networks such as the Third Generation Partnershi=
p Project


   (3GPP) GPRS networks, CDMA networks, and 3GPP Evolved Pac=
ket System


   (EPS) networks employ centralized mobility management too=
.  In


   particular, the Gateway GPRS Support Node (GGSN), Serving=
 GPRS


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 7]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            =
;   November 2013


 


 


   Support Node (SGSN) and Radio Network Controller (RNC) in=
 the 3GPP


   GPRS hierarchical network, and the Packet Data Network Ga=
teway (P-GW)


   and Serving Gateway (S-GW) in the 3GPP EPS network all ac=
t as anchors


   in a hierarchy.


 


 


         3G GPRS  &n=
bsp;            &nbs=
p; 3GPP EPS          =
;      MIP/PMIP


         +------+ =
;            &n=
bsp;  +------+        =
        +------+

         | GGSN |  &=
nbsp;           &nbs=
p; | P-GW |          &nbs=
p;     |HA/LMA|


         +------+ =
;            &n=
bsp;  +------+        =
        +------+

            /\&=
nbsp;           &nbs=
p;         /\   &nbs=
p;            &=
nbsp;     /\


           /  \=
            &nb=
sp;       /  \    &n=
bsp;            =
;   /  \


          /  &n=
bsp; \           &nb=
sp;      /    \   &n=
bsp;            =
;  /    \


         /   &n=
bsp;  \          &nb=
sp;     /      \  &n=
bsp;            =
; /      \


        /     &=
nbsp;  \         &nb=
sp;    /        \ &n=
bsp;            /&nb=
sp;       \


       /     &n=
bsp;    \        &nb=
sp;   /          \&n=
bsp;           / &nb=
sp;        \


      /      &n=
bsp;     \       &nb=
sp;  /          &nbs=
p; \          /  &nb=
sp;         \


  +------+      +------+=
  +------+      +------+ =
; +------+      +------+


  | SGSN |      | SGSN |  | S-GW |&=
nbsp;     | S-GW |  |MN/MAG|   &nbs=
p;  |MN/MAG|


  +------+      +------+=
  +------+      +------+ =
; +------+      +------+


     /\       &=
nbsp;    /\


    /  \       =
   /  \


   /    \      =
  /    \


+---+  +---+  +---+  +---&#=
43;


|RNC|  |RNC|  |RNC|  |RNC|


+---+  +---+  +---+  +---&#=
43;


 


   Figure 1.  Centralized mobility management.


 


3.2.  Distributed mobility management


 


   Mobility management functions may also be distributed to =
multiple


   networks as shown in Figure 2, so that a mobile node in a=
ny of these


   networks may be served by a nearby mobility function (MF)=
.


 


 


           &nbs=
p;        +------+  +--=
----+  +------+  +------+


           &nbs=
p;        |  MF  |  |&nbs=
p; MF  |  |  MF  |  |  MF  |<=
/pre>

           &nbs=
p;        +------+  +--=
----+  +------+  +------+


           &nbs=
p;            &=
nbsp;           &nbs=
p;      |


           &nbs=
p;            &=
nbsp;           &nbs=
p;    +----+


           &nbs=
p;            &=
nbsp;           &nbs=
p;    | MN |


           &nbs=
p;            &=
nbsp;           &nbs=
p;    +----+


 


   Figure 2.  Distributed mobility management.


 


   Mobility management may be partially or fully distributed=



   [I-D.yokota-dmm-scenario].  In the former case only =
the data plane is


 


 


 


Chan (Ed.), et al.        Expires M=
ay 11, 2014          &nbs=
p;       [Page 8]


 


Internet-Draft         &n=
bsp;        DMM-Reqs   &n=
bsp;            &nbs=
p;  November 2013


 


 


   distributed, implicitly assuming separation of data and c=
ontrol


   planes as described in [I-D.wakikawa-netext-pmip-cp-up-se=
partion].


   Fully distributed mobility management implies that both t=
he data


   plane and the control plane are distributed.  While =
mobility


   management can be distributed, it is not necessary for ot=
her


   functions such as subscription management, subscription d=
atabase, and


   network access authentication to be similarly distributed=
.


 


   A distributed mobility management scheme for a flat mobil=
e network of


   access nodes is proposed in [Paper-Distributed.Dynamic.Mo=
bility].


   Its benefits over centralized mobility management are sho=
wn through


   simulations in [Paper-Distributed.Centralized.Mobility].&=
nbsp; Moreover,


   the (re)use and extension of existing protocols in the de=
sign of both


   fully distributed mobility management [Paper-Migrating.Ho=
me.Agents]


   [Paper-Distributed.Mobility.SAE] and partially distribute=
d mobility


   management [Paper-Distributed.Mobility.PMIP] [Paper-=



   Distributed.Mobility.MIP] have been reported in the liter=
ature.


   Therefore, before designing new mobility management proto=
cols for a


   future distributed architecture, it is recommended to fir=
st consider


   whether existing mobility management protocols can be ext=
ended.


 


 


4.  Problem Statement


 


   The problems that can be addressed with DMM are summarize=
d in the


   following:


 


   PS1:  Non-optimal routes


 


         Routing via a central=
ized anchor often results in non-optimal


         routes, thereby incre=
asing the end-to-end delay.  The problem


         is manifested, for ex=
ample, when accessing a nearby server or


         servers of a Content =
Delivery Network (CDN), or when receiving


         locally available IP =
multicast or sending IP multicast packets.


         (Existing route optim=
ization is only a host-based solution.  On


         the other hand, local=
ized routing with PMIPv6 [RFC6705]


         addresses only a part=
 of the problem where both the MN and the


         CN are located in the=
 PMIP domain and attached to a MAG, and is


         not applicable when t=
he CN is outside the PMIP domain or does


         not behave like an MN=
.)


 


You argue for opt=
imized route when accessing a CDN server in the local network. But you say =
that the localized routing schemes don't work when the CN is outside the PM=
IP domain. What is the point ? When the CN is outside the PMIP domain, wher=
e is optimized route possibility ? 


 


So, PS1 is about =
optimized routing requirement in DMM. Even though the document fails to mak=
e the case that the current models have an issue, I'm OK with optimized rou=
ting goal for DMM in general terms.


 


Revise as fol=
lows:


 


       &n=
bsp; Routing via a centralized anchor often results in non-optimal


       &n=
bsp; routes, thereby increasing the end-to-end delay.  The problem


       &n=
bsp; is manifested, for example, when accessing a nearby server or


       &n=
bsp; servers of a Content Delivery Network (CDN), or when receiving


       &n=
bsp; locally available IP multicast or sending IP multicast packets.


       &n=
bsp; (Existing route optimization is only a host-based solution.  On


       &n=
bsp; the other hand, localized routing with PMIPv6 [RFC6705]


       &n=
bsp; addresses only a part of the problem where both the MN and the


       &n=
bsp; CN are attached to the same MAG, and it is not applicable when


       &n=
bsp; the CN does not behave like an MN.)


 


 


 


   PS2:  Divergence from ot=
her evolutionary trends in network


       =
  architectures such as distribution of content delivery.


 


 


         Centralized mobility =
management can become non-optimal with a


         flat network architec=
ture.


 


 =
;


So, this is "non-optimizal" because traffic has t=
o hit the central anchor ? Is it not same as PS1 ? Please add few lines of =
text


Revise as follows:


       &n=
bsp; Mobile networks have generally been evolving towards a flat


       &n=
bsp; network.  Centralized mobility management, which is non-optimal


       &n=
bsp; with a flat network architecture, does not support this


       &n=
bsp; evolution.


 =



 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
            [Page 9]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   PS3:  Low scalability of=
 centralized tunnel management and mobility


       =
  context maintenance


 


        =
; Setting up tunnels through a central anchor and maintaining


       =
  mobility context for each MN usually requires more concentrated=



       =
  resources in a centralized design, thus reducing scalability.


       =
  Distributing the tunnel maintenance function and the mobility


       =
  context maintenance function among different network entities


       =
  with proper signaling protocol design can increase scalability.=



 


 


Its not scalable =
because it requires lot of "concentrated resources" ? But, distri=
buting them allows it to scale. Not very convincing argument


 


We can revise=
 as follows:


   PS3:  Scalability of centr=
alized tunnel management and mobility


       &n=
bsp; context maintenance


 


       &n=
bsp; Setting up tunnels through a central anchor and maintaining=



       &n=
bsp; mobility context for each MN usually requires more concentrated


       &n=
bsp; resources in a centralized design, thus reducing scalability.


       &n=
bsp; Distributing the tunnel maintenance function and the mobility


       &n=
bsp; context maintenance function among different network entities


       &n=
bsp; with proper signaling protocol design can avoid increasing the


       &n=
bsp; concentrated resources with an increasing number of MNs.


 


 


 


   PS4:  Single point of fa=
ilure and attack


 


       =
  Centralized anchoring designs may be more vulnerable to single<=
/o:p>


       =
  points of failures and attacks than a distributed system.  The<=
o:p>


        =
; impact of a successful attack on a system with centralized


       =
  mobility management can be far greater as well.

 


 


   PS5:  Unnecessary mobili=
ty support to nodes that do not need it


 


       =
  IP mobility support is not always required, and not every=



       =
  parameter of mobility context is always used.  For example,


       =
  some applications do not need a stable IP address during a


       =
  handover to maintain session continuity.  Sometimes, the entire=



       =
  application session runs while the terminal does not change the=



       =
  point of attachment.  Besides, some sessions, e.g.  SIP-ba=
sed


       =
  sessions, can handle mobility at the application layer and


       =
  hence do not need IP mobility support; it is then more


       =
  efficient to deactivate IP mobility support for such sessions.<=
/o:p>


 


 


PS5 is about enab=
ling mobility support only to clients that need it ?

Yes.


   PS5:  Unnecessary mobility=
 support to clients that do not need it


 


       &n=
bsp; IP mobility support is usually provided to all MNs.  Yet it is


       &n=
bsp; not always required, and not every parameter of mobility


       &n=
bsp; context is always used.  For example, some applications do not


       &n=
bsp; need a stable IP address during a handover to maintain session


       &n=
bsp; continuity.  Sometimes, the entire application session runs<=
/o:p>


       &n=
bsp; while the terminal does not change the point of attachment.=



       &n=
bsp; Besides, some sessions, e.g.  SIP-based sessions, can handle=



       &n=
bsp; mobility at the application layer and hence do not need IP<=
/span>


       &n=
bsp; mobility support; it is then unnecessary to provide IP mobility


       &n=
bsp; support for such sessions.


 


 


 &nb=
sp; PS6:  (Related problem) Mobility signaling overhead with peer-to-p=
eer


 &nb=
sp;       communication


&nbs=
p;


 &nb=
sp;       Wasting resources when mobility sig=
naling (e.g., maintenance of


 &nb=
sp;       the tunnel, keep alive signaling, e=
tc.) is not turned off for


 &nb=
sp;       peer-to-peer communication.  <=
/span>Peer-to-peer communications have=



      &nbs=
p;  particular traffic patterns that often do not benefit from


      &nbs=
p;  mobility support from the network.  Thus, the associat=
ed


         mobility support s=
ignaling (e.g., maintenance of the tunnel,


         keep alive signali=
ng, etc.) wastes network resources for no


         application gain.<=
o:p>


 


So, the problem i=
s about signaling load in the network. You=
 want to minimize the signaling load in the mobility network because of the=
 Peer-to-Peer application traffic ? Ok.


Delete as sho=
wn above


 


   PS7:  (Related problem) =
Deployment with multiple mobility solutions


 


        =
; There are already many variants and extensions of MIP.


       =
  Deployment of new mobility management solutions can be


       =
  challenging, and debugging difficult, when they must co-exist


       =
  with solutions already in the field.


 


 


You mean to say, "protocols" or "solutions&q=
uot; ? 


 


Both. A ne=
w solution may not need a new protocol whereas a given protocol can be depl=
oyed in different manners.


 =
;


So, this is a section on "Problem Statement". Why=
 is this talking about a requirement ?


Delete “=
;must” which seem like a requirement.


       &n=
bsp; There are already many variants and extensions of MIP.


       &n=
bsp; Deployment of new mobility management solutions can be


       &n=
bsp; challenging, and debugging difficult, when they co-exist with


       &n=
bsp; solutions already deployed in the field.


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 10]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   PS8:  Duplicate multicas=
t traffic


 


       =
  IP multicast distribution over architectures using IP mobility<=
/o:p>


       =
  solutions (e.g., [RFC6224]) may lead to convergence of


       =
  duplicated multicast subscriptions towards the downstream=



       =
  tunnel entity (e.g.  MAG in PMIPv6).  Concretely, when


       =
  multicast subscription for individual mobile nodes is coupled


       =
  with mobility tunnels (e.g.  PMIPv6 tunnel), duplicate


       =
  multicast subscription(s) is prone to be received through=



       =
  different upstream paths.  This problem may also exist or be


       =
  more severe in a distributed mobility environment.=



 


 


5.  Requirements

 


   After comparing distributed m=
obility management against centralized


   deployment in Section 3, this=
 section identifies the following


   requirements:


 


5.1.  Distributed processing


 


   REQ1:  Distributed proce=
ssing


 


       =
   IP mobility, network access and routing solutions provided by<=
o:p>


        =
;  DMM MUST enable distributed processing for mobility management=



       =
   so that traffic can avoid traversing single mobility anchor


       =
   far from the optimal route.


 


       =
   Motivation: This requirement is motivated by current trends in=



        =
;  network evolution: (a) it is cost- and resource-effective to


       =
   cache and distribute content by combining distributed mobility=



       =
   anchors with caching systems (e.g., CDN); (b) the


       =
   significantly larger number of mobile nodes and flows call for=



       =
   improved scalability; (c) single points of failure are avoided=



       =
   in a distributed system; (d) threats against centrally


       =
   deployed anchors, e.g., home agent and local mobility anchor,<=
o:p>


       =
   are mitigated in a distributed system.


 


   This requirement addresses th=
e problems PS1, PS2, PS3, and PS4


   described in Section 4.<=
/o:p>


 


5.2.  Transparency to Upper Layers wh=
en needed


 


   REQ2:  Transparency to U=
pper Layers when needed


 


       =
   DMM solutions MUST provide transparent mobility support above<=
o:p>


       =
   the IP layer when needed.  Such transparency is needed, f=
or


       =
   example, when, upon change of point of attachment to the<=
/o:p>


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 11]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


       =
   network, an application flow cannot cope with a change in the<=
o:p>


       =
   IP address.  However, it is not always necessary to maint=
ain a


       =
   stable home IP address or prefix for every application or at


       =
   all times for a mobile node.


 


       =
   Motivation: The motivation of this requirement is to enable


       =
   more efficient routing and more efficient use of network<=
/o:p>


       =
   resources by selecting an IP address or prefix according to


       =
   whether mobility support is needed and by not maintaining=



       =
   context at the mobility anchor when there is no such need.


 


   This requirement addresses th=
e problem PS5 as well as the related


   problem PS6 stated in Section=
 4.


 


5.3.  IPv6 deployment


 


   REQ3:  IPv6 deployment


 


       =
   DMM solutions SHOULD target IPv6 as the primary deployment


       =
   environment and SHOULD NOT be tailored specifically to support=



       =
   IPv4, in particular in situations where private IPv4 addresses=



       =
   and/or NATs are used.


 


       =
   Motivation: This requirement conforms to the general


       =
   orientation of IETF work.  DMM deployment is foreseen in =
mid-


       =
   to long-term horizon, when IPv6 is expected to be far more


       =
   common than today.


 


   This requirement avoids the u=
nnecessarily complexity in solving the


   problems in Section 4 for IPv=
4, which will not be able to use some of


   the IPv6-specific features.


 


 


 


 


 


5.4.  Existing mobility protocols


 


   REQ4:  Existing mobility=
 protocols


 


       =
   A DMM solution SHOULD first consider reusing and extending


       =
   IETF-standardized protocols before specifying new protocols.


 


       =
   Motivation: Reuse of existing IETF work is more efficient and<=
o:p>


       =
   less error-prone.


 


   This requirement attempts to =
avoid the need of new protocols


   development and therefore the=
ir potential problems of being time-


   consuming and error-prone.


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 12]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


5.5.  Co-existence<=
/pre>

 


   REQ5:  Co-existence with=
 deployed networks and hosts


 


       =
   The DMM solution MUST be able to co-exist with existing


       =
   network deployments and end hosts.  For example, dependin=
g on


       =
   the environment in which DMM is deployed, DMM solutions may


       =
   need to be compatible with other deployed mobility protocols


       =
   or may need to co-exist with a network or mobile hosts/routers=



       =
   that do not support DMM protocols.  The mobile node may a=
lso


       =
   move between different access networks, where some of them may=



       =
   support neither DMM nor another mobility protocol.<=
/span>


       =
   Furthermore, a DMM solution SHOULD work across different<=
/o:p>


       =
   networks, possibly operated as separate administrative


       =
   domains, when allowed by the trust relationship between them.<=
o:p>


 


       =
   Motivation: (a) to preserve backwards compatibility so that


       =
   existing networks and hosts are not affected and continue to


       =
   function as usual, and (b) enable inter-domain operation if


       =
   desired.


 


   This requirement addresses th=
e related problem PS7 described in


   Section 4.<=
/pre>

 


5.6.  Security considerations


 


   REQ6:  Security consider=
ations


 


       =
   A DMM solution MUST not introduce new security risks or


       =
   amplify existing security risks against which the existing


       =
   security mechanisms/protocols cannot offer sufficient


       =
   protection.


 


       =
   Motivation: Various attacks such as impersonation, denial of


       =
   service, man-in-the-middle attacks, and so on, may be launched=



       =
   in a DMM deployment.  For instance, an illegitimate node =
may


       =
   attempt to access a network providing DMM.  Another examp=
le is


       =
   that a malicious node can forge a number of signaling messages=



       =
   thus redirecting traffic from its legitimate path.<=
/span>


       =
   Consequently, the specific node is under a denial of service


       =
   attack, whereas other nodes do not receive their traffic.=



       =
   Accordingly, security mechanisms/protocols providing access


       =
   control, integrity, authentication, authorization,<=
/span>


       =
   confidentiality, etc. can be used to protect the DMM entities<=
o:p>


       =
   as they are already used to protect against existing networks<=
o:p>


       =
   and existing mobility protocols defined in IETF.


 


   This requirement prevents a D=
MM solution from introducing


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 13]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   uncontrollable problems of po=
tentially insecure mobility management


   protocols which make deployme=
nt infeasible because platforms


   conforming to the protocols a=
re at risk for data loss and numerous


   other dangers, including fina=
ncial harm to the users.


 


 


 


 


 


5.7.  Multicast

 


   REQ7:  Multicast conside=
rations


 


       =
   DMM SHOULD consider multicast early so that solutions can be


       =
   developed not only to provide IP mobility support when it is


       =
   needed, but also to avoid network inefficiency issues in<=
/o:p>


       =
   multicast traffic delivery (such as duplicate multicast


       =
   subscriptions towards the downstream tunnel entities).  T=
he


       =
   multicast solutions should therefore avoid restricting the


       =
   management of all IP multicast traffic to a single host


       =
   through a dedicated (tunnel) interface on multicast-capable


       =
   access routers.


 


       =
   Motivation: Existing multicast deployment have been introduced=



       =
   after completing the design of the reference mobility


       =
   protocol, then optimization and extensions have been followed<=
o:p>


       =
   by "patching-up" procedure, thus leading to network<=
o:p>


       =
   inefficiency and non-optimal routing.  The multicast solu=
tions


       =
   should therefore be required to consider efficiency nature in<=
o:p>


       =
   multicast traffic delivery.


 


[Sri] Considering=
 multicast at a design phase is not technical requirement for DMM.


What is "pat=
ching up" procedure ? 


 


Revise as fol=
lows:


   REQ7:  Multicast considera=
tions


 


       &n=
bsp;  DMM SHOULD enable multicast solutions to be developed to avoid


       &n=
bsp;  network inefficiency in multicast traffic delivery.


 


       &n=
bsp;  Motivation: Existing multicast deployment have been introduced


       &n=
bsp;  after completing the design of the reference mobility=



       &n=
bsp;  protocol, often leading to network inefficiency and non-


       &n=
bsp;  optimal routing for the multicast traffic.  Instead DMM sho=
uld


       &n=
bsp;  consider multicast early so that the multicast solutions can


       &n=
bsp;  better consider efficiency nature in the multicast traffic<=
/o:p>


       &n=
bsp;  delivery (such as duplicate multicast subscriptions towards=



       &n=
bsp;  the downstream tunnel entities).  The multicast solutions


       &n=
bsp;  should then avoid restricting the management of all IP


       &n=
bsp;  multicast traffic to a single host through a dedicated


       &n=
bsp;  (tunnel) interface on multicast-capable access routers.


 


 


   This requirement addresses th=
e problems PS1 and PS8 described in


   Section 4.<=
/pre>

 


 


6.  Security Considerations


 


   Please refer to the discussio=
n under Security requirement in Section


   5.6.


 


 


7.  IANA Considerations


 


   None


 


 


8.  Co-authors and Contributors<=
/o:p>


 


   This problem statement docume=
nt is a joint effort among the numerous


   participants.  Each indi=
vidual has made significant contributions to


   this work and have been liste=
d as co-authors.


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 14]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


9.  References

 


9.1.  Normative References=



 


   [RFC2119]  Bradner, S., =
"Key words for use in RFCs to Indicate


       =
       Requirement Levels", BCP 14, RFC =
2119, March 1997.


 


9.2.  Informative References


 


   [I-D.bhandari-dhc-class-based=
-prefix]


       =
       Bhandari, S., Halwasia, G., Gundavelli=
, S., Deng, H.,


       =
       Thiebaut, L., Korhonen, J., and I. Far=
rer, "DHCPv6 class


       =
       based prefix", draft-bhandari-dhc=
-class-based-prefix-05


       =
       (work in progress), July 2013.


 


   [I-D.korhonen-6man-prefix-pro=
perties]


       =
       Korhonen, J., Patil, B., Gundavelli, S=
., Seite, P., and D.


       =
       Liu, "IPv6 Prefix Properties"=
;,


       =
       draft-korhonen-6man-prefix-properties-=
02 (work in


       =
       progress), July 2013.


 


   [I-D.wakikawa-netext-pmip-cp-=
up-separation]


       =
       Wakikawa, R., Pazhyannur, R., and S. G=
undavelli,


       =
       "Separation of Control and User P=
lane for Proxy Mobile


       =
       IPv6", draft-wakikawa-netext-pmip=
-cp-up-separation-00


       =
       (work in progress), July 2013.


 


   [I-D.yokota-dmm-scenario]


       =
       Yokota, H., Seite, P., Demaria, E., an=
d Z. Cao, "Use case


       =
       scenarios  for Distributed Mobili=
ty Management",


       =
       draft-yokota-dmm-scenario-00 (work in =
progress),


       =
       October 2010.


 


   [Paper-Distributed.Centralize=
d.Mobility]


       =
       Bertin, P., Bonjour, S., and J-M. Bonn=
in, "A Distributed


       =
       or Centralized Mobility",  P=
roceedings of Global


       =
       Communications Conference  (Globe=
Com), December 2009.


 


   [Paper-Distributed.Dynamic.Mo=
bility]


       =
       Bertin, P., Bonjour, S., and J-M. Bonn=
in, "A Distributed


       =
       Dynamic Mobility Management Scheme&nbs=
p; Designed for Flat IP


       =
       Architectures",  Proceedings=
 of 3rd International


       =
       Conference  on New Technologies, =
Mobility and Security


       =
       (NTMS), 2008.


 


   [Paper-Distributed.Mobility.M=
IP]


       =
       Chan, H., "Distributed Mobility M=
anagement with Mobile


       =
       IP",  Proceedings of  I=
EEE International Communication


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 15]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


       =
       Conference (ICC)  Workshop on Tel=
ecommunications:  from


        =
;      Research to Standards, June 2012.=



 


   [Paper-Distributed.Mobility.P=
MIP]


       =
       Chan, H., "Proxy Mobile IP  =
with Distributed Mobility


       =
       Anchors",  Proceedings of Gl=
obeCom Workshop  on Seamless


       =
       Wireless Mobility, December 2010.=



 


   [Paper-Distributed.Mobility.R=
eview]


       =
       Chan, H., Yokota, H., Xie, J., Seite, =
P., and D. Liu,


       =
       "Distributed and Dynamic Mobility=
 Management  in Mobile


       =
       Internet: Current Approaches and Issue=
s, Journal of


       =
       Communications, vol. 6, no. 1, pp. 4-1=
5, Feb 2011.",


       =
        Proceedings of GlobeCom Workshop=
  on Seamless Wireless


       =
       Mobility, February 2011.


 


   [Paper-Distributed.Mobility.S=
AE]


       =
       Fisher, M., Anderson, F., Kopsel, A., =
Schafer, G., and M.


       =
       Schlager, "A Distributed IP Mobil=
ity Approach for 3G SAE",


       =
        Proceedings of the 19th Internat=
ional Symposium  on


       =
       Personal, Indoor and Mobile Radio Comm=
unications (PIMRC),


       =
       2008.


 


   [Paper-Locating.User]


       =
       Kirby, G., "Locating the User&quo=
t;,  Communication


       =
       International, 1995.=



 


   [Paper-Migrating.Home.Agents]=



       =
       Wakikawa, R., Valadon, G., and J. Mura=
i, "Migrating Home


       =
       Agents  Towards Internet-scale Mo=
bility Deployments",


       =
        Proceedings of the ACM 2nd CoNEX=
T Conference  on Future


       =
       Networking Technologies, December 2006=
.


 


   [Paper-Mobile.Data.Offloading=
]


       =
       Lee, K., Lee, J., Yi, Y., Rhee, I., an=
d S. Chong, "Mobile


       =
       Data Offloading: How Much Can WiFi Del=
iver?",  SIGCOMM


       =
       2010, 2010.


 


   [RFC3753]  Manner, J. an=
d M. Kojo, "Mobility Related Terminology",

       =
       RFC 3753, June 2004.=



 


   [RFC5213]  Gundavelli, S=
., Leung, K., Devarapalli, V., Chowdhury, K.,


       =
       and B. Patil, "Proxy Mobile IPv6&=
quot;, RFC 5213, August 2008.


 


   [RFC5380]  Soliman, H., =
Castelluccia, C., ElMalki, K., and L.


       =
       Bellier, "Hierarchical Mobile IPv=
6 (HMIPv6) Mobility


       =
       Management", RFC 5380, October 20=
08.


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 16]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   [RFC5944]  Perkins, C., =
"IP Mobility Support for IPv4, Revised",


       =
       RFC 5944, November 2010.


 


   [RFC6224]  Schmidt, T., =
Waehlisch, M., and S. Krishnan, "Base


       =
       Deployment for Multicast Listener Supp=
ort in Proxy Mobile


       =
       IPv6 (PMIPv6) Domains", RFC 6224,=
 April 2011.


 


   [RFC6275]  Perkins, C., =
Johnson, D., and J. Arkko, "Mobility Support


       =
       in IPv6", RFC 6275, July 2011.


 


   [RFC6301]  Zhu, Z., Waki=
kawa, R., and L. Zhang, "A Survey of Mobility


       =
       Support in the Internet", RFC 630=
1, July 2011.


 


   [RFC6705]  Krishnan, S.,=
 Koodli, R., Loureiro, P., Wu, Q., and A.


       =
       Dutta, "Localized Routing for Pro=
xy Mobile IPv6",


       =
       RFC 6705, September 2012.


 


   [RFC6909]  Gundavelli, S=
., Zhou, X., Korhonen, J., Feige, G., and R.


       =
       Koodli, "IPv4 Traffic Offload Sel=
ector Option for Proxy


       =
       Mobile IPv6", RFC 6909, April 201=
3.


 


   [TS.23.401]=



       =
       3GPP, "General Packet Radio Servi=
ce (GPRS) enhancements


       =
       for Evolved Universal Terrestrial Radi=
o Access Network


       =
       (E-UTRAN) access", 3GPP TR 23.401=
 10.10.0, March 2013.


 


   [TS.29303]<=
/pre>

       =
       3GPP, "Domain Name System Procedu=
res; Stage 3", 3GPP


       =
       TR 23.303 11.2.0, September 2012.=



 


 


Authors' Addresses


 


   H Anthony Chan (editor)<=
/o:p>


   Huawei Technologies (more co-=
authors on P. 17)


   5340 Legacy Dr. Building 3, P=
lano, TX 75024, USA


   Email: h.a.chan@ieee.org


 


 


   Dapeng Liu<=
/pre>

   China Mobile


   Unit2, 28 Xuanwumenxi Ave, Xu=
anwu District, Beijing 100053, China


   Email: liudapeng@chinamobile.com

 


 


 


 


 


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 17]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   Pierrick Seite


   Orange

   4, rue du Clos Courtel, BP 91=
226, Cesson-Sevigne 35512, France


   Email: pierrick.seite@orange.com

 


 


   Hidetoshi Yokota


   KDDI Lab

   2-1-15 Ohara, Fujimino, Saita=
ma, 356-8502 Japan


   Email: yokota@kddilabs.jp


 


 


   Jouni Korhonen


   Renesas Mobile


   Porkkalankatu 24, FIN-00180 H=
elsinki, Finland


   Email: jouni.korhonen@nsn.com


   -


   Charles E. Perkins=



   Huawei Technologies


   Email: charliep@computer.org


   -


   Melia Telemaco


   Alcatel-Lucent Bell Labs=



   Email: telemaco.melia@alcatel-lucent.com


   -


   Elena Demaria


   Telecom Italia


   via G. Reiss Romoli, 274, TOR=
INO, 10148, Italy


   Email: elena.demaria@telecomitalia.it


   -


   Jong-Hyouk Lee


   Sangmyung University


   Email: hurryon@gmail.com


   -


   Kostas Pentikousis=



   EICT GmbH

   Email: k.pentikousis@eict.de


   -


   Tricci So

   ZTE


   Email: tso@zteusa.com


   -


   Carlos J. Bernardos


   Universidad Carlos III de Mad=
rid


   Av. Universidad, 30, Leganes,=
 Madrid 28911, Spain


   Email: cjbc@it.uc3m.es


   -


   Peter McCann


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 18]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   Huawei Technologies


   Email: PeterMcCann@huawei.com


   -


   Seok Joo Koh


   Kyungpook National University=
, Korea


   Email: sjkoh@knu.ac.kr


   -


   Wen Luo

   ZTE


   No.68, Zijinhua RD,Yuhuatai D=
istrict, Nanjing, Jiangsu 210012, China


   Email: luo.wen@zte.com.cn


   -


   Sri Gundavelli


   Cisco


   sgundave@cisco.com


   -


   Marco Liebsch


   NEC Laboratories Europe<=
/o:p>


   Email: liebsch@neclab.eu


   -


   Carl Williams


   MCSR Labs

   Email: carlw@mcsr-labs.org


   -


   Seil Jeon

   Instituto de Telecomunicacoes=
, Aveiro


   Email: seiljeon@av.it.pt


   -


   Sergio Figueiredo<=
/span>


   Universidade de Aveiro


   Email: sfigueiredo@av.it.pt


   -


   Stig Venaas=



   Email: stig@venaas.com


   -


   Luis Miguel Contreras Murillo=



   Telefonica I+D=



   Email: lmcm@tid.es


   -


   Juan Carlos Zuniga=



   InterDigital


   Email: JuanCarlos.Zuniga@InterDigital.com=



   -


   Alexandru Petrescu=



   Email: alexandru.petrescu@gmail.com


   -


   Georgios Karagiannis


   University of Twente


 


 


 


Chan (Ed.), et al.    =
    Expires May 11, 2014      =
           [Page 19]=



 


Internet-Draft    &nbs=
p;             =
DMM-Reqs           &=
nbsp;       November 2013

 


 


   Email: g.karagiannis@utwente.nl


   -


   Julien Laganier


   Juniper

   jlaganier@juniper.net


   -


   Wassim Michel Haddad


   Ericsson

   Wassam.Haddad@ericsson.com


   -


   Dirk von Hugo


   Deutsche Telekom Laboratories=



   Dirk.von-Hugo@telekom.de


   -


   Ahmad Muhanna


   Award Solutions


   amuhanna@awardsolutions.com


   -


   Byoung-Jo Kim


   ATT Labs

   macsbug@research.att.com


   -


   Hassan Ali-Ahmad


   Orange

   hassan.aliahmad@orange.com


   -


   Alper Yegin=



   Samsung

   alper.yegin@partner.samsung.com=



   -


 


 


 


 


 


 


 


 


 


 


 


 


 


 








--_000_6E31144C030982429702B11D6746B98C370E7086szxeml557mbxchi_--


From sgundave@cisco.com  Wed Nov 20 12:40:27 2013
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 178F51AE2C9 for ; Wed, 20 Nov 2013 12:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.025
X-Spam-Level: 
X-Spam-Status: No, score=-15.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 eUUA-s4Kg_0e for ; Wed, 20 Nov 2013 12:40:26 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CD0021AE278 for ; Wed, 20 Nov 2013 12:40:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4562; q=dns/txt; s=iport; t=1384980019; x=1386189619; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=16+uYokgHFS/p0ADaKkUiDmNgjIIvUZoQ+SyHrfS6/c=; b=jNLum8wzUTL6co+efwBGqOAJ7PFUxagNkocqpRE3t/srVuKuflJESUQs yRPFm9JWCA3P/1Bezx+t4pVZOHQbhzP90wu+jvGbnMG+qQuI3DB9678ZI ApdvsB9ba/sge1g4G69b3aOBG4gnue58VKopKBipskQBVEPppCUf2EnVT g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhEFAAMdjVKtJV2c/2dsb2JhbABZgkNEgQu9cYEaFnSCJQECBIELAQgRAwECKDkUCQgCBAESiAHBAI9GGIQyA5gSkg2DKIIq
X-IronPort-AV: E=Sophos;i="4.93,739,1378857600";  d="scan'208,217";a="286425605"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 20 Nov 2013 20:40:19 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAKKeIck010530 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 20:40:18 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.200]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 14:40:18 -0600
From: "Sri Gundavelli (sgundave)" 
To: h chan , "dmm@ietf.org" 
Thread-Topic: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
Thread-Index: AQHO5jC48xNumqgVNEGV0XEqGexEFw==
Date: Wed, 20 Nov 2013 20:40:17 +0000
Message-ID: 
In-Reply-To: <6E31144C030982429702B11D6746B98C370E6FAE@szxeml557-mbx.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.214]
Content-Type: multipart/alternative; boundary="_000_CEB25E1EEA4B7sgundaveciscocom_"
MIME-Version: 1.0
Subject: Re: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt
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, 20 Nov 2013 20:40:27 -0000

--_000_CEB25E1EEA4B7sgundaveciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Anthony,

Thanks for the updates.


Regards
Sri

From: h chan >
Date: Tuesday, November 19, 2013 6:11 PM
To: Sri Gundavelli >, "dmm@ie=
tf.org" >
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-requirements-07.txt

Sri,
Suggested revisions are shown in blue below.
Not sure about what improvements are desired for the definitions though.

H Anthony Chan

--_000_CEB25E1EEA4B7sgundaveciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Anthony,







Thanks for the updates.












Regards


Sri









From: h chan <h.anthony.chan@huawei.com>

Date: Tuesday, November 19, 2013 6:=
11 PM

To: Sri Gundavelli <sgundave@cisco.com>, "dmm@ietf.org" <dmm@ietf.org>

Subject: RE: [DMM] I-D Action: draf=
t-ietf-dmm-requirements-07.txt











Sri,



Suggested revisions are shown in blue below.



Not sure about what improvements are desired for the defi=
nitions though.



 





H Anthony Chan







--_000_CEB25E1EEA4B7sgundaveciscocom_--

From internet-drafts@ietf.org  Wed Nov 20 15:12:37 2013
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 DF1A01AE595; Wed, 20 Nov 2013 15:12:37 -0800 (PST)
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 ESAWqDaXV3Y5; Wed, 20 Nov 2013 15:12:36 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8BE1AE58F; Wed, 20 Nov 2013 15:12:36 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.83.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20131120231236.8976.25339.idtracker@ietfa.amsl.com>
Date: Wed, 20 Nov 2013 15:12:36 -0800
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-11.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: Wed, 20 Nov 2013 23:12:38 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Distributed Mobility Management Working G=
roup of the IETF.

	Title           : Requirements for Distributed Mobility Management
	Author(s)       : H Anthony Chan
                          Dapeng Liu
                          Pierrick Seite
                          Hidetoshi Yokota
                          Jouni Korhonen
	Filename        : draft-ietf-dmm-requirements-11.txt
	Pages           : 19
	Date            : 2013-11-20

Abstract:
   This document defines the requirements for Distributed Mobility
   Management (DMM).  The hierarchical structure in traditional wireless
   networks has led primarily to centralized deployment models.  As some
   wireless networks are evolving away from the hierarchical structure,
   a distributed model for mobility management can be useful to them.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-requirements

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-requirements-11

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-requirements-11


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 alper.yegin@yegin.org  Fri Nov 22 03:12:18 2013
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 16DDB1AE051 for ; Fri, 22 Nov 2013 03:12:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.554
X-Spam-Level: 
X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 sNfCKdyz2nyV for ; Fri, 22 Nov 2013 03:12:16 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A17341AC828 for ; Fri, 22 Nov 2013 03:12:16 -0800 (PST)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M3zXW-1VRsOb1FMw-00rgvn; Fri, 22 Nov 2013 06:12:09 -0500
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Apple Message framework v1283)
From: Alper Yegin 
In-Reply-To: 
Date: Fri, 22 Nov 2013 13:12:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: dmm 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:+GV59MN1CqT6qVY4pRajDRDvHftYQW6dkhIfar3ADVR 2Vd7f4KZ3tDhCHP1GxmJvmeiQdIbyYl6xHaXN18cltsNaiUR3D h6xw2VuoVCIRGuEzI+ZcrYiSwbjMUI7luxy9CswtR+XxiLOQRc T0cdgLSkhR7RQfKIQ8CST7Qpd753sPgsd/yP7yqNnDBaX36+oo VN+EoSXlXwjp/9PUN6+lMnyfkqu4EQK5dyXiwmd05S86OVmfTF b16sX9TlkzacLvOx7ciHUB1q9GxG0dOSQuQ150t/+vSG3//l5i zMqOo8PSz0Emj7x1OtepZsyJPqCOVf8yn2bkYMDEf8tWFP6bg1 gQoqvOAJu1j/9qM8rVrN+L/LuRv+xIIfZh3HOIH2UXX7I3X1PI cPvl71eJXw3rw==
Subject: [DMM] tunnels-vs-host routes and other DMM components
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, 22 Nov 2013 11:12:18 -0000

Hello folks,

Using tunnels vs. propagating host routes across a domain=85

The former is proven to work. The latter appears to have attractive =
attributes (e.g., absence of tunneling overhead, fully distributed =
nature, etc.), but there are also aspects that need to be addressed, =
such as:
- Can it scale (passing host-routes for millions of nodes even in single =
operator network)?
- Can it converge fast enough for seamless handovers?
- Is it practical from charging, lawful intercept, DPI, policy =
enforcement point of view?
- How do we deal with the case when the MN moves outside the domain? =
(probably we need to fall back to using a tunnel-based solution)

The host-route-based schemes need to overcome these challenges to appear =
as an alternative to tunnel-based solutions. I'm hoping the proponents =
of those scheme will show us how they handle these issues.

Maybe it'll turn out that under certain conditions host-route-based =
solutions work just fine (Pete was pointing at local mobility). If so, =
we can recognize that and tell people they can use such solutions =
instead of tunnel-based solutions, where applicable.=20

For example: If the anchor is within an operator network it can be used =
(which can substitute for tunnel-based anchoring on a central HA and =
also on previous AR -- but not for anchoring near the corresponding =
network which works across the Internet).=20

...

But note that, that discussion is just about  one component of DMM =
solution set. There are other components, which are not impacted by that =
discussion. Such as:
- The MN stack treating flows differently with respect to their mobility =
needs (assigning different types [colors/anchor type, etc] of IP =
addresses)
- The MN stack choosing anchors (i.e., selecting a specific anchor node =
based in the anchor type selection).

=85

And whenever a component involves DP/CP, we should recognize that they =
are separable and take that into account.=20


Alper






From alper.yegin@yegin.org  Fri Nov 22 03:16:00 2013
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 07B531AD8F3 for ; Fri, 22 Nov 2013 03:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.554
X-Spam-Level: 
X-Spam-Status: No, score=-0.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, 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 JXA1vxXJyCPj for ; Fri, 22 Nov 2013 03:15:59 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5551AC828 for ; Fri, 22 Nov 2013 03:15:59 -0800 (PST)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MQRKW-1W6w851vIq-00UDwG; Fri, 22 Nov 2013 06:15:50 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Alper Yegin 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com>
Date: Fri, 22 Nov 2013 13:15:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <2DA2F3E4-5C8C-4870-927B-4223AE24FF38@yegin.org>
References: <5963DDF1F751474D8DEEFDCDBEE43AE717948757@dfweml511-mbs.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE7179488EC@dfweml511-mbs.china.huawei.com> <52839A22.5090301@innovationslab.net> <5963DDF1F751474D8DEEFDCDBEE43AE717948BD6@dfweml511-mbs.china.huawei.com>
To: Peter McCann 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:2iqALR+cFxcql3PcdtXWUDykq8Q7lJlPelVuYt+VKyf 0NN8H8WE0b+SsbyYTvA2SUGMuP6BacFgUdFXEFHnMt+PQVaz0+ eKA9jsuN7snm6Pq0iRpcBDOVxjbH5cvsaP4NoUegyPONYD4Qss CKJX8dKu6HXRSx1bHyBepZxdcgP7z2BqCLel37nyNBeJMD1wN2 ++wEqdy9m8y6uFy1/7o6W9ScwQs3tI/WNHyYHmlqnEu2AroRd4 x3ZBJFybk5E9wLV6AS6iAEtfyeA26GObFIr2KW80C3mHqgN+oW tCwSBssXQGLVR27cq8+187ldm/v3hAZOCh4pott9qbDMqceDI1 GDvhiQZXDsXf39xTKuRDMChwUc2fYLHRjy8FFlOElgzcw7epOu J1A/KYukwvl/g==
Cc: "dmm@ietf.org" 
Subject: Re: [DMM] Preparing for DMM future steps and 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, 22 Nov 2013 11:16:00 -0000

Hi Pete,

> This obviously wouldn't work for billions of MNs.  But, with DMM =
people
> are starting to realize that MNs don't need completely stable global =
addresses
> that live forever. =20

Most don't, but some do. We need to account for them as well.

> So I think DMM should focus on localized mobility management.

This is not sufficient.
Think of the typical case where MN moves from cellular network of one =
operator to WiFi network of another operator.
This can be a physically localized, but topologically a global handover.

Alper




From alexandru.petrescu@gmail.com  Fri Nov 22 03:47:22 2013
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 AE7861AD738 for ; Fri, 22 Nov 2013 03:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level: 
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 oZi4heWiiI3A for ; Fri, 22 Nov 2013 03:47:20 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 901D51ACCEA for ; Fri, 22 Nov 2013 03:47:20 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rAMBlClO030986; Fri, 22 Nov 2013 12:47:12 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 48C672041F0; Fri, 22 Nov 2013 12:47:39 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3BE242041E6; Fri, 22 Nov 2013 12:47:39 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id rAMBl9aM027870; Fri, 22 Nov 2013 12:47:12 +0100
Message-ID: <528F443D.9060302@gmail.com>
Date: Fri, 22 Nov 2013 12:47:09 +0100
From: Alexandru Petrescu 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Alper Yegin 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: dmm 
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 22 Nov 2013 11:47:22 -0000

Hello Alper,

In this discussion, I may be missing the 'Mobile Router vs Host' dimension.

We would use host-based routes if we need Mobile Hosts, but we'd use 
prefix-based routes if we needed Mobile Routers.

The route convergence speed and domain size scalability aspects apply 
differently.

Additionally, I would shape the question from the other point of view as 
well: is it reasonable for PMIP solution to use tunnels even if the 
mobile stays within the same domain?

Alex

Le 22/11/2013 12:12, Alper Yegin a écrit :
> Hello folks,
>
> Using tunnels vs. propagating host routes across a domain…
>
> The former is proven to work. The latter appears to have attractive attributes (e.g., absence of tunneling overhead, fully distributed nature, etc.), but there are also aspects that need to be addressed, such as:
> - Can it scale (passing host-routes for millions of nodes even in single operator network)?
> - Can it converge fast enough for seamless handovers?
> - Is it practical from charging, lawful intercept, DPI, policy enforcement point of view?
> - How do we deal with the case when the MN moves outside the domain? (probably we need to fall back to using a tunnel-based solution)
>
> The host-route-based schemes need to overcome these challenges to appear as an alternative to tunnel-based solutions. I'm hoping the proponents of those scheme will show us how they handle these issues.
>
> Maybe it'll turn out that under certain conditions host-route-based solutions work just fine (Pete was pointing at local mobility). If so, we can recognize that and tell people they can use such solutions instead of tunnel-based solutions, where applicable.
>
> For example: If the anchor is within an operator network it can be used (which can substitute for tunnel-based anchoring on a central HA and also on previous AR -- but not for anchoring near the corresponding network which works across the Internet).
>
> ...
>
> But note that, that discussion is just about  one component of DMM solution set. There are other components, which are not impacted by that discussion. Such as:
> - The MN stack treating flows differently with respect to their mobility needs (assigning different types [colors/anchor type, etc] of IP addresses)
> - The MN stack choosing anchors (i.e., selecting a specific anchor node based in the anchor type selection).
>
> …
>
> And whenever a component involves DP/CP, we should recognize that they are separable and take that into account.
>
>
> Alper
>
>
>
>
>
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
>



From jouni.nospam@gmail.com  Fri Nov 22 06:11:06 2013
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 86ACF1AE0A3 for ; Fri, 22 Nov 2013 06:11:06 -0800 (PST)
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 7gtvA94pm27z for ; Fri, 22 Nov 2013 06:11:02 -0800 (PST)
Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 18B261ADF69 for ; Fri, 22 Nov 2013 06:11:01 -0800 (PST)
Received: by mail-we0-f179.google.com with SMTP id q59so1167307wes.24 for ; Fri, 22 Nov 2013 06:10:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oB23rR3z0OLsJbLTMr0UlShVz+BZye9E0M+Gzh3daCI=; b=qHXmsUWl3fEf8mF27M5FDS4xd7k6FwuE2mOEC5JVr6jywReM/a88UKLEZOsmN7kQZ4 f1KIfVrfIy3QcxrtYR8FbpqEX64GIvodbPyS8OFrA4Y8GprRYpnVGO7cSob4nwhM3chA tjfqU7oMgWtIcH+I60dOtgVRq7G3ZoNXQEgRsiaxwlNjQb7hEAop1S4aqUJiVG9fkRIN DWdfAy719YTNF6Rdk3M/GMXdctUZNw/mt6eeFbcxJH+m8Dkjw8y7QbjCYJI+tFTxo9xf 8iDkzqHEKlIw+G2CJf/TdMpA4HLSVVh8FnxgxdvFeXuR1Q0+ZJgksaGh+QNEyRttt8Wk HT0w==
X-Received: by 10.180.103.39 with SMTP id ft7mr2813370wib.54.1385129454610; Fri, 22 Nov 2013 06:10:54 -0800 (PST)
Received: from [10.216.13.198] ([93.158.55.49]) by mx.google.com with ESMTPSA id c10sm16178973wie.11.2013.11.22.06.10.53 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 06:10:54 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Fri, 22 Nov 2013 16:10:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <65700191-0AF4-437B-AB4A-1E2975FA2D7F@gmail.com>
References:  
To: Alper Yegin 
X-Mailer: Apple Mail (2.1510)
Cc: dmm 
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 22 Nov 2013 14:11:06 -0000

Alper,

On Nov 22, 2013, at 1:12 PM, Alper Yegin  wrote:

> Hello folks,
>=20
> Using tunnels vs. propagating host routes across a domain=85
>=20
> The former is proven to work. The latter appears to have attractive =
attributes (e.g., absence of tunneling overhead, fully distributed =
nature, etc.), but there are also aspects that need to be addressed, =
such as:
> - Can it scale (passing host-routes for millions of nodes even in =
single operator network)?
> - Can it converge fast enough for seamless handovers?
> - Is it practical from charging, lawful intercept, DPI, policy =
enforcement point of view?
> - How do we deal with the case when the MN moves outside the domain? =
(probably we need to fall back to using a tunnel-based solution)
>=20
> The host-route-based schemes need to overcome these challenges to =
appear as an alternative to tunnel-based solutions. I'm hoping the =
proponents of those scheme will show us how they handle these issues.

It might be worth looking into what SPRING is doing in this domain.
The new work around source routing might have some useful assets for
our use, specifically if source routes can be added by intermediate
or border nodes.

Maybe there is something "innovative" to do, which would allow us to
go around host routes and related frequent  IGP updates. Maybe the
"innovative" thing just moves or renames the routing problem.. I do
not know :)

- Jouni

> Maybe it'll turn out that under certain conditions host-route-based =
solutions work just fine (Pete was pointing at local mobility). If so, =
we can recognize that and tell people they can use such solutions =
instead of tunnel-based solutions, where applicable.=20
>=20
> For example: If the anchor is within an operator network it can be =
used (which can substitute for tunnel-based anchoring on a central HA =
and also on previous AR -- but not for anchoring near the corresponding =
network which works across the Internet).=20
>=20
> ...
>=20
> But note that, that discussion is just about  one component of DMM =
solution set. There are other components, which are not impacted by that =
discussion. Such as:
> - The MN stack treating flows differently with respect to their =
mobility needs (assigning different types [colors/anchor type, etc] of =
IP addresses)
> - The MN stack choosing anchors (i.e., selecting a specific anchor =
node based in the anchor type selection).
>=20
> =85
>=20
> And whenever a component involves DP/CP, we should recognize that they =
are separable and take that into account.=20
>=20
>=20
> Alper
>=20
>=20
>=20
>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From Peter.McCann@huawei.com  Fri Nov 22 08:52:20 2013
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 C9F281AE28A for ; Fri, 22 Nov 2013 08:52:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.827
X-Spam-Level: 
X-Spam-Status: No, score=-0.827 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, 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 gZnnNgxYWkp9 for ; Fri, 22 Nov 2013 08:52:19 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D0C521AE057 for ; Fri, 22 Nov 2013 08:52:18 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYF30255; Fri, 22 Nov 2013 16:52:10 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 16:51:53 +0000
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 22 Nov 2013 16:52:09 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 22 Nov 2013 08:52:01 -0800
From: Peter McCann 
To: Alper Yegin , dmm 
Thread-Topic: [DMM] tunnels-vs-host routes and other DMM components
Thread-Index: AQHO56MqLSJ+psE0Xk2phtDza+B7KA==
Date: Fri, 22 Nov 2013 16:52:01 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7182E2235@dfweml510-mbx.china.huawei.com>
References:  
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.125.89]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 22 Nov 2013 16:52:21 -0000

Hi, Alper,

All good questions.  Some comments below.

Alper Yegin wrote:
> Hello folks,
>=20
> Using tunnels vs. propagating host routes across a domain...
>=20
> The former is proven to work. The latter appears to have attractive
> attributes (e.g., absence of tunneling overhead, fully distributed
> nature, etc.), but there are also aspects that need to be addressed,
> such as:
> - Can it scale (passing host-routes for millions of nodes even in
> single operator network)?

I think a better way to put this question is "over what scope does it
scale?"  Clearly it should work fine over a limited scope such as the
region spanned by one pool of route reflectors.  In some deployment=20
cases (such as when the MN is able to release an old address fairly=20
quickly) this may be enough.

> - Can it converge fast enough for seamless handovers?

I see no reason why it can't be just as fast as a tunnel setup, if not
moreso.  You just need to propagate an UPDATE message as far as the
crossover router, and install a route into the FIB.  There is no good
reason why this would take more time than installing a tunnel state.
Some BGP implementations may need to be tuned for proper performance.

> - Is it practical from charging, lawful intercept, DPI, policy
> enforcement point of view?

We shouldn't sacrifice fault tolerance and optimal routing on the
altar of these "features".  They won't be needed in every deployment,
and when they are needed, we can find ways to implement them without
forcing the traffic to a central location in an unscalable and
fault-intolerant way.

> - How do we deal with the case when the MN moves outside the domain?
> (probably we need to fall back to using a tunnel-based solution)

Yes, and I think that should be a client-based tunnel to handle the
likely situation where there is no relationship between the old and
new domains other than the fact that they are both connected to the
Internet.

> The host-route-based schemes need to overcome these challenges to
> appear as an alternative to tunnel-based solutions. I'm hoping the
> proponents of those scheme will show us how they handle these issues.

Agree further study is needed.

> Maybe it'll turn out that under certain conditions host-route-based
> solutions work just fine (Pete was pointing at local mobility). If so,
> we can recognize that and tell people they can use such solutions
> instead of tunnel-based solutions, where applicable.

Yes.

> For example: If the anchor is within an operator network it can be
> used (which can substitute for tunnel-based anchoring on a central HA
> and also on previous AR -- but not for anchoring near the
> corresponding network which works across the Internet).

True but anchoring at a CN requires cross-domain coordination for the
network-based mobility management case.

>=20
> ...
>=20
> But note that, that discussion is just about  one component of DMM
> solution set. There are other components, which are not impacted by
> that discussion. Such as:
> - The MN stack treating flows differently with respect to their
> mobility needs (assigning different types [colors/anchor type, etc] of
> IP addresses)

Yes we still need to have that discussion.  This can be worked out=20
independently of the mechanism used by the network-based mobility
scheme.

> - The MN stack choosing anchors (i.e., selecting a specific anchor
> node based in the anchor type selection).

Yes the software in the MN still needs to handle multiple simultaneous
addresses, choosing among them, and managing their lifecycles.  The=20
important feature of DMM is to enable a decoupling between the mobility
events and the address lifecycle, so that addresses can be maintained
for some time after a mobility event and new ones can be allocated when
it makes sense to do so (not forced at the time of mobility).

> ...
>=20
> And whenever a component involves DP/CP, we should recognize that they
> are separable and take that into account.

Agree but with the caveat that DMM is not the right place to standardized
CP/DP interface protocols.

-Pete

> Alper


From alper.yegin@yegin.org  Sat Nov 23 01:44:30 2013
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 CCCF51AE25A for ; Sat, 23 Nov 2013 01:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.358
X-Spam-Level: 
X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, 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 SidtgeHynT-t for ; Sat, 23 Nov 2013 01:44:29 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id F26921AE255 for ; Sat, 23 Nov 2013 01:44:28 -0800 (PST)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0MEX0j-1VqyJH21U1-00FYpa; Sat, 23 Nov 2013 04:44:21 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=windows-1252
From: Alper Yegin 
In-Reply-To: <528F443D.9060302@gmail.com>
Date: Sat, 23 Nov 2013 01:13:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <528F443D.9060302@gmail.com>
To: Alexandru Petrescu 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:otaUr4x8v5TxkzAec2APzgzngk/KTQrRIhR6UKkCsUq L4iNbS52E9yYZrKwoWIoxxCnVTY4VziOz1fiGTHGOH9M2ynb+u xQbuNhMYIbn9v6gKPdCes1rA665Y6eegBQEv4urOv/cZxkWW1g /ufqHY9adgjQoT2ouPMuBm+rpnvOkwVpfOW5lGe6DgIpZVnfF1 zmlEuivbEy2aVVo4RdKPfM1nbpcplHLN/x2GoSkbTuyxOZz3De kte7ODEEOjMIlq3MrFufdA5FyFxWd/jPFuYFx3fzKivD93erCb eQCu7Hax0ZNzFYml7ClPJcI/7PHgEX0iEuqInD1JkAPe3ySOzU OAHmoxvZEkCD6uiCUqq+GcJHT5HEgJ4m4vYj1Bs4cSYnsCU1qR SRUYbMycsrjVA==
Cc: dmm 
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 23 Nov 2013 09:44:31 -0000

Hi Alex,

On Nov 22, 2013, at 1:47 PM, Alexandru Petrescu wrote:

> Hello Alper,
>=20
> In this discussion, I may be missing the 'Mobile Router vs Host' =
dimension.
>=20
> We would use host-based routes if we need Mobile Hosts, but we'd use =
prefix-based routes if we needed Mobile Routers.
>=20
> The route convergence speed and domain size scalability aspects apply =
differently.
>=20


You are right, we should also account for the mobile router. But I think =
spreading a specific route for a single host address and doing the same =
for a single prefix are pretty much the same (in terms of =
scalability/performance metrics).


> Additionally, I would shape the question from the other point of view =
as well: is it reasonable for PMIP solution to use tunnels even if the =
mobile stays within the same domain?
>=20

It depends on the solution specifics. We cannot say "shall not use =
tunnels in that case". But if some solution achieves not using tunnels =
(assuming w/o doing some funky business), then it sounds attractive. We =
can look at the details.

Alper


> Alex
>=20
> Le 22/11/2013 12:12, Alper Yegin a =E9crit :
>> Hello folks,
>>=20
>> Using tunnels vs. propagating host routes across a domain=85
>>=20
>> The former is proven to work. The latter appears to have attractive =
attributes (e.g., absence of tunneling overhead, fully distributed =
nature, etc.), but there are also aspects that need to be addressed, =
such as:
>> - Can it scale (passing host-routes for millions of nodes even in =
single operator network)?
>> - Can it converge fast enough for seamless handovers?
>> - Is it practical from charging, lawful intercept, DPI, policy =
enforcement point of view?
>> - How do we deal with the case when the MN moves outside the domain? =
(probably we need to fall back to using a tunnel-based solution)
>>=20
>> The host-route-based schemes need to overcome these challenges to =
appear as an alternative to tunnel-based solutions. I'm hoping the =
proponents of those scheme will show us how they handle these issues.
>>=20
>> Maybe it'll turn out that under certain conditions host-route-based =
solutions work just fine (Pete was pointing at local mobility). If so, =
we can recognize that and tell people they can use such solutions =
instead of tunnel-based solutions, where applicable.
>>=20
>> For example: If the anchor is within an operator network it can be =
used (which can substitute for tunnel-based anchoring on a central HA =
and also on previous AR -- but not for anchoring near the corresponding =
network which works across the Internet).
>>=20
>> ...
>>=20
>> But note that, that discussion is just about  one component of DMM =
solution set. There are other components, which are not impacted by that =
discussion. Such as:
>> - The MN stack treating flows differently with respect to their =
mobility needs (assigning different types [colors/anchor type, etc] of =
IP addresses)
>> - The MN stack choosing anchors (i.e., selecting a specific anchor =
node based in the anchor type selection).
>>=20
>> =85
>>=20
>> And whenever a component involves DP/CP, we should recognize that =
they are separable and take that into account.
>>=20
>>=20
>> Alper
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>=20
>>=20
>=20
>=20


From alper.yegin@yegin.org  Sat Nov 23 04:20:58 2013
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 A76D81AE04A for ; Sat, 23 Nov 2013 04:20:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.998
X-Spam-Level: *
X-Spam-Status: No, score=1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, 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 K8vmN56LJf0H for ; Sat, 23 Nov 2013 04:20:57 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9F71AD7C5 for ; Sat, 23 Nov 2013 04:20:57 -0800 (PST)
Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LeNRl-1VIq0H2CAn-00qmmT; Sat, 23 Nov 2013 07:20:48 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Alper Yegin 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE7182E2235@dfweml510-mbx.china.huawei.com>
Date: Sat, 23 Nov 2013 14:20:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5963DDF1F751474D8DEEFDCDBEE43AE7182E2235@dfweml510-mbx.china.huawei.com>
To: Peter McCann 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:pDxTP/cNTg4vKjMW2LGKU3iu7uVb8dudJSmlIjJpmxQ 5+GcrSL4ko2UlCjEbnLWYtw7rlPdoxu3h9a6K5vEXmFumCTKvk rU9abLburiLNEPJTmI8DnKyIU9xCNZ2XCPEQ4n6go3lI95QxNh l76fB5MnTmZsThUSNcMz9wRK8pT8KyiTo7oX0iDDKImtKoye3o IVbrYk9LnrMTKoZeHjZruuC6tu6wLKqfjJ22e/10y4eyJayvII fehtWQRWVDIx/pNMlQKPDffhIASnULnJF5LoaqPa7DnX0/RLwE FcxccF4biYrUMwR319P4Bi89SeVmgurfsbzfiJ6sigzVSQXkwj bhjS0pHzyGivkpBI7D6c/Vjx2D+nOhHqgfGISJb8fuz0B0ESTA cfsMCyuStTjbQ==
Cc: dmm 
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 23 Nov 2013 12:20:58 -0000

Hi Pete,

> All good questions.  Some comments below.
>=20
> Alper Yegin wrote:
>> Hello folks,
>>=20
>> Using tunnels vs. propagating host routes across a domain...
>>=20
>> The former is proven to work. The latter appears to have attractive
>> attributes (e.g., absence of tunneling overhead, fully distributed
>> nature, etc.), but there are also aspects that need to be addressed,
>> such as:
>> - Can it scale (passing host-routes for millions of nodes even in
>> single operator network)?
>=20
> I think a better way to put this question is "over what scope does it
> scale?"  Clearly it should work fine over a limited scope such as the
> region spanned by one pool of route reflectors.  In some deployment=20
> cases (such as when the MN is able to release an old address fairly=20
> quickly) this may be enough.

I presume you are talking about even a subset of an operator network.=20
Sure, OK, whatever it is if we can get some description of it, that'd =
help us understand the applicability of these approaches.


>=20
>> - Can it converge fast enough for seamless handovers?
>=20
> I see no reason why it can't be just as fast as a tunnel setup, if not
> moreso.  You just need to propagate an UPDATE message as far as the
> crossover router, and install a route into the FIB.  There is no good
> reason why this would take more time than installing a tunnel state.
> Some BGP implementations may need to be tuned for proper performance.
>=20

We know BGP is not designed for handling many rapid changes (after all =
non-mobile prefixes are much more stable compared to a moving MN).
But of source that does not necessarily mean BGP cannot handle it.
I'm not a BGP expert to confirm. It may be worth running this by the =
routing related WGs and collect some feedback.


>> - Is it practical from charging, lawful intercept, DPI, policy
>> enforcement point of view?
>=20
> We shouldn't sacrifice fault tolerance and optimal routing on the
> altar of these "features".  They won't be needed in every deployment,
> and when they are needed, we can find ways to implement them without
> forcing the traffic to a central location in an unscalable and
> fault-intolerant way.
>=20

Sounds good. We just need to see the details.

I'm not claiming any of these points are show-stoppers. But these are =
points that need to be addressed in order for people to feel confident =
about this alternative.
After all, this whole tunneling-based MIP business was created at the =
beginning because we couldn't propagate host routes across the Internet.
Now if we are going to go back to host routes, then we need to =
understand what changed since then or what we missed at the time and =
decided to go down the tunneling path.


>> - How do we deal with the case when the MN moves outside the domain?
>> (probably we need to fall back to using a tunnel-based solution)
>=20
> Yes, and I think that should be a client-based tunnel to handle the
> likely situation where there is no relationship between the old and
> new domains other than the fact that they are both connected to the
> Internet.
>=20

This sounds plausible too. It'd be good to see the details.

>> The host-route-based schemes need to overcome these challenges to
>> appear as an alternative to tunnel-based solutions. I'm hoping the
>> proponents of those scheme will show us how they handle these issues.
>=20
> Agree further study is needed.
>=20
>> Maybe it'll turn out that under certain conditions host-route-based
>> solutions work just fine (Pete was pointing at local mobility). If =
so,
>> we can recognize that and tell people they can use such solutions
>> instead of tunnel-based solutions, where applicable.
>=20
> Yes.
>=20
>> For example: If the anchor is within an operator network it can be
>> used (which can substitute for tunnel-based anchoring on a central HA
>> and also on previous AR -- but not for anchoring near the
>> corresponding network which works across the Internet).
>=20
> True but anchoring at a CN requires cross-domain coordination for the
> network-based mobility management case.
>=20

Can you elaborate on that?

>>=20
>> ...
>>=20
>> But note that, that discussion is just about  one component of DMM
>> solution set. There are other components, which are not impacted by
>> that discussion. Such as:
>> - The MN stack treating flows differently with respect to their
>> mobility needs (assigning different types [colors/anchor type, etc] =
of
>> IP addresses)
>=20
> Yes we still need to have that discussion.  This can be worked out=20
> independently of the mechanism used by the network-based mobility
> scheme.
>=20
>> - The MN stack choosing anchors (i.e., selecting a specific anchor
>> node based in the anchor type selection).
>=20
> Yes the software in the MN still needs to handle multiple simultaneous
> addresses, choosing among them, and managing their lifecycles.  The=20
> important feature of DMM is to enable a decoupling between the =
mobility
> events and the address lifecycle, so that addresses can be maintained
> for some time after a mobility event and new ones can be allocated =
when
> it makes sense to do so (not forced at the time of mobility).
>=20
>> ...
>>=20
>> And whenever a component involves DP/CP, we should recognize that =
they
>> are separable and take that into account.
>=20
> Agree but with the caveat that DMM is not the right place to =
standardized
> CP/DP interface protocols.
>=20

Yes.

Cheers,

Alper



> -Pete
>=20
>> Alper
>=20


From jouni.nospam@gmail.com  Mon Nov 25 01:18:26 2013
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 A470A1ACCEA for ; Mon, 25 Nov 2013 01:18:26 -0800 (PST)
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 uJFlp-GEioNm for ; Mon, 25 Nov 2013 01:18:24 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 55B681ACCDA for ; Mon, 25 Nov 2013 01:18:24 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id z5so2918169lbh.17 for ; Mon, 25 Nov 2013 01:18:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=QhopTASxNANooLjwe7VOo8fM7C0waCSOyQB8pf7jtio=; b=c51m3x4R8gUM+TV7hVWu29NLNc7XuCVV3KNss1UIcW0KG4o8BedpUhkHClm6QKKBc1 Nq52m0QGxOJl8LEbXPCOoYHSXO1A3mijLszuqfFwhnO+1ve9/b7Z0L2jfDU+XImFCV5u HdjEU7uugrctf9m+nDkdMDl4Hzgq8b3fxev+rm3BdtcwOJ7zPTcQyahAFehoEayXDDoA zNV3pKcYcHkC0RMimaZIvS7ua8ioqymane0G1F+gVIAZ/fPDaMFL+OzLEodaljv480Oz OJPKNuq6fDqF8s9B0WvlxsrnQFKQedLjXRO/PE6Jf6ex3zgT6Kkngb7iawYnAEw7Ly1i xH0A==
X-Received: by 10.112.189.202 with SMTP id gk10mr15701601lbc.11.1385371103973;  Mon, 25 Nov 2013 01:18:23 -0800 (PST)
Received: from [192.168.250.65] ([194.100.71.98]) by mx.google.com with ESMTPSA id c10sm34034600lbd.9.2013.11.25.01.18.23 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Nov 2013 01:18:23 -0800 (PST)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Mon, 25 Nov 2013 11:18:23 +0200
Message-Id: 
To: dmm 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Cc: Dapeng Liu , Peter McCann 
Subject: [DMM] Quick WGLC for draft-ietf-dmm-requirements-11
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, 25 Nov 2013 09:18:26 -0000

Folks,

This mail starts a quick one week WGLC for 
draft-ietf-dmm-requirements-11 to verify the
changes done since the last WGLC. After the
WGLC we are about to move the draft out of the
working group.

The WGLC ends 2-Dec-2013.

If you have something comment, send it into the
mailing list and possibly add into the issue 
tracker. We take silence as an acceptance for the
draft content. 

- Jouni & Dapeng

From Peter.McCann@huawei.com  Mon Nov 25 06:40:42 2013
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 B320B1ADE8A for ; Mon, 25 Nov 2013 06:40:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.303
X-Spam-Level: 
X-Spam-Status: No, score=-0.303 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 xMwQ287IUKaH for ; Mon, 25 Nov 2013 06:40:40 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A12FC1ADEA0 for ; Mon, 25 Nov 2013 06:40:39 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYH39196; Mon, 25 Nov 2013 14:40:38 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 14:40:12 +0000
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 14:40:37 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 06:40:27 -0800
From: Peter McCann 
To: Alper Yegin 
Thread-Topic: [DMM] tunnels-vs-host routes and other DMM components
Thread-Index: AQHO56MqLSJ+psE0Xk2phtDza+B7KJozQ7GAgALDNxA=
Date: Mon, 25 Nov 2013 14:40:26 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7182E253C@dfweml510-mbx.china.huawei.com>
References:   <5963DDF1F751474D8DEEFDCDBEE43AE7182E2235@dfweml510-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.125.89]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: dmm 
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 25 Nov 2013 14:40:42 -0000

Hi, Alper,

Alper Yegin wrote:
> Hi Pete,
>=20
>> All good questions.  Some comments below.
>>=20
>> Alper Yegin wrote:
>>> Hello folks,
>>>=20
>>> Using tunnels vs. propagating host routes across a domain...
>>>=20
>>> The former is proven to work. The latter appears to have attractive
>>> attributes (e.g., absence of tunneling overhead, fully distributed
>>> nature, etc.), but there are also aspects that need to be
>>> addressed, such as:
>>> - Can it scale (passing host-routes for millions of nodes even in
>>> single operator network)?
>>=20
>> I think a better way to put this question is "over what scope does
>> it scale?"  Clearly it should work fine over a limited scope such as
>> the region spanned by one pool of route reflectors.  In some
>> deployment cases (such as when the MN is able to release an old
>> address fairly
>> quickly) this may be enough.
>=20
> I presume you are talking about even a subset of an operator network.
> Sure, OK, whatever it is if we can get some description of it, that'd
> help us understand the applicability of these approaches.

Agreed.

>>> - Can it converge fast enough for seamless handovers?
>>=20
>> I see no reason why it can't be just as fast as a tunnel setup, if not
>> moreso.  You just need to propagate an UPDATE message as far as the
>> crossover router, and install a route into the FIB.  There is no good
>> reason why this would take more time than installing a tunnel state.
>> Some BGP implementations may need to be tuned for proper performance.
>>=20
>=20
> We know BGP is not designed for handling many rapid changes (after all
> non-mobile prefixes are much more stable compared to a moving MN).
> But of source that does not necessarily mean BGP cannot handle it.
> I'm not a BGP expert to confirm. It may be worth running this by the
> routing related WGs and collect some feedback.

There have been studies of the basic propagation time of an UPDATE
through a BGP router.  It can be done in as little as 2.4ms if the
timers and batching are configured properly.

>>> - Is it practical from charging, lawful intercept, DPI, policy
>>> enforcement point of view?
>>=20
>> We shouldn't sacrifice fault tolerance and optimal routing on the
>> altar of these "features".  They won't be needed in every
>> deployment, and when they are needed, we can find ways to implement
>> them without forcing the traffic to a central location in an
>> unscalable and fault-intolerant way.
>>=20
>=20
> Sounds good. We just need to see the details.
>=20
> I'm not claiming any of these points are show-stoppers. But these are
> points that need to be addressed in order for people to feel confident
> about this alternative. After all, this whole tunneling-based MIP
> business was created at the beginning because we couldn't propagate host
> routes across the Internet. Now if we are going to go back to host
> routes, then we need to understand what changed since then or what we
> missed at the time and decided to go down the tunneling path.

We will still need (client-based) tunnels across the Internet.  We are
just trying to buy a little time for the old address (and the current
CoA) so we don't have to have over-the-air tunnel signaling on every=20
change of base station.

>>> - How do we deal with the case when the MN moves outside the domain?
>>> (probably we need to fall back to using a tunnel-based solution)
>>=20
>> Yes, and I think that should be a client-based tunnel to handle the
>> likely situation where there is no relationship between the old and
>> new domains other than the fact that they are both connected to the
>> Internet.
>>=20
>=20
> This sounds plausible too. It'd be good to see the details.

I think we will need some new mechanisms to enable quick establishment
of a security association with a local HA at the time a local address
is assigned.  I don't want to require RADIUS round-trips (ugh).  Other
than that this is standard MIP.

>>> The host-route-based schemes need to overcome these challenges to
>>> appear as an alternative to tunnel-based solutions. I'm hoping the
>>> proponents of those scheme will show us how they handle these
> issues.
>>=20
>> Agree further study is needed.
>>=20
>>> Maybe it'll turn out that under certain conditions host-route-based
>>> solutions work just fine (Pete was pointing at local mobility). If so,
>>> we can recognize that and tell people they can use such solutions
>>> instead of tunnel-based solutions, where applicable.
>>=20
>> Yes.
>>=20
>>> For example: If the anchor is within an operator network it can be
>>> used (which can substitute for tunnel-based anchoring on a central HA
>>> and also on previous AR -- but not for anchoring near the
>>> corresponding network which works across the Internet).
>>=20
>> True but anchoring at a CN requires cross-domain coordination for
>> the network-based mobility management case.
>>=20
>=20
> Can you elaborate on that?

Maybe you didn't propose this, but a network-controlled CN-based anchor
would imply some kind of relationship between the visited and correspondent
networks.

>>> But note that, that discussion is just about  one component of DMM
>>> solution set. There are other components, which are not impacted by
>>> that discussion. Such as:
>>> - The MN stack treating flows differently with respect to their
>>> mobility needs (assigning different types [colors/anchor type, etc]
>>> of IP addresses)
>>=20
>> Yes we still need to have that discussion.  This can be worked out
>> independently of the mechanism used by the network-based mobility
>> scheme.
>>=20
>>> - The MN stack choosing anchors (i.e., selecting a specific anchor
>>> node based in the anchor type selection).
>>=20
>> Yes the software in the MN still needs to handle multiple simultaneous
>> addresses, choosing among them, and managing their lifecycles.  The
>> important feature of DMM is to enable a decoupling between the mobility
>> events and the address lifecycle, so that addresses can be maintained
>> for some time after a mobility event and new ones can be allocated when
>> it makes sense to do so (not forced at the time of mobility).
>>=20
>>> ...
>>>=20
>>> And whenever a component involves DP/CP, we should recognize that
>>> they are separable and take that into account.
>>=20
>> Agree but with the caveat that DMM is not the right place to
>> standardized CP/DP interface protocols.
>>=20
>=20
> Yes.
>=20
> Cheers,
>=20
> Alper

-Pete


From alper.yegin@yegin.org  Mon Nov 25 07:44:42 2013
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 44AD91ADF5C for ; Mon, 25 Nov 2013 07:44:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.998
X-Spam-Level: *
X-Spam-Status: No, score=1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FB_CIALIS_LEO3=3.899, 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 aefDyZ5YTuwz for ; Mon, 25 Nov 2013 07:44:40 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 308E71ADF57 for ; Mon, 25 Nov 2013 07:44:40 -0800 (PST)
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 0Mgbbr-1VyMqk2QSt-00Npx2; Mon, 25 Nov 2013 10:44:29 -0500
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Alper Yegin 
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE7182E253C@dfweml510-mbx.china.huawei.com>
Date: Mon, 25 Nov 2013 17:44:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <5963DDF1F751474D8DEEFDCDBEE43AE7182E2235@dfweml510-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE7182E253C@dfweml510-mbx.china.huawei.com>
To: Peter McCann 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:tFbk/gdrh7oh4NxayROi2g6sSI6Tio/vPg7/fFF6Qg5 NxUoj5sdNSc3XmU0qnHgzZbkFEP5c9hDQzaICtTo93TMdm/8xT 9bdsLtqNFW+1Y/vsGoyKYgQMYP3OAGdfA5YjYb/iwnBR9KSqHp yMx3HVOxEPuGTA6YS+/NinvX3FPBAZDo3UjdWEPRkfOBFhnzVr aHsSXJj5aCvtlpuISHM8Urzi4EFWAbF63Ks4iBEzh41XoWCc/w 3G6F+8MNXKQh0YfyOPN/x+zT0FRJbqxKmePVoSmGFyb1ecTD23 fbBIWi2jv3yZAZDrBsTP1X8yxDYWxu95JEvcxlPUVXe95wtAB+ OYG+/fSmKAcvWC0aOl5nNfk1Wn8rStrBxX0uTyAotCgACsgxHV 4iLS32Ix47Nrg==
Cc: dmm 
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 25 Nov 2013 15:44:42 -0000

Hi Pete,

>>>> Using tunnels vs. propagating host routes across a domain...
>>>>=20
>>>> The former is proven to work. The latter appears to have attractive
>>>> attributes (e.g., absence of tunneling overhead, fully distributed
>>>> nature, etc.), but there are also aspects that need to be
>>>> addressed, such as:
>>>> - Can it scale (passing host-routes for millions of nodes even in
>>>> single operator network)?
>>>=20
>>> I think a better way to put this question is "over what scope does
>>> it scale?"  Clearly it should work fine over a limited scope such as
>>> the region spanned by one pool of route reflectors.  In some
>>> deployment cases (such as when the MN is able to release an old
>>> address fairly
>>> quickly) this may be enough.
>>=20
>> I presume you are talking about even a subset of an operator network.
>> Sure, OK, whatever it is if we can get some description of it, that'd
>> help us understand the applicability of these approaches.
>=20
> Agreed.
>=20
>>>> - Can it converge fast enough for seamless handovers?
>>>=20
>>> I see no reason why it can't be just as fast as a tunnel setup, if =
not
>>> moreso.  You just need to propagate an UPDATE message as far as the
>>> crossover router, and install a route into the FIB.  There is no =
good
>>> reason why this would take more time than installing a tunnel state.
>>> Some BGP implementations may need to be tuned for proper =
performance.
>>>=20
>>=20
>> We know BGP is not designed for handling many rapid changes (after =
all
>> non-mobile prefixes are much more stable compared to a moving MN).
>> But of source that does not necessarily mean BGP cannot handle it.
>> I'm not a BGP expert to confirm. It may be worth running this by the
>> routing related WGs and collect some feedback.
>=20
> There have been studies of the basic propagation time of an UPDATE
> through a BGP router.  It can be done in as little as 2.4ms if the
> timers and batching are configured properly.
>=20

A reference would be good.

>>>> - Is it practical from charging, lawful intercept, DPI, policy
>>>> enforcement point of view?
>>>=20
>>> We shouldn't sacrifice fault tolerance and optimal routing on the
>>> altar of these "features".  They won't be needed in every
>>> deployment, and when they are needed, we can find ways to implement
>>> them without forcing the traffic to a central location in an
>>> unscalable and fault-intolerant way.
>>>=20
>>=20
>> Sounds good. We just need to see the details.
>>=20
>> I'm not claiming any of these points are show-stoppers. But these are
>> points that need to be addressed in order for people to feel =
confident
>> about this alternative. After all, this whole tunneling-based MIP
>> business was created at the beginning because we couldn't propagate =
host
>> routes across the Internet. Now if we are going to go back to host
>> routes, then we need to understand what changed since then or what we
>> missed at the time and decided to go down the tunneling path.
>=20
> We will still need (client-based) tunnels across the Internet.  We are
> just trying to buy a little time for the old address (and the current
> CoA) so we don't have to have over-the-air tunnel signaling on every=20=

> change of base station.
>=20

OK, then this is positioning the solution to be a localized mobility =
solution
(not localized like "NETLMM" whose locality covered the whole Internet =
:-)
Your approach wedges in between the L2-based solutions and MIP-based =
solutions.



>>>> - How do we deal with the case when the MN moves outside the =
domain?
>>>> (probably we need to fall back to using a tunnel-based solution)
>>>=20
>>> Yes, and I think that should be a client-based tunnel to handle the
>>> likely situation where there is no relationship between the old and
>>> new domains other than the fact that they are both connected to the
>>> Internet.
>>>=20
>>=20
>> This sounds plausible too. It'd be good to see the details.
>=20
> I think we will need some new mechanisms to enable quick establishment
> of a security association with a local HA at the time a local address
> is assigned.  I don't want to require RADIUS round-trips (ugh).  Other
> than that this is standard MIP.
>=20
>>>> The host-route-based schemes need to overcome these challenges to
>>>> appear as an alternative to tunnel-based solutions. I'm hoping the
>>>> proponents of those scheme will show us how they handle these
>> issues.
>>>=20
>>> Agree further study is needed.
>>>=20
>>>> Maybe it'll turn out that under certain conditions host-route-based
>>>> solutions work just fine (Pete was pointing at local mobility). If =
so,
>>>> we can recognize that and tell people they can use such solutions
>>>> instead of tunnel-based solutions, where applicable.
>>>=20
>>> Yes.
>>>=20
>>>> For example: If the anchor is within an operator network it can be
>>>> used (which can substitute for tunnel-based anchoring on a central =
HA
>>>> and also on previous AR -- but not for anchoring near the
>>>> corresponding network which works across the Internet).
>>>=20
>>> True but anchoring at a CN requires cross-domain coordination for
>>> the network-based mobility management case.
>>>=20
>>=20
>> Can you elaborate on that?
>=20
> Maybe you didn't propose this, but a network-controlled CN-based =
anchor
> would imply some kind of relationship between the visited and =
correspondent
> networks.


Our draft describes the MN-controlled case, hence CN and VN don't need =
to have a relationship.
We also left network-controlled case as TBD in the I-D, and that one is =
likely to require such a relationship.

Cheers,

Alper


>=20
>>>> But note that, that discussion is just about  one component of DMM
>>>> solution set. There are other components, which are not impacted by
>>>> that discussion. Such as:
>>>> - The MN stack treating flows differently with respect to their
>>>> mobility needs (assigning different types [colors/anchor type, etc]
>>>> of IP addresses)
>>>=20
>>> Yes we still need to have that discussion.  This can be worked out
>>> independently of the mechanism used by the network-based mobility
>>> scheme.
>>>=20
>>>> - The MN stack choosing anchors (i.e., selecting a specific anchor
>>>> node based in the anchor type selection).
>>>=20
>>> Yes the software in the MN still needs to handle multiple =
simultaneous
>>> addresses, choosing among them, and managing their lifecycles.  The
>>> important feature of DMM is to enable a decoupling between the =
mobility
>>> events and the address lifecycle, so that addresses can be =
maintained
>>> for some time after a mobility event and new ones can be allocated =
when
>>> it makes sense to do so (not forced at the time of mobility).
>>>=20
>>>> ...
>>>>=20
>>>> And whenever a component involves DP/CP, we should recognize that
>>>> they are separable and take that into account.
>>>=20
>>> Agree but with the caveat that DMM is not the right place to
>>> standardized CP/DP interface protocols.
>>>=20
>>=20
>> Yes.
>>=20
>> Cheers,
>>=20
>> Alper
>=20
> -Pete
>=20


From Peter.McCann@huawei.com  Mon Nov 25 07:48:12 2013
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 2A35C1ADF70 for ; Mon, 25 Nov 2013 07:48:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level: 
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 7R42JsCtRWMz for ; Mon, 25 Nov 2013 07:48:10 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 12C731ADF6C for ; Mon, 25 Nov 2013 07:48:09 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYH45087; Mon, 25 Nov 2013 15:48:09 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 15:47:44 +0000
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 25 Nov 2013 15:47:52 +0000
Received: from DFWEML510-MBX.china.huawei.com ([fe80::a55a:d832:7869:d6a6]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Mon, 25 Nov 2013 07:47:49 -0800
From: Peter McCann 
To: Alper Yegin 
Thread-Topic: [DMM] tunnels-vs-host routes and other DMM components
Thread-Index: AQHO56MqLSJ+psE0Xk2phtDza+B7KJozQ7GAgALDNxCAAJpeAP//ejfQ
Date: Mon, 25 Nov 2013 15:47:48 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7182E25B1@dfweml510-mbx.china.huawei.com>
References:   <5963DDF1F751474D8DEEFDCDBEE43AE7182E2235@dfweml510-mbx.china.huawei.com>  <5963DDF1F751474D8DEEFDCDBEE43AE7182E253C@dfweml510-mbx.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.193.125.89]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: dmm 
Subject: Re: [DMM] tunnels-vs-host routes and other DMM components
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, 25 Nov 2013 15:48:12 -0000

Hi, Alper,

Alper Yegin wrote:
>>> We know BGP is not designed for handling many rapid changes (after all
>>> non-mobile prefixes are much more stable compared to a moving MN). But
>>> of source that does not necessarily mean BGP cannot handle it. I'm not
>>> a BGP expert to confirm. It may be worth running this by the routing
>>> related WGs and collect some feedback.
>>=20
>> There have been studies of the basic propagation time of an UPDATE
>> through a BGP router.  It can be done in as little as 2.4ms if the
>> timers and batching are configured properly.
>>=20
>=20
> A reference would be good.

See, e.g., "Measuring BGP Pass-Through Times" by Feldman, Kong, Maennel, an=
d Tudor
http://www.net.t-labs.tu-berlin.de/papers/FKMT-MBPT-04.pdf

-Pete