- if new WG, t= here can be no milestones decided, but need to have some individual=C2=A0dr= afts submitted for discussions and for=C2=A0future adoption plans.=C2=A0

- if new WG, there should be in the charter related works/RFCs=C2= =A0in IETF that this WG will consider.=C2=A0

- if recharter WG, I= need to know its evaluation of previous charter(s), and why recharter?

- if recharter WG, I need to know clear milestones (dates of submiss= ions and date of conclude)=C2=A0and clear/stated=C2=A0adopted drafts and no= n adopted drafts that are under consideration.=C2=A0

- All=C2=A0W= G charters MUST have a date of conclude/recharter,=C2=A0otherwise we may wa= ste time/space/money in IETF.=C2=A0

- I prefer if the IETF=C2=A0c= harter has sections that are must and sections that are optional, so that w= e agree on how we review such charter. I think milestones are must for rech= arters and optional for new WG charter.=C2=A0

- I require for my = best=C2=A0review for=C2=A0recharter,=C2=A0a=C2=A0review AD evaluation secti= on for the WG's previous charter(s) and challenges.=C2=A0

Please note we need to take care with=C2=A0the charter=C2=A0det= ails, the=C2=A0WG-decisions=C2=A0and then recharter=C2=A0review. Therefore,= I object this WG to recharter until its WG=C2=A0decides the=C2=A0milestone= s and have clear work adoption plan related to drafts mentioned in the char= ter.=C2=A0

Regards,

On Friday, October 3, 2014, The IESG wrote:
The Distributed Mobility Management (dmm) workin= g group in the Internet
Area of the IETF is undergoing rechartering. The IESG has not made any
determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please = send your comments to

the IESG mailing list (iesg at ietf.org) by 2014-10-13.

Distributed Mobility Management (dmm)
------------------------------------------------
Current Status: Active WG

Chairs:
=C2=A0 Dapeng Liu <liudapeng@chinamobile.com>
=C2=A0 Jouni Korhonen <jouni.nospam@gmail.com&= gt;

Assigned Area Director:
=C2=A0 Brian Haberman <brian@innovationslab.net<= /a>>

Mailing list
=C2=A0 Address: dmm@ietf.org
=C2=A0 To Subscribe: https://www.ietf.org/mailman/listinfo/dmm
=C2=A0 Archive: http://www.ietf.org/mail-archive/web/dmm

Charter:

Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and
anywhere. The IETF Distributed Mobility Management (DMM) working group
(WG) specifies solutions for IP networks so that traffic between mobile
and correspondent nodes can take an optimal route. DMM solutions aim for transparency above the IP layer, including maintenance of active
transport level sessions when mobile hosts or mobile networks change
their point of attachment to the Internet.

Wireless network deployments have traditionally relied on hierarchical
schemes that often lead to centralized deployment models, where a small
number of mobility anchors manage both mobility and reachability for a
mobile node. The DMM WG will consider the latest developments in mobile
networking research and operational practice (i.e. flattening network
architectures, the impact of virtualization, new deployment needs as
wireless access technologies evolve in the coming years) and will
describe how distributed mobility management addresses the new needs in
this area better than previously standardized solutions.

A topic of particular focus will be mobility anchoring in this new
context, and the DMM working group is chartered to work on
maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC
5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new
approaches which capitalize on other protocols specified by the IETF.
For example, mobility management in a limited area, such as within an
autonomous system, is not strictly limited to mentioned IP mobility
protocols but can be any existing or a new protocol solution enabling
the movement of a mobile node such as routing protocols. When extending
protocols that are not based on Mobile IP, DMM solutions will have to be reviewed by the corresponding WGs.

IPv6 is assumed to be present in both the mobile host/router and the
access networks. DMM solutions are primarily targeted at IPv6
deployments and are not required to support IPv4, in particular for the
case where private IPv4 addresses and/or NATs are used. DMM solutions
must maintain backward compatibility:=C2=A0 If the network or the mobile host/router does not support the distributed mobility management
protocol that should not prevent the mobile host/router gaining basic
access (i.e., nomadic) to the network.

Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further,
mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized
networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment
models, e.g. in virtualized environments, are in-scope and encouraged.
Solutions may also specify the selection between the care-of addresses
and home address(es)/prefix(es) for different application use cases.

The working group will produce both informational architectural and
standards track protocol solutions on the following work item topics.

=C2=A0 =C2=A0 =C2=A0 o Distributed mobility management deployment models an= d scenarios:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 describe the target high-level network architec= tures and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 deployment models where distributed mobility ma= nagement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol solutions would apply.

=C2=A0 =C2=A0 =C2=A0 o Enhanced mobility anchoring: define protocol solutio= ns for a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 gateway and mobility anchor assignment and mid-= session mobility
=C2=A0 =C2=A0 =C2=A0 =C2=A0 anchor switching that go beyond what has been s= pecified, for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 example, in RFC 6097, 6463, and 5142. Traffic s= teering
=C2=A0 =C2=A0 =C2=A0 =C2=A0 associated with the anchor switch is also in-sc= ope if deemed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 appropriate.

=C2=A0 =C2=A0 =C2=A0 o Forwarding path and signaling management: the functi= on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 that handles mobility management signaling inte= racts with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 DMM network elements for managing the forwardin= g state
=C2=A0 =C2=A0 =C2=A0 =C2=A0 associated with a mobile node's IP traffic.= =C2=A0 These two functions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 may or may not be collocated. Furthermore, the = forwarding state
=C2=A0 =C2=A0 =C2=A0 =C2=A0 may also be distributed into multiple network e= lements instead
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of a single network element (e.g., anchor).=C2= =A0 Protocol extensions
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or new protocols will be specified to allow the= above mentioned
=C2=A0 =C2=A0 =C2=A0 =C2=A0 forwarding path and signalling management.

=C2=A0 =C2=A0 =C2=A0 o Exposing mobility state to mobile nodes and network = nodes:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 define solutions that allow, for example, mobil= e nodes to select
=C2=A0 =C2=A0 =C2=A0 =C2=A0 either a care-of address or a home address depe= nding on an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 application' mobility needs. In order to en= able this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 functionality, the network-side control functio= ns and other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 networking nodes must also be able to exchange = appropriate
=C2=A0 =C2=A0 =C2=A0 =C2=A0 control information, as well as to the mobile n= odes and their
=C2=A0 =C2=A0 =C2=A0 =C2=A0 applications.

The working group may decide to extend the current milestones based on
the new information and knowledge gained during working on other
documents listed in the initial milestones. Possible new documents and
milestones must still fit into the overall DMM charter scope as outlined above.

Milestones:

--20cf301b67d960703c0504cec5f9-- From nobody Tue Oct 7 00:31:16 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121AB1A9139 for ; Tue, 7 Oct 2014 00:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4V9hqohYWCPZ for ; Tue, 7 Oct 2014 00:31:12 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B93891A6FCB for ; Tue, 7 Oct 2014 00:31:12 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id t59so2754698yho.1 for ; Tue, 07 Oct 2014 00:31:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KS7jyNq3gHQMAIlcXhpU5qVGHzMnwRrMtuPLWDwm5fM=; b=LltNmiEumVEqZmuA/kUTZorBYUy/X8i6nBls0C/UtjEeeXq+3Jr/tgBOUjH1XOcwIL uCqyH3jbojVdE4xherUY1IX+l2ZnVJ9fGHfxPhI50kB3dLNp0Brv0xefd2b+k2uQ7dyV 9awWjScwT7riVGJaMqxk8vbXANqzxTZ/wiaY7beYd5alwgISH5dYDBrURK1kjRIussFg HoMPlwaELQ0VazC3rvSHv7gRO3Vup2zMc/OuJPZ3wXZSh6jSXhwXuCxCfZubBOq4PzGx 6goae5t/+1Z4UIQGfppKUsihutj0bEyrNBP7CA/25BQXIiTuHDAfSB43b2iUjAIidwAF WZCw== MIME-Version: 1.0 X-Received: by 10.236.51.201 with SMTP id b49mr2980333yhc.33.1412667072093; Tue, 07 Oct 2014 00:31:12 -0700 (PDT) Received: by 10.170.54.198 with HTTP; Tue, 7 Oct 2014 00:31:11 -0700 (PDT) In-Reply-To: References: <5424FEFA.2050008@gmail.com> Date: Tue, 7 Oct 2014 16:31:11 +0900 Message-ID: From: Satoru Matsushima To: sarikaya@ieee.org Content-Type: multipart/alternative; boundary=089e013a1caa04a6110504d02f5b Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/80ZwrZXemf-E-jxQlUzcQyWRcZA Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] Going forward with the DMM work items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 07:31:15 -0000 --089e013a1caa04a6110504d02f5b Content-Type: text/plain; charset=UTF-8 Hi Behcet, On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya wrote: > > I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi > we proposed new approaches like SDN. > > Please don't get me wrong. My position hasn't been changed. BGP is used to forwarding path management signaling. In your draft, XMPP is the protocol that has same role of BGP. Good idea, it is a pub-sub system as same as BGP. You may need to define data model for dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs either xmpp, netconf, or forces. I suppose that you might want to adopt end-system VPN ( https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data modeling. (actually it is BGP. :-) And, as you may know that there is a draft which mentions about use case of BGP in i2rs. ( http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases) > Having said that I don't think that the charter text on forwarding > path and signaling is talking about the same thing. > > Interesting. What do you expect for the charter text? Why not you ask Marco, Anthony and Alper to explain their thought? > > In DMM fir WiFi we also adopted the anycast discovery, what is wrong with > that? > How do you find the anycast address itself? > > Yes I agree, maybe other techniques like AAA can be worked out. Why > not do it as extensions? > > I suppose that it would be a part of enhanced anchoring work, isn't it? > Really? My thinking was that vEPC does not need any involvement from > MN because the prefix assigned to MN does not change. > > As I mentioned in my more recent mail, I think this item is based on > 2102 solution proposals in which MN had to deal with many prefixes. > > Can you clarify which network nodes need exposure to MN mobility > state? The ones on the path already know MN prefix, right? > > Quite not. I meant disclosing mobility information to network node that likes such as BGP speaker. > So you are saying that these three items gave you some good ideas to > think about on how you can improve your solution, vEPC. > > In my view, the charter items work well to achieve vEPC architecture model, yes. More precisely, as the result of discussions which I had so far with many dmm people, I have noticed some parts which the draft needs more work to achieve the architecture model. > You are indicating that there is a major solution proposal, i.e. vEPC > by you, but that can be improved here and there. > > You are missing the point that such a view point is not yet agreed by the > group. > I know. So I am trying to express my thought, and then we can recognize differences each other, and we can discuss. It's normal process in the ietf I think. > > Without such an agreement on the base, isn't it quite concerning what > the WT's or DT's will do? > > My understanding is that the formation of WT's or DT's is another way > of saying that we don't like all those solutions out there, we will > design our own solutions to the above 3. > I guess wg management, who are responsible to establish dmm standard, expect standardizing dmm solution would be very hard work because they find many variants for it. In that situation, it would be reasonable that they appoint some persons to lead the work. I really appreciate those persons who volunteer to take that role to out consolidated solution. Cheers, --satoru --089e013a1caa04a6110504d02f5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Behcet,

On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya <s= arikaya2012@gmail.com> wrote:

I agree that BGP part in vEPC needs rethinking. That's why in DM= M WiFi
we proposed new approaches like SDN.

Please don't get me wrong. My posi= tion hasn't been changed. BGP is used to forwarding path management sig= naling.=C2=A0

In your draft, XMPP is the protocol = that has same role of BGP. Good idea, it is a pub-sub system as same as BGP= . You may need to define data model for dmm in i2rs, yang? I don't know= which protocol will be adopted as i2rs either xmpp, netconf, or forces.=C2= =A0

I suppose that you might want to adopt end-sys= tem VPN (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its= xml data modeling. (actually it is BGP. :-) And, as you may know that ther= e is a draft which mentions about use case of BGP in i2rs. (http://tools.ietf.= org/html/draft-keyupate-i2rs-bgp-usecases)

Having said that I don't think that the charter text on forwarding
path and signaling is talking about the same thing.

Interesting. W= hat do you expect for the charter text?

Why not you ask Marco, An= thony and Alper to explain their thought?

=C2=A0

In DMM fir WiFi we also adopted the anycast discovery, what is wrong= with that?

How do you find the anycast= address itself?

=C2=A0

Yes I agree, maybe other techniques like AAA can be worked out. Why
not do it as extensions?

I suppose that= it would be a part of enhanced anchoring work, isn't it?

=C2=A0

Really? My thinking was that vEPC = does not need any involvement from
MN because the prefix assigned to MN does not change.

As I mentioned in my more recent mail, I think this item is based on
2102 solution proposals in which MN had to deal with many prefixes.

Can you clarify which network nodes need exposure to MN mobility
state? The ones on the path already know MN prefix, right?

Quite not. I m= eant disclosing mobility information to network node that likes such as BGP= speaker.

=C2=A0

So you are = saying that these three items gave you some good ideas to
think about on how you can improve your solution, vEPC.

In my view, the charter items work wel= l to achieve vEPC architecture model, yes.

More precisely, as= the result of discussions which I had so far with many dmm people, I have = noticed some parts which the draft needs more work to achieve the architect= ure model.=C2=A0

=C2=A0

You are indicating that there is a major solution proposal, i.e. vEPC
by you, but that can be improved here and there.

You are missing the point that such a view point is not yet agreed by the g= roup.

I know. So I am trying to express= my thought, and then we can recognize differences each other, and we can d= iscuss. It's normal process in the ietf I think.

=C2=A0

Without such an agreement on the base, isn't it quite concerning what the WT's or DT's will do?

My understanding is that the formation of WT's or DT's is another w= ay
of saying that we don't like all those solutions out there, we will
design our own solutions to the above 3.

I guess wg management, who are responsible to establish dmm standard, exp= ect standardizing dmm solution would be very hard work because they find ma= ny variants for it. In that situation, it would be reasonable that they app= oint some persons to lead the work. I really appreciate those persons who v= olunteer to take that role to out consolidated solution.

Cheers,

--satoru

--089e013a1caa04a6110504d02f5b-- From nobody Tue Oct 7 02:13:39 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEABE1A9233; Tue, 7 Oct 2014 02:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.486 X-Spam-Level: X-Spam-Status: No, score=-0.486 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, URIBL_RHS_DOB=1.514] 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 bVeuvAzIw2aH; Tue, 7 Oct 2014 02:13:34 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB241A9176; Tue, 7 Oct 2014 02:13:33 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so5699151lbi.22 for ; Tue, 07 Oct 2014 02:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=A6QcA4glPy83J6B/U7kz0FhI7NmpFf22bvox0RPltnc=; b=VALJG+rrxC25aLi+Gm1EmLvS/UibVl5gQH5gCGn/7kJovaxzWrXJkU9iC4deCo8v+i cfoXw1rx6MU/AkwVJa3GwnGTHeqH9qr61cnChiPG3yQ2p2syNfWfER6If7cwL3lmjkej k1Y7R/yYV0FcCI2Sazi7adc5UX1Knc/iVjpZnrzQ28qi0zxEWm6/6+XZCUZtzFJHGdZU wWFP/tH8o//WK31HRXFJjYvyyH8ZJ1NzRs6yN3QPYVpAPBQbzxTYsSIvhy0zEhwixAJT TNUwQZXlsaLPwutYmVJuRsWfdPQkBUxUXMKCF5mH9vTJmYBN5O00VL1qqt7QMkTz5A5u 4Kbg== X-Received: by 10.152.29.100 with SMTP id j4mr2620272lah.47.1412673212045; Tue, 07 Oct 2014 02:13:32 -0700 (PDT) Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPSA id us3sm6514769lbc.24.2014.10.07.02.13.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 02:13:31 -0700 (PDT) Message-ID: <5433AEC0.6000104@gmail.com> Date: Tue, 07 Oct 2014 12:13:36 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Abdussalam Baryun , "ietf@ietf.org" References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Kt3vhJaNnJHANLFTTNBqyJ3xeRc Cc: "iesg@ietf.org" , dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:13:37 -0000 Hi, Thank you for the review. See my initial comments inline. 10/7/2014 8:50 AM, Abdussalam Baryun kirjoitti: > Dear IESG, > > I received you message request for review, but there are some issues > missing for my review. For example there is no milestones presented even > though the submitted charter states below > > "The working group may decide to extend the current milestones based on > the new information and knowledge gained during working on other > documents listed in the initial milestones. " When we submitted the re-charter text we were given an advice to leave them out - for some reason. Anyway, these were the milestones at the time of finishing the text in the WG: Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group document. To be Proposed Standard. Feb 2015 - Submit 'Forwarding path and signaling management' as a working group document. To be Proposed Standard. May 2015 - Submit 'Exposing mobility state to mobile nodes and network nodes' as a working group document(s). To be Proposed Standard. Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. To be Proposed Standard. Nov 2015 - Submit 'Forwarding path and signaling management' submitted to the IESG. To be Proposed Standard. Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' submitted to the IESG. To be Proposed Standard. They are probably as of now, too aggressive time wise. > Where are the initial milestone, the above statement refers to? did this > WG decide on the milestones or not? When I review the WG production > there is only one RFC and one adopted draft, while previous charters WG has completed its work on the previous charter items. The last I-D is already past IETF LC and hopefully entering IESG telechat agenda any time soon. > were aiming for more drafts. In first charter dated 2007 there were > about three work items/drafts suggested without milestones which is ok > because it is new but what happened? I want to know why we did not > achieve that? an input from the AD can help. See above. - JOuni > > Creating/Rechartering WGs while not having clear milestones will cost > IETF. I need to see in your review request of charter/recharter the > following so that I can make better review: > > - if new WG, there can be no milestones decided, but need to have some > individual drafts submitted for discussions and for future adoption plans. > - if new WG, there should be in the charter related works/RFCs in IETF > that this WG will consider. > - if recharter WG, I need to know its evaluation of previous charter(s), > and why recharter? > - if recharter WG, I need to know clear milestones (dates of submissions > and date of conclude) and clear/stated adopted drafts and non adopted > drafts that are under consideration. > - All WG charters MUST have a date of conclude/recharter, otherwise we > may waste time/space/money in IETF. > - I prefer if the IETF charter has sections that are must and sections > that are optional, so that we agree on how we review such charter. I > think milestones are must for recharters and optional for new WG charter. > - I require for my best review for recharter, a review AD evaluation > section for the WG's previous charter(s) and challenges. > > Please note we need to take care with the charter details, > the WG-decisions and then recharter review. Therefore, I object this WG > to recharter until its WG decides the milestones and have clear work > adoption plan related to drafts mentioned in the charter. > > Regards, > > AB > > On Friday, October 3, 2014, The IESG wrote: > > The Distributed Mobility Management (dmm) working group in the Internet > Area of the IETF is undergoing rechartering. The IESG has not made any > determination yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your comments to > the IESG mailing list (iesg at ietf.org ) by > 2014-10-13. > > Distributed Mobility Management (dmm) > ------------------------------------------------ > Current Status: Active WG > > Chairs: > Dapeng Liu > > Jouni Korhonen > > > Assigned Area Director: > Brian Haberman > > > Mailing list > Address: dmm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dmm > Archive: http://www.ietf.org/mail-archive/web/dmm > > Charter: > > Mobility management solutions lie at the center of the wireless Internet > and enable mobile devices to partake in IP networks anytime and > anywhere. The IETF Distributed Mobility Management (DMM) working group > (WG) specifies solutions for IP networks so that traffic between mobile > and correspondent nodes can take an optimal route. DMM solutions aim for > transparency above the IP layer, including maintenance of active > transport level sessions when mobile hosts or mobile networks change > their point of attachment to the Internet. > > Wireless network deployments have traditionally relied on hierarchical > schemes that often lead to centralized deployment models, where a small > number of mobility anchors manage both mobility and reachability for a > mobile node. The DMM WG will consider the latest developments in mobile > networking research and operational practice (i.e. flattening network > architectures, the impact of virtualization, new deployment needs as > wireless access technologies evolve in the coming years) and will > describe how distributed mobility management addresses the new needs in > this area better than previously standardized solutions. > > A topic of particular focus will be mobility anchoring in this new > context, and the DMM working group is chartered to work on > maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC > 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new > approaches which capitalize on other protocols specified by the IETF. > For example, mobility management in a limited area, such as within an > autonomous system, is not strictly limited to mentioned IP mobility > protocols but can be any existing or a new protocol solution enabling > the movement of a mobile node such as routing protocols. When extending > protocols that are not based on Mobile IP, DMM solutions will have to be > reviewed by the corresponding WGs. > > IPv6 is assumed to be present in both the mobile host/router and the > access networks. DMM solutions are primarily targeted at IPv6 > deployments and are not required to support IPv4, in particular for the > case where private IPv4 addresses and/or NATs are used. DMM solutions > must maintain backward compatibility: If the network or the mobile > host/router does not support the distributed mobility management > protocol that should not prevent the mobile host/router gaining basic > access (i.e., nomadic) to the network. > > Contrary to earlier IP mobility protocols, mobility management signaling > paths and end-user traffic forwarding paths may differ. Further, > mobility-related functions may be located in separate network nodes. DMM > solutions should not distinguish between physical or virtualized > networking functions. Whenever applicable, clarifications and additional > features/capabilities for specific networking function deployment > models, e.g. in virtualized environments, are in-scope and encouraged. > Solutions may also specify the selection between the care-of addresses > and home address(es)/prefix(es) for different application use cases. > > The working group will produce both informational architectural and > standards track protocol solutions on the following work item topics. > > o Distributed mobility management deployment models and > scenarios: > describe the target high-level network architectures and > deployment models where distributed mobility management > protocol solutions would apply. > > o Enhanced mobility anchoring: define protocol solutions for a > gateway and mobility anchor assignment and mid-session mobility > anchor switching that go beyond what has been specified, for > example, in RFC 6097, 6463, and 5142. Traffic steering > associated with the anchor switch is also in-scope if deemed > appropriate. > > o Forwarding path and signaling management: the function > that handles mobility management signaling interacts with the > DMM network elements for managing the forwarding state > associated with a mobile node's IP traffic. These two > functions > may or may not be collocated. Furthermore, the forwarding state > may also be distributed into multiple network elements instead > of a single network element (e.g., anchor). Protocol > extensions > or new protocols will be specified to allow the above mentioned > forwarding path and signalling management. > > o Exposing mobility state to mobile nodes and network nodes: > define solutions that allow, for example, mobile nodes to > select > either a care-of address or a home address depending on an > application' mobility needs. In order to enable this > functionality, the network-side control functions and other > networking nodes must also be able to exchange appropriate > control information, as well as to the mobile nodes and their > applications. > > The working group may decide to extend the current milestones based on > the new information and knowledge gained during working on other > documents listed in the initial milestones. Possible new documents and > milestones must still fit into the overall DMM charter scope as outlined > above. > > Milestones: > > From nobody Tue Oct 7 02:34:02 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4595D1ACCD8 for ; Tue, 7 Oct 2014 02:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.485 X-Spam-Level: X-Spam-Status: No, score=-0.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514] 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 nhQWfKuMKUVP for ; Tue, 7 Oct 2014 02:33:58 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848C01ACCDC for ; Tue, 7 Oct 2014 02:33:58 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id i57so2835210yha.0 for ; Tue, 07 Oct 2014 02:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7tPRTVRBw6FekVtgS4VzEC318NFWoJ+QeaXfdtGM2OY=; b=UCzlcYLUdqb8ok+lDryGePidW2pTFyf0WcL+dOzFdOmn4SHRUrTrUcoTml99Dg5Aj0 fDYzw6YSC7R11RRCd2NUAqrTXVMRE026qenrQBFiANKVn/e+NmlgDvGvg/76VL9b18GT KO1C/EaYnrNYSK70jDNcPPpjF4eUS0j7lAKYDe6hTJjnyHT5A4Bei8sVVE3TBW5PAUsW 8uijpkIykWdAtBbAOe0opQkXGi0tXaG/fgbrotokLTNW32oTcPase+v43jSOCveUrU/a r0eiMeuGBSHKaxTmLmee7uasawuy8Nf2kow9K0KSoEd/bo3FiNlQLpavwgC4mvUsIVDZ uH+A== MIME-Version: 1.0 X-Received: by 10.236.128.33 with SMTP id e21mr600333yhi.187.1412674437835; Tue, 07 Oct 2014 02:33:57 -0700 (PDT) Received: by 10.170.54.198 with HTTP; Tue, 7 Oct 2014 02:33:57 -0700 (PDT) In-Reply-To: <2134F8430051B64F815C691A62D9831832D381B3@XCH-BLV-504.nw.nos.boeing.com> References: <5424FEFA.2050008@gmail.com> <2134F8430051B64F815C691A62D9831832D381B3@XCH-BLV-504.nw.nos.boeing.com> Date: Tue, 7 Oct 2014 18:33:57 +0900 Message-ID: From: Satoru Matsushima To: "Templin, Fred L" Content-Type: multipart/alternative; boundary=20cf3011dacd0cef0c0504d1e6de Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/0BDdZL3KaNv5FKK-Xfo3oK0kYC0 Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] Going forward with the DMM work items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 09:34:00 -0000 --20cf3011dacd0cef0c0504d1e6de Content-Type: text/plain; charset=UTF-8 Hi Fred, On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L wrote: > Hi, > > > Maybe I can't attend next webex meeting tomorrow. > > That is too bad, because I will be briefing the AERO BGP routing system at > the meeting tomorrow. > > Yes, sorry to say. > I read your proposal, but have not received any indication if you have > read my AERO proposal yet. AERO uses > BGP in a way that was first specified by RFC6179 in 2011 and carried > forward into draft-templin-ironbis and > draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of > which AERO Client Prefixes (ACPs) > are associated with which AERO servers. But, only the Servers are exposed > to localized ACP mobility events; > the BGP is only updated when an ACP moves to a new Server. This means that > there will be very little churn > in the BGP routing system itself. So, the BGP is not directly exposed to > localized mobility events. > > I know you are the guy who invent ISATAP so I understand you may utilize same mechanism. You and me look big-believer of BGP ecosystem. In my draft, 3gpp defined mobility management is assumed to exist so the mobility management exports BGP mobility information into routing information. Do you assume 3gpp or ietf mobility management protocol/system in your draft as well? Anycast has been widely used in other router discovery solutions. Two cases are 6rd [RFC5969] > and 6to4 [RFC3068]. But, anycast has known operational problems in real > networks, and in fact > has caused major headaches for 6to4 - even to the point that its > deprecation is currently being > called for: > > http://www.ietf.org/mail-archive/web/ipv6/current/msg21248.html > http://www.ietf.org/mail-archive/web/ipv6/current/msg21268.html > > AERO Clients use DNS discovery to discover the address(es) of nearby > Server(s) as the default > means. Other solutions such as manual configuration, DHCP option, etc. are > also possible. > Yes, I know, there are many type of endpoint discovery. Do you clear any patent which claim the right of dns based endpoint discovery? > It would be nice if you were to review the AERO architecture and explain > to me the way in which > this requirement is or is not addressed already there. > Well, will do. I suppose today you provides explanation to extract aero into three work items. Thats works a lot for me to help reviewing the aero. Cheers, --satoru --20cf3011dacd0cef0c0504d1e6de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Fred,

On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L <Fred= .L.Templin@boeing.com> wrote:

Hi,

> Maybe I can't attend next webex meeting tomorrow.

That is too bad, because I will be briefing the AERO BGP routing sys= tem at the meeting tomorrow.

Yes, sorry to = say.

=C2=A0

I read your prop= osal, but have not received any indication if you have read my AERO proposa= l yet. AERO uses
BGP in a way that was first specified by RFC6179 in 2011 and carried forwar= d into draft-templin-ironbis and
draft-templin-aerolink. In AERO, BGP allows AERO Relays to=C2=A0 keep track= of which AERO Client Prefixes (ACPs)
are associated with which AERO servers. But, only the Servers are exposed t= o localized ACP mobility events;
the BGP is only updated when an ACP moves to a new Server. This means that = there will be very little churn
in the BGP routing system itself. So, the BGP is not directly exposed to lo= calized mobility events.

I know you are= the guy who invent ISATAP so I understand you may utilize same mechanism. = You and me look big-believer of BGP ecosystem. In my draft, 3gpp defined mo= bility management is assumed to exist so the mobility management exports BG= P mobility information into routing information. Do you assume 3gpp or ietf= mobility management protocol/system in your draft as well?

<= /div>

=C2=A0Anycast has been widely used in other router= discovery solutions. Two cases are 6rd [RFC5969]

and 6to4 [RFC3068]. But, anycast has known operational problems in real net= works, and in fact
has caused major headaches for 6to4 - even to the point that its deprecatio= n is currently being
called for:

http://www.ietf.org/mail-archive/web/ipv6/current/msg212= 48.html
http://www.ietf.org/mail-archive/web/ipv6/current/msg212= 68.html

AERO Clients use DNS discovery to discover the address(es) of nearby Server= (s) as the default
means. Other solutions such as manual configuration, DHCP option, etc. are = also possible.

Yes, I know, there are m= any type of endpoint discovery. Do you clear any patent which claim the rig= ht of dns based endpoint discovery?

=C2=A0

It would be nice if you were to review the AERO architecture and explai= n to me the way in which
this requirement is or is not addressed already there.=C2=A0

Well, will do. I suppose today you provides explanati= on to extract aero into three work items. Thats works a lot for me to help = reviewing the aero.

Cheers,
--satoru
=C2=A0

--20cf3011dacd0cef0c0504d1e6de-- From nobody Tue Oct 7 08:44:45 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32E1A6F0D for ; Tue, 7 Oct 2014 08:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qOODLZwMDD2 for ; Tue, 7 Oct 2014 08:44:40 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431D51A6FBF for ; Tue, 7 Oct 2014 08:44:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B85AA1081CD for ; Tue, 7 Oct 2014 17:44:38 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxN5WRO0QjZU for ; Tue, 7 Oct 2014 17:44:38 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 9AD9CFF84B for ; Tue, 7 Oct 2014 17:44:36 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.93]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Tue, 7 Oct 2014 17:44:37 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: work team call - Forwarding Path & Signaling Management Thread-Index: Ac/iRSbXjjpuvkA0Rkigh7y1imMVXg== Date: Tue, 7 Oct 2014 15:44:36 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91A919C3@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.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D91A919C3PALLENEofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/mIszaKcyU6JTzmJgdQ5hg2I6ptM Subject: [DMM] work team call - Forwarding Path & Signaling Management X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 15:44:43 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D91A919C3PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To progress the technical work item discussion about Forwarding Path and Si= gnaling Management, let's find a suitable date for a 90min WebEx call during next week. Please enter your availability in the following doodle by this week Thursda= y at the latest. http://doodle.com/mdiyzcgsafumqyfn Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26D91A919C3PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To progress the technical work item discussion about= Forwarding Path and Signaling Management,
let’s find a suitable date for a 90min WebEx call during next week.

Please enter your availability in the following dood= le by this week Thursday at the latest.

http://doodle.com/mdiyzcgsafumqyfn

Best regards,

marco

--_000_69756203DDDDE64E987BC4F70B71A26D91A919C3PALLENEofficehd_-- From nobody Tue Oct 7 09:22:59 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6618C1ACE0C for ; Tue, 7 Oct 2014 09:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 E8avUjkJ-Cbi for ; Tue, 7 Oct 2014 09:22:46 -0700 (PDT) Received: from stl-mbsout-01.boeing.com (stl-mbsout-01.boeing.com [130.76.96.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709041ACE11 for ; Tue, 7 Oct 2014 09:22:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s97GMjHW027408; Tue, 7 Oct 2014 11:22:45 -0500 Received: from XCH-BLV-502.nw.nos.boeing.com (xch-blv-502.nw.nos.boeing.com [130.247.25.191]) by stl-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s97GMe40027319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Oct 2014 11:22:40 -0500 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-502.nw.nos.boeing.com ([169.254.2.179]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 09:22:39 -0700 From: "Templin, Fred L" To: Satoru Matsushima Thread-Topic: [DMM] Going forward with the DMM work items Thread-Index: AQHP4RzGXpUh8f5HfEmf5Z5P6OIeg5wjL6XwgAGnHID///V2YA== Date: Tue, 7 Oct 2014 16:22:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D396B1@XCH-BLV-504.nw.nos.boeing.com> References: <5424FEFA.2050008@gmail.com> <2134F8430051B64F815C691A62D9831832D381B3@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/neERkty9ZV4ONd-X3em7hKV1p7Q Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] Going forward with the DMM work items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:22:55 -0000 SGkgU2F0b3J1LA0KDQo+PiBUaGF0IGlzIHRvbyBiYWQsIGJlY2F1c2UgSSB3aWxsIGJlIGJyaWVm aW5nIHRoZSBBRVJPIEJHUCByb3V0aW5nIHN5c3RlbSBhdCB0aGUgbWVldGluZyB0b21vcnJvdy4N Cj4NCj4gWWVzLCBzb3JyeSB0byBzYXkuDQoNCk9LLiBUaGUgdGFsayBnZW5lcmF0ZWQgcXVpdGUg YSBmZXcgcXVlc3Rpb25zLCBhbmQgd2FzIGZvbGxvd2VkIGJ5IGEgZGVtbyBvZiBlbXVsYXRlZA0K bmV0d29yayBub2RlcyBydW5uaW5nIEJHUCBhbmQgYWRkaW5nL3dpdGhkcmF3aW5nIHJvdXRlcyBp biByZXNwb25zZSB0byBlbXVsYXRlZA0KQ2xpZW50L1NlcnZlciBhc3NvY2lhdGlvbnMuDQoNCj4+ IEkgcmVhZCB5b3VyIHByb3Bvc2FsLCBidXQgaGF2ZSBub3QgcmVjZWl2ZWQgYW55IGluZGljYXRp b24gaWYgeW91IGhhdmUgcmVhZCBteSBBRVJPIHByb3Bvc2FsIHlldC4gQUVSTyB1c2VzDQo+PiBC R1AgaW4gYSB3YXkgdGhhdCB3YXMgZmlyc3Qgc3BlY2lmaWVkIGJ5IFJGQzYxNzkgaW4gMjAxMSBh bmQgY2FycmllZCBmb3J3YXJkIGludG8gZHJhZnQtdGVtcGxpbi1pcm9uYmlzIGFuZA0KPj4gZHJh ZnQtdGVtcGxpbi1hZXJvbGluay4gSW4gQUVSTywgQkdQIGFsbG93cyBBRVJPIFJlbGF5cyB0byAg a2VlcCB0cmFjayBvZiB3aGljaCBBRVJPIENsaWVudCBQcmVmaXhlcyAoQUNQcykNCj4+IGFyZSBh c3NvY2lhdGVkIHdpdGggd2hpY2ggQUVSTyBzZXJ2ZXJzLiBCdXQsIG9ubHkgdGhlIFNlcnZlcnMg YXJlIGV4cG9zZWQgdG8gbG9jYWxpemVkIEFDUCBtb2JpbGl0eSBldmVudHM7DQo+PiB0aGUgQkdQ IGlzIG9ubHkgdXBkYXRlZCB3aGVuIGFuIEFDUCBtb3ZlcyB0byBhIG5ldyBTZXJ2ZXIuIFRoaXMg bWVhbnMgdGhhdCB0aGVyZSB3aWxsIGJlIHZlcnkgbGl0dGxlIGNodXJuDQo+PiBpbiB0aGUgQkdQ IHJvdXRpbmcgc3lzdGVtIGl0c2VsZi4gU28sIHRoZSBCR1AgaXMgbm90IGRpcmVjdGx5IGV4cG9z ZWQgdG8gbG9jYWxpemVkIG1vYmlsaXR5IGV2ZW50cy4NCj4NCj4gSSBrbm93IHlvdSBhcmUgdGhl IGd1eSB3aG8gaW52ZW50IElTQVRBUA0KDQpUaGF0IHdhcyBhIGxvbmcgdGltZSBhZ28uIDpefQ0K DQo+IHNvIEkgdW5kZXJzdGFuZCB5b3UgbWF5IHV0aWxpemUgc2FtZSBtZWNoYW5pc20uDQoNCk5v dCBleGFjdGx5IHRoZSBzYW1lIG1lY2hhbmlzbSwgYnV0IHllcyB0aGUgc2FtZSBOQk1BIHR1bm5l bCB2aXJ0dWFsIGxpbmsgbW9kZWwuDQpPbmNlIHRoZSB2aXJ0dWFsIGxpbmsgaXMgZXN0YWJsaXNo ZWQsIG9yZGluYXJ5IGxpbmstbG9jYWwgc2VydmljZXMgbGlrZSBESENQdjYgYW5kIElQdjYNCk5l aWdoYm9yIERpc2NvdmVyeSAoTkQpIGNhbiBiZSB1c2VkIHRvIG1hbmFnZSBDbGllbnQvU2VydmVy IGFzc29jaWF0aW9ucyBhbmQgQ2xpZW50DQptb2JpbGl0eSBldmVudHMuIFRoZXJlIGlzIG5vIG5l ZWQgZm9yIGFueSBvdGhlciBjb250cm9sIG1lc3NhZ2Ugc2lnbmFsaW5nIHByb3RvY29scy4NCg0K PiBZb3UgYW5kIG1lDQo+IGxvb2sgYmlnLWJlbGlldmVyIG9mIEJHUCBlY29zeXN0ZW0uIEluIG15 IGRyYWZ0LCAzZ3BwIGRlZmluZWQgbW9iaWxpdHkgbWFuYWdlbWVudCBpcyBhc3N1bWVkIHRvIGV4 aXN0IHNvDQo+IHRoZSBtb2JpbGl0eSBtYW5hZ2VtZW50IGV4cG9ydHMgQkdQIG1vYmlsaXR5IGlu Zm9ybWF0aW9uIGludG8gcm91dGluZyBpbmZvcm1hdGlvbi4gRG8geW91IGFzc3VtZSAzZ3BwDQo+ IG9yIGlldGYgbW9iaWxpdHkgbWFuYWdlbWVudCBwcm90b2NvbC9zeXN0ZW0gaW4geW91ciBkcmFm dCBhcyB3ZWxsPw0KDQpNeSBkcmFmdCBwcmVzZW50cyBhIG1ldGhvZCBmb3IgbWFuYWdpbmcgQ2xp ZW50IG1vYmlsaXR5IGJhc2VkIG9uIERIQ1B2NiBhbmQNCklQdjYgTkQgbWVzc2FnaW5nIGluIHRo ZSBzYW1lIHdheSB0aGF0IHRoZXNlIGZ1bmN0aW9ucyB3b3VsZCB3b3JrIG9uIG9yZGluYXJ5DQps aW5rcy4gQnV0IENsaWVudCBtb2JpbGl0eSBkb2VzIG5vdCBnZXQgcHJvcGFnYXRlZCB1cCB0byB0 aGUgU2VydmVyL1JlbGF5IEJHUA0Kcm91dGluZyBzeXN0ZW0gdW5sZXNzIHRoZSBDbGllbnQgY2hh bmdlcyBvdmVyIHRvIGEgbmV3IFNlcnZlciAod2hpY2ggc2hvdWxkDQpoYXBwZW4gb25seSB2ZXJ5 IGluZnJlcXVlbnRseSkuIFRoYXQgc2FpZCwgdGhlIEFFUk8gQkdQIHJvdXRpbmcgc3lzdGVtIGNh bg0KYmUgdXNlZCBpbmRlcGVuZGVudGx5IG9mIHRoZSB1bmRlcmx5aW5nIENsaWVudCBtb2JpbGl0 eSBzaWduYWxpbmcgLSBpdCBpcyBvbmx5DQpjb25jZXJuZWQgd2l0aCBhbm5vdW5jaW5nIGFuZCB3 aXRoZHJhd2luZyByb3V0ZXMgdmlhIEJHUCB1cGRhdGVzLiANCg0KPj4gQUVSTyBDbGllbnRzIHVz ZSBETlMgZGlzY292ZXJ5IHRvIGRpc2NvdmVyIHRoZSBhZGRyZXNzKGVzKSBvZiBuZWFyYnkgU2Vy dmVyKHMpIGFzIHRoZSBkZWZhdWx0DQo+PiBtZWFucy4gT3RoZXIgc29sdXRpb25zIHN1Y2ggYXMg bWFudWFsIGNvbmZpZ3VyYXRpb24sIERIQ1Agb3B0aW9uLCBldGMuIGFyZSBhbHNvIHBvc3NpYmxl Lg0KPg0KPiBZZXMsIEkga25vdywgdGhlcmUgYXJlIG1hbnkgdHlwZSBvZiBlbmRwb2ludCBkaXNj b3ZlcnkuIERvIHlvdSBjbGVhciBhbnkgcGF0ZW50IHdoaWNoIGNsYWltDQo+IHRoZSByaWdodCBv ZiBkbnMgYmFzZWQgZW5kcG9pbnQgZGlzY292ZXJ5Pw0KDQpUaGVyZSBhcmUgbm8gcGF0ZW50cyB0 aGF0IEkgYW0gYXdhcmUgb2YuIFRoZSBBRVJPIEROUyBkaXNjb3ZlcnkgZXhhY3RseSBwYXJhbGxl bHMgdGhlDQpkaXNjb3ZlcnkgbWV0aG9kIHVzZWQgZm9yIElTQVRBUCBhcyBmb3VuZCBpbiB3aWRl bHkgZGVwbG95ZWQgaW1wbGVtZW50YXRpb25zLg0KDQo+PiBJdCB3b3VsZCBiZSBuaWNlIGlmIHlv dSB3ZXJlIHRvIHJldmlldyB0aGUgQUVSTyBhcmNoaXRlY3R1cmUgYW5kIGV4cGxhaW4gdG8gbWUg dGhlIHdheSBpbiB3aGljaA0KPj4gdGhpcyByZXF1aXJlbWVudCBpcyBvciBpcyBub3QgYWRkcmVz c2VkIGFscmVhZHkgdGhlcmUuIA0KDQo+IFdlbGwsIHdpbGwgZG8uIEkgc3VwcG9zZSB0b2RheSB5 b3UgcHJvdmlkZXMgZXhwbGFuYXRpb24gdG8gZXh0cmFjdCBhZXJvIGludG8gdGhyZWUgd29yayBp dGVtcy4NCj4gVGhhdHMgd29ya3MgYSBsb3QgZm9yIG1lIHRvIGhlbHAgcmV2aWV3aW5nIHRoZSBh ZXJvLg0KDQpJIHN0aWxsIGRvbid0IGZlZWwgbGlrZSBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIHRo cmVlIHdvcmsgaXRlbXMsIGJ1dCBpdCB3YXMgc2FpZCBpbiB0aGUgY2FsbA0KKG1heWJlIGJ5IEFs cGVyPykgdGhhdCB0aGUgZW5oYW5jZWQgYW5jaG9yaW5nIHRlYW0gd291bGQgYmUgYSBwbGFjZSB0 byBkaXNjdXNzLiBJDQp0aGluayB3ZSB3b3VsZCBmaW5kIHRoYXQgQUVSTyBjb3VsZCBhbHNvIGJl IGRpc2N1c3NlZCB3aXRoaW4gdGhlIGNvbnRleHQgb2YgdGhlDQpvdGhlciB0d28gdGVhbXMgYXMg d2VsbC4NCg0KSSB0aGluayBmcm9tIG15IHRhbGsgdG9kYXkgcGVvcGxlIGNhbWUgYXdheSB3aXRo IGEgYmV0dGVyIHVuZGVyc3RhbmRpbmcgb2YgdGhlDQpvdmVyYWxsIEFFUk8gYXJjaGl0ZWN0dXJl IGV2ZW4gdGhvdWdoIHRoZSB0YWxrIGFuZCBkZW1vIGZvY3VzZWQgc3BlY2lmaWNhbGx5IG9uDQp0 aGUgQkdQIHJvdXRpbmcgc3lzdGVtLiBUaGVyZSB3YXMgaW50ZXJlc3QgaW4gaGF2aW5nIGEgbW9y ZSB0aG9yb3VnaCBkaXNjdXNzaW9uDQpvbiB0aGUgbGlzdCwgYW5kIEkgd2lsbCBzdGFydCBhIG5l dyB0aHJlYWQgb24gdGhhdCBzb29uLg0KDQpUaGFua3MgLSBGcmVkDQpmcmVkLmwudGVtcGxpbkBi b2VpbmcuY29tICANCg0KLS0tDQoNCkZyb206IFNhdG9ydSBNYXRzdXNoaW1hIFttYWlsdG86c2F0 b3J1Lm1hdHN1c2hpbWFAZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMDcsIDIw MTQgMjozNCBBTQ0KVG86IFRlbXBsaW4sIEZyZWQgTA0KQ2M6IHNhcmlrYXlhQGllZWUub3JnOyBE YXBlbmcgTGl1OyBkbW1AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRE1NXSBHb2luZyBmb3J3YXJk IHdpdGggdGhlIERNTSB3b3JrIGl0ZW1zDQoNCkhpIEZyZWQsDQoNCk9uIFR1ZSwgT2N0IDcsIDIw MTQgYXQgMTI6NTAgQU0sIFRlbXBsaW4sIEZyZWQgTCA8RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNv bT4gd3JvdGU6DQpIaSwNCg0KPiBNYXliZSBJIGNhbid0IGF0dGVuZCBuZXh0IHdlYmV4IG1lZXRp bmcgdG9tb3Jyb3cuDQoNClRoYXQgaXMgdG9vIGJhZCwgYmVjYXVzZSBJIHdpbGwgYmUgYnJpZWZp bmcgdGhlIEFFUk8gQkdQIHJvdXRpbmcgc3lzdGVtIGF0IHRoZSBtZWV0aW5nIHRvbW9ycm93Lg0K DQpZZXMsIHNvcnJ5IHRvIHNheS4NCg0KwqANCkkgcmVhZCB5b3VyIHByb3Bvc2FsLCBidXQgaGF2 ZSBub3QgcmVjZWl2ZWQgYW55IGluZGljYXRpb24gaWYgeW91IGhhdmUgcmVhZCBteSBBRVJPIHBy b3Bvc2FsIHlldC4gQUVSTyB1c2VzDQpCR1AgaW4gYSB3YXkgdGhhdCB3YXMgZmlyc3Qgc3BlY2lm aWVkIGJ5IFJGQzYxNzkgaW4gMjAxMSBhbmQgY2FycmllZCBmb3J3YXJkIGludG8gZHJhZnQtdGVt cGxpbi1pcm9uYmlzIGFuZA0KZHJhZnQtdGVtcGxpbi1hZXJvbGluay4gSW4gQUVSTywgQkdQIGFs bG93cyBBRVJPIFJlbGF5cyB0b8KgIGtlZXAgdHJhY2sgb2Ygd2hpY2ggQUVSTyBDbGllbnQgUHJl Zml4ZXMgKEFDUHMpDQphcmUgYXNzb2NpYXRlZCB3aXRoIHdoaWNoIEFFUk8gc2VydmVycy4gQnV0 LCBvbmx5IHRoZSBTZXJ2ZXJzIGFyZSBleHBvc2VkIHRvIGxvY2FsaXplZCBBQ1AgbW9iaWxpdHkg ZXZlbnRzOw0KdGhlIEJHUCBpcyBvbmx5IHVwZGF0ZWQgd2hlbiBhbiBBQ1AgbW92ZXMgdG8gYSBu ZXcgU2VydmVyLiBUaGlzIG1lYW5zIHRoYXQgdGhlcmUgd2lsbCBiZSB2ZXJ5IGxpdHRsZSBjaHVy bg0KaW4gdGhlIEJHUCByb3V0aW5nIHN5c3RlbSBpdHNlbGYuIFNvLCB0aGUgQkdQIGlzIG5vdCBk aXJlY3RseSBleHBvc2VkIHRvIGxvY2FsaXplZCBtb2JpbGl0eSBldmVudHMuDQoNCkkga25vdyB5 b3UgYXJlIHRoZSBndXkgd2hvIGludmVudCBJU0FUQVAgc28gSSB1bmRlcnN0YW5kIHlvdSBtYXkg dXRpbGl6ZSBzYW1lIG1lY2hhbmlzbS4gWW91IGFuZCBtZSBsb29rIGJpZy1iZWxpZXZlciBvZiBC R1AgZWNvc3lzdGVtLiBJbiBteSBkcmFmdCwgM2dwcCBkZWZpbmVkIG1vYmlsaXR5IG1hbmFnZW1l bnQgaXMgYXNzdW1lZCB0byBleGlzdCBzbyB0aGUgbW9iaWxpdHkgbWFuYWdlbWVudCBleHBvcnRz IEJHUCBtb2JpbGl0eSBpbmZvcm1hdGlvbiBpbnRvIHJvdXRpbmcgaW5mb3JtYXRpb24uIERvIHlv dSBhc3N1bWUgM2dwcCBvciBpZXRmIG1vYmlsaXR5IG1hbmFnZW1lbnQgcHJvdG9jb2wvc3lzdGVt IGluIHlvdXIgZHJhZnQgYXMgd2VsbD8NCg0KDQrCoEFueWNhc3QgaGFzIGJlZW4gd2lkZWx5IHVz ZWQgaW4gb3RoZXIgcm91dGVyIGRpc2NvdmVyeSBzb2x1dGlvbnMuIFR3byBjYXNlcyBhcmUgNnJk IFtSRkM1OTY5XQ0KYW5kIDZ0bzQgW1JGQzMwNjhdLiBCdXQsIGFueWNhc3QgaGFzIGtub3duIG9w ZXJhdGlvbmFsIHByb2JsZW1zIGluIHJlYWwgbmV0d29ya3MsIGFuZCBpbiBmYWN0DQpoYXMgY2F1 c2VkIG1ham9yIGhlYWRhY2hlcyBmb3IgNnRvNCAtIGV2ZW4gdG8gdGhlIHBvaW50IHRoYXQgaXRz IGRlcHJlY2F0aW9uIGlzIGN1cnJlbnRseSBiZWluZw0KY2FsbGVkIGZvcjoNCg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2lwdjYvY3VycmVudC9tc2cyMTI0OC5odG1sDQpo dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvaXB2Ni9jdXJyZW50L21zZzIxMjY4 Lmh0bWwNCg0KQUVSTyBDbGllbnRzIHVzZSBETlMgZGlzY292ZXJ5IHRvIGRpc2NvdmVyIHRoZSBh ZGRyZXNzKGVzKSBvZiBuZWFyYnkgU2VydmVyKHMpIGFzIHRoZSBkZWZhdWx0DQptZWFucy4gT3Ro ZXIgc29sdXRpb25zIHN1Y2ggYXMgbWFudWFsIGNvbmZpZ3VyYXRpb24sIERIQ1Agb3B0aW9uLCBl dGMuIGFyZSBhbHNvIHBvc3NpYmxlLg0KDQpZZXMsIEkga25vdywgdGhlcmUgYXJlIG1hbnkgdHlw ZSBvZiBlbmRwb2ludCBkaXNjb3ZlcnkuIERvIHlvdSBjbGVhciBhbnkgcGF0ZW50IHdoaWNoIGNs YWltIHRoZSByaWdodCBvZiBkbnMgYmFzZWQgZW5kcG9pbnQgZGlzY292ZXJ5Pw0KwqANCkl0IHdv dWxkIGJlIG5pY2UgaWYgeW91IHdlcmUgdG8gcmV2aWV3IHRoZSBBRVJPIGFyY2hpdGVjdHVyZSBh bmQgZXhwbGFpbiB0byBtZSB0aGUgd2F5IGluIHdoaWNoDQp0aGlzIHJlcXVpcmVtZW50IGlzIG9y IGlzIG5vdCBhZGRyZXNzZWQgYWxyZWFkeSB0aGVyZS7CoA0KDQpXZWxsLCB3aWxsIGRvLiBJIHN1 cHBvc2UgdG9kYXkgeW91IHByb3ZpZGVzIGV4cGxhbmF0aW9uIHRvIGV4dHJhY3QgYWVybyBpbnRv IHRocmVlIHdvcmsgaXRlbXMuIFRoYXRzIHdvcmtzIGEgbG90IGZvciBtZSB0byBoZWxwIHJldmll d2luZyB0aGUgYWVyby4NCg0KQ2hlZXJzLA0KLS1zYXRvcnUNCsKgDQo= From nobody Tue Oct 7 09:40:39 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4B61A700A for ; Tue, 7 Oct 2014 09:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q31U5hzkHF1 for ; Tue, 7 Oct 2014 09:40:37 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B079D1A6FD3 for ; Tue, 7 Oct 2014 09:40:36 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id q1so6732364lam.4 for ; Tue, 07 Oct 2014 09:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3MTv9SHHPgB8P8yZjoQ/hoHN2W+MVK4eE4dLaRtEv08=; b=saTWE+iTixzpKbhjZFn56N2u9H9Yd6EAkKZ44V6AO6AHEFuiJztlCLBwS3HAUGlW0O VRy/ZFVk+Hu0QLPCU8tn9CxYfVYPedD+21mz0U493eIFByL+4EvHWn3OuD5FKUwW/Ib9 1IwoCb3z0yhvDSqwCbSzKs13uGW7msRdeqHrJghEBYewPrPDGPL9FpnAd5NGBmhu3XhN 03sQX/yMSDuy2hYoU5TBGCCw5hACOK6g/WkU71n0hpyRV31g1eqgLrit4N7Y5d854gyt PTGfjnUEvDKt8VpwCLLpMlFOgPcBIhpZc8APPULmYILRPlyjlxnLsqTF0peo/FyyZ1HH zZKA== MIME-Version: 1.0 X-Received: by 10.152.22.7 with SMTP id z7mr5428847lae.6.1412700035046; Tue, 07 Oct 2014 09:40:35 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Tue, 7 Oct 2014 09:40:35 -0700 (PDT) In-Reply-To: <5433AEC0.6000104@gmail.com> References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <5433AEC0.6000104@gmail.com> Date: Tue, 7 Oct 2014 11:40:35 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen , Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/1_wzHKhob0x9-Xey73PA5HI1RSM Cc: dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:40:38 -0000 Hi Satoru, I copied Jouni's mail and removed ietf and iesg from the list. On Tue, Oct 7, 2014 at 4:13 AM, Jouni Korhonen wrote: > > Hi, > > Thank you for the review. See my initial comments inline. > > 10/7/2014 8:50 AM, Abdussalam Baryun kirjoitti: >> >> Dear IESG, >> >> I received you message request for review, but there are some issues >> missing for my review. For example there is no milestones presented even >> though the submitted charter states below >> >> "The working group may decide to extend the current milestones based on >> the new information and knowledge gained during working on other >> documents listed in the initial milestones. " > > > When we submitted the re-charter text we were given an advice to leave them > out - for some reason. Anyway, these were the milestones at the time of > finishing the text in the WG: > > Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group > document. To be Proposed Standard. > > Feb 2015 - Submit 'Forwarding path and signaling management' as a > working group document. To be Proposed Standard. > > May 2015 - Submit 'Exposing mobility state to mobile nodes and network > nodes' as a working group document(s). To be Proposed > Standard. > > Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. > To be Proposed Standard. > > Nov 2015 - Submit 'Forwarding path and signaling management' submitted > to the IESG. To be Proposed Standard. > > Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network > nodes' submitted to the IESG. To be Proposed Standard. > The above clearly states that three different protocols will be developed by DMM as Proposed Standard. You are an operator. Can you please comment on the possibility of adoption by operators three different protocols for DMM? BTW there is no mention of deployment models and related milestones. Regards, Behcet From nobody Tue Oct 7 11:09:04 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556321ACF00 for ; Tue, 7 Oct 2014 11:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 BQs2rypZI2UH for ; Tue, 7 Oct 2014 11:08:52 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7ED1ACEF7 for ; Tue, 7 Oct 2014 11:08:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s97I8lqi003607; Tue, 7 Oct 2014 11:08:47 -0700 Received: from XCH-BLV-101.nw.nos.boeing.com (xch-blv-101.nw.nos.boeing.com [130.247.25.116]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s97I8dJe003560 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Tue, 7 Oct 2014 11:08:40 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-101.nw.nos.boeing.com ([169.254.1.220]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 11:08:39 -0700 From: "Templin, Fred L" To: "dmm@ietf.org" Thread-Topic: AERO and Mobile IP comparison Thread-Index: Ac/iV8/siFPCXUa/R9y5TOPIME31aw== Date: Tue, 7 Oct 2014 18:08:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D399B7@XCH-BLV-504.nw.nos.boeing.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/B75dDO1vNPJ6KD6n-lcpUKGkQkA Subject: [DMM] AERO and Mobile IP comparison X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:09:00 -0000 Hi, During the call today, there was interest expressed in having a discussion = on the differences between AERO and Mobile IP. In the interest of getting the disc= ussion going, I will just say the following for now: - the mobility archetype for Mobile IP is that of a mobile host that wander= s away from its home link and tells a home agent on its home link where it has moved = to - the mobility archetype for AERO is that of a mobile router that stays con= nected to its home link even if it changes between access link technologies The latter model is supported through the abstraction of an NBMA tunnel vir= tual link that spans the mobile node's home network. IMHO, it is a cleaner and m= ore natural architecture that makes everything else easier. Comments? Questions? Thanks - Fred fred.l.templin@boeing.com =20 From nobody Tue Oct 7 11:15:52 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FD81ACEA3 for ; Tue, 7 Oct 2014 11:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] 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 Tnsn2Y_qqNSd for ; Tue, 7 Oct 2014 11:15:47 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 63C0F1A8729 for ; Tue, 7 Oct 2014 11:15:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=c5vRc+SQH2Dg6GyIAooe1QivGzHXMDTHmLNG5XH8h7eY7iyIzgSocGL1oX1I1NyR; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XbZIY-0005cW-D4; Tue, 07 Oct 2014 14:15:46 -0400 Message-ID: <54342DD1.5030000@earthlink.net> Date: Tue, 07 Oct 2014 11:15:45 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , dmm@ietf.org References: <2134F8430051B64F815C691A62D9831832D399B7@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D399B7@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7f52bc597bbf8f82b73904efb9036d72d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Y7DCIvLvuzsphSO059wPwXl7RfM Subject: Re: [DMM] AERO and Mobile IP comparison X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:15:49 -0000 Hello Fred, One comment: On 10/7/2014 11:08 AM, Templin, Fred L wrote: > - the mobility archetype for AERO is that of a mobile router that stays connected to its > home link even if it changes between access link technologies This implies local-only mobility, right? If so, then I guess from your other description that "local" is engineered to be huge. But more to the point it puts AERO pretty much in direct competition with PMIP -- or, perhaps PMIP with LMAs stitched together by way of BGP. Regards, Charlie P. From nobody Tue Oct 7 11:40:19 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7481A872F for ; Tue, 7 Oct 2014 11:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 pw7R1nz0vKuB for ; Tue, 7 Oct 2014 11:40:05 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4BA1A86E2 for ; Tue, 7 Oct 2014 11:39:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s97IdshF019063; Tue, 7 Oct 2014 11:39:54 -0700 Received: from XCH-BLV-503.nw.nos.boeing.com (xch-blv-503.nw.nos.boeing.com [130.247.25.192]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s97IdkHO018948 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Oct 2014 11:39:46 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-503.nw.nos.boeing.com ([169.254.3.244]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 11:39:45 -0700 From: "Templin, Fred L" To: Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] AERO and Mobile IP comparison Thread-Index: Ac/iV8/siFPCXUa/R9y5TOPIME31awAPZK6AAA6G00A= Date: Tue, 7 Oct 2014 18:39:45 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D39AB8@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D399B7@XCH-BLV-504.nw.nos.boeing.com> <54342DD1.5030000@earthlink.net> In-Reply-To: <54342DD1.5030000@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4Y-IkfPW35BtpT5nyHZ_EpXONMA Subject: Re: [DMM] AERO and Mobile IP comparison X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:40:13 -0000 Hi Charlie, > -----Original Message----- > From: Charlie Perkins [mailto:charles.perkins@earthlink.net] > Sent: Tuesday, October 07, 2014 11:16 AM > To: Templin, Fred L; dmm@ietf.org > Subject: Re: [DMM] AERO and Mobile IP comparison >=20 >=20 > Hello Fred, >=20 > One comment: >=20 > On 10/7/2014 11:08 AM, Templin, Fred L wrote: > > - the mobility archetype for AERO is that of a mobile router that stays= connected to its > > home link even if it changes between access link technologies >=20 > This implies local-only mobility, right? Not just local, but global also. Take for example an AERO mobile router tha= t is connecting over an access link provided by some ISP other than its home network. In th= at case, the node typically remains connected to its home link by setting up a VPN conne= ction via a security gateway connected to its home network. In that case, the AERO link= is said to be extended *through* the security gateway. So, the AERO mobile router rema= ins tethered to its home link via the VPN, but it can set up route optimizatio= n with Internet correspondents in a manner similar to MIPv6. In that case, communications w= ith the Internet correspondent can bypass the home network. > If so, then I guess from your other description that "local" is > engineered to be huge. AERO has been evolving for the better part of a decade really, but in recen= t years it has been specifically focused on enterprise network mobility where the ente= rprise network that services my employer has been used as the reference model. In = such cases, the AERO virtual link is indeed huge. > But more to the point it puts AERO > pretty much in direct competition with PMIP -- or, perhaps > PMIP with LMAs stitched together by way of BGP. I have to admit that PMIP comparison was an after-thought that only went in= to the AERO spec very recently. Yes, AERO can be applied in the same use cases as = for PMIP, but in the enterprise mobility case the AERO Client itself is the mob= ile router and runs a small piece of application layer code to do the tunneling and co= ntrol messaging. In our enterprise, for example, mobile nodes can start out attac= hed to a wired LAN connection, then change over to WiFi, then change over to 4G= , etc. See my "day in the life" message from several weeks ago: http://www.ietf.org/mail-archive/web/dmm/current/msg01464.html In fact, I see PMIP as a very specialized solution for cellular operator ne= tworks. There are vastly many other use cases where having the mobile node do the tunneling on its own behalf is necessary. AERO supports either model. Thanks - Fred fred.l.templin@boeing.com > Regards, > Charlie P. From nobody Tue Oct 7 13:25:20 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706D11A1ABE for ; Tue, 7 Oct 2014 13:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.786 X-Spam-Level: X-Spam-Status: No, score=-2.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] 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 b73wmTa55rWc for ; Tue, 7 Oct 2014 13:25:16 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0141A00A7 for ; Tue, 7 Oct 2014 13:25:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=OHaKbDnPxff1VSwomS8+RgUCMlJEc2gXmXJtX4n6dXeHPIm3Fqa/hRHVlHRIyuY5; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [107.1.141.74] (helo=[192.168.254.194]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XbbJr-0005J1-FL; Tue, 07 Oct 2014 16:25:15 -0400 Message-ID: <54344C29.1060807@earthlink.net> Date: Tue, 07 Oct 2014 13:25:13 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Templin, Fred L" , dmm@ietf.org References: <2134F8430051B64F815C691A62D9831832D399B7@XCH-BLV-504.nw.nos.boeing.com> <54342DD1.5030000@earthlink.net> <2134F8430051B64F815C691A62D9831832D39AB8@XCH-BLV-504.nw.nos.boeing.com> In-Reply-To: <2134F8430051B64F815C691A62D9831832D39AB8@XCH-BLV-504.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7cc8d7ce7b219f7ed8b52ae13b286f67a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 107.1.141.74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4WsvmBxvbgqx7BBFLNlql8HdWBo Subject: Re: [DMM] AERO and Mobile IP comparison X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:25:18 -0000 Hello Fred, A few little follow-up questions... On 10/7/2014 11:39 AM, Templin, Fred L wrote: >> From: Charlie Perkins [mailto:charles.perkins@earthlink.net] >> >> ... >> This implies local-only mobility, right? > Not just local, but global also. Take for example an AERO mobile router that is connecting > over an access link provided by some ISP other than its home network. In that case, the > node typically remains connected to its home link by setting up a VPN connection via a > security gateway connected to its home network. In that case, the AERO link is said to > be extended *through* the security gateway. So, the AERO mobile router remains > tethered to its home link via the VPN, but it can set up route optimization with Internet > correspondents in a manner similar to MIPv6. In that case, communications with the > Internet correspondent can bypass the home network. - Is the VPN setup part of AERO? - How does the mobile router know whether or not to do this? - Why would the external AERO servers admit traffic from the AERO client? Or, is AERO completely out of the picture for external networks? - Is the route optimization simply a matter of VPN to the correspondent node? Or, did you mean to suggest use of the MIPv6 mechanisms? Regards, Charlie P. From nobody Tue Oct 7 13:55:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A002B1A8865 for ; Tue, 7 Oct 2014 13:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66n72VLhzPck for ; Tue, 7 Oct 2014 13:55:44 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D471A8861 for ; Tue, 7 Oct 2014 13:55:42 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so7100389lab.5 for ; Tue, 07 Oct 2014 13:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=Yth2/YoRa5n+up0ZDze3u2LqKlbX4O5gkxp6PYBYAOs=; b=kA1MCsALokQRrKTBsxJeIAFo0U+x0dElrsoG7I8AZd+6VSrdhYIRYtVc5HrgR01BAe +u0YmlT2sLjKaI/P14uSBluZmy5HnL5t2AgaYnfrJVS8QTUyRX/d02r+2B6Pz2OaUbDS ZiJELGs1iQey8QovdGt6JmSwEA9dPlZWcQ/HhP+EY7v+drEy8HOzIwlEWOXKkQ0cpNhu q9wjbqY9LPO7SlCWpuOFXGHo3abWl2CGC1yJhwVdLomZOjftsTynVgUBCqQsfVvjBmZu 55p28B5FmDx5E18idrgy3oH7Ot+z/aNiNSXzfBAgK8hYYcNHO79wfOIusRzpXV4FG0aL NpqA== X-Received: by 10.112.198.74 with SMTP id ja10mr6453358lbc.14.1412715340722; Tue, 07 Oct 2014 13:55:40 -0700 (PDT) Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPSA id k3sm7050343lam.33.2014.10.07.13.55.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 13:55:39 -0700 (PDT) Message-ID: <54345351.6010100@gmail.com> Date: Tue, 07 Oct 2014 23:55:45 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/npPRLfg3SbPHLs9vdNp_wTUNd6k Subject: [DMM] DMM Interim telco #3 materials uploaded X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:55:46 -0000 Go here: o http://www.ietf.org/proceedings/interim/2014/10/07/dmm/agenda/agenda-interim-2014-dmm-3 o http://www.ietf.org/proceedings/interim/2014/10/07/dmm/minutes/minutes-interim-2014-dmm-3 o http://www.ietf.org/proceedings/interim/2014/10/07/dmm/proceedings.html - Jouni From nobody Tue Oct 7 13:58:38 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337F61A8862 for ; Tue, 7 Oct 2014 13:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xh2_aDn33ZRk for ; Tue, 7 Oct 2014 13:58:33 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B0FC1A8868 for ; Tue, 7 Oct 2014 13:58:32 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so6806111lbd.6 for ; Tue, 07 Oct 2014 13:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=XVhBg03z78sN+twdLmjb3qvV60momG6KVhv7RDbBtIk=; b=C0iaASYp05+e1keL1QfVOQiRbBWiaJKFMDI7yEKQ+D+ZcIzc0Q87QJsI7qYbpMeFpA /P9VJj/krZCGd4Z3QEMGWFcJkNHCKBuFIC/42PKQBkUu9cof5NNFEVQ40Nt+HTsCIXYR PTFlcFTgBtb8qwARRjKrYfQ4/HbsnJQW/gnTMoe9gKrakd8ZWtuEB0jb0imCKWZZlhPX 95pGpX1CpH4ZkbWCfD9R5mh+NHusP3DArKkmv3cwc7IZ+9wVyW+0LaHU8pbhvq46QzF5 9LFCpcVgaVObn0Rg0A1iT5BpWj1rUAOvDsI4GWMQl/YloQfvfWTuZc1ia9S5XNG/gnKC 2vXQ== X-Received: by 10.112.61.225 with SMTP id t1mr5498242lbr.104.1412715510649; Tue, 07 Oct 2014 13:58:30 -0700 (PDT) Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPSA id ad3sm7037638lbc.45.2014.10.07.13.58.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 13:58:29 -0700 (PDT) Message-ID: <543453FB.3000704@gmail.com> Date: Tue, 07 Oct 2014 23:58:35 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , "Sri Gundavelli (sgundave)" , Dapeng Liu Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/1SwQTsrRILX3zoWbrFbM0155XGs Subject: [DMM] addition to work team leads.. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 20:58:35 -0000 Folks, As announced, discussed and agreed in the Interim telco #3 Sri will take the lead for "Distributed mobility management deployment models and scenarios" work item. - Jouni & Dapend From nobody Tue Oct 7 14:09:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC65C1A8880 for ; Tue, 7 Oct 2014 14:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnk07pqXE71I for ; Tue, 7 Oct 2014 14:09:49 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8C21A8869 for ; Tue, 7 Oct 2014 14:09:49 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id s18so7134906lam.23 for ; Tue, 07 Oct 2014 14:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=gkDWqsryREtEEs2+aU/NJAQ0DIZjn8BbkYX2xLyuGAU=; b=0WYtoS3ytj9I4Pdjd9nEOjMvOarnLTzRI3ysuvTIsOGd8xkRbCq85xp4c/BT693Ihv udOrM49H0CKIwgEpIWj1lOh02GsZO9TvJozaHW+N17LgYGU/+qOYiFFIjA6Hw03+d3CI zzvqVw0j7cZdQ11hcObJJtkcVyQBKEOExJyX554Jr2AFOPmk9WaxoI1arVvxuTLa0DUE ULfJJ/XZSVyQF/wm041FoJkm0quzsz0oMV3HRHQvBjxub0C9fDaE+e1w7YLxGtUwIaR6 Zd/6XQCd7/vxEd3MoZWqfpDVpEsJ0QfAeRzpp2J/LUZbOlFBOYyvFlIJBBFM3dQndrGR 22bw== MIME-Version: 1.0 X-Received: by 10.152.163.66 with SMTP id yg2mr6801066lab.38.1412716187714; Tue, 07 Oct 2014 14:09:47 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Tue, 7 Oct 2014 14:09:47 -0700 (PDT) In-Reply-To: <543453FB.3000704@gmail.com> References: <543453FB.3000704@gmail.com> Date: Tue, 7 Oct 2014 16:09:47 -0500 Message-ID: From: Behcet Sarikaya To: Jouni Korhonen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/lWt42DWqGse60n2lB6qoXLLN2so Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] addition to work team leads.. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:09:51 -0000 Hi Jouni, I am confused. On Tue, Oct 7, 2014 at 3:58 PM, Jouni Korhonen wrote: > Folks, > > As announced, discussed and agreed in the Interim telco #3 Sri will take the > lead for "Distributed mobility management deployment models and scenarios" > work item. When you asked us to comment on the charter, there was no deployment models in the charter. Next, when we look at the milestones you just sent: Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group document. To be Proposed Standard. Feb 2015 - Submit 'Forwarding path and signaling management' as a working group document. To be Proposed Standard. May 2015 - Submit 'Exposing mobility state to mobile nodes and network nodes' as a working group document(s). To be Proposed Standard. Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. To be Proposed Standard. Nov 2015 - Submit 'Forwarding path and signaling management' submitted to the IESG. To be Proposed Standard. Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' submitted to the IESG. To be Proposed Standard. again there are no deployment models. As you know there were a lot of concerns on the deployment models as the deployment meant a specific protocol which does not exist in dmm case. It seems like deployment models came to your mind after I sent a mail asking about this. BTW, that was a joke :-) Regards, Behcet > > - Jouni & Dapend > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Tue Oct 7 14:20:21 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800821A8860 for ; Tue, 7 Oct 2014 14:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 uzZ6ATf6hWlz for ; Tue, 7 Oct 2014 14:20:17 -0700 (PDT) Received: from slb-mbsout-01.boeing.com (slb-mbsout-01.boeing.com [130.76.64.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE901A0AFE for ; Tue, 7 Oct 2014 14:20:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s97LKHEk012009; Tue, 7 Oct 2014 14:20:17 -0700 Received: from XCH-BLV-302.nw.nos.boeing.com (xch-blv-302.nw.nos.boeing.com [130.247.25.214]) by slb-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s97LKAUu011723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 7 Oct 2014 14:20:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-302.nw.nos.boeing.com ([169.254.2.49]) with mapi id 14.03.0181.006; Tue, 7 Oct 2014 14:20:10 -0700 From: "Templin, Fred L" To: Charlie Perkins , "dmm@ietf.org" Thread-Topic: [DMM] AERO and Mobile IP comparison Thread-Index: Ac/iV8/siFPCXUa/R9y5TOPIME31awAPZK6AAA6G00D//6/1gIAAbz3g Date: Tue, 7 Oct 2014 21:20:09 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D39F4B@XCH-BLV-504.nw.nos.boeing.com> References: <2134F8430051B64F815C691A62D9831832D399B7@XCH-BLV-504.nw.nos.boeing.com> <54342DD1.5030000@earthlink.net> <2134F8430051B64F815C691A62D9831832D39AB8@XCH-BLV-504.nw.nos.boeing.com> <54344C29.1060807@earthlink.net> In-Reply-To: <54344C29.1060807@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/foeU3-k9fqgqvhazt0eqP7H1qV4 Subject: Re: [DMM] AERO and Mobile IP comparison X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:20:19 -0000 Hi Charlie, > -----Original Message----- > From: Charlie Perkins [mailto:charles.perkins@earthlink.net] > Sent: Tuesday, October 07, 2014 1:25 PM > To: Templin, Fred L; dmm@ietf.org > Subject: Re: [DMM] AERO and Mobile IP comparison >=20 > Hello Fred, >=20 > A few little follow-up questions... >=20 > On 10/7/2014 11:39 AM, Templin, Fred L wrote: > >> From: Charlie Perkins [mailto:charles.perkins@earthlink.net] > >> > >> ... > >> This implies local-only mobility, right? > > Not just local, but global also. Take for example an AERO mobile router= that is connecting > > over an access link provided by some ISP other than its home network. I= n that case, the > > node typically remains connected to its home link by setting up a VPN c= onnection via a > > security gateway connected to its home network. In that case, the AERO = link is said to > > be extended *through* the security gateway. So, the AERO mobile router = remains > > tethered to its home link via the VPN, but it can set up route optimiz= ation with Internet > > correspondents in a manner similar to MIPv6. In that case, communicatio= ns with the > > Internet correspondent can bypass the home network. >=20 > - Is the VPN setup part of AERO? The AERO Client requests a DHCPv6 Prefix Delegation as part of the VPN setu= p. The security gateway (acting as an AERO Server) delegates the prefix and sets u= p a neighbor cache entry for the Client. > - How does the mobile router know whether or not to do this? The AERO Client needs to know whether it is connecting to an access link pr= ovided by the home network or by an ISP outside of the home network. One way of doing= this is to examine the connection-specific DNS suffix the Client gets when it conne= cts to the access link and comparing it to the home network DNS suffix. When I think about my laptop computer user experience, I have to perform a = manual intervention to select a security gateway and set up the VPN when I am conn= ecting via an Internet access link. That would be OK and compatible with AERO as well,= but would be much better if it were automated. Whether it can be fully automated depe= nds on what kind of security credentials are necessary to establish the VPN, e.g.,= whether certificates alone are sufficient or whether some kind of active badge need= s to be swiped, etc. Do you know more about this? > - Why would the external AERO servers admit traffic from the AERO client? The external AERO Servers are security gateways that also delegate AERO Cli= ent Prefixes (ACPs) to Clients using DHCPv6 PD. During PD, the Server performs = an additional layer of authentication for the Client above and beyond what is = done for establishing the VPN. So, the Server has a way of knowing that the Clie= nt is permitted to source packets from the delegated ACP. > Or, is AERO completely out of the picture for external networks? External networks as in something that does not have hard perimeters with security gateways - maybe like a university campus network? I'll have to th= ink more about that, but in that case there may need to be some other trust bas= is besides source address verification and IPsec tunnels. Any ideas? > - Is the route optimization simply a matter of VPN to the correspondent > node? VPN to the correspondent node (triggered by AERO mechanisms) is certainly a use case that we don't want to rule out. > Or, did you mean to suggest use of the MIPv6 mechanisms? For communications with correspondents that do not require IPsec protection= , the mechanism is the same as the MIPv6 Return Routability, only using IPv6 ND messaging for signaling. Otherwise, I just studied the RR procedure in RFC6275 and pretty much borrowed what I saw there for AERO. Thanks - Fred fred.l.templin@boeing.com =20 > Regards, > Charlie P. >=20 From nobody Tue Oct 7 14:23:17 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13ABD1A886A for ; Tue, 7 Oct 2014 14:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NIXH_OHZht1H for ; Tue, 7 Oct 2014 14:23:12 -0700 (PDT) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D03C1A8868 for ; Tue, 7 Oct 2014 14:23:12 -0700 (PDT) Received: by mail-la0-f52.google.com with SMTP id hz20so7279858lab.11 for ; Tue, 07 Oct 2014 14:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b1HkMb19/RTTkm4QmEyjsoPpZAWP+gaWiEmXSHFfZ7Q=; b=Z2jKMocohtrJt5WmLu1P2q/mdNOLMFa3UrcJ1H5zy6+Qwsm9yaAiB495lysHFtKS8C 6KaVuJV7+JRqXJKWstrdnll51OyuvIx12jNUIRf6pj+lHHrIa6OoYxm567lFlXspw96j TAYDj1bSKtuc2eGS68E4Ppwapqk617csZWENJCox+V5aJkRQGdBohiKlNONS2NDuWpXa szHdd5a7pZHH3RfM2B0EsyuHJwS+uNX5/FWmsmQqkY4uiiDz4mWRCgzvuTlfM8PtxEz+ 3RFg5oSFrIFL2TJddySXd24PiSzqh336r/E8KS3ja1V8KV46HL771YbrsGOIdO3iZ8xQ kHVw== MIME-Version: 1.0 X-Received: by 10.152.163.66 with SMTP id yg2mr6857785lab.38.1412716990404; Tue, 07 Oct 2014 14:23:10 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Tue, 7 Oct 2014 14:23:10 -0700 (PDT) In-Reply-To: References: <5424FEFA.2050008@gmail.com> Date: Tue, 7 Oct 2014 16:23:10 -0500 Message-ID: From: Behcet Sarikaya To: Satoru Matsushima Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/6G_qPhh0vxahXxfUFjkTkzXf-2g Cc: "dmm@ietf.org" Subject: Re: [DMM] Going forward with the DMM work items X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:23:14 -0000 Hi Satoru, Thank you for your comments on my draft, we will consider them in revising it next time. Let me say that I lived in Japan more than 7 years and I can probably state that I am a bit familiar with the culture. So my translation of your views is that these things happen in IETF and we should live with them. Yes, I agree that it happens but in IETF there is also freedom of expression. We can and we should point the discrepancies and there is nothing wrong to say that this (whatever it is) is wrong, people will respect you more if you do that. Regards, Behcet On Tue, Oct 7, 2014 at 2:31 AM, Satoru Matsushima wrote: > Hi Behcet, > > > On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya > wrote: >> >> >> I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi >> we proposed new approaches like SDN. >> > > Please don't get me wrong. My position hasn't been changed. BGP is used to > forwarding path management signaling. > > In your draft, XMPP is the protocol that has same role of BGP. Good idea, it > is a pub-sub system as same as BGP. You may need to define data model for > dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs > either xmpp, netconf, or forces. > > I suppose that you might want to adopt end-system VPN > (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data > modeling. (actually it is BGP. :-) And, as you may know that there is a > draft which mentions about use case of BGP in i2rs. > (http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases) > >> >> Having said that I don't think that the charter text on forwarding >> path and signaling is talking about the same thing. >> > > Interesting. What do you expect for the charter text? > Why not you ask Marco, Anthony and Alper to explain their thought? > > >> >> >> In DMM fir WiFi we also adopted the anycast discovery, what is wrong with >> that? > > > How do you find the anycast address itself? > > >> >> >> Yes I agree, maybe other techniques like AAA can be worked out. Why >> not do it as extensions? >> > > I suppose that it would be a part of enhanced anchoring work, isn't it? > > >> >> Really? My thinking was that vEPC does not need any involvement from >> MN because the prefix assigned to MN does not change. >> >> As I mentioned in my more recent mail, I think this item is based on >> 2102 solution proposals in which MN had to deal with many prefixes. >> >> Can you clarify which network nodes need exposure to MN mobility >> state? The ones on the path already know MN prefix, right? >> > > Quite not. I meant disclosing mobility information to network node that > likes such as BGP speaker. > > >> >> So you are saying that these three items gave you some good ideas to >> think about on how you can improve your solution, vEPC. >> > > In my view, the charter items work well to achieve vEPC architecture model, > yes. > More precisely, as the result of discussions which I had so far with many > dmm people, I have noticed some parts which the draft needs more work to > achieve the architecture model. > >> >> You are indicating that there is a major solution proposal, i.e. vEPC >> by you, but that can be improved here and there. >> >> You are missing the point that such a view point is not yet agreed by the >> group. > > > I know. So I am trying to express my thought, and then we can recognize > differences each other, and we can discuss. It's normal process in the ietf > I think. > >> >> >> Without such an agreement on the base, isn't it quite concerning what >> the WT's or DT's will do? >> >> My understanding is that the formation of WT's or DT's is another way >> of saying that we don't like all those solutions out there, we will >> design our own solutions to the above 3. > > > I guess wg management, who are responsible to establish dmm standard, expect > standardizing dmm solution would be very hard work because they find many > variants for it. In that situation, it would be reasonable that they appoint > some persons to lead the work. I really appreciate those persons who > volunteer to take that role to out consolidated solution. > > Cheers, > --satoru From nobody Tue Oct 7 14:53:51 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F311A00A3 for ; Tue, 7 Oct 2014 14:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hOZBfKJJwkn for ; Tue, 7 Oct 2014 14:53:47 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E86E41A6F1E for ; Tue, 7 Oct 2014 14:53:46 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id mk6so7280558lab.1 for ; Tue, 07 Oct 2014 14:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4YQGA7vaLJItca8A8vIO2urZpeXd9x7UmUBADSDHbk4=; b=W47IwgFS/cC2ZFmkZ2z0g0K/DhX6IwfIJpBVkuhqpWKMV90E4psZxTOfp4oV9RP/zj tbgb+H+ATu+rQmGexks9W7Mk+uQ80IzD9T1axBpAaGMi7RFhZKyMoKk2ysm626kXeaqn 5frf4fkXvbVmr9PP2E/nsWhUZifnnNKW55g0QYsaeIeh4Gfw3ffuh4mwih1J3Y/GCqkR tijyLOTmg/KB5lBbftbOduu+R+poaC40wzUl7hbu2Q4eym9FGmV9E2p5O31cAKTt19J1 o2B+x7ROwZCCb4miyjO5qEZPvTuxwA6zDkSVbZkRaQC4GAVlIubGxTT0ZsPLqsJrvQVt JZbQ== X-Received: by 10.112.26.103 with SMTP id k7mr6670580lbg.86.1412718825303; Tue, 07 Oct 2014 14:53:45 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:e10f:e7a6:7de3:f7dc? ([2001:1bc8:101:f101:e10f:e7a6:7de3:f7dc]) by mx.google.com with ESMTPSA id s8sm7084485las.29.2014.10.07.14.53.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 14:53:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: Date: Wed, 8 Oct 2014 00:53:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <543453FB.3000704@gmail.com> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/-81NjLtBb6tOzBVYPRGIMiY06Ww Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] addition to work team leads.. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 21:53:49 -0000 Behcet, On Oct 8, 2014, at 12:09 AM, Behcet Sarikaya wrote: > Hi Jouni, >=20 > I am confused. >=20 > On Tue, Oct 7, 2014 at 3:58 PM, Jouni Korhonen = wrote: >> Folks, >>=20 >> As announced, discussed and agreed in the Interim telco #3 Sri will = take the >> lead for "Distributed mobility management deployment models and = scenarios" >> work item. >=20 >=20 > When you asked us to comment on the charter, there was no deployment > models in the charter. We still have 4 work items. Deployment models is the first one of those. = That still does not imply we need to have an immediate milestone for = that work.=20 >=20 >=20 > Next, when we look at the milestones you just sent: I am aware of what I sent.. and assume the rest of the WG as well. >=20 >=20 > Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group > document. To be Proposed Standard. >=20 > Feb 2015 - Submit 'Forwarding path and signaling management' as a > working group document. To be Proposed Standard. >=20 > May 2015 - Submit 'Exposing mobility state to mobile nodes and = network > nodes' as a working group document(s). To be Proposed > Standard. >=20 > Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the = IESG. > To be Proposed Standard. >=20 > Nov 2015 - Submit 'Forwarding path and signaling management' = submitted > to the IESG. To be Proposed Standard. >=20 > Feb 2016 - Submit 'Exposing mobility state to mobile nodes and = network > nodes' submitted to the IESG. To be Proposed Standard. >=20 > again there are no deployment models. The proposed charter states: "The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. Possible new documents and milestones must still fit into the overall DMM charter scope as = outlined above." So if stuff that, _for_example_, comes out of what Sri is going to lead = starts to look good and in scope of the first work item, we can add a = milestone. > As you know there were a lot of concerns on the deployment models as > the deployment meant a specific protocol which does not exist in dmm > case. I am aware of concerns. I have a few myself. And I am happy someone is = willing to take a shot and try to make sense of it. >=20 > It seems like deployment models came to your mind after I sent a mail > asking about this. > BTW, that was a joke :-) Nope.. Chairs discussed that mid Sep, and Sri approached at the = beginning of Oct. - Jouni >=20 >=20 > Regards, >=20 > Behcet >>=20 >> - Jouni & Dapend >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Oct 8 04:38:42 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F7B1A02DA; Wed, 8 Oct 2014 04:38:40 -0700 (PDT) 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 4wvI5W4Yzy5T; Wed, 8 Oct 2014 04:38:38 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 124CA1A02DB; Wed, 8 Oct 2014 04:38:37 -0700 (PDT) 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 s98BcaVX001133; Wed, 8 Oct 2014 13:38:36 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id BAA56203877; Wed, 8 Oct 2014 13:39:40 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AD74B2030AE; Wed, 8 Oct 2014 13:39:40 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s98BcTkl025058; Wed, 8 Oct 2014 13:38:35 +0200 Message-ID: <54352235.7070304@gmail.com> Date: Wed, 08 Oct 2014 13:38:29 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: iesg@ietf.org References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> In-Reply-To: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/P3_pvR7DLsai8-m90qzO2JrQiZU Cc: dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) 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, 08 Oct 2014 11:38:40 -0000 Hello, I would like to comment on reusing prior work. Citing RFC3963 and RFC 5177 (v4 and v6 extensions to Mobile IP for network mobility) seems logical to me, since they're about Mobile IP too. Citing RFC 4888 and RFC 4889 (NEMO Route Optimization PS and solution analysis) seems logical to me, since the charter says "optimal" routes. Currently there is discussion in the DMM WG sketching potential solutions. When they're ready they'll certainly compare to these two sets of RFCs, and will have to answer same questions: does it work with Mobile Router (not just Mobile Host)? does it offer optimal routes? does it modify CN? is it subject to 'stalemate' situations (RFC4888 section 2.7)? does it involve multiple encapsulations? does it permit nestedness? Alex Le 03/10/2014 21:38, The IESG a �crit : > The Distributed Mobility Management (dmm) working group in the Internet > Area of the IETF is undergoing rechartering. The IESG has not made any > determination yet. The following draft charter was submitted, and is > provided for informational purposes only. Please send your comments to > the IESG mailing list (iesg at ietf.org) by 2014-10-13. > > Distributed Mobility Management (dmm) > ------------------------------------------------ > Current Status: Active WG > > Chairs: > Dapeng Liu > Jouni Korhonen > > Assigned Area Director: > Brian Haberman > > Mailing list > Address: dmm@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/dmm > Archive: http://www.ietf.org/mail-archive/web/dmm > > Charter: > > Mobility management solutions lie at the center of the wireless Internet > and enable mobile devices to partake in IP networks anytime and > anywhere. The IETF Distributed Mobility Management (DMM) working group > (WG) specifies solutions for IP networks so that traffic between mobile > and correspondent nodes can take an optimal route. DMM solutions aim for > transparency above the IP layer, including maintenance of active > transport level sessions when mobile hosts or mobile networks change > their point of attachment to the Internet. > > Wireless network deployments have traditionally relied on hierarchical > schemes that often lead to centralized deployment models, where a small > number of mobility anchors manage both mobility and reachability for a > mobile node. The DMM WG will consider the latest developments in mobile > networking research and operational practice (i.e. flattening network > architectures, the impact of virtualization, new deployment needs as > wireless access technologies evolve in the coming years) and will > describe how distributed mobility management addresses the new needs in > this area better than previously standardized solutions. > > A topic of particular focus will be mobility anchoring in this new > context, and the DMM working group is chartered to work on > maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC > 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new > approaches which capitalize on other protocols specified by the IETF. > For example, mobility management in a limited area, such as within an > autonomous system, is not strictly limited to mentioned IP mobility > protocols but can be any existing or a new protocol solution enabling > the movement of a mobile node such as routing protocols. When extending > protocols that are not based on Mobile IP, DMM solutions will have to be > reviewed by the corresponding WGs. > > IPv6 is assumed to be present in both the mobile host/router and the > access networks. DMM solutions are primarily targeted at IPv6 > deployments and are not required to support IPv4, in particular for the > case where private IPv4 addresses and/or NATs are used. DMM solutions > must maintain backward compatibility: If the network or the mobile > host/router does not support the distributed mobility management > protocol that should not prevent the mobile host/router gaining basic > access (i.e., nomadic) to the network. > > Contrary to earlier IP mobility protocols, mobility management signaling > paths and end-user traffic forwarding paths may differ. Further, > mobility-related functions may be located in separate network nodes. DMM > solutions should not distinguish between physical or virtualized > networking functions. Whenever applicable, clarifications and additional > features/capabilities for specific networking function deployment > models, e.g. in virtualized environments, are in-scope and encouraged. > Solutions may also specify the selection between the care-of addresses > and home address(es)/prefix(es) for different application use cases. > > The working group will produce both informational architectural and > standards track protocol solutions on the following work item topics. > > o Distributed mobility management deployment models and scenarios: > describe the target high-level network architectures and > deployment models where distributed mobility management > protocol solutions would apply. > > o Enhanced mobility anchoring: define protocol solutions for a > gateway and mobility anchor assignment and mid-session mobility > anchor switching that go beyond what has been specified, for > example, in RFC 6097, 6463, and 5142. Traffic steering > associated with the anchor switch is also in-scope if deemed > appropriate. > > o Forwarding path and signaling management: the function > that handles mobility management signaling interacts with the > DMM network elements for managing the forwarding state > associated with a mobile node's IP traffic. These two functions > may or may not be collocated. Furthermore, the forwarding state > may also be distributed into multiple network elements instead > of a single network element (e.g., anchor). Protocol extensions > or new protocols will be specified to allow the above mentioned > forwarding path and signalling management. > > o Exposing mobility state to mobile nodes and network nodes: > define solutions that allow, for example, mobile nodes to select > either a care-of address or a home address depending on an > application' mobility needs. In order to enable this > functionality, the network-side control functions and other > networking nodes must also be able to exchange appropriate > control information, as well as to the mobile nodes and their > applications. > > The working group may decide to extend the current milestones based on > the new information and knowledge gained during working on other > documents listed in the initial milestones. Possible new documents and > milestones must still fit into the overall DMM charter scope as outlined > above. > > Milestones: > > > From nobody Wed Oct 8 06:00:29 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 551561A03A3; Wed, 8 Oct 2014 06:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyJKdCiF9x7j; Wed, 8 Oct 2014 06:00:25 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43851A037F; Wed, 8 Oct 2014 06:00:24 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gq15so8261970lab.40 for ; Wed, 08 Oct 2014 06:00:22 -0700 (PDT) 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=23TSl6fbwCAiYLSmzYwY72Sz/ZRKI5w4zi78sysSR1g=; b=TCGxqSF3kdrQaxTeLRegfWUi6OxFD8Q7Jw3rI4X4nSI/PZ8fZUZF3jdK/NtNNLOgR3 7zI5TXhsQm9Je0Q4I21lmqTkO945W3lFmwwBF8OpgAjljjR/wPxsJKRKBz+OFMpQffSA t96jtM7v7FwukZgEFfRkgvhYBdTtMA5N6HTasbLCJ9dGiyd2a9nWesh07RrOImHRL0ZA 942f4MfysvuThegZpArYo0Uo+HM/+cGkx/Z9YiOTaA66at01T2j3iuqP94TISznc1oF1 u6ISmgenWVcmKd6EWCGqkR8vOJhKNe8sU5P8c3UzbmnvxliD8uZogQIACIrNaAfbdymg CNRg== X-Received: by 10.112.62.200 with SMTP id a8mr10621631lbs.34.1412773222788; Wed, 08 Oct 2014 06:00:22 -0700 (PDT) Received: from [84.231.133.183] (84-231-133-183.elisa-mobile.fi. [84.231.133.183]) by mx.google.com with ESMTPSA id n4sm15612lah.2.2014.10.08.06.00.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 06:00:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jouni X-Mailer: iPhone Mail (12A405) In-Reply-To: <54352235.7070304@gmail.com> Date: Wed, 8 Oct 2014 16:00:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com> References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <54352235.7070304@gmail.com> To: Alexandru Petrescu Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/7gyjCoNHd-pbYy0X_l1Pnk2kGHI Cc: "iesg@ietf.org" , dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) 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, 08 Oct 2014 13:00:28 -0000 Alex,=20 Do you have a specific change to the text in mind? The charter text uses sys= tematically "mobile host/router" to make sure mobile routers are not forgott= en. However, charter also allows solutions that are not specifically tailore= d to mobile routers.=20 Jouni --=20 Jouni Korhonen Broadcom (Sent from my mobile..) > Alexandru Petrescu kirjoitti 8.10.2014 kell= o 14.38: >=20 > Hello, >=20 > I would like to comment on reusing prior work. >=20 > Citing RFC3963 and RFC 5177 (v4 and v6 extensions to Mobile IP for network= mobility) seems logical to me, since they're about Mobile IP too. >=20 > Citing RFC 4888 and RFC 4889 (NEMO Route Optimization PS and solution anal= ysis) seems logical to me, since the charter says "optimal" routes. >=20 > Currently there is discussion in the DMM WG sketching potential solutions.= When they're ready they'll certainly compare to these two sets of RFCs, an= d will have to answer same questions: does it work with Mobile Router (not j= ust Mobile Host)? does it offer optimal routes? does it modify CN? is it s= ubject to 'stalemate' situations (RFC4888 section 2.7)? does it involve mul= tiple encapsulations? does it permit nestedness? >=20 > Alex >=20 > Le 03/10/2014 21:38, The IESG a =C3=A9crit : >> The Distributed Mobility Management (dmm) working group in the Internet >> Area of the IETF is undergoing rechartering. The IESG has not made any >> determination yet. The following draft charter was submitted, and is >> provided for informational purposes only. Please send your comments to >> the IESG mailing list (iesg at ietf.org) by 2014-10-13. >>=20 >> Distributed Mobility Management (dmm) >> ------------------------------------------------ >> Current Status: Active WG >>=20 >> Chairs: >> Dapeng Liu >> Jouni Korhonen >>=20 >> Assigned Area Director: >> Brian Haberman >>=20 >> Mailing list >> Address: dmm@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/dmm >> Archive: http://www.ietf.org/mail-archive/web/dmm >>=20 >> Charter: >>=20 >> Mobility management solutions lie at the center of the wireless Internet >> and enable mobile devices to partake in IP networks anytime and >> anywhere. The IETF Distributed Mobility Management (DMM) working group >> (WG) specifies solutions for IP networks so that traffic between mobile >> and correspondent nodes can take an optimal route. DMM solutions aim for >> transparency above the IP layer, including maintenance of active >> transport level sessions when mobile hosts or mobile networks change >> their point of attachment to the Internet. >>=20 >> Wireless network deployments have traditionally relied on hierarchical >> schemes that often lead to centralized deployment models, where a small >> number of mobility anchors manage both mobility and reachability for a >> mobile node. The DMM WG will consider the latest developments in mobile >> networking research and operational practice (i.e. flattening network >> architectures, the impact of virtualization, new deployment needs as >> wireless access technologies evolve in the coming years) and will >> describe how distributed mobility management addresses the new needs in >> this area better than previously standardized solutions. >>=20 >> A topic of particular focus will be mobility anchoring in this new >> context, and the DMM working group is chartered to work on >> maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC >> 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new >> approaches which capitalize on other protocols specified by the IETF. >> For example, mobility management in a limited area, such as within an >> autonomous system, is not strictly limited to mentioned IP mobility >> protocols but can be any existing or a new protocol solution enabling >> the movement of a mobile node such as routing protocols. When extending >> protocols that are not based on Mobile IP, DMM solutions will have to be >> reviewed by the corresponding WGs. >>=20 >> IPv6 is assumed to be present in both the mobile host/router and the >> access networks. DMM solutions are primarily targeted at IPv6 >> deployments and are not required to support IPv4, in particular for the >> case where private IPv4 addresses and/or NATs are used. DMM solutions >> must maintain backward compatibility: If the network or the mobile >> host/router does not support the distributed mobility management >> protocol that should not prevent the mobile host/router gaining basic >> access (i.e., nomadic) to the network. >>=20 >> Contrary to earlier IP mobility protocols, mobility management signaling >> paths and end-user traffic forwarding paths may differ. Further, >> mobility-related functions may be located in separate network nodes. DMM >> solutions should not distinguish between physical or virtualized >> networking functions. Whenever applicable, clarifications and additional >> features/capabilities for specific networking function deployment >> models, e.g. in virtualized environments, are in-scope and encouraged. >> Solutions may also specify the selection between the care-of addresses >> and home address(es)/prefix(es) for different application use cases. >>=20 >> The working group will produce both informational architectural and >> standards track protocol solutions on the following work item topics. >>=20 >> o Distributed mobility management deployment models and scenarios: >> describe the target high-level network architectures and >> deployment models where distributed mobility management >> protocol solutions would apply. >>=20 >> o Enhanced mobility anchoring: define protocol solutions for a >> gateway and mobility anchor assignment and mid-session mobility >> anchor switching that go beyond what has been specified, for >> example, in RFC 6097, 6463, and 5142. Traffic steering >> associated with the anchor switch is also in-scope if deemed >> appropriate. >>=20 >> o Forwarding path and signaling management: the function >> that handles mobility management signaling interacts with the >> DMM network elements for managing the forwarding state >> associated with a mobile node's IP traffic. These two functions >> may or may not be collocated. Furthermore, the forwarding state >> may also be distributed into multiple network elements instead >> of a single network element (e.g., anchor). Protocol extensions >> or new protocols will be specified to allow the above mentioned >> forwarding path and signalling management. >>=20 >> o Exposing mobility state to mobile nodes and network nodes: >> define solutions that allow, for example, mobile nodes to select >> either a care-of address or a home address depending on an >> application' mobility needs. In order to enable this >> functionality, the network-side control functions and other >> networking nodes must also be able to exchange appropriate >> control information, as well as to the mobile nodes and their >> applications. >>=20 >> The working group may decide to extend the current milestones based on >> the new information and knowledge gained during working on other >> documents listed in the initial milestones. Possible new documents and >> milestones must still fit into the overall DMM charter scope as outlined >> above. >>=20 >> Milestones: >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Oct 8 07:24:15 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6B61A1B1F; Wed, 8 Oct 2014 07:24:09 -0700 (PDT) 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 9smYH5Le1elG; Wed, 8 Oct 2014 07:24:06 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F88A1A1B2B; Wed, 8 Oct 2014 07:23:59 -0700 (PDT) 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 s98ENvZa002842; Wed, 8 Oct 2014 16:23:57 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 586A9209004; Wed, 8 Oct 2014 16:25:02 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 3FE1D208F71; Wed, 8 Oct 2014 16:25:02 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s98ENq6e009544; Wed, 8 Oct 2014 16:23:57 +0200 Message-ID: <543548F8.7060403@gmail.com> Date: Wed, 08 Oct 2014 16:23:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Jouni References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <54352235.7070304@gmail.com> <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com> In-Reply-To: <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/rPQos0SpZhJIkOxCBCPQm2vCevw Cc: "iesg@ietf.org" , dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) 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, 08 Oct 2014 14:24:09 -0000 Jouni, Thank you for the message. Here are the modifications: Where the Charter mentions "Mobile IPv6 protocol family (RFC x, y, z)" it should also mention RFC 3963 and RFC 5177. (these RFCs were mentioned in past versions but disappeared somehow). Where the Charter says "The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. Possible new documents and milestones must still fit into the overall DMM charter scope as outlined above. Milestones:[empty]" Please clarify that "initial milestones" is "RFC 4888, RFC 4889, draft-ietf-dmm-best-practices-gap-analysis-08"). Alex Le 08/10/2014 15:00, Jouni a écrit : > Alex, > > Do you have a specific change to the text in mind? The charter text > uses systematically "mobile host/router" to make sure mobile routers > are not forgotten. However, charter also allows solutions that are > not specifically tailored to mobile routers. > > Jouni > From nobody Wed Oct 8 07:25:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C501A1B26; Wed, 8 Oct 2014 07:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.987 X-Spam-Level: X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 Zsd50ZccEggq; Wed, 8 Oct 2014 07:25:48 -0700 (PDT) Received: from blv-mbsout-01.boeing.com (blv-mbsout-01.boeing.com [130.76.32.231]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2781A1B1F; Wed, 8 Oct 2014 07:25:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s98EPmdL027775; Wed, 8 Oct 2014 07:25:48 -0700 Received: from XCH-BLV-505.nw.nos.boeing.com (xch-blv-505.nw.nos.boeing.com [130.247.25.195]) by blv-mbsout-01.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s98EPeLm027732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Wed, 8 Oct 2014 07:25:40 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.62]) by XCH-BLV-505.nw.nos.boeing.com ([169.254.5.191]) with mapi id 14.03.0181.006; Wed, 8 Oct 2014 07:25:40 -0700 From: "Templin, Fred L" To: Jouni , Alexandru Petrescu Thread-Topic: [DMM] WG Review: Distributed Mobility Management (dmm) Thread-Index: AQHP4uxwgZMiI8yKjk6iNPqATAL5xZwmnxkA//+gelA= Date: Wed, 8 Oct 2014 14:25:39 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D3A660@XCH-BLV-504.nw.nos.boeing.com> References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <54352235.7070304@gmail.com> <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com> In-Reply-To: <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/R9a_Pfb6JeWvYsyaL7_gspL299E Cc: "iesg@ietf.org" , dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) 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, 08 Oct 2014 14:25:51 -0000 RldJVywgQUVSTyBpcyBhIG1vYmlsZSByb3V0ZXIgc29sdXRpb24uIEJ1dCwgaXQgaXMgZWFzeSB0 byBtYWtlIGFuIEFFUk8gbW9iaWxlIHJvdXRlcg0KYWN0IGxpa2UgYSBtb2JpbGUgaG9zdC4gQ2Vs bCBwaG9uZXMsIHRhYmxldHMsIGxhcHRvcHMsIGV0Yy4gYXJlIGFsbCBnb29kIGNhbmRpZGF0ZSBB RVJPDQptb2JpbGUgcm91dGVyL2hvc3RzLiAoQWlycGxhbmVzLCBhdXRvbW9iaWxlcywgb2NlYW4t Z29pbmcgdmVzc2VscywgZXRjLiBhcmUgYWxzbyBnb29kDQpjYW5kaWRhdGUgQUVSTyBtb2JpbGUg cm91dGVycy4pDQoNClRoYW5rcyAtIEZyZWQNCmZyZWQubC50ZW1wbGluQGJvZWluZy5jb20NCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbW0gW21haWx0bzpkbW0tYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvdW5pDQo+IFNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAwOCwgMjAxNCA2OjAwIEFNDQo+IFRvOiBBbGV4YW5kcnUgUGV0cmVzY3UNCj4gQ2M6IGll c2dAaWV0Zi5vcmc7IGRtbSBXRw0KPiBTdWJqZWN0OiBSZTogW0RNTV0gV0cgUmV2aWV3OiBEaXN0 cmlidXRlZCBNb2JpbGl0eSBNYW5hZ2VtZW50IChkbW0pDQo+IA0KPiBBbGV4LA0KPiANCj4gRG8g eW91IGhhdmUgYSBzcGVjaWZpYyBjaGFuZ2UgdG8gdGhlIHRleHQgaW4gbWluZD8gVGhlIGNoYXJ0 ZXIgdGV4dCB1c2VzIHN5c3RlbWF0aWNhbGx5ICJtb2JpbGUgaG9zdC9yb3V0ZXIiIHRvIG1ha2Ug c3VyZSBtb2JpbGUNCj4gcm91dGVycyBhcmUgbm90IGZvcmdvdHRlbi4gSG93ZXZlciwgY2hhcnRl ciBhbHNvIGFsbG93cyBzb2x1dGlvbnMgdGhhdCBhcmUgbm90IHNwZWNpZmljYWxseSB0YWlsb3Jl ZCB0byBtb2JpbGUgcm91dGVycy4NCj4gDQo+IEpvdW5pDQo+IA0KPiAtLQ0KPiBKb3VuaSBLb3Jo b25lbg0KPiBCcm9hZGNvbQ0KPiANCj4gKFNlbnQgZnJvbSBteSBtb2JpbGUuLikNCj4gDQo+ID4g QWxleGFuZHJ1IFBldHJlc2N1IDxhbGV4YW5kcnUucGV0cmVzY3VAZ21haWwuY29tPiBraXJqb2l0 dGkgOC4xMC4yMDE0IGtlbGxvIDE0LjM4Og0KPiA+DQo+ID4gSGVsbG8sDQo+ID4NCj4gPiBJIHdv dWxkIGxpa2UgdG8gY29tbWVudCBvbiByZXVzaW5nIHByaW9yIHdvcmsuDQo+ID4NCj4gPiBDaXRp bmcgUkZDMzk2MyBhbmQgUkZDIDUxNzcgKHY0IGFuZCB2NiBleHRlbnNpb25zIHRvIE1vYmlsZSBJ UCBmb3IgbmV0d29yayBtb2JpbGl0eSkgc2VlbXMgbG9naWNhbCB0byBtZSwgc2luY2UgdGhleSdy ZSBhYm91dA0KPiBNb2JpbGUgSVAgdG9vLg0KPiA+DQo+ID4gQ2l0aW5nIFJGQyA0ODg4IGFuZCBS RkMgNDg4OSAoTkVNTyBSb3V0ZSBPcHRpbWl6YXRpb24gUFMgYW5kIHNvbHV0aW9uIGFuYWx5c2lz KSBzZWVtcyBsb2dpY2FsIHRvIG1lLCBzaW5jZSB0aGUgY2hhcnRlciBzYXlzDQo+ICJvcHRpbWFs IiByb3V0ZXMuDQo+ID4NCj4gPiBDdXJyZW50bHkgdGhlcmUgaXMgZGlzY3Vzc2lvbiBpbiB0aGUg RE1NIFdHIHNrZXRjaGluZyBwb3RlbnRpYWwgc29sdXRpb25zLiAgV2hlbiB0aGV5J3JlIHJlYWR5 IHRoZXknbGwgY2VydGFpbmx5IGNvbXBhcmUgdG8gdGhlc2UNCj4gdHdvIHNldHMgb2YgUkZDcywg YW5kIHdpbGwgaGF2ZSB0byBhbnN3ZXIgc2FtZSBxdWVzdGlvbnM6IGRvZXMgaXQgd29yayB3aXRo IE1vYmlsZSBSb3V0ZXIgKG5vdCBqdXN0IE1vYmlsZSBIb3N0KT8gIGRvZXMgaXQgb2ZmZXINCj4g b3B0aW1hbCByb3V0ZXM/IGRvZXMgaXQgbW9kaWZ5IENOPyAgaXMgaXQgc3ViamVjdCB0byAnc3Rh bGVtYXRlJyBzaXR1YXRpb25zIChSRkM0ODg4IHNlY3Rpb24gMi43KT8gIGRvZXMgaXQgaW52b2x2 ZSBtdWx0aXBsZQ0KPiBlbmNhcHN1bGF0aW9ucz8gIGRvZXMgaXQgcGVybWl0IG5lc3RlZG5lc3M/ DQo+ID4NCj4gPiBBbGV4DQo+ID4NCj4gPiBMZSAwMy8xMC8yMDE0IDIxOjM4LCBUaGUgSUVTRyBh IMOpY3JpdCA6DQo+ID4+IFRoZSBEaXN0cmlidXRlZCBNb2JpbGl0eSBNYW5hZ2VtZW50IChkbW0p IHdvcmtpbmcgZ3JvdXAgaW4gdGhlIEludGVybmV0DQo+ID4+IEFyZWEgb2YgdGhlIElFVEYgaXMg dW5kZXJnb2luZyByZWNoYXJ0ZXJpbmcuIFRoZSBJRVNHIGhhcyBub3QgbWFkZSBhbnkNCj4gPj4g ZGV0ZXJtaW5hdGlvbiB5ZXQuIFRoZSBmb2xsb3dpbmcgZHJhZnQgY2hhcnRlciB3YXMgc3VibWl0 dGVkLCBhbmQgaXMNCj4gPj4gcHJvdmlkZWQgZm9yIGluZm9ybWF0aW9uYWwgcHVycG9zZXMgb25s eS4gUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0bw0KPiA+PiB0aGUgSUVTRyBtYWlsaW5nIGxp c3QgKGllc2cgYXQgaWV0Zi5vcmcpIGJ5IDIwMTQtMTAtMTMuDQo+ID4+DQo+ID4+IERpc3RyaWJ1 dGVkIE1vYmlsaXR5IE1hbmFnZW1lbnQgKGRtbSkNCj4gPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IEN1cnJlbnQgU3RhdHVzOiBBY3RpdmUg V0cNCj4gPj4NCj4gPj4gQ2hhaXJzOg0KPiA+PiAgIERhcGVuZyBMaXUgPGxpdWRhcGVuZ0BjaGlu YW1vYmlsZS5jb20+DQo+ID4+ICAgSm91bmkgS29yaG9uZW4gPGpvdW5pLm5vc3BhbUBnbWFpbC5j b20+DQo+ID4+DQo+ID4+IEFzc2lnbmVkIEFyZWEgRGlyZWN0b3I6DQo+ID4+ICAgQnJpYW4gSGFi ZXJtYW4gPGJyaWFuQGlubm92YXRpb25zbGFiLm5ldD4NCj4gPj4NCj4gPj4gTWFpbGluZyBsaXN0 DQo+ID4+ICAgQWRkcmVzczogZG1tQGlldGYub3JnDQo+ID4+ICAgVG8gU3Vic2NyaWJlOiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPiA+PiAgIEFyY2hpdmU6IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kbW0NCj4gPj4NCj4gPj4gQ2hhcnRl cjoNCj4gPj4NCj4gPj4gTW9iaWxpdHkgbWFuYWdlbWVudCBzb2x1dGlvbnMgbGllIGF0IHRoZSBj ZW50ZXIgb2YgdGhlIHdpcmVsZXNzIEludGVybmV0DQo+ID4+IGFuZCBlbmFibGUgbW9iaWxlIGRl dmljZXMgdG8gcGFydGFrZSBpbiBJUCBuZXR3b3JrcyBhbnl0aW1lIGFuZA0KPiA+PiBhbnl3aGVy ZS4gVGhlIElFVEYgRGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCAoRE1NKSB3b3JraW5n IGdyb3VwDQo+ID4+IChXRykgc3BlY2lmaWVzIHNvbHV0aW9ucyBmb3IgSVAgbmV0d29ya3Mgc28g dGhhdCB0cmFmZmljIGJldHdlZW4gbW9iaWxlDQo+ID4+IGFuZCBjb3JyZXNwb25kZW50IG5vZGVz IGNhbiB0YWtlIGFuIG9wdGltYWwgcm91dGUuIERNTSBzb2x1dGlvbnMgYWltIGZvcg0KPiA+PiB0 cmFuc3BhcmVuY3kgYWJvdmUgdGhlIElQIGxheWVyLCBpbmNsdWRpbmcgbWFpbnRlbmFuY2Ugb2Yg YWN0aXZlDQo+ID4+IHRyYW5zcG9ydCBsZXZlbCBzZXNzaW9ucyB3aGVuIG1vYmlsZSBob3N0cyBv ciBtb2JpbGUgbmV0d29ya3MgY2hhbmdlDQo+ID4+IHRoZWlyIHBvaW50IG9mIGF0dGFjaG1lbnQg dG8gdGhlIEludGVybmV0Lg0KPiA+Pg0KPiA+PiBXaXJlbGVzcyBuZXR3b3JrIGRlcGxveW1lbnRz IGhhdmUgdHJhZGl0aW9uYWxseSByZWxpZWQgb24gaGllcmFyY2hpY2FsDQo+ID4+IHNjaGVtZXMg dGhhdCBvZnRlbiBsZWFkIHRvIGNlbnRyYWxpemVkIGRlcGxveW1lbnQgbW9kZWxzLCB3aGVyZSBh IHNtYWxsDQo+ID4+IG51bWJlciBvZiBtb2JpbGl0eSBhbmNob3JzIG1hbmFnZSBib3RoIG1vYmls aXR5IGFuZCByZWFjaGFiaWxpdHkgZm9yIGENCj4gPj4gbW9iaWxlIG5vZGUuIFRoZSBETU0gV0cg d2lsbCBjb25zaWRlciB0aGUgbGF0ZXN0IGRldmVsb3BtZW50cyBpbiBtb2JpbGUNCj4gPj4gbmV0 d29ya2luZyByZXNlYXJjaCBhbmQgb3BlcmF0aW9uYWwgcHJhY3RpY2UgKGkuZS4gZmxhdHRlbmlu ZyBuZXR3b3JrDQo+ID4+IGFyY2hpdGVjdHVyZXMsIHRoZSBpbXBhY3Qgb2YgdmlydHVhbGl6YXRp b24sIG5ldyBkZXBsb3ltZW50IG5lZWRzIGFzDQo+ID4+IHdpcmVsZXNzIGFjY2VzcyB0ZWNobm9s b2dpZXMgZXZvbHZlIGluIHRoZSBjb21pbmcgeWVhcnMpIGFuZCB3aWxsDQo+ID4+IGRlc2NyaWJl IGhvdyBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IGFkZHJlc3NlcyB0aGUgbmV3IG5l ZWRzIGluDQo+ID4+IHRoaXMgYXJlYSBiZXR0ZXIgdGhhbiBwcmV2aW91c2x5IHN0YW5kYXJkaXpl ZCBzb2x1dGlvbnMuDQo+ID4+DQo+ID4+IEEgdG9waWMgb2YgcGFydGljdWxhciBmb2N1cyB3aWxs IGJlIG1vYmlsaXR5IGFuY2hvcmluZyBpbiB0aGlzIG5ldw0KPiA+PiBjb250ZXh0LCBhbmQgdGhl IERNTSB3b3JraW5nIGdyb3VwIGlzIGNoYXJ0ZXJlZCB0byB3b3JrIG9uDQo+ID4+IG1haW50ZW5h bmNlLW9yaWVudGVkIGV4dGVuc2lvbnMgb2YgdGhlIE1vYmlsZSBJUHY2IHByb3RvY29sIGZhbWls eSAoUkZDDQo+ID4+IDUyMTMsIFJGQyA1ODQ0LCBSRkMgNTU1NSwgUkZDIDU1NjgsIGFuZCBSRkMg NjI3NSkgYXMgd2VsbCBhcyBuZXcNCj4gPj4gYXBwcm9hY2hlcyB3aGljaCBjYXBpdGFsaXplIG9u IG90aGVyIHByb3RvY29scyBzcGVjaWZpZWQgYnkgdGhlIElFVEYuDQo+ID4+IEZvciBleGFtcGxl LCBtb2JpbGl0eSBtYW5hZ2VtZW50IGluIGEgbGltaXRlZCBhcmVhLCBzdWNoIGFzIHdpdGhpbiBh bg0KPiA+PiBhdXRvbm9tb3VzIHN5c3RlbSwgaXMgbm90IHN0cmljdGx5IGxpbWl0ZWQgdG8gbWVu dGlvbmVkIElQIG1vYmlsaXR5DQo+ID4+IHByb3RvY29scyBidXQgY2FuIGJlIGFueSBleGlzdGlu ZyBvciBhIG5ldyBwcm90b2NvbCBzb2x1dGlvbiBlbmFibGluZw0KPiA+PiB0aGUgbW92ZW1lbnQg b2YgYSBtb2JpbGUgbm9kZSBzdWNoIGFzIHJvdXRpbmcgcHJvdG9jb2xzLiBXaGVuIGV4dGVuZGlu Zw0KPiA+PiBwcm90b2NvbHMgdGhhdCBhcmUgbm90IGJhc2VkIG9uIE1vYmlsZSBJUCwgRE1NIHNv bHV0aW9ucyB3aWxsIGhhdmUgdG8gYmUNCj4gPj4gcmV2aWV3ZWQgYnkgdGhlIGNvcnJlc3BvbmRp bmcgV0dzLg0KPiA+Pg0KPiA+PiBJUHY2IGlzIGFzc3VtZWQgdG8gYmUgcHJlc2VudCBpbiBib3Ro IHRoZSBtb2JpbGUgaG9zdC9yb3V0ZXIgYW5kIHRoZQ0KPiA+PiBhY2Nlc3MgbmV0d29ya3MuIERN TSBzb2x1dGlvbnMgYXJlIHByaW1hcmlseSB0YXJnZXRlZCBhdCBJUHY2DQo+ID4+IGRlcGxveW1l bnRzIGFuZCBhcmUgbm90IHJlcXVpcmVkIHRvIHN1cHBvcnQgSVB2NCwgaW4gcGFydGljdWxhciBm b3IgdGhlDQo+ID4+IGNhc2Ugd2hlcmUgcHJpdmF0ZSBJUHY0IGFkZHJlc3NlcyBhbmQvb3IgTkFU cyBhcmUgdXNlZC4gRE1NIHNvbHV0aW9ucw0KPiA+PiBtdXN0IG1haW50YWluIGJhY2t3YXJkIGNv bXBhdGliaWxpdHk6ICBJZiB0aGUgbmV0d29yayBvciB0aGUgbW9iaWxlDQo+ID4+IGhvc3Qvcm91 dGVyIGRvZXMgbm90IHN1cHBvcnQgdGhlIGRpc3RyaWJ1dGVkIG1vYmlsaXR5IG1hbmFnZW1lbnQN Cj4gPj4gcHJvdG9jb2wgdGhhdCBzaG91bGQgbm90IHByZXZlbnQgdGhlIG1vYmlsZSBob3N0L3Jv dXRlciBnYWluaW5nIGJhc2ljDQo+ID4+IGFjY2VzcyAoaS5lLiwgbm9tYWRpYykgdG8gdGhlIG5l dHdvcmsuDQo+ID4+DQo+ID4+IENvbnRyYXJ5IHRvIGVhcmxpZXIgSVAgbW9iaWxpdHkgcHJvdG9j b2xzLCBtb2JpbGl0eSBtYW5hZ2VtZW50IHNpZ25hbGluZw0KPiA+PiBwYXRocyBhbmQgZW5kLXVz ZXIgdHJhZmZpYyBmb3J3YXJkaW5nIHBhdGhzIG1heSBkaWZmZXIuIEZ1cnRoZXIsDQo+ID4+IG1v YmlsaXR5LXJlbGF0ZWQgZnVuY3Rpb25zIG1heSBiZSBsb2NhdGVkIGluIHNlcGFyYXRlIG5ldHdv cmsgbm9kZXMuIERNTQ0KPiA+PiBzb2x1dGlvbnMgc2hvdWxkIG5vdCBkaXN0aW5ndWlzaCBiZXR3 ZWVuIHBoeXNpY2FsIG9yIHZpcnR1YWxpemVkDQo+ID4+IG5ldHdvcmtpbmcgZnVuY3Rpb25zLiBX aGVuZXZlciBhcHBsaWNhYmxlLCBjbGFyaWZpY2F0aW9ucyBhbmQgYWRkaXRpb25hbA0KPiA+PiBm ZWF0dXJlcy9jYXBhYmlsaXRpZXMgZm9yIHNwZWNpZmljIG5ldHdvcmtpbmcgZnVuY3Rpb24gZGVw bG95bWVudA0KPiA+PiBtb2RlbHMsIGUuZy4gaW4gdmlydHVhbGl6ZWQgZW52aXJvbm1lbnRzLCBh cmUgaW4tc2NvcGUgYW5kIGVuY291cmFnZWQuDQo+ID4+IFNvbHV0aW9ucyBtYXkgYWxzbyBzcGVj aWZ5IHRoZSBzZWxlY3Rpb24gYmV0d2VlbiB0aGUgY2FyZS1vZiBhZGRyZXNzZXMNCj4gPj4gYW5k IGhvbWUgYWRkcmVzcyhlcykvcHJlZml4KGVzKSBmb3IgZGlmZmVyZW50IGFwcGxpY2F0aW9uIHVz ZSBjYXNlcy4NCj4gPj4NCj4gPj4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBwcm9kdWNlIGJvdGgg aW5mb3JtYXRpb25hbCBhcmNoaXRlY3R1cmFsIGFuZA0KPiA+PiBzdGFuZGFyZHMgdHJhY2sgcHJv dG9jb2wgc29sdXRpb25zIG9uIHRoZSBmb2xsb3dpbmcgd29yayBpdGVtIHRvcGljcy4NCj4gPj4N Cj4gPj4gICAgICAgbyBEaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50IGRlcGxveW1lbnQg bW9kZWxzIGFuZCBzY2VuYXJpb3M6DQo+ID4+ICAgICAgICAgZGVzY3JpYmUgdGhlIHRhcmdldCBo aWdoLWxldmVsIG5ldHdvcmsgYXJjaGl0ZWN0dXJlcyBhbmQNCj4gPj4gICAgICAgICBkZXBsb3lt ZW50IG1vZGVscyB3aGVyZSBkaXN0cmlidXRlZCBtb2JpbGl0eSBtYW5hZ2VtZW50DQo+ID4+ICAg ICAgICAgcHJvdG9jb2wgc29sdXRpb25zIHdvdWxkIGFwcGx5Lg0KPiA+Pg0KPiA+PiAgICAgICBv IEVuaGFuY2VkIG1vYmlsaXR5IGFuY2hvcmluZzogZGVmaW5lIHByb3RvY29sIHNvbHV0aW9ucyBm b3IgYQ0KPiA+PiAgICAgICAgIGdhdGV3YXkgYW5kIG1vYmlsaXR5IGFuY2hvciBhc3NpZ25tZW50 IGFuZCBtaWQtc2Vzc2lvbiBtb2JpbGl0eQ0KPiA+PiAgICAgICAgIGFuY2hvciBzd2l0Y2hpbmcg dGhhdCBnbyBiZXlvbmQgd2hhdCBoYXMgYmVlbiBzcGVjaWZpZWQsIGZvcg0KPiA+PiAgICAgICAg IGV4YW1wbGUsIGluIFJGQyA2MDk3LCA2NDYzLCBhbmQgNTE0Mi4gVHJhZmZpYyBzdGVlcmluZw0K PiA+PiAgICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgYW5jaG9yIHN3aXRjaCBpcyBhbHNvIGlu LXNjb3BlIGlmIGRlZW1lZA0KPiA+PiAgICAgICAgIGFwcHJvcHJpYXRlLg0KPiA+Pg0KPiA+PiAg ICAgICBvIEZvcndhcmRpbmcgcGF0aCBhbmQgc2lnbmFsaW5nIG1hbmFnZW1lbnQ6IHRoZSBmdW5j dGlvbg0KPiA+PiAgICAgICAgIHRoYXQgaGFuZGxlcyBtb2JpbGl0eSBtYW5hZ2VtZW50IHNpZ25h bGluZyBpbnRlcmFjdHMgd2l0aCB0aGUNCj4gPj4gICAgICAgICBETU0gbmV0d29yayBlbGVtZW50 cyBmb3IgbWFuYWdpbmcgdGhlIGZvcndhcmRpbmcgc3RhdGUNCj4gPj4gICAgICAgICBhc3NvY2lh dGVkIHdpdGggYSBtb2JpbGUgbm9kZSdzIElQIHRyYWZmaWMuICBUaGVzZSB0d28gZnVuY3Rpb25z DQo+ID4+ICAgICAgICAgbWF5IG9yIG1heSBub3QgYmUgY29sbG9jYXRlZC4gRnVydGhlcm1vcmUs IHRoZSBmb3J3YXJkaW5nIHN0YXRlDQo+ID4+ICAgICAgICAgbWF5IGFsc28gYmUgZGlzdHJpYnV0 ZWQgaW50byBtdWx0aXBsZSBuZXR3b3JrIGVsZW1lbnRzIGluc3RlYWQNCj4gPj4gICAgICAgICBv ZiBhIHNpbmdsZSBuZXR3b3JrIGVsZW1lbnQgKGUuZy4sIGFuY2hvcikuICBQcm90b2NvbCBleHRl bnNpb25zDQo+ID4+ICAgICAgICAgb3IgbmV3IHByb3RvY29scyB3aWxsIGJlIHNwZWNpZmllZCB0 byBhbGxvdyB0aGUgYWJvdmUgbWVudGlvbmVkDQo+ID4+ICAgICAgICAgZm9yd2FyZGluZyBwYXRo IGFuZCBzaWduYWxsaW5nIG1hbmFnZW1lbnQuDQo+ID4+DQo+ID4+ICAgICAgIG8gRXhwb3Npbmcg bW9iaWxpdHkgc3RhdGUgdG8gbW9iaWxlIG5vZGVzIGFuZCBuZXR3b3JrIG5vZGVzOg0KPiA+PiAg ICAgICAgIGRlZmluZSBzb2x1dGlvbnMgdGhhdCBhbGxvdywgZm9yIGV4YW1wbGUsIG1vYmlsZSBu b2RlcyB0byBzZWxlY3QNCj4gPj4gICAgICAgICBlaXRoZXIgYSBjYXJlLW9mIGFkZHJlc3Mgb3Ig YSBob21lIGFkZHJlc3MgZGVwZW5kaW5nIG9uIGFuDQo+ID4+ICAgICAgICAgYXBwbGljYXRpb24n IG1vYmlsaXR5IG5lZWRzLiBJbiBvcmRlciB0byBlbmFibGUgdGhpcw0KPiA+PiAgICAgICAgIGZ1 bmN0aW9uYWxpdHksIHRoZSBuZXR3b3JrLXNpZGUgY29udHJvbCBmdW5jdGlvbnMgYW5kIG90aGVy DQo+ID4+ICAgICAgICAgbmV0d29ya2luZyBub2RlcyBtdXN0IGFsc28gYmUgYWJsZSB0byBleGNo YW5nZSBhcHByb3ByaWF0ZQ0KPiA+PiAgICAgICAgIGNvbnRyb2wgaW5mb3JtYXRpb24sIGFzIHdl bGwgYXMgdG8gdGhlIG1vYmlsZSBub2RlcyBhbmQgdGhlaXINCj4gPj4gICAgICAgICBhcHBsaWNh dGlvbnMuDQo+ID4+DQo+ID4+IFRoZSB3b3JraW5nIGdyb3VwIG1heSBkZWNpZGUgdG8gZXh0ZW5k IHRoZSBjdXJyZW50IG1pbGVzdG9uZXMgYmFzZWQgb24NCj4gPj4gdGhlIG5ldyBpbmZvcm1hdGlv biBhbmQga25vd2xlZGdlIGdhaW5lZCBkdXJpbmcgd29ya2luZyBvbiBvdGhlcg0KPiA+PiBkb2N1 bWVudHMgbGlzdGVkIGluIHRoZSBpbml0aWFsIG1pbGVzdG9uZXMuIFBvc3NpYmxlIG5ldyBkb2N1 bWVudHMgYW5kDQo+ID4+IG1pbGVzdG9uZXMgbXVzdCBzdGlsbCBmaXQgaW50byB0aGUgb3ZlcmFs bCBETU0gY2hhcnRlciBzY29wZSBhcyBvdXRsaW5lZA0KPiA+PiBhYm92ZS4NCj4gPj4NCj4gPj4g TWlsZXN0b25lczoNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBkbW0gbWFpbGluZyBsaXN0DQo+ID4gZG1tQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRtbSBtYWls aW5nIGxpc3QNCj4gZG1tQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG1tDQo= From nobody Wed Oct 8 10:44:26 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E4A1A912B; Wed, 8 Oct 2014 10:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rApRHQVbJvxL; Wed, 8 Oct 2014 10:44:23 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A149E1A6FD3; Wed, 8 Oct 2014 10:44:22 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id w7so8570294lbi.37 for ; Wed, 08 Oct 2014 10:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Mv1EdqDmK0bTqLouOorDmhGKX1My9OcXIK+k+cdX6Ss=; b=Il66e4NY9uU5HTxuqxoHgOU7j5tKsU41Psk3sypPunH4SYFQtvWh/hU1YgDxieHKpc tCTnZ+WU92yEu9Fsji28kA3cwTKUeuU85T0JtpBidnJ8f821FVSdHp2tBkhMTss1FNsh KYF0XXJXUKGoxtYUsSsp+orWs8jZmlgGQmGFKaccumZwGvGfZVoiupbBHdmGRh4je1Bv HUecN5PSriXWt49ElbOsMF189NEE4QG1kGHXRKm2NpGSyz8vhWFEepZCSPY49XXkwU9Y l+2POclpDzFSzBOiFgadLXSZFq+0UWhsVyM1yG8ZEIik18CET60XShovo8xdCm0LcbsL KKDg== X-Received: by 10.112.146.103 with SMTP id tb7mr12608355lbb.26.1412790260657; Wed, 08 Oct 2014 10:44:20 -0700 (PDT) Received: from [10.17.0.20] ([83.150.126.201]) by mx.google.com with ESMTPSA id m1sm227297lbt.22.2014.10.08.10.44.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 10:44:19 -0700 (PDT) Message-ID: <543577FA.9080005@gmail.com> Date: Wed, 08 Oct 2014 20:44:26 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alexandru Petrescu References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <54352235.7070304@gmail.com> <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com> <543548F8.7060403@gmail.com> In-Reply-To: <543548F8.7060403@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/eNwtUrLOVaPfXK0tZI-FJyrDckc Cc: "iesg@ietf.org" , dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) 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, 08 Oct 2014 17:44:25 -0000 Alex, 10/8/2014 5:23 PM, Alexandru Petrescu kirjoitti: > Jouni, > > Thank you for the message. > > Here are the modifications: > > Where the Charter mentions "Mobile IPv6 protocol family (RFC x, y, z)" > it should also mention RFC 3963 and RFC 5177. Hmm.. rather that listing all possible Mobile IP related protocols the charter text could just have "e.g." in front of the list of RFCs we got there at the momemt? > (these RFCs were mentioned in past versions but disappeared somehow). Yes, to avoid listing all possible RFCs on this topic. > Where the Charter says "The working group may decide to extend the > current milestones based on the new information and knowledge gained > during working on other documents listed in the initial milestones. > Possible new documents and milestones must still fit into the overall > DMM charter scope as outlined above. Milestones:[empty]" > > Please clarify that "initial milestones" is "RFC 4888, RFC 4889, > draft-ietf-dmm-best-practices-gap-analysis-08"). See http://www.ietf.org/mail-archive/web/dmm/current/msg01652.html - Jouni > > Alex > > > Le 08/10/2014 15:00, Jouni a écrit : >> Alex, >> >> Do you have a specific change to the text in mind? The charter text >> uses systematically "mobile host/router" to make sure mobile routers >> are not forgotten. However, charter also allows solutions that are >> not specifically tailored to mobile routers. >> >> Jouni >> > > From nobody Wed Oct 8 12:14:40 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3BD1A1A63; Wed, 8 Oct 2014 12:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyNuRPf22mUN; Wed, 8 Oct 2014 12:14:33 -0700 (PDT) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CD301A1A0A; Wed, 8 Oct 2014 12:14:32 -0700 (PDT) Received: by mail-lb0-f175.google.com with SMTP id u10so8677416lbd.6 for ; Wed, 08 Oct 2014 12:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=MuoDnYSQRVYx292j3YLyo77UpIb8PGnMo10KOh1PH6Y=; b=H5lQxHY0sEgfU2tQcQylO2RU46wO2RvgmV2bikQlnzGAoAHYN5dT/tzZWZNwwrqfUl ordOVvQvhbZLPmctkA0v0uMIG406Ql74NC2r/baqxTqmGJxxIp4w9xZE7qp5yWjB7NV6 M60DocjO7LE54YF2G5mP2krcuq8ePs+UAcotHUegv1PKvQiBaWzjFDhS1S02GK3ShHrR nHws0///b7pPoUlVW5I4ybv9gc5W5X6aDfnQC/GfYctRcZma31JbO/BdkQzB+okSgG15 GFofsn/3chBspb3AFmqQIJ+oUeXQo5pmUnFhEyMdGsmWIYsNw78QwBXYCMH6PohY+PmA B7CQ== MIME-Version: 1.0 X-Received: by 10.152.163.66 with SMTP id yg2mr13508725lab.38.1412795670447; Wed, 08 Oct 2014 12:14:30 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Wed, 8 Oct 2014 12:14:30 -0700 (PDT) In-Reply-To: <543548F8.7060403@gmail.com> References: <20141003193829.9669.13386.idtracker@ietfa.amsl.com> <54352235.7070304@gmail.com> <5BBFF707-2F25-4D30-9871-B5F17B9AF0B4@gmail.com> <543548F8.7060403@gmail.com> Date: Wed, 8 Oct 2014 14:14:30 -0500 Message-ID: From: Behcet Sarikaya To: Alexandru Petrescu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/b2-1jDDNmrylqlCMdnZs7siXF2c Cc: "iesg@ietf.org" , dmm WG Subject: Re: [DMM] WG Review: Distributed Mobility Management (dmm) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 19:14:34 -0000 Hi Alex, Added to the point you made, I have concerns on Enhanced mobility anchoring work item text and the references made there (BTW among others). The RFCs cited there, RFC 6097, 6463, and 5142 all progressed after the base protocol was developed, RFC 3775 or MIPv6 for 5142 and RFC 5213 or PMIPv6 for 6097 and 6363. They were extensions to what the protocol had offering some more advanced methods. My concern is DMM is being rechartered to develop the base solution. How could the base protocol be held to such a high standard even before its existence? I have similar concerns on the other work items and I think they carry similar sense. My suggestion is a base DMM protocol as an integrated solution has to be developed first and not developed in so many pieces. And then bring those three work items (or similar) up as a rechartering is= sue. Regards, Behcet On Wed, Oct 8, 2014 at 9:23 AM, Alexandru Petrescu wrote: > Jouni, > > Thank you for the message. > > Here are the modifications: > > Where the Charter mentions "Mobile IPv6 protocol family (RFC x, y, z)" it > should also mention RFC 3963 and RFC 5177. > > (these RFCs were mentioned in past versions but disappeared somehow). > > Where the Charter says "The working group may decide to extend the curren= t > milestones based on the new information and knowledge gained during worki= ng > on other documents listed in the initial milestones. Possible new documen= ts > and milestones must still fit into the overall DMM charter scope as outli= ned > above. Milestones:[empty]" > > Please clarify that "initial milestones" is "RFC 4888, RFC 4889, > draft-ietf-dmm-best-practices-gap-analysis-08"). > > Alex > > > Le 08/10/2014 15:00, Jouni a =C3=A9crit : >> >> Alex, >> >> Do you have a specific change to the text in mind? The charter text >> uses systematically "mobile host/router" to make sure mobile routers >> are not forgotten. However, charter also allows solutions that are >> not specifically tailored to mobile routers. >> >> Jouni >> > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Wed Oct 8 15:37:08 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02AE1A6F03 for ; Wed, 8 Oct 2014 15:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.986 X-Spam-Level: X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, 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 IoUSKj7EQC6B for ; Wed, 8 Oct 2014 15:37:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D1F1A6EE5 for ; Wed, 8 Oct 2014 15:37:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNL18089; Wed, 08 Oct 2014 22:37:01 +0000 (GMT) Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 8 Oct 2014 23:37:01 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.109]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.03.0158.001; Thu, 9 Oct 2014 06:37:00 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: [DMM] Enhanced anchoring WT preliminary call Thread-Index: AQHP4ZuEU1EDVk/CLEeg3F9ylmFAAJwjwarggAMJTwA= Date: Wed, 8 Oct 2014 22:36:59 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521A9259@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C521A8F23@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C521A8F23@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.195] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521A9259szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/GTcC_S-IGi2lj9XzoBdRH4uTw_o Subject: Re: [DMM] Enhanced anchoring WT preliminary call X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive:

= (Presentation: htt= p://www.ietf.org/proceedings/88/slides/slides-88-dmm-8.pdf)

= https://datatracker.ietf.org/doc/draft-yegin-dmm-ondemand-mobility/=

(Presentation: htt= p://www.ietf.org/proceedings/90/slides/slides-90-dmm-6.pdf)

= https://too= ls.ietf.org/html/draft-ietf-mif-mpvd-id-00

h= ttps://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-00

htt= p://tools.ietf.org/html/draft-ietf-mif-mpvd-ndp-support-00

<= a = href=3D"http://tools.ietf.org/html/draft-yegin-ip-mobility-orchestrator-00= ">http://tools.ietf.org/html/draft-yegin-ip-mobility-orchestrator-00

(Presentation: htt= p://www.ietf.org/proceedings/90/slides/slides-90-dmm-7.pdf)

Cheers,

Alper

Begin forwarded message:

From: Alper Yegin via = Cisco WebEx <admin@webex.com>
Subject: = Invitation to WebEx meeting: IETF DMM Mobility = Exposure & Selection WT call

Date: October 13, 2014 = 11:29:07 AM GMT+03:00

To: alper.yegin@yegin.org
=

Reply-To: = alper_yegin@hotmail.com


	=

Hi,


		Alper Yegin is inviting you to this WebEx meeting:

IETF DMM Mobility Exposure & Selection WT call

Thu, Oct 23, 5:00 pm | 1 hr 30 = min

Host: = Alper Yegin

Join

Agenda

= This meeting does not have an agenda.

Access Information

Where:		WebEx Online
Meeting = number:		237 930 353
Password:		This meeting does not require a = password.

Audio Connection

+44-203-478-5289 UK Domestic Toll

Access code: 237 930 353

Can't access your = meeting? Get = help.

= = = = = = = = =

= Delivering the power of collaboration
= Cisco WebEx Team =

= =




=20 IMPORTANT = NOTICE: This WebEx service includes a feature that allows audio and any = documents and other materials exchanged or viewed during the meeting to = be recorded. By joining this meeting, you automatically consent to such = recordings. If you do not consent to the recording, discuss your = concerns with the meeting host prior to the start of the recording or do = not join the meeting. Please note that any such recordings may be = subject to discovery in the event of litigation. =20
=A92014 Cisco = and/or its affiliates. All rights reserved. MT-A-001	=

= --Apple-Mail=_675F1778-A783-4407-9699-C64331B9AC77 Content-Disposition: attachment; filename="IETF DMM Mobility Exposure _ Selection WT call.ics" Content-Type: text/calendar; name="IETF DMM Mobility Exposure _ Selection WT call.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0APRODID:-//Microsoft=20Corporation//Outlook=2012.0=20= MIMEDIR//EN=0AVERSION:2.0=0AMETHOD:REQUEST=0A=0ABEGIN:VTIMEZONE=0A= TZID:Eastern=20Europe=0ABEGIN:STANDARD=0ADTSTART:20001029T040000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10=0A= TZOFFSETFROM:+0300=0ATZOFFSETTO:+0200=0ATZNAME:Standard=20Time=0A= END:STANDARD=0ABEGIN:DAYLIGHT=0ADTSTART:20000326T030000=0A= RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3=0A= TZOFFSETFROM:+0200=0ATZOFFSETTO:+0300=0ATZNAME:Daylight=20Savings=20Time=0A= END:DAYLIGHT=0AEND:VTIMEZONE=0A=0ABEGIN:VEVENT=0ACLASS:PUBLIC=0A= UID:M0VWN6S81IOIMBRB0JJC6DDYWQ-1KJ9=0ADTSTAMP:20141013T082907Z=0A= SUMMARY:IETF=20DMM=20Mobility=20Exposure=20&=20Selection=20WT=20call=0A= LOCATION:WebEx=20Online=0APRIORITY:5=0ASEQUENCE:1201776556=0A= TRANSP:OPAQUE=0A=0AORGANIZER;CN=3D"Alper=20Yegin=20via=20Cisco=20= WebEx":MAILTO:alper_yegin@hotmail.com=0A= ATTENDEE;ROLE=3DREQ-PARTICIPANT;PARTSTAT=3DNEEDS-ACTION;RSVP=3DTRUE:MAILTO= :alper.yegin@yegin.org=0A=0ADTSTART;TZID=3D"Eastern=20= Europe":20141023T170000=0ADTEND;TZID=3D"Eastern=20= Europe":20141023T183000=0A=0ADESCRIPTION:Hi,\n\nAlper=20Yegin=20is=20= inviting=20you=20to=20this=20WebEx=20meeting:\n\nIETF=20DMM=20Mobility=20= Exposure=20&=20Selection=20WT=20call\nThu,=20Oct=2023,=205:00=20pm=20|=20= 1=20hr=2030=20min\nIstanbul=20(Eastern=20Europe=20Summer=20Time,=20= GMT+03:00)\nHost:=20Alper=20Yegin\n\nWhen=20it's=20time,=20join=20the=20= meeting=20from=20= here:\nhttps://meetings.webex.com/collabs/meetings/join?uuid=3DM0VWN6S81IO= IMBRB0JJC6DDYWQ-1KJ9\n\nAgenda\nThis=20meeting=20does=20not=20have=20an=20= agenda.\n\nAccess=20Information\nWhere:=20WebEx=20Online\nMeeting=20= number:=20237=20930=20353\nMeeting=20password:=20This=20meeting=20does=20= not=20require=20a=20password.\n\nAudio=20Connection\n+44-203-478-5289=20= UK=20Domestic=20Toll\nAccess=20code:=20237=20930=20353\n\n\n\n\n\nCan't=20= access=20your=20meeting?=20Get=20= help:\nhttps://meetings.webex.com/collabs/#/support\n\n\nDelivering=20= the=20power=20of=20collaboration\nCisco=20WebEx=20= Team\n\n-----------------------------------------------------------\n\nIMP= ORTANT=20NOTICE:=20This=20WebEx=20service=20includes=20a=20feature=20= that=20allows=20audio=20and=20any=20documents=20and=20other=20materials=20= exchanged=20or=20viewed=20during=20the=20meeting=20to=20be=20recorded.=20= By=20joining=20this=20meeting,=20you=20automatically=20consent=20to=20= such=20recordings.=20If=20you=20do=20not=20consent=20to=20the=20= recording,=20discuss=20your=20concerns=20with=20the=20meeting=20host=20= prior=20to=20the=20start=20of=20the=20recording=20or=20do=20not=20join=20= the=20meeting.=20Please=20note=20that=20any=20such=20recordings=20may=20= be=20subject=20to=20discovery=20in=20the=20event=20of=20= litigation.\n\n=C2=A92014=20Cisco=20and/or=20its=20affiliates.=20All=20= rights=20reserved.\n\nMT-A-001\n=0A=0ABEGIN:VALARM=0AACTION:DISPLAY=0A= DESCRIPTION:REMINDER=0ATRIGGER:-PT900S=0AEND:VALARM=0A=0AEND:VEVENT=0A=0A= END:VCALENDAR=0A= --Apple-Mail=_675F1778-A783-4407-9699-C64331B9AC77 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

--Apple-Mail=_675F1778-A783-4407-9699-C64331B9AC77-- --Apple-Mail=_43C86E8E-95D9-4A83-A675-094A3A0558E3-- From nobody Wed Oct 15 06:42:41 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF011A1AC3 for ; Wed, 15 Oct 2014 06:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 kuiqn9RiNXXI for ; Wed, 15 Oct 2014 06:42:32 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C9A1A6FA7 for ; Wed, 15 Oct 2014 06:42:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 68953108412 for ; Wed, 15 Oct 2014 15:42:16 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ymOQl02gMgOG for ; Wed, 15 Oct 2014 15:42:16 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted 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 49829108410 for ; Wed, 15 Oct 2014 15:42:14 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.47]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Wed, 15 Oct 2014 15:41:52 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: FPSM: Proposed agenda for tomorrow's WT call#1 Thread-Index: Ac/ofQyQ1IUosKF6RuWjnXQGHj45/A== Date: Wed, 15 Oct 2014 13:41:52 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91AA7DC1@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.1.6.1] Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D91AA7DC1PALLENEofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/9Ik8wcae26WkucQlr056PgUi394 Subject: [DMM] FPSM: Proposed agenda for tomorrow's WT call#1 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, 15 Oct 2014 13:42:37 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D91AA7DC1PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Below you can find some proposed agenda items for tomorrow's WT call on Forwarding Path & Signaling Management (FPSM). For participation, please re= fer to the WebEx details which Sri posted on the DMM mailing list some days ago. Agenda WT call: q Check if everybody is on the same page w.r.t. objectives q Identify past/available work which falls into this work item q Technical summary and assessment of identified past/available work q Agree on next steps q Another WT telco before IETF91 ?! Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26D91AA7DC1PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Below you can find some proposed agenda items for to= morrow’s WT call on
Forwarding Path & Signaling Management (FPSM). For participation, pleas= e refer to
the WebEx details which Sri posted on the DMM mailing list some days ago.

Agenda WT call:

q&nb= sp; Check if everybody is on the same page w.r.t= . objectives

q&nb= sp; Identify past/available work which falls int= o this work item

q&nb= sp; Technical summary and assessment of identifi= ed past/available work

q&nb= sp; Agree on next steps

q&nb= sp; Another WT telco before IETF91 ?!=

Best regards,

marco

--_000_69756203DDDDE64E987BC4F70B71A26D91AA7DC1PALLENEofficehd_-- From nobody Thu Oct 16 01:32:16 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B3B1A0354 for ; Thu, 16 Oct 2014 01:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9953tV5zWAT for ; Thu, 16 Oct 2014 01:32:13 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E46A1A0053 for ; Thu, 16 Oct 2014 01:32:13 -0700 (PDT) Received: from [10.119.24.8] (115-187-74-78.op-net.com [115.187.74.78]) by mrelay.perfora.net (node=mreueus002) with ESMTP (Nemesis) id 0Lrcc7-1YJ5OR0NMz-013QV0; Thu, 16 Oct 2014 10:32:11 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1283) From: Alper Yegin In-Reply-To: <54345351.6010100@gmail.com> Date: Thu, 16 Oct 2014 11:32:11 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org> References: <54345351.6010100@gmail.com> To: dmm@ietf.org X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:feSFE0g5Am2BGTlhJLAZvqKqp3ooSsbOB1hgrdtU9sV yWEG6OMg7QNRpnzCjJYpH296yp2rZ769b5ATuLOBlpTKKdRlj5 HRFr++IUBxqaxqWP7U0jmkIoBdW8K5V+TMJpvBSC1xsw10RTWm M3ntLUE4TYhB3FMlAznrxjM2SmT9p+bah5Cxlc9xkiDNXuC76j Oz+UM0+/2zhtzUUSIfP/FdX0XMnfnQ+xa/7AHtlEVvUctsRErd 5ghGazzfV4vntbeAxHO/1GD8PvTUXA0ed08eWvwShbthrd5DDd /zA+mcZbdU8IAUeuUO/EdGdGCXvqHRe4koEXinOeJ56qanb68n VoRVWACmtatkQn3VQf5EQZdkdVrYyld+QltA696grAYSf6Bi3e 17QPdSpzuZPGA== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/KcEaA35p4sM3k04dXxHhFjshtCE Subject: [DMM] Forwarding Path & Signaling Management discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:32:14 -0000 Hello folks, Here are few clarification questions and comments on the Forwarding Path = & Signaling Management WT discussion material (oh, maybe it's time we = start numbering these WTs :-) = http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-inter= im-2014-dmm-3-1.pdf - Are we not going to support roaming? Or, even w/o roaming, I'd think = there'd be inter-domain signaling, e.g., DPA and DPN belonging to two = different networks. - What is the difference between DPA and DPN? We need definitions for = these terms. - Slide 8: Is this simply showing how BGP-based solutions can be covered = here? Or something else? - What is the relationship between Slides 6-7-8?=20 - What is a controller "type"? - Should QoS really be part of this work? I think not=85 - Why would DP be querying CP?=20 - Slide 13: It's not immediately clear why we need these identifiers, = and how they are used. Maybe there's a solution behind them, but the = reader cannot get the picture. Thanks. Alper From nobody Thu Oct 16 01:58:07 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47471A1AE8 for ; Thu, 16 Oct 2014 01:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 9D-BYoIJFsVT for ; Thu, 16 Oct 2014 01:58:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E398C1A1AE0 for ; Thu, 16 Oct 2014 01:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2755; q=dns/txt; s=iport; t=1413449882; x=1414659482; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ajyP2qOzOn7g0J+rUwk3jaE1SUupF1Ks1e2+NuJiEA8=; b=Ex765aj7ZGY+uD3FGmL1cxWBITykkZMBwTUPU824fAXrNYzsl2M/r6Tc Vk1zFNxoPjFmIB8t9Ts5jvaFwyqLP1WI2KUUkKkBtVW35mQ3JctcvPrg5 T1Cohl7fjYdhqESkVhrP3Mzi7RCVECz2qevivxo8gnqkmJ30sWPyzjI3T c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACyIP1StJV2Y/2dsb2JhbABbgw5TWATMBgyHSwKBEBYBfYQDAQEEAQEBawQXAgEIEhMhJwsXDgIEARIJEogjDclpAQEBAQEBAQMBAQEBAQEBG40dgziESwWRf4tWlhuDd2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,731,1406592000"; d="scan'208";a="363904803" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 16 Oct 2014 08:58:01 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9G8w1gW025722 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 08:58:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 03:58:00 -0500 From: "Sri Gundavelli (sgundave)" To: Alper Yegin , "dmm@ietf.org" Thread-Topic: [DMM] Forwarding Path & Signaling Management discussion Thread-Index: AQHP6RuzswbVpTGeek6d65nWzdhJkJwyStKA Date: Thu, 16 Oct 2014 08:58:00 +0000 Message-ID: References: <54345351.6010100@gmail.com> <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org> In-Reply-To: <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.94.87] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1C3F14209E1A724AB83ED06086808114@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/2OR1bIms5Kgpiy9c5oqipTsTw0U Subject: Re: [DMM] Forwarding Path & Signaling Management discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 08:58:04 -0000 Alper, Inline =8A On 10/16/14 1:32 AM, "Alper Yegin" wrote: >Hello folks, > >Here are few clarification questions and comments on the Forwarding Path >& Signaling Management WT discussion material (oh, maybe it's time we >start numbering these WTs :-) >http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-inter >im-2014-dmm-3-1.pdf > > >- Are we not going to support roaming? Or, even w/o roaming, I'd think >there'd be inter-domain signaling, e.g., DPA and DPN belonging to two >different networks. [Sri] I agree, Roaming should be supported. That's a good point. That is a intra-controller interface. > >- What is the difference between DPA and DPN? We need definitions for >these terms. [Sri]=20 Data Plane Anchor Data Plane Node We had some definitions in the IETF slides that we discussed in the last meeting=20 > >- Slide 8: Is this simply showing how BGP-based solutions can be covered >here? Or something else? [Sri] The interface can be realized using multiple approaches, one being the BGP-based approach, other explicit signaling based interface > >- What is the relationship between Slides 6-7-8? [Sri] I though we had some discussion on this in the last IETF. In the context of Forwarding path, the key point is the interface between a control plane entity and a data plane entity. May be Marco has a better explanation > >- What is a controller "type"? [Sri] In deployments there could be controller entities on function basis; Ex: Mobility Controller, Routing controller ..etc. I agree with you we should not decompose the controller, but should look at this as one single entity.=20 > >- Should QoS really be part of this work? I think not=8A [Sri] There is QoS support in all mobility architecture. QoS is tied to subscription and a key function of the mobility gateway. The CP entity should be able to provide the QoS parameters to the DP entity > >- Why would DP be querying CP? [Sri] Keeping the interface between CP and DP flexible allows us to support all types of scenarios. Lets take a simple example of a DP node loosing state, there should be mechanism to make a query to the CP entity. > >- Slide 13: It's not immediately clear why we need these identifiers, and >how they are used. Maybe there's a solution behind them, but the reader >cannot get the picture. [Sri] These are described at a high-level; Subject to change. The draft should have some details on the semantics and structure. > >Thanks. > >Alper > > > > > > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From nobody Thu Oct 16 02:03:46 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E401A6FA6 for ; Thu, 16 Oct 2014 02:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Vfetx_a--Cjq for ; Thu, 16 Oct 2014 02:03:41 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78EB1A6F01 for ; Thu, 16 Oct 2014 02:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7759; q=dns/txt; s=iport; t=1413450221; x=1414659821; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oEXLu1zw/+qG6z7Sf9zxmVb93PcZuJAK7C/ttAjIHaU=; b=gpedI8hWnWhq1Ff3cHPTq7lMWVd0P9fd6pTUEvhAjTTzx+m3OBDoW5gj oBi7VTdpV8Q08DLWx2sNlfi2btjM6kGUUJfSN+U/ey4beiBVNDI8xGJxv L2OZgq9kYkxTuSSSfafF5ORClDtI2+6ytJT2VF+mnVxxtY9ecqRk5QsT4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAFmJP1StJV2Y/2dsb2JhbABbgkhGU1gEzBCHTQKBEBYBfYQCAQEBBHcOBAIBCBEDAQIoBzIUCQgCBAESCYg1DclsAQEBAQEBAQEBAQEBAQEBAQEBGo9sEQE/GAaERQWRf4REhxKBMDyDCpElg3dsAYEOOYECAQEB X-IronPort-AV: E=Sophos;i="5.04,731,1406592000"; d="scan'208,217";a="363693072" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 16 Oct 2014 09:03:41 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9G93eoH030148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 09:03:40 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 04:03:40 -0500 From: "Sri Gundavelli (sgundave)" To: "Charles E. Perkins" , "dmm@ietf.org" Thread-Topic: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt Thread-Index: AQHP6SATJWAh7dzZF0+d2ISrgYvKAw== Date: Thu, 16 Oct 2014 09:03:39 +0000 Message-ID: References: <20140923174312.6322.91357.idtracker@ietfa.amsl.com> <5421C587.50809@computer.org> In-Reply-To: <5421C587.50809@computer.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.94.87] Content-Type: multipart/alternative; boundary="_000_D064D72316B00Asgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/K1IAUPtA_12KhgYIqpDXm655VIQ Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Thu, 16 Oct 2014 09:03:44 -0000 --_000_D064D72316B00Asgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Charlie =96 Are you asking the WG/chairs for draft adoption ? The current = version can be a good starting point and can be taken up as the =9600 versi= on of the WG draft. Off course, you still have plenty of comments on additi= onal types values that the draft still needs to address :), but the current= version can be adopted as a WG draft, IMO. Sri From: "Charles E. Perkins" > Organization: Blue Skies Date: Tuesday, September 23, 2014 12:09 PM To: "dmm@ietf.org" > Subject: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnid= s-00.txt Hello folks, We have published a ...-00 version of the MNIDs draft. This is mainly for reference purposes. A new version should be out within a week or so, incorporating the suggestions and comments from people who responded to the earlier suggestion to revisit this work. Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-perkins-dmm-4283mnids-00= .txt Date: Tue, 23 Sep 2014 10:43:12 -0700 From:

To: Charles E. Perkins , Vijay Devarapalli , Charles E.Perkins A new version of I-D, draft-perkins-dmm-4283mnids-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-dmm-4283mnids Revision: 00 Title: MN Identifier Types for RFC 4283 Mobile Node Identifier Opt= ion Document date: 2014-09-23 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283m= nids-00.txt Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnid= s/ Htmlized: http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D064D72316B00Asgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <90186612DADF9544B047246D86C2EA3A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Charlie =96 Are you asking the WG/chairs for draft adoption ? Th= e current version can be a good starting point and can be taken up as the = =9600 version of the WG draft. Off course, you still have plenty of comment= s on additional types values that the draft still needs to address :), but the current version can be adopted as a WG = draft, IMO.

Sri

From: "Charles E. Perkins"= ; <charliep@computer.org>= ;
Organization: Blue Skies
Date: Tuesday, September 23, 2014 1= 2:09 PM
To: "dmm@ietf.org" <dmm@ietf.= org>
Subject: [DMM] Fwd: New Version Not= ification for draft-perkins-dmm-4283mnids-00.txt

Hello folks,

We have published a ...-00 version of the MNIDs draft. This is mainly= for
reference purposes. A new version should be out within a week or so,<= br> incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.

-------- Original Message --------

Subject:	New Version Notification for draft-perkins-dmm-4283mnids-00.txt
Date:	Tue, 23 Sep 2014 10:43:12 -0700
From:	<internet-drafts@ietf.org>
To:	Charles E. Perkins <charliep@computer.org>, Vijay Devarapalli <unknown-email-Vijay-Devarapalli@ietfa.amsl.com>, Charles E.Perki= ns <charliep@computer.org>

A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-dmm-4283mnids
Revision:	00
Title:		MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Document date:	2014-09-23
Group:		Individual Submission
Pages:		4
URL:            http://www.ietf.org=
/internet-drafts/draft-perkins-dmm-4283mnids-00.txt
Status:         https://datatracker.ietf.org=
/doc/draft-perkins-dmm-4283mnids/
Htmlized:       http://tools.ietf.org/html/draft=
-perkins-dmm-4283mnids-00


Abstract:
   Additional Identifier Types are proposed for use with the Mobile Node
   Identifier Option for MIPv6 (RFC 4283).

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--_000_D064D72316B00Asgundaveciscocom_-- From nobody Thu Oct 16 02:16:44 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160081A014C for ; Thu, 16 Oct 2014 02:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 a2acDcmwZMT3 for ; Thu, 16 Oct 2014 02:16:38 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168BF1A1BE4 for ; Thu, 16 Oct 2014 02:16:38 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 50948374280; Thu, 16 Oct 2014 11:16:36 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 2632515805B; Thu, 16 Oct 2014 11:16:36 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 11:16:35 +0200 From: To: "Sri Gundavelli (sgundave)" , Alper Yegin , "dmm@ietf.org" Thread-Topic: [DMM] Forwarding Path & Signaling Management discussion Thread-Index: AQHP6Ru0UKvJ5UL4j0uFTQYd6ao1HJwyStQAgAAi62A= Date: Thu, 16 Oct 2014 09:16:34 +0000 Message-ID: <21186_1413450996_543F8CF4_21186_2529_1_81C77F07008CA24F9783A98CFD706F71142BB46F@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <54345351.6010100@gmail.com> <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.10.16.65723 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/OKwNuaxL58XXans6mEVutRyruAM Subject: Re: [DMM] Forwarding Path & Signaling Management discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 09:16:41 -0000 SGksDQoNCk9uIHJvYW1pbmc6IA0KDQpTcmksIEkgZ3Vlc3MgeW91IG1lYW50ICJpbnRlci1jb250 cm9sbGVyIGludGVyZmFjZSIsIHJpZ2h0PyBJTVUsIHJvYW1pbmcgaXMgYWJvdXQgY29vcmRpbmF0 aW9uIGJldHdlZW4gY29udHJvbGxlciBiZWxvbmdpbmcgdG8gZGlmZmVyZW50IGFkbWluaXN0cmF0 aXZlIChvciByb3V0aW5nPykgZG9tYWluLg0KDQpTcmkgYWxyZWFkeSBjbGFyaWZpZWQgdGhpcywg YnV0IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGluc2lzdCBvbiB0aGUgZmFjdCB0aGF0IHRo ZSB3b3J0IGl0ZW0gc2hhbGwgc3BlY2lmaWVkIGEgcHJvdG9jb2wgYWdub3N0aWMgQ1AvRFAgaW50 ZXJmYWNlIC5UaGVuLCB0aGlzIGdlbmVyaWMgaW50ZXJmYWNlICBjYW4gYmUgaW1wbGVtZW50ZWQg dXNpbmcgZGlmZmVyZW50IHByb3RvY29scyAoYW1vbmcgdGhlbSBpcyBCR1ApLCBidXQgdGhpcyBp cyBvdXQgb2Ygc2NvcGUgb2YgdGhlIHdvcmsgaXRlbS4NCg0KQlIsDQpQaWVycmljaw0KDQo+LS0t LS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+RGXCoDogZG1tIFttYWlsdG86ZG1tLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgU3JpIEd1bmRhdmVsbGkNCj4oc2d1bmRhdmUpDQo+RW52 b3nDqcKgOiBqZXVkaSAxNiBvY3RvYnJlIDIwMTQgMTA6NTgNCj7DgMKgOiBBbHBlciBZZWdpbjsg ZG1tQGlldGYub3JnDQo+T2JqZXTCoDogUmU6IFtETU1dIEZvcndhcmRpbmcgUGF0aCAmIFNpZ25h bGluZyBNYW5hZ2VtZW50IGRpc2N1c3Npb24NCj4NCj5BbHBlciwNCj4NCj5JbmxpbmUgxaANCj4N Cj4NCj5PbiAxMC8xNi8xNCAxOjMyIEFNLCAiQWxwZXIgWWVnaW4iIDxhbHBlci55ZWdpbkB5ZWdp bi5vcmc+IHdyb3RlOg0KPg0KPj5IZWxsbyBmb2xrcywNCj4+DQo+PkhlcmUgYXJlIGZldyBjbGFy aWZpY2F0aW9uIHF1ZXN0aW9ucyBhbmQgY29tbWVudHMgb24gdGhlIEZvcndhcmRpbmcNCj4+UGF0 aCAmIFNpZ25hbGluZyBNYW5hZ2VtZW50IFdUIGRpc2N1c3Npb24gbWF0ZXJpYWwgKG9oLCBtYXli ZSBpdCdzIHRpbWUNCj4+d2Ugc3RhcnQgbnVtYmVyaW5nIHRoZXNlIFdUcyA6LSkNCj4+aHR0cDov L3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy9pbnRlcmltLzIwMTQvMTAvMDcvZG1tL3NsaWRlcy9z bGlkZXMtaW4NCj4+dGVyDQo+PmltLTIwMTQtZG1tLTMtMS5wZGYNCj4+DQo+Pg0KPj4tIEFyZSB3 ZSBub3QgZ29pbmcgdG8gc3VwcG9ydCByb2FtaW5nPyBPciwgZXZlbiB3L28gcm9hbWluZywgSSdk IHRoaW5rDQo+PnRoZXJlJ2QgYmUgaW50ZXItZG9tYWluIHNpZ25hbGluZywgZS5nLiwgRFBBIGFu ZCBEUE4gYmVsb25naW5nIHRvIHR3bw0KPj5kaWZmZXJlbnQgbmV0d29ya3MuDQo+DQo+DQo+W1Ny aV0gSSBhZ3JlZSwgUm9hbWluZyBzaG91bGQgYmUgc3VwcG9ydGVkLiBUaGF0J3MgYSBnb29kIHBv aW50LiBUaGF0IGlzIGEgaW50cmEtDQo+Y29udHJvbGxlciBpbnRlcmZhY2UuDQo+DQo+DQo+Pg0K Pj4tIFdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBEUEEgYW5kIERQTj8gV2UgbmVlZCBk ZWZpbml0aW9ucyBmb3INCj4+dGhlc2UgdGVybXMuDQo+DQo+W1NyaV0NCj5EYXRhIFBsYW5lIEFu Y2hvcg0KPkRhdGEgUGxhbmUgTm9kZQ0KPg0KPldlIGhhZCBzb21lIGRlZmluaXRpb25zIGluIHRo ZSBJRVRGIHNsaWRlcyB0aGF0IHdlIGRpc2N1c3NlZCBpbiB0aGUgbGFzdA0KPm1lZXRpbmcNCj4N Cj4NCj4+DQo+Pi0gU2xpZGUgODogSXMgdGhpcyBzaW1wbHkgc2hvd2luZyBob3cgQkdQLWJhc2Vk IHNvbHV0aW9ucyBjYW4gYmUNCj4+Y292ZXJlZCBoZXJlPyBPciBzb21ldGhpbmcgZWxzZT8NCj4N Cj4NCj5bU3JpXSBUaGUgaW50ZXJmYWNlIGNhbiBiZSByZWFsaXplZCB1c2luZyBtdWx0aXBsZSBh cHByb2FjaGVzLCBvbmUgYmVpbmcgdGhlDQo+QkdQLWJhc2VkIGFwcHJvYWNoLCBvdGhlciBleHBs aWNpdCBzaWduYWxpbmcgYmFzZWQgaW50ZXJmYWNlDQo+DQo+DQo+Pg0KPj4tIFdoYXQgaXMgdGhl IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIFNsaWRlcyA2LTctOD8NCj4NCj4NCj5bU3JpXSBJIHRob3Vn aCB3ZSBoYWQgc29tZSBkaXNjdXNzaW9uIG9uIHRoaXMgaW4gdGhlIGxhc3QgSUVURi4gSW4gdGhl IGNvbnRleHQgb2YNCj5Gb3J3YXJkaW5nIHBhdGgsIHRoZSBrZXkgcG9pbnQgaXMgdGhlIGludGVy ZmFjZSBiZXR3ZWVuIGEgY29udHJvbCBwbGFuZSBlbnRpdHkNCj5hbmQgYSBkYXRhIHBsYW5lIGVu dGl0eS4NCj5NYXkgYmUgTWFyY28gaGFzIGEgYmV0dGVyIGV4cGxhbmF0aW9uDQo+DQo+DQo+DQo+ Pg0KPj4tIFdoYXQgaXMgYSBjb250cm9sbGVyICJ0eXBlIj8NCj4NCj5bU3JpXSBJbiBkZXBsb3lt ZW50cyB0aGVyZSBjb3VsZCBiZSBjb250cm9sbGVyIGVudGl0aWVzIG9uIGZ1bmN0aW9uIGJhc2lz Ow0KPkV4OiBNb2JpbGl0eSBDb250cm9sbGVyLCBSb3V0aW5nIGNvbnRyb2xsZXIgLi5ldGMuIEkg YWdyZWUgd2l0aCB5b3Ugd2Ugc2hvdWxkIG5vdA0KPmRlY29tcG9zZSB0aGUgY29udHJvbGxlciwg YnV0IHNob3VsZCBsb29rIGF0IHRoaXMgYXMgb25lIHNpbmdsZSBlbnRpdHkuDQo+DQo+DQo+DQo+ Pg0KPj4tIFNob3VsZCBRb1MgcmVhbGx5IGJlIHBhcnQgb2YgdGhpcyB3b3JrPyBJIHRoaW5rIG5v dMWgDQo+DQo+W1NyaV0gVGhlcmUgaXMgUW9TIHN1cHBvcnQgaW4gYWxsIG1vYmlsaXR5IGFyY2hp dGVjdHVyZS4gUW9TIGlzIHRpZWQgdG8NCj5zdWJzY3JpcHRpb24gYW5kIGEga2V5IGZ1bmN0aW9u IG9mIHRoZSBtb2JpbGl0eSBnYXRld2F5LiBUaGUgQ1AgZW50aXR5IHNob3VsZA0KPmJlIGFibGUg dG8gcHJvdmlkZSB0aGUgUW9TIHBhcmFtZXRlcnMgdG8gdGhlIERQIGVudGl0eQ0KPg0KPg0KPj4N Cj4+LSBXaHkgd291bGQgRFAgYmUgcXVlcnlpbmcgQ1A/DQo+DQo+W1NyaV0gS2VlcGluZyB0aGUg aW50ZXJmYWNlIGJldHdlZW4gQ1AgYW5kIERQIGZsZXhpYmxlIGFsbG93cyB1cyB0byBzdXBwb3J0 IGFsbA0KPnR5cGVzIG9mIHNjZW5hcmlvcy4gTGV0cyB0YWtlIGEgc2ltcGxlIGV4YW1wbGUgb2Yg YSBEUCBub2RlIGxvb3Npbmcgc3RhdGUsDQo+dGhlcmUgc2hvdWxkIGJlIG1lY2hhbmlzbSB0byBt YWtlIGEgcXVlcnkgdG8gdGhlIENQIGVudGl0eS4NCj4NCj4+DQo+Pi0gU2xpZGUgMTM6IEl0J3Mg bm90IGltbWVkaWF0ZWx5IGNsZWFyIHdoeSB3ZSBuZWVkIHRoZXNlIGlkZW50aWZpZXJzLA0KPj5h bmQgaG93IHRoZXkgYXJlIHVzZWQuIE1heWJlIHRoZXJlJ3MgYSBzb2x1dGlvbiBiZWhpbmQgdGhl bSwgYnV0IHRoZQ0KPj5yZWFkZXIgY2Fubm90IGdldCB0aGUgcGljdHVyZS4NCj4NCj5bU3JpXSBU aGVzZSBhcmUgZGVzY3JpYmVkIGF0IGEgaGlnaC1sZXZlbDsgU3ViamVjdCB0byBjaGFuZ2UuIFRo ZSBkcmFmdCBzaG91bGQNCj5oYXZlIHNvbWUgZGV0YWlscyBvbiB0aGUgc2VtYW50aWNzIGFuZCBz dHJ1Y3R1cmUuDQo+DQo+DQo+Pg0KPj5UaGFua3MuDQo+Pg0KPj5BbHBlcg0KPj4NCj4+DQo+Pg0K Pj4NCj4+DQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+ZG1tIG1haWxpbmcgbGlzdA0KPj5kbW1AaWV0Zi5vcmcNCj4+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbW0NCj4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPmRtbSBtYWlsaW5nIGxpc3QNCj5kbW1AaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVz IGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZl bnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4KVGhhbmsgeW91LgoK From nobody Thu Oct 16 03:08:19 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE091ACEFE for ; Thu, 16 Oct 2014 03:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Nqna_HERnw33 for ; Thu, 16 Oct 2014 03:08:11 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4F4B1A0194 for ; Thu, 16 Oct 2014 03:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8404; q=dns/txt; s=iport; t=1413454090; x=1414663690; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Ks2ljIMuCet11z+M/U+YbMyY35V1RF1BukkQCUm3u6Y=; b=ctjnttw7EET2IzLVrNVSfUeuh5a/vvBOya+M87K9atF/E4PC4BXUiokl CCwFoG7FBX9Kh78Eu/Bsv/z0RIvVDUk58M/BfOCDJLBdWrVPiPP8GPGZM TEoYiKTPNSWfSftbPAMroN10aPwOEIGWbDIf0jG0iIIcOgH4n2w/bH/bH o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAJqYP1StJV2Y/2dsb2JhbABbgw5TWASDAskJDIdLAht2FgF9hAMBAQQBAQEgEToEFwIBCBIGAgIJGgMCAgIlCxQBAg4CBAESCRKIIw20Z5UWAQEBAQEBAQECAQEBAQEBAQEagSyLcYJPEQEdOoJ3gVQFkX+GO4UbgTCDRpElg3dsgQ85gQIBAQE X-IronPort-AV: E=Sophos;i="5.04,731,1406592000"; d="scan'208";a="363921130" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 16 Oct 2014 10:08:09 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s9GA89CG011441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 Oct 2014 10:08:09 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Thu, 16 Oct 2014 05:08:09 -0500 From: "Sri Gundavelli (sgundave)" To: "pierrick.seite@orange.com" , Alper Yegin , "dmm@ietf.org" Thread-Topic: [DMM] Forwarding Path & Signaling Management discussion Thread-Index: AQHP6RuzswbVpTGeek6d65nWzdhJkJwyStKAgAB6igD//5kPgA== Date: Thu, 16 Oct 2014 10:08:08 +0000 Message-ID: References: <54345351.6010100@gmail.com> <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org> <21186_1413450996_543F8CF4_21186_2529_1_81C77F07008CA24F9783A98CFD706F71142BB46F@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <21186_1413450996_543F8CF4_21186_2529_1_81C77F07008CA24F9783A98CFD706F71142BB46F@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.21.94.87] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/NRRDqN9ztYNA7VVLqDdrML-dogA Subject: Re: [DMM] Forwarding Path & Signaling Management discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 10:08:16 -0000 SGkgUGllcnJpY2ssDQoNClllczsgVHlwby4gSXRzIGludGVyLWNvbnRyb2xsZXIgaW50ZXJmYWNl Lg0KDQpXZSBoYXZlIHRvIGxvb2sgYXQgRE1NIGFzIGEgbW9iaWxpdHkgZG9tYWluIGFuZCB0aGUg aW50ZXJhY3Rpb25zL3Byb3RvY29sDQppbnRlcmZhY2VzIGFyZSBiZXR3ZWVuIHRoZSBlbnRpdGll cyB3aXRoaW4gdGhhdCBkb21haW4uIFRoZSByb2FtaW5nIGlzDQptb3JlIGFib3V0IGEgYnVzaW5l c3MgcmVsYXRpb24gYW5kIGFib3V0IHNlY3VyaXR5IGFncmVlbWVudHMuIEkgZG8gbm90DQpiZWxp ZXZlIHdlIG5lZWQgdG8gbW9kZWwgYnVzaW5lc3MgcmVsYXRpb25zIGludG8gcHJvdG9jb2wgZGVm aW5pdGlvbnMuDQpUaGF0J3MgbW9yZSBhYm91dCBzaGFyaW5nIHNlY3VyaXR5IGNyZWRlbnRpYWwg YW5kIGF1dGhvcml6YXRpb24uIEl0cw0KcG9zc2libGUgYWRtaW5pc3RyYXRpdmUgYm91bmRhcmll cyBhcmUgYXQgYSBkb21haW4gbGV2ZWwgYW5kIHRoZQ0KY29udHJvbGxlcnMgb2YgZWFjaCBkb21h aW4gbWF5IGhhdmUgc2VjdXJpdHkgcmVsYXRpb24gd2l0aCBvdGhlcg0KY29udHJvbGxlcnMuIEEg Y29udHJvbGxlciBvZiBvbmUgZG9tYWluIG1heSBub3QgaW50ZXJmYWNlIHdpdGggdGhlIERhdGEN ClBsYW5lIGVudGl0aWVzIG1hbmFnZWQgYnkgYW5vdGhlciBjb250cm9sbGVyLCBidXQgaXQgbWF5 IGludGVyZmFjZSB3aXRoDQp0aGUgY29udHJvbGxlciBvZiBvdGhlciBkb21haW4sIHNvIHRoYXQg Y29udHJvbGxlciBjYW4gaW50ZXJmYWNlIHdpdGggdGhlDQpEYXRhIFBsYW5lIGVudGl0aWVzIHVu ZGVyIGl0cyBjb250cm9sLg0KDQpJbiB0aGlzIGNvbnRleHQgb2YgdGhpcyB3b3JrLCBpdHMgc2lt cGx5IGEgaW50ZXJmYWNlIGJldHdlZW4gQ29udHJvbC1QbGFuZQ0KYW5kIFVzZXItcGxhbmUgZW50 aXR5LiBUaGUgZm9jdXMgb2YgdGhlIGRpc2N1c3Npb24gaXMgbW9yZSBhYm91dCB0aGUNCnNlbWFu dGljcyBvZiB0aGUgaW50ZXJmYWNlOyBpdHMgYWJvdXQgb3BlcmF0aW9ucywgaW5mb3JtYXRpb24g ZWxlbWVudHMgYW5kDQp0aGUgZXhwZWN0ZWQgc3RhdGUgY2hhbmdlcy4NCg0KDQpTcmkNCg0KDQoN Cg0KDQoNCg0KT24gMTAvMTYvMTQgMjoxNiBBTSwgInBpZXJyaWNrLnNlaXRlQG9yYW5nZS5jb20i DQo8cGllcnJpY2suc2VpdGVAb3JhbmdlLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5PbiByb2Ft aW5nOiANCj4NCj5TcmksIEkgZ3Vlc3MgeW91IG1lYW50ICJpbnRlci1jb250cm9sbGVyIGludGVy ZmFjZSIsIHJpZ2h0PyBJTVUsIHJvYW1pbmcNCj5pcyBhYm91dCBjb29yZGluYXRpb24gYmV0d2Vl biBjb250cm9sbGVyIGJlbG9uZ2luZyB0byBkaWZmZXJlbnQNCj5hZG1pbmlzdHJhdGl2ZSAob3Ig cm91dGluZz8pIGRvbWFpbi4NCj4NCj5TcmkgYWxyZWFkeSBjbGFyaWZpZWQgdGhpcywgYnV0IEkg dGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIGluc2lzdCBvbiB0aGUNCj5mYWN0IHRoYXQgdGhlIHdv cnQgaXRlbSBzaGFsbCBzcGVjaWZpZWQgYSBwcm90b2NvbCBhZ25vc3RpYyBDUC9EUA0KPmludGVy ZmFjZSAuVGhlbiwgdGhpcyBnZW5lcmljIGludGVyZmFjZSAgY2FuIGJlIGltcGxlbWVudGVkIHVz aW5nDQo+ZGlmZmVyZW50IHByb3RvY29scyAoYW1vbmcgdGhlbSBpcyBCR1ApLCBidXQgdGhpcyBp cyBvdXQgb2Ygc2NvcGUgb2YgdGhlDQo+d29yayBpdGVtLg0KPg0KPkJSLA0KPlBpZXJyaWNrDQo+ DQo+Pi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj5EZSA6IGRtbSBbbWFpbHRvOmRtbS1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFNyaSBHdW5kYXZlbGxpDQo+PihzZ3VuZGF2 ZSkNCj4+RW52b3nDqSA6IGpldWRpIDE2IG9jdG9icmUgMjAxNCAxMDo1OA0KPj7DgCA6IEFscGVy IFllZ2luOyBkbW1AaWV0Zi5vcmcNCj4+T2JqZXQgOiBSZTogW0RNTV0gRm9yd2FyZGluZyBQYXRo ICYgU2lnbmFsaW5nIE1hbmFnZW1lbnQgZGlzY3Vzc2lvbg0KPj4NCj4+QWxwZXIsDQo+Pg0KPj5J bmxpbmUgxaANCj4+DQo+Pg0KPj5PbiAxMC8xNi8xNCAxOjMyIEFNLCAiQWxwZXIgWWVnaW4iIDxh bHBlci55ZWdpbkB5ZWdpbi5vcmc+IHdyb3RlOg0KPj4NCj4+PkhlbGxvIGZvbGtzLA0KPj4+DQo+ Pj5IZXJlIGFyZSBmZXcgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbnMgYW5kIGNvbW1lbnRzIG9uIHRo ZSBGb3J3YXJkaW5nDQo+Pj5QYXRoICYgU2lnbmFsaW5nIE1hbmFnZW1lbnQgV1QgZGlzY3Vzc2lv biBtYXRlcmlhbCAob2gsIG1heWJlIGl0J3MgdGltZQ0KPj4+d2Ugc3RhcnQgbnVtYmVyaW5nIHRo ZXNlIFdUcyA6LSkNCj4+Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvaW50ZXJpbS8y MDE0LzEwLzA3L2RtbS9zbGlkZXMvc2xpZGVzLWluDQo+Pj50ZXINCj4+PmltLTIwMTQtZG1tLTMt MS5wZGYNCj4+Pg0KPj4+DQo+Pj4tIEFyZSB3ZSBub3QgZ29pbmcgdG8gc3VwcG9ydCByb2FtaW5n PyBPciwgZXZlbiB3L28gcm9hbWluZywgSSdkIHRoaW5rDQo+Pj50aGVyZSdkIGJlIGludGVyLWRv bWFpbiBzaWduYWxpbmcsIGUuZy4sIERQQSBhbmQgRFBOIGJlbG9uZ2luZyB0byB0d28NCj4+PmRp ZmZlcmVudCBuZXR3b3Jrcy4NCj4+DQo+Pg0KPj5bU3JpXSBJIGFncmVlLCBSb2FtaW5nIHNob3Vs ZCBiZSBzdXBwb3J0ZWQuIFRoYXQncyBhIGdvb2QgcG9pbnQuIFRoYXQgaXMNCj4+YSBpbnRyYS0N Cj4+Y29udHJvbGxlciBpbnRlcmZhY2UuDQo+Pg0KPj4NCj4+Pg0KPj4+LSBXaGF0IGlzIHRoZSBk aWZmZXJlbmNlIGJldHdlZW4gRFBBIGFuZCBEUE4/IFdlIG5lZWQgZGVmaW5pdGlvbnMgZm9yDQo+ Pj50aGVzZSB0ZXJtcy4NCj4+DQo+PltTcmldDQo+PkRhdGEgUGxhbmUgQW5jaG9yDQo+PkRhdGEg UGxhbmUgTm9kZQ0KPj4NCj4+V2UgaGFkIHNvbWUgZGVmaW5pdGlvbnMgaW4gdGhlIElFVEYgc2xp ZGVzIHRoYXQgd2UgZGlzY3Vzc2VkIGluIHRoZSBsYXN0DQo+Pm1lZXRpbmcNCj4+DQo+Pg0KPj4+ DQo+Pj4tIFNsaWRlIDg6IElzIHRoaXMgc2ltcGx5IHNob3dpbmcgaG93IEJHUC1iYXNlZCBzb2x1 dGlvbnMgY2FuIGJlDQo+Pj5jb3ZlcmVkIGhlcmU/IE9yIHNvbWV0aGluZyBlbHNlPw0KPj4NCj4+ DQo+PltTcmldIFRoZSBpbnRlcmZhY2UgY2FuIGJlIHJlYWxpemVkIHVzaW5nIG11bHRpcGxlIGFw cHJvYWNoZXMsIG9uZSBiZWluZw0KPj50aGUNCj4+QkdQLWJhc2VkIGFwcHJvYWNoLCBvdGhlciBl eHBsaWNpdCBzaWduYWxpbmcgYmFzZWQgaW50ZXJmYWNlDQo+Pg0KPj4NCj4+Pg0KPj4+LSBXaGF0 IGlzIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBTbGlkZXMgNi03LTg/DQo+Pg0KPj4NCj4+W1Ny aV0gSSB0aG91Z2ggd2UgaGFkIHNvbWUgZGlzY3Vzc2lvbiBvbiB0aGlzIGluIHRoZSBsYXN0IElF VEYuIEluIHRoZQ0KPj5jb250ZXh0IG9mDQo+PkZvcndhcmRpbmcgcGF0aCwgdGhlIGtleSBwb2lu dCBpcyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gYSBjb250cm9sIHBsYW5lDQo+PmVudGl0eQ0KPj5h bmQgYSBkYXRhIHBsYW5lIGVudGl0eS4NCj4+TWF5IGJlIE1hcmNvIGhhcyBhIGJldHRlciBleHBs YW5hdGlvbg0KPj4NCj4+DQo+Pg0KPj4+DQo+Pj4tIFdoYXQgaXMgYSBjb250cm9sbGVyICJ0eXBl Ij8NCj4+DQo+PltTcmldIEluIGRlcGxveW1lbnRzIHRoZXJlIGNvdWxkIGJlIGNvbnRyb2xsZXIg ZW50aXRpZXMgb24gZnVuY3Rpb24NCj4+YmFzaXM7DQo+PkV4OiBNb2JpbGl0eSBDb250cm9sbGVy LCBSb3V0aW5nIGNvbnRyb2xsZXIgLi5ldGMuIEkgYWdyZWUgd2l0aCB5b3Ugd2UNCj4+c2hvdWxk IG5vdA0KPj5kZWNvbXBvc2UgdGhlIGNvbnRyb2xsZXIsIGJ1dCBzaG91bGQgbG9vayBhdCB0aGlz IGFzIG9uZSBzaW5nbGUgZW50aXR5Lg0KPj4NCj4+DQo+Pg0KPj4+DQo+Pj4tIFNob3VsZCBRb1Mg cmVhbGx5IGJlIHBhcnQgb2YgdGhpcyB3b3JrPyBJIHRoaW5rIG5vdMWgDQo+Pg0KPj5bU3JpXSBU aGVyZSBpcyBRb1Mgc3VwcG9ydCBpbiBhbGwgbW9iaWxpdHkgYXJjaGl0ZWN0dXJlLiBRb1MgaXMg dGllZCB0bw0KPj5zdWJzY3JpcHRpb24gYW5kIGEga2V5IGZ1bmN0aW9uIG9mIHRoZSBtb2JpbGl0 eSBnYXRld2F5LiBUaGUgQ1AgZW50aXR5DQo+PnNob3VsZA0KPj5iZSBhYmxlIHRvIHByb3ZpZGUg dGhlIFFvUyBwYXJhbWV0ZXJzIHRvIHRoZSBEUCBlbnRpdHkNCj4+DQo+Pg0KPj4+DQo+Pj4tIFdo eSB3b3VsZCBEUCBiZSBxdWVyeWluZyBDUD8NCj4+DQo+PltTcmldIEtlZXBpbmcgdGhlIGludGVy ZmFjZSBiZXR3ZWVuIENQIGFuZCBEUCBmbGV4aWJsZSBhbGxvd3MgdXMgdG8NCj4+c3VwcG9ydCBh bGwNCj4+dHlwZXMgb2Ygc2NlbmFyaW9zLiBMZXRzIHRha2UgYSBzaW1wbGUgZXhhbXBsZSBvZiBh IERQIG5vZGUgbG9vc2luZw0KPj5zdGF0ZSwNCj4+dGhlcmUgc2hvdWxkIGJlIG1lY2hhbmlzbSB0 byBtYWtlIGEgcXVlcnkgdG8gdGhlIENQIGVudGl0eS4NCj4+DQo+Pj4NCj4+Pi0gU2xpZGUgMTM6 IEl0J3Mgbm90IGltbWVkaWF0ZWx5IGNsZWFyIHdoeSB3ZSBuZWVkIHRoZXNlIGlkZW50aWZpZXJz LA0KPj4+YW5kIGhvdyB0aGV5IGFyZSB1c2VkLiBNYXliZSB0aGVyZSdzIGEgc29sdXRpb24gYmVo aW5kIHRoZW0sIGJ1dCB0aGUNCj4+PnJlYWRlciBjYW5ub3QgZ2V0IHRoZSBwaWN0dXJlLg0KPj4N Cj4+W1NyaV0gVGhlc2UgYXJlIGRlc2NyaWJlZCBhdCBhIGhpZ2gtbGV2ZWw7IFN1YmplY3QgdG8g Y2hhbmdlLiBUaGUgZHJhZnQNCj4+c2hvdWxkDQo+PmhhdmUgc29tZSBkZXRhaWxzIG9uIHRoZSBz ZW1hbnRpY3MgYW5kIHN0cnVjdHVyZS4NCj4+DQo+Pg0KPj4+DQo+Pj5UaGFua3MuDQo+Pj4NCj4+ PkFscGVyDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5kbW0gbWFpbGluZyBsaXN0 DQo+Pj5kbW1AaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZG1tDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5kbW0gbWFpbGluZyBsaXN0DQo+PmRtbUBpZXRmLm9yZw0KPj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4NCj5DZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMNCj5jb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0K PnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXoNCj5yZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXINCj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMNCj5lbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sDQo+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUNCj5vdSBmYWxzaWZpZS4gTWVyY2ku DQo+DQo+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQNCj5pbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQg YnkgbGF3Ow0KPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj5kZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlDQo+YmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+VGhhbmsgeW91Lg0KPg0KDQo= From nobody Thu Oct 16 03:41:51 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1834B1A19E7 for ; Thu, 16 Oct 2014 03:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 HBECnyZu2bnH for ; Thu, 16 Oct 2014 03:41:48 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BC741ACFF5 for ; Thu, 16 Oct 2014 03:41:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 38C07108432; Thu, 16 Oct 2014 12:41:47 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOub80BAZs0K; Thu, 16 Oct 2014 12:41:47 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 1C7BA108163; Thu, 16 Oct 2014 12:41:41 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.47]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Thu, 16 Oct 2014 12:41:41 +0200 From: Marco Liebsch To: "Sri Gundavelli (sgundave)" , Alper Yegin , "dmm@ietf.org" Thread-Topic: [DMM] Forwarding Path & Signaling Management discussion Thread-Index: AQHP6Ru4CE5qclrB7EOMfOq354q+kJwyStQAgAA1SaA= Date: Thu, 16 Oct 2014 10:41:40 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91AAF911@PALLENE.office.hd> References: <54345351.6010100@gmail.com> <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org> 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 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Hr2VVKcum_eotc5Qn4E4f5zsxPc Subject: Re: [DMM] Forwarding Path & Signaling Management discussion X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 10:41:50 -0000 Please see inline for my opinion about your questions to slide 6-8. >-----Original Message----- >From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli >(sgundave) >Sent: Donnerstag, 16. Oktober 2014 10:58 >To: Alper Yegin; dmm@ietf.org >Subject: Re: [DMM] Forwarding Path & Signaling Management discussion .. > > >> >>- Slide 8: Is this simply showing how BGP-based solutions can be >>covered here? Or something else? > > >[Sri] The interface can be realized using multiple approaches, one being t= he >BGP-based approach, other explicit signaling based interface > > >> >>- What is the relationship between Slides 6-7-8? > > >[Sri] I though we had some discussion on this in the last IETF. In the con= text of >Forwarding path, the key point is the interface between a control plane en= tity >and a data plane entity. >May be Marco has a better explanation > [marco] slides 6 and 7 show the enforcement of policies on data plane ancho= r and data plane node, whereas slide 8 shows that policies can also be enforc= ed at regular transport network functions to steer forwarding of (downlink) tr= affic to the MN's anchor. This can lead to the following discussion point: If we keep mobility- or se= ssion states away from the data plane functions, but hold them solely in the control function= s, the question is whether we need to differentiate data plane anchor and data pla= ne node=20 from these transport network routers or switches. marco > > >> From nobody Thu Oct 16 14:18:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678801A89B1 for ; Thu, 16 Oct 2014 14:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIHi3pVgA-3x for ; Thu, 16 Oct 2014 14:18:54 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EFF1A8985 for ; Thu, 16 Oct 2014 14:18:34 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id gq15so3586973lab.26 for ; Thu, 16 Oct 2014 14:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=WpvH3xFZQEWOMiKicbr5VsGJLg7F+ndBV7BiohjqOY0=; b=X0A9HKu6wbVLDZMQAfM5SGW5ONxGAozEEPF/atEXqd1pst9JWCjOW3KH9QQzHkIhDR JCFq5j/YydMVx/hYmYr6orYkkjHoT1Jwkn2HliP9wJydnT21HHyC5QJhv7LbMb7Nh06m FusPt9FHcnHxUtwjQHo/7QW/UFKMwaCIV2AdJvgsBz6g/FktuZ4kuujsPer1kX73xcgK 9y2LzkcYSFyef52TB3GMDgKU8FyaLh78A0LY0Ts5enZnJ1J0hxLgRsq17uhJ70LlU9Ei 8wDqp7o0W4Lv6GUmy9FmKjQmKE0pVc0qu1IRiog0ZcBEghscEuDKVoCxSC3jm09BeO3X CsPQ== X-Received: by 10.112.133.138 with SMTP id pc10mr4450055lbb.48.1413494313447; Thu, 16 Oct 2014 14:18:33 -0700 (PDT) Received: from [10.188.7.197] (ppp-seco11pa2-46-193-135-220.wb.wifirst.net. [46.193.135.220]) by mx.google.com with ESMTPSA id ju20sm8152346lab.14.2014.10.16.14.18.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 16 Oct 2014 14:18:32 -0700 (PDT) Message-ID: <54403625.9030408@gmail.com> Date: Fri, 17 Oct 2014 00:18:29 +0300 From: Jouni Korhonen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/uYaphkrhYvzjqnbUf2HqOcULZlo Subject: [DMM] Charter approved X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Oct 2014 21:18:55 -0000 Folks, IESG has approved our new charter. Now we can execute at the full speed in the solution space! - Jouni & Dapeng From nobody Thu Oct 16 22:33:03 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D22FC1A90B9 for ; Thu, 16 Oct 2014 22:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SBL=0.141, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFQhtLzr87qL for ; Thu, 16 Oct 2014 22:32:59 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8E11A90B4 for ; Thu, 16 Oct 2014 22:32:59 -0700 (PDT) Received: from [10.119.24.4] (115-187-74-78.op-net.com [115.187.74.78]) by mrelay.perfora.net (node=mreueus001) with ESMTP (Nemesis) id 0M4IeT-1XxM9d3IZP-00rtOF; Fri, 17 Oct 2014 07:32:58 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Fri, 17 Oct 2014 08:32:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54345351.6010100@gmail.com> <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org> To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:L9L1My0clnH0t3dSTvDP8rho5ODk+Zw4c/mpMqCGxon 4IRQNIZ8QPRwD0/3CntmKoi25IoxRmsqUxtlSuIy91oVsBzlcp Hul8mja/45T4YMjruGssDkZSzJAutUgkdoYFmUlC1xYpeHWkSH 2JeZMTz+u2hhNIfPdi4eharAe8KIjAKvSoO+KNfHviqWuHiaq9 c3WuyhRTaddG2jySKNpCc4kgVSnWT6Uwsn2W9Lz0n+ZRmAmpXy dMn5Tq5jnkg3qm6DvZMiBjIrPmRdYD7/wCdWZ/Pg36Q4ZO7xEb 41ZeR0uJPGtBTgIBzBvYkonNQthWVOblLKjQNnNZX/Yunxe1xp gO/c9NBN1DB1W0csTQEWHVUf1ketJ07u6sj0h1QR0zd8Ctjvpi vtY6uG9xZL2+w== X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/9lOboSbHAGCbmtunmad469beews Cc: "dmm@ietf.org" Subject: Re: [DMM] Forwarding Path & Signaling Management discussion 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, 17 Oct 2014 05:33:02 -0000 Sri, >> - Should QoS really be part of this work? I think not=8A >=20 > [Sri] There is QoS support in all mobility architecture. QoS is tied = to > subscription and a key function of the mobility gateway. The CP entity > should be able to provide the QoS parameters to the DP entity I'd say let's not deal with it in DMM WG. Or at the least, let's not = tackle it in the first phase of DMM work. Otherwise we are making our life an order of magnitude harder from very = beginning. Alper On Oct 16, 2014, at 11:58 AM, Sri Gundavelli (sgundave) wrote: > Alper, >=20 > Inline =8A >=20 >=20 > On 10/16/14 1:32 AM, "Alper Yegin" wrote: >=20 >> Hello folks, >>=20 >> Here are few clarification questions and comments on the Forwarding = Path >> & Signaling Management WT discussion material (oh, maybe it's time we >> start numbering these WTs :-) >> = http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-inter= >> im-2014-dmm-3-1.pdf >>=20 >>=20 >> - Are we not going to support roaming? Or, even w/o roaming, I'd = think >> there'd be inter-domain signaling, e.g., DPA and DPN belonging to two >> different networks. >=20 >=20 > [Sri] I agree, Roaming should be supported. That's a good point. That = is a > intra-controller interface. >=20 >=20 >>=20 >> - What is the difference between DPA and DPN? We need definitions for >> these terms. >=20 > [Sri]=20 > Data Plane Anchor > Data Plane Node >=20 > We had some definitions in the IETF slides that we discussed in the = last > meeting=20 >=20 >=20 >>=20 >> - Slide 8: Is this simply showing how BGP-based solutions can be = covered >> here? Or something else? >=20 >=20 > [Sri] The interface can be realized using multiple approaches, one = being > the BGP-based approach, other explicit signaling based interface >=20 >=20 >>=20 >> - What is the relationship between Slides 6-7-8? >=20 >=20 > [Sri] I though we had some discussion on this in the last IETF. In the > context of Forwarding path, the key point is the interface between a > control plane entity and a data plane entity. > May be Marco has a better explanation >=20 >=20 >=20 >>=20 >> - What is a controller "type"? >=20 > [Sri] In deployments there could be controller entities on function = basis; > Ex: Mobility Controller, Routing controller ..etc. I agree with you we > should not decompose the controller, but should look at this as one = single > entity.=20 >=20 >=20 >=20 >>=20 >> - Should QoS really be part of this work? I think not=8A >=20 > [Sri] There is QoS support in all mobility architecture. QoS is tied = to > subscription and a key function of the mobility gateway. The CP entity > should be able to provide the QoS parameters to the DP entity >=20 >=20 >>=20 >> - Why would DP be querying CP? >=20 > [Sri] Keeping the interface between CP and DP flexible allows us to > support all types of scenarios. Lets take a simple example of a DP = node > loosing state, there should be mechanism to make a query to the CP = entity. >=20 >>=20 >> - Slide 13: It's not immediately clear why we need these identifiers, = and >> how they are used. Maybe there's a solution behind them, but the = reader >> cannot get the picture. >=20 > [Sri] These are described at a high-level; Subject to change. The = draft > should have some details on the semantics and structure. >=20 >=20 >>=20 >> Thanks. >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From nobody Thu Oct 16 22:59:45 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4380F1A90C6 for ; Thu, 16 Oct 2014 22:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 QHlbMq_ql3eI for ; Thu, 16 Oct 2014 22:59:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FC81A90C3 for ; Thu, 16 Oct 2014 22:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4260; q=dns/txt; s=iport; t=1413525581; x=1414735181; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Xp0fWr7kpIWwxmLEvo2Zg4LY9ekn3w3hukGuHl6wqt8=; b=esbHh8modz85/dLGYMzCaPAYPXddaGvDZIEoaYEAosEy2QuJhNMoNhJo VBBV9yF8Rsgs5fke8jNhz+bZja0rfCita48yx08rIVvVuNpapWM2edayY +lCXv4TtUEFOC1W1Dxk8L6Ed+BcPYEv9q4qVDByDeLzuS4/domsG9eKEC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAAmvQFStJV2d/2dsb2JhbABbgw5TWATMHAyHTAKBExYBfYQDAQEEAQEBZAcEBxACAQgSBg0hJwsXDgIEDgUJEAKIJA3LCwEBAQEBAQEBAQEBAQEBAQEBAQEZjRyDMQeESwWSAIcKhE+WHIN3bIFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.04,737,1406592000"; d="scan'208";a="363805922" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 17 Oct 2014 05:59:40 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s9H5xeHD004009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 Oct 2014 05:59:40 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 00:59:40 -0500 From: "Sri Gundavelli (sgundave)" To: Alper Yegin Thread-Topic: [DMM] Forwarding Path & Signaling Management discussion Thread-Index: AQHP6RuzswbVpTGeek6d65nWzdhJkJwyStKAgAHOXwD//5IiAA== Date: Fri, 17 Oct 2014 05:59:39 +0000 Message-ID: References: <54345351.6010100@gmail.com> <52415DEA-DCE9-4EFD-B682-3E5AA83DFD65@yegin.org>

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.151.171] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/vbAYP9bXIpCBdx0ssI8gK6WJv-Q Cc: "dmm@ietf.org" Subject: Re: [DMM] Forwarding Path & Signaling Management discussion 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, 17 Oct 2014 05:59:44 -0000 Alper, Fair point on the complexity involved in getting this right. I agree with that assessment. Not having it as part of the baseline also carries the risk of getting this interface tagged as an incomplete-interface and not-ready-for-deployment. Lets see how the interface shapes up, based on that we can decide. Regards Sri =20 On 10/16/14 10:32 PM, "Alper Yegin" wrote: > >Sri, > >>> - Should QoS really be part of this work? I think not=A9 >>=20 >> [Sri] There is QoS support in all mobility architecture. QoS is tied to >> subscription and a key function of the mobility gateway. The CP entity >> should be able to provide the QoS parameters to the DP entity > >I'd say let's not deal with it in DMM WG. Or at the least, let's not >tackle it in the first phase of DMM work. >Otherwise we are making our life an order of magnitude harder from very >beginning. > >Alper > > > > > > > > > >On Oct 16, 2014, at 11:58 AM, Sri Gundavelli (sgundave) wrote: > >> Alper, >>=20 >> Inline =A9 >>=20 >>=20 >> On 10/16/14 1:32 AM, "Alper Yegin" wrote: >>=20 >>> Hello folks, >>>=20 >>> Here are few clarification questions and comments on the Forwarding >>>Path >>> & Signaling Management WT discussion material (oh, maybe it's time we >>> start numbering these WTs :-) >>>=20 >>>http://www.ietf.org/proceedings/interim/2014/10/07/dmm/slides/slides-int >>>er >>> im-2014-dmm-3-1.pdf >>>=20 >>>=20 >>> - Are we not going to support roaming? Or, even w/o roaming, I'd think >>> there'd be inter-domain signaling, e.g., DPA and DPN belonging to two >>> different networks. >>=20 >>=20 >> [Sri] I agree, Roaming should be supported. That's a good point. That >>is a >> intra-controller interface. >>=20 >>=20 >>>=20 >>> - What is the difference between DPA and DPN? We need definitions for >>> these terms. >>=20 >> [Sri]=20 >> Data Plane Anchor >> Data Plane Node >>=20 >> We had some definitions in the IETF slides that we discussed in the last >> meeting=20 >>=20 >>=20 >>>=20 >>> - Slide 8: Is this simply showing how BGP-based solutions can be >>>covered >>> here? Or something else? >>=20 >>=20 >> [Sri] The interface can be realized using multiple approaches, one being >> the BGP-based approach, other explicit signaling based interface >>=20 >>=20 >>>=20 >>> - What is the relationship between Slides 6-7-8? >>=20 >>=20 >> [Sri] I though we had some discussion on this in the last IETF. In the >> context of Forwarding path, the key point is the interface between a >> control plane entity and a data plane entity. >> May be Marco has a better explanation >>=20 >>=20 >>=20 >>>=20 >>> - What is a controller "type"? >>=20 >> [Sri] In deployments there could be controller entities on function >>basis; >> Ex: Mobility Controller, Routing controller ..etc. I agree with you we >> should not decompose the controller, but should look at this as one >>single >> entity.=20 >>=20 >>=20 >>=20 >>>=20 >>> - Should QoS really be part of this work? I think not=A9 >>=20 >> [Sri] There is QoS support in all mobility architecture. QoS is tied to >> subscription and a key function of the mobility gateway. The CP entity >> should be able to provide the QoS parameters to the DP entity >>=20 >>=20 >>>=20 >>> - Why would DP be querying CP? >>=20 >> [Sri] Keeping the interface between CP and DP flexible allows us to >> support all types of scenarios. Lets take a simple example of a DP node >> loosing state, there should be mechanism to make a query to the CP >>entity. >>=20 >>>=20 >>> - Slide 13: It's not immediately clear why we need these identifiers, >>>and >>> how they are used. Maybe there's a solution behind them, but the reader >>> cannot get the picture. >>=20 >> [Sri] These are described at a high-level; Subject to change. The draft >> should have some details on the semantics and structure. >>=20 >>=20 >>>=20 >>> Thanks. >>>=20 >>> Alper >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 > From nobody Fri Oct 17 19:14:50 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B1C11A008F for ; Fri, 17 Oct 2014 19:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id maAOUj5jJSwh for ; Fri, 17 Oct 2014 19:14:46 -0700 (PDT) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64C401A0008 for ; Fri, 17 Oct 2014 19:14:46 -0700 (PDT) Received: by mail-vc0-f170.google.com with SMTP id hy10so1443370vcb.1 for ; Fri, 17 Oct 2014 19:14:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3s+G85ku+NrM1dUIL4C91GvDGQc2gYVDqaYF/kAERPA=; b=dSJZybZQfN8zriKHwPEtZdO+5j/xW1e4kzHBoFRoBY0knz67mvBB9ABBLCoh27GTs2 +49FHd0Gh5JkXmDARjSc06O/rrTnn0NNPeF8hcbf2DbwHaLwSjQZkEUhWERZLSLtQN26 HEjvG/30AGIlDb+rPRazjGbm38yYZ/6FRoVWuzptIZzPDUjw453ODz5s6/d/vZmBojBR BRT/6VAT14LtzG7Bj1NL2EyR22xVBKTmMzmCn6U85Zj5/4cI7U+4lIURuXZrFUdykbvC t0kiZItlgRzpsRd/XV/rapPW5gvag85AoNaEaM15eUQeqV5uOa95lRUIdD0q5UHX5uRh +ddg== MIME-Version: 1.0 X-Received: by 10.221.66.12 with SMTP id xo12mr191234vcb.72.1413598485522; Fri, 17 Oct 2014 19:14:45 -0700 (PDT) Received: by 10.220.140.74 with HTTP; Fri, 17 Oct 2014 19:14:45 -0700 (PDT) In-Reply-To: References: <20140923174312.6322.91357.idtracker@ietfa.amsl.com> <5421C587.50809@computer.org> Date: Sat, 18 Oct 2014 10:14:45 +0800 Message-ID: From: Hui Deng To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=001a1136530895af9e0505a90b74 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/UREiSJ1pklP-SN1ImFdLx86-LyQ Cc: "dmm@ietf.org" Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Sat, 18 Oct 2014 02:14:48 -0000 --001a1136530895af9e0505a90b74 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable how it is related to : http://www.ietf.org/id/draft-ietf-mif-mpvd-id-00.txt -Hui 2014-10-16 17:03 GMT+08:00 Sri Gundavelli (sgundave) : > Charlie =E2=80=93 Are you asking the WG/chairs for draft adoption ? The= current > version can be a good starting point and can be taken up as the =E2=80=93= 00 version > of the WG draft. Off course, you still have plenty of comments on > additional types values that the draft still needs to address :), but the > current version can be adopted as a WG draft, IMO. > > > Sri > > > > > > From: "Charles E. Perkins" > Organization: Blue Skies > Date: Tuesday, September 23, 2014 12:09 PM > To: "dmm@ietf.org" > Subject: [DMM] Fwd: New Version Notification for > draft-perkins-dmm-4283mnids-00.txt > > Hello folks, > > We have published a ...-00 version of the MNIDs draft. This is mainly fo= r > reference purposes. A new version should be out within a week or so, > incorporating the suggestions and comments from people who responded > to the earlier suggestion to revisit this work. > > Regards, > Charlie P. > > > > -------- Original Message -------- Subject: New Version Notification for > draft-perkins-dmm-4283mnids-00.txt Date: Tue, 23 Sep 2014 10:43:12 -0700= From: >

To: Charles E. > Perkins , Vijay > Devarapalli > , Charles E.Perkins > > > A new version of I-D, draft-perkins-dmm-4283mnids-00.txt > has been successfully submitted by Charles E. Perkins and posted to the > IETF repository. > > Name: draft-perkins-dmm-4283mnids > Revision: 00 > Title: MN Identifier Types for RFC 4283 Mobile Node Identifier Option > Document date: 2014-09-23 > Group: Individual Submission > Pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-perkins-dmm-428= 3mnids-00.txt > Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mn= ids/ > Htmlized: http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00 > > > Abstract: > Additional Identifier Types are proposed for use with the Mobile Node > Identifier Option for MIPv6 (RFC 4283). > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > --001a1136530895af9e0505a90b74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

how it is related to :

http://www.ietf.org/id/draft-i= etf-mif-mpvd-id-00.txt

=C2=A0

-Hui

2014-10-16 17:03 GMT+0= 8:00 Sri Gundavelli (sgundave) <sgundave@cisco.com>:

Charlie =E2=80=93 Are you asking the WG/chairs =C2=A0for draft adoptio= n ? The current version can be a good starting point and can be taken up as= the =E2=80=9300 version of the WG draft. Off course, you still have plenty= of comments on additional types values that the draft still needs to address :), but the current version can be adopted as a WG = draft, IMO.

Sri

From: "Charles E. Perkins"= ; <charliep@c= omputer.org>
Organization: Blue Skies
Date: Tuesday, September 23, 2014 1= 2:09 PM
To: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] Fwd: New Version Not= ification for draft-perkins-dmm-4283mnids-00.txt

Hello folks,

We have published a ...-00 version of the MNIDs draft.=C2=A0 This is mainly= for
reference purposes.=C2=A0 A new version should be out within a week or so,<= br> incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.

-------- Original Message --------

Subject:	New Version Notification for draft-perkins-dmm-4283mnids-00.txt
Date:	Tue, 23 Sep 2014 10:43:12 -0700
From:	<inter= net-drafts@ietf.org>
To:	Charles E. Perkins <charliep@computer.org>, Vijay Devarapalli <unknown-email-Vijay-Devarapalli@ietfa.amsl.com>, Charles E.Perki= ns <charliep@computer.org>

A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-dmm-4283mnids
Revision:	00
Title:		MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Document date:	2014-09-23
Group:		Individual Submission
Pages:		4
URL:            http://www.ietf.org/internet-draf=
ts/draft-perkins-dmm-4283mnids-00.txt
Status:         https://datatracker.ietf.org/doc/draft-per=
kins-dmm-4283mnids/
Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4=
283mnids-00


Abstract:
   Additional Identifier Types are proposed for use with the Mobile Node
   Identifier Option for MIPv6 (RFC 4283).

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

--001a1136530895af9e0505a90b74-- From nobody Fri Oct 17 21:55:29 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296FD1A0204 for ; Fri, 17 Oct 2014 21:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 SIcVAp6lOY5W for ; Fri, 17 Oct 2014 21:55:25 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60B71A0067 for ; Fri, 17 Oct 2014 21:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12050; q=dns/txt; s=iport; t=1413608124; x=1414817724; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=m98AZMlpSRw6/Q2VwjpWnr43X3IqsEazyyYnYKNZNy0=; b=hcx3A7IrfcNt1CDA/xs17TtqLSMGjsQ7+7zPy5U/6MU10+w6UOvBYoG/ 65LzUqf5iHSCFEYpC3iZECl7dmEyDDzMavkmSOGueItrl9lNzIAPwmjAk PxIdmrHr9XETH/6EKMBgUdZeiCTRM8ZwMTUQopjsSX5PWd+HdgKfhw/Dg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAEDyQVStJA2N/2dsb2JhbABSCYJIRlNYBMoIgWYBCYdOAoEUFgF9hAIBAQEEAQEBawkCDAQCAQgRAwECKAchBgsUCQgCBA4FCYgiAxENxmMNhjEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjhmBUgcKAT8NBAcGA4RCBZIAhEaFAoIRgTA8gwqKUoZag3dsAYEOOYEDAQEB X-IronPort-AV: E=Sophos; i="5.04,743,1406592000"; d="scan'208,217"; a="88095497" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 18 Oct 2014 04:55:23 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s9I4tNIL030084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 18 Oct 2014 04:55:23 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 17 Oct 2014 23:55:23 -0500 From: "Sri Gundavelli (sgundave)" To: Hui Deng Thread-Topic: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt Thread-Index: AQHP6SATJWAh7dzZF0+d2ISrgYvKA5w1dCOA//+3hoA= Date: Sat, 18 Oct 2014 04:55:23 +0000 Message-ID: References: <20140923174312.6322.91357.idtracker@ietfa.amsl.com> <5421C587.50809@computer.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.151.171] Content-Type: multipart/alternative; boundary="_000_D0673DC316B4C2sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/QgnZrQl0OJ9p30d-bPOPHxFoFsc Cc: "dmm@ietf.org" Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Sat, 18 Oct 2014 04:55:27 -0000 --_000_D0673DC316B4C2sgundaveciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hui, May be this is for Charlie and also Vijay from the ancient history. But, le= t me try. The work in MIF is more about defining network/PVD identity. In one sense i= ts similar to the PLMN ID construct. Where as the MN-Id extensions draft is= more about generating MN-Identity based on other protocol identifiers and = other physical device identifiers. We already have IMSI-based identifier, w= hich is the IMSI-NAI; We needed similar identifier based on MAC address for= Wi-Fi, and also others identifiers based on some other sources. So, this i= s more about extending the base 4283 work with new types. Regards Sri From: Hui Deng > Date: Friday, October 17, 2014 7:14 PM To: Sri Gundavelli > Cc: "Charles E. Perkins" >, "dmm@ietf.org" = > Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283= mnids-00.txt how it is related to : http://www.ietf.org/id/draft-ietf-mif-mpvd-id-00.txt -Hui 2014-10-16 17:03 GMT+08:00 Sri Gundavelli (sgundave) >: Charlie =96 Are you asking the WG/chairs for draft adoption ? The current = version can be a good starting point and can be taken up as the =9600 versi= on of the WG draft. Off course, you still have plenty of comments on additi= onal types values that the draft still needs to address :), but the current= version can be adopted as a WG draft, IMO. Sri From: "Charles E. Perkins" > Organization: Blue Skies Date: Tuesday, September 23, 2014 12:09 PM To: "dmm@ietf.org" > Subject: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnid= s-00.txt Hello folks, We have published a ...-00 version of the MNIDs draft. This is mainly for reference purposes. A new version should be out within a week or so, incorporating the suggestions and comments from people who responded to the earlier suggestion to revisit this work. Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-perkins-dmm-4283mnids-00= .txt Date: Tue, 23 Sep 2014 10:43:12 -0700 From:

To: Charles E. Perkins , Vijay Devarapalli , Charles E.Perkins A new version of I-D, draft-perkins-dmm-4283mnids-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-dmm-4283mnids Revision: 00 Title: MN Identifier Types for RFC 4283 Mobile Node Identifier Opt= ion Document date: 2014-09-23 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283m= nids-00.txt Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnid= s/ Htmlized: http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_D0673DC316B4C2sgundaveciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <895E2A135C213043B389B8EFAE1D2EEA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Hui,

May be this is for Charlie and also Vijay from the ancient history. Bu= t, let me try.

The work in MIF is more about defining network/PVD identity. In one se= nse its similar to the PLMN ID construct. Where as the MN-Id extensions dra= ft is more about generating MN-Identity based on other protocol identifiers= and other physical device identifiers. We already have IMSI-based identifier, which is the IMSI-NAI; We needed si= milar identifier based on MAC address for Wi-Fi, and also others identifier= s based on some other sources. So, this is more about extending the base 42= 83 work with new types.

Regards

Sri

From: Hui Deng <denghui02@gmail.com>
Date: Friday, October 17, 2014 7:14= PM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: "Charles E. Perkins" = <charliep@computer.org>,= "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Fwd: New Version= Notification for draft-perkins-dmm-4283mnids-00.txt

how it is related to :

http:= //www.ietf.org/id/draft-ietf-mif-mpvd-id-00.txt

-Hui

2014-10-16 17:03 GMT+08:00 Sri Gundavelli (s= gundave) <sgundave@cisco.= com>:

Charlie =96 Are you asking the WG/chairs for draft adoption ? Th= e current version can be a good starting point and can be taken up as the = =9600 version of the WG draft. Off course, you still have plenty of comment= s on additional types values that the draft still needs to address :), but the current version can be adopted as a WG = draft, IMO.

Sri

From: "Charles E. Perkins"= ; <charliep@c= omputer.org>
Organization: Blue Skies
Date: Tuesday, September 23, 2014 1= 2:09 PM
To: "dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] Fwd: New Version Not= ification for draft-perkins-dmm-4283mnids-00.txt

Hello folks,

We have published a ...-00 version of the MNIDs draft. This is mainly= for
reference purposes. A new version should be out within a week or so,<= br> incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.

-------- Original Message --------

Subject: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Date: Tue, 23 Sep 2014 10:43:12 -0700

From: <inter= net-drafts@ietf.org>

To: Charles E. Perkins <charliep@computer.org>, Vijay Devarapalli <unknown-email-Vijay-Devarapalli@ietfa.amsl.com>, Charle= s E.Perkins <charliep@com= puter.org>

A new version of I-D, draft-perkins-dmm-4283mnids-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-dmm-4283mnids Revision: 00 Title: MN Identifier Types for RFC 4283 Mobile Node Identifier Option Document date: 2014-09-23 Group: Individual Submission Pages: 4 URL: http://www.ietf.org/internet-draf= ts/draft-perkins-dmm-4283mnids-00.txt Status: https://datatracker.ietf.org/doc/draft-per= kins-dmm-4283mnids/ Htmlized: http://tools.ietf.org/html/draft-perkins-dmm-4= 283mnids-00 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). = =20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat
_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

--_000_D0673DC316B4C2sgundaveciscocom_-- From nobody Sun Oct 19 19:47:19 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7CB1A1B17 for ; Sun, 19 Oct 2014 19:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 t80Uic3l_ML7 for ; Sun, 19 Oct 2014 19:47:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9931A1B10 for ; Sun, 19 Oct 2014 19:47:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BNV00531; Mon, 20 Oct 2014 02:47:10 +0000 (GMT) Received: from SZXEML456-HUB.china.huawei.com (10.82.67.199) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Oct 2014 03:47:10 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.109]) by szxeml456-hub.china.huawei.com ([10.82.67.199]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 10:47:09 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: enhanced anchor teleconference - notes Thread-Index: Ac/kmyIgzK7C1cuuSYGTNwAoaaSSegAAxylwAXM4azAAaTeVUA== Date: Mon, 20 Oct 2014 02:47:08 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521A9B85@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.47.151.5] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521A9B85szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/Dxnr9zEjoASdjmgSmpSFGCKmYTU Subject: [DMM] FW: enhanced anchor teleconference - notes 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, 20 Oct 2014 02:47:17 -0000 --_000_6E31144C030982429702B11D6746B98C521A9B85szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following attended the enhanced anchor team teleconference on Oct 10 at= 7-8AM pacific time. Satoru Matsushima, Fred Templin, Alper Yegin, Marco Liebsch, Kostas Pentiko= usis, Anthony Chan Anthony (AC): Introduction: Different DMM solutions are using anchors. They= are using different names for the anchor. While the names may be different= , the description of what it does ought to have similarities among. It is t= herefore suggested to first ask what are the functions of anchor and try to= identify what are common among them. We might be able to further categoriz= e different mechanisms in using the anchor. Alper (AY): Like it, define various attributes of anchors. AC: Examples are: draft-seite-dmm-dma called it MAR (mobility capable acces= s router), and the functions include forwarding by tunneling, allocating IP= prefix/addr, Advertize prefix plus location update. draft-bernardos-dmm-pm= ip called it MAAR, and the functions include forwarding by tunneling, alloc= ation IP prefix/address, prefix advertisement and location update (in conju= nction with a centralized mobility database). There are several other examp= les. AY: IP anchor is a functional entity which can be located everywhere: it al= locates IP address, and it advertise prefixes. Another element of the ancho= r is host-specific forwarding entry. Fred (FT): Do we assume a Mobile IP type of model? Can the anchor talk to M= N, or can it talk to MAG? AY: We have not talked about the distinction between network-based and host= -based protocols yet. Discussion agreed to include both network-based and host-based mobility. FT: Then for host-based solution, the traffic in the case of route optimiza= tion (directly between MN and CN) does not traverse through the above ancho= r. Marco (ML): There is also a Control-Plane anchor. AY: True. Don't enter the discussion of other WTs. AC: This discussion so far lists both data plane function and control plane= function. AY: Ok, let's recognize that there are so far two entities, Control and Dat= a Plane. They may be collocated or separated. Discussion agrees to separately list the functions in the data plane and th= ose in the control plane. It enables separating data and control planes but= it does not exclude the cases where they are combined as in the mobility p= rotocols in the past. AY: ... routers have a specific name, e.g. deflector. Host specific forward= ing entries. (FT: has to leave) ..discussion about lose definition of anchor (entity applying flow/host pol= icies for traffic), the model applies to any RO traffic case. Even endpoint= s can function as anchor (MIP6 RO). ML: multiple anchors to be considered. MAG to even CN can anchor traffic in= case of RO. AY: Can do this, but that deviates from understanding so far. AC: Another example of multiple anchors is in draft-matsushima-stateless-up= lane-vepc . Question on whether the traffic in this draft is symmetric or asymmetric (U= L/DL) AY: Discuss where such anchor function can be located. There can be multipl= e anchors, and not just a single anchor. Discussion agrees that it is not necessary to have a single anchor for a gi= ven prefix. There may be multiple anchors for the same IP prefix (as in the= case of anycast and in the case of BGP) AC: There is an information element such as binding or a mobility database = and with location update function in the control plane. AY: That is the forwarding entry. Discussions: It appears that the terms IP anchor and mobility anchor had be= en used, but they have remained undefined. ML: anchor definition moves more towards legacy function of router/switch, = which carries state for MN (per-host or aggregated). AY: draft-mccann-dmm-flatarch uses BGP. More than one router can have a per= -host state. AC: Conclusion? Time schedule is tight. Charter requires to submit first dr= aft in February. AY: Let's produce the WT output. AC: We may start with the functions of the anchor. The next may be to expla= in the different ways of using the anchor to support mobility. .. discuss Discussion agrees that Discovery mechanism is in this WT. It means discover= the identity of the anchor and its capabilities. AC: It is desirable to categorize different mechanisms of using the anchor. AY: There are 3 categories to locate the anchor, Anchoring in the MN's acce= ss network, correspondent node's network, and at the corresponding node its= elf. AY: After discovery, there is signaling. Notes taken by Marco, edited by Anthony. H Anthony Chan --_000_6E31144C030982429702B11D6746B98C521A9B85szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following attended= the enhanced anchor team teleconference on Oct 10 at 7-8AM pacific time.

Satoru Matsushima, Fre= d Templin, Alper Yegin, Marco Liebsch, Kostas Pentikousis, Anthony Chan

Anthony (AC): Introduction: Different DMM solutions = are using anchors. They are using different names for the anchor. While the= names may be different, the description of what it does ought to have simi= larities among. It is therefore suggested to first ask what are the functions of anchor and try to identify what are= common among them. We might be able to further categorize different mechan= isms in using the anchor.

Alper (AY): Like it, define various attributes of an= chors.

AC: Examples are: draft-seite-dmm-dma called it MAR = (mobility capable access router), and the functions include forwarding by t= unneling, allocating IP prefix/addr, Advertize prefix plus location update.= draft-bernardos-dmm-pmip called it MAAR, and the functions include forwarding by tunneling, allocation IP pre= fix/address, prefix advertisement and location update (in conjunction with = a centralized mobility database). There are several other examples.

AY: IP anchor is a functional entity which can be lo= cated everywhere: it allocates IP address, and it advertise prefixes. Anoth= er element of the anchor is host-specific forwarding entry.

Fred (FT): Do we assume a Mobile IP type of model? C= an the anchor talk to MN, or can it talk to MAG?

AY: We have not talked about the distinction between= network-based and host-based protocols yet.

Discussion agreed to include both network-based and = host-based mobility.

FT: Then for host-based solution, the traffic in the= case of route optimization (directly between MN and CN) does not traverse = through the above anchor.

Marco (ML): There is also a Control-Plane anchor.

AY: True. Don’t enter the discussion of other = WTs.

AC: This discussion so far lists both data plane fun= ction and control plane function.

AY: Ok, let’s recognize that there are so far = two entities, Control and Data Plane. They may be collocated or separated.<= o:p>

Discussion agrees to separately list the functions i= n the data plane and those in the control plane. It enables separating data= and control planes but it does not exclude the cases where they are combin= ed as in the mobility protocols in the past.

AY: … routers have a specific name, e.g. defle= ctor. Host specific forwarding entries.

(FT: has to leave)

..discussion about lose definition of anchor (entity= applying flow/host policies for traffic), the model applies to any RO traf= fic case. Even endpoints can function as anchor (MIP6 RO).

ML: multiple anchors to be considered. MAG to even C= N can anchor traffic in case of RO.

AY: Can do this, but that deviates from understandin= g so far.

AC: Another example of multiple anchors is in draft-= matsushima-stateless-uplane-vepc .

Question on whether the traffic in this draft is sym= metric or asymmetric (UL/DL)

AY: Discuss where such anchor function can be locate= d. There can be multiple anchors, and not just a single anchor.<= /p>

Discussion agrees that it is not necessary to have a= single anchor for a given prefix. There may be multiple anchors for the sa= me IP prefix (as in the case of anycast and in the case of BGP) =

AC: There is an information element such as binding = or a mobility database and with location update function in the control pla= ne.

AY: That is the forwarding entry.

Discussions: It appears that the terms IP anchor and= mobility anchor had been used, but they have remained undefined.

ML: anchor definition moves more towards legacy func= tion of router/switch, which carries state for MN (per-host or aggregated).=

AY: draft-mccann-dmm-flatarch uses BGP. More than on= e router can have a per-host state.

AC: Conclusion? Time schedule is tight. Charter requ= ires to submit first draft in February.

AY: Let’s produce the WT output.

AC: We may start with the functions of the anchor. T= he next may be to explain the different ways of using the anchor to support= mobility.

.. discuss

Discussion agrees that Discovery mechanism is in thi= s WT. It means discover the identity of the anchor and its capabilities.

AC: It is desirable to categorize different mechanis= ms of using the anchor.

AY: There are 3 categories to locate the anchor, Anc= horing in the MN’s access network, correspondent node’s network= , and at the corresponding node itself.

AY: After discovery, there is signaling. =

Notes taken by Marco, edited by Anthony.<= /p>

H Anthony Chan<= o:p>

--_000_6E31144C030982429702B11D6746B98C521A9B85szxeml557mbxchi_-- From nobody Sun Oct 19 19:56:32 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCDB1A1B34 for ; Sun, 19 Oct 2014 19:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 P6pjDJ4ycqmP for ; Sun, 19 Oct 2014 19:56:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4091A1B22 for ; Sun, 19 Oct 2014 19:56:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKS32692; Mon, 20 Oct 2014 02:56:28 +0000 (GMT) Received: from SZXEML451-HUB.china.huawei.com (10.82.67.194) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 20 Oct 2014 03:56:25 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.109]) by szxeml451-hub.china.huawei.com ([10.82.67.194]) with mapi id 14.03.0158.001; Mon, 20 Oct 2014 10:56:19 +0800 From: h chan To: "dmm@ietf.org" Thread-Topic: enhanced anchor description Thread-Index: Ac/kmyIgzK7C1cuuSYGTNwAoaaSSegAAxylwAXM4azAAaUKUEA== Date: Mon, 20 Oct 2014 02:56:19 +0000 Message-ID: <6E31144C030982429702B11D6746B98C521A9B8B@szxeml557-mbx.china.huawei.com> References: <69756203DDDDE64E987BC4F70B71A26D91A95156@PALLENE.office.hd> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.5] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C521A9B8Bszxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/BbaeJhDeaiwX7-G4WcOUllFC7-g Subject: [DMM] enhanced anchor description 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, 20 Oct 2014 02:56:31 -0000 --_000_6E31144C030982429702B11D6746B98C521A9B8Bszxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The following is an attempt to describe anchor (for dmm) for discussion. Different proposed dmm solutions have used anchor. The functions of an anchor common to these solutions are: (1) advertise prefix/address of the MN (2) allocate prefix/address of the MN The functions used in some proposed dmm solutions but are not common to all= of them are: (1) packets to/from the MN traverse through. Note: with multiple anchors using anycast address, a packet may or may not = traverse any one of the anchors. Note: with route optimization in the host-based MIP, the packet does not tr= averse the anchor any more. Yet the anchor does perform the above functions= . (2) indirection, e.g., tunneling (3) information, e.g., binding HoA and CoA (4) sends route update, e.g., using BGP Methods to provide mobility support using anchor: (1) indirection (2) update routing tables ... H Anthony Chan --_000_6E31144C030982429702B11D6746B98C521A9B8Bszxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The following is an at= tempt to describe anchor (for dmm) for discussion.

Different proposed dmm= solutions have used anchor.

The functions of an an= chor common to these solutions are:

(1) advertise prefix/a= ddress of the MN

(2) allocate prefix/ad= dress of the MN

The functions <= span style=3D"color:#1F497D">used in some proposed dmm solutions but are not common to all of them are:

(1) packets to/from th= e MN traverse through.

Note: with multiple an= chors using anycast address, a packet may or may not traverse any one of th= e anchors.

Note: with route optim= ization in the host-based MIP, the packet does not traverse the anchor any = more. Yet the anchor does perform the above functions.

(2) indirection, e.g.,= tunneling

(3) information, e.g.,= binding HoA and CoA

(4) sends route update= , e.g., using BGP

Methods to provide mob= ility support using anchor:

(1) indirection

(2) update routing tab= les

…

H Anthony Chan<= span style=3D"color:#1F497D">

--_000_6E31144C030982429702B11D6746B98C521A9B8Bszxeml557mbxchi_-- From nobody Mon Oct 20 09:49:02 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A79F1A8917; Mon, 20 Oct 2014 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 aFGZvAFa-dVI; Mon, 20 Oct 2014 09:48:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CA11C1A9045; Mon, 20 Oct 2014 09:35:18 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141020163518.28050.82419.idtracker@ietfa.amsl.com> Date: Mon, 20 Oct 2014 09:35:18 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_SwvKJ8FRSt2VNAmU6HrAJ3Zua0 Cc: dmm WG Subject: [DMM] WG Action: Rechartered Distributed Mobility Management (dmm) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 16:48:59 -0000 The Distributed Mobility Management (dmm) working group in the Internet Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Distributed Mobility Management (dmm) ------------------------------------------------ Current Status: Active WG Chairs: Dapeng Liu Jouni Korhonen Assigned Area Director: Brian Haberman Mailing list Address: dmm@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dmm Archive: http://www.ietf.org/mail-archive/web/dmm Charter: Mobility management solutions lie at the center of the wireless Internet and enable mobile devices to partake in IP networks anytime and anywhere. The IETF Distributed Mobility Management (DMM) working group (WG) specifies solutions for IP networks so that traffic between mobile and correspondent nodes can take an optimal route. DMM solutions aim for transparency above the IP layer, including maintenance of active transport level sessions when mobile hosts or mobile networks change their point of attachment to the Internet. Wireless network deployments have traditionally relied on hierarchical schemes that often lead to centralized deployment models, where a small number of mobility anchors manage both mobility and reachability for a mobile node. The DMM WG will consider the latest developments in mobile networking research and operational practice (i.e. flattening network architectures, the impact of virtualization, new deployment needs as wireless access technologies evolve in the coming years) and will describe how distributed mobility management addresses the new needs in this area better than previously standardized solutions. A topic of particular focus will be mobility anchoring in this new context, and the DMM working group is chartered to work on maintenance-oriented extensions of the Mobile IPv6 protocol family (RFC 5213, RFC 5844, RFC 5555, RFC 5568, and RFC 6275) as well as new approaches which capitalize on other protocols specified by the IETF. For example, mobility management in a limited area, such as within an autonomous system, is not strictly limited to mentioned IP mobility protocols but can be any existing or a new protocol solution enabling the movement of a mobile node such as routing protocols. When extending protocols that are not based on Mobile IP, DMM solutions will have to be reviewed by the corresponding WGs. IPv6 is assumed to be present in both the mobile host/router and the access networks. DMM solutions are primarily targeted at IPv6 deployments and are not required to support IPv4, in particular for the case where private IPv4 addresses and/or NATs are used. DMM solutions must maintain backward compatibility: If the network or the mobile host/router does not support the distributed mobility management protocol that should not prevent the mobile host/router gaining basic access (i.e., nomadic) to the network. Contrary to earlier IP mobility protocols, mobility management signaling paths and end-user traffic forwarding paths may differ. Further, mobility-related functions may be located in separate network nodes. DMM solutions should not distinguish between physical or virtualized networking functions. Whenever applicable, clarifications and additional features/capabilities for specific networking function deployment models, e.g. in virtualized environments, are in-scope and encouraged. Solutions may also specify the selection between the care-of addresses and home address(es)/prefix(es) for different application use cases. The working group will produce one or more documents on the following work item topics. o Distributed mobility management deployment models and scenarios: describe the target high-level network architectures and deployment models where distributed mobility management protocol solutions would apply. o Enhanced mobility anchoring: define protocol solutions for a gateway and mobility anchor assignment and mid-session mobility anchor switching that go beyond what has been specified, for example, in RFC 6097, 6463, and 5142. Traffic steering associated with the anchor switch is also in-scope if deemed appropriate. o Forwarding path and signaling management: the function that handles mobility management signaling interacts with the DMM network elements for managing the forwarding state associated with a mobile node's IP traffic. These two functions may or may not be collocated. Furthermore, the forwarding state may also be distributed into multiple network elements instead of a single network element (e.g., anchor). Protocol extensions or new protocols will be specified to allow the above mentioned forwarding path and signalling management. o Exposing mobility state to mobile nodes and network nodes: define solutions that allow, for example, mobile nodes to select either a care-of address or a home address depending on an application' mobility needs. In order to enable this functionality, the network-side control functions and other networking nodes must also be able to exchange appropriate control information, as well as to the mobile nodes and their applications. The working group may decide to extend the current milestones based on the new information and knowledge gained during working on other documents listed in the initial milestones. Possible new documents and milestones must still fit into the overall DMM charter scope as outlined above. Milestones: Feb 2015 - Submit 'Enhanced mobility anchoring' as a working group document. Feb 2015 - Submit 'Forwarding path and signaling management' as a working group document. May 2015 - Submit 'Exposing mobility state to mobile nodes and network nodes' as a working group document(s). Nov 2015 - Submit 'Enhanced mobility anchoring' submitted to the IESG. Nov 2015 - Submit 'Forwarding path and signaling management' submitted to the IESG. Feb 2016 - Submit 'Exposing mobility state to mobile nodes and network nodes' submitted to the IESG. From nobody Mon Oct 20 11:16:40 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274DC1A8AD7 for ; Mon, 20 Oct 2014 11:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZxyux8PABbl for ; Mon, 20 Oct 2014 11:16:35 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 939131A8ADC for ; Mon, 20 Oct 2014 11:16:11 -0700 (PDT) Received: by mail-ig0-f182.google.com with SMTP id hn15so5112903igb.15 for ; Mon, 20 Oct 2014 11:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type; bh=bNJLkUE+eQC/Z5L2qucAfsNIMtjyLeBjD9RDlw61xo8=; b=FdlrD/e3DX1w08gpa6goDHTOGKKgdkbT9MYpnnEJASn5Kal3VPEi+FKBQn0qUOUNOI EHcvhU1iqBV06xM9jq8c0CahIG7aZrlpqIGIpSyHSuRZiA5yO47FkDzRn7HBpYugUBxV xuKdjvdJzYkLxWtZjpYJz4BfJldIJAvtzC7vkNL0XCV3YY1a5mZWRjJuISAoiI3bRZwa 2ktfJDRSzBfRB4P+mrS6ZhOwWJYXavv9RPqFOV2PDroh5PgDeTkuxsz/LK44onzzgDJW uSHzff2Ox1Zz9xC3HXRdFj6qoVIIM+4UHJRThWGbzsaPB/xdjGkQKnPqBhrEMK05U8y/ 5l0g== MIME-Version: 1.0 X-Received: by 10.42.100.84 with SMTP id z20mr29028476icn.31.1413828970200; Mon, 20 Oct 2014 11:16:10 -0700 (PDT) Received: by 10.107.175.22 with HTTP; Mon, 20 Oct 2014 11:16:10 -0700 (PDT) Date: Mon, 20 Oct 2014 13:16:10 -0500 Message-ID: From: Behcet Sarikaya To: "Templin, Fred L" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/_Ri7N1QswOqwFn_7BWvvAVvMyIQ Cc: "dmm@ietf.org" Subject: Re: [DMM] AERO and Mobile IP comparison X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Oct 2014 18:16:37 -0000 Hi Fred, I think your draft is now Rev. 44 at https://tools.ietf.org/html/draft-templin-aerolink-44 I don't really have any comments on the text. But if you have been wondering why AERO reminds people Mobile IP or Proxy Mobile IP or MOBIKE? I classify those protocols as 20th century protocols. It seems like AERO is very much like them. I think that in dmm maybe we should look into 21st century protocols. That may mean designing with new concepts like control plane/data plane separation, virtualization, as in vEPC, cloud, and SDN control. Regards, Behcet On Tue, Oct 7, 2014 at 4:20 PM, Templin, Fred L wrote: > Hi Charlie, > >> -----Original Message----- >> From: Charlie Perkins [mailto:charles.perkins@earthlink.net] >> Sent: Tuesday, October 07, 2014 1:25 PM >> To: Templin, Fred L; dmm@ietf.org >> Subject: Re: [DMM] AERO and Mobile IP comparison >> >> Hello Fred, >> >> A few little follow-up questions... >> >> On 10/7/2014 11:39 AM, Templin, Fred L wrote: >> >> From: Charlie Perkins [mailto:charles.perkins@earthlink.net] >> >> >> >> ... >> >> This implies local-only mobility, right? >> > Not just local, but global also. Take for example an AERO mobile router that is connecting >> > over an access link provided by some ISP other than its home network. In that case, the >> > node typically remains connected to its home link by setting up a VPN connection via a >> > security gateway connected to its home network. In that case, the AERO link is said to >> > be extended *through* the security gateway. So, the AERO mobile router remains >> > tethered to its home link via the VPN, but it can set up route optimization with Internet >> > correspondents in a manner similar to MIPv6. In that case, communications with the >> > Internet correspondent can bypass the home network. >> >> - Is the VPN setup part of AERO? > > The AERO Client requests a DHCPv6 Prefix Delegation as part of the VPN setup. The > security gateway (acting as an AERO Server) delegates the prefix and sets up a > neighbor cache entry for the Client. > >> - How does the mobile router know whether or not to do this? > > The AERO Client needs to know whether it is connecting to an access link provided by > the home network or by an ISP outside of the home network. One way of doing this is > to examine the connection-specific DNS suffix the Client gets when it connects to the > access link and comparing it to the home network DNS suffix. > > When I think about my laptop computer user experience, I have to perform a manual > intervention to select a security gateway and set up the VPN when I am connecting via > an Internet access link. That would be OK and compatible with AERO as well, but would > be much better if it were automated. Whether it can be fully automated depends on > what kind of security credentials are necessary to establish the VPN, e.g., whether > certificates alone are sufficient or whether some kind of active badge needs to be > swiped, etc. Do you know more about this? > >> - Why would the external AERO servers admit traffic from the AERO client? > > The external AERO Servers are security gateways that also delegate AERO Client > Prefixes (ACPs) to Clients using DHCPv6 PD. During PD, the Server performs an > additional layer of authentication for the Client above and beyond what is done > for establishing the VPN. So, the Server has a way of knowing that the Client is > permitted to source packets from the delegated ACP. > >> Or, is AERO completely out of the picture for external networks? > > External networks as in something that does not have hard perimeters with > security gateways - maybe like a university campus network? I'll have to think > more about that, but in that case there may need to be some other trust basis > besides source address verification and IPsec tunnels. Any ideas? > >> - Is the route optimization simply a matter of VPN to the correspondent >> node? > > VPN to the correspondent node (triggered by AERO mechanisms) is certainly > a use case that we don't want to rule out. > >> Or, did you mean to suggest use of the MIPv6 mechanisms? > > For communications with correspondents that do not require IPsec protection, > the mechanism is the same as the MIPv6 Return Routability, only using IPv6 > ND messaging for signaling. Otherwise, I just studied the RR procedure in > RFC6275 and pretty much borrowed what I saw there for AERO. > > Thanks - Fred > fred.l.templin@boeing.com > >> Regards, >> Charlie P. >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Mon Oct 20 11:36:42 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAB21A902A for ; Mon, 20 Oct 2014 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 zmCKps9c3IqC for ; Mon, 20 Oct 2014 11:36:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BE91A8AF1 for ; Mon, 20 Oct 2014 11:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=468; q=dns/txt; s=iport; t=1413830198; x=1415039798; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0Vc8/NVEe2gsXQIBUknPJ0tW+jwwVUlmTfx3NzJKJPI=; b=Milxe6VecCkfHLkyTqkeJkkQTc+ZRw3Syj44RrZrcEOzKfwJ0X1O5TYH Kfj+xdeHKsTQC1R+Ogi+BRjPXTOZ28GTN+li/yj5FWB7ljb48Ku4l2rta iEVlGxWOl597wzpF1T7wkpYT6pa9Gp9lsGxRieVii5OO52r4TTeY9esAk Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAJlVRVStJA2K/2dsb2JhbABcgw5TWATMK4dNAoETFgF9hAMCAgI6PxIBCDYxESUCBA4FiCsDEQ2yaYwSDYYuAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSOHYI0B4RLAQSSAYRGhQKCEY9IhlqDd2wBgUeBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,757,1406592000"; d="scan'208";a="365062620" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 20 Oct 2014 18:36:38 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s9KIaa3x000300 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Oct 2014 18:36:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.11]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 20 Oct 2014 13:36:36 -0500 From: "Sri Gundavelli (sgundave)" To: "sarikaya@ieee.org" , "Templin, Fred L" Thread-Topic: [DMM] AERO and Mobile IP comparison Thread-Index: AQHP7JTHozqvGlJe5kG9nGWZFHmwRQ== Date: Mon, 20 Oct 2014 18:36:35 +0000 Message-ID: In-Reply-To: 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.218] Content-Type: text/plain; charset="us-ascii" Content-ID: <77923E7A5A8AEE42ADB8348E74D75A01@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/vzXWtHdCCkOVm5xT7zbmL1_Eiic Cc: "dmm@ietf.org" Subject: Re: [DMM] AERO and Mobile IP comparison 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, 20 Oct 2014 18:36:39 -0000 +1 on the below comment; (for a change). Per the offline discussions and the approaches reflected in https://tools.ietf.org/agenda/90/slides/slides-90-dmm-10.pdf On 10/20/14 11:16 AM, "Behcet Sarikaya"

Thanks,

Dapeng Liu&am= p;Jouni

=20

=E5=9C=A8 2014=E5=B9=B4= 10=E6=9C=8823=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=9B=9B=EF=BC=8C10:05=EF=BC=8C= Jouni Korhonen =E5=86=99=E9=81=93=EF=BC=9A

Just a reminder.

<= /div>
10/9/2014 3:25 PM, Jouni Korhonen kirjoitti:
=46olks,

Honolulu mee= ting is getting close.. we have asked for a 2.5h
slot. Hopeful= ly we are by then already executing our new
charter.
=
We will have updates from work teams (and also reserve tim= e for
discussions)

We will accept pres= entations (that fall into the charter scope)
selectively. So fe= el free to ask for a slot. Note that during
the interims some t= opics have already been presented in detail
and those are not l= ikely to be repeated during the f2f meeting.

- J= ouni & Dapeng

=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
dmm mail= ing list
dmm=40ietf.org
ht= tps://www.ietf.org/mailman/listinfo/dmm
=20 =20 =20 =20

=20

--5449ef74_721da317_1fc-- From nobody Fri Oct 24 02:42:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DE81AD94A for ; Fri, 24 Oct 2014 02:42:55 -0700 (PDT) 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 SUdTW4qAEb_M for ; Fri, 24 Oct 2014 02:42:53 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96D61AD944 for ; Fri, 24 Oct 2014 02:42:52 -0700 (PDT) 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 s9O9goZ0018310 for ; Fri, 24 Oct 2014 11:42:50 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2AC7E203CBB for ; Fri, 24 Oct 2014 11:44:19 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 17BF1203B17 for ; Fri, 24 Oct 2014 11:44:19 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s9O9gSQO025145 for ; Fri, 24 Oct 2014 11:42:50 +0200 Message-ID: <544A1F04.3070505@gmail.com> Date: Fri, 24 Oct 2014 11:42:28 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: dmm@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/gWmTtJ5COtzRHtUbi0c4wH1Q9P4 Subject: Re: [DMM] offlisted mails - names of Work Teams 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, 24 Oct 2014 09:42:55 -0000 I agree with this request from Behcet because it may give greater visibility. I am interested about what is happening in each of the teams, although I also think they need a level of separation from the rest of the world. What are the names of the work teams? 1 - Mobility Exposure 2 - Forwarding Path and Signalling Management 3 - Enhanced Anchor Is this correct? Alex Le 23/10/2014 22:03, Behcet Sarikaya a �crit : > Hi all, > > If you send me an email related to dmm issues and you do not wish the > mail to be cc'ed or forwarded to the list, > please MARK your mail clearly on the subject line as offlisted. > You may wish to send the mail to 20 or so other people, I don't care. > > Otherwise I may inadvertently cc it to the list. > > Let this be known. > > Regards, > > Behcet > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Fri Oct 24 06:42:20 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BE51A0065 for ; Fri, 24 Oct 2014 06:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGSyIYck4sXH for ; Fri, 24 Oct 2014 06:42:14 -0700 (PDT) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5320F1A00E9 for ; Fri, 24 Oct 2014 06:41:58 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hy4so249022vcb.38 for ; Fri, 24 Oct 2014 06:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=10xu1sX4fPVKoWJkIiSc3qnbcGn4tdXY6benca16vII=; b=QH5x54k4j2iF1wANQAbKT05w+Ruyk4c36roQ0HZkSqiU8jitqSCigNj46u/lJQT3Ou 4gWndexJ+Kzj/TXPkLtlaR6DcXfHdf3BUQxMSFsdphMEr7ScndwmqIFedxwQ7prT/tyj uuNPdtabVUWsqUwwOuLr2eP3vNWAXNP1LI/TOxUtcoE2PuES3o/tnbkL5dxsSD69ruA+ 7mH1y0n6/jxBlKOpalxoHSGiWH3IXAHgLiwuMcJ39LLPoXnoeulPaoQUW9rDnVkkkA7n n9yD6zLYhfYm2A+lhiKnGT1ZPQ1NfCPJX/osdJxHoPdtXyZL0Ji/aecORtOEinkS01fs dj2Q== MIME-Version: 1.0 X-Received: by 10.53.13.7 with SMTP id eu7mr545977vdd.40.1414158117459; Fri, 24 Oct 2014 06:41:57 -0700 (PDT) Received: by 10.220.140.74 with HTTP; Fri, 24 Oct 2014 06:41:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 Oct 2014 21:41:57 +0800 Message-ID: From: Hui Deng To: "Sri Gundavelli (sgundave)" Content-Type: multipart/alternative; boundary=001a1133ec243f5b6d05062b588a Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/DU6SU_ocHqB_B7_GiRAAxKl_Z8o Cc: "dmm@ietf.org" Subject: Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.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: Fri, 24 Oct 2014 13:42:15 -0000 --001a1133ec243f5b6d05062b588a Content-Type: text/plain; charset=UTF-8 Hi Sri, ok, thanks, -Hui 2014-10-23 23:49 GMT+08:00 Sri Gundavelli (sgundave) : > Probably not. Its not updating RFC4283. Its defining new type values and > certainly it can be done in a separate document. > > May be Chairs have a better view. > > > Sri > > From: Hui Deng > Date: Wednesday, October 22, 2014 7:09 PM > To: Sri Gundavelli > Cc: "Charles E. Perkins" , "dmm@ietf.org" < > dmm@ietf.org> > Subject: Re: [DMM] Fwd: New Version Notification for > draft-perkins-dmm-4283mnids-00.txt > > thanks for your explaination, > wouldn't that be RFC 4283bis? > > -Hui > > 2014-10-18 12:55 GMT+08:00 Sri Gundavelli (sgundave) : > >> Hi Hui, >> >> May be this is for Charlie and also Vijay from the ancient history. >> But, let me try. >> >> The work in MIF is more about defining network/PVD identity. In one >> sense its similar to the PLMN ID construct. Where as the MN-Id extensions >> draft is more about generating MN-Identity based on other protocol >> identifiers and other physical device identifiers. We already have >> IMSI-based identifier, which is the IMSI-NAI; We needed similar identifier >> based on MAC address for Wi-Fi, and also others identifiers based on some >> other sources. So, this is more about extending the base 4283 work with new >> types. >> >> >> Regards >> Sri >> >> --001a1133ec243f5b6d05062b588a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Sri,

=C2=A0

ok, thanks,

=C2=A0

-Hui

2014-10-23 23:49 GMT+08:00 Sri Gundavelli (sgundave) <= span dir=3D"ltr"><sgundave@cisco.com>:

Probably not. Its not updating RFC4283. Its defining new type values a= nd certainly it can be done in a separate document.

May be Chairs have a better view.

Sri

From: Hui Deng <denghui02@gmail.com>
Date: Wednesday, October 22, 2014 7= :09 PM
To: Sri Gundavelli <sgundave@cisco.com>
Cc: "Charles E. Perkins" = <charliep@com= puter.org>, "= dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Fwd: New Version= Notification for draft-perkins-dmm-4283mnids-00.txt

thanks for your explaination,

wouldn't that be RFC 4283bis?

=C2=A0

-Hui

2014-10-18 12:55 GMT+08:00 Sri Gundavelli (sgund= ave)=C2=A0<sgundave@cisco.com>:

Hi Hui,

May be this is for Charlie and also Vijay from the ancient history. Bu= t, let me try.

The work in MIF is more about defining network/PVD identity. In one se= nse its similar to the PLMN ID construct. Where as the MN-Id extensions dra= ft is more about generating MN-Identity based on other protocol identifiers= and other physical device identifiers. We already have IMSI-based identifier, which is the IMSI-NAI; We needed si= milar identifier based on MAC address for Wi-Fi, and also others identifier= s based on some other sources. So, this is more about extending the base 42= 83 work with new types.

Regards

Sri

--001a1133ec243f5b6d05062b588a-- From nobody Fri Oct 24 06:50:57 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4F41A0121 for ; Fri, 24 Oct 2014 06:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4Fw6SQ2-RWV for ; Fri, 24 Oct 2014 06:50:40 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4E71A009E for ; Fri, 24 Oct 2014 06:50:19 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id gm9so1220471lab.32 for ; Fri, 24 Oct 2014 06:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=biuO+Cm59995tLgRDEN2N+1Nsw/9ztrutPkzepc0+mw=; b=FHiuqCRgzYTcN+cfpfo4ulYMWEzTaUIw87HM12QbxSHhHBB8G6ZkypHnLtk60mqHdm K6nnnJ3raMJaMXPKZiZprWkjDCXE9Tfl5G/8Ff8juzQXPY0loJGjOpbkLMzGi7Bn2zoo PCQlmwfyy7aigT+TGbuhJ9oZ+gTxp+5Yu6MAfVg0k0ux4MNvIUId40kJ67+t8RT1+OGl xHW7H8b+3hFpp6RnVrmyqOJZI79R0mu+sEldKU9RlLAcW5IzpZJqaI01Ycl+bB84tZ3V WOUo/T3e5ETiUAchndkew9T9sLvS4fdCzAYHYfDZ8VaCVpqLViFx4QAqsJW95xXxW/rk sZtw== X-Received: by 10.112.133.138 with SMTP id pc10mr4755630lbb.48.1414158617920; Fri, 24 Oct 2014 06:50:17 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id pr7sm1883266lbc.18.2014.10.24.06.50.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 06:50:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: <544A1F04.3070505@gmail.com> Date: Fri, 24 Oct 2014 16:50:14 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544A1F04.3070505@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/CjO654vr1OoSqsTOfyy00shxPA0 Cc: dmm@ietf.org Subject: Re: [DMM] offlisted mails - names of Work Teams 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, 24 Oct 2014 13:50:43 -0000 On Oct 24, 2014, at 12:42 PM, Alexandru Petrescu wrote: > I agree with this request from Behcet because it may give greater = visibility. >=20 > I am interested about what is happening in each of the teams, although = I also think they need a level of separation from the rest of the world. Could you open a bit what you actually mean.. > What are the names of the work teams? > 1 - Mobility Exposure > 2 - Forwarding Path and Signalling Management > 3 - Enhanced Anchor >=20 > Is this correct? http://www.ietf.org/mail-archive/web/dmm/current/msg01623.html http://www.ietf.org/mail-archive/web/dmm/current/msg01662.html - Jouni >=20 > Alex >=20 > Le 23/10/2014 22:03, Behcet Sarikaya a =E9crit : >> Hi all, >>=20 >> If you send me an email related to dmm issues and you do not wish the >> mail to be cc'ed or forwarded to the list, >> please MARK your mail clearly on the subject line as offlisted. >> You may wish to send the mail to 20 or so other people, I don't care. >>=20 >> Otherwise I may inadvertently cc it to the list. >>=20 >> Let this be known. >>=20 >> Regards, >>=20 >> Behcet >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Oct 24 07:01:03 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3C11A014A for ; Fri, 24 Oct 2014 07:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 bpi5_hr0oLy4 for ; Fri, 24 Oct 2014 07:00:58 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4580D1A011B for ; Fri, 24 Oct 2014 07:00:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1350E108650 for ; Fri, 24 Oct 2014 16:00:57 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyA53nYvrVJr for ; Fri, 24 Oct 2014 16:00:56 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted 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 C14EC10864A for ; Fri, 24 Oct 2014 16:00:54 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.4]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 24 Oct 2014 16:00:54 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: [FPSM] work item call#2 Thread-Index: Ac/vkTP95sU6y/ptQhOs7cl4bUnpUA== Date: Fri, 24 Oct 2014 14:00:54 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91AD4CE1@DAPHNIS.office.hd> 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: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D91AD4CE1DAPHNISofficehd_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/CFH1KezdiwsUU94_jiDquvZmZ-Y Subject: [DMM] [FPSM] work item call#2 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, 24 Oct 2014 14:01:01 -0000 --_000_69756203DDDDE64E987BC4F70B71A26D91AD4CE1DAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, the clear winner for our next telco on the work item about Forwarding Path = and Signaling Management is Monday, 3rd November 2014, 16:00 CET. Duration: 90min. I will send an agenda around before the meeting. If you would like to see a particular item on the agenda, please let me kno= w. Best regards, marco --_000_69756203DDDDE64E987BC4F70B71A26D91AD4CE1DAPHNISofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

the clear winner for our next telco on the work item= about Forwarding Path and Signaling Management
is Monday, 3^rd November 2014, 16:00 CET.

Duration: 90min.

I will send an agenda around before the meeting.

If you would like to see a particular item on the ag= enda, please let me know.

Best regards,

marco

--_000_69756203DDDDE64E987BC4F70B71A26D91AD4CE1DAPHNISofficehd_-- From nobody Fri Oct 24 08:01:04 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC01E1A1A02 for ; Fri, 24 Oct 2014 08:01:00 -0700 (PDT) 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 9UMtbCzGDXVi for ; Fri, 24 Oct 2014 08:00:56 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A722D1A1A1B for ; Fri, 24 Oct 2014 08:00:54 -0700 (PDT) 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 s9OF0n6p015512; Fri, 24 Oct 2014 17:00:49 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B0921209041; Fri, 24 Oct 2014 17:02:18 +0200 (CEST) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id A4A76203FB9; Fri, 24 Oct 2014 17:02:18 +0200 (CEST) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s9OF0XnX003451; Fri, 24 Oct 2014 17:00:49 +0200 Message-ID: <544A6991.4090303@gmail.com> Date: Fri, 24 Oct 2014 17:00:33 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jouni References: <544A1F04.3070505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/83HfDtzx2p9VXh4rDmu_UwVlhCY Cc: dmm@ietf.org Subject: Re: [DMM] offlisted mails - names of Work Teams 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, 24 Oct 2014 15:01:01 -0000 Le 24/10/2014 15:50, Jouni a �crit : > > On Oct 24, 2014, at 12:42 PM, Alexandru Petrescu wrote: > >> I agree with this request from Behcet because it may give greater >> visibility. >> >> I am interested about what is happening in each of the teams, >> although I also think they need a level of separation from the rest >> of the world. > > Could you open a bit what you actually mean... Jouni - with all due respect, I think it is you who needs to explain, not me :-) Anyways, here's why some more explanation is needed: the situation is uncommon: 3 work teams (instead of 1 design team), frequent audio-conferences w/o audiologs (instead of frequent emails logged). If one tries, is one allowed to participate to the audioconferences? Or are the work teams completely closed groups? Does each of these groups also exchange private emails? Do they use private email lists expanders instead of lists of names? Are these emails archived? Are these email exchanges open for reading now? That said, I also agree that these groups may indeed need to be a little bit separated from each other and maybe from everybody else in order to focus. But under no circumstances should they become unaccountable with respect to the WG at large. >> What are the names of the work teams? 1 - Mobility Exposure 2 - >> Forwarding Path and Signalling Management 3 - Enhanced Anchor >> >> Is this correct? > > http://www.ietf.org/mail-archive/web/dmm/current/msg01623.html > http://www.ietf.org/mail-archive/web/dmm/current/msg01662.html Thanks for the pointers, that's what I needed. One would notice differences between what you think and what they think the names are. "forwarding path and signaling.." Forwarding Path and Signaling Management "enhanced mobility anchoring.." Enhanced Anchor "exposing mobility state.." Mobility Exposure Which one is led by Sri? That will help me understand this: 'Sri will take the lead for "Distributed mobility management deployment models and scenarios" work item.' As you see - everything may be clear for you, but not for me :-) Alex > > - Jouni > > >> >> Alex >> >> Le 23/10/2014 22:03, Behcet Sarikaya a �crit : >>> Hi all, >>> >>> If you send me an email related to dmm issues and you do not wish >>> the mail to be cc'ed or forwarded to the list, please MARK your >>> mail clearly on the subject line as offlisted. You may wish to >>> send the mail to 20 or so other people, I don't care. >>> >>> Otherwise I may inadvertently cc it to the list. >>> >>> Let this be known. >>> >>> 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 > > > From nobody Fri Oct 24 09:18:34 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890501A1F73 for ; Fri, 24 Oct 2014 09:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwemtWTWwN0g for ; Fri, 24 Oct 2014 09:18:32 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930A21A6F12 for ; Fri, 24 Oct 2014 09:17:52 -0700 (PDT) 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 7577488120 for ; Fri, 24 Oct 2014 09:17:52 -0700 (PDT) Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 31A171368226 for ; Fri, 24 Oct 2014 09:17:52 -0700 (PDT) Message-ID: <544A7BA9.3060105@innovationslab.net> Date: Fri, 24 Oct 2014 12:17:45 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dmm@ietf.org References: <544A1F04.3070505@gmail.com> <544A6991.4090303@gmail.com> In-Reply-To: <544A6991.4090303@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1x2umiq5Ric22rfvuawQiiOAcCfHE4PgU" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/1L3ywA37lbRTWt2F3ROEiibTZ7o Subject: Re: [DMM] offlisted mails - names of Work Teams 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, 24 Oct 2014 16:18:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1x2umiq5Ric22rfvuawQiiOAcCfHE4PgU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex (and others), On 10/24/14 11:00 AM, Alexandru Petrescu wrote: > But under no circumstances should they become unaccountable with > respect to the WG at large. Please (re-)read what I posted about these teams a little while ago. http://www.ietf.org/mail-archive/web/dmm/current/msg01627.html Regards, Brian --1x2umiq5Ric22rfvuawQiiOAcCfHE4PgU 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 iQEcBAEBCgAGBQJUSnuvAAoJEBOZRqCi7goqTpMIAMx+tHO7sla6/4xDWx9Z+JWu /s3mXhvL3Ty3ruLZjRfMA9lL3fg1z/zuuuL2HeKHBqTyst3WUjO3TkBSmM8IXwij HLHgsrp7M5IhoZF1dusuUyDDuvnYypMZ15jFyuai8IJ0Yu8nETy96DZdHneeDtcs rOqX+nlolEmw672l2YtfSk0UnjsDFkw/zXv3xTVrNwKTAMORE8spJZWa++mNe53F /3dza1NTwD8+fJKa6JfsPqpkwLMpnZX2+GmvsNngFwKEauoSa08pYXyBQkSPVxaW m99BmeOvz/iXfQIWd6QB8DDyRVzu89HN27LI60xdmMVrtYxkiU0LP1rMzHIo7zQ= =G/dS -----END PGP SIGNATURE----- --1x2umiq5Ric22rfvuawQiiOAcCfHE4PgU-- From nobody Fri Oct 24 09:20:37 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0D51A1B87 for ; Fri, 24 Oct 2014 09:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Y0NpUldNtFsS for ; Fri, 24 Oct 2014 09:20:21 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E391A1B64 for ; Fri, 24 Oct 2014 09:20:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E848210864B for ; Fri, 24 Oct 2014 18:20:11 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHMIwcUNccWf for ; Fri, 24 Oct 2014 18:20:11 +0200 (CEST) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted 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 BD8D010864A for ; Fri, 24 Oct 2014 18:20:09 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.4]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Fri, 24 Oct 2014 18:20:09 +0200 From: Marco Liebsch To: "dmm@ietf.org" Thread-Topic: [FPSM] notes from call#1 Thread-Index: Ac/vpiPBB+Cny/x9QLSXoQyQvY4ZrQ== Date: Fri, 24 Oct 2014 16:20:08 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D91AD4E08@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: multipart/related; boundary="_004_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/sSU7ddnuGffCw2hmqXF8l0N6S10 Subject: [DMM] [FPSM] notes from call#1 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, 24 Oct 2014 16:20:24 -0000 --_004_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_ Content-Type: multipart/alternative; boundary="_000_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_" --_000_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please find below some notes from last telco about the DMM work item Forwar= ding Path and Signaling Management. Best regards, marco --- notes from telco 2014-10-19: --- Check if everybody is on the same page w.r.t. objectives. Associated charter item has been read and focus of work item (WI) has been = summarized and agreed upon: --> This work item is about the specification of the C-/D-Plane reference i= nterface and semantics without being specific to a particular protocol Discussion about illustration of WI scope. Figure [cid:image003.jpg@01CFED4F.7807A540] Comments and conclusions from discussion: Provide examples for a Controller: LMA-C, MAG-C, OpenFlow-C Example for multiple-controller space: MAG-C and LMA-C, can use PMIPv6 as i= nter-controller protocol. Type of controller should not matter for the generic specification in this = WI. Controller, which is responsible for a particular D-Plane function, must be= unambiguous. Multiple controllers must be synchronized (prerequisite). (marco's note: Ma= ybe we should look at this again, as we may not mandate this in any case) Agreement that roaming should be addressed. May imply inter-controller comm= unication (Home-Foreign network controller). However, specification of the inter-controller interface is out of scope. Focus is the interface between controller(s) and Data Plane Node (DPN). This work assumes that each entity, which requires mobility management, kno= ws how to contact a controller. ? Need to differentiate DPA, DPN and other transport nodes, such as routers= and switches, which terminate the specified interface? ! So far yes Need to provide a clear definition of terms 'DPA' and 'DPN' in the specific= ation. Proposals: DPA owns IP address (?) DPN just performs routing. Discussion about IP address 'ownership' at DPA. No need that IP address fit= s into the DPA's network. Better: DPA must receive traffic from a foreign network Discussion about special role of BGP Speakers on control and data plane nod= e, in case BGP is used as protocol base to implement this specification. No clear 'policy control' and 'policy enforcement' role= s. No concerns with this, just an observation. ? Is this work tailored to a specific solution? ! No, it's a utility. May be used to enable any deployment where Control- a= nd Data-Plane are separated. Agreed procedure: Progress the specification and description of the generic= protocol interface. Authors of existing and new solution drafts should confirm that this specification supports their proto= col. Another WI telco before IETF91? Supported! Find suitable date/time through doodle. --- end of telco --- --_000_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Please find below some notes from last telco about t= he DMM work item Forwarding Path and Signaling Management.

Best regards,

marco

--- notes from telco 2014-10-19: ---

Check if everybody is on the same page w.r.t. object= ives.

Associated charter item has been read and focus of w= ork item (WI) has been summarized and agreed upon:

=E0 Thi= s work item is about the specification of the C-/D-Plane reference interface and semantics wi= thout being specific to a particular protocol

Discussion about illustration of WI scope.

Figure

3D"cid:image003.jpg@01C=

Comments and conclusions from discussion:=

Provide examples for a Controller: LMA-C, MAG-C, Ope= nFlow-C

Example for multiple-controller space: MAG-C and LMA= -C, can use PMIPv6 as inter-controller protocol.

Type of controller should not matter for the generic= specification in this WI.

Controller, which is responsible for a particular D-= Plane function, must be unambiguous.

Multiple controllers must be synchronized (prerequis= ite). (marco’s note: Maybe we should look at this again, as we
may not mandate this in any case)

Agreement that roaming should be addressed. May impl= y inter-controller communication (Home-Foreign network controller).
However, specification of the inter-controller interface is out of scope. Focus is the interface between controller(s) and Data Plane Node (DPN).

This work assumes that each entity, which requires m= obility management, knows how to contact a controller.

? Need to differentiate DPA, DPN and other transport= nodes, such as routers and switches, which terminate
the specified interface?

! So far yes

Need to provide a clear definition of terms ‘D= PA’ and ‘DPN’ in the specification.

Proposals:

DPA owns IP address (?)=

DPN just performs routi= ng.

Discussion about IP address ‘ownership’ = at DPA. No need that IP address fits into the DPA’s network.

Better:

DPA must receive traffi= c from a foreign network

Discussion about special role of BGP Speakers on con= trol and data plane node, in case BGP is used as protocol base to implement=
this specification. No clear ‘policy control’ and ‘policy= enforcement’ roles. No concerns with this, just an observation.=

? Is this work tailored to a specific solution?=

! No, it’s a utility. May be used to enable an= y deployment where Control- and Data-Plane are separated.

Agreed procedure: Progress the specification and des= cription of the generic protocol interface. Authors of existing and new
solution drafts should confirm that this specification supports their proto= col.

Another WI telco before IETF91? Supported!

Find suitable date/time through doodle.

--- end of telco ---

--_000_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_-- --_004_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9334; creation-date="Fri, 24 Oct 2014 16:20:08 GMT"; modification-date="Fri, 24 Oct 2014 16:20:08 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/2wBDAQsLCw8NDx0QEB09KSMpPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT3/wAARCACjAfEDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAazBEZmOFUZJNQ pNM6o3kDDKTw449PzqSc4gkOcYU84zjj071lm0hv9VdbjdIqWsTKA7KASz5OAe+B+VMDR82fbn7P zszjePven/16GlnG7EGcYx8459fyqt/YVh/zxf8A7+v/AI0f2FYf88X/AO/r/wCNAFoyTbiPI43g Z3j7vr/9agSTErmDALEE7xwOxqr/AGFYf88X/wC/r/40f2FYf88X/wC/r/40gLIlnIXNvgkEn5xw ew/GjzZ9pP2cZ2ZxvH3vT/69Vv7CsP8Ani//AH9f/Gj+wrD/AJ4v/wB/X/xpgWmkmG7EGcYx8459 fyo8ybcR5HG/Gd4+76//AFqq/wBhWH/PF/8Av6/+NH9hWH/PF/8Av6/+NIC0skxK5gwCSD844HY/ jSCWchc2+CVJI3jg9hVb+wrD/ni//f1/8aP7CsP+eL/9/X/xoAsmWfBIt8naCBvHX0/+vStJMN22 DOMY+cc+v5VV/sKw/wCeL/8Af1/8aP7CsP8Ani//AH9f/GmBa8ybdjyeN+M7x931/wDrULJMSuYM ZJB+ccDsfxqr/YVh/wA8X/7+v/jR/YVh/wA8X/7+v/jSAsiWcgZt8EqSRvHB7D/69BlnAOLfJCgg bxye4/8Ar1W/sKw/54v/AN/X/wAaP7CsP+eL/wDf1/8AGmBaaSYbtsGcEY+ccjv+VHmTbseTxvxn ePu+v/1qq/2FYf8APF/+/r/40f2FYf8APF/+/r/40gLSyTHbugxknPzjj0/OkEs+Bm3AOwkjeOD6 f/Xqt/YVh/zxf/v6/wDjR/YVh/zxf/v6/wDjQBZMs4Bxb5IUEDeOT3FK0kwLbYMgEAfOOR3P4VV/ sKw/54v/AN/X/wAaP7CsP+eL/wDf1/8AGmBa8ybdjyON+M7x93+9/wDWpFlnO3dBjOc/OOPT86rf 2FYf88X/AO/r/wCNH9hWH/PF/wDv6/8AjSAsiWfaCbcZ2ZxvH3vT/wCvQZZwGxb5IUEDeOT3H4VW /sKw/wCeL/8Af1/8aP7CsP8Ani//AH9f/GmBaMkwLAQZAYAHeOR3NPjcupLIUIYjB9j1/GsuXT7e xvtPe2V0Z5yrfvGII8tzjBPqBWjbABHwqr+8c/K2f4j+tAE1FFFIAooooAKKKKACiiigAooooAKK KKACiiigAooooAKKKKACiiigAooooAK5m31yZdPiu5LhHuLibyTbuVVLcl8c8buMYOepPaumqI2s DGQtDGTIMOSg+b6+tAHPw+J7meRAttB5YaJJG8w8l5XjBXjlcrn3BqC18VXoslluIbaUx2QupWiY jJLFQoHOMYyT29K6kRRgACNQAAAAOmOn5UiwRJu2Rou7OcKBnPWgDnrfXbiXWxFIDIkUUqutt86y MDFhl78ByD+NU7nUtXIu545nW2iujCWYJgfvkVQmOehYHd+FdbHDFEFEcaIFBACqBgU7y0wRsXBO SMd6EBzcXiqa7uTb2kUDs0yJHIzMFKsshyRjP/LP8c1JpXiabVL+GJLPbC6KXbdypaMPn3HO3171 vJbwxklIo1JO4kKBk+v60CCJZA4iQOF2hgoyB6Z9KAJKKKKACiiigBk2fJkxuztP3ev4e9UbbP8A bM2d2fskP3uv3pOtXZhmCQAEkqeAcE8etUbdguszBjtP2SHhjz96SgDSopvmJ/eX86PMT+8v50AO opvmJ/eX86PMT+8v50AOopvmJ/eX86PMT+8v50AOopvmJ/eX86PMT+8v50AOopvmJ/eX86PMT+8v 50Ac54tv5bSfTo5L2bT9NmeQXV5FgFCFyi7iCFBOecdsd6yv+ExvrW9s7OEC8iaKEq88LRz3YcNu kUAAKEwCwI/LjPceYn95fzo8xP7y/nQB55/wl2vXCae0zWVqsk1lLI6ROV8qZXJQ5PGCoGfcVI3j jW4LGwuLi1sg13E08aBJP3mGVRAvP+sOScnj2PJrv/MT+8v50eYn95fzoA8tXxtrumx3cu37US6o pufljh/eXHUjHUIi9fTr37bw9q2pateXzXUNvBbW7rEsYDGTcURySxOMDcRwO1bnmJ/eX86PMT+8 v50AOopvmJ/eX86PMT+8v50AOopvmJ/eX86PMT+8v50AOopvmJ/eX86PMT+8v50AOopvmJ/eX86P MT+8v50AOopvmJ/eX86PMT+8v50AU7//AI+9N/6+T/6Kkqxa4KPgof3j/cHH3j19/Wq186m800Bg T9pPf/plJVm2bcj/ADbv3jD7u3ueP/r96AJqKKKACiiigAooooAKKKKACiiigAooooAKKKKACiii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigBkyl4ZFChiVI2k4zVJ7W3uEjNzp iSOsXG9EYr/s5J/+tWhRQBmnTbABv+JPCcAHiGPnPb8KDpmngkf2RAcMBkQx8+/0rSooAzRpmnkg f2RAMsVz5MfA9fp+tA0ywO3/AIk8AyD1hj4x/jWlRQBm/wBm2GM/2PD93djyY+vp16/p70HTLAbv +JPCcAHiGPnP+FaVFAGadM08Ej+yIDhgufJj5Hr9P1oGmaeSB/ZEAyxXJhj4Hr9P1rSooAzRptgQ v/EnhGQTzDHxjt+NH9m2GM/2PD93djyY+vp16/p71pUUAZp0ywG7/iTwHGMYhj5z/hQdM0/JH9kQ cNtz5MfI9fp+vtWXqxY6rOBM8YG3gzFR07DBqphv+fs/+BJ/+Jq+UnmN8aZp5IH9kQDLEZMMfHv9 KBptgQD/AGPCMgnBhj4x2/GsDDf8/Z/8CT/8TRhv+fs/+BJ/+Jo5Q5jf/s2wwT/Y8P3d2PJj6+nX r+nvQ2mWA3Y0eA4xjEMfOfT6VgYb/n7P/gSf/iat6UWGqwAzvIDuGBMWH3T1GBRyhzGp/Zmn5I/s iD723Pkx9PX6fr7UDTNPJA/siAZJGTDHx7/jWlRUFGaNNsCAf7HhGVJwYY+Pb6mg6bYAE/2PCcKG x5MfX069f0rSooAzTpmnjdjR4DjGMQx85/wo/szT84/siD7+3Pkx9P730/X2rSooAzRpmnnbnR4B kkHMMfGP8aBptgQD/Y8IypbBhj4Pp16/pWlRQBmHTbAAn+xoThQ2BDHyfTr1/SlbTNPG7GjwHBAG IY+c/wCFaVFAFGGytLeYSQaZHG4baHSNAQP72Qc4/X2qzbhvLJcOCWY4cjIGfbtUtFABRRRQAUUU UAFFFFABRRRQAUUUlAC0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF ABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBgXkay6ndb9x2lQPmIx8o96j+zRf3W/wC+2/xq a4/5Cd3/ALy/+gim022KxH9mi/ut/wB9t/jR9mi/ut/323+NSUUXYWRH9mi/ut/323+NSWcaxana 7NwyzA/MTn5T70U63/5CVp/vN/6AaE2FjdooopDCimSTRwjMsiIPVjiq/wDaVu2fKLzH/pkhb9Rx SuilCUtkW6Kqfabl/wDVWbAHvK4X+WTRsvpPvTQxD/YQsfzJ/pRcfs+7X9ehbpkk0cIzLIiD1ZgK r/YN/wDrri4k9t+0fkuKfHYWsRykEYb+8Vyfzo1C0Fu/6/ryGf2lbnIiLzEf88kLfqOKztbsv7Qf S5Ps8p/0pRIMkER7WzuwemcfpW5RQrik4tWSOPgj1W2hhh8qWSFpzJteAHyv9J7d/uHPPpkYrQtx qOqeHL2G4aVLwArHNgoHYAEMowpA3cYI7Hk9a6CimT1ON01dVudSje4hvY4bxjqDLJkCAqpQQn0z +7bHs1Tol/pukaddQrctdyxRLdRlS0jbUwFBIIU5JJzjPPIrq6KAOe1G51mK51B7YSGGNoFiURj7 px5jg7SWIHscehqpLfa/HGyqGmlNozJ5cBAVwCQW3KMk8DAI5/h711lFAHGX8mqXt5JdQrfQpHvW OSOEq3l+ZAehHOQH7ZIBqzDNrEUkhjSSOFJSwQW4AlBuGBJ4z/q8NxjrmuqooQM5jw3q97qUd49x OfM8lZIozGCFzu+YbQMqcDAJJ4PrVQ6xrG2CHdcLcmGVlAtw3nurIF/hBVDuI5APvxk9dFBFBu8m JI9xy2xQMn1NP2ruDYG4DGcc4oA5Vb/XvMlMyvHH54SQRwlmiTefmT5MMCuP73XPHSqd7aahcXE8 wt5nWNLlo1NsNsjbItpZSOWPzfkR6129FAHL3Go6pHYzlVvPtZldRGkHyRAFthB2HcCAvryR93tV ebW1d5linmud/mpHJDlIgbb+E44+fIxn2712VFAHKy3etuJfssly0KJM8Ur2wDylUQqCpUY+YsOg JA/GuojZmiRmGGIBI9DTqKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiig AooooAKKKKACiiigAooooAKr3lsbqHYs8sDA5Dxtg/8A1xViigDn5orqz/4+Z7jZ/wA9UlO38f7v 48e9H7w8/arnH/XU1vkZGD0rOuNJUZezYRMeTGfuH8O34flVXFYoImws252Zzlmdsk9qdTWZo5BF OhikPQN0b6HoadSYwpGZUUszBVHUk4ApaCARgjI96QEH22E8RlpT6RoW/wDrU13mlKmO3lQqcq7S hCOMdsnvVqmBmkkMUCGWUdVXov1PQUkmXzRXT7/6RBsv2+9fPGP9hmb9Sf6U6Czur0YhvL2Ve8rz FU/Dbjd+H51pwaQDh71hKe0Y+4P/AIr8fyrSAAAAGAO1MXO+mhR0/R7ewjxzNITkyS/M34egq/RR QJtvdhRRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoqN5kjdVZsMwJAx6daZ9sgKg7+Cm/ofu+t FgJ6KgN5AoYl+FAY8HoelKbqFSQX5Vgp4PU9KLBcmoqEXUJIAfkvs6H73pSLdwttw/3s44PbrRYL k9FQfbINud/Gzf0P3fWg3kChiX+6ATweh6U7MLk9FQm6hBIL8hgh4PU9KBdQlgA/JYoOD1FKwE1F QLeQMFIf7wJHB6DrR9sg2538bN/Q/d9adguSTQxzxmOZFdD1DDNZc+mTQZa1Yyx/883PzD6N3+h/ OtBruFd2X+6ATweM9KU3UIYgvyHCHg9T2o1EYiSK5ZeQ6/eRhhl+ooeRUIByWb7qKMs30Fadylne 7RJ9/cUR1BDAjrg/5FJaLZWqgwnLSKWMjAlmA65P9KLBcrwaZNPhrljDH/zzQ/Mfq3b8PzrThhjt 4xHCiog6BRTPtkAXO/jZv6H7vrQ13Cu7L/dxng9+lGoE9FQ/aodxG/kPs6H73pQt3CxUB+WYqOD1 HWlYZNRUAvIGCkPwylhweg60G8gCkl+Am/ofu+tOzC5PRULXcK7tz424zweM9KPtUO7G/nf5fQ/e 9KVguTUVCt3CxUB+WJUcHqOtILyBgCH4Klxweg607BcnoqA3kABJfgIHPB6HoaVruFd258bSAeD3 6UWYXJqKh+1Q5xv53+X0P3vShbuFtuH+8SBwe3WlYCaioBeQEAh+CpccHoOtBvIACS/AUOeD0PSn ZhcnoqFruFSwL8qQp4PU9KPtUO7G/nf5fQ/e9KVgJqKhW7hbbh87s44PbrSC8gKg7+Cm/ofu+tOw XJ6KgN5AoYl+FUMeD0PSlN3CpYF+VYKeD1PSiwXJqKZHKkoYowbaxU47EdafSAKKKKACiiigAooo oAKKKKACiiigAooooAKKK5Z9YuYtQuG+2B/L1AW/2UquPK2KSeBuyMls57UAdTRXJweLJ7m5hKm1 jtllZZXYN86+UJFK9wcE/lVq18SSXumXsixESQ7wsqLlOIw4Jz0+8OvpQB0VFcbHrGpWTWdxqFwy 28sTyIJQu5v3a/e2DpuPGOfWrUPiu4mCOLWEIuPNy5zzOYflGPbPP096dtbCvpc6iisbQdam1jzW ktvKjADId3PJI2kdcjH059q2aQwooooAKKKKAIQD9sY7Wx5YGd3HU9v61NUAA+3McJnyxzn5up7e lecfEfW9S03xDFFZX1xBGbdWKxuQM7m5qKtRU48zMqtVUo8zPTqK+e5/HGtQXUcLatd/MCSfOOR6 cfhSL471ttn/ABMr4Fhn/Xjgcc9ffpWH1pWvZmH1xWvyv8D6For52X4g6w0YcalqG3cFyZSAPfNW Lfxrrdw8qLql6pjOCDKefem8SlvFhLGKOriz6BorzH4c63qeo+IpIr2+uJ4xbswSRyRnK816dWtO oqkeZG9KqqseZBRRRWhqFFZniO9m07w9e3VswWaKMshIzg/SvMf+FheIP+fqP/vyv+FdFHDTrJuJ zV8VTotKfU9horx7/hYPiH/n6j/78r/hR/wsHxD/AM/Uf/flf8K2/s6t5GP9pUfM9horx7/hYXiD /n6j/wC/K/4Uf8LC8Qf8/Uf/AH5X/Cj+zq3kH9pUfM9horP0G6lvtCsbm4YNLLCruQMZJHpWhXE1 Z2O5O6uFFFVr7UrPTIDPf3UNtEP45XCj9aEnJ2QyzWdrurDRdKkuvKM0g+WOMHG9j0Gazl+IHhd5 TGNatdw7kkD8yMVe1FYtW0xJbWRJ4wwkVoyGDcEcEfWt1RnTnH2sWl53RnUm1BuOrPO9f8W+IprI 3WmamlswA821NqAyk/3HO4MPrj6VVtPiZqWi2SS6tqUeo3bqGWzS22BR/tScYPXgA1qa9cTvCYCy LEv8AXaD7kDqfrXGahdaheWh0oKt6rfLFGYBJJHyOEb7yjjp0r6fC4ejVpqMqatfyvb1t/k/M4ae Jcnue6aNqkOtaPa6jbhliuIw4Vuo9jV2uc8PNF4V8F6bDrVxBaPDCFfzJAAD1x7nmlT4geF3lMY1 q1DDuSQPzIxXzU8NOU5exi3FN2aVz0E9NToqKjguIbqFZreVJYnGVdGDA/iKkrlasUFFZ2vyzW+g 3txbzvDLBC8quoU8hSRnIIxWYNduLVbpJXjZbd4oUklJLyu6q/IUAD72PwoA6SiuXt/FlxciGVbS EQyCIYMuG3PEZBzjAAIxn3z2ph8XzCOM+Tb+YI3eVGcq25GUFFHdvm65I6evAB1dFcvJ4ruFVjHb QM0jbY0MhBjxMsX7zjjO7Ix6Ee9WE1q8gstbnuRbSNYORHHHlcgIG+YnPXPWgDoKK5m48T3Ns08U kNsJbbzWcmQhZAgQ7U4+8Q4/L3qtceKrhL3zlSPyVjmUW4b5wwljjDSDsOSfoaAOvorBsvEFxNf2 tvdW6QCcFQQ24s43dh93hc8+vXIreoAhgJJlyXP7w43jGOB09qmqGAEGbKuMyEjc2c8Dp6CpqGAU UUUAFFFFABRRRQAVBeXkNhbNPcFhGpC/KpYkkgAADk5JFT1S1fThqunNalgoZ0Y5GQQrhiPxxigB 0Op2lxAsscwwxYBW+VsqSGG085BByKW21G1u4IZY5lAljWVVYgNtbGCR+NYSeESlxGTcBoY/lRDu BRRIzpjB5I3YOeuBTLfwWI0ZJrgSgwhVc7gUfy1TIGcY+UEf5NAHS/aIRIsfnR72JAXcMkjrxUUm p2UWzzLuBd8nlLmQcvjO364rFPhm5L2Ra8jIhdZpsR43y7y7MOe+cYPTFEHhQ2qWnkyQbrdbcYMW FYxhwT17h/0oA2ZtSghvksz5jTuu/akbMAucZJAwBn1qC61LTbDFyzQtJLIsAMe0szHouf159Kiv NIkn1+DUUMDCOLyisgOV+bOQQf51Tt/CawLZqssWLcW+QIsbjFvyfqd/6UAbAawjRgDaqkT/ADcq Aje/oacstlbxyIr28aR43gFQFz0z6ZrBi8IsDbiaaFkt2iAAi/1io5bL88sc9fr61JP4ZmkhMQnh 2pctcIdhDSbi2Vcg8438Y9BQBtSz2YJjmktwVXlXZeAeOnpyKXdaRlo8wKUUFl4G0Z447DNYP/CG wjPzREb2I3R7iAYBEBknJxjNM/4Q0sJ1kuFk8wDDOGOPubgRnBHyf5xQBvRXdgLoQQzW/nzKZQqM MuM4LcdfrSR6nbS3c9upfdA22RihCK2AcbsYzhh+dUrLQmsdVF2jxFMzArswVDuGGD7HP51Hc+Gx cJqh88iS9lWRSS21NoTAK5weU69eaANhrmFGVWmjDMdoBYZJ9PrUU2pWcEixy3UKyO/lqpcZLYJ2 /XArEPhSSXzZJ54WmkEh3CLhGaUScc9sY/WpU8OzRpAvmWzfZ7hpUdojucNvB3HPX5+vqPehgbMV 7BKqfOqO8Yk8tyAwX1IpRd25VWE8RVm2A7xgt6fX2rm08HSJai2+1RFAn+s8s793k+Vtzn7nfH4V NJ4WdZFe2nihZZEdWWP7gCIrYGcHOzoR6elAG6CPtzDKZ8scY+bqe/pXlXxU/wCRnh/69V/9CavV g3+msu4/6sHbt46nnP8ASuQ8YeBrvxJq6XcF1BCiwiPa4JOQSe31rHEwc6donNioSqUnGO55FsVj yqknGcj06VQN3DGgY2iqoYmM8ckNtJ9q9O/4VNqH/QRtf++WqBfg1coxZby0BJzna/XOf51wxw9R bx/r7zzoYWqvij+P/BPOY7u3cqhtgpYqQCo5JOM1eWNELFVVSxySBjNd23wfvHfe17aFshslW6jp T/8AhU2of9BG1/75alLD1HsvxCeFqv4Y/iV/hZ/yNEv/AF7N/wChLXrlcT4P8DXfhvV3vJ7uCZGi Me1AQckg9/pXbV3YeDhTtI9HCQlTpKMtwooorc6TF8Y/8ilqX/XE/wA68Tr3PxHZTaj4fvbS2UNN LHtQE4BP1rzP/hXniD/n3h/7/LXqYCtCnFqTseVmFGpUlFwVzi9QilkaLy0ldQHyI32kHA2nqO9Q fY70CaTzWMj5QLuIGDj5s54xz0Fd3/wrzxB/z7w/9/lo/wCFeeIP+feH/v8ALXVKpQk23M5I0sRF JKByVoJRaxrOMSKNp5znHfNTV0//AArzxB/z7w/9/lo/4V54g/594f8Av8tarE0UrcyMnhazd+Rn pPhb/kVtM/690/lWtWfoVpLY6FZWtwoWWGFUcA5wQPWtCvnpayZ9HBWigrz3UbC6m167v21BICWa PEvzJ5YbG3aQQenSvQqxdX0E325oJFVm5KsOK6MJVVObu7X02uYYmNRxXJ0PJW0+ysdfluIZLC1L Z8mSa13RRtxg7Mnb9TkD0rT+G99qifEO7tb3UFu1nty8jRSB45CNu0jHHAOK1r34e6pdvhTaKCep c8fpW34O8AQeGbt7+e4+03zpsBUbUjU9cDvnA5r3sRjsO8PNSlzScbLS7+/oZ0FU+0jqprO2uDma 3hkP+2gP86SCytrUk29vDET18tAv8qnor5jmdrXOyy3PPL6wuptbvL99QSEuWjIlG9DGGIC7SDnp 0+tcb9gs7DXZri3lsbR2z5Ek1tuijbPB25O36ndj0r1rV9Aa93NBIqs3JVxxXH3vw91S7bCm0QH+ IueP0r6DA4ymo2nO2lun+Wp53LXjPVX1Mv4Z32pr4/v7S9v1ulmtzJI0UgeN2G3DAjjocV6/XI+D vAMHhe5kvZpzcX0ieXuA2oi5yQB74HJrrq8/NK9KvX5qW1ktrbeR3001HUgvbmG0tHluMmMYUgDJ JJwBjvkkCmSzWRSRZZLfaCBIGK4z2B9+P0qLWbWW7sAtuoaWOaKZVJwG2OGxn6Csx/DDKoaF7cyf aLiVhJFlW80nqM8kA9fr615xZszz2drBJLO8EcUQJdmIAXA7/QVCkOltPFOgtTJHFmMgjCoTnIHT GR1rGPhCTa0AvENuVfl48uWaARZJzjtmkuPCD3f2szTRZuYivAbEbGMRkBc4K4GcH1oA6GNrOSQi IwM8gDnaQSwHQ+/1pZGto5GEhhV5FyQxALAfzArKn0m6tdSkvtN8hS0YTySCFc8AE88bQD93GelS aloX9oakk5dEiaIxTDBJkTDDac8fxZzjP50AXrmS1jjLyIkhR87QAW3ccj3HFRxXem3EbTQy2siy s0ZZSp3kcFfc8dKxF8ITtFIJ72OR3iGW8r/lruXc/XuqKMexqzbeHZrW7WVJbdlBlXa0R4V5N+Rz ww6fgPShgaNpeadPZxXsDQJFsUK52qUBAIU+nUcVLdajbWas0sg+VkVwDkpuIAJHYZPWsBvBpEMC RTxjyYokKBCqyFEdSTg9w/6Ut14YnWC7itXQQ3KJF5Yye6gyEsSchV6Dr9aAOhtwA02FUZkJ+Vs5 4HJ9D7VPUFsQWmwY/wDWHOwew6+9T0MEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAQtFIbhZEmKptwyEZB9/Y0gjuABmdSQpB/d9T2PX9KnoouBAY7jBxOoO0 AHy/4vXr+lKyTndtmUZIx8nT1796moouBDsmz/rlxvzjZ/D6df1oCTgrmZTgnPydR279qmoouBAI 7jAzOpO0gny+p7Hr+lBjuMHE6g7QAfL6Huev6VPRTuBCyTndiZRkjHydB3796Nk27PnLjfnGz+H0 6/rU1FICFY5xt3TKcZz+76+nftSCO4wMzrnaQT5f8Xr1/Sp6KLgQGOfDYnUEqAP3fQ9z1/SlKTkt iZQCRj5Og7jr3qaii4EOybd/rlxvzjZ/D6df1oWOcbd0ynGc/u+vp37VNRRcCAR3GB+/XOzGfL/i 9ev6UGOchsTqCVAH7voe561PRRcCEpOS2JlALAgbOg7jrQEmyMzLjeSRs/h9Ov61NRQBCsc427pl OM5/d9fTv2pPLuMD9+udmM+X/F69f0qeii4EBjnIbE6gkDH7voe5696UpPk4mUAsCBs6DuOv61NR RcCEJNkZmUjcSRs6r2HX9aBHOAuZ1OAc/u+p7d+1TUUXAg8u42/69c7MZ8v+L16/pSmOc7sTqMgY /d9PXv3qaincCEpPk4mUDcCBs6L6df1oCTZGZlI3EkbOo7Dr+tTUUgIBHOAuZ1JAOf3fU9u/ajy7 jb/r1zsxny/4vXr+lT0U7gQtHOd22ZRnGP3fT1796Ck24/vlxvBA2fw+nX9amopXAhCTgrmZSAxJ GzqOw60gjuAFzOpIUg/u+p7HrU9FFwIDHcbTidc7MZ8v+L16/pStHOd22ZRnGP3fT1796moouBHE jJv3Nu3MSOAMD0qSiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAP/2Q== --_004_69756203DDDDE64E987BC4F70B71A26D91AD4E08DAPHNISofficehd_-- From nobody Fri Oct 24 09:46:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD461A802A for ; Fri, 24 Oct 2014 09:46:55 -0700 (PDT) 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 FfYwwUVqKAKe for ; Fri, 24 Oct 2014 09:46:49 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614F61A7025 for ; Fri, 24 Oct 2014 09:46:48 -0700 (PDT) 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 s9OGkjYO009737 for ; Fri, 24 Oct 2014 18:46:46 +0200 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E90CD20918F for ; Fri, 24 Oct 2014 18:48:14 +0200 (CEST) Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id DA6F4203FA1 for ; Fri, 24 Oct 2014 18:48:14 +0200 (CEST) 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 s9OGkYAQ027395 for ; Fri, 24 Oct 2014 18:46:45 +0200 Message-ID: <544A826A.4020607@gmail.com> Date: Fri, 24 Oct 2014 18:46:34 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: dmm@ietf.org References: <544A1F04.3070505@gmail.com> <544A6991.4090303@gmail.com> <544A7BA9.3060105@innovationslab.net> In-Reply-To: <544A7BA9.3060105@innovationslab.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/mMl-igT2s1963NwZ3LE23GO_RnY Subject: Re: [DMM] offlisted mails - names of Work Teams 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, 24 Oct 2014 16:46:55 -0000 Le 24/10/2014 18:17, Brian Haberman a �crit : > Alex (and others), > > On 10/24/14 11:00 AM, Alexandru Petrescu wrote: >> But under no circumstances should they become unaccountable with >> respect to the WG at large. > > Please (re-)read what I posted about these teams a little while ago. > > http://www.ietf.org/mail-archive/web/dmm/current/msg01627.html Thank you for the pointer, I've read and re-read it at the time. It increased my confidence to re-think again the same thing: we dont know whether these are Design Teams RFC2418, or something else. I dont know what to expect as output. I dont know what does this mean to the future of Mobile IP? Are the 3 teams going to produce a competitor to Mobile IP? Is Mobile IP becoming Historic? Is Mobile IP Network Mobility taken into account in these teams? Is Network Mobility considered from the start, or as an afterthought (like NEMO after Mobile IP, PrefixDelegationPMIP after PMIP)? Are the earlier RFCs considered? My remarks to the Charter proposal got rejected in this respect. Alex > > Regards, > Brian > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From nobody Fri Oct 24 10:08:25 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FA51A1A28 for ; Fri, 24 Oct 2014 10:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 B19nekUyXHaM for ; Fri, 24 Oct 2014 10:08:10 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A5F1A8898 for ; Fri, 24 Oct 2014 10:03:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s9OH3J2N010013; Fri, 24 Oct 2014 10:03:19 -0700 Received: from XCH-BLV-302.nw.nos.boeing.com (xch-blv-302.nw.nos.boeing.com [130.247.25.214]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s9OH3A8S009944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Fri, 24 Oct 2014 10:03:11 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-BLV-302.nw.nos.boeing.com ([169.254.2.104]) with mapi id 14.03.0210.002; Fri, 24 Oct 2014 10:03:09 -0700 From: "Templin, Fred L" To: Alexandru Petrescu , "dmm@ietf.org" Thread-Topic: [DMM] offlisted mails - names of Work Teams Thread-Index: AQHP76o09u+E6ad8GEy7aU1OvjpJDZw/eOfg Date: Fri, 24 Oct 2014 17:03:08 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D578ED@XCH-BLV-504.nw.nos.boeing.com> References: <544A1F04.3070505@gmail.com> <544A6991.4090303@gmail.com> <544A7BA9.3060105@innovationslab.net> <544A826A.4020607@gmail.com> In-Reply-To: <544A826A.4020607@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/8O5oMvseRBbZv_u7Skxs6qPFCOo Subject: Re: [DMM] offlisted mails - names of Work Teams 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, 24 Oct 2014 17:08:13 -0000 Hi Alex, > -----Original Message----- > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Alexandru Petrescu > Sent: Friday, October 24, 2014 9:47 AM > To: dmm@ietf.org > Subject: Re: [DMM] offlisted mails - names of Work Teams >=20 > Le 24/10/2014 18:17, Brian Haberman a =E9crit : > > Alex (and others), > > > > On 10/24/14 11:00 AM, Alexandru Petrescu wrote: > >> But under no circumstances should they become unaccountable with > >> respect to the WG at large. > > > > Please (re-)read what I posted about these teams a little while ago. > > > > http://www.ietf.org/mail-archive/web/dmm/current/msg01627.html >=20 > Thank you for the pointer, I've read and re-read it at the time. >=20 > It increased my confidence to re-think again the same thing: we dont > know whether these are Design Teams RFC2418, or something else. >=20 > I dont know what to expect as output. >=20 > I dont know what does this mean to the future of Mobile IP? >=20 > Are the 3 teams going to produce a competitor to Mobile IP? Is Mobile > IP becoming Historic? >=20 > Is Mobile IP Network Mobility taken into account in these teams? >=20 > Is Network Mobility considered from the start, or as an afterthought > (like NEMO after Mobile IP, PrefixDelegationPMIP after PMIP)? >=20 > Are the earlier RFCs considered? >=20 > My remarks to the Charter proposal got rejected in this respect. Based on what I can tell, these three focused areas are still calling for a= n IP mobility protocol. It could be based on MIP/PMIP, or on some new protocol like AERO. Thanks - Fred fred.l.templin@boeing.com > Alex >=20 > > > > Regards, > > Brian > > > > > > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Oct 24 10:51:36 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE361A89A4 for ; Fri, 24 Oct 2014 10:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR2w8xOUN7CZ for ; Fri, 24 Oct 2014 10:51:31 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53C51A89EF for ; Fri, 24 Oct 2014 10:51:30 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so3116144lab.33 for ; Fri, 24 Oct 2014 10:51:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Lgk8RTg3cmTdZOmfmAuSJmQxVM/v+9kwO0gsrDb1cDI=; b=AtWbelZT4JO//D2J01nszr2X0tDvYQUSUEyDsZxRlvMUHI0Nd9FFjR8MdhsCnKH2hm QnDz93i6KploPWEf7Ka/eQ4WrxwH+JX3liXSGJyYZnJiqSgv7FBwLsOzQlxMFnPj/N6A OYUkiUKsPeCjDNqrVJsJe0EwHZmDGKgZtf+3Y7nxaf6dDktdQri+iLl9tU9Q2UFffAo3 suBU8KMK6Q8QoEkPb7FzmcZtTTXUlSllkHyKlQUgX0CpkqLmvqlibUkRm29f3EuOC1LZ WL7L4qiveffKGpDZ7TXANeSVuIZfTnghl6GUQ2UlRUQYt+360uwIZe1qBxIIF74+Wxwh GMLQ== X-Received: by 10.152.30.9 with SMTP id o9mr6191858lah.8.1414173089169; Fri, 24 Oct 2014 10:51:29 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id pf1sm2082582lbc.0.2014.10.24.10.51.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 10:51:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Jouni In-Reply-To: <544A826A.4020607@gmail.com> Date: Fri, 24 Oct 2014 20:51:24 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544A1F04.3070505@gmail.com> <544A6991.4090303@gmail.com> <544A7BA9.3060105@innovationslab.net> <544A826A.4020607@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1283) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/PNWGnZIeBGUoGOIEBXbtPmauy-o Cc: dmm@ietf.org Subject: Re: [DMM] offlisted mails - names of Work Teams 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, 24 Oct 2014 17:51:34 -0000 Ok.. once more.=20 On Oct 24, 2014, at 7:46 PM, Alexandru Petrescu wrote: > Le 24/10/2014 18:17, Brian Haberman a =E9crit : >> Alex (and others), >>=20 >> On 10/24/14 11:00 AM, Alexandru Petrescu wrote: >>> But under no circumstances should they become unaccountable with >>> respect to the WG at large. >>=20 >> Please (re-)read what I posted about these teams a little while ago. >>=20 >> http://www.ietf.org/mail-archive/web/dmm/current/msg01627.html >=20 > Thank you for the pointer, I've read and re-read it at the time. Good. > It increased my confidence to re-think again the same thing: we dont = know whether these are Design Teams RFC2418, or something else. Does it matter? We have 4 chartered work items. Chairs decided to = delegate the work and called for volunteers to take a lead for running = facilitator duties on each work item. If you want to call them design = teams, you are free to do so. Chairs decided to call them as working = team since construction of those is less formal than typically with = design teams. > I dont know what to expect as output. Maybe re-re-read the pointed mails? "The working teams, if they so manage, will produce the solution I-D(s). = These documents will be equivalent to any individual produced I-D, = though." I personally hope, in a chair role, that working teams will produce = solution I-Ds with a wide support behind each of them. > I dont know what does this mean to the future of Mobile IP? To be seen. Is that an issue? DMM WG still has the maintenance role of = MIP. The charter allows us to abandon MIP as a DMM solution if the WG so = decides or the WG can decide to build everything on top of MIP. You are = free to steer the public opinion & solution space by contributing. The = whole process is contribution driven. > Are the 3 teams going to produce a competitor to Mobile IP? Is Mobile = IP becoming Historic? I have no idea. Why not joining to some of those working team calls or = read the call minutes and find out? By participating and contributing = you can steer the fate of MIP. For contribution you have two basic = approaches: 1) write your own I-D (possibly co-authored with other = people) or 2) join working teams, drive your ideas there and contribute = to their possible output I-Ds. > Is Mobile IP Network Mobility taken into account in these teams? If you have concerns on the lack of visibility of nemo, join the team(s) = and make sure your concerns get addressed. > Is Network Mobility considered from the start, or as an afterthought = (like NEMO after Mobile IP, PrefixDelegationPMIP after PMIP)? Up to WG and working teams to decide. NEMO is not excluded in the = charter. > Are the earlier RFCs considered? I would assume so but cannot speak for other people and their plans. > My remarks to the Charter proposal got rejected in this respect. Because NEMO was already part of the existing charter text. - Jouni >=20 > Alex >=20 >>=20 >> Regards, >> Brian >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >>=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Fri Oct 24 14:56:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89411A8F3C for ; Fri, 24 Oct 2014 14:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lgAryUGkJaJo for ; Fri, 24 Oct 2014 14:56:51 -0700 (PDT) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC9BD1A06FD for ; Fri, 24 Oct 2014 14:56:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id s9OLupZa028010; Fri, 24 Oct 2014 14:56:51 -0700 Received: from XCH-PHX-511.sw.nos.boeing.com (xch-phx-511.sw.nos.boeing.com [10.57.37.28]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id s9OLukpk027977 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK) for ; Fri, 24 Oct 2014 14:56:46 -0700 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.66]) by XCH-PHX-511.sw.nos.boeing.com ([169.254.11.19]) with mapi id 14.03.0210.002; Fri, 24 Oct 2014 14:56:44 -0700 From: "Templin, Fred L" To: "dmm@ietf.org" Thread-Topic: I-D Action: draft-templin-aerolink-46.txt Thread-Index: AQHP79RCCG77oicdZ0GswoshJUVgJpw/ydOQ Date: Fri, 24 Oct 2014 21:56:43 +0000 Message-ID: <2134F8430051B64F815C691A62D9831832D57F22@XCH-BLV-504.nw.nos.boeing.com> References: <20141024214801.19360.64069.idtracker@ietfa.amsl.com> In-Reply-To: <20141024214801.19360.64069.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/tZUZZD2SLvVmKnVA_1wWv3VSDmQ Subject: [DMM] FW: I-D Action: draft-templin-aerolink-46.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: Fri, 24 Oct 2014 21:56:53 -0000 Hi, here is a final update of AERO before IETF91. Please take a look to see= if this brings it sufficiently up to 21st century requirements. Thanks - Fred fred.l.templin@boeing.com -----Original Message----- From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of inte= rnet-drafts@ietf.org Sent: Friday, October 24, 2014 2:48 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-templin-aerolink-46.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Transmission of IP Packets over AERO Links Author : Fred L. Templin Filename : draft-templin-aerolink-46.txt Pages : 63 Date : 2014-10-24 Abstract: This document specifies the operation of IP over tunnel virtual links using Asymmetric Extended Route Optimization (AERO). Nodes attached to AERO links can exchange packets via trusted intermediate routers that provide forwarding services to reach off-link destinations and redirection services for route optimization. AERO provides an IPv6 link-local address format known as the AERO address that supports operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6 ND to IP forwarding. Admission control and provisioning are supported by the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), and node mobility is naturally supported through dynamic neighbor cache updates. Although DHCPv6 and IPv6 ND messaging is used in the control plane, both IPv4 and IPv6 are supported in the data plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-templin-aerolink/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-templin-aerolink-46 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-templin-aerolink-46 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Fri Oct 24 16:22:33 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A211A6EFC for ; Fri, 24 Oct 2014 16:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-JU11D5TaRb for ; Fri, 24 Oct 2014 16:22:29 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34BB1A1BCC for ; Fri, 24 Oct 2014 16:22:29 -0700 (PDT) Received: by mail-pa0-f48.google.com with SMTP id ey11so1966986pad.7 for ; Fri, 24 Oct 2014 16:22:29 -0700 (PDT) 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=clE0jhfX9K39J76gkGHwR7/I9gg9pYYFsPrz8BdhMTQ=; b=oyUiK+eWbQOpXTN3yPsG7QogL1YOnYmBrITeYbXKB28CqRxqc36JVa/KTFv2JKc35u xP474oTZioPHOJAqTA7Z4/qy6PGNsu8af4Swnp32JnNp0r3UDTLGVgtncEQ4nA0dDqVy vAf1k6muWcoK+jsGKkYoOh3Kg17KZF1ky3vHfmnBcdNlBwH3Wnhgrl5YbM2SEA+Y0e6o 7ZBN+TpepmTnrMFn506rFxy0DxX9Jcdb3HClTsh2Yo4gSSQylVngnhpQxqkRROi4gqdS rQjhconaQVnwBq4jIOIkKKV889SVtjlWQlXQC5TCl/o0gt3BZTDwCJTLGI/uNgVD/QUV DGqw== X-Received: by 10.70.123.138 with SMTP id ma10mr7900590pdb.64.1414192949480; Fri, 24 Oct 2014 16:22:29 -0700 (PDT) Received: from [10.0.1.5] ([121.152.87.242]) by mx.google.com with ESMTPSA id qh7sm4794347pab.48.2014.10.24.16.22.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 Oct 2014 16:22:28 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Jong-Hyouk Lee In-Reply-To: Date: Sat, 25 Oct 2014 08:22:27 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8B1C3F8C-F6C2-40D0-928C-6E3C69E50D73@gmail.com> References: <52F57E50.8080003@kddilabs.jp> <3C261B1F-F897-4B00-B48E-1974CF0AB695@gmail.com>

<8AF5182C-D47C-4770-9E66-1D23AE9BC34D@yegin.org> To: sarikaya@ieee.org, "Alper Yegin (alper.yegin@yegin.org)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/DN-ddVTnVAVmlYQoI_9FJ-_OR1g Cc: "dmm@ietf.org" Subject: Re: [DMM] DMM's benefits 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, 24 Oct 2014 23:22:32 -0000 -- Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random Protocol Engineering Lab., Sangmyung University #email: jonghyouk@gmail.com #webpage: https://sites.google.com/site/hurryon > On Oct 24, 2014, at 3:40 AM, Behcet Sarikaya = wrote: >=20 > my apologies for forwarding this conversation to this list without > permission from Alper. >=20 > Behcet >=20 > ---------- Forwarded message ---------- > From: Behcet Sarikaya > Date: Thu, Oct 23, 2014 at 10:49 AM > Subject: Re: DMM's benefits > To: Alper Yegin , "dmm@ietf.org" > Cc: Jouni Korhonen , Sri Gundavelli > , "karagian@cs.utwente.nl" > , Kostas Pentikousis , > Dapeng Liu , Marco Liebsch > , Peter McCann , h > chan , Ryuji Wakikawa > , "Zuniga, Juan Carlos" > , Carlos Jes=C3=BAs Bernardos Cano > , Suresh Krishnan , > "pierrick.seite@orange.com IMT/OLN" , > Charlie Perkins , Danny Moses > , John Kaippallimalil > >=20 >=20 > Hi all, >=20 > Two observations: > 1. I don't understand why this mail was not sent to dmm list? So I = added it now. > 2. It was amazing to see the amount of speculation made just based on > the acronym DMM (in Alper's mail). >=20 > How do we know what DMM solution (let me clarify it a bit) will look > like so we can talk about its performance? >=20 > Isn't this what dmm WG should work on first, keeping in mind > performance benefits and other aspects? >=20 > Regards, >=20 > Behcet >=20 > On Wed, Oct 22, 2014 at 2:15 AM, Alper Yegin = wrote: >> Guys, >>=20 >> We've been talking about cost reduction and e2e latency reduction as = the benefits of DMM (compared to current architectures). >> Can you point to any measurements, analysis, simulation, data to back = that up? >>=20 >> I remember Dapeng's analysis from earlier meetings. Do you have = anything else handy? >> I need to compile additional evidence =E2=80=A6 Just as references: 1. Distributed IP Mobility Management from the Perspective of the IETF: = Motivations, Requirements, Approaches, Comparison, and Challenges", IEEE = Wireless Communications Magazine, vol. 20, no. 5, pp. 159-168, October = 2013. 2. Mobile Data Offloading: A Host-based Distributed Mobility Management = Approach", IEEE Internet Computing Magazine, vol. 18, no. 1, pp. 20-29, = January/February 2014. >>=20 >> Alper >>=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From nobody Sun Oct 26 07:36:16 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D101A8882 for ; Sun, 26 Oct 2014 07:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mo42DlTMFGff for ; Sun, 26 Oct 2014 07:36:13 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D201A887F for ; Sun, 26 Oct 2014 07:36:12 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so2898253qgf.6 for ; Sun, 26 Oct 2014 07:36:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:subject:mime-version:content-type; bh=UjSl4kWte8xr3OplTtOSlQUhzUpW5A5cs61cNERYxVo=; b=fXsI/aiUqlRbZ4deKnhpOrwQdmyfl7d5VBvb8cf+41TxxsIEvU4LsSDQsjgxWbOcCA dUdSDQg94oqkUQonfqN3AUe0OjlwbtMszyUxWfRfZE7ASbYoX7QFfarR/kmyJiIY9Fqv A7cpdq25BR8pKN4tiPZ6TgEHZkw/X/1ht8L/xI/jrFhbCA3qeucLMYTAHlxokOKycpGo USEuLuOljHCKIAKCT6Ffw3Tp0QPVdRCwj9Fj93Mx7HZQnC+sZP2jx5O6CVcNubX9fM1W EZvhqBemU1bOtLNj1dTrt4Mv+Byr8hnheczmsj38JVUSUvaCaATXjNHYUOenAxkeOUXS wPIg== X-Received: by 10.140.32.227 with SMTP id h90mr22609029qgh.13.1414334171905; Sun, 26 Oct 2014 07:36:11 -0700 (PDT) Received: from [167.1.1.5] ([205.164.14.196]) by mx.google.com with ESMTPSA id h32sm8885219qge.16.2014.10.26.07.36.09 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 26 Oct 2014 07:36:10 -0700 (PDT) Date: Sun, 26 Oct 2014 22:41:50 +0800 From: Max To: "=?utf-8?Q?dmm=40ietf.org?=" Message-ID: <8D0DB649DAAF4D3A9A3E284809633E50@gmail.com> X-Mailer: sparrow 1.6.3 (build 1173) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="544d082e_238e1f29_3ff" Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/4pkJc-T9yyl72mMx9_oq83ElMBw Subject: [DMM] Minutes for Interim call#2 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: Sun, 26 Oct 2014 14:36:14 -0000 --544d082e_238e1f29_3ff Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Minutes for interim call#2 is uploaded. http://www.ietf.org/proceedings/interim/2014/09/16/dmm/minutes/minutes-interim-2014-dmm-2 -- Dapeng Liu --544d082e_238e1f29_3ff Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Minutes for interim call=232 is uploaded.

http://www.ietf.org/proceedings/interim/2014/09/16/dmm/minutes/minutes-i= nterim-2014-dmm-2

Dapeng Liu

--544d082e_238e1f29_3ff-- From nobody Sun Oct 26 08:06:50 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 681781A88D9 for ; Sun, 26 Oct 2014 08:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pwHIr1o1NFMj for ; Sun, 26 Oct 2014 08:06:43 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1F351A88D7 for ; Sun, 26 Oct 2014 08:06:42 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id u10so4564833lbd.29 for ; Sun, 26 Oct 2014 08:06:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tSvqRuCV9QSlnr/E0ciQEZQ4LFRy/NQJIhwBGzHuzUI=; b=oXGcpi9mGiBFePV1ZPGmPQoXsfitBv2A49uAPF7Ewe0wcEcz9cJxz558nXcsuS3Zce 2HB82oBU0fBfYD+n3vunjAmozP3rVC6DgglkVbUVyGoWiBwfxRLNuB+zUttXwkBY71WD w+92RLX2VRGAELNTyx+8iMAtJUCPWfOGwga2IYeD8MarHk8Mrc4hLEg3e5jAtcaYvuDj kFpWbmDLBDEslBG5aJCIUxrN52Hz7D75wRPBjNDFUspvPdaaweoKsISw0EL2HswTi7j0 2QHz49K4Dv3YmCofHsjS4I7MCW8B4RgJOhkC2wypgjKM9xJsTWryyjyIXCf3ghFFs4kA Lvjw== MIME-Version: 1.0 X-Received: by 10.152.22.135 with SMTP id d7mr17428371laf.46.1414336000987; Sun, 26 Oct 2014 08:06:40 -0700 (PDT) Received: by 10.25.170.2 with HTTP; Sun, 26 Oct 2014 08:06:40 -0700 (PDT) Date: Sun, 26 Oct 2014 23:06:40 +0800 Message-ID: From: Dapeng Liu To: dmm Content-Type: multipart/alternative; boundary=089e0158b9c6ee9694050654c231 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/SiM395bWbfpTLH5ytECk6_imM-Y Subject: [DMM] Draft agenda for IETF91 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: Sun, 26 Oct 2014 15:06:45 -0000 --089e0158b9c6ee9694050654c231 Content-Type: text/plain; charset=ISO-8859-1 Draft agenda for IETF91 has been uploaded. http://www.ietf.org/proceedings/91/agenda/agenda-91-dmm Since we have formed 4 working teams during the interim, we will give most of our agenda time for the working teams. ------ Best Regards, Dapeng Liu --089e0158b9c6ee9694050654c231 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Draft agenda for IETF91 has been uploaded.=A0

http= ://www.ietf.org/proceedings/91/agenda/agenda-91-dmm

<= /div>

Since we have formed 4 working teams during the interim, we will = give most of our agenda time for the working teams.

------
Best= Regards,
Dapeng Liu

--089e0158b9c6ee9694050654c231-- From nobody Mon Oct 27 00:50:18 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626E41A8A43 for ; Mon, 27 Oct 2014 00:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 hS0o2HBbW7mN for ; Mon, 27 Oct 2014 00:50:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FA41A8A39 for ; Mon, 27 Oct 2014 00:50:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKY88208; Mon, 27 Oct 2014 07:50:14 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 27 Oct 2014 07:50:13 +0000 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.43]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 27 Oct 2014 15:50:06 +0800 From: Weixinpeng To: "dmm@ietf.org" Thread-Topic: New Version Notification for draft-wei-dmm-address-management-00.txt Thread-Index: AQHP8bm14wj83kl3IkScrYtyskNfGJxDkJrw Date: Mon, 27 Oct 2014 07:50:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/htpu58nr_NmfM1E7jvJm4YNnKug Subject: [DMM] FW: New Version Notification for draft-wei-dmm-address-management-00.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: Mon, 27 Oct 2014 07:50:17 -0000 SGkgYWxsLCANCkEgZHJhZnQgb24gSVAgYWRkcmVzcyBtYW5hZ2VtZW50IGluIERNTSBpcyBzdWJt aXR0ZWQsIEkgdGhpbmsgaG93IElQIGFkZHJlc3NlcyBzaG91bGQgYmUgbWFuYWdlZCBpbiBETU0g bmV0d29yayBpcyB2ZXJ5IGVzc2VudGlhbCB0bw0Kc291cmNlIGFkZHJlc3Mgc2VsZWN0aW9uIG9u IG1vYmlsZSBzaWRlLCBhbmQgbW9iaWxpdHkgbWFuYWdlbWVudCBzaWduYWxpbmcgb24gbmV0d29y ayBzaWRlLCBzbyB0aGVyZSBzaG91bGQgYmUgYSBjb25zZW5zdXMgb24gSVAgYWRkcmVzcyBtYW5h Z2VtZW50IGlzc3VlLg0KDQpDb21tZW50cyBhcmUgd2VsY29tZWQhIFRoYW5rcyENCg0KLVhpbnBl bmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPlNlbnQ6IE1vbmRh eSwgT2N0b2JlciAyNywgMjAxNCAzOjQzIFBNDQo+VG86IFdlaXhpbnBlbmc7IFdlaXhpbnBlbmcN Cj5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ZHJhZnQtd2VpLWRtbS1h ZGRyZXNzLW1hbmFnZW1lbnQtMDAudHh0DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXdlaS1kbW0tYWRkcmVzcy1tYW5hZ2VtZW50LTAwLnR4dA0KPmhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgWGlucGVuZyBXZWkgYW5kIHBvc3RlZCB0byB0aGUgSUVURg0KPnJl cG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LXdlaS1kbW0tYWRkcmVzcy1tYW5hZ2VtZW50DQo+ UmV2aXNpb246CTAwDQo+VGl0bGU6CQlJUCBBZGRyZXNzIE1hbmFnZW1lbnQgaW4gRE1NDQo+RG9j dW1lbnQgZGF0ZToJMjAxNC0xMC0yNw0KPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+ UGFnZXM6CQk3DQo+VVJMOg0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXdlaS1kbW0tYWRkcmVzcy1tYW5hZ2VtZW50LTAwLg0KPnR4dA0KPlN0YXR1czoNCj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13ZWktZG1tLWFkZHJlc3MtbWFuYWdl bWVudC8NCj5IdG1saXplZDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWkt ZG1tLWFkZHJlc3MtbWFuYWdlbWVudC0wMA0KPg0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9j dW1lbnQgcHJvdmlkZXMgYW4gSVAgYWRkcmVzcyBtYW5hZ2VtZW50IHNvbHV0aW9uIGZvciBETU0N Cj4gICBuZXR3b3JrLg0KPg0KPg0KPg0KPg0KPg0KPlBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRh a2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj51bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KPg0KPlRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Oct 27 20:59:34 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F871A044F; Mon, 27 Oct 2014 20:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Rxvv5tGbmDIu; Mon, 27 Oct 2014 20:59:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC3C1A001E; Mon, 27 Oct 2014 20:59:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ80023; Tue, 28 Oct 2014 03:59:23 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 03:59:21 +0000 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.168]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 11:59:14 +0800 From: Xueli To: "pierrick.seite@orange.com" , Ted Lemon , "STARK, BARBARA H" Thread-Topic: =?Windows-1252?Q?[homenet]_Fwd:_New_Liaison_Statement, _"Broadband_Forum_W?= =?Windows-1252?Q?ork_on_=93Hybrid_Access_for_Broadband_Networks=94_(WT-34?= =?Windows-1252?Q?8)"?= Thread-Index: AQHP7WIcOm96HPXJ7U2H19EDbAXxJpw7zesggAASlkCACQpR4A== Date: Tue, 28 Oct 2014 03:59:14 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B449036DFF@nkgeml504-mbx.china.huawei.com> References: <20141021160652.24101.60334.idtracker@ietfa.amsl.com> <4BBD7952-84F7-40F9-9034-8DD7A1F2A05C@nominum.com> <2D09D61DDFA73D4C884805CC7865E61130EA59FC@GAALPA1MSGUSRBF.ITServices.sbc.com> <01FE63842C181246BBE4CF183BD159B4490350AD@nkgeml504-mbx.china.huawei.com> <31246_1413972312_54478158_31246_662_1_81C77F07008CA24F9783A98CFD706F71142BD145@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <31246_1413972312_54478158_31246_662_1_81C77F07008CA24F9783A98CFD706F71142BD145@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/related; boundary="_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/w3LrWMSHpHK0VSuk6zFNzz7Yk1I Cc: HOMENET Working Group , "mif@ietf.org" , "dmm@ietf.org" Subject: [DMM] =?windows-1252?q?=3D=3FWindows-1252=3FQ=3FRE=3A=5F=5Bhomene?= =?windows-1252?q?t=5D=5FFwd=3A=5FNew=5FLiaison=5FStatement=2C_=5F=22Broad?= =?windows-1252?q?band=5FFor=3F=3D_um_Work_on_=93Hybrid_Access_for_Broadba?= =?windows-1252?q?nd_Networks=94_=28WT-348=29=22?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 03:59:30 -0000 --_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_ Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_" --_000_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pierrick First of all, thanks a lot for agree with the big picture depicture and arc= hitecture.. I am fine to split the architecture considerations and solution design in t= wo different documents. And I updated the architecture draft (No specific solution there) in the ne= w version, I hope it makes sense for you. http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-archi= tecture-01.txt Do you mind to share more about the solution about DMM proposal. Which exact issues it is really solving? Best Regards Li From: pierrick.seite@orange.com [mailto:pierrick.seite@orange.com] Sent: Wednesday, October 22, 2014 6:05 PM To: Xueli; Ted Lemon; STARK, BARBARA H Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org Subject: RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on= =93Hybrid Access for Broadband Networks=94 (WT-348)" Hi Li, Architecture considerations and solution design are two different things, w= hich should not be addressed in the same I-D. People may agree with the big= picture depicture and architecture but not agree with going on extensions = to the GRE protocol to address the issue. BTW, I think that going for exten= sions to GRE header to address the hybrid access use-case is not the right = way. Actually, IETF solutions already exist (RFC 4908 ) and, moreover, the= re is ongoing effort in DMM to update RFC 4908 to meet hybrid access requir= ements. BR, Pierrick De : Xueli [mailto:xueli@huawei.com] Envoy=E9 : mercredi 22 octobre 2014 11:48 =C0 : Ted Lemon; STARK, BARBARA H Cc : HOMENET Working Group; mif@ietf.org Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on = =93Hybrid Access for Broadband Networks=94 (WT-348)" Hello Thanks Barbara to send this liaison out. Hybrid Access network is that Residential gateway (RG, or CPE) is extended = with more than two access lines (e.g. DSL + LTE) in order to provide higher bandwidth for the customers. Th= e scenario and architecture are shown as follows [cid:image002.jpg@01CF9A07.BF8CD480] Right now, we have two individual drafts, one for architecture and requirem= ents, and the other one is for an optional solution. The draft (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-arc= hitecture-00 ; ) proposes the architecture and gap analysis. The solution draft proposes one option for the solutions, http://tools.ietf= .org/html/draft-heileyli-gre-notifications-00 We did not combine them as one draft, because we believe there may be other= candidates, and we would like to have further discussions in the related g= roups and IETF. We used to present it in Homenet in Toronto. Now the authors have invited Orange to join this architecture work. We will= send out the new version of these drafts soon. We are glad to invite the experts for comments. Best Regards Li Xue on the co-authors behalf -----Original Message----- From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, October 22, 2014 3:05 AM To: STARK, BARBARA H Cc: HOMENET Working Group Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on= =93Hybrid Access for Broadband Networks=94 (WT-348)" On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H > wrote: > FYI. I made sure they were aware of IETF mif and homenet activities in th= is area. I intend to try to prevent having to track efforts that try to do = the same thing in two different ways. But some of the BBF effort may be foc= used on what can be done around "bonding" of multiple interfaces that are u= nder the control of a single service provider. I don't see this in mif or h= omenet. Thanks. I couldn't really tell what was being proposed from the Liaison s= tatement, so this information is helpful. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___________________________________________________________________________= ______________________________________________ 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_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pierrick

First of all, thanks a lot for agree with the big picture depictu= re and architecture..

I am fine to split the architecture considerations and solution d= esign in two different documents.

And I updated the architecture draft (No specific solution there)= in the new version, I hope it makes sense for you.

http= ://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-architect= ure-01.txt

Do you mind to share more about the solution about DMM proposal.<= o:p>

Which exact issues it is really solving?

Best Regards

&n= bsp;

From: pierrick.sei= te@orange.com [mailto:pierrick.seite@orange.com]
Sent: Wednesday, October 22, 2014 6:05 PM
To: Xueli; Ted Lemon; STARK, BARBARA H
Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org
Subject: RE: [homenet] Fwd: New Liaison Statement, "Broadband F= orum Work on =93Hybrid Access for Broadband Networks=94 (WT-348)"=

Hi Li,

Architecture considerations and solution design are two different= things, which should not be addressed in the same I-D. People may agree wi= th the big picture depicture and architecture but not agree with going on extensions to the GRE protocol to address the = issue. BTW, I think that going for extensions to GRE header to address the = hybrid access use-case is not the right way. Actually, IETF solutions alrea= dy exist (RFC 4908 ) and, moreover, there is ongoing effort in DMM to update RFC 4908 to meet hybrid access re= quirements.

BR,

Pierrick

De : Xueli [mailto:= xueli@huawei.com]
Envoy=E9 : mercredi 22 octobre 2014 11:48
=C0 : Ted Lemon; STARK, BARBARA H
Cc : HOMENET Working Group; mif@ietf.org
Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadba= nd Forum Work on =93Hybrid Access for Broadband Networks=94 (WT-348)"<= /span>

Hello

Thanks Barbara to send this = liaison out.

Hybrid Access network is tha= t Residential gateway (RG, or CPE) is extended with more than two access li= nes

(e.g. DSL + LTE) in orde= r to provide higher bandwidth for the customers. The scenario and architect= ure are shown as follows

3D"cid:image002.jpg@01CF9A07.BF8CD480"

Right now, we have two indiv= idual drafts, one for architecture and requirements, and the other one is f= or an optional solution.

The draft (htt= p://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-architecture-00 ; ) proposes the architecture and gap analysis.

The solution draft proposes = one option for the solutions, = http://tools.ietf.org/html/draft-heileyli-gre-notifications-00

We did not combine them as o= ne draft, because we believe there may be other candidates, and we would li= ke to have further discussions in the related groups and IETF.

We used to present it in Hom= enet in Toronto.

Now the authors have invited= Orange to join this architecture work. We will send out the new version of= these drafts soon.

We are glad to invite the ex= perts for comments.

Best Regards

Li Xue on the co-authors beh= alf

-----Original Message-----

From: homenet [mailto:homene= t-bounces@ietf.org] On Behalf Of Ted Lemon

Sent: Wednesday, October 22,= 2014 3:05 AM

To: STARK, BARBARA H<= span lang=3D"FR">

Cc: HOMENET Working Group

Subject: Re: [homenet] Fwd: = New Liaison Statement, "Broadband Forum Work on = =93Hybrid Access for Broadband Networks<= span lang=3D"EN-US" style=3D"font-family:"Courier New"">=94 (WT-348)"

On Oct 21, 2014, at 2:55 PM,= STARK, BARBARA H <bs7652@att.com&= gt; wrote:

> FYI. I made sure they w= ere aware of IETF mif and homenet activities in this area. I intend to try = to prevent having to track efforts that try to do the same thing in two dif= ferent ways. But some of the BBF effort may be focused on what can be done around "bonding" of multiple = interfaces that are under the control of a single service provider. I don't= see this in mif or homenet.

Thanks. I couldn= 't really tell what was being proposed from the Liaison statement, so this = information is helpful.

____________________________= ___________________

homenet mailing list<= span lang=3D"FR">

homenet@ietf.org

https://www.ietf.org/mailma= n/listinfo/homenet

____________________________________________________=
_____________________________________________________________________<=
/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_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_-- --_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9036; creation-date="Tue, 28 Oct 2014 03:59:13 GMT"; modification-date="Tue, 28 Oct 2014 03:59:13 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCADWAawDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0uiii uc4gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKbHLHMgeJ1dCSAynI 4OD+tADqrXNxdxSBbfT2uVIyWEyJg+mGqzRQBUmub2NwItMeZSoJYXCLg9xgntSy3N4k+yPTWlj4 /eCdF+vBOeKtUUAVXubxbny101ni3Aed56AY9duc0fabz7V5f9mt5O7HneemMeu3Ofwq1RQBVjub xrny301o4skecZ0Ix67Qc1aoooAKKRmVELsQqqMknoBQrBlDKQQRkEdCKAFooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKaZYxMs JdRIylgmeSBjJ/UfnTqACiiigAooooAKKbHLHMpaJ1cBipKnOCDgj8DTqACiio7idLa2luJM7IkL tgZOAMmgCrq9xJFaCC3OLm6YQw/7JPVv+AjJ/CrVtbxWltFbQLtiiUIo9hTl2SqkoUHIypI5AI/S nUAFFFFABRRRQAUUUUAFFFFABgEYIBB6g96zdIP2V59JdiTaENDnq0Lfd/LlfwFaVJsXfv2jfjG7 HOPTNAxaKbHLHMC0bq4VipKnOCDgj8DTqBBRRUVxdRWvleaSBLIIlbHAY9M+men1IoAlooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMubRjLrcV/ 9su1RYnUotww5LKQAP7vByPpVoWCi6+0fa7zO7d5ZuG8v6bemPale7K6pDZbARJC8u/PTaVGMf8A Av0qzQN3Ksdgsdx5/wBrvWOSdj3DFP8AvnpiiHT1hmMgu7185+WS4Zl59qtUUAVIdPWBmYXl9JuU riW5ZgM9xnofeiLTliVx9svn3rty9yzFfceh96t0UAZuj6S2mJKHuZ5mklkcB5mdQGYkcHv6mtKq 1hdm9hkkKBNk0kWAc52sVz+OKsM6ou52VR6scChg9xaq6qjSaPexopZ2t5AqgZJJU4FLaaha3tlH dxSqI5FDDcwBGfXng064vre1tJbp5UMcSMxKsDnAyQOetDBaMfbgrawgjBEagg9uKkpkM0c8SyxO GVgDkEGn03uIKKKKQBRVNr24GrLYi0BjaMyed53YHH3cep9ap3Wt3kFzLEmjvKqGTa3nhWkCAEkL t/2uOecUDszYorHGuXDahLaR6crmKbyyBcjeRhSWCbegDAnn1rYoCwUUUUCCmyx+bE0Zd03DG5G2 sPoe1OooAytN0U2UFxG97dsZpZGBFyx2hmyCPRvU1aTTlSF4vtl8wfHztcsWXHoe1Osbs3kUrlAn lzyRYBznaxGfxxVmgbvcqDTlW3aH7ZfEMwO83LFx7Buw9qSTTIpdOmsZJp5VmBG+aUuynsQT6HBq 5RQFytp089xYxtdRmO4XKSgjGWBwSPY9R9as1Wvbz7Ebd3TMMkojkfP+r3cKfpnA/GrNAgooooAK KytV1w6XqFjamykmF5JsDq6AA4Pqw74HPHPrxRf64bHWrLTTZSSfa9wEgdAAQM9Cc+vX04zTsOzN WisqfXDB4ht9INnI3nxs6yh0xxjtuz0z78cA0f24R4kGjGzkBMPmCbemOuOmc9OfX2xzSsFjVorK g1wzeIp9HNlIhiiEnml0IIJOeA2fT355ArVoBqwUUUUCCiiigAooooAKKKbLIsMTSPu2qMnapY/g ByaAHUVl6drsN9bTTNFOnkyOpAt5OQrlRjK8n2HSrKapbPA8wW42RkA5tZA3PopXJ/Cgdi3RVQap bG3acLcbFbaQbWTdn/d25x74o/tO2FsLjbcbC23H2WTdn/d25x74xQBborL1LXYbHSJL9IpnwpKK 1vIMkHuNuQPc1oQTx3MQljDhScfvI2Q/kwBoCxJRRRQIKKKKAKklrI2swXY2+VHbyRtzzlmUjj/g Jq3VOS4lXW7e2DfuntpHZcdWDIBz+Jq5R0GwooooEFFQXzyRWFxLCwSSOJmRmXcAQCenesrRdUur uBru4uhLAsfzoLRo5A+FPyryWXDelCHbS5o6ZayWlvKku3L3Esgwc8M5I/Q1YlhiuIzHPFHKh6rI oYH8DWdp2uw31vPK0U6eTJIpAt5OVVioIyvJ9hzVldUtngeYLc7EIBzayhufQbcn8KGDvcZZaNp9 lp8dktpA8aKAd0K/OR0JGME0650iwubCWyNpAkUisMLCuFJGNwGMZ96Zouqpq+nRXIjeN2QM6tG6 gE+hYDP4Vfpu99Qu0yK2tYLOBYbeKOJFA4RAoJx1wO9S1S1S5lsoortDmCKQfaFxn92eCw/3SQfp mrtIQUUUUAZl7YahPetPb3dtEhgaEK8DMwB5JyHHP4U5dPu47mwdbqIx2kPlMHiYvJkAE53cdPQ1 o0UDuYb6DdnULm7iu7WKS4k3eatu3mouFBUNv54UdR3Nbp5JOMUlFAN3CiiigQUUVStLia71C7ZX H2SAiFAAPnkHLtn24X8DQA7TbaS1hmSXbl7mWQYOeGYkfoat0UUAFFFFAEV1bR3lrLbTDMcqFWx7 96bYi6WyiW9Km4VdrspyGI43fj1/Gp6KACisnxBdataW8L6VEkrGVfMUxM52A5bofTPue1M1u71i 2NkdPjilDSL9o/cu2F6MeD05HHX9aaQ7Gu0UbnLxox6ZZQe+f580NFG7b2jRm4+YqCeOnNOGcc4z 3x0opCGmKMvvMaF8g7iozkdOfxP50eVHv3+Wm/Od20ZzjHX6cU6igBoijD7xGgfJO4KM89efwH5U 6isfT7rWJNevILuOMWSgGCRYWXcRwwBJ9cdevagZsUVkaRdavPqV9FqEca26MDbusLLvGMHBJ9Qe vPIPStegHoFFFFAgooooAKKKB1oAZFBHboUiQIpYuQPUnJP4k0+s/RGZrKUsxJ+1zjk5/wCWjVoU De4UUUUCGTwR3ULwTIJI5BhlPcU/rWf4gZl8P3zKxUiLgg4I5FaJ60DEooooEFFFFAEDWgfUYr3e QY4ni244O4qc5/4DU9Z8rN/wkdqu47TaSkjPGdyVoUdBsKKKKBEdxAtzbSQOXVJUKMUbBweDg9qq Wej29lPHMk11K0UZjj86beEU4zj/AL5H5VfooGMigjt1KRIEDMXIHdmOSfxJp+az9FZmtJyzE4vJ xyc8eY1aFAPcZBDFbQJBCgSKMbUUdAKfRRQIbIiSxtHIoZHUqynoQeoqKytms7KK2aZpvKXaHYYJ A6Z/DAqeigAooqtcz3sTgW1gLlSOWNwseD6YINAFmiqk1xfo4EOmrMpAJY3Kpg9xgj9aWW4vkn2R acssfH7z7Sq/XjFAFqiqr3F8tz5aacrw7sed9pUceu3Gfwo8+++1eX/Z6+Tux532lenrtxn8KALV FVY7i+a52PpypDkjzftKnj124zVqgBHDFGCNsYggNjOD61DZWkdjZRWsWSsa4yerHqSfcnJ/Gp6K ACiiigAooooAKKKy/EOn32o6d5Gn3T2828HeJNo4OeeDnpjt1oGjUopkKskEauzM4Ubi7BjnvkgD P5U+gQUUUUAFFFFABRRRQAUUEZBGSM9x1FZGhadqFjNetfXUk6zy+ZEHlD7AeoPyjnjr056cUDNe iiigQUUUUAFFFKOtAFWBrK1tneKWJIRK5d2k+UOWO7JP+1mpVubdy4W4ibyxl8SA7B6n0/Guduhv 8H6igQuzXUwULEZDnzz/AAjrUTwSvfX7TRtdxrcW0k/l2jRiWJVOQFOd+CQSM9ulNIu2504uIGg8 9Z4jCBnzQ4Kfn0prXtmkayteW6xscK5mUKfoc81gXKQSC6njt7mCzmnhMZjtiw8xckyGLGdn3QeO cfjTZLW2fQry4msU3q0wgaK1dfOLqAX8rBIJxj8M96LCsdA62upWbxb47iCUbWMb5B9sip6w9SsJ JvD9wujEQm5BkaPyDmRjgcAldvStF4NRMSKuowiQZ3P9kyG9ON/H50CLdFVJYNQZIxFfxRsFw7G1 3bz6gbhj6c0TQag2zyb+KPCgNutd24+v3hj6UgLdFVJodQeQGG/iiXAyrWu8k9zncKWWG/afdFfR Rxcfuzbbj7/NuH8qBExt4muUuSv71EKK2eikgkfoKkrIns9UfxDDcR3aLbLBIvNvnbllIUndyTg8 47VsDrR0GyL7RB5xh8+LzR1j3jcPw601L2zlLCO8t3KDLBZVO0dycHgVj6fHaRiztbrTXl1CCYu0 gtz8r5OZfM6EHPqTzjFVdLthPJPI0ccUNrdTzgC1dZXDFwASRgqQc4Ge1Mdjooby0uHKQXdvMwGS scqscfQGpq5XwsRF9jhlgMk3k7UcWjw/ZlCDcrZGCSR611VDVmJqxBaJbJE4tSpQyuW2tn5yx3fr mp6ztD/485/+vy4/9GNWjSB7sKKKKBBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANll jgiaWV1jjUZZmOABTqoa1o9vrmnPY3OBG55bYCwHfbnoferNpbraWcVuu3ESBcqgUH3wOBmgZNUU 13a2zBbi6ghJGQJJVUkfialrG8QSWyyaeJoGlZLpJGK2zSbUG7JJCmhbglc2RyARyDyCKaJEMpiD AyKoYr3AOQD9OD+Vc1rCE3upTxNfB4rON4FiEoTzcnBAAwTjaMfmKmuYLKPxC19cW124ntozE0Ql O5wzZGFOBwV4OB+tOw7HRYOM44owfSuWlXUF1mVpJCk5ucxMEnbMWRgAL+7xjIOe+asxJbzeJ7tX mvlXdGYUHmrH5gzuOcY9BjOKLCsdBg+lGD6da5WyDQXNvNE98ZJL+eMiUSlViw20EEYC52kE+vWn aJHerfwJcyMJiGF2u2clzjnJb5Bz0K/hRYbVjpY5Emj8yJw6ZI3KcjIOD+op1YHh23tbHNqttdJd K8ocuJSirvJHLHbyCMYredFkRkdQysCCGGQR7ikxPcSOWOZS0Tq4DFSVOcEHBH4GnVmaJoVvoUc6 QMrefJ5jHywpBPUcds5IHbNadABRRRQIKKKB1oAhtLmK5iaSFSqrI6HIx8ysQf1BqbNUdHikhs5V lRkY3MzAMMZBkYg/iKvUDe4uT60ZNJRQIhvLqOytJbqbcY4l3NtGTipqoa5FJPod5FCjSSPHhVUZ JORWgetA+glFFFAgooooAha6jW9jtDu8ySNpBxxhSAf/AEIVNVGWKQ6/bTBGMa2sql8cAlkwP0P5 VeoGGaXJ9aSigQuT60lFFAEFpcxXUTvCpVVleM5GPmViD+oqeqOjxSQ2syyoyE3UzAMMZBkJB/EV eoG9wooooEFFFFABRRVa5sI7pw7zXSEDGIbh4x+SkUAWaKqTadFO4dp7tSABiO6kQcewPX3pZdOi mn85p7tW4+VLl1Xj/ZBxQBaoqq+nxPc/aDNdhsg7VuXCf98g4x7Uf2fF9q+0eddbt27b9pfZ/wB8 5xj2oAtUVVj0+KO588T3ZbJO1rl2T/vknGKtUAFFFFABRRRQAUUUUAFU9U1az0e2FxeyMiFgowhb qQO31q5UF7Y22o25t7uPzYiclCxAP1x1/wAaBq3UljkSaNZIzlHGVOCMj6Gn5I701V2qFBJCgDJO T+feloELk+tGaSigAzS5PrSUUALk+tJmiigALbVJJ4Ayao6drNjqrzpZys7W7lHDIy4Ix6j3q9Va 00+2sXle3jKNO26Qlyd7f3jk9ff6elA+hZooooEFFFFABSM6opd3VFHVmOAPxpaRlV1Kuqup6qwy D+FAFSz1WyvYZJY7iILG7I2ZF42sVz16Ejipxd2rI0i3UBRfvMJVIH1OeKhtNKsrKGSKK3iKyOzt mNedzFsdOgJ4qYWlqqNGtrAEb7yiJQD9RjmgegC7tTGZBdQGMHBfzV2g+mc0fa7Xy/M+1QeXnG/z V259M5oFpaiMxi1gCE5KeUu0n1xij7Ja+X5f2WDy852eUu3PrjFAEF7qtlY2D3klxE0SAkbZF+bH Yc8mrUckcqb4pEkU/wASMGH5iq17pVnfWL2ckEaxOCBtjUbc9xxxVmOOOJdkUaRqP4UUKPyFADqK KKBBRRRQBWe7ZdVhstgKyQPKWzyCpUY/8eqzVSS1kbWILsFfLjt5IyM85ZlI/wDQTVugYUUUUCI7 iR4raWVEDsiFgpbaDgZxnBxVCy1eSUW5vbaO0W5h82JxPvXAAJDEgYOCD6dav3Eby20sSOEZ0Khi u4DIxnGRmqFlpMkIgF7cx3S20PlRIINi4IAJYEnJwB+tCHpYntNVsr2KSSO4iCxO6NmReNrbc9eh xwamF5aMjSC7gKL95hKuB9TmorTSrKyikjit4isru7ZjXnc27HTpzwKmFpahCgtYAjfeURLg/UYo DQj0/ULfU7OO6tpFZZFDbQwJXPY4PFWarafp9vplnHa20aqsahdwUAtjucDmrNNgMmmjt4JJ5W2x xKXY+gAyajsZpriyhmuIhDJIu4xg5256A++MZ96j1G0e+WCDIFv5oecHq6ryF+hOM+wq2eTmkAUU UUCCiiigAooooAKKKKAEffsbywC+DtDdM9s1Bp94t/Yx3IUozZDoeqODhlP0INWKp29rLbajdSIV +zXAEm3PKy9GwPQgA/Ue9Ay5RRRQIKKKKACiiigDK17Wm0SCGYWhnWSVUYiRV2gnk8nsMnPQY5pu s65JpBsv9BMoupVjb98g2Z+p7HHPTnrWsyK33lVu3IzQyI33kVuMcgHimPQUZxyMHuPSiiikIKKK KACsmw1uS81y80xrIxfZQpEnmo27PXgH1446Z5xWtSBEByEUHnkDnnrQMytK1x9S1K+s2sjB9kcD cZUbcCB6H13DjjjHWtakCIpyqKD0yABS0AwooooEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF AFKSeVdct7YP+6e2kdlx1YMgB/U1dqBrRW1CK83kNHE0QXHBDEHP/jtT0DCiiigQUUUUAUtKuJbm 2meZ9zLczIDjoquQB+QqzcTrbxGVklcDtFGXb8hzTLO0WzieNXLh5XlJI6FmLEfrU9DG9zL03W1v dIivpLa6VmVSypbSHk/3RjJHvTr3WEttJnvUtromNHKo1tIDkLnkYyB71fhhjt4UhhQRxoMKq9AK WSNJonikUOjqVZT0IPBFNhpchsbtb21SYRyx7gMiSNkOcdgece9WKRVCqFUYAGAPQUtJiCiiigAo pcH0pMUAFFLg+lJQAUUUUAFFFFAFLS55biCdpX3FbqZAcdFVyAPyq7UFnaLZxyIrlhJM8pJHQsxO P1qegb3CiiigRBe3aWNlLdSDKxLnb3Y9h9ScD8aLFLmOyiW8k8y425lYDA3Hkgew6fhRdWaXcluZ GOyCUS7OzsB8ufoefqBU9AwooooEZGrz6zFqNiNPVGtmf/SMwF9qnjJIYZ5IOBzwT0o1GbWY9cso 7NUaxbIuCYC23PQk7hnkHp0zk5rXop3HcyLifWV8SW8UKodNZCJW8gnaxwR8272YZxgZGc5o8/WB 4nEW1Dphi+95B4frjdu9O+MdsZrXoouFzIt5tZPiWeGZU/s3yx5biAj5hnIzu9CvOMHBxiteiikD CiiigQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGRPeaoviGG3jtI2tmgkbm5xuwyjc Rt4IyeM96uia/wDtWw2MQg3Y837T82PXbt/TNWqKBlWOa/a42SWMSQ5P7wXO447Hbt/rRDNqDTFZ rGGOPn51udx9uNo/nVqigCpDNqLswnsIYgFJUrdb8nsPuDH1oin1Flcy6fChC5QC63bj6H5Bj681 booAytCutRuYpjfW6oFnlVXE288OQFxtHAHetWiigHuFU9YJGiX5BwRbScj/AHTVymTRRzwyQyru jkUoy+oIwRQCdmJbf8ekP/XNf5CpKj3xQtFAWVS42xqT97A6D8KkpsQUUUUgOfv1szrN+0948DRW aSJtumXY+W5C5xngcY5qrdXDSMZ7u5Z3jSDzI7e7MU1sxAJAj6Puzn1xkV0j2drJL5z2sDygg+Y0 SlvbnGac1tbvMJmt4WlU5EhjBYfjjNNOxVzHe6sNN1bU7uScnyoo2Mf2gtgnOcIWxnp2rcqBrCye QyNZWzSE5LmFSxPrnFT0hMKKKKBBTZTIsTGJBI4HyqW2gn64OKdTPOi+0fZ/MXzdm/Z325xn6ZoA y9JvNVntrlrizjLJPKsebnrhyAv3OAB3q4k2omF2ewhWUY2ILrIb1ydnH5GrdFA7lQTaibdmawhE wYBY/tWQR67tnH0xTJ7+ez02W6urZI5U4jiSXzN7HhRnA5JIFXqjlgimaMyoGMTh0z2YdD+tAEWn WjWNjHDI5kl5aVz/ABOTlj+ZqzRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6raPd2R8ji5hYTQH0deQPx5B9 jU1ndx31nFdRZCSruAPVT3B9wcj8KmoAA6AD6UDCiiigQUUUUAFFFFABRRRQAjMqIzuwVVBLE9gO prP0dGmjl1KVCst6wdVPVIhwi/lz9WNaJGRgjIooGFFFFAgooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAqtc6fb3cgeUzggY/d3EkY/JSBVmigCpNpltcOHkNxlVCjZcyKMD2DD86WXTbaefznNxv4 +7cyKOPYNirVFAFV9Nt5Ln7Qxn8zIbi5kC5/3Q2PwxR/Ztv9q+05n8zdu/4+ZNuf93djHtirVFAF WPTbeO5+0KZ9+SfmuZCvP+yWx+lWqKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAopHBMbBW2kg4YDOPeu f8PXup6lGk73crGONTLHcWyxrIWTIKlQDgH8xQOx0NFY9pfyW+jtI0W+c3bwKplZlLmQqPmPIXP5 Dio21nUYZruKe0tR9llgRikrHeJDjI44xnoadgszcorJutWu7az1Wb7NC8mnyfKoZsSJtDenDYOP Sm3usXtgkC3NtbxzXMhEfzO6ooGTu2rnd24496LBZmxRVTTL039mJmjMbBihGGAOO67gDg/Smarh YUke+ntYlJBW3A8yVj91VPPOewHP0pAXqKzXm1e20u0P2WK6vC6JcK8ojCqfvNnoSPQde1aR60CC iuc1rVr6yudTSGW4xDaxyQ+XarIsbEtkscdPl7+pq3e6vdWUt1b+TBJOgiNorMQbjedvPHGD6U7D szYorAi1PUbT+0ZZY0ntLS7KO7ynzApCkhBjGFLd+TV1b7UX1e5so7S3MVuYy0xlIyrZ4Ax94Yz6 UWCxpUVmwTSJrV+k4AVII5FKSMRty/8ACeA3HOOv4VVS+1GfUtKldEhtLsOQscpJI2blDgjr0OR0 5FFgsblFMmZUgkdpPKVUJL4B2gDrzXNaJ4kd7K7kvbuO9eK3W6TytgYISRsO3jIIH/fVILHUUVly 3+p2UM017ZW5jWNShgmJzIWACHcOOv3ulR3mqalpkLve2lt8zpHC8Tuys7E5DDbuAGM8A5p2CxsU VkQ6xdT6fcSw2YmnhdVARXVJAe43AMcDOQOeKI9Vv5NMedLFHuUn8poUL5Uf3ipAbOOdo7EUWCxr 0VU0y8kvrITTIkcm9lZEJO0g4wcgEH1HaotVlvYzB9l84Rkt5zwRCWRePlwp6jPU49KQWNCisi31 G8nitbe1e2vLh4DNJO4aOMgNt4UAkHPbtg1BceILu3m+zyWkUVxFCsk8bGR/mbOFQopHQdT607BZ m9RWJd65ewyztFZRNbQWqXTNI7K+1s5Xbj73B9qk1HXBYXyxAwSpuRZEG/zFLHA5AKjqDgkcUWYW Neisya+1IazLYW9pbyIkSS+a8pX5SSCpGPvccdvWnxyTf8JI8MgG1rXdGVkbGN+OVPGcnqO1ILGh RWVDq1xJ9nuWt4hZXM3lRMHPmAkkKSMYwSOnUVq0AFFFFAgooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAR1DoyHOGGDg4P51WtdNtrOyNnAZlhxgAzuSo9AScj8KKKAIY9FtI LWe3hjkdZskpNcSMpYnOckkg55yOahsdBEKXovVUm9ZGdUld8bRwd7fMTnnPGMDFFFMd3Yk/sDTv IuINs+y6YNP/AKTJmQgYyTuz0/kKsNptu9ssDGZgjbkczuZFPqHzuH50UUguyW3t47WLy495GSxL uXYk9ySSTUV5pttfSwzTeaJIM+W8czxlc9fukelFFAiOfRtPurKCzuIDLDbyLLGHkYkOpyDnOT+N Xjyc0UUAUbjRrK6e5eZJSbpBHNiZwGUdBgHjv09TUUul3U+tWV5LHbG1sVfyiXZpSzADJyMevfvm iimhj10LTluXuBC5eSXzZMzOVdx0LLnBx2z0wKlj0u2ivnvUM/nSHL5uHKtjplc44z6UUUguNi0m 1ivmvVNx57cMWuJCCOcDaTjHJ4x3piaHp8d1FcpE4kgYmL98+I89QozgA+nSiigLlq7tIb60ktbg M0Uq7XVXKkj0yOagbSLJ5Y5ZI3kaKEwKHlYgoeoIJw2ff0oooC4R6PYxxyRmN5Ukj8tlmleQbPQb icD6UJpFmsUkZWWQSABmlnd2GORgk5GDzxRRQFxH0aylgMMqzSgyLJue4dnDL90hicjFD6NYvAkL RyEJL5yv5z79+Mbt+ck4OOtFFAXLNtbQ2kIhhUqoJJySxJPUknkn3NRXem217NFNMJBLCCEkilaN lB6jKkegoooENfSLJ44UEbx+QpWNopWRlB6jcCCQepz3ofSbNljVVli8tPLBindCV9CQcn8aKKB3 GzaLYz+d5kcmJ4lhkAmcAoOgwDx+HqabcaFp9yWMscp3FWYCd1DMuMMQDywwOevFFFFwuSf2Xbf2 gb/M/ntgE/aH2kDoNucY5PGO9H9k2v8AaH2/Nx5/TP2mTGM5xtzjGe2KKKAFTS7OO6+0rGwcMXCm RiiserBM4B68gdzVuiigQUUUUAFFFFABRRRQB//Z --_004_01FE63842C181246BBE4CF183BD159B449036DFFnkgeml504mbxchi_-- From nobody Mon Oct 27 21:05:38 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E029C1A036D; Mon, 27 Oct 2014 21:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AsbviIlBziRm; Mon, 27 Oct 2014 21:04:57 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040A91A0364; Mon, 27 Oct 2014 21:04:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKZ80353; Tue, 28 Oct 2014 04:04:54 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Oct 2014 04:04:53 +0000 Received: from NKGEML504-MBX.china.huawei.com ([169.254.7.168]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 28 Oct 2014 12:04:48 +0800 From: Xueli To: "Sri Gundavelli (sgundave)" , "pierrick.seite@orange.com" , Ted Lemon , "STARK, BARBARA H" Thread-Topic: =?iso-8859-1?Q?[DMM]_RE:_[homenet]_Fwd:_New_Liaison_Statement, __"Broadban?= =?iso-8859-1?Q?d_For_um_Work_on_=B3Hybrid_Access_for_Broadband_Networks?= =?iso-8859-1?Q?=B2_(WT-348)"?= Thread-Index: AQHP7ebM3TmRiAKOr0eUpP4sbHAVFJxE62qQ Date: Tue, 28 Oct 2014 04:04:47 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B449036E17@nkgeml504-mbx.china.huawei.com> References: <31246_1413972312_54478158_31246_662_1_81C77F07008CA24F9783A98CFD706F71142BD145@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.97.86] Content-Type: multipart/related; boundary="_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/bgLOEai947_WmcHYicSYx3hRy_8 Cc: HOMENET Working Group , "mif@ietf.org" , "dmm@ietf.org" Subject: [DMM] =?iso-8859-1?q?=3D=3Fiso-8859-1=3FQ=3FRE=3A=5F=5FRE=3A=5F?= =?iso-8859-1?q?=5Bhomenet=5D=5FFwd=3A=5FNew=5FLiaison=5FStatement=2C_=5F?= =?iso-8859-1?q?=5F=22Broa=3F=3D_dband_For_um_Work_on_=B3Hybrid_Access_for?= =?iso-8859-1?q?_Broadband_Networks=B2_=28WT-348=29=22?= X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 04:05:21 -0000 --_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_ Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_" --_000_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Sri Thanks for the comments. Just some clarification for the cross email. A new version about the architecture is uploaded.. http://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-archi= tecture-01.txt There are some new requirements about the hybrid access topic, such as bon= ding, traffic policy distribution etc. Do you mind to share more additional technologies about the existing protoc= ols solution for hybrid access. Which exact issues it is really solving, in order to evaluate if the existi= ng solutions properly solve this use case? Best Regards Li From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] Sent: Wednesday, October 22, 2014 6:56 PM To: pierrick.seite@orange.com; Xueli; Ted Lemon; STARK, BARBARA H Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org Subject: Re: [DMM] RE: [homenet] Fwd: New Liaison Statement, "Broadband For= um Work on =B3Hybrid Access for Broadband Networks=B2 (WT-348)" Hi Li, While the term "hybrid-access" sounds fresh and new, but its important to u= nderstand that this is largely a use-case around mobile networks. Per my co= mments in the last HOMENET meeting, mobility working groups have defined so= lutions for this multi-access use-case. There are clearly mechanisms that a= llow network entities to negotiate flow policies and switch traffic on appl= ication basis. The access can be LTE, WLAN, SatRAN, Fixed line ..etc, but t= he negotiated policies allow the peers to agree on binding a flow to a give= n access. Wearing cisco vendor hat, we have deployed solutions for this us= e-case for the last decade. So, I agree with the BBF use-case and I think w= e should probably draft a BCP-type solution document, explaining BBF on the= tools that are available for addressing this issue. If there are minor gap= s, we should certainly propose extensions to the protocols. As pierrick, I'm also not in favor of defining a control protocol for GRE a= s its not needed. GRE is a use-plane protocol and the semantics that are pr= esent in the header are only designed to be used for adding meta-data relat= ed to the IP flows in that tunnel header. There are no semantics for defini= ng a new signaling layer in a user-plane protocol. GRE was always used in c= onjunction with a signaling protocol and that signaling protocol is IPsec, = MIP, PMIP ..and so on. However, you design that control protocol, it will e= xactly smell and feel like existing protocols. The aspect around subscriber= identity, authorization, access policy, Traffic flow template definition .= ..all of this has to be modeled and in the process we will end up reinventi= ng every thing that we defined over the last many years, but it will have a= new title, "GRE-CP". Regards Sri From: "pierrick.seite@orange.com" > Date: Wednesday, October 22, 2014 3:05 AM To: Xueli >, Ted Lemon >, "STARK, BARBARA H" > Cc: HOMENET Working Group >, "mif= @ietf.org" >, "dmm@i= etf.org" > Subject: [DMM] =3D?Windows-1252?Q?RE:_[homenet]_Fwd:_New_Liaison_Statement,= _"Broadband_For?=3D um Work on "Hybrid Access for Broadband Networks" (WT-= 348)" Hi Li, Architecture considerations and solution design are two different things, w= hich should not be addressed in the same I-D. People may agree with the big= picture depicture and architecture but not agree with going on extensions = to the GRE protocol to address the issue. BTW, I think that going for exten= sions to GRE header to address the hybrid access use-case is not the right = way. Actually, IETF solutions already exist (RFC 4908 ) and, moreover, the= re is ongoing effort in DMM to update RFC 4908 to meet hybrid access requir= ements. BR, Pierrick De : Xueli [mailto:xueli@huawei.com] Envoy=E9 : mercredi 22 octobre 2014 11:48 =C0 : Ted Lemon; STARK, BARBARA H Cc : HOMENET Working Group; mif@ietf.org Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on = "Hybrid Access for Broadband Networks" (WT-348)" Hello Thanks Barbara to send this liaison out. Hybrid Access network is that Residential gateway (RG, or CPE) is extended = with more than two access lines (e.g. DSL + LTE) in order to provide higher bandwidth for the customers. Th= e scenario and architecture are shown as follows [cid:image002.jpg@01CF9A07.BF8CD480] Right now, we have two individual drafts, one for architecture and requirem= ents, and the other one is for an optional solution. The draft (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-network-arc= hitecture-00 ; ) proposes the architecture and gap analysis. The solution draft proposes one option for the solutions, http://tools.ietf= .org/html/draft-heileyli-gre-notifications-00 We did not combine them as one draft, because we believe there may be other= candidates, and we would like to have further discussions in the related g= roups and IETF. We used to present it in Homenet in Toronto. Now the authors have invited Orange to join this architecture work. We will= send out the new version of these drafts soon. We are glad to invite the experts for comments. Best Regards Li Xue on the co-authors behalf -----Original Message----- From: homenet [mailto:homenet-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Wednesday, October 22, 2014 3:05 AM To: STARK, BARBARA H Cc: HOMENET Working Group Subject: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on= "Hybrid Access for Broadband Networks" (WT-348)" On Oct 21, 2014, at 2:55 PM, STARK, BARBARA H > wrote: > FYI. I made sure they were aware of IETF mif and homenet activities in th= is area. I intend to try to prevent having to track efforts that try to do = the same thing in two different ways. But some of the BBF effort may be foc= used on what can be done around "bonding" of multiple interfaces that are u= nder the control of a single service provider. I don't see this in mif or h= omenet. Thanks. I couldn't really tell what was being proposed from the Liaison s= tatement, so this information is helpful. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___________________________________________________________________________= ______________________________________________ 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_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Sri

Thanks for the comments. = Just some clarification for the cross email.

A new version about the archite= cture is uploaded..

http= ://www.ietf.org/internet-drafts/draft-lhwxz-hybrid-access-network-architect= ure-01.txt

There are some new requir= ements about the hybrid access topic, such as bonding, traffic policy distr= ibution etc.

Do you mind to share more addit= ional technologies about the existing protocols solution for hybrid access.=

Which exact issues it is really= solving, in order to evaluate if the existing = solutions properly solve this use case?<= span lang=3D"EN-US">

Best Regards<= /p>

&n= bsp;

From: Sri Gundavel= li (sgundave) [mailto:sgundave@cisco.com]
Sent: Wednesday, October 22, 2014 6:56 PM
To: pierrick.seite@orange.com; Xueli; Ted Lemon; STARK, BARBARA H Cc: HOMENET Working Group; mif@ietf.org; dmm@ietf.org
Subject: Re: [DMM] RE: [homenet] Fwd: New Liaison Statement, "B= roadband For um Work on =B3Hybrid Access for Broadband Networks=B2 (WT-348)= "

&nbs= p;

Hi Li,

&nbs= p;

While the= term "hybrid-access" sounds fresh and new, but its important to = understand that this is largely a use-case around mobile networks. Per my c= omments in the last HOMENET meeting, mobility working groups have defined solutions for this multi-access use-case. There are cl= early mechanisms that allow network entities to negotiate flow policies and= switch traffic on application basis. The access can be LTE, WLAN, SatRAN, = Fixed line ..etc, but the negotiated policies allow the peers to agree on binding a flow to a given access. &nb= sp;Wearing cisco vendor hat, we have deployed solutions for this use-case f= or the last decade. So, I agree with the BBF use-case and I think we should= probably draft a BCP-type solution document, explaining BBF on the tools that are available for addressing this issue. = If there are minor gaps, we should certainly propose extensions to the prot= ocols.

&nbs= p;

As pierri= ck, I'm also not in favor of defining a control protocol for GRE as its not= needed. GRE is a use-plane protocol and the semantics that are present in = the header are only designed to be used for adding meta-data related to the IP flows in that tunnel header. There = are no semantics for defining a new signaling layer in a user-plane protoco= l. GRE was always used in conjunction with a signaling protocol and that si= gnaling protocol is IPsec, MIP, PMIP ..and so on. However, you design that control protocol, it will exact= ly smell and feel like existing protocols. The aspect around subscriber ide= ntity, authorization, access policy, Traffic flow template definition ̷= 0;all of this has to be modeled and in the process we will end up reinventing every thing that we defined over th= e last many years, but it will have a new title, "GRE-CP".

&nbs= p;

Regards

Sri<= /o:p>

&nbs= p;

From: &quo= t;pierrick.seite@orange.com" <pierrick.seite@ora= nge.com>
Date: Wednesday, October 22, 2014 3:05 AM
To: Xueli <xueli@huawei.com>, Ted Lemon <Ted.Lemon@no= minum.com>, "STARK, BARBARA H" <bs7652@att.com>
Cc: HOMENET Working Group <ho= menet@ietf.org>, "mif@ietf.org<= /a>" <mif@ietf.org>, "<= a href=3D"mailto:dmm@ietf.org">dmm@ietf.org" <dmm@ietf.org>
Subject: [DMM] =3D?Windows-1252?Q?RE:_[homenet]_Fwd:_New_Liaison_Sta= tement, _"Broadband_For?=3D um Work on “Hybrid Access for Broadb= and Networks” (WT-348)"

&nbs= p;

Hi Li,

<= /span>

BR,

Pierrick

<= /span>

De : Xueli [mailto:xueli@huawei.com]
Envoy=E9 : mercredi 22 octobre 2014 11:48
=C0 : Ted Lemon; STARK, BARBARA H
Cc : HOMENET Working Group; mif= @ietf.org
Objet : RE: [homenet] Fwd: New Liaison Statement, "Broadba= nd Forum Work on “Hybrid Access for Broadband Networks” (WT-348= )"

Hello =

Thanks= Barbara to send this liaison out.

Hybrid= Access network is that Residential gateway (RG, or CPE) is extended with m= ore than two access lines

(e.g. = DSL + LTE) in order to provide higher bandwidth for the customers. The = scenario and architecture are shown as follows

3D"cid:image002.jpg@01CF9A07.BF=

Right = now, we have two individual drafts, one for architecture and requirements, = and the other one is for an optional solution.

The dr= aft (http://tools.ietf.org/html/draft-lhwxz-hybrid-access-net= work-architecture-00 ; ) proposes the architecture and gap analysis.

The so= lution draft proposes one option for the solutions, = http://tools.ietf.org/html/draft-heileyli-gre-notifications-00

We did= not combine them as one draft, because we believe there may be other candi= dates, and we would like to have further discussions in the related groups = and IETF.<= /p>

We use= d to present it in Homenet in Toronto.

Now th= e authors have invited Orange to join this architecture work. We will send = out the new version of these drafts soon.

We are= glad to invite the experts for comments.

Best R= egards

Li Xue= on the co-authors behalf

-----O= riginal Message-----

From: = homenet [mailto:homenet-bounces= @ietf.org] On Behalf Of Ted Lemon

Sent: = Wednesday, October 22, 2014 3:05 AM

To: ST= ARK, BARBARA H

Cc: HO= MENET Working Group

Subjec= t: Re: [homenet] Fwd: New Liaison Statement, "Broadband Forum Work on “Hybrid = Access for Broadband Networks” (WT-348)"

On Oct= 21, 2014, at 2:55 PM, STARK, BARBARA H <bs7652@att.com> wrote:

> F= YI. I made sure they were aware of IETF mif and homenet activities in this = area. I intend to try to prevent having to track efforts that try to do the= same thing in two different ways. But some of the BBF effort may be focused on what can be done around "bonding&= quot; of multiple interfaces that are under the control of a single service= provider. I don't see this in mif or homenet.

Thanks= . I couldn't really tell what was being proposed from the Liais= on statement, so this information is helpful.

______= _________________________________________

homene= t mailing list

homenet@ietf.org

https= ://www.ietf.org/mailman/listinfo/homenet

______________________________=
___________________________________________________________________________=
________________

Ce message et ses pieces joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc

pas etre diffuses, exploites o=
u copies sans autorisation. Si vous avez recu ce message par erreur, veuill=
ez le signaler

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

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

This message and its attachmen=
ts 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 emai=
l in error, please notify the sender and delete this message and its attach=
ments.

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

Thank you.

--_000_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_-- --_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9036; creation-date="Tue, 28 Oct 2014 04:04:47 GMT"; modification-date="Tue, 28 Oct 2014 04:04:47 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCADWAawDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0uiii uc4gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKbHLHMgeJ1dCSAynI 4OD+tADqrXNxdxSBbfT2uVIyWEyJg+mGqzRQBUmub2NwItMeZSoJYXCLg9xgntSy3N4k+yPTWlj4 /eCdF+vBOeKtUUAVXubxbny101ni3Aed56AY9duc0fabz7V5f9mt5O7HneemMeu3Ofwq1RQBVjub xrny301o4skecZ0Ix67Qc1aoooAKKRmVELsQqqMknoBQrBlDKQQRkEdCKAFooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKaZYxMs JdRIylgmeSBjJ/UfnTqACiiigAooooAKKbHLHMpaJ1cBipKnOCDgj8DTqACiio7idLa2luJM7IkL tgZOAMmgCrq9xJFaCC3OLm6YQw/7JPVv+AjJ/CrVtbxWltFbQLtiiUIo9hTl2SqkoUHIypI5AI/S nUAFFFFABRRRQAUUUUAFFFFABgEYIBB6g96zdIP2V59JdiTaENDnq0Lfd/LlfwFaVJsXfv2jfjG7 HOPTNAxaKbHLHMC0bq4VipKnOCDgj8DTqBBRRUVxdRWvleaSBLIIlbHAY9M+men1IoAlooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAMubRjLrcV/ 9su1RYnUotww5LKQAP7vByPpVoWCi6+0fa7zO7d5ZuG8v6bemPale7K6pDZbARJC8u/PTaVGMf8A Av0qzQN3Ksdgsdx5/wBrvWOSdj3DFP8AvnpiiHT1hmMgu7185+WS4Zl59qtUUAVIdPWBmYXl9JuU riW5ZgM9xnofeiLTliVx9svn3rty9yzFfceh96t0UAZuj6S2mJKHuZ5mklkcB5mdQGYkcHv6mtKq 1hdm9hkkKBNk0kWAc52sVz+OKsM6ou52VR6scChg9xaq6qjSaPexopZ2t5AqgZJJU4FLaaha3tlH dxSqI5FDDcwBGfXng064vre1tJbp5UMcSMxKsDnAyQOetDBaMfbgrawgjBEagg9uKkpkM0c8SyxO GVgDkEGn03uIKKKKQBRVNr24GrLYi0BjaMyed53YHH3cep9ap3Wt3kFzLEmjvKqGTa3nhWkCAEkL t/2uOecUDszYorHGuXDahLaR6crmKbyyBcjeRhSWCbegDAnn1rYoCwUUUUCCmyx+bE0Zd03DG5G2 sPoe1OooAytN0U2UFxG97dsZpZGBFyx2hmyCPRvU1aTTlSF4vtl8wfHztcsWXHoe1Osbs3kUrlAn lzyRYBznaxGfxxVmgbvcqDTlW3aH7ZfEMwO83LFx7Buw9qSTTIpdOmsZJp5VmBG+aUuynsQT6HBq 5RQFytp089xYxtdRmO4XKSgjGWBwSPY9R9as1Wvbz7Ebd3TMMkojkfP+r3cKfpnA/GrNAgooooAK KytV1w6XqFjamykmF5JsDq6AA4Pqw74HPHPrxRf64bHWrLTTZSSfa9wEgdAAQM9Cc+vX04zTsOzN WisqfXDB4ht9INnI3nxs6yh0xxjtuz0z78cA0f24R4kGjGzkBMPmCbemOuOmc9OfX2xzSsFjVorK g1wzeIp9HNlIhiiEnml0IIJOeA2fT355ArVoBqwUUUUCCiiigAooooAKKKbLIsMTSPu2qMnapY/g ByaAHUVl6drsN9bTTNFOnkyOpAt5OQrlRjK8n2HSrKapbPA8wW42RkA5tZA3PopXJ/Cgdi3RVQap bG3acLcbFbaQbWTdn/d25x74o/tO2FsLjbcbC23H2WTdn/d25x74xQBborL1LXYbHSJL9IpnwpKK 1vIMkHuNuQPc1oQTx3MQljDhScfvI2Q/kwBoCxJRRRQIKKKKAKklrI2swXY2+VHbyRtzzlmUjj/g Jq3VOS4lXW7e2DfuntpHZcdWDIBz+Jq5R0GwooooEFFQXzyRWFxLCwSSOJmRmXcAQCenesrRdUur uBru4uhLAsfzoLRo5A+FPyryWXDelCHbS5o6ZayWlvKku3L3Esgwc8M5I/Q1YlhiuIzHPFHKh6rI oYH8DWdp2uw31vPK0U6eTJIpAt5OVVioIyvJ9hzVldUtngeYLc7EIBzayhufQbcn8KGDvcZZaNp9 lp8dktpA8aKAd0K/OR0JGME0650iwubCWyNpAkUisMLCuFJGNwGMZ96Zouqpq+nRXIjeN2QM6tG6 gE+hYDP4Vfpu99Qu0yK2tYLOBYbeKOJFA4RAoJx1wO9S1S1S5lsoortDmCKQfaFxn92eCw/3SQfp mrtIQUUUUAZl7YahPetPb3dtEhgaEK8DMwB5JyHHP4U5dPu47mwdbqIx2kPlMHiYvJkAE53cdPQ1 o0UDuYb6DdnULm7iu7WKS4k3eatu3mouFBUNv54UdR3Nbp5JOMUlFAN3CiiigQUUVStLia71C7ZX H2SAiFAAPnkHLtn24X8DQA7TbaS1hmSXbl7mWQYOeGYkfoat0UUAFFFFAEV1bR3lrLbTDMcqFWx7 96bYi6WyiW9Km4VdrspyGI43fj1/Gp6KACisnxBdataW8L6VEkrGVfMUxM52A5bofTPue1M1u71i 2NkdPjilDSL9o/cu2F6MeD05HHX9aaQ7Gu0UbnLxox6ZZQe+f580NFG7b2jRm4+YqCeOnNOGcc4z 3x0opCGmKMvvMaF8g7iozkdOfxP50eVHv3+Wm/Od20ZzjHX6cU6igBoijD7xGgfJO4KM89efwH5U 6isfT7rWJNevILuOMWSgGCRYWXcRwwBJ9cdevagZsUVkaRdavPqV9FqEca26MDbusLLvGMHBJ9Qe vPIPStegHoFFFFAgooooAKKKB1oAZFBHboUiQIpYuQPUnJP4k0+s/RGZrKUsxJ+1zjk5/wCWjVoU De4UUUUCGTwR3ULwTIJI5BhlPcU/rWf4gZl8P3zKxUiLgg4I5FaJ60DEooooEFFFFAEDWgfUYr3e QY4ni244O4qc5/4DU9Z8rN/wkdqu47TaSkjPGdyVoUdBsKKKKBEdxAtzbSQOXVJUKMUbBweDg9qq Wej29lPHMk11K0UZjj86beEU4zj/AL5H5VfooGMigjt1KRIEDMXIHdmOSfxJp+az9FZmtJyzE4vJ xyc8eY1aFAPcZBDFbQJBCgSKMbUUdAKfRRQIbIiSxtHIoZHUqynoQeoqKytms7KK2aZpvKXaHYYJ A6Z/DAqeigAooqtcz3sTgW1gLlSOWNwseD6YINAFmiqk1xfo4EOmrMpAJY3Kpg9xgj9aWW4vkn2R acssfH7z7Sq/XjFAFqiqr3F8tz5aacrw7sed9pUceu3Gfwo8+++1eX/Z6+Tux532lenrtxn8KALV FVY7i+a52PpypDkjzftKnj124zVqgBHDFGCNsYggNjOD61DZWkdjZRWsWSsa4yerHqSfcnJ/Gp6K ACiiigAooooAKKKy/EOn32o6d5Gn3T2828HeJNo4OeeDnpjt1oGjUopkKskEauzM4Ubi7BjnvkgD P5U+gQUUUUAFFFFABRRRQAUUEZBGSM9x1FZGhadqFjNetfXUk6zy+ZEHlD7AeoPyjnjr056cUDNe iiigQUUUUAFFFKOtAFWBrK1tneKWJIRK5d2k+UOWO7JP+1mpVubdy4W4ibyxl8SA7B6n0/Guduhv 8H6igQuzXUwULEZDnzz/AAjrUTwSvfX7TRtdxrcW0k/l2jRiWJVOQFOd+CQSM9ulNIu2504uIGg8 9Z4jCBnzQ4Kfn0prXtmkayteW6xscK5mUKfoc81gXKQSC6njt7mCzmnhMZjtiw8xckyGLGdn3QeO cfjTZLW2fQry4msU3q0wgaK1dfOLqAX8rBIJxj8M96LCsdA62upWbxb47iCUbWMb5B9sip6w9SsJ JvD9wujEQm5BkaPyDmRjgcAldvStF4NRMSKuowiQZ3P9kyG9ON/H50CLdFVJYNQZIxFfxRsFw7G1 3bz6gbhj6c0TQag2zyb+KPCgNutd24+v3hj6UgLdFVJodQeQGG/iiXAyrWu8k9zncKWWG/afdFfR Rxcfuzbbj7/NuH8qBExt4muUuSv71EKK2eikgkfoKkrIns9UfxDDcR3aLbLBIvNvnbllIUndyTg8 47VsDrR0GyL7RB5xh8+LzR1j3jcPw601L2zlLCO8t3KDLBZVO0dycHgVj6fHaRiztbrTXl1CCYu0 gtz8r5OZfM6EHPqTzjFVdLthPJPI0ccUNrdTzgC1dZXDFwASRgqQc4Ge1Mdjooby0uHKQXdvMwGS scqscfQGpq5XwsRF9jhlgMk3k7UcWjw/ZlCDcrZGCSR611VDVmJqxBaJbJE4tSpQyuW2tn5yx3fr mp6ztD/485/+vy4/9GNWjSB7sKKKKBBRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUANll jgiaWV1jjUZZmOABTqoa1o9vrmnPY3OBG55bYCwHfbnoferNpbraWcVuu3ESBcqgUH3wOBmgZNUU 13a2zBbi6ghJGQJJVUkfialrG8QSWyyaeJoGlZLpJGK2zSbUG7JJCmhbglc2RyARyDyCKaJEMpiD AyKoYr3AOQD9OD+Vc1rCE3upTxNfB4rON4FiEoTzcnBAAwTjaMfmKmuYLKPxC19cW124ntozE0Ql O5wzZGFOBwV4OB+tOw7HRYOM44owfSuWlXUF1mVpJCk5ucxMEnbMWRgAL+7xjIOe+asxJbzeJ7tX mvlXdGYUHmrH5gzuOcY9BjOKLCsdBg+lGD6da5WyDQXNvNE98ZJL+eMiUSlViw20EEYC52kE+vWn aJHerfwJcyMJiGF2u2clzjnJb5Bz0K/hRYbVjpY5Emj8yJw6ZI3KcjIOD+op1YHh23tbHNqttdJd K8ocuJSirvJHLHbyCMYredFkRkdQysCCGGQR7ikxPcSOWOZS0Tq4DFSVOcEHBH4GnVmaJoVvoUc6 QMrefJ5jHywpBPUcds5IHbNadABRRRQIKKKB1oAhtLmK5iaSFSqrI6HIx8ysQf1BqbNUdHikhs5V lRkY3MzAMMZBkYg/iKvUDe4uT60ZNJRQIhvLqOytJbqbcY4l3NtGTipqoa5FJPod5FCjSSPHhVUZ JORWgetA+glFFFAgooooAha6jW9jtDu8ySNpBxxhSAf/AEIVNVGWKQ6/bTBGMa2sql8cAlkwP0P5 VeoGGaXJ9aSigQuT60lFFAEFpcxXUTvCpVVleM5GPmViD+oqeqOjxSQ2syyoyE3UzAMMZBkJB/EV eoG9wooooEFFFFABRRVa5sI7pw7zXSEDGIbh4x+SkUAWaKqTadFO4dp7tSABiO6kQcewPX3pZdOi mn85p7tW4+VLl1Xj/ZBxQBaoqq+nxPc/aDNdhsg7VuXCf98g4x7Uf2fF9q+0eddbt27b9pfZ/wB8 5xj2oAtUVVj0+KO588T3ZbJO1rl2T/vknGKtUAFFFFABRRRQAUUUUAFU9U1az0e2FxeyMiFgowhb qQO31q5UF7Y22o25t7uPzYiclCxAP1x1/wAaBq3UljkSaNZIzlHGVOCMj6Gn5I701V2qFBJCgDJO T+feloELk+tGaSigAzS5PrSUUALk+tJmiigALbVJJ4Ayao6drNjqrzpZys7W7lHDIy4Ix6j3q9Va 00+2sXle3jKNO26Qlyd7f3jk9ff6elA+hZooooEFFFFABSM6opd3VFHVmOAPxpaRlV1Kuqup6qwy D+FAFSz1WyvYZJY7iILG7I2ZF42sVz16Ejipxd2rI0i3UBRfvMJVIH1OeKhtNKsrKGSKK3iKyOzt mNedzFsdOgJ4qYWlqqNGtrAEb7yiJQD9RjmgegC7tTGZBdQGMHBfzV2g+mc0fa7Xy/M+1QeXnG/z V259M5oFpaiMxi1gCE5KeUu0n1xij7Ja+X5f2WDy852eUu3PrjFAEF7qtlY2D3klxE0SAkbZF+bH Yc8mrUckcqb4pEkU/wASMGH5iq17pVnfWL2ckEaxOCBtjUbc9xxxVmOOOJdkUaRqP4UUKPyFADqK KKBBRRRQBWe7ZdVhstgKyQPKWzyCpUY/8eqzVSS1kbWILsFfLjt5IyM85ZlI/wDQTVugYUUUUCI7 iR4raWVEDsiFgpbaDgZxnBxVCy1eSUW5vbaO0W5h82JxPvXAAJDEgYOCD6dav3Eby20sSOEZ0Khi u4DIxnGRmqFlpMkIgF7cx3S20PlRIINi4IAJYEnJwB+tCHpYntNVsr2KSSO4iCxO6NmReNrbc9eh xwamF5aMjSC7gKL95hKuB9TmorTSrKyikjit4isru7ZjXnc27HTpzwKmFpahCgtYAjfeURLg/UYo DQj0/ULfU7OO6tpFZZFDbQwJXPY4PFWarafp9vplnHa20aqsahdwUAtjucDmrNNgMmmjt4JJ5W2x xKXY+gAyajsZpriyhmuIhDJIu4xg5256A++MZ96j1G0e+WCDIFv5oecHq6ryF+hOM+wq2eTmkAUU UUCCiiigAooooAKKKKAEffsbywC+DtDdM9s1Bp94t/Yx3IUozZDoeqODhlP0INWKp29rLbajdSIV +zXAEm3PKy9GwPQgA/Ue9Ay5RRRQIKKKKACiiigDK17Wm0SCGYWhnWSVUYiRV2gnk8nsMnPQY5pu s65JpBsv9BMoupVjb98g2Z+p7HHPTnrWsyK33lVu3IzQyI33kVuMcgHimPQUZxyMHuPSiiikIKKK KACsmw1uS81y80xrIxfZQpEnmo27PXgH1446Z5xWtSBEByEUHnkDnnrQMytK1x9S1K+s2sjB9kcD cZUbcCB6H13DjjjHWtakCIpyqKD0yABS0AwooooEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFF AFKSeVdct7YP+6e2kdlx1YMgB/U1dqBrRW1CK83kNHE0QXHBDEHP/jtT0DCiiigQUUUUAUtKuJbm 2meZ9zLczIDjoquQB+QqzcTrbxGVklcDtFGXb8hzTLO0WzieNXLh5XlJI6FmLEfrU9DG9zL03W1v dIivpLa6VmVSypbSHk/3RjJHvTr3WEttJnvUtromNHKo1tIDkLnkYyB71fhhjt4UhhQRxoMKq9AK WSNJonikUOjqVZT0IPBFNhpchsbtb21SYRyx7gMiSNkOcdgece9WKRVCqFUYAGAPQUtJiCiiigAo pcH0pMUAFFLg+lJQAUUUUAFFFFAFLS55biCdpX3FbqZAcdFVyAPyq7UFnaLZxyIrlhJM8pJHQsxO P1qegb3CiiigRBe3aWNlLdSDKxLnb3Y9h9ScD8aLFLmOyiW8k8y425lYDA3Hkgew6fhRdWaXcluZ GOyCUS7OzsB8ufoefqBU9AwooooEZGrz6zFqNiNPVGtmf/SMwF9qnjJIYZ5IOBzwT0o1GbWY9cso 7NUaxbIuCYC23PQk7hnkHp0zk5rXop3HcyLifWV8SW8UKodNZCJW8gnaxwR8272YZxgZGc5o8/WB 4nEW1Dphi+95B4frjdu9O+MdsZrXoouFzIt5tZPiWeGZU/s3yx5biAj5hnIzu9CvOMHBxiteiikD CiiigQUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAGRPeaoviGG3jtI2tmgkbm5xuwyjc Rt4IyeM96uia/wDtWw2MQg3Y837T82PXbt/TNWqKBlWOa/a42SWMSQ5P7wXO447Hbt/rRDNqDTFZ rGGOPn51udx9uNo/nVqigCpDNqLswnsIYgFJUrdb8nsPuDH1oin1Flcy6fChC5QC63bj6H5Bj681 booAytCutRuYpjfW6oFnlVXE288OQFxtHAHetWiigHuFU9YJGiX5BwRbScj/AHTVymTRRzwyQyru jkUoy+oIwRQCdmJbf8ekP/XNf5CpKj3xQtFAWVS42xqT97A6D8KkpsQUUUUgOfv1szrN+0948DRW aSJtumXY+W5C5xngcY5qrdXDSMZ7u5Z3jSDzI7e7MU1sxAJAj6Puzn1xkV0j2drJL5z2sDygg+Y0 SlvbnGac1tbvMJmt4WlU5EhjBYfjjNNOxVzHe6sNN1bU7uScnyoo2Mf2gtgnOcIWxnp2rcqBrCye QyNZWzSE5LmFSxPrnFT0hMKKKKBBTZTIsTGJBI4HyqW2gn64OKdTPOi+0fZ/MXzdm/Z325xn6ZoA y9JvNVntrlrizjLJPKsebnrhyAv3OAB3q4k2omF2ewhWUY2ILrIb1ydnH5GrdFA7lQTaibdmawhE wYBY/tWQR67tnH0xTJ7+ez02W6urZI5U4jiSXzN7HhRnA5JIFXqjlgimaMyoGMTh0z2YdD+tAEWn WjWNjHDI5kl5aVz/ABOTlj+ZqzRRQIKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAp6raPd2R8ji5hYTQH0deQPx5B9 jU1ndx31nFdRZCSruAPVT3B9wcj8KmoAA6AD6UDCiiigQUUUUAFFFFABRRRQAjMqIzuwVVBLE9gO prP0dGmjl1KVCst6wdVPVIhwi/lz9WNaJGRgjIooGFFFFAgooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAqtc6fb3cgeUzggY/d3EkY/JSBVmigCpNpltcOHkNxlVCjZcyKMD2DD86WXTbaefznNxv4 +7cyKOPYNirVFAFV9Nt5Ln7Qxn8zIbi5kC5/3Q2PwxR/Ztv9q+05n8zdu/4+ZNuf93djHtirVFAF WPTbeO5+0KZ9+SfmuZCvP+yWx+lWqKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAopHBMbBW2kg4YDOPeu f8PXup6lGk73crGONTLHcWyxrIWTIKlQDgH8xQOx0NFY9pfyW+jtI0W+c3bwKplZlLmQqPmPIXP5 Dio21nUYZruKe0tR9llgRikrHeJDjI44xnoadgszcorJutWu7az1Wb7NC8mnyfKoZsSJtDenDYOP Sm3usXtgkC3NtbxzXMhEfzO6ooGTu2rnd24496LBZmxRVTTL039mJmjMbBihGGAOO67gDg/Smarh YUke+ntYlJBW3A8yVj91VPPOewHP0pAXqKzXm1e20u0P2WK6vC6JcK8ojCqfvNnoSPQde1aR60CC iuc1rVr6yudTSGW4xDaxyQ+XarIsbEtkscdPl7+pq3e6vdWUt1b+TBJOgiNorMQbjedvPHGD6U7D szYorAi1PUbT+0ZZY0ntLS7KO7ynzApCkhBjGFLd+TV1b7UX1e5so7S3MVuYy0xlIyrZ4Ax94Yz6 UWCxpUVmwTSJrV+k4AVII5FKSMRty/8ACeA3HOOv4VVS+1GfUtKldEhtLsOQscpJI2blDgjr0OR0 5FFgsblFMmZUgkdpPKVUJL4B2gDrzXNaJ4kd7K7kvbuO9eK3W6TytgYISRsO3jIIH/fVILHUUVly 3+p2UM017ZW5jWNShgmJzIWACHcOOv3ulR3mqalpkLve2lt8zpHC8Tuys7E5DDbuAGM8A5p2CxsU VkQ6xdT6fcSw2YmnhdVARXVJAe43AMcDOQOeKI9Vv5NMedLFHuUn8poUL5Uf3ipAbOOdo7EUWCxr 0VU0y8kvrITTIkcm9lZEJO0g4wcgEH1HaotVlvYzB9l84Rkt5zwRCWRePlwp6jPU49KQWNCisi31 G8nitbe1e2vLh4DNJO4aOMgNt4UAkHPbtg1BceILu3m+zyWkUVxFCsk8bGR/mbOFQopHQdT607BZ m9RWJd65ewyztFZRNbQWqXTNI7K+1s5Xbj73B9qk1HXBYXyxAwSpuRZEG/zFLHA5AKjqDgkcUWYW Neisya+1IazLYW9pbyIkSS+a8pX5SSCpGPvccdvWnxyTf8JI8MgG1rXdGVkbGN+OVPGcnqO1ILGh RWVDq1xJ9nuWt4hZXM3lRMHPmAkkKSMYwSOnUVq0AFFFFAgooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAR1DoyHOGGDg4P51WtdNtrOyNnAZlhxgAzuSo9AScj8KKKAIY9FtI LWe3hjkdZskpNcSMpYnOckkg55yOahsdBEKXovVUm9ZGdUld8bRwd7fMTnnPGMDFFFMd3Yk/sDTv IuINs+y6YNP/AKTJmQgYyTuz0/kKsNptu9ssDGZgjbkczuZFPqHzuH50UUguyW3t47WLy495GSxL uXYk9ySSTUV5pttfSwzTeaJIM+W8czxlc9fukelFFAiOfRtPurKCzuIDLDbyLLGHkYkOpyDnOT+N Xjyc0UUAUbjRrK6e5eZJSbpBHNiZwGUdBgHjv09TUUul3U+tWV5LHbG1sVfyiXZpSzADJyMevfvm iimhj10LTluXuBC5eSXzZMzOVdx0LLnBx2z0wKlj0u2ivnvUM/nSHL5uHKtjplc44z6UUUguNi0m 1ivmvVNx57cMWuJCCOcDaTjHJ4x3piaHp8d1FcpE4kgYmL98+I89QozgA+nSiigLlq7tIb60ktbg M0Uq7XVXKkj0yOagbSLJ5Y5ZI3kaKEwKHlYgoeoIJw2ff0oooC4R6PYxxyRmN5Ukj8tlmleQbPQb icD6UJpFmsUkZWWQSABmlnd2GORgk5GDzxRRQFxH0aylgMMqzSgyLJue4dnDL90hicjFD6NYvAkL RyEJL5yv5z79+Mbt+ck4OOtFFAXLNtbQ2kIhhUqoJJySxJPUknkn3NRXem217NFNMJBLCCEkilaN lB6jKkegoooENfSLJ44UEbx+QpWNopWRlB6jcCCQepz3ofSbNljVVli8tPLBindCV9CQcn8aKKB3 GzaLYz+d5kcmJ4lhkAmcAoOgwDx+HqabcaFp9yWMscp3FWYCd1DMuMMQDywwOevFFFFwuSf2Xbf2 gb/M/ntgE/aH2kDoNucY5PGO9H9k2v8AaH2/Nx5/TP2mTGM5xtzjGe2KKKAFTS7OO6+0rGwcMXCm RiiserBM4B68gdzVuiigQUUUUAFFFFABRRRQB//Z --_004_01FE63842C181246BBE4CF183BD159B449036E17nkgeml504mbxchi_-- From nobody Tue Oct 28 11:45:13 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 112DE1A90D8 for ; Tue, 28 Oct 2014 11:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 eRIkH946guVq for ; Tue, 28 Oct 2014 11:45:08 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA21AC402 for ; Tue, 28 Oct 2014 11:45:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Q8vQ2ZU3U+2LYfLAtLSPsBeaLncIB079Qr7bF3xE5/+rVbROYQJqg4ki4mcBCZon; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.80]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XjBlT-0005JW-7Z; Tue, 28 Oct 2014 14:45:07 -0400 Message-ID: <544FE430.8030001@earthlink.net> Date: Tue, 28 Oct 2014 11:45:04 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" References: <20141027221050.26265.71506.idtracker@ietfa.amsl.com> In-Reply-To: <20141027221050.26265.71506.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141027221050.26265.71506.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020202010409070005040202" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac7ea0152333ad908c717f5fd4fbb155205350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/ypfe48tvAk7BOaDC6t3JhgoNxrQ Cc: Vijay Devarapalli Subject: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-01.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: Tue, 28 Oct 2014 18:45:11 -0000 This is a multi-part message in MIME format. --------------020202010409070005040202 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, The MNIDs draft has been updated. Comments are welcome, and the draft will be discussed at the Hawaii meeting if there is time. Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-perkins-dmm-4283mnids-01.txt Date: Mon, 27 Oct 2014 15:10:50 -0700 From: To: Charles E. Perkins , Charles E. Perkins A new version of I-D, draft-perkins-dmm-4283mnids-01.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-dmm-4283mnids Revision: 01 Title: MN Identifier Types for RFC 4283 Mobile Node Identifier Option Document date: 2014-10-27 Group: Individual Submission Pages: 7 URL: http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-01.txt Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/ Htmlized: http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-perkins-dmm-4283mnids-01 Abstract: Additional Identifier Types are proposed for use with the Mobile Node Identifier Option for MIPv6 (RFC 4283). 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. The IETF Secretariat --------------020202010409070005040202 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello folks,

The MNIDs draft has been updated. Comments are welcome, and the
draft will be discussed at the Hawaii meeting if there is time.

Regards,
Charlie P.

-------- Original Message --------

Subject:	New Version Notification for draft-perkins-dmm-4283mnids-01.txt
Date:	Mon, 27 Oct 2014 15:10:50 -0700
From:	<internet-drafts@ietf.org>
To:	Charles E. Perkins <charliep@computer.org>, Charles E. Perkins <charliep@computer.org>

A new version of I-D, draft-perkins-dmm-4283mnids-01.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-dmm-4283mnids
Revision:	01
Title:		MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Document date:	2014-10-27
Group:		Individual Submission
Pages:		7
URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-01.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-perkins-dmm-4283mnids-01

Abstract:
   Additional Identifier Types are proposed for use with the Mobile Node
   Identifier Option for MIPv6 (RFC 4283).

                                                                                  


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.

The IETF Secretariat

--------------020202010409070005040202-- From nobody Tue Oct 28 11:51:56 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6B1AC42B for ; Tue, 28 Oct 2014 11:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 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_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 oAuERByokTlS for ; Tue, 28 Oct 2014 11:51:51 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 67EF41AC43C for ; Tue, 28 Oct 2014 11:51:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=be1TDjwZjgTjYETvhj4AboQR9vPdkRtFwXG4UB4MHkvDT1CytBvQ1uZNTC6Zo4vj; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Forwarded-Message-Id:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [99.51.72.196] (helo=[192.168.1.80]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1XjBrh-0006Uy-Fh; Tue, 28 Oct 2014 14:51:33 -0400 Message-ID: <544FE5B2.1000900@earthlink.net> Date: Tue, 28 Oct 2014 11:51:30 -0700 From: Charlie Perkins User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "dmm@ietf.org" , Sri Gundavelli References: <20141027215933.17305.18978.idtracker@ietfa.amsl.com> In-Reply-To: <20141027215933.17305.18978.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20141027215933.17305.18978.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------090304070805010801010309" X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956527bd5036cbc8ac77260de8ae12a555850c658b2575b6dae350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 99.51.72.196 Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/w5WRfM0SOLPNSb-8YkYz5YnHjzU Subject: [DMM] Fwd: New Version Notification for draft-perkins-dmm-privacy-00.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: Tue, 28 Oct 2014 18:51:54 -0000 This is a multi-part message in MIME format. --------------090304070805010801010309 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello folks, We have put together a draft about privacy considerations for DMM. Privacy is a very timely subject, and I think that it should be a kept in mind during all design phases for the DMM teams. This is a simple and short draft to invite discussion. No doubt there is a lot of room for expansion of the discussion, and we will be happy to incorporate other guidelines or references to other relevant IETF publications that may be suggested. I have requested a time slot at the upcoming IETF for a discussion about privacy as it is related to DMM protocol development. Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-perkins-dmm-privacy-00.txt Date: Mon, 27 Oct 2014 14:59:33 -0700 From: To: Charles E. Perkins , Sri Gundavelli , Charles E. Perkins , Sri Gundavelli A new version of I-D, draft-perkins-dmm-privacy-00.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-perkins-dmm-privacy Revision: 00 Title: Privacy considerations for DMM Document date: 2014-10-26 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-perkins-dmm-privacy-00.txt Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-privacy/ Htmlized: http://tools.ietf.org/html/draft-perkins-dmm-privacy-00 Abstract: Recent events have emphasized the importance of privacy in protocol design. This document describes ways in which DMM protocol designs and DMM networks can reduce certain threats to privacy. 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. The IETF Secretariat --------------090304070805010801010309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello folks,

We have put together a draft about privacy considerations for DMM.

Privacy is a very timely subject, and I think that it should be a kept in
mind during all design phases for the DMM teams.

This is a simple and short draft to invite discussion. No doubt there
is a lot of room for expansion of the discussion, and we will be happy
to incorporate other guidelines or references to other relevant IETF
publications that may be suggested.

I have requested a time slot at the upcoming IETF for a discussion
about privacy as it is related to DMM protocol development.

Regards,
Charlie P.

-------- Original Message --------

Subject:	New Version Notification for draft-perkins-dmm-privacy-00.txt
Date:	Mon, 27 Oct 2014 14:59:33 -0700
From:	<internet-drafts@ietf.org>
To:	Charles E. Perkins <charliep@computer.org>, Sri Gundavelli <sgundave@cisco.com>, Charles E. Perkins <charliep@computer.org>, Sri Gundavelli <sgundave@cisco.com>

A new version of I-D, draft-perkins-dmm-privacy-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:		draft-perkins-dmm-privacy
Revision:	00
Title:		Privacy considerations for DMM
Document date:	2014-10-26
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-perkins-dmm-privacy-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perkins-dmm-privacy/
Htmlized:       http://tools.ietf.org/html/draft-perkins-dmm-privacy-00


Abstract:
   Recent events have emphasized the importance of privacy in protocol
   design.  This document describes ways in which DMM protocol designs
   and DMM networks can reduce certain threats to privacy.

                                                                                  


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.

The IETF Secretariat

--------------090304070805010801010309-- From nobody Wed Oct 29 07:56:37 2014 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0900D1A0110 for ; Wed, 29 Oct 2014 07:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 NcKLvu_Efkuy for ; Wed, 29 Oct 2014 07:56:31 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.167.192.145]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740001A00F9 for ; Wed, 29 Oct 2014 07:56:31 -0700 (PDT) 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 s9TEuSxg004401; Wed, 29 Oct 2014 15:56:28 +0100 Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 03CF420502A; Wed, 29 Oct 2014 15:58:05 +0100 (CET) Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EB0C5204FEB; Wed, 29 Oct 2014 15:58:04 +0100 (CET) Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s9TEuDkP004476; Wed, 29 Oct 2014 15:56:28 +0100 Message-ID: <5451000D.8090607@gmail.com> Date: Wed, 29 Oct 2014 15:56:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Jouni References: <544A1F04.3070505@gmail.com> <544A6991.4090303@gmail.com> <544A7BA9.3060105@innovationslab.net> <544A826A.4020607@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/q0jfenuQtWRvr26jRJmjlbq2CGk Cc: dmm@ietf.org Subject: Re: [DMM] offlisted mails - names of Work Teams X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: ,

USA Toll-Free:	888-858-6182
USA Caller Paid:	646-746-3029
For Other Countries:	Click Here to View Global Conference Access Numbers=
Access Code:<= span style=3D"font-size:12.0pt;font-family:"Verdana","sans-s= erif";color:black">	8774651

Subject:	Re: [DMM] Maintenance of Mobile IPv6
Date:	Wed, 29 Oct 2014 11:19:37 -0700
From:	Charlie Perkins <charles.perkins@earthlink.net>
To:	Alexandru Petrescu <alexandru.petrescu@gmail.com>
CC:	dmm@ietf.org <dmm@ietf.org>