Re: NHRP question

[Eric Gray <[e-mail]>]

Yakov,

	The redundancy between these bits is largely an issue of usage.  The
fact that a query source is a host (or a router) is significant in
determination of whether or not the information contained in a request
is "stable" (at least to some implementations) but is none-the-less a
fact that might be worth knowing.  The same thing applies to whether or
not _each_ destination in a response is a host or router.  The issue of
stability verses source/destination type should be treated as orthogonal
and the bits retained - after all, the minute someone comes up with an
example of why the information MUST be treated as orthogonal, the bits
will neeed to re-inserted and this would be likely to be an issue with
future backward compatibility.



						Eric Gray

Subject: Re: NHRP question
Date: Thu, 19 Oct 95 05:11:25 PDT
From: Yakov Rekhter <[e-mail]>
To: [e-mail] (Joel Halpern)
CC: [e-mail]

Joel,

> Last time I spoke to Yakov about the router to router case, his goal was to
> eliminate all unsafe router-router cases.  There are safe cases.
> The intend of the combination of Q, S, and B bits was to identify the
> applicable cases.

As I mentioned in my other note, use of the current NHRP format (and
specifically its fixed header) may be a problem for the router-router
NHRP. So, I'd like to decouple the discussion on whether the
combination of Q, S, and B bits would be useful for the router-router
NHRP from the question I asked -- whether Q and S bits are useful for
the current (non router-router) NHRP. Let's focus (at least for now)
on the current NHRP.

> The general goal was to be able to tell if the requestor was a host
> or router, and whether the responder was someone it was safe for the
> requestor to talk to.
>
> 1) It seemed useful to distinguish between the "stable" case identified
> by the "B" bit, and the more specific case when the responder is a
> directly attached host.  Clearly it is not critical.

Do we have a practical example of when such distinction would be useful ?

>
> 2) One could say that a source equivalent of the "B" bit would be better
> than the "Q" bit.  It would be more general.  However,
>     Most of us are probably assuming that information learned on behalf
>     of one source can be used for/with other sources.
> If that is true, then the fact that a specific request is on behalf of
> an on-subnet host is not particularly important.  Therefore, what is
> needed to detect safety is the Q bit.

But the "B" bit (stable) carries sufficient semantics. So, why do
we need the "Q" bit ?

> In particular, an interdomain request is safe if the Q bit is on in the
> request, or the B bit is on in the response.  We could get rid of the S
> bit, although I think it is a useful subset of "B" to identify.

As you just indicated, there is redundancy among Q, B and S bits. I've
yet to see a practical example where this redundancy is needed.

I think that a single bit (indicating "stable" information) would be
sufficient. On the Request this bit would indicate that the information
provided by the originator of the Request is stable. On the Reply this
bit would indicate that the information provided by the originator of
the Reply is stable.

And if one bit is sufficient, then we should clean up the spec and
eliminate the other two.

Yakov.