Subject: [netext] Comments & Feedback on the ID: draft-trung-netext-flow-mobility-support-00

From: Tran Minh Trung <[email-masked]>
Date: Mon, 13 Sep 2010 21:48:47 +0900

Hi Rajeev, Julien, Sri  and all,

We have submitted new ID at:
http://datatracker.ietf.org/doc/draft-trung-netext-flow-mobility-support/

Could you check it out and give us your comments?

To support flow mobility, our ID allows PMIPv6 to support
shared-prefix model and flow-based routing.

For supporting shared-prefix model, we recommend the implementations
to extend PMIPv6 in two ways:
-  Proactive signaling: HNP is shared across attachments immediately
when it is assigned to the MN.
-  Re-active signaling: HNP is shared only when a flow using that HNP
is moved to an attachment that the HNP is not valid.

For supporting flow-based routing, we adopt the existing work from
flow binding ID in MEXT WG.

For more detail, Pls. check our new ID at:
http://datatracker.ietf.org/doc/draft-trung-netext-flow-mobility-support/

We appreciate your comments.
Regards,
TrungTM

On Fri, Aug 20, 2010 at 12:09 PM, Rajeev Koodli <[email-masked]> wrote:
>
> This is the essence of what I have been saying:
>
> 1. LMA can assign whatever prefix it chooses upon each attachment
> (already-assigned prefix, a new one, a combination of the two)
> 2. For flow mobility to work, the prefix has to be valid on the
> corresponding MAG
> 3. It is up to the LMA to decide when to signal the prefix (if it is not
> already valid on the MAG in question) - my statement "whenever the LMA
> decides.." in the text I proposed.
>
> So, to answer your question (Reactive vs. Proactive): leave it to the LMA.
> But, we do need to document the implications of *when* we signal the prefix
> to MAGs; e.g., signaling as soon as the MN is assigned a new prefix vs.
> on-demand.
>
> The remaining question in my mind is what is the requirement for a MAG when
> it learns a new prefix? It should advertize it in the RA for ND to work
> correctly? Are we okay without it? Not sure..
>
> -Rajeev
>
>
>
> On 8/19/10 7:22 PM, "Youn-Hee Han" <[email-masked]> wrote:
>
>> Hi Julien and all,
>>
>>>>
>>>> Things are getting complexed... Now, the MN can have multiple logical
>>>> interfaces. If this is the case, just prohibit flow mobility between
>>>> difference logical interfaces such as between IF1 and IF3. This is
>>>> equivalent to non-support of logical interface. This just doesn't work
>>>> and nobody who is rational enough would complain...
>>>>
>>>> Let's try to make it as simple as possible in order to get consensus
>>>> more easily please...
>>>
>>> Agree. As simple as possible is: all prefixes assigned to the mobile node
>>> are signaled to the mobile node's MAG. Then LMA can decides where to route
>>> flow. This is the minimum requirement for network-based flow mobility.
>>>
>>> --julien
>>
>> As I wrote in the previous mails, I also agree with Julien.
>> I'd like to rephrase his comments as follows
>>
>> "All prefixes assigned to an MN are signaled to the *all* MAGs which serve the
>> MN.
>> Then, LMA can decides where to route each flow. This is the minimum
>> requirement
>> for the network-based flow mobility." I like this.
>>
>> But, there is still an issue relevant to the signaling.
>> It can be called "Proactive vs. Reactive Signaling."
>>
>> "Proactive Signaling" means that when LMA assigns a new prefix to MN via an
>> MAG,
>> it proactively signals the prefix to the other all MAGs. "Reactive Signaling"
>> means that LMA signals the new prefix to another (not all) MAG only when a
>> flow
>> is needed to be moved to the MAG which has not the prefix.
>>
>> Which strategy should we select? or... We support both?
>>
>> Youn-Hee Han
>>
>>
>>
>>
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

-- 
Ph.D., Senior Member
Electronics and Telecommunications Research Institute
Standards Research Center
161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
Tel : +82-42-860-1132,   Fax : +82-42-861-5404

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 17 Sep 2010 20:39:37 -0700

Hi Tran:

Thanks for the document and your efforts on this work.

Carlos Bernardos is working on the flow mobility solution spec. He is
consolidating the earlier discussed solution specs into one document. He is
the editor for that document.

