Re: [DMM] Call for WG Adoption of a current practices and gap analysis document

I've reviewed both the documents and here is my feedback. 1. Both the documents are well written and many points are valid and equally many points are also debatable, but is not a blocker for the draft adoption. 3. Given the efforts put in by the Authors of both the documents, I'd hate to pick

Re: [DMM] Call for WG Adoption of a current practices and gap analysis document

Hi Dirk, I agree. It will take some efforts to do the content merge. Regards Sri On 1/14/13 6:12 AM, dirk.von-h...@telekom.de dirk.von-h...@telekom.de wrote: Hi Sri and all, Although it's too late (sorry for that) I agree with you and others who commented similarly that it's impossible (for

Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Distributed solution: Take IP traffic directly from access router to the Internet. Counter argument. It implies, LI, Charging, DPI Šetc on each of the distributed nodes. Implies more CAPEX and OPEX ? I'm not against distributed models and 6909 is the proof point. But, IMO, it will hard

Re: [DMM] Preparing for DMM future steps and rechartering

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

Re: [DMM] Preparing for DMM future steps and rechartering

Hi Marco, My intention is not to eliminate a tunnel that exists in any of the tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes topological anchor point for the MN's IP address(es). Forget about the C-plane for now. Tunnels apply solely below (well,

Re: [DMM] Preparing for DMM future steps and rechartering

Gundavelli (sgundave) wrote: Hi Marco, My intention is not to eliminate a tunnel that exists in any of the tunnel management protocols (aka MIP6, PMIP6, ..). My picture of DMM primarily distributes topological anchor point for the MN's IP address(es). Forget about the C-plane for now. Tunnels

Re: [DMM] Preparing for DMM future steps and rechartering

Hi Marco, On 11/15/13 1:56 AM, Marco Liebsch marco.lieb...@neclab.eu wrote: Depends. I assume that the session you describe is a mobility session (binding ID-Locator), not a data session. If the mobility session remains anchored at the previous attachment point, there will be a tunnel towards

Re: [DMM] Preparing for DMM future steps and rechartering

Hi Pete, On 11/15/13 12:13 PM, Peter McCann peter.mcc...@huawei.com wrote: There can be (but does not have to be) a centralized control plane element that has a global view of all the MNs currently attached and keeps track of which MAG they are currently on. From the point of view of DMM,

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

Anthony, Thanks for the updates. Regards Sri From: h chan h.anthony.c...@huawei.commailto:h.anthony.c...@huawei.com Date: Tuesday, November 19, 2013 6:11 PM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com, dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject:

Re: [DMM] re-charter text updated

On 3/17/14 7:20 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: Folks, Triggered by the question from Behcet, we should come up with the milestones. Few proposals: o The deployment models and scenarios I-D is obvious. o Anchor selection I-D is obvious. Could we also bundle the re-anchoring

Re: [DMM] re-charter text updated

On 3/20/14 5:54 AM, Peter McCann peter.mcc...@huawei.com wrote: I think our extensions should be to the prefix information option and not DHCP. The properties of an address may change after a handover and we should not couple the DHCP state machine (which is about lease renewal) to the

Re: [DMM] re-charter text updated

Gundavelli (sgundave) wrote: On 3/20/14 5:54 AM, Peter McCann peter.mcc...@huawei.com wrote: I think our extensions should be to the prefix information option and not DHCP. The properties of an address may change after a handover and we should not couple the DHCP state machine (which

Re: [DMM] rechartering draft comments

On 3/27/14 2:26 PM, Jouni Korhonen jouni.nos...@gmail.com wrote: You know that it just happens to be the only RFC even attempting to explain how LMAs are selected dynamically. If the reference here is contentious, I am happy to remore it.. just give me alternative text. I agree. RFC6097 and

Re: [DMM] draft charter text updates in github..

Agree. We should ensure the base solution supports IPv6 transport and user sessions. Optionally, support for IPv4 can be allowed on certain interfaces, but clearly should not deal with IPv4, NAT's or allow IPv4-only solutions. Regards Sri On 6/18/14 8:43 AM, Brian Haberman

Re: [DMM] draft charter text updates in github..

. Regards Sri On 6/19/14 11:30 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Thursday, June 19, 2014 11:20 AM To: Brian Haberman; dmm@ietf.org Subject: Re: [DMM

Re: [DMM] draft charter text updates in github..

:34 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, June 19, 2014 1:32 PM To: Templin, Fred L; Brian Haberman; dmm@ietf.org Subject: Re: [DMM] draft charter text updates

Re: [DMM] demand for DMM traffic steering

Hi Marco, I think we may have to qualify the term anchor. In our conf calls we used the terms, Control Plane Anchor (CPA), Data Plane Anchor (DPA) with Home/Access prefix tags. At the start of a session, the selected anchor assigns a topologically correct address. The HoA/HNP for a mobile

Re: [DMM] demand for DMM traffic steering

steering Hi Sri, Thanks for your prompt response. please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Freitag, 11. Juli 2014 19:46 To: Marco Liebsch; dmm@ietf.orgmailto:dmm@ietf.org Subject: Re: [DMM] demand for DMM traffic steering Hi Marco, I think we may have

Re: [DMM] demand for DMM traffic steering

Alper – That can be fixed. Sri From: Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Date: Saturday, July 12, 2014 12:36 AM To: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Cc: Marco Liebsch marco.lieb...@neclab.eumailto:marco.lieb...@neclab.eu,

Re: [DMM] demand for DMM traffic steering

Ryuji, We need to capture this discussion. Goal for next week is for all to agree on few things and write-up some text right there Š. Regards Sri On 7/16/14 12:03 AM, Ryuji Wakikawa ryuji.wakik...@gmail.com wrote: Sri and all I didn¹t capture all the discussion, but I agree with your

[DMM] Offloading traffic in Access DPA

(Changing the subject line). Does your model consider offloading traffic at the Access DPA? Yes. Multiple approaches. - Approach of allocating a local session after each L3 handover. The traffic associated will that new sessions always be offloaded from that DPA, which is also the Home DPA

Re: [DMM] demand for DMM traffic steering

...@sprint.commailto:brent.hirsch...@sprint.com, Alper Yegin alper.ye...@yegin.orgmailto:alper.ye...@yegin.org Cc: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Sri, please see inline. From: Sri Gundavelli (sgundave) [mailto:sgund

Re: [DMM] WG adoption (was Re: DMM solution space)

I'm in favor of this approach. This was my suggestion as well in the past (when we presented prefix coloring spec) to move forward some documents. But, those should be documents which are considered common across multiple solution approaches. The issue seems to be charter approval. Sri On

Re: [DMM] demand for DMM traffic steering

. But with certain terms there is some expectation of the function behind. We need to be clear about the roles of both, access and home DPA for mobility management and assess their role in driving the different DMM scenarios. marco From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent

Re: [DMM] demand for DMM traffic steering

I do not know your definition of approach vs solution, but one can argue DMM itself is about a deployment model and an approach. I always insisted its less of a protocol work and more about a tying many aspects. So, what we have been discussing is a solution approach which has the essential

Re: [DMM] demand for DMM traffic steering

@ietf.orgmailto:dmm@ietf.org Subject: RE: [DMM] demand for DMM traffic steering Hi, Just to be sure that we are on the same page…. De : dmm [mailto:dmm-boun...@ietf.org] De la part de Sri Gundavelli (sgundave) Envoyé : jeudi 17 juillet 2014 06:37 À : Marco Liebsch; Hirschman, Brent B [CTO]; Alper Yegin Cc : dmm

Re: [DMM] demand for DMM traffic steering

saying this to save us energy. If we read your I-D, we can all see how it meets the requirements. Otherwise, we are going to have to ask about them and have lengthy discussions to understand things). Alper On Jul 17, 2014, at 10:51 PM, Sri Gundavelli (sgundave) wrote: Alper

Re: [DMM] IETF#90 DMM agenda update

Behcet, Check some of the documents in MPLS/Routing areas. DMM to most part is about deployment. Without bringing the deployment aspects, documenting DMM solutions will be immature. Sri On 7/22/14 8:08 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote: Hi Brian, On Tue, Jul 22, 2014 at

Re: [DMM] IETF#90 DMM agenda update

sarikaya2...@gmail.com wrote: Hi Sri, On Tue, Jul 22, 2014 at 10:16 AM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Behcet, Check some of the documents in MPLS/Routing areas. Sorry, I am familiar with those areas, they are not in Intarea :-). DMM to most part is about deployment

Re: [DMM] IETF#90 DMM agenda update

Of pierrick.se...@orange.com Sent: Mittwoch, 23. Juli 2014 10:13 To: sarik...@ieee.org; Sri Gundavelli (sgundave) Cc: dmm@ietf.org Subject: Re: [DMM] IETF#90 DMM agenda update -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Behcet Sarikaya Envoyé : mardi 22

Re: [DMM] 回复： interim call #1 and rechater text

On 9/5/14 3:11 AM, Jouni jouni.nos...@gmail.com wrote: Folks, This mail start a one week period to comment and propose changes to the re-charter text. The call ends 12th Sep. All the material from the Interim call#1 including the latest re-charter text is available at:

Re: [DMM] regarding the re-chartering..

, On 09/09/2014 10:11 AM, Sri Gundavelli (sgundave) wrote: This is bit strange. Some thing changed in the IANA Mobile Node Identifier pages. I assumed the MN Id was defined in RFC4283. How come I see a definition in 5271 as well. Confused. Jouni / Brian ­ Any ideas ? Unless, I've been smoking Š

Re: [DMM] regarding the re-chartering..

Haberman br...@innovationslab.net wrote: Sri, On 9/9/14 2:09 PM, Sri Gundavelli (sgundave) wrote: Hi Suresh, Thanks. That makes sense. Now, I remember that spec/update. The option name conflict and my search not finding 4283 references threw me off. Thanks. If this is *really* confusing

Re: [DMM] regarding the re-chartering..

Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just one sub-type for mac based identifiers ? 2.) Sub type value (1) is currently used. Its currently overloaded for IMSI-NAI (3GPP

Re: [DMM] regarding the re-chartering..

examples and some explanation on how they are used. Sri On 9/9/14 2:20 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Charlie, This is good. Thanks. 1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2 address, why do we need to two sub-types ? Why not have just

Re: [DMM] regarding the re-chartering..

both, node-specific IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI. There may be value in adding the IMEI to the list of possible types of node-specific IDs. marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Dienstag

Re: [DMM] A Day in the Life of an Enterprise Mobile Device User

Hi Fred, On 9/4/14 7:50 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: No, in that VPN is cited in the scenario and VPN+Mobile IP are not working well together. Right - switching between VPN and non-VPN will be important for enterprise network mobile device users. I think Alex is

Re: [DMM] DMM Interim call #2 - agenda forming

, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Fred, IMHO, DMM solution need to be tied to one specific protocol. We don't have to battle this out and come up with one answer. Once we have high-level view of the solution and the interfaces, its possible

Re: [DMM] DMM Interim call #2 - agenda forming

: Wednesday, September 10, 2014 3:15 PM To: Sri Gundavelli (sgundave) Cc: Templin, Fred L; Jouni Korhonen; Dapeng Liu; dmm@ietf.org Subject: Re: [DMM] DMM Interim call #2 - agenda forming Hi Sri, On Wed, Sep 10, 2014 at 5:01 PM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Hi Fred

Re: [DMM] DMM Interim call #2 - agenda forming

Hi Fred, The below comment from you made me thinking. I must admit I'm not much familiar with Aero, have not seen its references in CDMA, WiMAX, CableLabs, WLAN or LTE architectures. But, if it has all the mobility features and you believe this can conclude the WG, I thought I will explore this

Re: [DMM] regarding the re-chartering..

the node or using the ID as key for a lookup, I am wondering if it would not be more appropriate to go for a different container option to carry such information. Something like a complementary identifier option. marco -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund

Re: [DMM] DMM Interim call #2 - agenda forming

is DHCPv6 Regards Sri On 9/11/14 11:00 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, See below for some follow-up: -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, September 11, 2014 12:28 AM To: Templin, Fred

Re: [DMM] MNID Types

to submit the -00.txt document as it is to the Internet Drafts directory, and then to go about making updates according to the discussion on this list. Do you think this is reasonable? Regards, Charlie P. On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote: Changing the subject line

Re: [DMM] DMM Interim call #2 - agenda forming

Hi Fred, Thanks again for your responses. Lets zoom into the following two points. On 9/11/14 4:07 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: 9.) Are you aware of implementation of a Aero client on iPhone ? Can Aero client be implemented in today's Apple iOS device, using

Re: [DMM] A Day in the Life of an Enterprise Mobile Device User

On 9/12/14 2:36 AM, Alexandru Petrescu alexandru.petre...@gmail.com wrote: Sri - I agree that specifications allow certain handovers. I am not sure what do you mean by Mobile VPN? Mobile IP using a MH-HA tunnel with a VPN-style tunnel? A VPN which changes the source address with a new IKE

Re: [DMM] DMM Interim call #2 - agenda forming

Hi Fred, On 9/12/14 8:17 AM, Templin, Fred L fred.l.temp...@boeing.com wrote: Based on these points #3 and #9, can we conclude that we cannot apply AERO for DMM ? If not, how do we apply and deploy Aero for DMM networks ? I don't think so. Surely we can do proxy AERO, and surely iOS phones

Re: [DMM] DMM Interim call #2 - agenda forming

, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Friday, September 12, 2014 7:02 PM To: Templin, Fred L; Jouni Korhonen; sarik...@ieee.org Cc: Dapeng Liu; dmm@ietf.org Subject: Re: [DMM] DMM Interim

Re: [DMM] DMM Interim call #2 - agenda forming

the other. Again, I've my views against using any client-based solutions for RO solutions. Regards Sri On 9/15/14 4:02 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Monday, September

[DMM] Signaling Message Fragmentation

[Discussion under the maintenance scope] With the standardization of all the new mobility options (ANI, QoS, IFOM, MNP..etc) and specially with the NAI/Domain type fields in some of those options, we are almost close to hitting the PBU/BU fragmentation limit. Any thoughts on how to deal with

Re: [DMM] Signaling Message Fragmentation

Hi Fred, inline .. On 9/23/14 4:14 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, -Original Message- From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Tuesday, September 23, 2014 4:06 PM To: Templin, Fred L; dmm@ietf.org Subject: Re: Signaling Message

Re: [DMM] Signaling Message Fragmentation

Hi Fred, On 9/23/14 5:00 PM, Templin, Fred L fred.l.temp...@boeing.com wrote: Hi Sri, I'm not much of a fan of advertised MTU values in RAs and such. It may be OK if your tunnel is point-to-point, but I want good MTU solution for NBMA tunnels where the MTU between neighbors A and B may

Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Hi Pierrick, The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 3GPP TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI information is seen as a confidential IE. But, I agree on the need to include some text on how the signaling message can be protected with privacy /

Re: [DMM] Signaling Message Fragmentation

Hi Fred, I can think of use cases related to my industry, for example when a first airplane provides an access link to a second airplane, the second airplane provides an access link to a third airplane, etc. Seems to match the below use-case. I do not know the Boeing's or the broader

Re: [DMM] MNID Types

. Cheers, Hakima De: Sri Gundavelli (sgundave) sgund...@cisco.commailto:sgund...@cisco.com À: Charles E. Perkins charl...@computer.orgmailto:charl...@computer.org Cc: Vijay Devarapalli dvi...@rocketmail.commailto:dvi...@rocketmail.com, dmm@ietf.orgmailto:dmm

[DMM] Forwarding Path Signaling Management - Work Team Call

:16010101T02 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Sri Gundavelli (sgundave):MAILTO:sgund...@cisco.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Marco Lieb sch:MAILTO:marco.lieb

Re: [DMM] Forwarding Path Signaling Management discussion

Alper, Inline Š On 10/16/14 1:32 AM, Alper Yegin alper.ye...@yegin.org 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 :-)

Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

