Subject: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 13 Jun 2014 19:16:23 +0200

Hi,

As agreed in London, I've updated the flow mobility draft to include
also the FMI/FMA signaling option (in addition to the use of Update
Notifications). The draft also includes a mechanism to allow selecting
which one of the two signaling mechanisms to use.

In my personal opinion, it'd be much cleaner and simpler to just specify
one signaling mechanism, but this is up to the WG to decide.

Comments, reviews and discussion on this new revision would be welcome.
Hopefully we could get at least a new revision before Toronto.

Thanks,

Carlos

Subject: [netext] I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Date: Fri, 13 Jun 2014 10:12:34 -0700
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF.

        Title           : Proxy Mobile IPv6 Extensions to Support Flow Mobility
        Author          : Carlos J. Bernardos
	Filename        : draft-ietf-netext-pmipv6-flowmob-09.txt
	Pages           : 24
	Date            : 2014-06-13

Abstract:
   Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy
   Mobile IPv6 domain through different interfaces.  This document
   describes extensions to the Proxy Mobile IPv6 protocol that are
   required to support network based flow mobility over multiple
   physical interfaces.

   The extensions described in this document consist on the operations
   performed by the local mobility anchor and the mobile access gateway
   to manage the prefixes assigned to the different interfaces of the
   mobile node, as well as how the forwarding policies are handled by
   the network to ensure consistent flow mobility management.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netext-pmipv6-flowmob/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netext-pmipv6-flowmob-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmipv6-flowmob-09

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
netext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netext

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 19 Jun 2014 13:40:59 +0900

Hello Carlos,

Thanks for updating the draft.
I have a couple of questions and comments:

o In Section 3.2.1, which is the shared prefix case, there is no message
exchange between the LMA and MAG, so there is no flow information on the
MAG side. It should work in the sense of routing, but if, for example,
each flow has a specific QoS, the MAG should also need to know which
flow should go on which QoS path especially for upstream traffic towards
the LMA. Or, the MAG may want to send a trigger for flow mobility to the
MN (the exact mechanism is out of scope). Some mobility signaling should
be there, too.

o In Section 3.3, FMI/FMA are revived considering the case where UPN is
not supported, but they convey very little information. There is no
special information that cannot be conveyed by the existing messages.
Since RFC7077 is now a proposed standard, I cannot think of a situation
where the UPN/UPA are not supported, nevertheless FMI/FMA are
supported.It rather seems more natural to mandate the support of RFC7077
or to mandate FMI/FMA for all flow mobility operations.
Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
convey different set of parameters in Figure 7. Could you clarify it a
little bit more please?

o In Section 3.3, just above Figure 7, there is a description: "..., and
the type of flow mobility operation (add flow)", but does RFC6089 define
such an operation code? This kind of operation should also be defined in
the draft.

Regards,

-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[email-masked]

---

From: <[email-masked]>
Date: Thu, 19 Jun 2014 08:32:21 +0000

Hi Hidetoshi/all,

Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London, we have decided (group consensus) to reintroduce FMI/FMA to avoid dependency between RFC. Now, it's true that introducing 2 options for message format makes the solution more complex for little added-value (no major differences between messages)... So, maybe the question is "is it good or bad to have RFC dependency?" then update the draft according the answer...

Pierrick

De : netext [mailto:[email-masked]] De la part de Hidetoshi Yokota
Envoyé : jeudi 19 juin 2014 06:41
À : [email-masked]
Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

Hello Carlos,

o In Section 3.2.1, which is the shared prefix case, there is no message exchange between the LMA and MAG, so there is no flow information on the MAG side. It should work in the sense of routing, but if, for example, each flow has a specific QoS, the MAG should also need to know which flow should go on which QoS path especially for upstream traffic towards the LMA. Or, the MAG may want to send a trigger for flow mobility to the MN (the exact mechanism is out of scope).  Some mobility signaling should be there, too.

