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

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi Behcet,

Please, see inline.

On Mon, 2012-10-01 at 15:51 -0500, Behcet Sarikaya wrote:
> 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.

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

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

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

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
> threads for each.

OK, I'll follow those threads.

Thanks,

Carlos

> 
> Regards,
> 
> Behcet

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