Re: [NSIS] Proposed draft "Mobility Support in NSIS"

[Xiaoming Fu <[e-mail]>]

Hi,

Thanks for your insightful comments. My comments inline:

Charles Q. Shen wrote:
> Hi,  
> 
> I think having such a draft discussing mobility issues with NSIS is
> helpful and inline with the WG charter. I started a similar effort in an
> earlier draft last July
> http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-mobility-fw-00.txt.  

I read this draft and found it helpful. For example, your draft 
identified the necessity to soft-state refresh even for the _intact 
path_ (I find this term looks more appealing than _common path_ :)) 
before and after a handoff happens. This has also been summarized in 
issue 3 and section 4.1 in our draft.

> 
> Fu's draft incorporated some recent issues including NSLP/NTLP
> interaction, Discovery, peer-to-peer addressing etc. It would be good to
> elaborate those parts when they become clearer in the WG discussion. 

Yes, to my understanding a concrete conclusion has not been drawn so far 
on whether end-to-end or peer-peer addressing will be used in NTLP. 
That's why the draft discusses both peer-peer and e2e addressing issues 
there, in align with framework draft. It is also my belief that with the 
further development of framework/protocol work, discovery and NSLP/NTLP 
issues would be clearer and we'll be able to look into these issues in 
depth.

> 
> Disscussion of tunneling/non-optimized routing is also useful, but it
> would be beneficial to refer to RFC2746 which provides a very good
> example of solving tunneling issues in the case of RSVP. 

You're right! This is related to the addressing mode of NTLP messages. I 
think RFC2746 scheme would probably be most useful for at least e2e 
addressing approaches such as RSVP. For peer-peer addressing, it looks 
to me discovery component would help to identify next peer and IP-in-IP 
tunneled signaling message can be avoided, as long as the MIP tunnel 
endpoints support NTLP.

> 
> Some issues may also be grouped together. Basically there are cases of
> sender mobility and receiver mobility (The protocol itself could be
> either sender initiated or receiver initated). Handoff causes
> appropriate signaling actions in three segments of the network: the
> intact path, the new path and the obsoleted path. (This applies to both
> optimized/non-optimized routing, and possibly involves tunneling.) 

Thanks for your suggestions, such restructuring looks fine to me.

> The handoff process would further impact subsequent regular soft-state
> refresh which has to be considered.
Regarding the two types of soft-state timers: the mobility management 
timer (let's assume "only" one mobility management, or minimal value of 
timers of all mobility management schemes) and the NSIS timer (let's 
assume NTLP would do some basic state management), there are a few open 
issues (have not explored in our draft yet):

- Shall we use a smaller value for NSIS timer than mobility management 
timer? my conjecture would be "yes", to ensure NSIS signaling actually 
reflect mobility signaling.

- How can we know this comparision at all? This could be through an API, 
or, say, a mobility routing interface issue. If this knowledge is 
unaware to NSIS at all, a simplest way presumably can be NSIS signlaing 
directly after each moibility management.

Cheers,
Xiaoming

> Best regards,
> 
> Charles
> 
> ---
> Charles Q. Shen
> Department of Electrical Engineering
> Columbia University
> Email: [e-mail]
> Phone: [phone]
> http://www.ee.columbia.edu/~charles
> 
> 
> -------- Original Message --------
> Subject: [NSIS] Proposed draft "Mobility Support in NSIS"
> Date: Sat, 28 Jun 2003 23:43:09 +0200
> From: Xiaoming Fu <[e-mail]>
> To: [e-mail]
> 
> Hi all,
> 
> Here is a new Internet Draft that we propose as a problem statement and
> proposed mechanisms to extend NSIS for mobility support:
> http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.txt or
> http://www.ietf.org/internet-drafts/draft-fu-nsis-mobility-00.pdf
> 
> Following previous work (Michael Thomas, Cedric Westphal/Hemant Chaskar,
> Charles Shen, and many others), this Draft aims to provide an extensive
> view on mobility support related issues that will be of broad general
> use.
> 
> We welcome your comments. We are also especially interested in other
> open issues and studying how they may be addressed by future versions of
> the Draft.
> 
> Regards,
> Xiaoming
> 
> 


_______________________________________________
nsis mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/nsis