Pierrick,
Thanks for reviewing the draft.
H. Anthony Chan
From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com]
Sent: Monday, November 13, 2017 4:33 PM
To: h chan <h.anthony.c...@huawei.com>
Subject: RE: Distributed Mobility Anchoring - Draft Review Request
Hello Anthony,
I'
Dirk,
Thanks for checking version 06 again. The corrections are now made in version
07.
H. Anthony Chan
From: dirk.von-h...@telekom.de [mailto:dirk.von-h...@telekom.de]
Sent: Friday, November 03, 2017 11:32 PM
To: dmm@ietf.org
Cc: h chan <h.anthony.c...@huawei.com>
Subject: RE: Distr
lto:c...@it.uc3m.es]
Sent: Monday, June 05, 2017 10:10 AM
To: h chan; Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; Seil Jeon; Suresh Krishnan; Byju Pularikkal
(byjupg)
Subject: Re: Distributed Mobility Anchoring - Draft Review Request
Hi Anthony, all,
Again, apologies for
just moves all the complexity to
>the so-called SM function.
>
>- With the fair disclaimer that I might not be objective here, I think
>the document misses quite a lot of existing works (even as active IETF
>drafts) proposing solutions for the distribution of mobility anchors.
Thank you for taking time out of your busy schedule.
H. Anthony Chan
-Original Message-
From: Carlos Jesús Bernardos Cano [mailto:c...@it.uc3m.es]
Sent: Thursday, May 11, 2017 5:01 AM
To: h chan; Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; Seil Jeon; Suresh Krishnan
: Thursday, April 06, 2017 2:34 AM
To: Sri Gundavelli (sgundave); dmm
Cc: Marco Liebsch; Dapeng Liu; h chan; Seil Jeon; Suresh Krishnan; Byju
Pularikkal (byjupg)
Subject: Re: Distributed Mobility Anchoring - Draft Review Request
Hi Sri,
Sure, no prob, but I might need one additional week as next week
Pierrick,
Thanks for reviewing the draft with the corrections and comments. Some
corrections and revisions are in version 05 and are explained below. Other
corrections will be made in version 06 which I am still working on.
Following sentence can be removed (no real added value and better
(byjupg) [mailto:byj...@cisco.com]
Sent: Monday, April 17, 2017 7:05 PM
To: h chan; dirk.von-h...@telekom.de; Sri Gundavelli (sgundave); dmm@ietf.org
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request
Hi Anthony
I did go through the latest version. Document is very thorough
to condense this way.
Meanwhile, I will wait after hearing the review comments from Carlos to make
the corrections before uploading a new version.
H. Anthony Chan
From: Byju Pularikkal (byjupg) [mailto:byj...@cisco.com]
Sent: Monday, April 17, 2017 7:05 PM
To: h chan; dirk.von-h...@telekom.de; Sri
Dirk,
Thank you so much for the review. I have just finished going through each of
the corrections (in-line) and am uploading version 04 with these corrections.
H. Anthony Chan
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of dirk.von-h...@telekom.de
Sent: Tuesday, April 11, 2017 7:03 AM
To:
support
H Anthony Chan
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandre Petrescu
Sent: Wednesday, June 29, 2016 9:51 AM
To: dmm@ietf.org
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05
Hi,
I support this draft but I have some
The updated draft-chan-dmm-distributed-mobility-anchoring-07 was uploaded 10
days ago. Please provide comments. Thank you.
H Anthony Chan
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen
Sent: Friday, February 26, 2016 3:51 PM
To: dmm@ietf.org
=1136694accessNumber=6467463029#C2
Access Code:
3101535
Continue discussions on the enhanced mobility anchoring.
H Anthony Chan
From: h chan
Sent: Tuesday, May 19, 2015 12:37 PM
To: 'dmm@ietf.org'
Subject: RE: Enhanced mobility anchoring
Let us schedule 2 teleconferences (one hour each
=1136694accessNumber=6467463029#C2
Access Code:
8774651
Seil will give short presentation based on the draft
https://tools.ietf.org/html/draft-yhkim-dmm-enhanced-anchoring-01
followed by feedback and discussions on the work on enhanced mobility anchoring.
H Anthony Chan
From: h chan
Sent: Tuesday, May 19, 2015
Let us schedule 2 teleconferences (one hour each) to accommodate everyone in
the doodle list:
1st teleconference: Friday May 22 at 9:30-10:30AM US Central Time
2nd teleconference: Wednesday May 27 at 9:30-10:30AM US Central Time
Thanks.
H Anthony Chan
From: h chan
Sent: Friday, May 15, 2015
Please check your availability for a teleconference to discuss enhanced
mobility anchoring. Thanks.
http://doodle.com/fibfbwybwhws65gb
H Anthony Chan
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
texts have been improved.
All 3 co-authors have carefully checked before we upload. We are now waiting
for your feedback.
Thanks.
H Anthony Chan
From: h chan
Sent: Thursday, March 26, 2015 5:55 PM
To: dmm@ietf.org
Subject: Enhanced mobility anchoring
I was asked to provide more explanation
Please check your availability for teleconference next week. Thanks.
http://doodle.com/ex3drz8xt4cc7m9r
H Anthony Chan
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
The timezone in the doodle is US central time. I tried to enter 8am and 9am in
US Central time, but I am not sure whether you can change the time zone to view
it.
H Anthony Chan
From: Templin, Fred L [mailto:fred.l.temp...@boeing.com]
Sent: Thursday, April 02, 2015 4:57 PM
To: h chan
Subject
I was asked to provide more explanation about anchoring.
Distributed mobility management may have anchoring functionality in different
networks so that routes do not need to traverse a centralized anchor.
Yet, the definition of anchoring function (AF) in RFC 7333 is in terms of
route
Please check your availability for next teleconference presentation. Thanks.
http://doodle.com/vtdezsuh3ifw48awnmdzhdw3/admin#table
H Anthony Chan
From: h chan
Sent: Monday, December 15, 2014 11:28 AM
To: dmm@ietf.org
Subject: RE: [DMM] enhanced mobility anchor teleconference
There are two
The suggested time for the next teleconference is Nov 26 or Dec 1, 2
Please vote at:
http://doodle.com/k3reqg8d7v3n8geb
H Anthony Chan
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent: Sunday, October 19, 2014 4:56 PM
To: dmm@ietf.org
Subject: [DMM] enhanced anchor description
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
Pentikousis, Anthony Chan
Anthony (AC): Introduction: Different DMM solutions are using anchors. They are
using different names
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
=6467463029#C2
Access Code:
8774651
Suggested discussion: look at the similarities/differences in different
proposed DMM solutions on what the anchor does and how the anchor is being used.
H Anthony Chan
-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent
-Original Message-
From: Alper Yegin [mailto:alper.ye...@yegin.org]
Sent: Thursday, July 03, 2014 3:38 PM
To: h chan
Cc: pierrick.se...@orange.com; Jouni Korhonen; Charlie Perkins; dmm@ietf.org;
dmm-cha...@tools.ietf.org
Subject: Re: [DMM] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04
I also like to try more generic wording. How about the following:
2. Internetwork Location Information (LI) function: managing and
keeping track of the internetwork location of an MN. The
location information may be a binding of the IP advertised
address/prefix (e.g.,
I see 2 sessions in the agenda.
H Anthony Chan
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alper Yegin
Sent: Monday, June 23, 2014 2:26 PM
To: dmm@ietf.org
Subject: [DMM] Fwd: IETF 90 Preliminary Agenda
How are we going to make progress on solution discussions when all we have is a
Alex,
Thanks for spelling out the conditions more accurately. Just to confirm whether
the addition the text in red as in the following is needed for accuracy reasons.
May I ask whether we can alternatively assume that ingress filtering should
always not be prevented. Then when the red text
-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
Sent: Friday, January 31, 2014 5:43 AM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Le 30/01/2014 20:53, h chan a écrit :
Alex,
I think the applications which work without
or prefix.
H Anthony Chan
-Original Message-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
Sent: Thursday, January 30, 2014 11:39 AM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Le 30/01/2014 18:08, h chan a écrit :
Alex
Anthony Chan
-Original Message-
From: Brian Haberman [mailto:br...@innovationslab.net]
Sent: Wednesday, January 29, 2014 8:26 AM
To: h chan; Alexandru Petrescu; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Anthony,
Does this requirement also include a way
, possibly operated as separate administrative
domains, when allowed by the trust relationship between them.
H Anthony Chan
-Original Message-
From: Brian Haberman [mailto:br...@innovationslab.net]
Sent: Wednesday, January 29, 2014 8:01 AM
To: h chan; draft-ietf-dmm-requireme
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Le 28/01/2014 23:33, h chan a écrit :
Let us try to include MR.
How about the following
REQ2: Network-layer mobility support when needed
DMM solutions MUST enable network-layer
Regarding the following:
- Should PS7 mention mobility solutions that operated at other layers of the
protocol stack?
Original
PS7: Deployment with multiple mobility solutions
There are already many variants and extensions of MIP.
Deployment of new mobility
-
From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com]
Sent: Tuesday, January 28, 2014 1:27 PM
To: h chan; dmm@ietf.org
Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Le 28/01/2014 19:58, h chan a écrit :
Let me try to understand the concern here.
What is new
Are there any more comments on the requirements draft? Is this latest draft
okay?
H Anthony Chan
-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Friday, December 21, 2012 5:10 PM
To: i-d-annou...@ietf.org
Cc:
the previous IP address; the new application sessions that
started after the MN has moved to the new network can use the new IP address.
H Anthony Chan
-Original Message-
From: Ahmad Muhanna [mailto:amuha...@awardsolutions.com]
Sent: Friday, December 21, 2012 10:13 AM
To: h chan; Jouni
Revised paragraph in Introduction:
Mobile users are, more than ever, consuming Internet content; such
traffic imposes new requirements on mobile core networks for data
traffic delivery. The presence of content providers closer to the
mobile/fixed Internet Service Providers network
Revised paragraph in Section 3.2:
Mobility management may be partially or fully distributed. In the
former case only the data plane is distributed. Fully distributed
mobility management implies that both the data plane and the control
plane are distributed. These different
Revised PS2:
PS2: Divergence from other evolutionary trends in network
architectures such as distribution of content delivery.
Centralized mobility management can become non-optimal with a
flat network architecture.
H Anthony Chan
-Original Message-
Revised PS3：
PS3: Low scalability of centralized tunnel management and mobility
context maintenance
Setting up tunnels through a central anchor and maintaining
mobility context for each MN therein requires more resources in
a centralized design, thus
Revised REQ4:
REQ4: Existing mobility protocols
A DMM solution SHOULD first consider reusing and extending
IETF-standardized protocols before specifying new protocols.
H Anthony Chan
-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On
Ahmad,
The mobile nodes are running network applications (IP sessions).
Mobility can be thought of as being provided to the mobile nodes. Alternatively
it can be thought of as being provided to the applications. I think the
difference is shown in the following:
IP mobility support is not
and/or transmitted) using
multiple endpoints.
In other words, compatibility with multicast distribution scenario doesn't
necessarily avoid PS1 and PS6.
Thank you and best regards,
Sérgio
On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing
How about changing PS3 to the following:
Low scalability of centralized tunnel and mobility context maintenance
Setting up tunnels through a central anchor which maintains the mobility
context for each MN therein requires more resources at the centralized anchor,
thus reducing scalability.
to be managed (e.g., subscribed, received and/or transmitted) using
multiple endpoints.
In other words, compatibility with multicast distribution scenario doesn't
necessarily avoid PS1 and PS6.
Thank you and best regards,
Sérgio
On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast
I have clarified the section on compatibility in the 06 version. Please check.
H Anthony Chan
From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Tuesday, October 30, 2012 5:47 AM
To: h chan
Cc: dmm@ietf.org
Subject: 答复: RE: [DMM] Some comments on
draft-chan-dmm-framework-gap-analysis-05
Please check this updated REQ1 in draft-ietf-dmm-requirements-02:
REQ2: Transparency to Upper Layers when needed
DMM solutions MUST provide transparent mobility support above
the IP layer when needed. Such transparency is needed, for
example, when, upon change
]
Sent: Thursday, June 07, 2012 8:21 PM
To: h chan
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: 答复: RE: Re: [DMM] draft requirement REQ-4: compatibility
Hi Antony,
Yes, I agree, the DMM solution shall be compatibile with the exsiting network
deployments. But only say
not support the dmm enabling protocol.
Motivation: The motivation of this requirement is to allow inter-domain
operation if desired and to preserve backwards compatibility so that the
existing networks and hosts are not affected and do not break.
H Anthony Chan
From: h chan
Sent: Thursday, June
Anthony Chan
From: luo@zte.com.cn [mailto:luo@zte.com.cn]
Sent: Wednesday, June 06, 2012 12:56 AM
To: h chan
Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter McCann
Subject: 答复: Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers
Hi Anthony:
The last part
-Hyouk Lee [mailto:jonghy...@gmail.com]
Sent: Friday, May 18, 2012 7:09 AM
To: jouni korhonen
Cc: h chan; dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-6: authentication and authorization
Jouni,
This requirement is for access network security between a mobile node and an
access router
NOT break.
H Anthony Chan
-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of h chan
Sent: Wednesday, May 23, 2012 8:02 PM
To: Peter McCann; jouni korhonen
Cc: dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-4: compatibility
An attempt to clean up
anchors in the requirement.
H Anthony Chan
-Original Message-
From: jouni korhonen [mailto:jouni.nos...@gmail.com]
Sent: Thursday, May 17, 2012 6:46 PM
To: h chan
Cc: dmm@ietf.org
Subject: Re: [DMM] draft requirement REQ-1: Distributed deployment
Breaking the silence..
On May 7, 2012, at 8
REQ3: IPv6 deployment
The DMM solutions SHOULD target IPv6 as primary deployment and SHOULD NOT be
tailored specifically to support IPv4, in particular in situations where
private IPv4 addresses and/or NATs are used.
REQ-3M (Motivation for REQ-3):
The motivation for this requirement is to be
56 matches
Mail list logo