Charlie – 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 –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

Re: [DMM] Forwarding Path Signaling Management discussion

.Then, this generic interface can be implemented using different protocols (among them is BGP), but this is out of scope of the work item. BR, Pierrick -Message d'origine- De : dmm [mailto:dmm-boun...@ietf.org] De la part de Sri Gundavelli (sgundave) Envoyé : jeudi 16 octobre 2014 10:58 À : Alper Yegin

Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

dmm@ietf.orgmailto: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 (sgundave) sgund...@cisco.commailto:sgund

Re: [DMM] AERO and Mobile IP comparison

+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 sarikaya2...@gmail.com wrote: I think that in dmm maybe we should look into 21st century

[DMM] =?Windows-1252?Q?Re:__RE:_[homenet]_Fwd:_New_Liaison_Statement, __Br?= oadband For um Work on ³Hybrid Access for Broadband Networks² (WT-348)

We probably should not be cross posting the mail to three WG mailers, but I will respond to this one last email Hi Li, 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 comments in the last HOMENET

Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

that be RFC 4283bis? -Hui 2014-10-18 12:55 GMT+08:00 Sri Gundavelli (sgundave) sgund...@cisco.commailto:sgund...@cisco.com: 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

Re: [DMM] offlisted mails - names of Work Teams

Alex - I give up :) Regards Sri On 10/29/14 10:12 AM, Alexandru Petrescu alexandru.petre...@gmail.com wrote: Le 29/10/2014 18:03, Sri Gundavelli (sgundave) a écrit : Alex: The maintenance work does include mobile router based deployments; The work that we did in NETEXT, MEXT, MIP4 comes

Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment

