Subject: Re: (ION) Non-member submission ...

From: "Paul Henri" <[email-masked]>
Date: Mon, 02 Nov 1998 12:17:35 -0500

[email-masked] wrote:

> 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.
>
> X-Info: To unsubscribe, email [email-masked]' with
> X-Info: 'unsubscribe ion' in the body of the message.

Sanjeev,

Thanks for the clarification; Best one yet. I have more
questions/comments:

- When the nhc is revalidating a cached entry with a prefix length such
as /16 (I agree that the original request had a /32), one would think
that the contents of the resolution request would be x.y.0.0/16. Rather
than having transit routers which forward the request *modify* the
prefix length, why can't the routers follow the simple rule of not
forwarding the request if the router's route has a prefix length longer
than /16? Routers with, say, /8 routes would forward because /8 is a
superset of /16.  Assuming the prefix length gets longer along the
routed path (valid?), the last/egress router will likely be the one
which returned the /16 in the first place.

- Using the above logic, note that handling a /32 request is dead easy
because transit routers can't have routes with masks longer than /32.

Regards,
pdh

--
Paul Henri
[email-masked]

---

From: [email-masked]
Date: Mon, 02 Nov 98 12:52:45 -0500

Paul pl see my replies embedded below ...

> as /16 (I agree that the original request had a /32), one would think

actually the original request would have had to be a /16 or ``less'' 
in order to get back /16 in the response ...

> that the contents of the resolution request would be x.y.0.0/16. Rather

Not necessarily, the request can still try with /1 in order to try to get 
any more aggregation (in case routing has changed) than the last time

> which returned the /16 in the first place.

they could decide to not forward if they so wish but that is unnecessarily 
reducing the possible shortcutting since at least some subset of the prefix
could have utilized the shortcut. Basically treat each refresh also just 
like the original request and each time try to obtain the maximal 
aggregation which does not cause misrouting. If the prefix returned on a 
refresh response is different from that in the previous response, the 
requestor should immediately update his shortcut cache accordingly ...

Sanjeev.

ps:
btw the spec wording could certainly have been a little more explicit 
to ensure handling prefixing is clear enough ... In particular it ought 
to mandate the initial setting of the CIE prefix and handling of 
cases where no CIE was present in the request in the first place ...