o In Section 3.3, FMI/FMA are revived considering the case where UPN is not supported, but they convey very little information. There is no special information that cannot be conveyed by the existing messages. Since RFC7077 is now a proposed standard, I cannot think of a situation where the UPN/UPA are not supported, nevertheless FMI/FMA are supported. It rather seems more natural to mandate the support of RFC7077 or to mandate FMI/FMA for all flow mobility operations.
Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey different set of parameters in Figure 7. Could you clarify it a little bit more please?

o In Section 3.3, just above Figure 7, there is a description: "..., and the type of flow mobility operation (add flow)", but does RFC6089 define such an operation code? This kind of operation should also be defined in the draft.

Regards,

--

Hidetoshi Yokota

e-mail:[email-masked]<mailto:e-mail:[email-masked]>

(2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:

Hi,

Thanks,

Carlos

netext mailing list

[email-masked]<mailto:[email-masked]>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Jun 2014 13:46:06 +0000

Hi Pierrick,

After the NETEXT meeting in London, we had some offline discussions with Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging format for FMI/FMA. So, the Flow Mobility spec may refer to this message as FMI/FMA, but the underneath messaging format will confirm to RFC-7077 format and will have references to RFC-7077. We are not going to define a new MH message. This closes the key issue of using two notification approaches in the same spec. AFAIK, no one has any objection to this. If any does, its now time to speak up :)

Regards
Sri

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 19, 2014 1:32 AM
To: Hidetoshi Yokota <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

Hi Hidetoshi/all,

Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London, we have decided (group consensus) to reintroduce FMI/FMA to avoid dependency between RFC. Now, it’s true that introducing 2 options for message format makes the solution more complex for little added-value (no major differences between messages)… So, maybe the question is “is it good or bad to have RFC dependency?” then update the draft according the answer...

Pierrick

De : netext [mailto:[email-masked]] De la part de Hidetoshi Yokota
Envoyé : jeudi 19 juin 2014 06:41
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

Hello Carlos,

Regards,

--

Hidetoshi Yokota

Hi,

Thanks,

Carlos

netext mailing list

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 19 Jun 2014 19:36:46 +0200

Hi Hidetoshi,

Thanks for your comments. Please see inline below.

On Thu, 2014-06-19 at 13:40 +0900, Hidetoshi Yokota wrote:
> o In Section 3.2.1, which is the shared prefix case, there is no
> message exchange between the LMA and MAG, so there is no flow
> information on the MAG side. It should work in the sense of routing,
> but if, for example, each flow has a specific QoS, the MAG should also
> need to know which flow should go on which QoS path especially for
> upstream traffic towards the LMA. Or, the MAG may want to send a
> trigger for flow mobility to the MN (the exact mechanism is out of
> scope).  Some mobility signaling should be there, too.

[Carlos] There was a discussion on this in the past (don't remember
exactly when, but I recall that Rajeev was one of the drivers) and the
group decision was to make the signaling at the prefix level, not at
flow level. If the group think there is value on supporting
flow-granularity signaling, we could add it.

> 
> o In Section 3.3, FMI/FMA are revived considering the case where UPN
> is not supported, but they convey very little information. There is no
> Since RFC7077 is now a proposed standard, I cannot think of a
> situation where the UPN/UPA are not supported, nevertheless FMI/FMA
> are supported. It rather seems more natural to mandate the support of
> RFC7077 or to mandate FMI/FMA for all flow mobility operations.

[Carlos] As Pierrick has already replied to you, there was discussion in
London about supporting both mechanisms. I think this deserves another
thread on the mailing list devoted to that discussion. As I expressed in
a previous e-mail, my personal opinion as WG member is that we should go
for just one signaling mechanism (being UPN/UPA my preference), but here
I'm acting as the editor of the document and I just updated the document
to reflect the consensus of the room in London.