Marco, Should some of this discussion on terminology be part of the other arch/deployment spec ? We should use a consist terminology across all of these 4 documents. I think the discussions we have had early this year on the DMM functional entities, terminology and the deployment models should

Re: [DMM] Data-Plane anchors in a control-/data-plane separated deyploment

IETF 88, IETF 89 and also couple of conf calls early this year. Regards Sri On 12/18/14 9:28 AM, Behcet Sarikaya sarikaya2...@gmail.com wrote: On Thu, Dec 18, 2014 at 11:10 AM, Sri Gundavelli (sgundave) sgund...@cisco.com wrote: Marco, Should some of this discussion on terminology be part

Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01

I support the adoption of this draft as a WG document; There was good amount of discussion on supporting RFID related identifiers. We need to make sure all of those comments will be addressed in the subsequent revisions. Sri On 4/1/15, 8:02 AM, Jouni Korhonen jouni.nos...@gmail.com wrote:

Re: [DMM] WT#4 - Conf Call Timing Poll

So, far I’ve received two presentation slot requests. I plan to close the poll Monday and confirm the dates. From: Sri Gundavelli sgund...@cisco.commailto:sgund...@cisco.com Date: Tuesday, May 26, 2015 at 8:17 AM To: dmm@ietf.orgmailto:dmm@ietf.org dmm@ietf.orgmailto:dmm@ietf.org Subject:

