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

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

Hi Behcet,

On Wed, 2012-10-10 at 14:37 -0500, Behcet Sarikaya wrote:
> Hi Carlos,
> 
> Please see inline.
> 
> On Wed, Oct 10, 2012 at 7:21 AM, Carlos Jesús Bernardos Cano
> <[e-mail]> wrote:
> > Hi Behcet,
> >
> > More comments below inline.
> >
> > On Mon, 2012-10-08 at 15:19 -0500, Behcet Sarikaya wrote:
> >> Hi Carlos,
> >> Please see inline.
> >>
> >> On Mon, Oct 8, 2012 at 2:28 AM, Carlos Jesús Bernardos Cano
> >> <[e-mail]> wrote:
> >> > 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.").
> >> >
> >>
> >> You are talking about MAG suggesting prefixes (HNPs) to LMA not addresses.
> >
> > 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.
> 
> >>
> >>
> >> >> 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.
> >>
> >> Good thanks.
> >>
> >> > 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.
> >>
> >> 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.
> >
> > Think of the other direction (LMA->MAG). In order to perform flow
> > 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?

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

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