[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Hi Iljitsch,
> > Detecting that there was a 'failure' due to a firewall is also quite
> > difficult to determine anyhow. The only way would be to compare
> > multiple address pairs and determine in one case it works but
> > in another it doesn't work; and be sure that it wasn't just a
> > transiant
> > failure.
>
> I'm not sure what your point is. Either a firewall lets the shim
> packets through and then we consider the link working (well, if it
> does indeed work of course), or it doesn't, and we consider the link
> not working.
>
> In a pathalogical case it would be possible for an upper layer to
> fail consistently so it doesn't provide positive advice / provides
> negative advice all the time so we need to probe reachability more or
> less continously, but our probes would still make it.
Jari was worrying that for some ULPs, firewalls will let packets through,
but not for all ULPs. In this case, how do we classify this negative feedback?
I guess I am thinking that this might be an unsolvable problem, because I
don't think that the shim layer will know why a certain ULP failed
and another ULP succeded. It could be because there is no route for
one of the ULPs; it could be because someone typed a wrong URL; there
could be a momentary glitch; it could be due to firewalls, etc.
I'm sort of thinking that if we support negative feedback, that we
have to be careful about what we infer in terms of signifigance of the
failure.
John