Re: [DMM] DMM WT#4 - 2 Discussion

Thanks for all the discussion today on the WT#4 call. Attendees: Carlos Jesús Bernardos, Satoru Matsushima, Seil Jeon, KJ Sun, Anthony Chen Sri - Update from Seil - Update from Anthony - CPA/DPA sub-functions and roles; Session Re-anchoring; Flow stitching - Next steps on coming out with

[DMM] DMM WT#4 - 2 Discussion

Thanks for all the discussion on the WT#4 call. Attendees: Marco Liebsch, Danny Moses, Jouni Korhonen, Dapeng Liu, Seil, Vic Liu, Fu Qiao, Sri .. The Poll is now closed for the next call. Date: Tuesday, June 23rd at 7AM PDT WebEx Details below Agenda: 1. Seil Jeon will present his new

[DMM] WT#4 - Conf Call

Folks: I’m trying to schedule one or two calls to discuss the work items under WT#4. We did have few discussions including f2f meetings in the past, but now doing it more formally. Scope of WT#4 per chairs suggestion was to cover, architectural/deployment models and to tie the different work

Re: [DMM] RFC4283bis progress..

Brian/Fred, This is exactly what I was thinking. Conveying identity and validating identity are two different things. What is carried in NAI (RFC4283) is just un-authenticated identity. What is needed for validation is a protocol extension such as in RFC4285. Regards Sri On 7/14/15, 11:30 AM,

