Subject: RE: [NSIS] GIMPS connection mode and network re-routing

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 3 Feb 2004 10:42:00 -0000

hi xiaoming,

> -----Original Message-----
> From: Xiaoming Fu [mailto:[email-masked]]
> Sent: Monday, February 02, 2004 17:38
> To: Hancock, Robert
> Cc: [email-masked]'; Nsis (E-mail)
> Subject: Re: [NSIS] GIMPS connection mode and network re-routing
> 
> 
> Hi Robert,
> 
> Do we have a measurement about the possibility of a route 
> change due to 
> node failure during a session? 
i have no figures to hand. henning provided a pointer
to rerouting statistics in an earlier mail.

> Unless it is mobility-related route 
> change (very likely more frequent), in either mode (c- or d-), an e2e 
> refresh at NTLP level (which carefully chooses a refresh timer) in 
> general should be ok.
i don't see how a refresh in C mode can do any good to you. 
this is precisely the point in question.

> If the router which can detect a route 
> change is 
> able to support NTLP, we can certainly reuse RSVP local repair 
> mechanism, as additional enhancement.
this is certainly something under consideration (although there
is a question of whether "RSVP local repair" = "NTLP local
repair" or "NSLP local repair".

r.

> 
> Xiaoming
> 
> Hancock, Robert wrote:
> > hi marcus,
> > 
> > 
> >>>Therefore, we would propose to get rid of 5.3.4, leaving us with
> >>>simple D mode and raw C mode. The consequence would be a final
> >>>acceptance within the group that the lack of automatic route change
> >>>detection in C mode is something we can all live with.
> >>>
> >>
> >>I have no problem to get rid of this as long as the 
> >>specification defines how route changes are handled.
> >>
> >>Marcus
> >>
> > 
> > 
> > there are two parts to 'handled':
> > 1. detected
> > 2. repaired (in general, "reacted to")
> > 
> > and (1) can be subdivided into
> > 1a. detected as possibly having occurred
> > 1b. confirmed (and the new route discovered)
> > 
> > my view (but i am thinking aloud here) is that 
> > 1a - GIMPS will describe one method for this (periodic re-issue
> > of D-mode query/response exchanges); might include protocol 
> > elements which assist other mechanisms (e.g. TTL measurements);
> > but certainly won't be comprehensive. there is important
> > stuff to be done here (cf. zappala's routing interface for
> > RSVP) but not as part of the basic GIMPS spec.
> > 
> > 1b - GIMPS defines this already (it's the D mode 
> > discover/query), or at least we know it has to.
> > 
> > 2 - the main point is that GIMPS doesn't carry out
> > the repair operation itself, it notifies NSLPs that they
> > may need to do it. so, the main issue from a protocol
> > perspective is: where (at which node) to deliver the
> > notification. there are some subtleties here (sections
> > 6.1.2 and 6.1.3 of the GIMPS draft) which some comments
> > on would be nice.
> > 
> > r.
> > 
> 

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

---

From: Xiaoming Fu <[email-masked]>
Date: Tue, 03 Feb 2004 20:09:03 +0100

> this is precisely the point in question.

While the refreshes are forwarded peer-to-peer way, the NTLP node can 
choose either to do recovery or simple refresh, depending on the 
response for such "refreshes". In the formal case, for example, when a 
NTLP node sees ICMP “host unreachable” or “network unreachable” message 
(which indicate a router failure at some point in the network) back to 
itself, it can initiate a new discovery and setup a new connection. Does 
this work?

> repair" or "NSLP local repair".

I think it will be more likely NTLP local repair in this context. 
Reusing NTLP local repair as the general level to deal with routing of 
NSIS messages can avoid several parellel processes take place. This 
works well if the node detecting a route change also supports NSLPs; if 
not, a signal can be sent to corresponding NSLPs to carry there 
corresponding NSLP info stored in previous NSLP hop(s), then this NTLP 
node can initiate the re-establishment of all states in the new path 
segment. A problem comes, the same will be as in NSLP local repair, that 
this detecting NTLP has no knowledge about how many NSLPs altogether 
bounded to the flow, and where are they (even with a capacity-based 
discovery we still needs to know which capacities they can be - how 
come?). Therefore, I would think a more general approach would be 
notifying the source node to deliver all NSLPs+NTLP information, i.e., 
trigger a new e2e refresh.

Xiaoming