Subject: RE: (ION) widest acceptable prefix

From: Nick Weeds <[email-masked]>
Date: Wed, 21 Oct 1998 15:20:44 +0100

>-----Original Message-----
>From:	Srinivasan Balaji [SMTP:[email-masked]]
>Sent:	Wednesday, October 21, 1998 2:50 PM
>To:	Nick Weeds
>Cc:	'Joel Halpern'; [email-masked]'
>Subject:	Re: (ION) widest acceptable prefix
>
>If I have understood your question correctly,
>  1.2.4.x/24 is anyway incorrect as we want to reach 1.2.3.x/24 and
>1.2.4.x/24
>doesn't take us there.
>
Maybe I didn't explain my concern correctly.  It's true that route
1.2.4.0/24 doesn't match the original request 1.2.3.4/8.  However, it
does overlap with our chosen route 1.2.0.0/16.  If we just use route
1.2.0.0/16 and update the request to 1.2.3.4/16, then the reply might
get back to the client as 1.2.3.4/16.  In this case, the client would
probably use the reply for all destinations 1.2.x.x/16, which would give
sub-optimal routing for addresses 1.2.4.x.  The end result is that by
ignoring 1.2.4.0/24 when updating the request, the client might end up
using a sub-optimal route.  This is essentially the situation described
in RFC 2332 section 6.3 condition (b).  If RFC 2332 section 6.3
condition (b) applies in this case then we would have to update the
prefix length in the request to be at least 24.

> Only (1) would be the right one[ultimately the egress
>NHRP router would set the final value greater or equal to 16], as far as (3)
>is
>concerned, there is nothing like prefix length of 0xff, the largest is 32
>(host
>route) and since this router doesn't have a host specific route, 1.2.3.4/32
>would also be incorrect.
>
It's a minor point, but prefix length 0xFF is permissible.  In fact RFC
2332 section 5.2.3 requires prefix length to be set to 0xFF in an NHRP
Resolution Request with the U flag set.  I think the idea is that prefix
length 0xFF is a protocol-independent encoding for "match the entire
host address".
>
>Nick Weeds wrote:
>
>> Joel,
>>
>> Thanks for this explanation.  It makes the intention much clearer.
>>
>> If I understand you correctly, it is important for NHRP routers which
>> forward NHRP Resolution Requests to update the prefix length.
>>
>> Suppose a transit NHRP router gets a request for 1.2.3.4/8, looks up
>> 1.2.3.4 in its routing table and finds an entry for 1.2.0.0/16.
>> Presumably in this case the NHRP router MUST update the prefix length in
>> the request to be at least 16.  Is this correct ?
>>
>
>Yes.
>
>> What if the NHRP router has routing table entries for 1.2.0.0/16 and for
>> 1.2.4.0/24 ?
>> The router might update the request to be any of the following:
>>
>> (1) 1.2.3.4/16
>> This uses a simple routing table lookup of 1.2.3.4 but gives a
>> sub-optimal route for 1.2.4.*.
>>
>> (2) 1.2.3.4/24
>> This requires a more complicated routing table lookup to spot the
>> 1.2.4.0/24 route.
>>
>> (3) 1.2.3.4/0xFF
>> This avoids sub-optimal routing and complicated routing table lookup by
>> setting prefix length = 0xFF in all cases.
>>
>> Which of these 3 actions is acceptable ?
>>
>> Thanks,
>>
>>         Nick.
>>
>> >-----Original Message-----
>> >From:  Joel Halpern [SMTP:[email-masked]]
>> >Sent:  Monday, October 19, 1998 9:04 AM
>> >To:    Fox, Barbara
>> >Cc:    'Albert Manfredi'; [email-masked]'
>> >Subject:       RE: (ION) widest acceptable prefix
>> >
>> >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.
>> >
>> >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.
>
>
>
>--
>
>-----------------------------------------------------------------
>Srinivasan Balaji           Voice : (732) 283-2770 xtn.303
>Ficon Technology            Fax   : (732) 283-2848
>1000 Route 9 North          mailto:[email-masked]
>Woodbridge, NJ 07095        Web   : http://www.ficon-tech.com
>-----------------------------------------------------------------
>
>
X-Info: To unsubscribe, email [email-masked]' with
X-Info: 'unsubscribe ion' in the body of the message.

---

From: Srinivasan Balaji <[email-masked]>
Date: Wed, 21 Oct 1998 10:48:45 -0400

I probably tried to respond too quickly, it should have been 1.2.3.4/24. I agree
that 1.2.3.4/16 would give subobtimal path, Thanks for correcting me.

Regards,
Balaji.

--