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

["Charles Q. Shen" <[e-mail]>]

Hi Xiaoming, 

Thanks for your reply. Please find comments inline.

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Xiaoming Fu
> Sent: Monday, July 07, 2003 4:22 AM
> To: Charles Q. Shen; [e-mail]
> Subject: Re: [NSIS] Proposed draft "Mobility Support in NSIS"
> 
> 
> Hi,
> 
> Thanks for your insightful comments. My comments inline:

Thanks :-)

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

Yes, I think it is very appropriate to include this issue into the
draft. When we did our RSVP-Mobile IP implementation we found it
actually causes many complexities as detailed in our implementation
draft. 
http://www.ee.columbia.edu/~charles/publication/draft-shen-nsis-rsvp-mob
ileipv6-00.txt

As to the terminotlogy, we can always think about better ones :)

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

That would be very helpful because those aspects differentiate the
protocol from original RSVP and require new efforts that are different
from existing work on RSVP mobility.

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

Yes, you are right, the two addressing modes should be treated
differently on this issue.

1) in e2e mode like RSVP, RFC 2746 describes three possibilities of the
(logical) link. That seems to me is a more generic description. You are
certainly correct in pointing out the requirement for the two tunnel end
points to be NSIS aware to achieve a true e2e signaling.

2) in p2p mode, if the discovery is done properly with the help of NSIS
aware tunnel endpoints, you are probably right that such tunneling could
be avoided. (Do we have the path-coupled assumption here? )

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

Thanks.

> 
> > The handoff process would further impact subsequent regular 
> soft-s  tate
> > 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.

I think there is always a trade-off here in terms of signaling overheads
and promptness of response. Upon handoff, trying to achieve an
"on-demand" adjustment (i.e., movement triggers both MIP and NSIS) is
probably appropriate. During normal refresh, I agree that generally the
NSIS timer should not be larger than the mobility timer. After all, why
should the specific NSIS signaling (e.g. QoS) be still there if the
mobility entry has expired? Of course there might be more details to
look at. 


Cheers

Charles

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


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