Subject: Re: (ION) RFC 2332 again

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

Joel, about this point:

>> 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.

>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.

I think this might need to be clarified or highlighted somehow in
the RFC. Maybe it's too cryptic and too far back, in Section 6 of
the RFC, I don't know. Maybe it's just me.

The point is that when the NHS that serves 1.2.3.33, 1.2.3,65, ... ,
and 1.2.3.161, all masked 255.255.255.224, replies to an NHRP
request, this NHS _must_ know that another NHS exists that serves
only the 1.2.3.192 subnet, and that therefore both of these NHS must
always respond with the 1.2.3.*/27 reply. Maybe this was clear to
everyone, but it wasn't obvious to me.

Thanks for the explanation, though. I think that this makes good
sense now. Until someone else comes up with a tricky question.

Bert
[email-masked]

-----Original Message-----
From: Joel Halpern <[email-masked]>
Date: Friday, November 06, 1998 4:33 PM
Subject: Re: (ION) RFC 2332 again

>On Fri, 6 Nov 1998, Albert Manfredi wrote:
>
>> 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.
>Presumably, it does this because it has a 1.2.0.0/16 routing table
>entry...
>
>> 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.
>Correct.  That is what the response meanse.
>
>>
>> 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.
>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.
>
>> 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.
>The is mandatory, not optional.
>
>
>Yours,
>Joel M. Halpern                         [email-masked]
>Newbridge Networks Inc.
>
>X-Info: To unsubscribe, email [email-masked]' with
>X-Info: 'unsubscribe ion' in the body of the message.
>

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

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 9 Nov 1998 15:43:33 -0500

-----Original Message-----
From: Archana Nehru <[email-masked]>
Date: Monday, November 09, 1998 4:33 PM
Subject: Re: (ION) RFC 2332 again

[ ... ]

>>So it might
>> ask for 1.2.3.4/16 without knowing that the actual entry should
be
>> 1.2.3.4/24. So the NHS replies to that request with 1.2.3.4/24
and
>> 1.2.4.1/24, let's say.
>>
>> Now the NHC only has one good choice.
>
>I am not sure why you are saying that an NHS will return the
1.2.3.4/24
>to the ingress NHC when the only match it finds in its registered
cache
>is 1.2.3.4/16. As I stated in my previous mail, 1.2.4.1/24 gets
>registered after the "reply"(1.2.3.4/16) has been sent to the
ingress
>NHC. So initially NHS could not have found 1.2.4.1/24 entry in its
>registered cache and therefore cannot return 1.2.4.1/24 to the
ingress
>NHC.So ingress NHC would use the sub-optimal route for some time.

Well, at the time that the shortcut was established, that route
_was_ the optimal one. You're saying what happens when a new route
is made available, after the fact.

Presumably, all of the cached values are aged and discarded
eventually. Right? So any new request would find the new routes. The
only question then is whether you should force an old call to be
torn down at some point.

>One alternative to avoid suboptimal routing could be that egress
NHS may
>purge the ingress NHC when 1.2.4.1/24 registers to inform the
ingress
>NHC that 1.2.3.4/16 is not a correct resolution. The ingress NHC
may
>then retry resolution and get both 1.2.3.4/24 and 1.2.4.1/24.

I don't think the NHS needs to purge anything necessarily. I think
cached values should be timed out, just like ARP tables are.

Bert

---

From: "Albert Manfredi" <[email-masked]>
Date: Mon, 9 Nov 1998 18:13:52 -0500

-----Original Message-----
From: Archana Nehru <[email-masked]>
Date: Monday, November 09, 1998 6:16 PM
Subject: Re: (ION) RFC 2332 again

>Albert Manfredi wrote:

>> I don't think the NHS needs to purge anything necessarily.
>> I think cached values should be timed out, just like ARP
>> tables are.
>
>Yes, that is an option too..it is probably an easier thing to do
>from implementation's point of view. The only disadvantage
>we have in that case is sub-optimal routing for sometime,
>which I guess is acceptable.

More or less unavoidable in a circuit-oriented system like ATM.
Actually, that's a "feature," because one problem with
packet-switched systems is their proclivity for changing routes at
the drop of a hat, creating havoc for QoS contracts. (Which is why
even RSVP would not permit such unscheduled route change.)

This general problem also exists in PNNI. What happens when PNNI
sees a different route come available? Does it shift existing VCs to
make use of the new route? Not unless you deliberately force the
connected users to periodically tear down and setup again their
calls. Same idea here, methinks.

The wireless ATM Working Group is toiling over this problem of
changing VCs dynamically, as the wireless user moves between "cells"
(used in the cellular phone sense of the word). I suppose something
of that sort could be introduced into all ATM switches at some
point. But there are tradeoffs to be considered.

Bert

---

From: "Andrew G. Malis" <[email-masked]>
Date: Mon, 09 Nov 1998 23:04:28 -0500

Majordomo didn't like this one for some reason ... please send replies to
Archana!

Andy

-------

>Sender: [email-masked]
>Message-ID: <[email-masked]>
>Date: Mon, 09 Nov 1998 14:21:02 -0800
>Organization: Trillium Digital Systems Inc
>X-Mailer: Mozilla 3.0Gold (X11; I; SunOS 5.5.1 sun4m)
>MIME-Version: 1.0
>To: Albert Manfredi <[email-masked]>
>CC: ION Group <[email-masked]>
>References: <[email-masked]>
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>Albert Manfredi wrote:
>
>Yes, I was just trying to point out that 1.2.4.* will be getting
>sub-optimally routed till the ingress NHC refreshes and gets back a
>1.2.3.4/24 and also 1.2.4.1/24 in response.
> 
>Yes, that is an option too..it is probably an easier thing to do from
>implementation's point of view. The only disadvantage we have in that
>case is sub-optimal routing for sometime, which I guess is acceptable. 
>
>Regards
>-archana
>
>________________________________________________________________________
>Archana Nehru                     :  Trillium Digital Systems, Inc 
>E-mail: [email-masked]       :  Los Angeles, California     
>Phone: +1 310 442 9222     
>________________________________________________________________________
>

---

From: Tim Salo <[email-masked]>
Date: Thu, 12 Nov 1998 14:06:32 -0600 (CST)

> Date: Wed, 11 Nov 1998 15:04:13 -0800
> 	[...]
> My assumption is that there is a traditional routing protocol like RIP
> etc running that maintians proper routing information at the NHS.
> 	[...]

A while ago I wanted to run RIP over Classical IP, but I couldn't
find a commercial MARS server.

Does anyone know of a commercial product that includes a MARS server?

Can I run routing protocols over ATM using IETF protocols and commercial
products?

-tjs