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

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 1 Oct 2012 15:51:19 -0500

Hi Carlos,

Sorry for my late reply. We need to continue this conversation.
>> >> 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.
>> >
>>
>>
>> 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.
>
> 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.
>

Sorry, MAGs do not assign addresses, MAGs advertise HNPs and MN makes
an address like you call pref1::mn1.
So MN receives pref1 on if1 it makes pref1::mn1
and MN receives pref1 on if2, it does not make pref1::mn1 because mn1
is the hardware address (or iid) on if1 and on if2, the hardware
address (or iid) is different, you need to show it as pref1::mn1',
maybe, with mn1 not = mn1'.

You have this type of misleading terminology in more than one figure
(Figs 4,5 &6) and that is what I am asking you to correct.

I hope it is clear now?

>>
>> >>
>> >> 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.
>> >
>>
>> 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)?
>
> 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.

Why? I guess you mean LMA routing. LMA has to send the two flows to
two different addresses anyway, right?

So what is different in Section 3.2.1?

I have comments on other section, I am going to create different
threads for each.

Regards,

Behcet

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 08 Oct 2012 09:28:52 +0200

Hi Behcet,

Please, see inline.

> an address like you call pref1::mn1.

Well, I did mean "assigned at distinct MAGs", but anyway, MAGs can
assign addresses (section 6.9.1.1 of RFC5213: "If the mobile access
gateway learns the mobile node's home network prefix(es) either from its
policy store or from other means, the mobile access gateway MAY choose
to request the local mobility anchor to allocate the specific prefix(es)
by including a Home Network Prefix option for each of those requested
prefixes.").

> (Figs 4,5 &6) and that is what I am asking you to correct.

I understand now your comment and I see your point. I'll update the
figures and the text to clarify this. The point is, that even with
different IIDs, the scenarios are different, as when the MN is sharing a
common set of prefixes on all MAGs, the MAGs already have the required
forwarding state, so no signaling is required on the network to achieve
flow mobility.

Thanks for the comment.

> So what is different in Section 3.2.1?

In one case the assigned prefixes on different interfaces of the MN are
different, whereas in the other they are not.

> I have comments on other section, I am going to create different

OK, I'll follow those threads.

Thanks,

Carlos

-- 
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: Mon, 8 Oct 2012 15:19:53 -0500

Hi Carlos,
Please see inline.

> by including a Home Network Prefix option for each of those requested

You are talking about MAG suggesting prefixes (HNPs) to LMA not addresses.

> figures and the text to clarify this.

Good thanks.

> The point is, that even with

I don't understand your point. It is the LMA that does the routing of
different flows to different interfaces based on the flow state.

What does it mean to say that MAG has the required forwarding state?
MAG forwards to the proper LMA of MN, in most cases only to one LMA.

> different, whereas in the other they are not.

Why does this change LMA's flow routing, that was my question. Still
not yet answered?

Regards,

Behcet

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 10 Oct 2012 14:21:46 +0200

Hi Behcet,

More comments below inline.

> You are talking about MAG suggesting prefixes (HNPs) to LMA not addresses.

Right, but addresses are then configured out of those prefixes...

> MAG forwards to the proper LMA of MN, in most cases only to one LMA.

Think of the other direction (LMA->MAG). In order to perform flow
mobility, you need the MAG routing state to be consistent.

Carlos

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 Oct 2012 14:37:50 -0500

Hi Carlos,

Please see inline.

> Right, but addresses are then configured out of those prefixes...

Thanks, this is what I said.

So when MN configures addresses, even if the prefixes are the same the
addresses are different. Addresses assigned to the interfaces of MN
that are simultaneously connected are different. These are the
addresses that are used as source/destination addresses in the traffic
selectors defined in RFC 6088 Section 3.2.

> mobility, you need the MAG routing state to be consistent.

Absolutely.

Let's consider then LMA to MAG flow routing.
LMA receives a packet for MN  which has multiple active interfaces
(destination address pointing at Interface A). It checks the binding
cache and finds the TS and then matches the TS with the packet and it
wants to redirect this packet to  interface B.

Please tell me how does it help to assign the same prefix to all interfaces?

Even if HNPs are the same, you would have to distinguish the
interfaces based on the addresses anyway, right?

Regards,

Behcet

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 22 Oct 2012 16:18:51 +0200

Hi Behcet,

> interfaces based on the addresses anyway, right?

On the LMA yes, but in the MAGs then you don't need additional routing
state.

Carlos