[DMM] Intdir early review of draft-ietf-dmm-ondemand-mobility-14
Reviewer: Brian Haberman Review result: Not Ready This is an early review request for draft-ietf-dmm-ondemand-mobility. I am having a hard time with the thrust of this document. The following issues really need to be addressed in some form... 1. Where is the concept of an IP session defined? Given that IP is connectionless, this term is really about IP address stability and its lifetime. A new term could/should be coined to reflect what is really needed. 2. The needs described in this document have a mix of the ID/Location split issues raised in a variety of other specifications. It would be good to clarify what is different here. 3. The draft only references host-based Mobile IP specifications. What are the implications when other solutions (e.g., PMIP) are employed? 4. It is problematic that this document explicitly rules out of scope any discussion of how this API interacts with address assignment methods (e.g., DHCP). Clearly, there will need to be a way for this API to influence each of the address assignment methods available. Some of the classes of IP addresses described in this document require certain lifetime guarantees from the address assignment method. That needs to addressed since it will require changes to every assignment method. 5. The IETF has a very checkered history of success in getting APIs standardized within the appropriate group (POSIX/Austin/Open). Has this proposed API been discussed within that community? ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] FW: New Version Notification for draft-mccann-dmm-prefixcost-02.txt
I had intended to bring this up during the session, but we are/were pressed for time... On 10/26/15 9:22 PM, Peter McCann wrote: > I don't understand why you think it needs to be so complicated. It > seems much simpler than the other prefix coloring approaches I have > seen being suggested, and much easier to see how applications would > use the information. > > I agree it might be wise to consult 6man and also MIF. Perhaps Brian > can suggest how to open the discussion to those other groups. I think initial coordination with 6man should be explored. This can be done by raising the issue on the 6man mailing list and asking for input. We may need to work with other folks (perhaps in OPS/MGMT or RTG) depending on how the prefix cost gets defined and its rate of change. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] RFC4283bis progress..
Hi Fred, On 7/14/15 10:54 AM, Templin, Fred L wrote: Hi Sri, Reason for the X.509 certificate is that, in some environments, an attacker can spoof a DHCP Client Identifier and receive services that were intended for the authentic client. With X.509 certificate, the certificate holder has to sign its DHCP messages with its private key so the DHCP server can authenticate using the public key and therefore defeat any spoofing. Can you suggest an X.509 format/profile that can be represented in 254 bytes? Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] RFC4283bis progress..
On 7/14/15 12:19 PM, Templin, Fred L wrote: Hi Brian, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Tuesday, July 14, 2015 8:37 AM To: dmm@ietf.org Subject: Re: [DMM] RFC4283bis progress.. Hi Fred, On 7/14/15 10:54 AM, Templin, Fred L wrote: Hi Sri, Reason for the X.509 certificate is that, in some environments, an attacker can spoof a DHCP Client Identifier and receive services that were intended for the authentic client. With X.509 certificate, the certificate holder has to sign its DHCP messages with its private key so the DHCP server can authenticate using the public key and therefore defeat any spoofing. Can you suggest an X.509 format/profile that can be represented in 254 bytes? Probably not, but I think I have a better understanding of my requirements now. A mobile node can use an X.509 certificate to prove ownership of the DHCP Client Identifier, so it is the Client ID and not the X.509 certificate itself that identifies the mobile node. Do I have that right? The client ID identifies the node. An X.509 certificate provides the means of mapping identities to public keys and have that information verified by a third-party (CA). So, one could do something like: 1. Client sends client-id to the server 2. Server looks up X.509 cert by the client-id 3. Server sends a challenge to the client based on the public key in the cert 4. Client responds to the challenge by signing the response with the private key 5. The server verifies the response with the public key Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
On 4/22/15 12:51 PM, Templin, Fred L wrote: Hi Alex, -Original Message- From: Alexandru Petrescu [mailto:alexandru.petre...@gmail.com] Sent: Tuesday, April 21, 2015 12:42 PM To: Templin, Fred L; Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 31/03/2015 00:42, Templin, Fred L a écrit : Hi Alex, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Alexandru Petrescu Sent: Thursday, March 26, 2015 3:03 PM To: Jouni Korhonen; dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call Le 26/03/2015 13:17, Jouni Korhonen a écrit : Alex, 3/26/2015, 11:00 AM, Alexandru Petrescu kirjoitti: [snip] I thought by fixed you meant it stays the same wherever the Host goes (something like the Home Address). Alper - I think a LL address can also be qualified as 'fixed' - it never changes. Does LL here mean link-local or link-layer? If it is the former one, then the above assertion is not correct. Link-local. And you seem to say a link-local address is not fixed? I think link-local addresses _are_ fixed set in stone. They are formed locally without need of help from router. AERO provides a fixed link-local address that is formed from a prefix received by DHCPv6 Prefix Delegation (PD). Fred - but why should this ll prefix be provided by DHCP? Is it of variable value? Or is the link-local constant all the time? (in which case it could be hardcoded everywhere). DHCPv6 Prefix Delegation delegates an IPv6 prefix to the AERO Client (e.g., 2001:db8:1:2::/64). The Client then constructs an AERO link-local address from the prefix as fe80::2001:db8:1:2 (i.e., it embeds the 64-bit prefix from the prefix delegation in the 64-bit interface identifier of an IPv6 link-local address). So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
On 4/27/15 12:30 PM, Templin, Fred L wrote: Hi Brian, -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Monday, April 27, 2015 9:22 AM To: dmm@ietf.org Subject: Re: [DMM] Mobility Exposure and Selection WT call On 4/27/15 11:53 AM, Templin, Fred L wrote: So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Just because the AERO address Interface ID is not formed via EUI-64 does not mean that it is not a link-local address (see RFC7136, which updates RFC4291). RFC7421 gives further commentary. I am not referring to the IID of the link-local address. I am talking about the 54 bits of zero which immediately follow the FE80::/10 prefix. AERO leaves those 54 bits as zero - are you seeing some place in the spec where it does not appear that way? Apologies. I read your example incorrectly. As long as the prefix delegated is 64 bits... Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Mobility Exposure and Selection WT call
On 4/27/15 11:53 AM, Templin, Fred L wrote: So, it is not actually a link-local address per the IPv6 Addressing Architecture (https://tools.ietf.org/html/rfc4291#section-2.5.6). Just because the AERO address Interface ID is not formed via EUI-64 does not mean that it is not a link-local address (see RFC7136, which updates RFC4291). RFC7421 gives further commentary. I am not referring to the IID of the link-local address. I am talking about the 54 bits of zero which immediately follow the FE80::/10 prefix. signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] DMM work teams
DMM WG, I want to, once again, clarify the guiding principles for the DMM work teams. Hopefully, this will make it clear to all participants how the work teams will influence the WG. The guiding principles are: 1. All work teams are open to input from anyone 2. Any work team holding a meeting will announce that meeting to the WG 3. Any document produced by a work team is treated as any individual draft 4. Anyone can publish alternative proposals and ask the WG to consider them 5. WG consensus will drive the adoption of any solutions drafts (work team generated or otherwise). If you have any questions about the above, please contact me. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] offlisted mails - names of Work Teams
I want to ask a question (or two) on this thread... On 10/29/14 10:56 AM, Alexandru Petrescu wrote: Jouni, I reply here, but I will write separate emails. Le 24/10/2014 19:51, Jouni a écrit : Ok.. once more. On Oct 24, 2014, at 7:46 PM, Alexandru Petrescu wrote: 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. 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. Jouni - there are some particular aspects in which these teams work. There are no emails to look at: everything seems to be happening on the phone? Are the audiologs available? How are these work teams any different than a group of people getting together to write a draft? You don't get the level of information you are asking for above for individual drafts. Audioconferences: I tried to participate to a doodle but the hours are not clear about the time region. It looks like a change in the traditional way work is being done here. 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. Let's hope for the best. Do you not believe the chairs' and AD's comments that drafts created by these work teams will be treated like all other individual submissions? 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. I will reply separately about this but for now I can say that I am a bit surprised by your statement. 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. Ok. 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? To join I need to use the right tools and Doodle in particular is not very appropriate (what time zone is that?). Doodle polls generally present time in the viewer's timezone. If not, contact the person who posted the poll and ask them to verify the poll configuration. Do you have a better tool in mind for polling a group of people on their availability? Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] offlisted mails - names of Work Teams
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 signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Fwd: New Liaison Statement, Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348)
Something for you to be aware of... Brian Original Message Subject: New Liaison Statement, Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348) Date: Tue, 21 Oct 2014 09:06:52 -0700 From: Liaison Statement Management Tool l...@ietf.org To: The IETF Chair ch...@ietf.org CC: david.i.al...@ericsson.com, sven.oo...@alcatel-lucent.com, gbing...@broadband-forum.org, guiu.fabre...@alcatel-lucent.com, The IESG i...@ietf.org, David Sinicrope david.sinicr...@ericsson.com, rme...@broadband-forum.org, david.j.tho...@bt.com, christophe.al...@orange.com Title: Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348) Submission Date: 2014-10-21 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1355/ From: Broadband Forum (Christophe Alter christophe.al...@orange.com) To: The IETF (The IETF Chair ch...@ietf.org) Cc: The IESG i...@ietf.org,David Sinicrope david.sinicr...@ericsson.com,christophe.al...@orange.com,david.i.al...@ericsson.com,david.j.tho...@bt.com,sven.oo...@alcatel-lucent.com,guiu.fabre...@alcatel-lucent.com,rme...@broadband-forum.org,gbing...@broadband-forum.org Response Contact: Technical Contact: Purpose: For information Body: Dear IETF and 3GPP colleagues, At the Broadband Forum Meeting held recently in Dublin, Ireland, the End to End Architecture Working Group has approved and begun work on a new project called “WT-348 Hybrid Access for Broadband Networks” defining architectural requirements to allow coordinated and, when needed, simultaneous use of fixed broadband access and 3GPP access networks for converged operators. The business drivers for this work include enabling service providers to offer faster service provisioning and fulfillment, higher throughput and increased WAN reliability. We will keep you informed of this work as it progresses. The Broadband Forum’s Q4 meeting will be held December 8 - 12, 2014 in Taipei, Taiwan. Sincerely, Christophe Alter, Broadband Forum Technical Committee Chair Attachments: Broadband Forum Work on “Hybrid Access for Broadband Networks” (WT-348) https://datatracker.ietf.org/documents/LIAISON/liaison-2014-10-21-broadband-forum-the-ietf-broadband-forum-work-on-hybrid-access-for-broadband-networks-wt-348-attachment-1.pdf signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. He also emphasized importance of running code. Running code is good thing. So is an understanding of customer needs (in this case, other SDOs). Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
On 9/3/14 12:50 PM, Behcet Sarikaya wrote: Hi Brian, On Wed, Sep 3, 2014 at 11:30 AM, Brian Haberman br...@innovationslab.net wrote: Just for clarification... On 9/3/14 12:22 PM, Behcet Sarikaya wrote: I am also concerned on the time DMM is taking on dressing up the charter text. I remind you on what Jari Arkko who is founding AD for DMM said in Toronto admin plenary: WGs should have solution work from day 1. Not should, but rather could. Not all WGs need to have requirements, frameworks, architecture, etc. That is why this type of discussion during charter development is important. Here is the quote: WGs should have solution work from day 1 from page 22 of Jari's slides at: http://www.ietf.org/proceedings/90/slides/slides-90-iesg-opsplenary-7.pdf Yes, that is what the slide says. The IESG discussed the contents of this presentation and the overwhelming consensus (and what was verbalized in the plenary) is that WGs should not be formed where the *only* output is architecture, frameworks, and/or requirements documents. The charter should have protocol/solution work on the charter from day one. It does not mean that non-solution documents should be skipped if they are needed or provide useful background. The charter text that Jouni sent to the mailing has four (4) work items. By my read, three (3) of them are solutions to identified problem areas. So, I believe the charter is following the spirit of Jari's plenary slides. Your only complaint is about the first work item. I have seen people asking about clarifications on that work item, but you are the only one who wants it removed. I believe others are in favor of providing a document of the high-level models being targeted for the solutions work. At this point, the WG chairs need to determine if there is consensus for the latest charter text. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] regarding the re-chartering..
Behcet, On 9/3/14 2:33 PM, Behcet Sarikaya wrote: You don't seem to understand my points. That is quite possible. Your comment on the list was I am against any deployment work before we decide on a solution... I read that as an objection to having the deployment models work item on the agenda. Please do tell me what I am missing. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] AD Evaluation: draft-ietf-dmm-best-practices-gap-analysis
All, I have reviewed draft-ietf-dmm-best-practices-gap-analysis as a part of the publication process. The document is well-written and easy to follow. I only have a few points I would like to see addressed/discussed before I move the draft to IETF Last Call. 1. I would suggest making the following change to the Abstract: s/The present document/This document/ 2. Re-word the Introduction to not refer to the DMM WG. In general, an RFC should not reference a WG name since that WG may not exist forever. 3. I would drop the 2119 keyword paragraph (and the corresponding reference to 2119). The only places where those words are used is in sections 5.5 5.6 and those should be changed (described in a later point). 4. Please expand (and reference) SCTP in section 4.1. I would also suggest doing a search for acronyms and ensuring they are all expanded on first use. 5. In Figure 1 (section 4.2), I would suggest giving the MNs unique labels and then using those labels in the supporting text. 6. Section 4.2.1: * s/by IETF// * s/outside IETF/in other standards organizations/ * s/IETF has defined extensions/Extensions have been defined/ * Please remove reference to seamoby WG. 7. Section 5.1 : s/by IETF// 8. Section 5.2 mentions the need for host to network signaling for determining which apps are using IP mobility management, but there is no mention of any signaling from applications to the IP stack that a particular app needs IP mobility management. I think that needs some discussion in the document. 9. Sections 5.5 and 5.6... I would suggest re-wording these sections to paraphrase the text from the requirements document. Specifically, the verbatim use of 2119 keywords may be confusing since it is inconsistent with previous sections. 10. Section 5.8 : Remove explicit mention of multimob WG. Let me know if you have any questions/concerns with these comments/suggestions. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
On 7/23/14 10:16 AM, Behcet Sarikaya wrote: So my question is what guarantees that is the DT is going to produce the right solution and why repeat the history again? Who said that *if* a DT is formed that its output is considered special? http://www.ietf.org/iesg/statement/design-team.html signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
On 7/23/14 10:49 AM, Behcet Sarikaya wrote: On Wed, Jul 23, 2014 at 9:36 AM, Brian Haberman br...@innovationslab.net wrote: On 7/23/14 10:16 AM, Behcet Sarikaya wrote: So my question is what guarantees that is the DT is going to produce the right solution and why repeat the history again? Who said that *if* a DT is formed that its output is considered special? http://www.ietf.org/iesg/statement/design-team.html My point is that at this time in dmm I can not see any justification for forming a design team to develop a solution or parts of a solution. Jouni pointed out that the DT approach is just an option. We already have solutions and it seems like at least one of them is implemented. I don't think it is reasonable to expect any deployment now. In view of this I am unable to see the need for some many items in the proposed charter. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] IETF#90 DMM agenda update
On 7/22/14 10:49 AM, Jouni Korhonen wrote: Folks, The agenda has been slightly updated (shuffling around the slots and arranging more time to the charter/next steps discussion). Some presenters are affected slightly (-5 minutes). see http://www.ietf.org/proceedings/90/agenda/agenda-90-dmm Regarding the re-chartering and the next steps. We have a tight deadline to meet if we want to ship the new charter text to the next IESG telechat. Brian will reveal the gory details of the expected re-chartering process and timelines. We are also supposed to come up (again) with a rought agreement of the deployment architecture(s) that DMM functional elements map into. This will be discussed as a part of the re-chartering slot and recapping the discussions we had earlier. We are also supposed to come up with a rough agreement how to progress from now on. This could mean (note the conditionality here) a series of interim meetings and setting up small groups (or design teams) to work on the initial set of the solution space drafts. We need to step out of the progress every second IETF meeting mode ;) http://www.ietf.org/iesg/statement/interim-meetings.html Also keep in mind that the start of the new work poses some serialization whether we want or now: first stabilize charter reach rough consensus on the deployment models/functional elements. These can be done in parallel. Note that rough consensus does not mean a ready spec or spec at all. Second execute with the solutions space.. the deployment models work might benefit from having a slight heads up before other drafts. These can be done in parallel, though. As a reminder, the charter may change on the route before it gets approved but we can do the opportunistic thing and start working as if the charter were already approved when the WG ships it. - Jouni Dapeng ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: IETF 90 Preliminary Agenda
All, It wasn't a false alarm. The original request from the chairs was for a single session. The chairs contacted me today and asked about the possibility of a second slot. I was able to work that out with the Secretariat before most of you reviewed the schedule. Thank the Secretariat (Stephanie, in particular) for being so willing to add an additional DMM slot. Regards, Brian On 6/23/14 5:01 PM, Alper Yegin wrote: Oops, I missed the second one :-) Sorry for the false alarm. On Jun 23, 2014, at 11:15 PM, h chan wrote: 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 single 2-hr session for the whole DMM WG? Begin forwarded message: From: IETF Agenda age...@ietf.org Subject: IETF 90 Preliminary Agenda Date: June 23, 2014 10:16:20 PM GMT+03:00 To: IETF Announcement List ietf-annou...@ietf.org Cc: i...@ietf.org Reply-To: i...@ietf.org, IETF Agenda age...@ietf.org The IETF 90 Preliminary Agenda has been posted. The final agenda will be published on Friday, June 27th, 2014. Currently Registration and Breaks are not displaying. This will be remedied on the final agenda. https://datatracker.ietf.org/meeting/90/agenda.html https://datatracker.ietf.org/meeting/90/agenda.txt More information regarding IETF 90 in Toronto, ON, Canada is located here:https://www.ietf.org/meeting/90/index.html Thank you! IETF Secretariat ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] draft charter text updates in github..
Hi Fred, On 6/18/14 11:25 AM, Templin, Fred L wrote: Hi Jouni, -Original Message- From: Jouni Korhonen [mailto:jouni.nos...@gmail.com] Sent: Wednesday, June 18, 2014 3:00 AM To: Templin, Fred L; dmm@ietf.org Subject: Re: [DMM] draft charter text updates in github.. Fred, It is true IPv4 is there (and will be for a long time). Although the charter does emphasize IPv6 as the base solution it does not prohibit adding IPv4 support. It is just we can accept an IPv6-only solution as a valid complete solution from DMM point of view. However, a solution that works equally well whether the access networks are IPv6-only, dual-stack, or IPv4-only has clear advantages in terms of near-term deployment in real networks. Therefore, I think the charter is currently saying _too much_. My new proposal is simply to strike the following two sentences: DMM solutions are primarily targeted at IPv6 deployments and should not be required to support IPv4, specifically in situations where private IPv4 addresses and/or NATs are used. IPv6 is assumed to be present in both the mobile host/router and the access networks. The above has been a part of the DMM charter for a long time. Taking it out would appear to be opening the door for IPv4-only solutions. My assessment of the winds within the community is that people are not interested in new protocols for IPv4. Just my opinion... Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Hi Jouni, On 1/30/14 7:40 PM, Jouni Korhonen wrote: On Jan 29, 2014, at 6:01 AM, Brian Haberman br...@innovationslab.net wrote: [snip] We can change to: REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts without breaking them. For example, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols or may need to co-exist with a network or mobile hosts/routers that do not support DMM protocols. The mobile node may also move between different access networks, where some of them may support neither DMM nor another mobility protocol. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. The without breaking is fine. However, the need to be compatible with phrasing is still problematic. Is that inferring that in some situations that a DMM solution would need to interact with, for example, PMIP? Your observation is correct. Maybe slightly better wording would work: REQ5: Co-existence with deployed networks and hosts The DMM solution may require loose, tight or no integration into existing mobility protocols and host IP stack. Independent of the integration level, the DMM solution MUST be able to co-exist with existing network deployments, end hosts and routers that may or may not implement existing mobility protocols. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. I am fine with this formulation. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Hi Anthony, On 1/29/14 1:51 PM, h chan wrote: Brian, The requirement is intended to include a capability of not using network-layer mobility management, as opposed to using it by default. I think it is sufficient to leave to the explanation (the sentences after the first sentence) to say that network-layer mobility support is not always needed in order to justify this capability. The alternative then is to say that network-layer mobility is provided but it is possible to not use such support. REQ2: Using and not Using Network-layer mobility support DMM solutions MUST enable network-layer mobility but it MUST be possible to not invoke it. Mobility support is needed, for example, when an application or a host cannot cope with a change in the IP address when a node moves. Yet a mobile node can often be stationary, and mobility support can also be provided at other layers. It is then not always necessary to maintain a stable IP address or prefix. Of cause enable does not mean it must be used. Yet explicitly say it is possible to not invoke it is to draw the contrast to using it by default. My only concern is that it is unclear *who* invokes the network-layer mobility support. Is it envisioned that the application can signal the need for mobility support? Does the user have to configure which applications get support? Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Anthony, I am fine with that. I would like feedback from the rest of the WG on these changes. Brian On 1/29/14 1:53 PM, h chan wrote: Delete those explanatory sentences then. REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts. Furthermore, a DMM solution SHOULD work across different networks, 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...@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements On 1/28/14 4:33 PM, h chan wrote: Regarding the following: - What is meant by co-exist in REQ5? Does this mean that a DMM solution does not break an existing one? Or does it mean that it must inter-operate with existing ones? Is this like IPv4 and IPv6 being incompatible, but can run concurrently on the same network? Or does this mean there needs to be some mechanism for interaction (i.e., like NAT64)? I think the bottom line is that the existing ones do not break. Original REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts. For example, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols or may need to co-exist with a network or mobile hosts/routers that do not support DMM protocols. The mobile node may also move between different access networks, where some of them may support neither DMM nor another mobility protocol. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. We can change to: REQ5: Co-existence with deployed networks and hosts The DMM solution MUST be able to co-exist with existing network deployments and end hosts without breaking them. For example, depending on the environment in which DMM is deployed, DMM solutions may need to be compatible with other deployed mobility protocols or may need to co-exist with a network or mobile hosts/routers that do not support DMM protocols. The mobile node may also move between different access networks, where some of them may support neither DMM nor another mobility protocol. Furthermore, a DMM solution SHOULD work across different networks, possibly operated as separate administrative domains, when allowed by the trust relationship between them. The without breaking is fine. However, the need to be compatible with phrasing is still problematic. Is that inferring that in some situations that a DMM solution would need to interact with, for example, PMIP? Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
That works for me. Brian On 1/28/14 4:58 PM, h chan wrote: 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 management solutions can be challenging, and debugging difficult, when they co-exist with solutions already deployed in the field. We can change to PS7: Deployment with multiple mobility solutions There are already many variants and extensions of MIP as well mobility solutions at other layers. Deployment of new mobility management solutions can be challenging, and debugging difficult, when they co-exist with solutions already deployed in the field. H Anthony Chan -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Friday, January 24, 2014 11:30 AM To: draft-ietf-dmm-requireme...@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: [DMM] AD Evaluation: draft-ietf-dmm-requirements All, I have performed my AD review, as a part of the publication process, of draft-ietf-dmm-requirements. The following issues should be addressed prior to moving this draft to IETF Last Call. Please let me know if you have any questions on these points. 1. I would suggest making sure that the Abstract and Introduction explicitly state that these requirements for for network (L3)-layer mobility management. 2. Introduction: - The EPC acronym needs to be expanded. - Do not reference the DMM charter within the document. - expand HA and LMA since you are using them before the Terminology section. 3. Section 3: - It would be nice to ensure that all acronyms used in the figures are expanded somewhere prior to the figures. - I am curious as to why there is not any mention in this section about route optimization within the mobility protocols. This mention should describe why current route optimization is host-based in order to lead into PS1. 4. Section 4: - To be abundantly clear, I would re-word the start of PS3 to be Lack of scalability. - I am not sure that it benefits the document to label PS6 and PS7 as related. Those issues are problematic on their own. If you remove the (related problem) label from them, make sure that REQ2 is updated to remove mention of related problem. - Should PS7 mention mobility solutions that operated at other layers of the protocol stack? 5. Section 5: - Why does this section have sub-section numbers AND REQ numbers? - I am not sure I understand what REQ1 is saying when it talks about combining mobility anchors with CDNs. It *sounds* like mobility management needs to be maintained by CDN providers. - I am a little confused by REQ2. It says that a DMM solution should be transparent to the applications. However, the motivation talks about identifying applications that do (or do not) need mobility support from the network layer. That doesn't sound transparent to me. Am I reading this incorrectly? - I am wondering if the SHOULD in REQ4 ought to be a MUST. Why would anyone work on a new protocol without first determining the feasibility of the existing ones? - What is meant by co-exist in REQ5? Does this mean that a DMM solution does not break an existing one? Or does it mean that it must inter-operate with existing ones? Is this like IPv4 and IPv6 being incompatible, but can run concurrently on the same network? Or does this mean there needs to be some mechanism for interaction (i.e., like NAT64)? - I think REQ6 is incomplete. A DMM solution can introduce new vulnerabilities, but it needs to provide ways to cope with those vulnerabilities. 6. I would like to avoid issues further along the publication chain, so I would like the editors to look at how the contributing authors are identified in the draft. A good approach is described in the RFC Style Guide (https://www.rfc-editor.org/policy.html#policy.auth) and deviating from that can be problematic. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements
Routers as well. Because, if we talk Mobile Routers, then rarely an application runs directly on it. Most applications would run on LFN. Transparency? If the applications run on the LFN, the change of the attachment of the MR is 'transparent' to them, regardless whether or not MR does something to maintain stability of that address (Mobile IP, other). Second, this transparency may depend on the direction, or more complex 'shape' of the application flows. Some IP flows of some applications have very complex 'shapes', with various sets of IP src and dst, and triangular or HA-less shapes. Take for example a video-call. The session establishment through an intermediary and behind NAT is followed by the ongoing 4 flows (2 audio 2 video)... they all take different paths... each may need or not need to go through the HA, and each has distinct behaviours when the IP address changes, hence each would have a distinct 'transparency' requirement. Is this _one_ application? Alex H Anthony Chan -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Brian Haberman Sent: Monday, January 27, 2014 7:20 AM To: h chan; draft-ietf-dmm-requireme...@tools.ietf.org; dmm@ietf.org; Peter McCann Subject: Re: [DMM] AD Evaluation: draft-ietf-dmm-requirements On 1/24/14 7:38 PM, h chan wrote: 4. Section 4: - I am not sure that it benefits the document to label PS6 and PS7 as related. Those issues are problematic on their own. If you remove the (related problem) label from them, make sure that REQ2 is updated to remove mention of related problem. The intention of the name related problems was not to suggest they are less problematic, but rather to distinguish them from the other problems directly on mobility management. Although these problems are not directly on mobility management, the DMM solutions can solve these additional problems. They are therefore included. So, as long as this section is not to be interpreted as limited to problems directly on mobility management, we can drop the word related. I will leave it to the authors/WG, but I don't see a benefit to the related tag. Regards, Brian ___ 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Hi Pete, Speaking with no hat on... On 11/12/13 4:29 PM, Peter McCann wrote: Hi, Sri, Even if we agree that those services are necessary (and I would point out once again that most of them are not beneficial to the end-user) I don't think we should be architecting the network in such a way that we lose the basic benefits of IP (shortest path routing and fault-tolerance). We can implement those services without taking all the packets to a central location; maybe just the first packet or meta-information about the first packet can be taken to an SDN controller that can make some decision and pass it down to the user plane. I really don't think this is such fantastic science-fiction. ;) The degree to which this is science fiction really depends on what scope you think these host routes will have in the routing system. * Are you assuming mobility within a single enterprise or Autonomous System? * Limited mobility within a consortium of networks? * Is this global mobility for any/all nodes? Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
Rather than sink into a re-chartering discussion, I would like the WG to focus on completing the existing work items. It was suggested that an interim (or 2) get set up to work on these items. Please focus on this rather than re-chartering. Regards, Your friendly AD On 11/13/13 3:43 PM, Behcet Sarikaya wrote: As for the next steps, my suggestion is that Jouni posts a draft charter based on the slide he showed in Vancouver where different pieces of a dmm solution was listed. We can have email discussions based on that proposal and hopefully come to a consensus in a reasonable amount of time. However, Jouni did not post his slides in the proceedings, I checked all the presentations and the chair's slides are not there. So maybe the first step should be that Jouni posts his slides so we can have a look. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Preparing for DMM future steps and rechartering
I never said they had to be face-to-face meetings. It is completely acceptable to hold virtual (on-line) meetings. Regards, Brian On 11/13/13 4:01 PM, Behcet Sarikaya wrote: Hi Brian, I personally think that Interim(s) would not work for dmm. Only a few people could go to such meetings. Most of us already have a heavy travel schedule, squeezing another trip seems not so reasonable. Regards, Behcet On Wed, Nov 13, 2013 at 2:53 PM, Brian Haberman br...@innovationslab.netwrote: Rather than sink into a re-chartering discussion, I would like the WG to focus on completing the existing work items. It was suggested that an interim (or 2) get set up to work on these items. Please focus on this rather than re-chartering. Regards, Your friendly AD On 11/13/13 3:43 PM, Behcet Sarikaya wrote: As for the next steps, my suggestion is that Jouni posts a draft charter based on the slide he showed in Vancouver where different pieces of a dmm solution was listed. We can have email discussions based on that proposal and hopefully come to a consensus in a reasonable amount of time. However, Jouni did not post his slides in the proceedings, I checked all the presentations and the chair's slides are not there. So maybe the first step should be that Jouni posts his slides so we can have a look. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] WGLC starts for draft-ietf-dmm-requirements-03
On 4/9/13 6:10 PM, Behcet Sarikaya wrote: I believe multicast is a distraction to dmm at this moment. I am curious as to why you call it a distraction. It seems to me that having multicast support considered at the beginning of the process is much better than trying to bolt it on after the fact. That is the reason that I suggested that DMM-related multicast be discussed in DMM. Could you explain why multicast should not be considered by DMM? Regards, Brian ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
[DMM] Mobility-related work in the IEEE
All, As per the note below, the IEEE has approved the OmniRAN study group. There is potential for significant interactions between OmniRAN and the IETF on mobility-related work. Regards, Brian Original Message Subject: [new-work] Status of Study Groups per November 2012 IEEE 802 Plenary Date: Thu, 3 Jan 2013 14:48:13 -0600 From: john_dambro...@dell.com To: new-w...@ietf.org Dear Colleagues, The following Study Groups were approved at the November 2012 IEEE 802 Plenary - 1. IEEE 802, OmniRAN EC Study Group 2. IEEE 802.1 802.11 Bridging Study Group 3. IEEE 802.3 Reduced Twisted Pair Gigabit Ethernet Study Group 4. IEEE 802.3 Next Generation BASE-T Study Group 5. IEEE 802.3 Distinguished Minimum Latency Traffic in a Converged Traffic Environment Study Group 6. IEEE 802.11 Pre-association Discovery (PAD) Study Group 7. IEEE 802.11 General Link (GLK) Study Group 8. IEEE 802.15 Ultra Low Power Study Group 9. IEEE 802.15 Layer 2 Routing Study Group Please note, per the IEEE 802 LMSC Policies and Procedures that a Study Group is chartered plenary session-to-plenary session. Therefore, the Study Groups, listed above and found at http://www.ieee802.org/StudyGroups.shtml, are chartered until the IEEE 802 March 2013 Plenary Session. Please note that IEEE meetings are open and may be attended by any individuals who register and fulfill any registration fees. Details regarding future IEEE 802 plenary meeting schedules may be found at http://www.ieee802.org/PARs.shtml. Please refer to individual working groups for their interim meeting schedules. A listing of all working groups may be found at http://www.ieee802.org/. Best Regards, John D'Ambrosia IEEE 802 LMSC Recording Secretary Note - This email solely represents the views of the IEEE 802 LMSC and does not necessarily represent a position of the IEEE or the IEEE Standards Association. ___ new-work mailing list new-w...@ietf.org https://www.ietf.org/mailman/listinfo/new-work ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
