Subject: [NSIS] GIST Refresh Mechanism eventually breaks upstream path on Crossover Router

From: Thomas Herzog <[email-masked]>
Date: Mon, 28 Nov 2005 19:12:22 +0100

Hi, all,

I think there is a glitch in GIST refresh mechanism in the case that rerouting 
takes place.

If rerouting occurs, the new and the old GIST signaling paths should converge 
somewhere again, let us call this node "Crossover Router".

This Crossover Router has a "former upstream peer" and a "current upstream 
peer", that means, the current upstream peer is on the new Signaling Path and 
has just established a connection to the Crossover Router. The Crossover 
Router stored upstream routing information for that flow to go over the 
current upstream peer.

GIST Routing State on the former upstream peer however is subject to a 
soft-state mechanism and will stay established until it's RSV time timeout 
occurs or the NSLP pulls down the Routing State manually via 
"InvalidateRoutingState".

Having noted this, it may happen that the former upstream peer triggers a 
Refresh of the routing state. The Refresh would cause the Crossover Router to 
install the former upstream peer for the upstream path. Also, the Crossover 
Router would again signal a Routing Change to it's NSLP. The next refresh 
from the current upstream peer will again set back the upstream path and so 
on and so on as long as the state on the former upstream peer is valid.

One could now define that the NSLP on the crossover router should actively 
tell the NSLP on the former upstream peer to pull down GIST state. But even 
if this would be done, the Refresh could already be triggered before the NSLP 
has done this and the NSLP gets again a new "Routing changed" notification.

Also, one could argue, that design problems in GIST should not have to be 
mended by active intervention by the NSLP. And the eventual loss of correct 
upstream path anywhere on the Signaling path should be considered a "design 
problem".

Having thought about this issue, I would like to propose discussion about a 
new GIST Query-type Message, say "GIST Refresh" with the following semantics:

GIST Refresh:
- may refresh established Routing State
- may lead to establishment of new Routing State

GIST Query:
- may replace established Routing State
- may lead to establishment of new Routing State

Thus the former upstream peer would try a Refresh, this fails and the Routing 
State gets deleted without any Interaction needed by NSLP.

I know, this would be a big modification to GIST, but it would make GIST work 
more reliable in case of rerouting.

Cheers, Thomas

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

---

From: Thomas Herzog <[email-masked]>
Date: Mon, 28 Nov 2005 22:28:41 +0100

Hi, all,

of course, there could also be other possibilities to fix this issue. I think, 
in general,  a Responding Node should be able to detect whether an incoming 
GIST Query is part of a state setup or of a refresh requence.

This could also be implemented by adding a flag *somewhere* to a Query. So a 
Responding Node could drop a Query if it comes in from another peer than the 
currently installed peer and is part of a Refresh.

Cheers, Thomas