Subject: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00

From: Tran Minh Trung <[email-masked]>
Date: Tue, 20 Jul 2010 17:44:10 +0900

Hi Bernardos and all,

I have some comments and questions on the I-D
draft-bernardos-netext-pmipv6-flowmob-00 as follows:

1) I think the LMA can decide to move down-link flows only. The
up-link flows should be moved by the MN (eg. the MN is aware of the
attachment status via each IF and decide which IF is better for
sending up-link flows). The MAG should be aware of the movement of
up-link flows and inform the LMA to update information.

2) It is necessary to discuss about the flow mobility triggers. The
signaling procedure between MAG/LMA depends on trigger. With different
kind of trigger we have to use different signaling procedure.

3) The proposed solution requires new signaling messages and new
caching table. It makes more complicated for implementing and
combining with the existing standard than just extending the current
PBU/PBA messages as well as BCE and BULE caching table.

4) What are the necessary requirements of the logical interface to
support flow mobility?

I hope that we can have more discussion on these issues before making
it as a WG document.

Regards,
Tran Minh Trung

-- 
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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 20 Jul 2010 18:06:36 +0200

Hi Tran Minh,

> draft-bernardos-netext-pmipv6-flowmob-00 as follows:

Thanks a lot for the feedback. Please see some comments inline below.

> sending up-link flows). The MAG should be aware of the movement of

Our assumption is that the MN does implement the logical interface (as
explained in draft-melia-netext-logical-interface-support-01). The LMA
has of course the direct control of how downlink flows are routed, but
an MN implementing the logical interface will just mirror that behavior
with the uplink packets. Therefore, the LMA is the only entity
controlling flow mobility both in downlink and uplink directions.

> up-link flows and inform the LMA to update information.

In the current draft, the MAG is informed about flow mobility operations
by the LMA. There is signaling defined for that purpose.

> kind of trigger we have to use different signaling procedure.

The trigger is out of the scope of the solution draft. Any kind of
trigger could be supported. For example a central policy entity can make
the decisions based on the overall state of the network and trigger the
LMA. IMHO, which entity triggers the LMA can be left out of the scope,
as it does not have an impact on the protocol (with current design).

> PBU/PBA messages as well as BCE and BULE caching table.

Well, this was a design decision (there might be of course others). We
preferred not to overload existing signaling. Regarding the data
structures, they are just logical ones, they could also even be
implemented by extending BCE and BUL.

> 4) What are the necessary requirements of the logical interface to

This should be covered by
draft-melia-netext-logical-interface-support-01.

> I hope that we can have more discussion on these issues before making

Sure, useful discussion as this is very very welcome. Thanks!

Kind Regards,

Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Jul 2010 09:32:01 -0700

Hi Carlos,

One question below -

Carlos Jesús Bernardos Cano wrote:
> In the current draft, the MAG is informed about flow mobility
> operations by the LMA. There is signaling defined for that purpose.

Why does the LMA needs to inform the MAG about flow mobility operations?

It seems to me that these operations are essentially transparent to the MAG and thus the MAG needs not to be involved at all in flow mobility: The LMA decides where to send downlink packets, and the MN mirrors that behavior for uplink packet (as described in the logical interface draft.)

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 20 Jul 2010 19:22:39 +0200

Hi Julien,

> It seems to me that these operations are essentially transparent to the MAG and thus the MAG needs not to be involved at all in flow mobility: The LMA decides where to send downlink packets, and th…

Well, there are two scenarios. If the MN is assigned the same of
prefixes across the different physical interfaces that belong to the
logical interface, you are right that this signaling can be avoided
(this is actually pointed out in the draft), as there is nothing else to
be added at the MAG. However, if the MN gets different prefixes at each
physical interface, then we need to signal the MAG, so it knows how to
route packets downlink (and also to prevent potential ingress filtering
in the uplink).

Carlos

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Jul 2010 12:06:13 -0700

Hi Carlos,