Re: [DMM] RFC4283bis progress..

: https://www.ietf.org/id/draft-ietf-dhc-sedhcpv6-08.txt Thanks – Fred fred.l.temp...@boeing.commailto:fred.l.temp...@boeing.com From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Charlie Perkins Sent: Thursday, July 09, 2015 7:45 PM To: Sri Gundavelli (sgundave); jouni korhonen; dmm

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

eed to inform the MN about this so it can move its applications off of the high-cost prefix and on to the lower cost prefixes. I also don’t see the reason to expose the network mobility management scheme to the MN. Why does the MN care that it’s a tunnel being used, and not a set of routing table

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

nd yet the protocol functions by preferring routes with lower values over higher ones. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Thursday, October 22, 2015 5:38 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

want to send a map of the operator’s network to the MN. So, I think encapsulating this information in a single cost metric is both necessary and appropriate. -Pete From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Friday, October 23, 2015 11:22 AM To: Pet

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

ve, as I think you do, that the prefix property will change upon handover to a new AR then we shouldn’t tie the transmission of the information to the DHCP state machine. We should not force DHCP to run on every handover. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

fer the lowest cost prefix (the more local one). What is wrong with that? The only reason you would use a higher cost prefix is because you had a session already established on that prefix and needed to keep using it. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Wednesday,

