Subject: Re: [netext] draft-ietf-netext-pmipv6-flowmob-04

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 18 Sep 2012 19:45:52 +0200

Ni Behcet, all,

Again, apologies for the late reply.

Thanks for your comments and questions. Please find some comments inline
below.

On Fri, 2012-08-24 at 16:13 -0500, Behcet Sarikaya wrote:
> Hi Carlos,
> 
> I have questions on Section 3.2.1. on MN sharing a common set of
> prefixes on all MAGs.
> 
> I don't understand why this is related to flow mobility but not prefix
> allocation policy.
> In Fig. 2, you consider flow Y to pref1::mn1 on if2
> 
> and then you move flow Y to if1. I am confused about the figure. How
> come pref1::mn1 and pref1::mn1 stays the same? What is mn1? Is it the
> iid?

mn1 are the 128-N rightmost bits of the MN1 address, where N is the
prefix length. Typically mn1 would correspond to the iid.

> Do you assume that both if1 and if2 have the same iid? How could this
> be possible? Secondly you did not mention this assumption.

The document does not go into the details of whether if1 and if2 have
the same iid or not. The assumptions on the MN side are the following:

  "It is
   assumed that the mobile node IP layer interface can simultaneously
   and/or sequentially attach to multiple MAGs, possibly over multiple
   media.  One form to achieve this multiple attachment is described in
   [I-D.ietf-netext-logical-interface-support], which allows the mobile
   node supporting traffic flows on different physical interfaces
   regardless of the assigned prefixes on those physical interfaces."

You can also check Section 6 on MN considerations.

> 
> I think that if2 should be referred to as mn2 then the situation will
> be clear, i.e. moving flows between two different interfaces with
> different addresses, so this case is not any different than the cases
> you have in Sections 3.2.2 and 3.2.3.

The point is to address (in Section 3.2.1) a different scenario in which
the same prefix (or set of prefixes) is assigned to different physical
interfaces. This is possible, so it should be considered.

> 
> You  explain in this section that some flow mobility update action (?)
> happens in both LMA and MN and the flow is magically moved. Even if we
> assume what you have is correct this case does not deserve any mention
> in the draft, i.e. there is no observable action to specify.

It is needed to specify how to ensure that different physical interfaces
of the same MN get assigned the same prefix (or set of prefixes).

Thanks again for your comments,

Carlos

> 
> I have more coming up later.
> 
> Regards,
> 
> Behcet
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Sep 2012 15:07:09 -0500

Hi Carlos,

Please see inline.

>> I don't understand why this is related to flow mobility but not prefix

You did not answer this one.

> You can also check Section 6 on MN considerations.

Can I say that pref1::mn1 can not be the same?
This is based on your reply and the fact that you did not make any
assumption/requirement on this, so you need to modify the figure
accordingly.

> interfaces. This is possible, so it should be considered.

Yes but the problem is not any different than when different prefixes
are assigned, so what is the big deal that requires a different
section which happens to be the first section (3.2.1)?

> of the same MN get assigned the same prefix (or set of prefixes).

Please see above. If this case is no different than the cases in 3.2.2
and 3.2.3 then why?

Regards,

Behcet

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 20 Sep 2012 10:32:37 +0200

Hi Behcet,

> You did not answer this one.

Sorry, I didn't see any question there. If you want me to comment on
this, assigning a common set of prefixes is one of the possible ways of
enabling flow mobility -- as documented in the draft -- and therefore I
see it as related to flow mobility.

> assumption/requirement on this, so you need to modify the figure

You mean the iid part of the address not being the same, while the
prefixes are? I don't see what would be the value of doing so. If the
addresses assigned by distinct MAGs are different, then the other
mechanisms described in the draft could be used, but using different
prefixes is cleaner, simpler and avoids potential ND-related problems.

> section which happens to be the first section (3.2.1)?

I disagree here. The problem is different, as in one case there is no
additional changes required in the MAG routing to be able to forward
packets, while in the other there is. The order of the section is not
meaningful, there is no special reason for having it first, just that we
felt it was easier to describe the solutions in that way.

> Please see above. If this case is no different than the cases in 3.2.2

But the case is different.

Thanks,

Carlos