Re: [DMM] Distributed Mobility Anchoring - Draft Review Request
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Mon, 13 November 2017 15:49 UTC
Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96EE1200F1 for <dmm@ietfa.amsl.com>; Mon, 13 Nov 2017 07:49:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com
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 zxZC-oYX6EP2 for <dmm@ietfa.amsl.com>; Mon, 13 Nov 2017 07:49:27 -0800 (PST)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6071200FC for <dmm@ietf.org>; Mon, 13 Nov 2017 07:49:27 -0800 (PST)
Received: by mail-pg0-x233.google.com with SMTP id j16so7415500pgn.9 for <dmm@ietf.org>; Mon, 13 Nov 2017 07:49:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :organization:mime-version:content-transfer-encoding; bh=RHcVlkHQiOK7KRqO9nc++Ejs/0KwbZPE/XjO9h573oI=; b=G9d0if3M15K3/ZHZ2QXCumpz6Zq/W1Gfgzq5w/bezRsQ8GiAdi1djI7B4Q58AVC4JT kxcoWgcE1byyrbSAVNcw3kQ9t2wsBPPQUn5qO4MHVL7zNRL/4BlJCCKICE2OItD34+r6 MaO7Jld37pGAdkfdDeEIPBgR3iyIbO9cpf5YV6AGkFWOPUWO8J3Q/x77AtFg4AHGnvIv vMYs5Bq7xGjXtyrsmVjg4lYrwUdbMDnMdynUp0A9AacZs7yIuO6L4uabfIpX9C/+LFDY iqredBkzV6M5UfI8Y9EL2f+HhxBLUGSPz50zE+3ii99ZtfXJ3TBtTUp7Prt0wEMlkPpG pqyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:organization:mime-version :content-transfer-encoding; bh=RHcVlkHQiOK7KRqO9nc++Ejs/0KwbZPE/XjO9h573oI=; b=jYhJnANnXeHFlDhVC25UqnbEnn8hgGqFIHNS++ii9VhT5Nnj03KOusGq/TPXh6I9t2 JZRwz3+hCiKZ9Cd9BU4/Xhv9Xi9bMLuvLOMrck7IX1Kgqboocv5HReSe47aO5R29MsJF qzVwVGfBUfyEs8NOXkrAFHKPjW97GTVpkMalwwZxdvu8gv8M8zPzFGacNyfuW/20P0J2 IhapUKcrg5LNm8ps1hEG2j06vDMxugUGdyaGPgu/bDvB2Xw051mwOnNAld9iHxrVeTYF e3/XfOnw5p9w3xxFFPsoHy60ysCoxlWZMXR4x2Bf/dbrVCgDVntONtSGj++AyI6PEK8t FUVw==
X-Gm-Message-State: AJaThX7iKckTLKi8O6u2nfRL8ZaoWRgC7K7eEuczYAb11pzyigHDzQBH +vlfB3tkRYqGYsw4UzFkDvbYgwc1
X-Google-Smtp-Source: AGs4zMYCxD3eMppAWZ8R9DVOe8X3gSMC+Gb1EseE5QP7urq+b3WeqPzPQfkW92L+7K/a4dBDG+4JzQ==
X-Received: by 10.84.236.70 with SMTP id h6mr9166163pln.166.1510588166833; Mon, 13 Nov 2017 07:49:26 -0800 (PST)
Received: from acorde ([2001:67c:1232:144:1002:c770:86fb:34ec]) by smtp.gmail.com with ESMTPSA id u9sm38724027pfa.40.2017.11.13.07.49.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 13 Nov 2017 07:49:26 -0800 (PST)
Message-ID: <1510588163.3804.16.camel@it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
Reply-To: cjbc@it.uc3m.es
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, "Dirk.von-Hugo@telekom.de" <Dirk.von-Hugo@telekom.de>, "dmm@ietf.org" <dmm@ietf.org>
Date: Mon, 13 Nov 2017 16:49:23 +0100
In-Reply-To: <D621E85B.294AC7%sgundave@cisco.com>
References: <D621E85B.294AC7%sgundave@cisco.com>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.1-1
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/H-WYz5lPu8jyRZ4NjJEC3EuMuU0>
Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review Request
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Nov 2017 15:49:32 -0000
Hi, I've reviewed -07 and I think all the comments I made to -05 have been address to a level good enough to make the document progress. I haven't been able to do a full review, but looking at the diff from -05 to -06 it seems OK to me. Apologies for the belated reply. Thanks, Carlos On Fri, 2017-11-03 at 16:36 +0000, Sri Gundavelli (sgundave) wrote: > Thank you Dirk. > > Folks – Please review and comment. We want to close the FPC and the > other three WG drafts in the next month or so. They are long over > due; now decision time for “close” or “kill”. > > Please review and comment. We want to close this work and shift the > focus to more interesting topics such as SRv6 for mobile user plane > ..etc. > > Sri > > > > From: dmm <dmm-bounces@ietf.org> on behalf of "Dirk.von-Hugo@telekom. > de" <Dirk.von-Hugo@telekom.de> > Date: Friday, November 3, 2017 at 8:32 AM > To: "dmm@ietf.org" <dmm@ietf.org> > Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review > Request > > Dear all, > my comments from review on v03 of the draft have all been considered > in v06 (and maybe before). Still very few and minor nits detected as > follows: > with with => with (p.4) > Figures 2 => Figure 2 (p.10) > Figures 3 => Figure 3 (p.10/p.11) > if these packets ever reaches any of them => if these packets ever > reach any of them (p.27) > a MR => an MR (p.11/p.39/p.40) > are no MNN => are no MNNs (p.40, twice) > Beside that I am fine with moving the draft to WGLC! > Thanks a lot to the authors! > Best Regards > Dirk > From: h chan [mailto:h.anthony.chan@huawei.com] > Sent: Montag, 30. Oktober 2017 22:48 > To: von Hugo, Dirk <Dirk.von-Hugo@telekom.de> > Subject: RE: Distributed Mobility Anchoring - Draft Review Request > > Dirk > In the last meeting, the chair asks whether the reviewers are > satisfied with the revised version – whether your comments have been > satisfactorily addressed or whether more corrections are needed. > This is needed before the draft may go to WGLC. > Please reply to the dmm mailing list. Thank you. > H. Anthony Chan > > From: h chan > Sent: Tuesday, May 09, 2017 11:57 PM > To: 'pierrick.seite@orange.com' <pierrick.seite@orange.com>; Dirk.von > -Hugo@telekom.de; sgundave@cisco.com; dmm@ietf.org > Subject: RE: Distributed Mobility Anchoring - Draft Review Request > > 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 > readability without this sentence IMHO) > “ Distributed mobility management solutions do not > rely on a centrally deployed mobility anchor in the data plane > [Paper-Distributed.Mobility]. “ > Thanks and it is now removed in version 05 > “network slice“ is a typical 5G wording and not well defined from > the IETF perspective (AFAIK) . This wording may lead to > interpretation, I’d suggest to not use it in this document. > Added reference to draft-geng-netslices-architecture in version 05, > so that the meaning of network slice is no longer ambiguous. > Maybe a reference would be needed here (later in the document > (terminology), location management is stated to be a control > function. But, separate LM from forwading management is not yet a > current practices in mobile networks): “In general, control plane > functions may be separate from data plane functions and be > centralized but may also be co-located with the data plane functions > at the distributed anchors” > > Still working on it. > Does it help to reference the gap analysis RFC7429? We already made > the statement about separating out LM as a control function in > RFC7429. > > How about changing “In general, …” to the following in version 06? > Control plane functions may or may not be separate from data plane > functions. In distributed mobility environment, data plane functions > are distributed but the control plane functions may be centralized > when they are separate. Else they may co-locate at the distributed > anchors. > > Page 11: > > s/ MN is allocated an IP prefix/address IP1 which is anchored to the > DPA with the IP prefix/address IPa1./ An IP prefix/address IP1, > anchored to the DPA with the IP prefix/address IPa1, is allocated to > MN./ > > or > > MN is provisioned with an IP prefix/address IP1, which is anchored to > the DPA with the IP prefix/address IPa1. > > By the way, there are many “MN is allocated an IP prefix/address” > which sounds odd to me (but I’m French, so… J). I’d write either “an > IP prefix/address is allocated to the MN” or “MN is provisioned with > an IP prefix/address” > > Thanks, and I also realize that a more proper word is “assign” the > IPv6 prefix. Changed to the following in version 05: > An IP prefix/address IP1, which is anchored to the DPA with the IP > prefix/address IPa1, is assigned for use by an MN. > > Page 12: > > s/ The flow of this communication session is shown as flow(IP1, ...) > which uses IP1 and other parameters./ The flow of this communication > session is shown as flow(IP1, ...), meaning that it uses IP1 and > other parameters./ > > Thanks and it is corrected in version 05 > > page 15: > > > s/A mobile network node (MNN) in the mobile network is allocated > an IP prefix/address IPn1 which is anchored to the MR with the IP > prefix/address IP1./ A mobile network node (MNN) in the mobile > network is allocated an IP > prefix/address IPn1, which is anchored to the MR with the IP > prefix/address IP1./ > > I think that a comma before “which” gives better readability (this > comment applies to the rest of the document) > > Changed in version 05 to: An IP prefix/address IPn1 anchored to the > MR is assigned for use by the MNN in the mobile network. > > s/ The operations of distributed mobility anchoring are defined in > order that they may work together in expected manners to produce a > distributed mobility solution./ The operations of distributed > mobility anchoring are defined in order > that they may (might?) work together to produce a distributed > mobility solution./ > > Thanks, and the change is made in version 05. > > page 18: > > s/The parameters indicated above are only the minimal./ The list > above only gives the minimal set of parameters required./ > > Thanks, and the change is made in version 05. > > page 21: > > the sentence below is hard to parse… I’d suggest to reword it. > > With forwarding table updates, changes to the forwarding table are > needed at each of the affected forwarding switches > in order to change the forwarding path of the packets for the flow > from that originally between the CN and the home > network anchor or previous AR to that between the CN and the new AR. > > Changed in the version 05 to: The objective of forwarding table > updates is to change the forwarding path so that the packets in the > flow will be forwarded from the CN to the new AR instead of the home > network anchor or previous AR. Each of the affected forwarding > switches will need appropriate changes to its forwarding table. > > Page 29: > > A network or network slice may not need IP mobility support. For > example, a network slice for stationary sensors only will never > encounter mobility. > > More generally, when applications can handle IP address change, we > don’t need mobility support => I’d add something on mobility > management at the application level. > > Still working on it. How does the following sound: > A network or network slice may not need IP mobility support. Mobility > support can be provided at the transport layer or the application > layer, or it may not be needed at all as in the case of a network > slice for stationary sensors only. > > > Page 42: > > ---------- OLD TEXT ----------- > The appropriate IPv6 nodes (CPA, DPA) are to be implemented > the mobility functions LM and FM as described > respectively > in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. > > ---------- NEW TEXT ---------- > The appropriate IPv6 nodes (CPA, DPA) have to implement > the mobility functions LM and FM as described > respectively > in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. > > Thanks and the change is made in version 05. > > H. Anthony Chan > > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of pierrick.seite@o > range.com > Sent: Tuesday, May 02, 2017 8:57 AM > To: Dirk.von-Hugo@telekom.de; sgundave@cisco.com; dmm@ietf.org > Subject: Re: [DMM] Distributed Mobility Anchoring - Draft Review > Request > > Hi all, > > Sorry for the late reply… I have read this document and, like other > reviewers, I think it is in good shape. Actually, I do not have much > to add to Dirk’s review, just few editorial details below. > > Thanks for authors for this hard work. > Regards, > Pierrick > > ---- my comments --------- > Introduction: > > Following sentence can be removed (no real added value and better > readability without this sentence IMHO) > “ Distributed mobility management solutions do not > rely on a centrally deployed mobility anchor in the data plane > [Paper-Distributed.Mobility]. “ > > “network slice“ is a typical 5G wording and not well defined from > the IETF perspective (AFAIK) . This wording may lead to > interpretation, I’d suggest to not use it in this document. > > Maybe a reference would be needed here (later in the document > (terminology), location management is stated to be a control > function. But, separate LM from forwading management is not yet a > current practices in mobile networks): “In general, control plane > functions may be separate from data plane functions and be > centralized but may also be co-located with the data plane functions > at the distributed anchors” > > Page 11: > > s/ MN is allocated an IP prefix/address IP1 which is anchored to the > DPA with the IP prefix/address IPa1./ An IP prefix/address IP1, > anchored to the DPA with the IP prefix/address IPa1, is allocated to > MN./ > > or > > MN is provisioned with an IP prefix/address IP1, which is anchored to > the DPA with the IP prefix/address IPa1. > > By the way, there are many “MN is allocated an IP prefix/address” > which sounds odd to me (but I’m French, so… J). I’d write either “an > IP prefix/address is allocated to the MN” or “MN is provisioned with > an IP prefix/address” > > Page 12: > > s/ The flow of this communication session is shown as flow(IP1, ...) > which uses IP1 and other parameters./ The flow of this communication > session is shown as flow(IP1, ...), meaning that it uses IP1 and > other parameters./ > > page 15: > > > s/A mobile network node (MNN) in the mobile network is allocated > an IP prefix/address IPn1 which is anchored to the MR with the IP > prefix/address IP1./ A mobile network node (MNN) in the mobile > network is allocated an IP > prefix/address IPn1, which is anchored to the MR with the IP > prefix/address IP1./ > > I think that a comma before “which” gives better readability (this > comment applies to the rest of the document) > > s/ The operations of distributed mobility anchoring are defined in > order that they may work together in expected manners to produce a > distributed mobility solution./ The operations of distributed > mobility anchoring are defined in order > that they may (might?) work together to produce a distributed > mobility solution./ > > page 18: > > s/The parameters indicated above are only the minimal./ The list > above only gives the minimal set of parameters required./ > > > page 21: > > the sentence below is hard to parse… I’d suggest to reword it. > > With forwarding table updates, changes to the forwarding table are > needed at each of the affected forwarding switches > in order to change the forwarding path of the packets for the flow > from that originally between the CN and the home > network anchor or previous AR to that between the CN and the new AR. > > Page 29: > > A network or network slice may not need IP mobility support. For > example, a network slice for stationary sensors only will never > encounter mobility. > > More generally, when applications can handle IP address change, we > don’t need mobility support => I’d add something on mobility > management at the application level. > > > Page 42: > > ---------- OLD TEXT ----------- > The appropriate IPv6 nodes (CPA, DPA) are to be implemented > the mobility functions LM and FM as described > respectively > in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. > > ---------- NEW TEXT ---------- > The appropriate IPv6 nodes (CPA, DPA) have to implement > the mobility functions LM and FM as described > respectively > in LM-cfg:3 or LM-cfg:4 and FM-cfg:2 in Section 3.2. > > > > De : dmm [mailto:dmm-bounces@ietf.org] De la part de Dirk.von-Hugo@te > lekom.de > Envoyé : mardi 11 avril 2017 14:03 > À : sgundave@cisco.com; dmm@ietf.org > Objet : Re: [DMM] Distributed Mobility Anchoring - Draft Review > Request > > Dear all, > referring to the ‘Any other …’ sentence and considering myself as > semi-expert, I post feedback of my review below (mainly detected nits > and proposed clarifications for ease of understanding) > ;-) > Overall the content IMO is in good shape and right degree of detail. > Thanks to all authors and contributors! I wonder whether the security > section could be a little bit extended e.g. with reference to > security considerations in requirements RFC 7333 or deployment draft > [I-D.ietf-dmm-deployment-models]. > Thanks a lot! > Best Regards > Dirk > > Sometimes text refers to ‘the IP’ only instead of ‘the IP address (or > also ‘/ prefix’?)’ – for me it would increase understandability so I > recommend e.g. on > p.4: > so that the IP no longer belongs => so that the IP address no longer > belongs [similarly also on p.28, Figure 6 and on p.31, Figure 7] > mix of flows requiring and not requiring IP mobility support => mix > of flows both requiring and not requiring IP mobility support [also > on p.29, 32, 34, 38 …] > > p.5: > Section 5.3.1 Mobility => Section 5.3.1. Mobility > described in Section 5.4.1 => described in Section 5.4.1. > binding of the IP advertised address/prefix => binding of the > advertised IP address/prefix [?] > > the CPA co-locates => the CPA is co-located (also p.10/11/12/14) [?] > > p.15: > solution may exhibit the operations as needed. => solution may > exhibit only those operations needed. [?] > > p.21: > central plane possessing => control plane possessing > > p.23: (2*) > using the appropirate => using the appropriate > p.24: > where the original path and the direct IPv6 path overlaps.=> where > the original path and the direct IPv6 path overlap. > > p.25: > to reduce unnecessarily long path. => to reduce unnecessarily long > paths. > p.26: > MNNs in the network carried by the MR obtains IP prefixes => MNNs in > the network carried by the MR obtain IP prefixes > MNNs moves with the MR. => MNNs move with the MR. > other affected switch/routers => other affected switches/routers > (2*) > > p.29: > need IP mobility support. It is necessary to => need IP mobility > support it is necessary to > when the application was => when the application is > p.32: > The appropriate IPv6 nodes (CPA, DPA, CPN, DPN) are to be implemented > the mobility functions … => At the appropriate IPv6 nodes (CPA, DPA, > CPN, DPN) the mobility functions … have to be implemented [I would > say] > other affected routers => other affected switches/routers [right? 2*] > if these packets ever reaches any of them, the they will not traverse > towards AR1 but will traverse towards AR2. Section 3.2.2. > => if these packets ever reach any of them, they will not traverse > towards AR1 but will traverse towards AR2 (see Section 3.2.2). > p.33: > Such are described in the FM operations => Such procedures are > described by the FM operations > p.34: > In Figure 8: > At Net1 / AR1 / CPA: > |LM:IP1<-->IPa2 | => |LM:IP1<-->IPa1 | [!?] > p.36: > Figure 9. IP prefix/address anchor switching to the new network with > with the LM => Figure 9. IP prefix/address anchor switching to the > new network with the LM > > p.38: > The AR2 may now send RA to AR2, => The AR2 may now send RA to MN, > > p.39: > that the new anchor is ready => that the new anchor is ready. > > p.41: > above multiple FWs => above multiple FW’s [to be consistent] > Figure 2(b)in Section => Figure 2(b) in Section > > p.42: > parameters described in Section 3.2.1 provides => parameters > described in Section 3.2.1 provide > > p.44: > Section 5.3.1 apply here. => Section 5.3.1 applies here. [only one > configuration guideline (GL-cfg) in that section] > to which a MNN is => to which an MNN is > while the MNN is attached to and therefore => while the MNN is > attached to MR and therefore/ while the MNN is attached to it and > therefore > > p.45: > which a MNN is attached. => which an MNN is attached. > > p.46: > there are no MNN attaching to the MR. Here there are also no MNN => > there is no MNN attaching to the MR. Here there is also no MNN / > there are no MNNs attaching to the MR. Here there are also no MNNs > > p.47: > so that such packets ever reaches any of them, the packet will not => > so that in case such packets ever reach any of them, the packets will > not > The security considerations are already described in different > sessions => The security considerations are already described in > different sections > These work have been referenced. => These works have been referenced. > / This work has been referenced. > > > > From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Sri Gundavelli > (sgundave) > Sent: Mittwoch, 5. April 2017 17:15 > To: dmm > Subject: [DMM] Distributed Mobility Anchoring - Draft Review Request > > Hi Marco, Carlos, Seil & Biju, > > I believe you have all kindly agreed to review the below draft and > post your feedback to the list. Will be great if you can do that in > the next 2 weeks (COB: 19th of April, 2017). > > We want to wrap up this work soon, but want to make sure the draft is > technically correct. Editorial issues can be fixed, but minimally > the draft should be technically correct and we want to hear that from > the group. > > https://tools.ietf.org/html/draft-ietf-dmm-distributed-mobility-anch > oring-03 > > Any other experts, please review and post your feedback. > > Anthony – Please work with the reviewers. > > > > ——————- > > 10:00 Title: Distributed Mobility Anchoring > Presenter: H Anthony Chan > Time: 10 minutes > Draft: https://tools.ietf.org/html/draft-ietf-dmm-distrib > uted-mobility-anchoring-03 > > > Anthony summarizes update. > Comment from Alex about nemo missed. > Different modes, move to new network and keep/give up old IP address. > Rest of work for WG to review and comment. > > Sri: we need good reviews on this document. Editorial but also > technically. > > Volunteers: Reviews: Marco, Carlos, Seil > > > ——————- > _____________________________________________________________________ > ____________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous > avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender > and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm
- Re: [DMM] Distributed Mobility Anchoring - Draft … Dirk.von-Hugo
- Re: [DMM] Distributed Mobility Anchoring - Draft … Sri Gundavelli (sgundave)
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … Byju Pularikkal (byjupg)
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- [DMM] Distributed Mobility Anchoring - Draft Revi… Sri Gundavelli (sgundave)
- Re: [DMM] Distributed Mobility Anchoring - Draft … Seil Jeon
- Re: [DMM] Distributed Mobility Anchoring - Draft … Carlos Jesús Bernardos Cano
- Re: [DMM] Distributed Mobility Anchoring - Draft … Marco Liebsch
- Re: [DMM] Distributed Mobility Anchoring - Draft … Byju Pularikkal (byjupg)
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … pierrick.seite
- Re: [DMM] Distributed Mobility Anchoring - Draft … Sri Gundavelli (sgundave)
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … Byju Pularikkal (byjupg)
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … Carlos Jesús Bernardos Cano
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … Carlos Jesús Bernardos Cano
- Re: [DMM] Distributed Mobility Anchoring - Draft … Sri Gundavelli (sgundave)
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … Dirk.von-Hugo
- Re: [DMM] Distributed Mobility Anchoring - Draft … Sri Gundavelli (sgundave)
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan
- Re: [DMM] Distributed Mobility Anchoring - Draft … Carlos Jesús Bernardos Cano
- Re: [DMM] Distributed Mobility Anchoring - Draft … h chan