Re: [DMM] I-D Action: draft-ietf-dmm-4283mnids-01.txt

Charlie, I had the same comment on the missing LORA identifiers. Is that a standard ? This is another SDO standard. I can provide the text for LORA. Regards Sri From: dmm > on behalf of Charlie Perkins

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

n suggest how to open the discussion to those other groups. -Pete From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] Sent: Monday, October 26, 2015 6:14 PM To: Peter McCann; John Kaippallimalil; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] FW: New Version Notification for d

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

John: How would the AR know the cost of a prefix ? Assuming the AR is taking the role of a access gateway and the projected prefix is from a remote gateway, how would it put a cost ? Our earlier discussions, we always talked about presenting capabilities of a prefix and not some arbitrary cost

Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt

milar to the chapter on host considerations). We can add a section like “Network Considerations” and state how host/network work to deliver consistent prefix cost (but also that the values are out of scope) – would that address your concern? John From: Sri Gundavelli (sgundave) [mailto:sgund..

[DMM] Review comments on draft-ietf-dmm-4283mnids-00.txt

Hi Charlie, Please see inline for my review comments. Regards Sri Distributed Mobility Management [dmm] C. Perkins Internet-Draft Futurewei Expires: October 24, 2015 V. Devarapalli

Re: [DMM] RFC4283bis progress..

I can review and provide comments. I think its ready for publication, may be after a minor edit. From: dmm dmm-boun...@ietf.orgmailto:dmm-boun...@ietf.org on behalf of jouni korhonen jouni.nos...@gmail.commailto:jouni.nos...@gmail.com Date: Thursday, July 9, 2015 at 1:49 PM To:

Re: [DMM] WG Last Call #2 for draft-ietf-dmm-4283mnids-00

I have read this document and support its publication. I will send out my review comments. Sri On 9/11/15, 12:48 AM, "dmm on behalf of pierrick.se...@orange.com" wrote: >Hi, > >I have read this document and I have no particular

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

I support the adoption of draft-seite-dmm-rg-multihoming as. WG document. The ability for the MAG to register multiple transport end points with the LMA is a basic protocol semantic. How a system architecture uses this extension is a deployment consideration. Sri

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

> but "Hybrid Access" is a term defined by BBF WT-348 so it should be >removed from the text to avoid misleading. We will consider this feedback. > As the draft intends not to refer to BBF WT-348's "DSL+LTE" use-case, >Figure 1 should be removed. The extension is not tied to any specific

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

>>> >>> >>> >>> Do you mean that using DSL and LTE together is a BBF trademark? ... >>> come on. :-).. anyway, I don't care about using another example... why >>> not WiFi and LTE... is it ok? Is there any SDO which claims >>>exclusivity on this >>use-case ;-) ? > Ok, no problem. Now, I guess,

