Re: Re: [NSIS Mobility draft] Updating from -07 to -08

Hi,
a few answers below.

Jukka

On Mon, 17 Dec 2007, Hong Cheng wrote:

> Hi Jukka,
> 
> Generally, I would agree with you that the NSLP should not be used to
> replace the mobility management protocol.
> 
> Regarding your analysis, I would like to clarify some points. Please see
>  inline:
> 
> Jukka MJ Manner wrote:
> > Hi,
> > 
> > Me and Nuutti Varis, our GIST expert, had a chat yesterday and we tried to 
> > figure out what could be a good option. I think the problem lies 
> > elsewhere, it is not a (QoS) NSLP problem.
> > 
> > When the IP address does not change 
> 
> [Cheng] I think this is a different scenario than what we were
> discussing earlier. The case seems more of a re-routing issue than a
> mobility issue (which belongs to a different section). GIST should have
> dealt with the normal re-routing case. In case there are other protocols
> involved, different considerations would apply (see below).
> 
> > (with MIP the e2e BU solves the problem),
> 
> [Cheng] The MIP BU should solve the routing aspect of the problem.
> Possible NSIS operation sequence has been detailed in several earlier
> emails. However, as Roland pointed out, the description in the draft
> might be insufficient about the NSIS mechanism, e.g. the GIST API to
> inform NSLP of the new MRI after change of MIP Binding Cache, etc.

[JM]: This may be so, I haven't thought about how the GIST API fits with 
MIP. I trust Roland that there is a problem.

> 
> > the point is that even if we would be able to send a message 
> > upstream, we still need the routing towards the MN to be in place. There
> > must be some routing protocol in place that sets up e.g. a new host route 
> > to the MN when it has moved. This protocol must be coupled with GIST, 
> > i.e., GIST must be able to get a notification from a routing change. This 
> > would be a cross-over router having the MN state. Once the node gets a 
> > hint that the next peer for a MN has changed, it can reissue a RESERVE 
> > towards the new path.
> 
> [Cheng] Can you share a bit more on what is the use case/scenario you
> have in mind? (when MN moves but IP address does not change) Usually, to
> achieve this, some sort of tunneling needs to be used, e.g. network
> based local mobility management. If this is the case, the nodes involved
> would be totally different, and the analysis should also be different.
> It does not have to be the crossover router that issues the RESERVE. The
> tunnel signaling interaction must be considered here as well.

[JM]: You could per-host forwarding within a local domain based on 
tunnels, or you could update just per-host routes in the domain routers. 
Both have their interactions with GIST. I don't think we should try to 
figure out all possible local (micro) mobility schemes and see how they 
would work. Just the general considerations are enough, IMO.


> 
> cheers
> 
> Cheng Hong
> 
> 
> 
> > Thus, I would say that we should not invent an NSLP solution to a mobility 
> > management protocol issue. We just need to note that GIST must be able to 
> > see when routes change, to set up the new route on the downstream.
> > 
> > rgs,
> > Jukka
> > 
> > On Fri, 7 Dec 2007, Roland Bless wrote:
> > 
> >> Hi Jukka,
> >>
> >> see comment inline.
> >>
> >> Jukka MJ Manner wrote:
> >>> On Thu, 15 Nov 2007, Roland Bless wrote:
> >>>
> >>>> Hi Jukka,
> >>>>
> >>>> [I'm taking this to the list now...]
> >>>>
> >>>> Jukka MJ Manner wrote:
> >>>>> I think we are talking about the same thing. The main point is that if IP 
> >>>>> addresses change, the MRI is invalidated, and the QNI must then, in one 
> >>>>> way or another be notified. There must be (otherwise nothing works) some 
> >>>>> mobility signaling where the QNI gets to know the new IP of the MN, and 
> >>>>> can then reissue a RESERVE with a new MRI.
> >>>> Ok, however, I believe that your proposed solution doesn't work:
> >>>> you proposed to send a NOTIFY towards the CN. This will require usage
> >>>> of the new flow's MRI and the resulting GIST Query must be sent in
> >>>> _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream.
> >>>> Now there is the problem of choosing the correct encapsulation for the
> >>>> Query: only _upstream_ Q-mode encapsulation would be an option, but this
> >>>> is not appropriate to use in this case due to its limited applicability
> >>>> to certain environments. Even if the MN could send the NOTIFY to its
> >>>> new access router (QNE4 below), there is no routing state installed yet
> >>>> in upstream direction in QNE4, i.e., it doesn't know any next peer
> >>>> in upstream direction, so only upstream Q-mode could be used, but that
> >>>> is not really applicable in this case. So only the last paragraph of
> >>>> section 4.3.3 applies:
> >>>>    o  If no routing state exists, GIST can attempt to use Q-mode as in
> >>>>       the Query case: either sending a Data message with the Q-mode
> >>>>       encapsulation, or using the event as a trigger for routing state
> >>>>       setup (see Section 4.4).  If this is not possible, e.g. because
> >>>>       the encapsulation for the MRM is only defined for one message
> >>>>       direction, then this is an error condition which is reported back
> >>>>       to the local signalling application.
> >>>>
> >>>> So an error will be reported back to the application.
> >>>> As a conclusion: sending a NOTIFY in upstream direction does not
> >>>> work along paths that have no routing state yet.
> >>>
> >>> [JM]: If the CN requests reliable or secure transport, GIST will send an 
> >> I don't know what it has to do with reliable and secure transport?
> >>
> >>> empty Query to the next, set up routing state, and only then send the 
> >>> NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in 
> >>> question, so should it send an error back, or forward the message in the 
> >>> same way towards the CN? 
> >> Please read the above text again. The problem lies in the fact that
> >> you have to send a GIST-Query _upstream_ and no routing state exists
> >> yet. So even if an MA exists, it cannot be used.
> >> This could only be done with _upstream_ Q-mode encapsulation, but this
> >> is definitely not applicable in a general way.
> >>
> >>> [JM]: Yet, also with unreliable/unsecure transport, what would happen, if 
> >>> QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it 
> >>> doesn't know about, so it could as well forward the message further, 
> >>> right? The message will eventually hit a QNE (or eventually the CN), who 
> >>> then knows about the SID.
> >> See above. The GIST Query has to find its way first. This is the real
> >> problem.
> >>
> >> Regards,
> >>  Roland
> >>
> > 
> > 
> > _______________________________________________
> > nsis mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/nsis
> > 
> > 
> 
> 
>