Subject: (ION) RFC 2332 again

From: "Albert Manfredi" <[email-masked]>
Date: Fri, 6 Nov 1998 10:57:35 -0500

Archana Nehru and I have had a brief exchange on this question about
how one can ensure that a shortcut (NHRP, RFC 2332) is in fact the
correct one. As the RFC is written, I'm not sure this is possible.
The basic problem is that the cached information at the requesting
NHC might be misleading. Seems to me that a new request must always
be transmitted, for every new shortcut, to prevent this problem from
occurring.

Let's say requesting NHC wants to reach 1.2.3.161. The requestor
will not know the mask of this destination, so it might request
1.2.3.161/16.

The request goes through the routed path, and an egress NHS is
connected to 1.2.3.*, so it replies with 1.2.3.161/24, perhaps. Or
worse, it replies with 1.2.3.161/16.

Now the requesting NHC caches this shortcut.

Next, the requesting NHC needs a shortcut to 1.2.3.193. Guess what?
The cached shortcut looks good. Use the same shortcut as before.

But what the source NHC doesn't know is that these two destination
hosts are in IP subnets masked 255.255.255.224, so that they might
very well be in different locations, with a better shortcut
available to reach 1.2.3.193. There could easily be an NHS at the
same location as 1.2.3.193, which is 10 miles from 1.2.3.161.

A proper response from this other NHS might be 1.2.3.193/27, for
example, meaning that _it_ is the router at .193's actual subnet.

So, bottom line, unless each shortcut is found with its own NHRP
request, I don't know how one can ensure that indeed the shortcut is
the best one? Not sure whether this has any implication on reducing
the risk of loops.

Bert
[email-masked]

X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Joel Halpern <[email-masked]>
Date: Fri, 6 Nov 1998 15:21:54 -0500 (EST)

> will not know the mask of this destination, so it might request
Presumably, it does this because it has a 1.2.0.0/16 routing table
entry...

> The cached shortcut looks good. Use the same shortcut as before.
Correct.  That is what the response meanse.

> same location as 1.2.3.193, which is 10 miles from 1.2.3.161.
If that were true, the responder MUST have replied with /27, not /24.  The
responder has to use the same rules as everyone else.  The only way he can
respond with the /24 is if he forwards the entire /24 off of the ATM.
There might be further divisions further downstream, but those can not
effect the correct exit from the ATM.  The /24 answer means that for all
destinations within the /24 prefix of the request, the responder is where
routing would take you.

> example, meaning that _it_ is the router at .193's actual subnet.
The is mandatory, not optional.

Yours,
Joel M. Halpern                         [email-masked]
Newbridge Networks Inc.

---

From: Archana Nehru <[email-masked]>
Date: Mon, 09 Nov 1998 09:56:19 -0800

Joel,
I have one more question on this.

Supposing a NHC1 registers 1.2.3.4 /16 with an NHS. Now suppose an
ingress NHC tries to resolve 1.2.4.5/16. When the resolution request
reaches the NHS, it looks up its registered cache and finds a match
there, and therefore will return 1.2.3.4/16 in the resolution reply. Now
immediately afterwards, suppose another NHC2 registers 1.2.4.5/24 with
the NHS. Does it not mean that the ingress NHC will be using a sub
optimal route(at least till the time it refreshes) for 1.2.4.5?

-regards
Archana

________________________________________________________________________
Archana Nehru                     :  Trillium Digital Systems, Inc 
E-mail: [email-masked]       :  Los Angeles, California     
Phone: +1 310 442 9222     
________________________________________________________________________
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Joel Halpern <[email-masked]>
Date: Wed, 11 Nov 1998 09:46:35 -0500 (EST)

There are two issues here.
One is with regard to registration, and one is with regard to routing
changes.

> Supposing a NHC1 registers 1.2.3.4 /16 with an NHS. Now suppose an
An NHC can not register a prefix.  A registration is always for a full
address.

> optimal route(at least till the time it refreshes) for 1.2.4.5?
If this occurs with routing (as opposed to registration), and the egress
router still has a path to 1.2/16, and the metrics have not changed since
the path was established, then you will keep using the sub-optimal but
loop free path.
Note that normally, this kind of situation will result in a routing
visible change if it occurs within the span of a single routing protocol.
That will cause either the ingress or egress routers (in the case of a r2r
shortcut) to reverify.  (For a host->router shortcut, this will usually
cause the egress to send a purge to the ingress, causing a reverify.)

Yours,

---

From: Archana Nehru <[email-masked]>
Date: Wed, 11 Nov 1998 10:22:36 -0800

> An NHC can not register a prefix.  A registration is always for a full

I am not sure why you are saying that NHC cannot register a prefix
(1.2.3.4/16)in its registration. This is the only way an NHC can
register a subnet.Isn't it?

> the path was established, then you will keep using the sub-optimal but

I am not sure why an NHS needs to look up the routing table in cases
where the prefix to be filled can be determined from the registration
cache itself. Supposing an NHC has registered the subnet 1.2.3.4/16
(1.2.*.*),when an NHS receives resolution request for 1.2.3.6/16, the
look up in the registered cache itself determines the prefix length.
Additionally the NHS should also check that there is no registered entry
like 1.2.4.7/24 which is a subset of the 1.2.*.* .If there is, NHS
should return 1.2.3.4/24. So isnot it enough for an NHS to not query the
routing table to fill the prefix length and depend absolutely on the
information that was registered with it?

-regards
Archana

---

From: Joel Halpern <[email-masked]>
Date: Wed, 11 Nov 1998 15:37:46 -0500 (EST)

My apologies on a misleading statement.  Jim Luciani pointed out to me
that an NHC can register a prefix.
However, if it does so, it better be correct. 
If an NHC registers 1.2.3.4/16, it better be able to directly reach all of
1.2/16.  Hence, it should not matter if someone else registers 1.2.4.7/24.
Note that this is different from the situation with routing in general,
where overlapping routes will take care of tehmselves.

Yours,