Carlos Jesús Bernardos Cano wrote:
> > > > up-link flows should be moved by the MN (eg. the MN is aware of
> > > > the attachment status via each IF and decide which IF is better
> > > > for sending up-link flows). The MAG should be aware of the
> > > > movement of
> > >
> > > Our assumption is that the MN does implement the logical interface
> > > (as explained in draft-melia-netext-logical-interface-support-01).
> > > The LMA has of course the direct control of how downlink flows are
> > > routed, but an MN implementing the logical interface will just
> > > mirror that behavior with the uplink packets. Therefore, the LMA is
> > > the only entity controlling flow mobility both in downlink and
> > > uplink directions.
> > >
> > It seems to me that these operations are essentially transparent to
> > the MAG and thus the MAG needs not to be involved at all in flow
> > mobility: The LMA decides where to send downlink packets, and the MN
> > mirrors that behavior for uplink packet (as described in the logical
> > interface draft.)
> 
> (this is actually pointed out in the draft), as there is nothing else
> to be added at the MAG. However, if the MN gets different prefixes at
> each physical interface, then we need to signal the MAG, so it knows
> how to route packets downlink (and also to prevent potential ingress
> filtering in the uplink).

So in the simple case where the MN is assigned the same (set of) prefix(es) across multiple physical interfaces then there is no need for flow mobility signaling. 

Since the draft does not detail any requirement that would justify the need for the other model (different prefixes assigned to different physical interfaces) my take is that we can keep things simple by simply removing that other model from the draft and proceed with a single (and simple) model -- same (set of) prefix(es) across multiple physical interfaces.

--julien

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 21 Jul 2010 00:02:57 +0200

Hi Julien,

On Tue, 2010-07-20 at 12:06 -0700, Laganier, Julien wrote:
> So in the simple case where the MN is assigned the same (set of)
> prefix(es) across multiple physical interfaces then there is no need
> for flow mobility signaling. 

I need to think of this more carefully (just to ensure I'm not
overlooking anything). There might be the need in case the MN is
attached through different interfaces to the same MAG. In that case we
might need some support and signalling to make the MAG aware of the
interface that should be used to deliver packets to the MN. That is a
very particular scenario anyway, as the MAG will "see" the same IP
address attached at different interfaces.

> 
> Since the draft does not detail any requirement that would justify the
> need for the other model (different prefixes assigned to different
> physical interfaces) my take is that we can keep things simple by
> simply removing that other model from the draft and proceed with a
> single (and simple) model -- same (set of) prefix(es) across multiple
> physical interfaces.

