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

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

Hi Julien,

On Tue, 2010-07-20 at 12:06 -0700, Laganier, Julien wrote:
> 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. 

I need to think of this more carefully (just to ensure I'm not
overlooking anything). There might be the need in case the MN is
attached through different interfaces to the same MAG. In that case we
might need some support and signalling to make the MAG aware of the
interface that should be used to deliver packets to the MN. That is a
very particular scenario anyway, as the MAG will "see" the same IP
address attached at different interfaces.

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

Well, the draft does not detail any requirement, but this does not
necessarily mean there is not (I'm not saying either way). I think this
deserves a second thought, because when I looked at existing solutions,
there were some that assumed that model, so I'd say that we need to at
least understand why. Maybe people can comment on this particular
issue... I'd fine to removing this if there is no real need for
supporting the two models.

Thanks,

Carlos

> 
> --julien

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