Re: [DMM] Going forward with the DMM work items
Hi Satoru, Thank you for your comments on my draft, we will consider them in revising it next time. Let me say that I lived in Japan more than 7 years and I can probably state that I am a bit familiar with the culture. So my translation of your views is that these things happen in IETF and we should live with them. Yes, I agree that it happens but in IETF there is also freedom of expression. We can and we should point the discrepancies and there is nothing wrong to say that this (whatever it is) is wrong, people will respect you more if you do that. Regards, Behcet On Tue, Oct 7, 2014 at 2:31 AM, Satoru Matsushima wrote: > Hi Behcet, > > > On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya > wrote: >> >> >> I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi >> we proposed new approaches like SDN. >> > > Please don't get me wrong. My position hasn't been changed. BGP is used to > forwarding path management signaling. > > In your draft, XMPP is the protocol that has same role of BGP. Good idea, it > is a pub-sub system as same as BGP. You may need to define data model for > dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs > either xmpp, netconf, or forces. > > I suppose that you might want to adopt end-system VPN > (https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data > modeling. (actually it is BGP. :-) And, as you may know that there is a > draft which mentions about use case of BGP in i2rs. > (http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases) > >> >> Having said that I don't think that the charter text on forwarding >> path and signaling is talking about the same thing. >> > > Interesting. What do you expect for the charter text? > Why not you ask Marco, Anthony and Alper to explain their thought? > > >> >> >> In DMM fir WiFi we also adopted the anycast discovery, what is wrong with >> that? > > > How do you find the anycast address itself? > > >> >> >> Yes I agree, maybe other techniques like AAA can be worked out. Why >> not do it as extensions? >> > > I suppose that it would be a part of enhanced anchoring work, isn't it? > > >> >> Really? My thinking was that vEPC does not need any involvement from >> MN because the prefix assigned to MN does not change. >> >> As I mentioned in my more recent mail, I think this item is based on >> 2102 solution proposals in which MN had to deal with many prefixes. >> >> Can you clarify which network nodes need exposure to MN mobility >> state? The ones on the path already know MN prefix, right? >> > > Quite not. I meant disclosing mobility information to network node that > likes such as BGP speaker. > > >> >> So you are saying that these three items gave you some good ideas to >> think about on how you can improve your solution, vEPC. >> > > In my view, the charter items work well to achieve vEPC architecture model, > yes. > More precisely, as the result of discussions which I had so far with many > dmm people, I have noticed some parts which the draft needs more work to > achieve the architecture model. > >> >> You are indicating that there is a major solution proposal, i.e. vEPC >> by you, but that can be improved here and there. >> >> You are missing the point that such a view point is not yet agreed by the >> group. > > > I know. So I am trying to express my thought, and then we can recognize > differences each other, and we can discuss. It's normal process in the ietf > I think. > >> >> >> Without such an agreement on the base, isn't it quite concerning what >> the WT's or DT's will do? >> >> My understanding is that the formation of WT's or DT's is another way >> of saying that we don't like all those solutions out there, we will >> design our own solutions to the above 3. > > > I guess wg management, who are responsible to establish dmm standard, expect > standardizing dmm solution would be very hard work because they find many > variants for it. In that situation, it would be reasonable that they appoint > some persons to lead the work. I really appreciate those persons who > volunteer to take that role to out consolidated solution. > > Cheers, > --satoru ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Going forward with the DMM work items
Hi Satoru, >> That is too bad, because I will be briefing the AERO BGP routing system at >> the meeting tomorrow. > > Yes, sorry to say. OK. The talk generated quite a few questions, and was followed by a demo of emulated network nodes running BGP and adding/withdrawing routes in response to emulated Client/Server associations. >> I read your proposal, but have not received any indication if you have read >> my AERO proposal yet. AERO uses >> BGP in a way that was first specified by RFC6179 in 2011 and carried forward >> into draft-templin-ironbis and >> draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of >> which AERO Client Prefixes (ACPs) >> are associated with which AERO servers. But, only the Servers are exposed to >> localized ACP mobility events; >> the BGP is only updated when an ACP moves to a new Server. This means that >> there will be very little churn >> in the BGP routing system itself. So, the BGP is not directly exposed to >> localized mobility events. > > I know you are the guy who invent ISATAP That was a long time ago. :^} > so I understand you may utilize same mechanism. Not exactly the same mechanism, but yes the same NBMA tunnel virtual link model. Once the virtual link is established, ordinary link-local services like DHCPv6 and IPv6 Neighbor Discovery (ND) can be used to manage Client/Server associations and Client mobility events. There is no need for any other control message signaling protocols. > You and me > look big-believer of BGP ecosystem. In my draft, 3gpp defined mobility > management is assumed to exist so > the mobility management exports BGP mobility information into routing > information. Do you assume 3gpp > or ietf mobility management protocol/system in your draft as well? My draft presents a method for managing Client mobility based on DHCPv6 and IPv6 ND messaging in the same way that these functions would work on ordinary links. But Client mobility does not get propagated up to the Server/Relay BGP routing system unless the Client changes over to a new Server (which should happen only very infrequently). That said, the AERO BGP routing system can be used independently of the underlying Client mobility signaling - it is only concerned with announcing and withdrawing routes via BGP updates. >> AERO Clients use DNS discovery to discover the address(es) of nearby >> Server(s) as the default >> means. Other solutions such as manual configuration, DHCP option, etc. are >> also possible. > > Yes, I know, there are many type of endpoint discovery. Do you clear any > patent which claim > the right of dns based endpoint discovery? There are no patents that I am aware of. The AERO DNS discovery exactly parallels the discovery method used for ISATAP as found in widely deployed implementations. >> It would be nice if you were to review the AERO architecture and explain to >> me the way in which >> this requirement is or is not addressed already there. > Well, will do. I suppose today you provides explanation to extract aero into > three work items. > Thats works a lot for me to help reviewing the aero. I still don't feel like I fully understand the three work items, but it was said in the call (maybe by Alper?) that the enhanced anchoring team would be a place to discuss. I think we would find that AERO could also be discussed within the context of the other two teams as well. I think from my talk today people came away with a better understanding of the overall AERO architecture even though the talk and demo focused specifically on the BGP routing system. There was interest in having a more thorough discussion on the list, and I will start a new thread on that soon. Thanks - Fred fred.l.temp...@boeing.com --- From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] Sent: Tuesday, October 07, 2014 2:34 AM To: Templin, Fred L Cc: sarik...@ieee.org; Dapeng Liu; dmm@ietf.org Subject: Re: [DMM] Going forward with the DMM work items Hi Fred, On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L wrote: Hi, > Maybe I can't attend next webex meeting tomorrow. That is too bad, because I will be briefing the AERO BGP routing system at the meeting tomorrow. Yes, sorry to say. I read your proposal, but have not received any indication if you have read my AERO proposal yet. AERO uses BGP in a way that was first specified by RFC6179 in 2011 and carried forward into draft-templin-ironbis and draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of which AERO Client Prefixes (ACPs) are associated with which AERO servers. But, only the Servers are exposed to localized ACP mobility events; the BGP is only updated when an ACP moves to a new Server. This means that there will be very little churn in the BGP rou
Re: [DMM] Going forward with the DMM work items
Hi Fred, On Tue, Oct 7, 2014 at 12:50 AM, Templin, Fred L wrote: > Hi, > > > Maybe I can't attend next webex meeting tomorrow. > > That is too bad, because I will be briefing the AERO BGP routing system at > the meeting tomorrow. > > Yes, sorry to say. > I read your proposal, but have not received any indication if you have > read my AERO proposal yet. AERO uses > BGP in a way that was first specified by RFC6179 in 2011 and carried > forward into draft-templin-ironbis and > draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of > which AERO Client Prefixes (ACPs) > are associated with which AERO servers. But, only the Servers are exposed > to localized ACP mobility events; > the BGP is only updated when an ACP moves to a new Server. This means that > there will be very little churn > in the BGP routing system itself. So, the BGP is not directly exposed to > localized mobility events. > > I know you are the guy who invent ISATAP so I understand you may utilize same mechanism. You and me look big-believer of BGP ecosystem. In my draft, 3gpp defined mobility management is assumed to exist so the mobility management exports BGP mobility information into routing information. Do you assume 3gpp or ietf mobility management protocol/system in your draft as well? Anycast has been widely used in other router discovery solutions. Two cases are 6rd [RFC5969] > and 6to4 [RFC3068]. But, anycast has known operational problems in real > networks, and in fact > has caused major headaches for 6to4 - even to the point that its > deprecation is currently being > called for: > > http://www.ietf.org/mail-archive/web/ipv6/current/msg21248.html > http://www.ietf.org/mail-archive/web/ipv6/current/msg21268.html > > AERO Clients use DNS discovery to discover the address(es) of nearby > Server(s) as the default > means. Other solutions such as manual configuration, DHCP option, etc. are > also possible. > Yes, I know, there are many type of endpoint discovery. Do you clear any patent which claim the right of dns based endpoint discovery? > It would be nice if you were to review the AERO architecture and explain > to me the way in which > this requirement is or is not addressed already there. > Well, will do. I suppose today you provides explanation to extract aero into three work items. Thats works a lot for me to help reviewing the aero. Cheers, --satoru ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Going forward with the DMM work items
Hi Behcet, On Tue, Oct 7, 2014 at 5:33 AM, Behcet Sarikaya wrote: > > I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi > we proposed new approaches like SDN. > > Please don't get me wrong. My position hasn't been changed. BGP is used to forwarding path management signaling. In your draft, XMPP is the protocol that has same role of BGP. Good idea, it is a pub-sub system as same as BGP. You may need to define data model for dmm in i2rs, yang? I don't know which protocol will be adopted as i2rs either xmpp, netconf, or forces. I suppose that you might want to adopt end-system VPN ( https://tools.ietf.org/html/draft-ietf-l3vpn-end-system-03) as its xml data modeling. (actually it is BGP. :-) And, as you may know that there is a draft which mentions about use case of BGP in i2rs. ( http://tools.ietf.org/html/draft-keyupate-i2rs-bgp-usecases) > Having said that I don't think that the charter text on forwarding > path and signaling is talking about the same thing. > > Interesting. What do you expect for the charter text? Why not you ask Marco, Anthony and Alper to explain their thought? > > In DMM fir WiFi we also adopted the anycast discovery, what is wrong with > that? > How do you find the anycast address itself? > > Yes I agree, maybe other techniques like AAA can be worked out. Why > not do it as extensions? > > I suppose that it would be a part of enhanced anchoring work, isn't it? > Really? My thinking was that vEPC does not need any involvement from > MN because the prefix assigned to MN does not change. > > As I mentioned in my more recent mail, I think this item is based on > 2102 solution proposals in which MN had to deal with many prefixes. > > Can you clarify which network nodes need exposure to MN mobility > state? The ones on the path already know MN prefix, right? > > Quite not. I meant disclosing mobility information to network node that likes such as BGP speaker. > So you are saying that these three items gave you some good ideas to > think about on how you can improve your solution, vEPC. > > In my view, the charter items work well to achieve vEPC architecture model, yes. More precisely, as the result of discussions which I had so far with many dmm people, I have noticed some parts which the draft needs more work to achieve the architecture model. > You are indicating that there is a major solution proposal, i.e. vEPC > by you, but that can be improved here and there. > > You are missing the point that such a view point is not yet agreed by the > group. > I know. So I am trying to express my thought, and then we can recognize differences each other, and we can discuss. It's normal process in the ietf I think. > > Without such an agreement on the base, isn't it quite concerning what > the WT's or DT's will do? > > My understanding is that the formation of WT's or DT's is another way > of saying that we don't like all those solutions out there, we will > design our own solutions to the above 3. > I guess wg management, who are responsible to establish dmm standard, expect standardizing dmm solution would be very hard work because they find many variants for it. In that situation, it would be reasonable that they appoint some persons to lead the work. I really appreciate those persons who volunteer to take that role to out consolidated solution. Cheers, --satoru ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Going forward with the DMM work items
Hi Satoru, On Sun, Oct 5, 2014 at 11:19 PM, Satoru Matsushima wrote: > Behcet, and all, > > Maybe I can't attend next webex meeting tomorrow. So let me try to make > clear what I am thinking. Please correct me if I'm wrong to understand the > notion of the next DMM charter. > > 1. Forwarding path and signaling > In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that > wherever mobility management located, existing user-plane control protocol > works fine for forwarding path management with some already proposed > extensions. The important thing is, BGP itself is not mobility management > protocol in the vEPC. The reason for this is because it enables stable > operation, maintained continuously for many advanced use cases, and most > scalable since it supports global Internet routing. But I think that BGP > does not suitable for mobility management. I understand that other people > may have their own choice, of course. I agree that BGP part in vEPC needs rethinking. That's why in DMM WiFi we proposed new approaches like SDN. Having said that I don't think that the charter text on forwarding path and signaling is talking about the same thing. > > 2. Enhanced mobility anchoring > As you may know the vEPC has anycast discovery for EPC-E. It is not a > discovery mechanism actually. As the anycast address is assumed to be > informed from control-plane, which address should be chosen is a matter of > anchor selection policy or algorithm in the mobility management. So I know > that more intelligent anchor selection in the mobility management should be > considered to optimize the path. Anycast would be an operational choice > whether the informed address is assigned to single or multiple routers. In DMM fir WiFi we also adopted the anycast discovery, what is wrong with that? Yes I agree, maybe other techniques like AAA can be worked out. Why not do it as extensions? > > 3. Mobility state exposure > Some people asked me to what entity discloses mobility info mapped into > routes. Yes, vEPC need that entity to achieve the architecture model. Now > that the draft has stated that it is a further study item. We have to study > common way to disclose mobility information regardless the type of mobility > management, which are MIP/PMIP or GTP-C whatever. It may need mobility state > exposure for not only mobile node, but also network node that the charter > has already mentioned. Really? My thinking was that vEPC does not need any involvement from MN because the prefix assigned to MN does not change. As I mentioned in my more recent mail, I think this item is based on 2102 solution proposals in which MN had to deal with many prefixes. Can you clarify which network nodes need exposure to MN mobility state? The ones on the path already know MN prefix, right? > > I support these work items to moving forward. I've found some solutions in > the forwarding path and signaling. But AFAIK, couldn't see the solutions to > apply other two items, but it might be already there. I would like to see > solutions which are clarified into three work items and fill them. I would > be happy to contribute to make things progress. > So you are saying that these three items gave you some good ideas to think about on how you can improve your solution, vEPC. You are indicating that there is a major solution proposal, i.e. vEPC by you, but that can be improved here and there. You are missing the point that such a view point is not yet agreed by the group. Without such an agreement on the base, isn't it quite concerning what the WT's or DT's will do? My understanding is that the formation of WT's or DT's is another way of saying that we don't like all those solutions out there, we will design our own solutions to the above 3. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Going forward with the DMM work items
Hi, > Maybe I can't attend next webex meeting tomorrow. That is too bad, because I will be briefing the AERO BGP routing system at the meeting tomorrow. > So let me try to make clear what I am thinking. Please correct me if I'm > wrong to understand the notion > of the next DMM charter. > 1. Forwarding path and signaling > In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that > wherever mobility management > located, existing user-plane control protocol works fine for forwarding path > > management with some > already proposed extensions. The important thing is, BGP itself is not > mobility management protocol in > the vEPC. The reason for this is because it enables stable operation, > maintained continuously for many > advanced use cases, and most scalable since it supports global Internet > routing. But I think that BGP does > not suitable for mobility management. I understand that other people may have > their own choice, of course. I read your proposal, but have not received any indication if you have read my AERO proposal yet. AERO uses BGP in a way that was first specified by RFC6179 in 2011 and carried forward into draft-templin-ironbis and draft-templin-aerolink. In AERO, BGP allows AERO Relays to keep track of which AERO Client Prefixes (ACPs) are associated with which AERO servers. But, only the Servers are exposed to localized ACP mobility events; the BGP is only updated when an ACP moves to a new Server. This means that there will be very little churn in the BGP routing system itself. So, the BGP is not directly exposed to localized mobility events. > 2. Enhanced mobility anchoring > As you may know the vEPC has anycast discovery for EPC-E. It is not a >discovery mechanism actually. As the > anycast address is assumed to be informed from control-plane, which address > should be chosen is a matter > of anchor selection policy or algorithm in the mobility management. So I know > that more intelligent anchor > selection in the mobility management should be considered to optimize the > path. Anycast would be an > operational choice whether the informed address is assigned to single or > multiple routers. Anycast has been widely used in other router discovery solutions. Two cases are 6rd [RFC5969] and 6to4 [RFC3068]. But, anycast has known operational problems in real networks, and in fact has caused major headaches for 6to4 - even to the point that its deprecation is currently being called for: http://www.ietf.org/mail-archive/web/ipv6/current/msg21248.html http://www.ietf.org/mail-archive/web/ipv6/current/msg21268.html AERO Clients use DNS discovery to discover the address(es) of nearby Server(s) as the default means. Other solutions such as manual configuration, DHCP option, etc. are also possible. > 3. Mobility state exposure > Some people asked me to what entity discloses mobility info mapped into > routes. Yes, vEPC need > that entity to achieve the architecture model. Now that the draft has stated > that it is a further study > item. We have to study common way to disclose mobility information regardless > the type of mobility > management, which are MIP/PMIP or GTP-C whatever. It may need mobility state > exposure for not > only mobile node, but also network node that the charter has already > mentioned. It would be nice if you were to review the AERO architecture and explain to me the way in which this requirement is or is not addressed already there. Thanks - Fred fred.l.temp...@boeing.com From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Sunday, October 05, 2014 9:20 PM To: sarik...@ieee.org Cc: Dapeng Liu; dmm@ietf.org Subject: Re: [DMM] Going forward with the DMM work items Behcet, and all, Maybe I can't attend next webex meeting tomorrow. So let me try to make clear what I am thinking. Please correct me if I'm wrong to understand the notion of the next DMM charter. 1. Forwarding path and signaling In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that wherever mobility management located, existing user-plane control protocol works fine for forwarding path management with some already proposed extensions. The important thing is, BGP itself is not mobility management protocol in the vEPC. The reason for this is because it enables stable operation, maintained continuously for many advanced use cases, and most scalable since it supports global Internet routing. But I think that BGP does not suitable for mobility management. I understand that other people may have their own choice, of course. 2. Enhanced mobility anchoring As you may know the vEPC has anycast discovery for EPC-E. It is not a discovery mechanism actually. As the anycast address is assumed to be informed from control-plane, which address should be chos
Re: [DMM] Going forward with the DMM work items
Behcet, and all, Maybe I can't attend next webex meeting tomorrow. So let me try to make clear what I am thinking. Please correct me if I'm wrong to understand the notion of the next DMM charter. 1. Forwarding path and signaling In fact, my proposal, stateless-uplan for vEPC (aka vEPC), to dmm is that wherever mobility management located, existing user-plane control protocol works fine for forwarding path management with some already proposed extensions. The important thing is, BGP itself is not mobility management protocol in the vEPC. The reason for this is because it enables stable operation, maintained continuously for many advanced use cases, and most scalable since it supports global Internet routing. But I think that BGP does not suitable for mobility management. I understand that other people may have their own choice, of course. 2. Enhanced mobility anchoring As you may know the vEPC has anycast discovery for EPC-E. It is not a discovery mechanism actually. As the anycast address is assumed to be informed from control-plane, which address should be chosen is a matter of anchor selection policy or algorithm in the mobility management. So I know that more intelligent anchor selection in the mobility management should be considered to optimize the path. Anycast would be an operational choice whether the informed address is assigned to single or multiple routers. 3. Mobility state exposure Some people asked me to what entity discloses mobility info mapped into routes. Yes, vEPC need that entity to achieve the architecture model. Now that the draft has stated that it is a further study item. We have to study common way to disclose mobility information regardless the type of mobility management, which are MIP/PMIP or GTP-C whatever. It may need mobility state exposure for not only mobile node, but also network node that the charter has already mentioned. I support these work items to moving forward. I've found some solutions in the forwarding path and signaling. But AFAIK, couldn't see the solutions to apply other two items, but it might be already there. I would like to see solutions which are clarified into three work items and fill them. I would be happy to contribute to make things progress. Cheers, --satoru On Sat, Sep 27, 2014 at 12:14 AM, Behcet Sarikaya wrote: > Hi Jouni, > > I don't see anything in the charter regarding the design teams or > "working teams". I also mentioned this in the list and there was no > objection. > > On what basis you are forming the working teams? > > We currently have many solution drafts and I can not see any of them > dividing the solution as exposing mobility state, enhanced mobility > anchoring or forwarding path and signaling. > > These three items were mentioned by certain people which I believe do > not constitute the consensus in DMM. Yes the charter had those but my > interpretation was it was for the purpose of abstracting the solution > into some pieces. I have never interpreted them to be the requirements > to divide the final DMM protocol like this. > > My question is we do that three four solution drafts and some of them > implemented. > What do we do with them? > > My advice to those colleagues wishing to lead the design teams is to > please come up with your own solution and get into the race with > others. > How come they can get the hat of DT lead and produce something and get > priority over others who worked so hard? > > Regards, > > Behcet > > On Fri, Sep 26, 2014 at 12:51 AM, Jouni Korhonen > wrote: > > Folks, > > > > In the interim call #2 we agreed to form "working teams". We got three > > volunteers to run up those: > > > > o Alper will take care of coordinating "exposing mobility state.." > > o Anthony will take care of coordinating "enhanced mobility anchoring.." > > o Marco will take care of coordinating "forwarding path and signaling.." > > > > The above gentlement will arrange calls for brainstorming that are open > for > > everyone to participate. The process is open - about equivalent to a > design > > team, you just don't need to signup for one. Just keep in mind that it is > > good to concentrate on a limited amount of work items. > > > > 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. > > > > - Jouni & Dapeng > > > > ___ > > 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
Re: [DMM] Going forward with the DMM work items
Hi Behcet, > -Original Message- > From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] > Sent: Wednesday, October 01, 2014 3:18 PM > To: Templin, Fred L > Cc: dmm@ietf.org > Subject: Re: [DMM] Going forward with the DMM work items > > On Wed, Oct 1, 2014 at 3:59 PM, Templin, Fred L > wrote: > > Hi Behcet, > > > >> -Original Message- > >> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] > >> Sent: Wednesday, October 01, 2014 12:51 PM > >> To: Templin, Fred L > >> Cc: dmm@ietf.org > >> Subject: Re: [DMM] Going forward with the DMM work items > >> > >> The point is that the way the charter is being interpreted is > >> we don't need solutions and we won't care if there are some, > >> > >> instead we will build the solution in five-six pieces from zero in DTs. > > > > Yeah, I guess that would be a shame. If people took the time to truly > > understand > > the AERO virtual link model and its applicability to Internet mobility I > > don't think > > there would be a rush to go off and do things in pieces. > > > > But, I am socializing ideas and at least some people seem to be actively > > engaging > > with me. So, I'm not sure where complaining would help further the process. > > > Again I think you are not getting the point. > > I am not sure if there is consensus on this interpretation? OK, I guess the IESG is dwelling on this now as well. > I also have concerns on the division of mobile state, anchoring, etc. > in the charter. > > I think that reflects the thinking from the solution drafts we had in 2012. > Now we are in 2014 and most of those solution drafts (including the > one I had) are no longer being pursued and the thinking has > considerably changed. > There are solutions that are completely network based and require no > mobility state tracking at the UE. > Also in anchoring things have changed. You seem to like solutions, so why not have a look at AERO and see if you can get behind it? AFAICT, it is now truly a comprehensive mobility solution but if I am missing something please let me know. Thanks - Fred fred.l.temp...@boeing.com > So these are my concerns. > > Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Going forward with the DMM work items
On Wed, Oct 1, 2014 at 3:59 PM, Templin, Fred L wrote: > Hi Behcet, > >> -Original Message- >> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] >> Sent: Wednesday, October 01, 2014 12:51 PM >> To: Templin, Fred L >> Cc: dmm@ietf.org >> Subject: Re: [DMM] Going forward with the DMM work items >> >> The point is that the way the charter is being interpreted is >> we don't need solutions and we won't care if there are some, >> >> instead we will build the solution in five-six pieces from zero in DTs. > > Yeah, I guess that would be a shame. If people took the time to truly > understand > the AERO virtual link model and its applicability to Internet mobility I > don't think > there would be a rush to go off and do things in pieces. > > But, I am socializing ideas and at least some people seem to be actively > engaging > with me. So, I'm not sure where complaining would help further the process. Again I think you are not getting the point. I am not sure if there is consensus on this interpretation? I also have concerns on the division of mobile state, anchoring, etc. in the charter. I think that reflects the thinking from the solution drafts we had in 2012. Now we are in 2014 and most of those solution drafts (including the one I had) are no longer being pursued and the thinking has considerably changed. There are solutions that are completely network based and require no mobility state tracking at the UE. Also in anchoring things have changed. So these are my concerns. Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Going forward with the DMM work items
Hi Behcet, > -Original Message- > From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] > Sent: Wednesday, October 01, 2014 12:51 PM > To: Templin, Fred L > Cc: dmm@ietf.org > Subject: Re: [DMM] Going forward with the DMM work items > > The point is that the way the charter is being interpreted is > we don't need solutions and we won't care if there are some, > > instead we will build the solution in five-six pieces from zero in DTs. Yeah, I guess that would be a shame. If people took the time to truly understand the AERO virtual link model and its applicability to Internet mobility I don't think there would be a rush to go off and do things in pieces. But, I am socializing ideas and at least some people seem to be actively engaging with me. So, I'm not sure where complaining would help further the process. Thanks - Fred fred.l.temp...@boeing.com > Behcet > > On Mon, Sep 29, 2014 at 11:34 AM, Templin, Fred L > wrote: > > Hi Behcet, > > > >> -Original Message- > >> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] > >> Sent: Monday, September 29, 2014 8:50 AM > >> To: Templin, Fred L > >> Cc: Brian Haberman; dmm@ietf.org > >> Subject: Re: [DMM] Going forward with the DMM work items > >> > >> Hi Fred, > >> > >> > >> On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L > >> wrote: > >> > Hi Behcet, > >> > > >> >> -Original Message----- > >> >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya > >> >> Sent: Friday, September 26, 2014 12:22 PM > >> >> To: Brian Haberman > >> >> Cc: dmm@ietf.org > >> >> Subject: Re: [DMM] Going forward with the DMM work items > >> >> > >> >> Hi Brian, > >> >> > >> >> You deleted maybe by mistake the first three paragraphs of my previous > >> >> mail. > >> >> > >> >> Let me add to those one more point: > >> >> > >> >> Previously mobility groups in IETF produced single protocols like > >> >> Mobile IP or Proxy Mobile IP. > >> >> These protocols have seen some operator adoption, of course not much > >> >> but some. > >> >> This time we will be asking the operators to adopt exposing mobility > >> >> state protocol, enhanced mobility anchoring protocol and forwarding > >> >> path and signaling protocol (maybe forwarding path protocol and > >> >> signaling protocol)l. > >> >> And maybe deployment models protocol which was in the charter but > >> >> somehow got dropped. > >> >> How is that going to happen? > >> > >> Do you plan to divide your solution into > >> > >> exposing mobility state protocol, > >> enhanced mobility anchoring protocol. > >> forwarding path protocol > >> signaling protocol ? > >> > >> That is the way things are going. > > > > All of these things I think have areas of overlap with aspects > > of the AERO proposal. > > > >> Otherwise you are off track. > > > > I think the best I can do is represent the AERO proposal and speak > > to the areas where there is overlap. I think we have already > > established that AERO solves the tunnel MTU problem and that has > > applicability outside of just AERO. I am also feeding some of my > > correspondent capability discovery ideas to Alper and that again > > has wider applicability. The AERO NBMA model is being discussed > > in relation to the MIP/PMIP point-to-point model. Signaling based > > on plain old DHCPv6 and IPv6ND instead of specialized Mobility > > Headers has also been discussed. > > > > So, maybe I'm not seeing the forest for the trees but if you > > think I am off track what am I supposed to do about it? Complain, > > or continue to conduct a productive investigation as I am already > > doing? > > > >> >> Anyway these are my concerns, I could not attend Interim call #2, I > >> >> believe many people could not including Jouni. > >> > > >> > Jouni was able to attend the call. I was on the call and asked the > >> > question as to whether non-MIPv6/PMIPv6 solutions could be considered > >> > and the answer I got (I think from Jouni) was "possibly". > >> > > >> >> People should speak up, otherwise it appears like it is only my issue. > >> > > >
Re: [DMM] Going forward with the DMM work items
The point is that the way the charter is being interpreted is we don't need solutions and we won't care if there are some, instead we will build the solution in five-six pieces from zero in DTs. Behcet On Mon, Sep 29, 2014 at 11:34 AM, Templin, Fred L wrote: > Hi Behcet, > >> -Original Message- >> From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] >> Sent: Monday, September 29, 2014 8:50 AM >> To: Templin, Fred L >> Cc: Brian Haberman; dmm@ietf.org >> Subject: Re: [DMM] Going forward with the DMM work items >> >> Hi Fred, >> >> >> On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L >> wrote: >> > Hi Behcet, >> > >> >> -Original Message- >> >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya >> >> Sent: Friday, September 26, 2014 12:22 PM >> >> To: Brian Haberman >> >> Cc: dmm@ietf.org >> >> Subject: Re: [DMM] Going forward with the DMM work items >> >> >> >> Hi Brian, >> >> >> >> You deleted maybe by mistake the first three paragraphs of my previous >> >> mail. >> >> >> >> Let me add to those one more point: >> >> >> >> Previously mobility groups in IETF produced single protocols like >> >> Mobile IP or Proxy Mobile IP. >> >> These protocols have seen some operator adoption, of course not much but >> >> some. >> >> This time we will be asking the operators to adopt exposing mobility >> >> state protocol, enhanced mobility anchoring protocol and forwarding >> >> path and signaling protocol (maybe forwarding path protocol and >> >> signaling protocol)l. >> >> And maybe deployment models protocol which was in the charter but >> >> somehow got dropped. >> >> How is that going to happen? >> >> Do you plan to divide your solution into >> >> exposing mobility state protocol, >> enhanced mobility anchoring protocol. >> forwarding path protocol >> signaling protocol ? >> >> That is the way things are going. > > All of these things I think have areas of overlap with aspects > of the AERO proposal. > >> Otherwise you are off track. > > I think the best I can do is represent the AERO proposal and speak > to the areas where there is overlap. I think we have already > established that AERO solves the tunnel MTU problem and that has > applicability outside of just AERO. I am also feeding some of my > correspondent capability discovery ideas to Alper and that again > has wider applicability. The AERO NBMA model is being discussed > in relation to the MIP/PMIP point-to-point model. Signaling based > on plain old DHCPv6 and IPv6ND instead of specialized Mobility > Headers has also been discussed. > > So, maybe I'm not seeing the forest for the trees but if you > think I am off track what am I supposed to do about it? Complain, > or continue to conduct a productive investigation as I am already > doing? > >> >> Anyway these are my concerns, I could not attend Interim call #2, I >> >> believe many people could not including Jouni. >> > >> > Jouni was able to attend the call. I was on the call and asked the >> > question as to whether non-MIPv6/PMIPv6 solutions could be considered >> > and the answer I got (I think from Jouni) was "possibly". >> > >> >> People should speak up, otherwise it appears like it is only my issue. >> > >> > AERO is a solution alternative that I would like to see taken under >> > wider consideration within this domain. I think that is starting to >> > happen through some of the recent list discussions, so others on the >> > list should now be coming aware of it. I also plan to attend IETF91 >> > where I would ask for another AERO presentation timeslot if it would >> > please the wg and the chairs. >> > >> > So, it seems to me that I am already doing all I can. Do you think >> > I should be doing more? >> >> I think you are trying to push your own solution > > I am conducting an investigation. Others have joined me in a friendly > exchange of ideas. Is it the wrong approach? > >> and you think that you are effective in it. > > Which means that you think I am not effective in it? > >> I think DMM should see the big picture and everybody, including Ryuji, >> Satoru and others should speak up. > > Sure, it would be good to hear from them. I have already specified > a BGP-based distributed mobility managem
Re: [DMM] Going forward with the DMM work items
Hi Behcet, > -Original Message- > From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] > Sent: Monday, September 29, 2014 8:50 AM > To: Templin, Fred L > Cc: Brian Haberman; dmm@ietf.org > Subject: Re: [DMM] Going forward with the DMM work items > > Hi Fred, > > > On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L > wrote: > > Hi Behcet, > > > >> -Original Message- > >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya > >> Sent: Friday, September 26, 2014 12:22 PM > >> To: Brian Haberman > >> Cc: dmm@ietf.org > >> Subject: Re: [DMM] Going forward with the DMM work items > >> > >> Hi Brian, > >> > >> You deleted maybe by mistake the first three paragraphs of my previous > >> mail. > >> > >> Let me add to those one more point: > >> > >> Previously mobility groups in IETF produced single protocols like > >> Mobile IP or Proxy Mobile IP. > >> These protocols have seen some operator adoption, of course not much but > >> some. > >> This time we will be asking the operators to adopt exposing mobility > >> state protocol, enhanced mobility anchoring protocol and forwarding > >> path and signaling protocol (maybe forwarding path protocol and > >> signaling protocol)l. > >> And maybe deployment models protocol which was in the charter but > >> somehow got dropped. > >> How is that going to happen? > > Do you plan to divide your solution into > > exposing mobility state protocol, > enhanced mobility anchoring protocol. > forwarding path protocol > signaling protocol ? > > That is the way things are going. All of these things I think have areas of overlap with aspects of the AERO proposal. > Otherwise you are off track. I think the best I can do is represent the AERO proposal and speak to the areas where there is overlap. I think we have already established that AERO solves the tunnel MTU problem and that has applicability outside of just AERO. I am also feeding some of my correspondent capability discovery ideas to Alper and that again has wider applicability. The AERO NBMA model is being discussed in relation to the MIP/PMIP point-to-point model. Signaling based on plain old DHCPv6 and IPv6ND instead of specialized Mobility Headers has also been discussed. So, maybe I'm not seeing the forest for the trees but if you think I am off track what am I supposed to do about it? Complain, or continue to conduct a productive investigation as I am already doing? > >> Anyway these are my concerns, I could not attend Interim call #2, I > >> believe many people could not including Jouni. > > > > Jouni was able to attend the call. I was on the call and asked the > > question as to whether non-MIPv6/PMIPv6 solutions could be considered > > and the answer I got (I think from Jouni) was "possibly". > > > >> People should speak up, otherwise it appears like it is only my issue. > > > > AERO is a solution alternative that I would like to see taken under > > wider consideration within this domain. I think that is starting to > > happen through some of the recent list discussions, so others on the > > list should now be coming aware of it. I also plan to attend IETF91 > > where I would ask for another AERO presentation timeslot if it would > > please the wg and the chairs. > > > > So, it seems to me that I am already doing all I can. Do you think > > I should be doing more? > > I think you are trying to push your own solution I am conducting an investigation. Others have joined me in a friendly exchange of ideas. Is it the wrong approach? > and you think that you are effective in it. Which means that you think I am not effective in it? > I think DMM should see the big picture and everybody, including Ryuji, > Satoru and others should speak up. Sure, it would be good to hear from them. I have already specified a BGP-based distributed mobility management scheme in both the AERO spec and earlier in RFC6179. (I have read their draft; I have no way of knowing whether they have read my documents.) Thanks - Fred fred.l.temp...@boeing.com > Regards, > > Behcet > > > > > Thanks - Fred > > fred.l.temp...@boeing.com > > > >> Regards, > >> > >> Behcet > >> > >> On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman > >> wrote: > >> > > >> > > >> > On 9/26/14 11:14 AM, Behcet Sarikaya wrote: > >> > > >> >> > >> >> My question is we do that three four solution drafts and some of the
Re: [DMM] Going forward with the DMM work items
Hi Fred, On Fri, Sep 26, 2014 at 2:34 PM, Templin, Fred L wrote: > Hi Behcet, > >> -Original Message- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya >> Sent: Friday, September 26, 2014 12:22 PM >> To: Brian Haberman >> Cc: dmm@ietf.org >> Subject: Re: [DMM] Going forward with the DMM work items >> >> Hi Brian, >> >> You deleted maybe by mistake the first three paragraphs of my previous mail. >> >> Let me add to those one more point: >> >> Previously mobility groups in IETF produced single protocols like >> Mobile IP or Proxy Mobile IP. >> These protocols have seen some operator adoption, of course not much but >> some. >> This time we will be asking the operators to adopt exposing mobility >> state protocol, enhanced mobility anchoring protocol and forwarding >> path and signaling protocol (maybe forwarding path protocol and >> signaling protocol)l. >> And maybe deployment models protocol which was in the charter but >> somehow got dropped. >> How is that going to happen? Do you plan to divide your solution into exposing mobility state protocol, enhanced mobility anchoring protocol. forwarding path protocol signaling protocol ? That is the way things are going. Otherwise you are off track. >> >> Anyway these are my concerns, I could not attend Interim call #2, I >> believe many people could not including Jouni. > > Jouni was able to attend the call. I was on the call and asked the > question as to whether non-MIPv6/PMIPv6 solutions could be considered > and the answer I got (I think from Jouni) was "possibly". > >> People should speak up, otherwise it appears like it is only my issue. > > AERO is a solution alternative that I would like to see taken under > wider consideration within this domain. I think that is starting to > happen through some of the recent list discussions, so others on the > list should now be coming aware of it. I also plan to attend IETF91 > where I would ask for another AERO presentation timeslot if it would > please the wg and the chairs. > > So, it seems to me that I am already doing all I can. Do you think > I should be doing more? I think you are trying to push your own solution and you think that you are effective in it. I think DMM should see the big picture and everybody, including Ryuji, Satoru and others should speak up. Regards, Behcet > > Thanks - Fred > fred.l.temp...@boeing.com > >> Regards, >> >> Behcet >> >> On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman >> wrote: >> > >> > >> > On 9/26/14 11:14 AM, Behcet Sarikaya wrote: >> > >> >> >> >> My question is we do that three four solution drafts and some of them >> >> implemented. >> >> What do we do with them? >> > >> > My expectation, as AD, is that the WG will assess the drafts presented >> > by these teams for adoption. People's opinion of those drafts should >> > not be influenced by the fact they were written by a team. >> > >> >> >> >> My advice to those colleagues wishing to lead the design teams is to >> >> please come up with your own solution and get into the race with >> >> others. >> > >> > Race? >> > >> >> How come they can get the hat of DT lead and produce something and get >> >> priority over others who worked so hard? >> > >> > First of all, the chairs are well within their right to appoint DT >> > leads. They could have appointed all the other slots on the DT as well, >> > but chose to ask for volunteers. >> > >> > I do not see anything in Jouni's note that indicates that a team's >> > output gets any preferential treatment. The rules of the IETF prevent >> > that. >> > >> > To re-enforce Jouni's last sentence... >> > >> >>> These documents will be equivalent to any individual produced I-D, >> >>> though. >> > >> > 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
Re: [DMM] Going forward with the DMM work items
Hi Behcet, > -Original Message- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Behcet Sarikaya > Sent: Friday, September 26, 2014 12:22 PM > To: Brian Haberman > Cc: dmm@ietf.org > Subject: Re: [DMM] Going forward with the DMM work items > > Hi Brian, > > You deleted maybe by mistake the first three paragraphs of my previous mail. > > Let me add to those one more point: > > Previously mobility groups in IETF produced single protocols like > Mobile IP or Proxy Mobile IP. > These protocols have seen some operator adoption, of course not much but some. > This time we will be asking the operators to adopt exposing mobility > state protocol, enhanced mobility anchoring protocol and forwarding > path and signaling protocol (maybe forwarding path protocol and > signaling protocol)l. > And maybe deployment models protocol which was in the charter but > somehow got dropped. > How is that going to happen? > > Anyway these are my concerns, I could not attend Interim call #2, I > believe many people could not including Jouni. Jouni was able to attend the call. I was on the call and asked the question as to whether non-MIPv6/PMIPv6 solutions could be considered and the answer I got (I think from Jouni) was "possibly". > People should speak up, otherwise it appears like it is only my issue. AERO is a solution alternative that I would like to see taken under wider consideration within this domain. I think that is starting to happen through some of the recent list discussions, so others on the list should now be coming aware of it. I also plan to attend IETF91 where I would ask for another AERO presentation timeslot if it would please the wg and the chairs. So, it seems to me that I am already doing all I can. Do you think I should be doing more? Thanks - Fred fred.l.temp...@boeing.com > Regards, > > Behcet > > On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman > wrote: > > > > > > On 9/26/14 11:14 AM, Behcet Sarikaya wrote: > > > >> > >> My question is we do that three four solution drafts and some of them > >> implemented. > >> What do we do with them? > > > > My expectation, as AD, is that the WG will assess the drafts presented > > by these teams for adoption. People's opinion of those drafts should > > not be influenced by the fact they were written by a team. > > > >> > >> My advice to those colleagues wishing to lead the design teams is to > >> please come up with your own solution and get into the race with > >> others. > > > > Race? > > > >> How come they can get the hat of DT lead and produce something and get > >> priority over others who worked so hard? > > > > First of all, the chairs are well within their right to appoint DT > > leads. They could have appointed all the other slots on the DT as well, > > but chose to ask for volunteers. > > > > I do not see anything in Jouni's note that indicates that a team's > > output gets any preferential treatment. The rules of the IETF prevent that. > > > > To re-enforce Jouni's last sentence... > > > >>> These documents will be equivalent to any individual produced I-D, though. > > > > 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
Re: [DMM] Going forward with the DMM work items
Hi Brian, You deleted maybe by mistake the first three paragraphs of my previous mail. Let me add to those one more point: Previously mobility groups in IETF produced single protocols like Mobile IP or Proxy Mobile IP. These protocols have seen some operator adoption, of course not much but some. This time we will be asking the operators to adopt exposing mobility state protocol, enhanced mobility anchoring protocol and forwarding path and signaling protocol (maybe forwarding path protocol and signaling protocol)l. And maybe deployment models protocol which was in the charter but somehow got dropped. How is that going to happen? Anyway these are my concerns, I could not attend Interim call #2, I believe many people could not including Jouni. People should speak up, otherwise it appears like it is only my issue. Regards, Behcet On Fri, Sep 26, 2014 at 11:22 AM, Brian Haberman wrote: > > > On 9/26/14 11:14 AM, Behcet Sarikaya wrote: > >> >> My question is we do that three four solution drafts and some of them >> implemented. >> What do we do with them? > > My expectation, as AD, is that the WG will assess the drafts presented > by these teams for adoption. People's opinion of those drafts should > not be influenced by the fact they were written by a team. > >> >> My advice to those colleagues wishing to lead the design teams is to >> please come up with your own solution and get into the race with >> others. > > Race? > >> How come they can get the hat of DT lead and produce something and get >> priority over others who worked so hard? > > First of all, the chairs are well within their right to appoint DT > leads. They could have appointed all the other slots on the DT as well, > but chose to ask for volunteers. > > I do not see anything in Jouni's note that indicates that a team's > output gets any preferential treatment. The rules of the IETF prevent that. > > To re-enforce Jouni's last sentence... > >>> These documents will be equivalent to any individual produced I-D, though. > > 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
Re: [DMM] Going forward with the DMM work items
On 9/26/14 11:14 AM, Behcet Sarikaya wrote: > > My question is we do that three four solution drafts and some of them > implemented. > What do we do with them? My expectation, as AD, is that the WG will assess the drafts presented by these teams for adoption. People's opinion of those drafts should not be influenced by the fact they were written by a team. > > My advice to those colleagues wishing to lead the design teams is to > please come up with your own solution and get into the race with > others. Race? > How come they can get the hat of DT lead and produce something and get > priority over others who worked so hard? First of all, the chairs are well within their right to appoint DT leads. They could have appointed all the other slots on the DT as well, but chose to ask for volunteers. I do not see anything in Jouni's note that indicates that a team's output gets any preferential treatment. The rules of the IETF prevent that. To re-enforce Jouni's last sentence... >> These documents will be equivalent to any individual produced I-D, though. Regards, Brian signature.asc Description: OpenPGP digital signature ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Going forward with the DMM work items
Hi Jouni, I don't see anything in the charter regarding the design teams or "working teams". I also mentioned this in the list and there was no objection. On what basis you are forming the working teams? We currently have many solution drafts and I can not see any of them dividing the solution as exposing mobility state, enhanced mobility anchoring or forwarding path and signaling. These three items were mentioned by certain people which I believe do not constitute the consensus in DMM. Yes the charter had those but my interpretation was it was for the purpose of abstracting the solution into some pieces. I have never interpreted them to be the requirements to divide the final DMM protocol like this. My question is we do that three four solution drafts and some of them implemented. What do we do with them? My advice to those colleagues wishing to lead the design teams is to please come up with your own solution and get into the race with others. How come they can get the hat of DT lead and produce something and get priority over others who worked so hard? Regards, Behcet On Fri, Sep 26, 2014 at 12:51 AM, Jouni Korhonen wrote: > Folks, > > In the interim call #2 we agreed to form "working teams". We got three > volunteers to run up those: > > o Alper will take care of coordinating "exposing mobility state.." > o Anthony will take care of coordinating "enhanced mobility anchoring.." > o Marco will take care of coordinating "forwarding path and signaling.." > > The above gentlement will arrange calls for brainstorming that are open for > everyone to participate. The process is open - about equivalent to a design > team, you just don't need to signup for one. Just keep in mind that it is > good to concentrate on a limited amount of work items. > > 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. > > - Jouni & Dapeng > > ___ > 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] Going forward with the DMM work items
Folks, In the interim call #2 we agreed to form "working teams". We got three volunteers to run up those: o Alper will take care of coordinating "exposing mobility state.." o Anthony will take care of coordinating "enhanced mobility anchoring.." o Marco will take care of coordinating "forwarding path and signaling.." The above gentlement will arrange calls for brainstorming that are open for everyone to participate. The process is open - about equivalent to a design team, you just don't need to signup for one. Just keep in mind that it is good to concentrate on a limited amount of work items. 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. - Jouni & Dapeng ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