Re: [DMM] Call for adoption confirmation: draft-seite-dmm-rg-multihoming-02

> For me (as an individual contributor) the I-D gives a standard way to >register multiple transport connections/tunnels between a MAG and a LMA, potentially over different technologies (wired, wireless, ..) on the transport network side without needing to rely on engineering solutions Ack.

Re: [DMM] conclusion of adoption calls

On 12/21/15, 2:28 PM, "Behcet Sarikaya" <sarikaya2...@gmail.com> wrote: >On Mon, Dec 21, 2015 at 3:56 PM, Sri Gundavelli (sgundave) ><sgund...@cisco.com> wrote: >> Beat the protocol any time things don¹t go our way. >> >> >> Published Septe

Re: [DMM] conclusion of adoption calls

Beat the protocol any time things don¹t go our way. Published September 14, 2015 https://www.ietf.org/id/draft-sarikaya-nvo3-vmm-dmm-pmip-07.txt I wonder why ? Academic interest ? On 12/21/15, 9:46 AM, "dmm on behalf of Behcet Sarikaya"

Re: [DMM] WGLC #2 for draft-ietf-dmm-lma-controlled-mag-params-01

Thanks Pierrick. We can define the default values along with the range for each variable. Regards Sri On 6/8/16, 2:07 AM, "dmm on behalf of pierrick.se...@orange.com" wrote: >Hi, > >I have read this I-D and I think it is ready to

Re: [DMM] conclusion of adoption calls

Hi Thierry, DMM has the charter for the NEMO protocol maintenance. So, it is the right group and you should be able to bring maintenance and deployment related extensions to this group. Regards Sri > On Jan 8, 2016, at 6:50 AM, Thierry Ernst wrote: > > > Hi Alex,

Re: [DMM] WG Adoption call for draft-chan-dmm-distributed-mobility-anchoring-08

+1 On 7/24/16, 10:50 AM, "dmm on behalf of Seil Jeon" wrote: >I support this I-D for WG adoption. > >Regards, >Seil Jeon > >-Original Message- >From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni >Sent: Sunday, July 24, 2016

Re: [DMM] WGLC #2 for draft-ietf-dmm-ondemand-mobility-05

Support From: dmm > on behalf of Satoru Matsushima > Date: Tuesday, June 28, 2016 at 12:20 AM To: Jouni > Cc: "刘大鹏(鹏成)"

Re: [DMM] dime - New Meeting Session Request for IETF 98

:) Its by design .. even your email client does not want you to leave DMM. Thank you for all your contributions. Sri On 2/1/17, 5:00 PM, "dmm on behalf of jouni.nospam" wrote: >I was gently reminded that even if mobility could be

Re: [DMM] [Int-dir] Review of draft-ietf-dmm-lma-controlled-mag-params-02

Hi Suresh, Dhananjay has an updated draft, he will post it this week. Regards Sri On 1/27/17, 11:10 AM, "Suresh Krishnan" wrote: >Hi Dhananjay/authors, > Any progress on this? I would like to get this moving soon. > >Thanks >Suresh > >On 12/22/16, 4:35 AM,

Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

Thank you Dale for a great review. Charlie/Authors - Can you please respond to Dale and address these comments. Regards Sri On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" wrote: >Reviewer: Dale Worley >Review result: Ready with

Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

Hi Charlie, Please see inline. From: dmm > on behalf of Charlie Perkins > Date: Friday, February 10, 2017 at 2:28 PM To: Dale Worley

Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

HI Dale, Thanks again for the comments. Please see inline. On 2/13/17, 8:55 AM, "Dale R. Worley" <wor...@ariadne.com> wrote: >"Sri Gundavelli (sgundave)" <sgund...@cisco.com> writes: >> When we discussed this issue in the past, the general feedback

Re: [DMM] DMM IETF 98 meeting

Gentle Reminder . Please send your requests for presentation slot by 2/23. Please include Title: Description: Time: Presenters: Draft Reference (If exists): Regards Sri From: Dapeng Liu > Date: Monday, January 23, 2017 at 2:09 AM To: dmm

  1   2   3   4   >