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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 3 Feb 2004 22:57:46 -0000

hi,

new readers: please note a new open issue below.

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

*if* the rerouting is taking place because of a node failure,
*and* that node is the downstream NTLP peer, then you will
detect that failure in C mode and can think about recovery
the way you say (but see below).

however, rerouting can take place for many reasons, and only
rarely (i would contend) will it fit this scenario. the rerouting
might not be related to a node failure (you could be adding or
removing a link, or there could be a change in routing protocol
state for some other reason. even if it is a node failure, if it
doesn't change the reachability between the two peers, ICMP 
messages won't tell you about this.

summary: C mode has weak route change detection capabilities.
we have to agree if this is ok to live with (so far I get the
impression that it is).

there is the question of how GIMPS should handle ICMP messages
(and other error messages) in C mode. over-enthusiastic 
processing can be a source of DoS attacks (as have been 
identified in BGP of late). anyone with advice on this is
welcome to offer it ...

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

but then it might as well be NSLP local repair, surely?

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

but then the repair is not local anyway!

(also, this does not tell you it should be NTLP repair as well.)

it is clear that the NTLP has to be able to do the notification.
but it is not clear that is has to do the repairs, or even if 
this is possible. (for example, some route change detection 
methods may be possible only at the NSLP level.)

r.

> Xiaoming

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

---

From: Xiaoming Fu <[email-masked]>
Date: Wed, 04 Feb 2004 20:35:16 +0100

Hi Robert,

I agree that refresh in C mode makes things difficult; ICMP error 
messages don't work for this purpose in certain cases. Nevertheless, it 
may make sense to have an e2e refresh message to trigger discovery 
before being forwarded on to "next peer", allowing a chance to discover 
any route change in between two peers or next peer itself.

> but then it might as well be NSLP local repair, surely?

Depends on how we call that. You can forward those NSLP messages from 
then on no matter what they are, but notify the corresponding NSLP 
entities when such are found. Routing is still job of the NTLP level - 
to be "recovered" with active discovery while .

> but then the repair is not local anyway!
I don't argue this is real _local_ any more, but as said this causes a 
number of challenges. In either case (if this can be made possible or 
not) refreshing with trigger of discovery is perhaps more realistic.

Xiaoming