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

[Behcet Sarikaya <[e-mail]>]

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