Re: Application Statement
"j.garrett" <jwg@garage.att.com> Thu, 09 March 1995 07:08 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28003;
9 Mar 95 2:08 EST
Received: from maelstrom.acton.timeplex.com by IETF.CNRI.Reston.VA.US
id aa27999; 9 Mar 95 2:08 EST
Received: from gw2.att.com (gw2.att.com [192.20.239.134]) by
maelstrom.acton.timeplex.com (8.6.9/ACTON-MAIN-1.2) with SMTP id CAA09661 for
<rolc@maelstrom.timeplex.com>; Thu, 9 Mar 1995 02:03:40 -0500
Received: from garage.UUCP by ig1.att.att.com id AA25318;
Thu, 9 Mar 95 02:05:28 EST
Message-Id: <9503090705.AA25318@ig1.att.att.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "j.garrett" <jwg@garage.att.com>
Date: 9 Mar 95 02:04:00 -0500
Original-From: garage!jwg (j.garrett)
To: jhalpern@newbridge.com
Cc: rolc@maelstrom.timeplex.com
Subject: Re: Application Statement
Joel, After some more thought I understand your point. There is no guarantee that routing will determine that the next-hop to a next-hop is the next-hop. That is, routing could determine that router R1 is the next-hop to some destination, and also determine that router R2 is the next-hop to router R1. In this case an NHRP request would be sent to R2 and this NHRP transaction would resolve the address of R1. Therefore, my assertion in a couple of postings to the ROLC list that NHRP can not do address resolution of a next hop determined by routing was wrong. I do hope that if routing is able to use router R1 as a next-hop, that routing (and address resolution) will be clever enough to send packets addressed to R1 directly to R1, without going through some other next-hop router. This said, I will offer one observation. If you want routing to determine which IP prefixes can be reached without going through a next-hop router, and don't want the routing decision to be made independently for each host address, and if you want an address resolution procedure that will resolve a host address, the address resolution procedure better not depend on sending a query to the (non-existant) next-hop identified by routing. Moreover, if routing has learned from a routing peer that the host can be reached without going through a next-hop router, the routing peer that provided this information is a good candidate to help resolve the host's address. John Garrett !h
- Application Statement dhc2
- Re: Application Statement Curtis Villamizar
- Re: Application Statement dhc2
- Re: Application Statement Jeffrey A. Buffum - Bay Networks
- Application Statement yakov
- Re: Application Statement Curtis Villamizar
- Re: Application Statement j.garrett
- Re: Application Statement Juha Heinanen
- Re: Application Statement Jeffrey A. Buffum - Bay Networks
- Re: Application Statement j.garrett
- Application Statement yakov
- Application Statement yakov
- Re: Application Statement Bruce Cole
- Application Statement yakov
- Re: Application Statement yakov
- Re: Application Statement Bruce Cole
- Re: Application Statement Bruce Cole
- Re: Application Statement j.garrett
- Re: Application Statement Curtis Villamizar
- Re: Application Statement j.garrett
- Re: Application Statement Curtis Villamizar
- Application Statement yakov
- Application Statement yakov
- Re: Application Statement Ross Callon
- Re: Application Statement Ted Matsumura
- Application Statement dhc2