Well, the draft does not detail any requirement, but this does not
necessarily mean there is not (I'm not saying either way). I think this
deserves a second thought, because when I looked at existing solutions,
there were some that assumed that model, so I'd say that we need to at
least understand why. Maybe people can comment on this particular
issue... I'd fine to removing this if there is no real need for
supporting the two models.

Thanks,

Carlos

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 20 Jul 2010 15:29:26 -0700

> supporting the two models.

I think both the models need to be captured. Having a separate /64 can be a
subscription issue - the provider may want to maintain separate sessions for
the multi-access. And, a MAG needs to have the session state as well for
such purposes as QoS, policy and accounting. So, signaling is necessary
regardless of whether the same /64 is used or not.

-Rajeev

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 20 Jul 2010 15:55:24 -0700

Rajeev Koodli wrote: 
> > necessarily mean there is not (I'm not saying either way). I think
> > this deserves a second thought, because when I looked at existing
> > solutions, there were some that assumed that model, so I'd say that
> > we need to at least understand why. Maybe people can comment on this 
> > particular issue... I'd fine to removing this if there is no real need 
> > for supporting the two models.
> 
> I think both the models need to be captured. 

Engineering is about designing solutions to problems. Thus seems premature to capture more than one model without having captured requirements that justify the need for those.

>                                              Having a separate /64 can
> be a subscription issue - the provider may want to maintain separate
> sessions for the multi-access. And, a MAG needs to have the session state 
> as well for such purposes as QoS, policy and accounting. So, signaling is
> necessary regardless of whether the same /64 is used or not.

If we can agree that there's a requirement that separate session be maintained for each of the accesses, then we can discuss how to best fulfill this requirements, including, but not necessarily relying on, signaling. 

I do not know yet how that would relate to the use of one (set of) prefix(es) per physical interface.

--julien

---

From: Tran Minh Trung <[email-masked]>
Date: Wed, 21 Jul 2010 19:17:22 +0900

Hi Bernardos,

Thank you for your reply.
Pls. see my replies inline.

> by the LMA. There is signaling defined for that purpose.

Let's consider the case that the MN performs a handoff. I think it is
a special case of flow mobility when all flows are moved from an
interface to another. The MAG is aware of that event and informs the
LMA by using handoff indicator. So I think that we may consider the
same for the case that flows are moved by the MN. The MAG can be aware
of this movement by analyzing the packets received from the MN and
inform the LMA.

In real network both operator (the LMA) and user (the MN) can set and
perform the rules to select the best interface (access technologies)
for serving a specific service flow. So we may better support for both
of them.

> as it does not have an impact on the protocol (with current design).

I agree that it is not necessary to discuss detail about trigger in
the solution draft.
However, we have to mention about where do triggers come from?. Basing
on the source of trigger we have to use different signaling procedure.

For examples:

- The MN performs new attachment -> The MAG is aware of that event and
informs the LMA about new attachment and asks the LMA whether to move
some exiting flows to new attachment.
- The MAG receives new flows from an interface of the MN -> The MAG
informs and asks LMA to check whether this flow is a new flow or just
a flow moved from another interface of the MN.
- The LMA sees some changes in the network conditions or service
profile of the MN -> The LMA decides to move some flows to get better
services and inform MAGs.

> draft-melia-netext-logical-interface-support-01.

I get some confuses about the logical interface described in the I-D
“draft-melia-netext-logical-interface-support-” and the logical
interface used in the I-D “01draft-bernardos-netext-pmipv6-flowmob-00”

IMHO, when we use logical interface, the (set of) prefix(es) is
assigned to the logical interface only, not to physical interface. The
LMA, at layer 3, may see only the logical interface.

>From this point, I think the 'Unique prefix per physical interface'
scenario is not necessary.

However if we consider this scenario, then we can justify why we need
it as Julien suggested. And also we can discuss to make clear that why
we use the logical interface to hide the physical interfaces but we
still separate prefix(es) assignment basing on physical interfaces.

---
Tran Minh Trung

---

From: <[email-masked]>
Date: Wed, 21 Jul 2010 15:51:45 +0200

Hi Tran Minh and Carlos,

Please let me jump into this interesting discussion.

Tran Minh, You're right, theoretically both the LMA and the MN should also be able to make decision about the path to use for a given IP flow. In addition to handover triggers at the MN side that you are suggesting, it may be not desirable that the LMA enforces its decision to the MN despite of the user preferences. 

However, a MN driven decision in a network based mobility management solution is quite tricky without MN signalling (and we definitely want to avoid such a signalling, I don't want to reopen the debate :-)). For example, you wrote:

"The MAG can be aware of this movement by analyzing the packets received from the MN and inform the LMA."

I don't think such a simple solution could be sufficient, since there are some cases where the MN does not use the uplink very often, e.g. RTP streaming. 

So, trying to support the MN driven routing decision would bring additional complexity and delay in the design of a solution. So, for the sake of pragmatism, it makes sense to focus, in a first step, on a routing decision driven by the LMA where the MN just updates its uplink path according to where packets are received.

Then we need to clarify the requirement for handover triggers to be processed at the MN side only. If so, we could think about extension to the base solution as drafted in draft-bernardos.

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de Tran Minh Trung
> Envoyé : mercredi 21 juillet 2010 12:17
> À : [email-masked]
> Cc : [email-masked]
> Objet : Re: [netext] Comments & Questions on the I-D:draft-bernardos-
> netext-pmipv6-flowmob-00
> 
> Hi Bernardos,
> 
> "draft-melia-netext-logical-interface-support-" and the logical
> interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob-00"
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: "Zuniga, Juan Carlos" <[email-masked]>
Date: Wed, 21 Jul 2010 17:06:16 -0400

Pierrick, Tran Minh,

As Carlos mentioned in his first response to Tran Minh, the necessary requirements of the logical interface to support flow mobility should be captured in the applicability document. The current wording in "draft-melia-netext-logical-interface-support-01" is a little messy due to the last minute merger of two other i-ds, but this is the place where the overall system should be described (i.e. beyond PMIP changes).

Regarding the MN driven decision, we discussed in the past that a trigger could be sent to the LMA via L2.5 signalling. This would not be in scope for the solution document (draft-bernardos-netext-pmipv6-flowmob-00) which, as Pierrick points out, only considers network based solutions. However, it should be documented in the applicability document as this could be one more input at the LMA to trigger the flow mobility (from the network). By making this distinction, we allow both MN and LMA to start the flow mobility, and still limit the mobility management solution to be network based.

Regards,

Juan-Carlos

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Wednesday, July 21, 2010 9:52 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [netext] Comments & Questions on theI-D:draft-bernardos-
> netext-pmipv6-flowmob-00
> 
> Hi Tran Minh and Carlos,
> 
> Tran Minh, You're right, theoretically both the LMA and the MN should
> also be able to make decision about the path to use for a given IP
> flow. In addition to handover triggers at the MN side that you are
> suggesting, it may be not desirable that the LMA enforces its decision
> to the MN despite of the user preferences.
> 
> However, a MN driven decision in a network based mobility management
> solution is quite tricky without MN signalling (and we definitely want
> to avoid such a signalling, I don't want to reopen the debate :-)). For
> example, you wrote:
> 
> "The MAG can be aware of this movement by analyzing the packets
> received from the MN and inform the LMA."
> 
> I don't think such a simple solution could be sufficient, since there
> are some cases where the MN does not use the uplink very often, e.g.
> RTP streaming.
> 
> So, trying to support the MN driven routing decision would bring
> additional complexity and delay in the design of a solution. So, for
> the sake of pragmatism, it makes sense to focus, in a first step, on a
> routing decision driven by the LMA where the MN just updates its uplink
> path according to where packets are received.
> 
> Then we need to clarify the requirement for handover triggers to be
> processed at the MN side only. If so, we could think about extension to
> the base solution as drafted in draft-bernardos.
> 
> Regards,
> Pierrick
> 
> the
> (as
> operations

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Jul 2010 07:15:16 +0200

Hi Tran Minh,

Some comments inline below...

> of this movement by analyzing the packets received from the MN and

I think the case of an MN handoff should not be tackled as a particular
case of flow mobility. I'd try to explain why is so IMHO. There are two
different cases: simultaneous attachment to different access
technologies and sequential attachment. The first case is the one I
think you are referring to, and for that I think we cannot assume the MN
can easily control the movement of flows. With current charter, we are
not allowed to define any signaling between the MN and the MAG, and
therefore -- how Pierrick said in another e-mail -- it is quite hard to
define an MN-centric solution for flow mobility.
The second case is really what I understand as inter-tech handoff, and
for that we probably need to tackle that in a different way than flow
mobility. Using the logical interface, that case actually can be
supported quite easily, as we just basically need to follow RFC5213, but
benefiting from the fact that the address(es) that the MN is using
remains the same (it can be seen as an intra-technology handover from
the viewpoint of the MN).
> for serving a specific service flow. So we may better support for both

See above.

> on the source of trigger we have to use different signaling procedure.

Why do we need to know where the triggers come from? If the LMA knows
that it has to move flow X from MN's interface a to MN's interface b...
does it really matter where this flow mobility decision come from (from
the viewpoint of the solution design)?

> some exiting flows to new attachment.

In the drafted solution, the LMA is aware of this event. However that
event is not the trigger itself for moving flows. The deciding entity
(which could be the LMA itself, or even the MAG) should be aware of the
interfaces through which the MN is attached to the PMIPv6 domain, so it
can use that information when deciding to move flows.

> a flow moved from another interface of the MN.

Why do we need this? I don't understand.

> services and inform MAGs.

It can be the LMA or any other entity. The LMA is the entity signaling
and managing the mobility of flows, but it is not necessarily the entity
making the decisions about flow mobility.

> LMA, at layer 3, may see only the logical interface.

I don't agree with that. The logical interface is an artifact at the MN
side, to avoid requiring changes at the host stack. The network can --
and in my opinion must -- know about the different physical interfaces
that the mobile has, so it can handle the movement of flows.

> scenario is not necessary.

This is not exactly the same that saying that the LMA sees at layer 3
only the logical interface, IMHO. We still need to discuss and agree
about whether this "unique (set of) prefix(es) per physical interface"
model is required or not.

> still separate prefix(es) assignment basing on physical interfaces.

See above.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Jul 2010 07:15:21 +0200

Dear Pierrick,

I agree with your comments.

Thanks,

Carlos

On Wed, 2010-07-21 at 15:51 +0200, [email-masked]
wrote:
> to avoid such a signalling, I don't want to reopen the debate :-)).
> For example, you wrote:
> 
> routing decision driven by the LMA where the MN just updates its
> uplink path according to where packets are received.
> 
> processed at the MN side only. If so, we could think about extension
> to the base solution as drafted in draft-bernardos.
> 
> Regards,
> Pierrick
>

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Thu, 22 Jul 2010 10:55:42 +0200

Right, and this is currently captured in the logical interface ID (section 5.3). This should clear up doubts.

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Zuniga, Juan Carlos
Envoyé : mercredi 21 juillet 2010 23:06
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : Re: [netext] Comments & Questions ontheI-D:draft-bernardos-netext-pmipv6-flowmob-00

Pierrick, Tran Minh,

Regards,

Juan-Carlos

---

From: "MELIA TELEMACO" <[email-masked]>
Date: Thu, 22 Jul 2010 11:06:51 +0200

Hi all,

The ID Carlos posted proposes a network based signaling to achieve flow mobility. As Juan Carlos stated earlier the LMA takes flow mobility decisions based on external triggers and while these triggers are out of scope for the solution design document people might feel free to adopt any of them. Although achieving the same goal, the proposed method is semantically different from the one specified for DSMIP. We should not mix things.

telemaco

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Carlos Jesús Bernardos Cano
Envoyé : jeudi 22 juillet 2010 07:15
À : Tran Minh Trung
Cc : [email-masked]
Objet : Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00

Hi Tran Minh,

See above.

See above.

Thanks,

Carlos

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 22 Jul 2010 11:12:41 -0700

On 7/21/10 10:15 PM, "Carlos Jesús Bernardos Cano" <[email-masked]> wrote:

> case of flow mobility. I'd try to explain why is so IMHO.

Yes, flow mobility is for simultaneous access. We have discussed this during
multiple meetings prior to re-chartering. Handover typically involves
relinquishing an interface for another.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 22 Jul 2010 11:15:15 -0700

Yes, I think it would be necessary to maintain/manage state for each
session.
If there is a way to do this without signaling, please elaborate.

-Rajeev

On 7/20/10 3:55 PM, "Laganier, Julien" <[email-masked]> wrote:

> Engineering is about designing solutions to problems. Thus seems premature to
> capture more than one model without having captured requirements that justify
> the need for those.
> 
> If we can agree that there's a requirement that separate session be maintained
> for each of the accesses, then we can discuss how to best fulfill this
> requirements, including, but not necessarily relying on, signaling.
>

---

From: Tran Minh Trung <[email-masked]>
Date: Fri, 23 Jul 2010 19:13:06 +0900

Hi Carlos, Pierrick, Rajeev and all

Thank you very much for your comments.

I agree with Pierrick and Carlos that in the first step we just focus
on a routing decision driven by the LMA as drafted in
draft-bernardos-netext-pmipv6-flowmob-00. I do hope that in the next
step we can clarify the requirement for handover triggers to be
processed at the MN side only.

About the unique prefix(es) per physical interface model for
separating session issue, I think we still need more discussion.

See all of you at IETF78 meeting next week.
Regards,
Tran Minh Trung

---

From: "Laganier, Julien" <[email-masked]>
Date: Sat, 24 Jul 2010 05:50:11 -0700

For example, the LMA knows that there are different MAGs so it can distinguish packets coming from one MAG from the others.

--julien

Rajeev Koodli wrote:
> >>                                              Having a separate /64
> can
> > I do not know yet how that would relate to the use of one (set of)
> prefix(es)
> > per physical interface.
> >
> > --julien