Subject: RE: [NSIS] GIST Refresh Mechanism eventually breaks upstream path onCrossover Router

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 15 Dec 2005 11:16:59 -0000

hi thomas,

this is a good question.

I think the general issue here is that we can have a scenario
where two nodes (P1, P2) think they are the upstream peer 
of a crossover node CN2, and their routing state management 
messages confuse the crossover node.

there are two classes of solution:
1) prevent the 'wrong' upstream peer (P1) issuing refreshes
2) prevent the crossover accepting them

      /--P1--\           (old path)
--CN1-        -CN2--  flow direction ------->
      \--P2--/           (new path)

the local repair approach concentrates on the first method. in
the general scheme of things, local repair must have been 
iniated from the upstream crossover node CN1, which must 
therefore have unique downstream state through the path with
P2. CN1 will not be refreshing state through the P1 path, which
will eventually cause all the state on that path to time out
(including preventing P1 from generating refreshes).

One point to clarify in the draft is that P1 should stop 
refreshing routing state if its upstream state times out. 
I suspect this should be enforced at the GIST level. (We
can't stop a signaling application at P1 from generating a new
NSLP message and starting the process over again, but at 
least we can prevent GIST keeping stuff around in the
background.)

As you point out, stale state on the old path can still
lead to P1 issuing refreshes (I think the time for which this
can take place is bounded by the RSV time at CN1, but I'm
not totally sure about this). The solution here is explicit
tear along the path at the NSLP level followed by indication
to GIST that routing state is no longer needed. I don't think
it's unreasonable to depend on NSLP operation here; the basic
point is that we left explicit teardown out of GIST for
authorisation reasons, so part of the overall signalling
functionality is deferred to the NSLP anyway. It corresponds
to the fact that GIST depends on the NSLP to decide to send
messages in the first place. To put it another way, we cannot
actually solve the explicit tear problem entirely at the
GIST level since state in the signalling applications can
cause GIST to come back to life anyway. But we should also
update section 7 to point out this aspect of the GIST/NSLP
interaction.

So much for approach (1). Option (2) which you suggest has some
attractions, and could for example be added as a backwards 
compatible extension at some stage (there are spare bits in
the common header, one of which could be defined as a hint
'ignore me if you have state from someone else'). However, I'd
be uncomfortable to make that change in this version. Partly
it's because we would effectively have two different sorts of
Query message with the processing depending on degree of state
synchronisation between Q and R node, and there are several new
cases to analyse (e.g. what if the Q node thinks something is 
a refresh but the R node does not; this would arise when route
changes were detected as part of the normal soft state mechanism).
Also, route flaps really do take place, so it might well be that
the flow returned to the 'old' path, but P1 was never able to
re-establish the state. We'd need another error message to 
indicate that a Query was rejected, and so on. I'm not saying
these issues are insoluble, but I think there is a case for
a more leisurely analysis. In the meantime, the clarifications/
refinements in section 7 will be included.

cheers,

r.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Thomas Herzog
> Sent: 28 November 2005 21:29
> To: [email-masked]
> Subject: Re: [NSIS] GIST Refresh Mechanism eventually breaks 
> upstream path onCrossover Router
> 
> 
> 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
> 
> 
> Am Montag, 28. November 2005 19:12 schrieb Thomas Herzog:
> > 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
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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