> o In Section 3.3, just above Figure 7, there is a description: "...,
> and the type of flow mobility operation (add flow)", but does RFC6089
> define such an operation code? This kind of operation should also be
> defined in the draft.

[Carlos] By "add", a lifetime higher than 0 is meant (as 0 means
"remove"). I agree this should be clarified in the document. Thanks for
the comment.

Once again, thanks for your comments!

Carlos

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Jun 2014 18:09:13 +0000

Hi Carlos/All,

Can we plan to close this work in the next few days. AFAIK, this FMI/FMA issue is now resolved. If you still doubt the consensus on this issue, we can wait for 2 days for any comments and post the next rev.

I'm hoping we will close this work this week and go LC on Monday (if chairs agree). Waiting for Toronto meeting can delay the work by another few months.

Regards
Sri

From: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Thursday, June 19, 2014 6:46 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hidetoshi Yokota <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

Hi Pierrick,

Regards
Sri

Hi Hidetoshi/all,

Pierrick

Hello Carlos,

Regards,

--

Hidetoshi Yokota

Hi,

Thanks,

Carlos

netext mailing list

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 19 Jun 2014 17:52:53 -0500

On Thu, Jun 19, 2014 at 1:09 PM, Sri Gundavelli (sgundave)
<[email-masked]> wrote:
> Hi Carlos/All,
>
> Can we plan to close this work in the next few days. AFAIK, this FMI/FMA
> issue is now resolved. If you still doubt the consensus on this issue, we
> can wait for 2 days for any comments and post the next rev.
>

This draft is in no way close WG LC.

At the outset Raj has set out very clearly the direction for this work
in his mail way back on March 3, 2011
http://www.ietf.org/mail-archive/web/netext/current/msg01839.html

Quote
Flow mobility in the context of Proxy MIP6 is the switching of a flow
by the LMA from MAGx to MAGy when the MN is attached to the LMA via multiple
interfaces through different MAGs. The LMA makes the decision to move
a flow based on some policy.
Unquote

No mention of LMA-initiated flow mobility can be found in this draft.
Use case scenario 1, common set of prefixes is not feasible.
MN can get different prefixes even on a single interface, what is the
point of considering same prefix on all interfaces?

If we remove Use Case 1 then there are no use cases.

This draft needs to be reworked.

Regards,

Behcet

> I'm hoping we will close this work this week and go LC on Monday (if chairs
> agree). Waiting for Toronto meeting can delay the work by another few
> months.
>
>
> Regards
> Sri
>
> From: Sri Gundavelli <[email-masked]>
> To: "[email-masked]" <[email-masked]>, Hidetoshi
> Yokota <[email-masked]>, "[email-masked]" <[email-masked]>
>
> After the NETEXT meeting in London, we had some offline discussions with
> Rajiv and folks. There is agreement to use the RFC-7077 (UPN) messaging
> format for FMI/FMA. So, the Flow Mobility spec may refer to this message as
> FMI/FMA, but the underneath messaging format will confirm to RFC-7077 format
> and will have references to RFC-7077. We are not going to define a new MH
> message. This closes the key issue of using two notification approaches in
> the same spec. AFAIK, no one has any objection to this. If any does, its now
> time to speak up :)
>
> Regards
> Sri
>
>
> From: "[email-masked]" <[email-masked]>
> To: Hidetoshi Yokota <[email-masked]>, "[email-masked]"
> <[email-masked]>
> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London, we
> have decided (group consensus) to reintroduce FMI/FMA to avoid dependency
> between RFC. Now, it’s true that introducing 2 options for message format
> makes the solution more complex for little added-value (no major differences
> between messages)… So, maybe the question is “is it good or bad to have RFC
> dependency?” then update the draft according the answer...
>
>
>
> Pierrick
>
>
>
> exchange between the LMA and MAG, so there is no flow information on the MAG
> side. It should work in the sense of routing, but if, for example, each flow
> has a specific QoS, the MAG should also need to know which flow should go on
> which QoS path especially for upstream traffic towards the LMA. Or, the MAG
> may want to send a trigger for flow mobility to the MN (the exact mechanism
> is out of scope).  Some mobility signaling should be there, too.
>
> o In Section 3.3, FMI/FMA are revived considering the case where UPN is not
> supported, but they convey very little information. There is no special
> information that cannot be conveyed by the existing messages. Since RFC7077
> is now a proposed standard, I cannot think of a situation where the UPN/UPA
> are not supported, nevertheless FMI/FMA are supported. It rather seems more
> natural to mandate the support of RFC7077 or to mandate FMI/FMA for all flow
> mobility operations.
> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to convey
> different set of parameters in Figure 7. Could you clarify it a little bit
> more please?
>
> o In Section 3.3, just above Figure 7, there is a description: "..., and the
> type of flow mobility operation (add flow)", but does RFC6089 define such an
> operation code? This kind of operation should also be defined in the draft.
>
> Regards,
>
> --
>
> Hidetoshi Yokota
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 19 Jun 2014 23:11:20 +0000

