Subject: (ION) Non-member submission from ["Paul Henri" <[email-masked]>]

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 30 Oct 1998 17:23:08 -0500 (EST)

Sorry, I meant to forward this to the list last week.  Paul has now
been added to the list sender list.

Andy

---------- Forwarded message ----------

Date: Mon, 19 Oct 1998 10:56:51 -0400
From: "Paul Henri" <[email-masked]>
Organization: Nortel
X-Mailer: Mozilla 4.06 [en] (X11; I; SunOS 5.5.1 sun4m)
MIME-Version: 1.0
To: [email-masked]
Subject: Re: (ION) widest acceptable prefix
References: <Pine.GSO.3.96.981019040247.1504W-100000@lobster>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Joel Halpern wrote:

> Sorry, I got lost in the (1)s and (2)s.  The intend was:
>
> If you request an answer of length x, you will never get an answer shorter
> than length x.
>
> This is not so much for the originator  (he is probably only willing to
> accept /32, or willing to accept anything), but for the progression.  It
> is important that the match only get lengthened as it goes from router to
> router.  If the mask got shortened, it could produce incorrect overlapping
> resolutions.
>

I am having trouble making sense of this. Barbara's response seems more
logical to me. If the requestor is looking for a /24 (for reasons only it
knows), it may be inappapropriate to respond with something which is
represents a subset of the /24 (eg. /32). A superset (eg. /16) covers the
request, and more.

Consider the obvious case of an nhc sending a request for a /32. If this
request arrives at an egress nhs which knows that the specified host is on a
locally-attached subnet, the nhs should be able to reply with the subnet mask
(say /24). The nhc can use the mask to reduce the size of its resolution
cache table. Isn't this a case of a shorter prefix being used to satisfy a
request?

Regards,
pdh
--
Paul Henri
[email-masked]

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

---

From: [email-masked]
Date: Fri, 30 Oct 98 18:01:45 -0500

Paul, 

the requestor does not have any reason to ask for anything 
other than /32 or /1. Either it is capable of shortcutting 
to prefixed destinations (in which case it would want the 
maximum possible aggregation) or it is not (in which case it 
requests /32). (The reason some requestors might not be capable of 
handling prefixes is that it requires efficient longest prefix
match lookups ...). It does not know of the different 
possible prefixes for that destination along the routed path, 
only the routers themselves know that.

The ``range'' of destinations should only get more specific 
as the request traverses forward to prevent misrouting. 
For example if R1 has different next hops for 9.1.*.* and 
9.2.*.* but R2 has the same next hop for all destinations in the 
range 9.*.*.* then if we are requesting resolution for 9.1.1.1, 
we should not be able to use that shortcut for traffic to 9.2.1.1 
since the routed paths for these two destinations are different. 
So the prefix returned should not be 9.*.*.* (as the egress NHS 
might have preferred) but 9.1.*.*.

Sanjeev.