Re: [netext] Comments & Questions on the I-D: draft-bernardos-netext-pmipv6-flowmob-00

["Laganier, Julien" <[e-mail]>]

Hi Carlos,

Carlos Jesús Bernardos Cano wrote:
> 
> Hi Julien,
> 
> On Tue, 2010-07-20 at 09:32 -0700, Laganier, Julien wrote:
> > Hi Carlos,
> >
> > One question below -
> >
> > Carlos Jesús Bernardos Cano wrote:
> > >
> > > Hi Tran Minh,
> > >
> > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote:
> > > > Hi Bernardos and all,
> > > >
> > > > I have some comments and questions on the I-D
> > > > draft-bernardos-netext-pmipv6-flowmob-00 as follows:
> > >
> > > Thanks a lot for the feedback. Please see some comments inline
> > > below.
> > >
> > > > 1) I think the LMA can decide to move down-link flows only. The
> > > > up-link flows should be moved by the MN (eg. the MN is aware of
> > > > the attachment status via each IF and decide which IF is better
> > > > for sending up-link flows). The MAG should be aware of the
> > > > movement of
> > >
> > > Our assumption is that the MN does implement the logical interface
> > > (as explained in draft-melia-netext-logical-interface-support-01).
> > > The LMA has of course the direct control of how downlink flows are
> > > routed, but an MN implementing the logical interface will just
> > > mirror that behavior with the uplink packets. Therefore, the LMA is
> > > the only entity controlling flow mobility both in downlink and
> > > uplink directions.
> > >
> > > > up-link flows and inform the LMA to update information.
> > >
> > > In the current draft, the MAG is informed about flow mobility
> > > operations by the LMA. There is signaling defined for that purpose.
> >
> > Why does the LMA needs to inform the MAG about flow mobility
> > operations?
> >
> > It seems to me that these operations are essentially transparent to
> > the MAG and thus the MAG needs not to be involved at all in flow
> > mobility: The LMA decides where to send downlink packets, and the MN
> > mirrors that behavior for uplink packet (as described in the logical
> > interface draft.)
> 
> Well, there are two scenarios. If the MN is assigned the same of
> prefixes across the different physical interfaces that belong to the
> logical interface, you are right that this signaling can be avoided
> (this is actually pointed out in the draft), as there is nothing else
> to be added at the MAG. However, if the MN gets different prefixes at
> each physical interface, then we need to signal the MAG, so it knows
> how to route packets downlink (and also to prevent potential ingress
> filtering in the uplink).

So in the simple case where the MN is assigned the same (set of) prefix(es) across multiple physical interfaces then there is no need for flow mobility signaling. 

Since the draft does not detail any requirement that would justify the need for the other model (different prefixes assigned to different physical interfaces) my take is that we can keep things simple by simply removing that other model from the draft and proceed with a single (and simple) model -- same (set of) prefix(es) across multiple physical interfaces.

--julien