Behcet,

> This draft is in no way close WG LC.

That has been just your comment since day-1. AFAIK, no one in the WG is
able to understand the technical issue you are raising, other than these
vague comments. 

If you see a technical issue, explain it, challenge us and we are up for
it. If you cannot, park the issue and its time to move forward.

FWIW, Suresh, when chairing the WG in one of the meetings did a poll in
the room and no one agreed with your views. So, its time to move on ..

Sri

On 6/19/14 3:52 PM, "Behcet Sarikaya" <[email-masked]> wrote:

>> between RFC. Now, it¹s true that introducing 2 options for message
>>format
>> between messages)Š So, maybe the question is ³is it good or bad to have
>>RFC
>> dependency?² then update the draft according the answer...
>>
>>
>>
>> Pierrick
>>
>>
>>
>>not
>>convey
>>and the
>>_________________________________________________________________________
>>________________________________________________
>>
>> Orange decline toute responsabilite si ce message a ete altere, deforme
>>ou
>> falsifie. Merci.
>>
>> As emails may be altered, Orange is not liable for messages that have
>>been
>> modified, changed or falsified.
>> Thank you.
>>
>>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sun, 22 Jun 2014 09:46:55 +0900

Hi Carlos,

Thanks for your response and the discussion is getting more active 
towards the WGLC!

Please see inline:

> flow-granularity signaling, we could add it.

Flow movement at the prefix level is ok, but the new MAG needs to know 
which flow(s) is/are coming within that prefix to link it/them to proper 
QoS path(s) and optionally to inform the MN about it. Actual use cases 
would require more than just routing.

> to reflect the consensus of the room in London.

I see, but Sri has a different view on it. Let's discuss it on the ML. I 
also prefer to stick to one set of signaling messages.

> "remove"). I agree this should be clarified in the document. Thanks for

Not only clarifying the text, but also more explicit mobility operation 
commands such as "add" or "remove" should be defined rather than using 
the lifetime value. This would be more true if the flow movement is at 
the prefix level; you don't want to lose all flows with the same prefix 
by setting the lifetime value to zero for removing just one flow. Please 
take it into consideration.

Regards,

-- 
Hidetoshi Yokota

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Jun 2014 12:37:36 -0700

Yes, but just to be clear: The Flow Mobility ID defines FMI/FMA messages
which use the same format as UPN with the new Code values.

-Rajeev

