The Routing Over Large Clouds Mailing List Archive by date

[gardo@vnet.ibm.com]

Andrew,

>> Apparently there is no strong opposition for this proposal; please
>> add this to the version-5 draft.  Thanks!
>
>Hold on, hold on ... I'm not quite clear on exactly what are the mechanisms
>involved here (the packet format is the easy bit).
>
>> I propose that a destination address mask field be added to the
>> IP-specific part of the Purge packet.  With this feature, a much
>> more efficient purge can be performed; a single Purge packet can purge
>> a large number of cache entries, instead of sending a
>> large number of Purge packets...
>> I have not heard a strong technical reason against this proposal.
>> If there is one, please tell me; otherwise, let's add it.
>
>Some clarifications needed please:
>
>1. Is this just a control-traffic argument or do the wildcard-purge
>packets carry more semantics than just a string of simple-purge packets?

A simple 32-bit mask is added alongside the 32-bit destination that is
in the Purge packet.  There is no list.  This change adds a great deal
of flexibility to this purge feature...

>
>2. Presumably the only purges that can be condensed together are those from
>one particular NHS to one particular requester, correct?

That is what I had in mind, but maybe there is a way to enhance
further...  :-)

>
>3. A client now *must* index by destination (match on wildcarded destination
>to be more exact) and cannot use request-id for acting on the purge. Correct?

True, if the request-id in the Purge is zero.
The client must have a match on both the
destination and request-id if the request-id is non-zero.

>4. Doesn't this feature suffer from some of the same "state scaling" problems at
>intermediate nodes that caused the group to question the utility of the destination
>prefix extension?

Please refresh me on the details of this old discussion,
and remember we are deleting cache entries.

>Or are you assuming that purge messages not be interpreted
>by intermediate nodes and are just a private responder->requester interaction?

I would expect intermediate nodes that have cache entries that match
the Purge destination/mask would purge those entries.

>If the latter, then doesn't the purger have to send separate purges to each
>possible intermediate node that might have cached the previous response? Ugly.
>> >From a NHRP protocol standpoint, this Purge mask field should be
>> independent from the destination prefix extension found in
>> Request/Reply packets.
>>
>> Here are the only arguments I've heard against this proposal, but I
>> do not think they are strong enough to stop this proposal:
>>  1) If a client uses the destination to purge his cache, a mask does not
>>     complicate things.  An additional bit-wise AND operation does not
>>     complicate a client.
>
>It's more than just that one operation but I agree it's not much extra for a
>client which was doing destination address matches anyway.
>
>>  2) If the purge feature is only an optimization (an option that is not
>>     really required), then this should not add additional overhead in
>>     a minimal client implementation because these implementations
>>     can ignore Purge packets (only an optimization).
>
>This sounds like an interoperability can-o'worms. Or at least a very-suboptimal-
>performance can-o'worms. Shouldn't acting on a "purge" be mandatory? I'm more
>concerned about correctly functioning clients than minimal clients.

I misunderstood what was meant in a previous discussion when the
purge feature was called an optimization.  I interpreted this to mean
an optional feature.
The fact that the purge feature is an NHRP optimization should not
enter into this discussion about destination address mask...

>
>Andrew
>

-- Russell