I've quickly read your spec and this is overlaps with that work. But, I do
see lot of efforts went into this document, surely some of the work around
BCE extensions, or the notification messages from LMA  ..etc can be
leveraged. I've issues with the support for shared prefix model, there are
technical challenges, other than that the approach of solving mobility at
the granularity of prefixes as what you guys documented is fine with no need
for new options. I agree with this. Currently, we have too much of garbage
in our solution spec, we have to simplify the approaches and support some
basic mobility scenarios, such as flow movement at prefix level, the
presence of natural RA triggers. We need a simple spec. Hopefully, we will
get there.

Please talk to Carlos and the Raj who is shepherding this work as the WG
chair, and possibly see how this work can be leveraged.

Regards
Sri

---

From: Tran Minh Trung <[email-masked]>
Date: Mon, 20 Sep 2010 14:49:16 +0900

Hi Sri,

Thank you for your feedback and agreement. We will talk to Carlos and
the Raj about how to leverage it.
We do hope that we can simplify and  have a simple spec. for
supporting flow mobility in PMIPv6.

By the way, what do you mean when saying "... flow movement at prefix
level, the presence of natural RA triggers"?.
Could you elaborate more about it?.

Regards,
TrungTM

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 20 Sep 2010 09:11:55 -0700

Hi Sri,

Sri Gundavelli wrote:
> consolidating the earlier discussed solution specs into one document.
> He is the editor for that document.

Just to make sure we're all the same page here: Carlos is working on _a_ flow mobility solution specification. The WG has not adopted a specific document yet.
 
> I've quickly read your spec and this is overlaps with that work. But, I
> do see lot of efforts went into this document, surely some of the work
> around BCE extensions, or the notification messages from LMA  ..etc can be
> leveraged. I've issues with the support for shared prefix model, there
> are technical challenges, other than that the approach of solving mobility
> at the granularity of prefixes as what you guys documented is fine with no
> need for new options.

Could you please be more specific as to what are your issues with the support for shared prefix model? 
               
>                           I agree with this. Currently, we have too much of
> garbage in our solution spec, we have to simplify the approaches and support
> some basic mobility scenarios, such as flow movement at prefix level, the
> presence of natural RA triggers. We need a simple spec. Hopefully, we
> will get there.

Isn't the fact that there is "too much garbage in [your] solution spec" a natural outcome of this WG not having a discussion to capture solution requirements that corresponds to the high level "flow mobility" function?

The lack of discussion in that space impairs our ability to do good engineering and is hindering progress. At minimum we need to agree on a common terminology. For example I do not know what "flow movement at prefix level" or "natural RA triggers" mean? Could you please be more specific?
 
> Please talk to Carlos and the Raj who is shepherding this work as the
> WG chair, and possibly see how this work can be leveraged.

At this point I do not understand why you are redirecting Tran to Carlos; this WG has not adopted a specific document. What would be appropriate for now is for participants to this WG to have a discussion on the list on what are "flow mobility" solution requirements. That being done, we can have a debate on what is the best solution fulfilling these requirements.

--julien

---

From: <[email-masked]>
Date: Mon, 20 Sep 2010 18:17:34 +0200

On 9/20/10 11:11 AM, "ext Laganier, Julien" <[email-masked]> wrote:

> Just to make sure we're all the same page here: Carlos is working on _a_ flow
> mobility solution specification. The WG has not adopted a specific document
> yet.
> 

There is no WG adopted I-D specifying flow mobility using PMIP6 yet. I might
however add that we will (may) seek consensus and WG feedback prior to
IETF79 on adopting "an" I-D as the WG baseline.

-Raj

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 20 Sep 2010 09:29:31 -0700

[email-masked] wrote: 
> > Just to make sure we're all the same page here: Carlos is working on
> > _a_ flow mobility solution specification. The WG has not adopted a specific
> > document yet.
> 
> There is no WG adopted I-D specifying flow mobility using PMIP6 yet. I
> might however add that we will (may) seek consensus and WG feedback prior to

IMHO it would be perfectly appropriate to do so after we have a discussion on what are simple solution requirements. Absent that, we will find ourselves in the exact same situation that in Maastricht where there was a push to adopt a solution document that had barely been discussed, and as a result fail to reach rough consensus.

For the sake of getting the discussion we need to have started, maybe one of the co-author of each of the solution on the table could highlight in a short note to the list the requirements that their solution fulfill. Once these have been discussed it will be much easier to get consensus on the solution that best fulfills those. 

--julien

---

From: <[email-masked]>
Date: Mon, 20 Sep 2010 18:35:04 +0200

Hi Julien,

On 9/20/10 11:29 AM, "ext Laganier, Julien" <[email-masked]> wrote:

> IMHO it would be perfectly appropriate to do so after we have a discussion on
> what are simple solution requirements. Absent that, we will find ourselves in
> the exact same situation that in Maastricht where there was a push to adopt a
> solution document that had barely been discussed, and as a result fail to
> reach rough consensus.

Right.. I am hoping to make progress on this work item by having a
discussion on the ML now and not wait to get to Beijing.

> 
> For the sake of getting the discussion we need to have started, maybe one of
> the co-author of each of the solution on the table could highlight in a short
> note to the list the requirements that their solution fulfill. Once these have
> been discussed it will be much easier to get consensus on the solution that
> best fulfills those.

I hope the authors/editors of these I-Ds take note of your suggestion. I
will prod them to initiate such a discussion on the ML ASAP.

-Raj

---

From: "Laganier, Julien" <[email-masked]>
Date: Mon, 20 Sep 2010 09:40:21 -0700

Hi Raj,

[email-masked] 
> >> There is no WG adopted I-D specifying flow mobility using PMIP6 yet.
> >> I might however add that we will (may) seek consensus and WG feedback
> >> prior to IETF79 on adopting "an" I-D as the WG baseline.
> >
> > IMHO it would be perfectly appropriate to do so after we have a
> > discussion on what are simple solution requirements. Absent that, we will 
> > find ourselves in the exact same situation that in Maastricht where there
> > was a push to adopt a solution document that had barely been discussed, and
> > as a result fail to reach rough consensus.
> 

Glad to see we're on the same page.

> > For the sake of getting the discussion we need to have started, maybe
> > one of the co-author of each of the solution on the table could highlight in
> > a short note to the list the requirements that their solution fulfill. Once
> > these have been discussed it will be much easier to get consensus on the
> > solution that best fulfills those.
> 
> I hope the authors/editors of these I-Ds take note of your suggestion.
> I will prod them to initiate such a discussion on the ML ASAP.

Thank you.

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 20 Sep 2010 10:04:06 -0700

Hi Julien:

The latest draft from Carlos (once the authors agree on the text which is
under discussions), should be the basis for review. The key aspects for
review:

1. Supported scenarios
2. Options carried in signaling messages
3. RA management on the MAG-MN link
4. Flow policy assumptions and related aspects, leveraging of MEXT options

Currently, Carlos is working on simplyfing the doc, based on the discussions
between dozen authors, hopefully what you see is a clean and a simple
approach, as what Carlos attempted to present in the meeting. I agree with
you, the earlier doc required lot of work and so he is doing that.

To your specific comments on clarification, #1 should clarify on the flow
mobility approaches. Moving flows at a group level, always the movement of
whole prefix, and also the approach of individual flow movement.

We can let Carlos complete the doc update, and we can pick up the discussion
from there. I'm sure, we will discuss a lot, or there is a good possibility,
you might agree to the whole solution and with no further comments. :)

Regards
Sri

On 9/20/10 9:11 AM, "Laganier, Julien" <[email-masked]> wrote:

> Isn't the fact that there is "too much garbage in [your] solution spec" a
> natural outcome of this WG not having a discussion to capture solution
> requirements that corresponds to the high level "flow mobility" function?
> 
> The lack of discussion in that space impairs our ability to do good
> engineering and is hindering progress. At minimum we need to agree on a common
> terminology. For example I do not know what "flow movement at prefix level" or
> "natural RA triggers" mean? Could you please be more specific?
>  
> At this point I do not understand why you are redirecting Tran to Carlos; this
> WG has not adopted a specific document. What would be appropriate for now is
> for participants to this WG to have a discussion on the list on what are "flow
> mobility" solution requirements. That being done, we can have a debate on what
> is the best solution fulfilling these requirements.
> 
> --julien

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 20 Sep 2010 10:30:42 -0700

> is the best solution fulfilling these requirements.

This is probably a question to the chair. There is an editor who is
consolidating the different solution specs in this space. It can extend to
this doc as well. Off course, one can always challenge the candidate WG doc,
if the solution approaches are different ..

Sri

---

From: <[email-masked]>
Date: Mon, 20 Sep 2010 20:46:33 +0200

> if the solution approaches are different ..

Any WG member is free to propose solutions for the work item which is in the
scope of the charter.
At the present time there is no working group I-D on the flow mobility
topic. There are multiple I-Ds with similarities and differences. It is upto
the authors and WG members to eventually conclude on an I-D and move
forward.

-Raj

And just as an FYI, I will be acting as the only chair w.r.t the flow
mobility topic since Rajeev is a co-author/contributor.