On Thu, Jun 19, 2014 at 6:46 AM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> FMI/FMA, but the underneath messaging format will confirm to RFC-7077
> format and will have references to RFC-7077. We are not going to define a
> new MH message. This closes the key issue of using two notification
> approaches in the same spec. AFAIK, no one has any objection to this. If
> any does, its now time to speak up :)
>
>  Regards
> Sri
>
>
> To: Hidetoshi Yokota <[email-masked]>, "[email-masked]" <
> [email-masked]>
> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in London,
> we have decided (group consensus) to reintroduce FMI/FMA to avoid
> dependency between RFC. Now, it’s true that introducing 2 options for
> message format makes the solution more complex for little added-value (no
> major differences between messages)… So, maybe the question is “is it good
> or bad to have RFC dependency?” then update the draft according the
> answer...
>
>
>
> Pierrick
>
>
>
> *De :* netext [mailto:[email-masked] <[email-masked]>] *De
> la part de* Hidetoshi Yokota
> *Envoyé :* jeudi 19 juin 2014 06:41
> *À :* [email-masked]
> *Objet :* Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
>
>
>
> Hello Carlos,
>
> MAG side. It should work in the sense of routing, but if, for example, each
> flow has a specific QoS, the MAG should also need to know which flow should
> go on which QoS path especially for upstream traffic towards the LMA. Or,
> the MAG may want to send a trigger for flow mobility to the MN (the exact
> mechanism is out of scope).  Some mobility signaling should be there, too.
>
> not supported, but they convey very little information. There is no special
> natural to mandate the support of RFC7077 or to mandate FMI/FMA for all
> flow mobility operations.

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 25 Jun 2014 09:02:28 +0900

Hi Rajeev,

"New Code" values mean new MH Types or different ones? If your intention
is to define new MH types with exactly the same format as UPN/UPA, then
it would be better to define a new flag or notification reason in UPN/UPA.

Regards,
--
Hidetoshi

