Subject: RE: Issues splitting/consensus - Re: [NSIS] Details about NSIS at IETF 58

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 7 Nov 2003 00:42:34 -0000

hi all,

yes, let's do it like this and see how we get on. my preference 
would be to get a single coherent document with the broad scope 
that jukka mentions (route change, mobility, multihoming) and 
maybe a bit more (see later reply to paulo, to come), which 
explains what signalling messages have to be sent around and 
when to handle these problems. deciding which layer is responsible
for which bit of this should come later.

one thing which we discovered doing our mobility work is that 
there are still decisions about complexity/performance tradeoffs
to be made in this work. for example, in the general case, to 
achieve a rapid teardown on the old path may be quite difficult;
so, there is a choice between 'we try to make this possible
always' and 'if you want to have this function, do it with 
card/ct/whatever'. to make these decisions sensibly, we need some
concrete analysis in a form which everyone can absorb and come
to a view on. (the result can then go into the protocol design
documents.)

r.

PS. i'm all for meeting at the reception, although I may be
fit to collapse asleep by the end of it. we can at least find
out who is around and when people are free monday.

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]]
> Sent: Thursday, November 06, 2003 13:21
> To: [email-masked]
> Subject: Re: Issues splitting/consensus - Re: [NSIS] Details 
> about NSIS
> at IETF 58
> 
> 
> 
> Hi all,
> 
> I went through all mobility-related drafts and I basically 
> agree with you 
> about the common issues.
> 
> To me it seems that we have pretty much identified the main 
> issues, and it
> is time to move on now. I would suggest that we gather one 
> single draft
> about the implications of mobility, routing, multi-homing and routing
> changes/repair into one single WG draft. This draft would be used as a
> "requirements"-type of document as the design of NTLP 
> continues, to check
> that the design fits specific environments (mobile, routing changes,
> multi-homing). The document would also include the 
> backgrounds for certain
> issues, not just repeat requirements already mentioned in the 
> requirements
> draft. In addition, the document would be a reference for the 
> current and
> future NSLP documents: what you need to take into account 
> when you design
> an NSLP?
> 
> I would include in this document the issues Seong-Ho already 
> mentioned,
> and, the issue with refresh timers, and encapsulation issues 
> because many
> LMM protocols do this. I would leave out resource discovery (since, at
> least in a mobile environment, CARD is doing this), and 
> pre-reservations,
> because these are more of a trick and very special scheme to deal with
> mobility and resources. Moreover, I wouldn't want the document to have
> discussions on how to implement things - the NTLP and NSLP 
> documents will
> do this eventually, if not already.
> 
> Thus, it would be a draft that documents the current 
> understanding of the
> issues between mobility/routing/multi-homing and resource signaling.
> 
> The authors of the various mobility drafts listed by John 
> could meet in
> Minneapolis, e.g. on Sunday, after the reception, to discuss 
> these issues
> before the actual NSIS WG meetings. We could, for example, 
> try to agree on 
> an initial set of issues to discuss in the draft, and assign 
> responsible 
> section editors, and an overall editor.
> 
> Any comments?
> 
> Regards,
> Jukka
> 
> 
> On Thu, 6 Nov 2003, Seong-Ho Jeong wrote:
> 
> > Hi Robert, Xiaoming, Jukka, Sung-Hyuck, and John,
> > 
> > IMO, the following could be (mobility-related) common issues 
> > (concerning the NTLP/NSLP) that the drafts submitted by different 
> > people have discussed.
> > 
> > - Differences between the general route change (not related 
> to mobility) and 
> >    mobility-caused route change
> > - How to discover crossover router (or crossover node) 
> using some identifiers
> >   (how to discover upstream and downstream crossover routers)
> > - How to setup states on the new path and teardown old 
> states on the obsolete path
> >   (as quickly as possible,......)
> > - State update on the joined/common/shared/unchanged path 
> after handover
> > - Interactions with mobility protocols such as CT and CARD 
> (in a general way)
> > - Interactions between the NTLP and NSLP
> > - Security issues (authorization,...)
> > - etc.
> > 
> > I think that (at least) the above issues may need to be 
> addressed in the NSIS WG.... 
> > Additionally, it might be good to include the following 
> issues that were discussed 
> > separately by the different drafts.
> > 
> > - IP-in-IP encapsulation
> > - Dead peer (crossover router) discovery
> > - Discovery of resource availability
> > - State mangement (refresh timer value management,...)
> > - Last node detection
> > - Pre-reservation
> > - etc....
> > 
> > Regards,
> > 
> > Seong-Ho Jeong
> > 
> > ----- Original Message ----- 
> > From: "Hancock, Robert" <[email-masked]>
> > To: "Xiaoming Fu" <[email-masked]>; 
> <[email-masked]>
> > Cc: <[email-masked]>; <[email-masked]>
> > Sent: Wednesday, November 05, 2003 5:01 AM
> > Subject: RE: Issues splitting/consensus - Re: [NSIS] 
> Details about NSIS at IETF 58
> > 
> > 
> > > hi xiaoming, jukka, john, ....
> > > 
> > > process-wise:
> > > i see some value in a 'what things group X/Y/Z cares 
> about' discussion.
> > > i see much more value in a 'this is the complete issue 
> list and here
> > > are the commonalities/divergences between different 
> people' discussion
> > > (as I think we succeeded in doing with the 3 QoS drafts 
> in Vienna).
> > > 
> > > we should start that discussion on the list now and maybe 
> we can do
> > > some further merging in Minneapolis (depending on what 
> else is exciting
> > > to do on Monday).
> > > 
> > > on a scoping point:
> > > between the lines I detect some concern that there is a 
> danger that
> > > some of the mobility discussion may turn into some kind 
> of 'Mobile-NSIS'
> > > project with a life of its own. it's my opinion that this 
> shouldn't
> > > happen (and in fact isn't likely to happen). instead, 
> what I think we
> > > are talking about here is analysis work which will feed 
> into defining
> > > the functionality that is required in the basic NSIS 
> protocols themselves
> > > (just like we have analysed security and so on). that 
> protocol design 
> > > work - which is going on now - is a potential eager 
> consumer of this 
> > > mobility work; at the moment, the mobility impact on 
> protocol design
> > > has been driven mainly by instinct rather than solid 
> thought, and it
> > > is time to put that instinct on a much firmer foundation.
> > > 
> > > on the technical points:
> > > i have a pile of drafts to read...
> > > 
> > > cheers,
> > > 
> > > r.
> > > > -----Original Message-----
> > > > From: Xiaoming Fu [mailto:[email-masked]]
> > > > Sent: Tuesday, November 04, 2003 08:59
> > > > To: [email-masked]
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Issues splitting/consensus - Re: [NSIS] 
> Details about NSIS at
> > > > IETF 58
> > > > 
> > > > 
> > > > John,
> > > > 
> > > > This sounds a good idea. One thing that has become clear to 
> > > > me is that 
> > > > although we all have some kind of idea on what mobility 
> issues are, 
> > > > those ideas are not necessarily totally aligned 
> (although a certain 
> > > > number of issues have been described in different ways and not 
> > > > particulalrly opposed in most cases since pre-&post-Vienna 
> > > > discussions).
> > > > 
> > > > If NSIS is going to develop something interoperable 
> with mobility 
> > > > protocols, I think it is probably necessary to come to some 
> > > > reasonable 
> > > > agreement on which issues are of common concern to all and 
> > > > which are of 
> > > > different view for each, before we go too far into presenting 
> > > > "seperate" 
> > > > issues but possibly repeating many issues several 
> times. These can 
> > > > include, but not limit to, all the bullets that have 
> come out of the 
> > > > existing discussions (e.g., host IP change, route 
> change, IP-in-IP 
> > > > encapsulation, crossover router discovery, routing interface, 
> > > > etc.). For 
> > > > example, it seems to me more or less at least a 
> consensus has been 
> > > > reached that working with mobility/route change is more 
> of an NTLP 
> > > > concern rather than simply an NSLP issue. However, there are 
> > > > many other 
> > > > issues have not converged. For instance, there was a concern 
> > > > that flow 
> > > > ID should be able to used to route NSIS packets, but very 
> > > > likely, it can 
> > > > be problematic or inefficient in mobility and tunneling 
> scenarios; we 
> > > > may instead rely on NTLP session ID together with the discovery 
> > > > functionality. Perhaps the outcome of the Minneapolis meeting 
> > > > would be 
> > > > not so much a direct solution, but to clarify a number 
> of things.
> > > > 
> > > > Best regards,
> > > > Xiaoming
> > > > 
> > > > [email-masked] wrote:
> > > > > Hi Jukka,
> > > > > 
> > > > > 
> > > > >>Should we have one slide per draft for the background on 
> > > > the problem space 
> > > > >>people see? One slide with the main issues each "group" 
> > > > feels are the 
> > > > >>most important? Thath would make four slides?
> > > > >>
> > > > >>We could also have a preliminary discussion on the list.
> > > > > 
> > > > > 
> > > > > I'd like that we could discuss this on the list, a combined 
> > > > presentation
> > > > > would be one possible solution.
> > > > > 
> > > > > br,
> > > > > John
> > > > > 
> > > > 
> > > > 
> > > > _______________________________________________
> > > > nsis mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/nsis
> > > > 
> > > 
> > > _______________________________________________
> > > nsis mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/nsis
> > >zÈ¬(tm)¨¥Sx%SËg²+"z×è®m¶>>ÿü0ÃXzµú+fùsSYsYùb²Ø§~ç²+
> 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: Xiaoming Fu <[email-masked]>
Date: Fri, 07 Nov 2003 09:50:17 +0100

Robert,

Short comments inline:
> for example, in the general case, to 
> card/ct/whatever'. 

Probably this is desirable for many access networks - recall how bulk, 
real-time traffic have evolved the QoS necessity - in (rather frequent) 
movement of a number of mobile nodes, (mostly, access network) routers 
may come up overloaded within bottleneck resources (which can be pretious).

> to make these decisions sensibly, we need some

I agree.

Best regards,
Xiaoming