Re: [DMM] rechartering
Hi Jouni, all, let me pick up some comments again, which we should clarify. About anchor selection: Referring to the milestones, having the anchor re-selection document separated from the advanced anchor selection only by 3 months does not seem to be useful, even if you consider re-selection to be used only for advanced DMM deployment and operation, whereas basic anchor selection is required for any DMM deployment with decentralized data plane anchors. I understand this document treats solely selection and runtime re-selection, not the associated establishment of routing/tunnel states according to the selected anchor. So, I think both aspects, selection and re-selection, should go into a single document. Unless the WG decides that re-selection is too advanced, then it may go into a separate document when the base selection spec is almost ready, as it will depend on it. About forwarding path and signaling management: In particular if the support of runtime/mid-session anchor change is considered for the first set of DMM solution documents, the described work item about 'forwarding path and signaling management' should be given a milestone, as this is essential if anchors are changed mid-session and IP address continuation is expected. So far there is no document about this work item in the charter list. Inter-working between mobility functions and network nodes, e.g. routers, requires the use of some non-mobility protocol. DMM should at least describe which states (identifiers, locator addresses/IDs, ..) to expose through these protocols. That's what I understood behind mobility state exposure, whereas the text in the work items list reads more like this is about announcements from the network to an MN about the characteristics of an IP address to support the MN in picking the right address for an application. I know it's more a terms issue, but we need clarification what we expect from a work item. Hope the above makes sense and we can easily clarify. marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen Sent: Dienstag, 27. Mai 2014 10:51 To: dmm@ietf.org Subject: Re: [DMM] rechartering Now that the gap analysis I-D is almost on the stage of leaving the WG and the requirements I-D has almost completed IESG, it would be time to return to the rechartering topic. First, the latest revision can be found at: https://github.com/jounikor/dmm-re-charter Second, have a look at it. There are few changes proposed by Alper eons ago and corrected milestones pointed by Behcet. Third, let us get this finally done.. - Jouni 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: Folks, Sorry for letting this topic to rot in a dark for the couple of last weeks. I'll crank out a revision shortly.. - 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
Re: [DMM] rechartering
Marco, 5/28/2014 3:35 PM, Marco Liebsch kirjoitti: Hi Jouni, all, let me pick up some comments again, which we should clarify. About anchor selection: Referring to the milestones, having the anchor re-selection document separated from the advanced anchor selection only by 3 months does not seem to be useful, even if you consider re-selection to be used only for advanced DMM deployment and operation, whereas basic anchor selection is required for any DMM deployment with decentralized data plane anchors. I understand this document treats solely selection and runtime re-selection, not the associated establishment of routing/tunnel states according to the Actually, I was in an opinion that re-selection would also cover the needed parts for possible re-routing of traffic.. whatever the mechanisms is. Does anyone else share the same view? selected anchor. So, I think both aspects, selection and re-selection, should go into a single document. Unless the WG decides that re-selection is too advanced, then it may go into a separate document when the base selection spec is almost ready, as it will depend on it. About forwarding path and signaling management: In particular if the support of runtime/mid-session anchor change is considered for the first set of DMM solution documents, the described work item about 'forwarding path and signaling management' should be given a milestone, as this is essential if anchors are changed mid-session and IP address continuation is expected. So far there is no document about this work item in the charter list. Right, any suggestions for the actual document name and time lines? Inter-working between mobility functions and network nodes, e.g. routers, requires the use of some non-mobility protocol. DMM should at least describe which states (identifiers, locator addresses/IDs, ..) to expose through these protocols. That's what I understood behind mobility state exposure, whereas the text in the work items list reads more like this is about announcements from the network to an MN about the characteristics of an IP address to support the MN in picking the right address for an application. I know it's more a terms issue, but we need clarification what we expect from a work item. The latter is what I had in mind.. mainly the MN-network communication. Hope the above makes sense and we can easily clarify. Sure. - Jouni marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen Sent: Dienstag, 27. Mai 2014 10:51 To: dmm@ietf.org Subject: Re: [DMM] rechartering Now that the gap analysis I-D is almost on the stage of leaving the WG and the requirements I-D has almost completed IESG, it would be time to return to the rechartering topic. First, the latest revision can be found at: https://github.com/jounikor/dmm-re-charter Second, have a look at it. There are few changes proposed by Alper eons ago and corrected milestones pointed by Behcet. Third, let us get this finally done.. - Jouni 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: Folks, Sorry for letting this topic to rot in a dark for the couple of last weeks. I'll crank out a revision shortly.. - 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
Re: [DMM] rechartering
Inter-working between mobility functions and network nodes, e.g. routers, requires the use of some non-mobility protocol. DMM should at least describe which states (identifiers, locator addresses/IDs, ..) to expose through these protocols. That's what I understood behind mobility state exposure, whereas the text in the work items list reads more like this is about announcements from the network to an MN about the characteristics of an IP address to support the MN in picking the right address for an application. I know it's more a terms issue, but we need clarification what we expect from a work item. The latter is what I had in mind.. mainly the MN-network communication. Plus, the interaction between the apps and the IP stack on the MN. Alper Hope the above makes sense and we can easily clarify. Sure. - Jouni marco -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Jouni Korhonen Sent: Dienstag, 27. Mai 2014 10:51 To: dmm@ietf.org Subject: Re: [DMM] rechartering Now that the gap analysis I-D is almost on the stage of leaving the WG and the requirements I-D has almost completed IESG, it would be time to return to the rechartering topic. First, the latest revision can be found at: https://github.com/jounikor/dmm-re-charter Second, have a look at it. There are few changes proposed by Alper eons ago and corrected milestones pointed by Behcet. Third, let us get this finally done.. - Jouni 4/22/2014 3:55 PM, Jouni Korhonen kirjoitti: Folks, Sorry for letting this topic to rot in a dark for the couple of last weeks. I'll crank out a revision shortly.. - 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