(2014/06/24 4:37), Rajeev Koodli wrote:
>
> Yes, but just to be clear: The Flow Mobility ID defines FMI/FMA
> messages which use the same format as UPN with the new Code values.
>
> -Rajeev
>
>
>
> On Thu, Jun 19, 2014 at 6:46 AM, Sri Gundavelli (sgundave)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Pierrick,
>
>     After the NETEXT meeting in London, we had some offline
>     discussions with Rajiv and folks. There is agreement to use the
>     RFC-7077 (UPN) messaging format for FMI/FMA. So, the Flow Mobility
>     spec may refer to this message as FMI/FMA, but the underneath
>     messaging format will confirm to RFC-7077 format and will have
>     references to RFC-7077. We are not going to define a new MH
>     message. This closes the key issue of using two notification
>     approaches in the same spec. AFAIK, no one has any objection to
>     this. If any does, its now time to speak up :)
>
>     Regards
>     Sri
>
>
>     From: "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     To: Hidetoshi Yokota <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     Release -08 mandates RFC7077 and the doc was good, IMHO. But, in
>     London, we have decided (group consensus) to reintroduce FMI/FMA
>     to avoid dependency between RFC. Now, it’s true that introducing 2
>     options for message format makes the solution more complex for
>     little added-value (no major differences between messages)… So,
>     maybe the question is “is it good or bad to have RFC dependency?”
>     then update the draft according the answer...
>
>     Pierrick
>
>     *De :*netext [mailto:[email-masked]] *De la part de*
>     Hidetoshi Yokota
>     *Envoye' :* jeudi 19 juin 2014 06:41
>     *A` :* [email-masked] <mailto:[email-masked]>
>     information on the MAG side. It should work in the sense of
>     routing, but if, for example, each flow has a specific QoS, the
>     MAG should also need to know which flow should go on which QoS
>     path especially for upstream traffic towards the LMA. Or, the MAG
>     may want to send a trigger for flow mobility to the MN (the exact
>     o In Section 3.3, FMI/FMA are revived considering the case where
>     UPN is not supported, but they convey very little information.
>     There is no special information that cannot be conveyed by the
>     existing messages. Since RFC7077 is now a proposed standard, I
>     cannot think of a situation where the UPN/UPA are not supported,
>     nevertheless FMI/FMA are supported. It rather seems more natural
>     to mandate the support of RFC7077 or to mandate FMI/FMA for all
>     convey different set of parameters in Figure 7. Could you clarify
>     it a little bit more please?
>
>     o In Section 3.3, just above Figure 7, there is a description:
>     "..., and the type of flow mobility operation (add flow)", but
>     does RFC6089 define such an operation code? This kind of operation
>     should also be defined in the draft.
>
>     Regards,
>
>     -- 
>
>     Hidetoshi Yokota
>
>      
>
>     e-mail:[email-masked] <mailto:e-mail:[email-masked]>
>
>         [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 25 Jun 2014 19:51:23 +0200

Hi Hidetoshi,

On Sun, 2014-06-22 at 09:46 +0900, Hidetoshi Yokota wrote:
> which flow(s) is/are coming within that prefix to link it/them to
> proper QoS path(s) and optionally to inform the MN about it. Actual
> use cases would require more than just routing.

Yes, I see your point here, as this was originally discussed. I'd like
to know what the feeling of the WG on this matter.
> I see, but Sri has a different view on it. Let's discuss it on the ML.
> I also prefer to stick to one set of signaling messages.

Based on the discussion, I'm going to send an updated version with just
one set of signaling messages (either later today or tomorrow).
> Not only clarifying the text, but also more explicit mobility
> operation commands such as "add" or "remove" should be defined rather
> than using the lifetime value. This would be more true if the flow
> movement is at the prefix level; you don't want to lose all flows with
> the same prefix by setting the lifetime value to zero for removing
> just one flow. Please take it into consideration.

Let's go back to this once we have the new version with one single
signaling mechanism.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 26 Jun 2014 00:05:21 +0200

Hi,

I've just posted -10, now including only one single signaling
mechanisms, as discussed on the ML.

I think this version is ready for WGLC.

Carlos

On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote:
> Hi Carlos/All,
> 
> 
> Can we plan to close this work in the next few days. AFAIK, this
> FMI/FMA issue is now resolved. If you still doubt the consensus on
> this issue, we can wait for 2 days for any comments and post the next
> rev.
> 
> 
> I'm hoping we will close this work this week and go LC on Monday (if
> chairs agree). Waiting for Toronto meeting can delay the work by
> another few months.
> 
> 
> 
> 
> Regards
> Sri
> 
> 
> After the NETEXT meeting in London, we had some offline discussions
> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN)
> messaging format for FMI/FMA. So, the Flow Mobility spec may refer to
> this message as FMI/FMA, but the underneath messaging format will
> confirm to RFC-7077 format and will have references to RFC-7077. We
> are not going to define a new MH message. This closes the key issue of
> using two notification approaches in the same spec. AFAIK, no one has
> any objection to this. If any does, its now time to speak up :)
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> London, we have decided (group consensus) to reintroduce FMI/FMA to
> avoid dependency between RFC. Now, it’s true that introducing 2
> options for message format makes the solution more complex for little
> added-value (no major differences between messages)… So, maybe the
> question is “is it good or bad to have RFC dependency?” then update
> the draft according the answer...
> 
>  
> 
> Pierrick
> 
>  
>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Sun, 29 Jun 2014 22:32:14 +0900

Hi Carlos,

I briefly reviewed the updated draft and have a couple of comments.

o The messages named as FMI/FMA in this document are actually UPN/UPA, 
so the description is confusing since it looks as if new messages were 
defined. I would propose a new flag or notification reason/status code 
to indicate that UPN/UPA are used for flow mobility.

o In the previous version, FMI could convey the Flow ID mobility option, 
but the latest version can convey only HNPs. This looks like a 
degradation and I'm not sure how both LMA and MAG can share the same 
flow mobility cache.

o The flow mobility operation such as "add" or "remove" should be able 
to specify the targeted flow. To this end, the Flow ID mobility option 
in RFC6089 should be used. The flow binding action sub-option defined in 
RFC7109 can be used for the flow mobility operation.

Please take these points into consideration.

Regards,
--
Hidetoshi