Subject: (ION) Revalidating routing

From: Albert Manfredi <[email-masked]>
Date: Wed, 08 Jul 1998 15:59:06 -0400

In reference to draft-halpern-ion-r2r-00.txt.

This extension to NHRP is aimed at eliminating the possibility of
routing loops. It also stipulates that: "Both ends of a shortcut
have to monitor the status of the route ..."

1. If the status changes with respect to the destination NHS, it
must issue a Purge message. This causes the requester to re-issue an
NHRP request.

2. If the requesting NHS notices a change, it would also result in
another NHRP request being sent by that requesting NHS.

Let's say the initial loop-free routing has done its job and that
while the SVC shortcut is in place, something breaks in the ATM net
(e.g. one of the NHSs involved in setting up the shortcut). Is there
any reason not to let PNNI fix the ATM net without new NHRP requests
being sent and without the IP layer even caring?

In principle at least, the PNNI fix would be at least as effective
as any new NHRP route (always assuming more ATM switches than NHSs
in the net). So for the duration of that SVC, anyway, why not let
ATM take care of itself? I mean, just because some NHS along the IP
route breaks while this SVC is active, it does not mean that this
nice, straight shortcut is any less good, right?

Or perhaps this is an example of when the C bit (MSbit of the
extension) should be set to 0? So, would the C bit set to 0 result
in a "more robust" solution? The implication in this draft is no,
but depending what the NBMA network is, the answer could be yes.
Yes?

Thanks.

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: Wed, 8 Jul 1998 16:18:16 -0400 (EDT)

On Wed, 8 Jul 1998, Albert Manfredi wrote:
[text elided]
> being sent and without the IP layer even caring?

It would seem ok -- for a little while -- to wait and see if PNNI can fix
things.  Routing probably will wait a little bit to see if the links come
back up.  So, if VCs can be re-established, this will be ok.  However, if
it is ok, it is likely that it will occur before any routing visible
change occurs.

I suppose one could put in a time delay before acting on a routing change,
but one is probably black-holing packets in the mean time.
Note that it will be difficult to tell from the routing change indications
whether the changes were inside the ATM net, or outside it.  It will also
be difficult to tell whether the change was an ATM failure or a router
failure.

So, while in principle this sort of delay is possible, in practice it does
not strike me as effective.  Others may disagree.

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

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 08 Jul 98 13:23:52 PDT

Bert,

> have to monitor the status of the route ..."

Please also notice the last paragraph in Section 10:

   This document doesn't have a proof that the mechanisms described here
   result in loop-free steady state forwarding when NHRP is used to
   establish shortcuts among routers.

That is, while the document *aims* at eliminating the possibility
of forwarding loops, there is no *proof* that the procedures
described in this document are *sufficient* to achieve this aim.

Of course, one could postulates that the procedures described
in the document are sufficient...

Yakov.