The Routing Over Large Clouds Mailing List Archive by date

[gardo@vnet.ibm.com]

>Russell,
>
>> This change adds a great deal of flexibility to this purge feature...
>
>Is it flexibility for flexibility's sake you are looking for or do you
>have some reason for it e.g. a reduction in control traffic?

Less control traffic, quantity of state data, more rapid convergence,
a more flexible purge feature, etc.

>>>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.

>Do all wildcard Purges will contain zero request-id?  (I've still not
>seen any text from you describing the semantics of wildcard purge).
>Do you think that any reduction in control packets outweighs the
>(potential) extra processing involved in doing a wildcard destination
>lookup rather than a request-id lookup?  Do you think that you will
>often have one NHS being able to coalesce multiple purges together
>back to the same requester - can you describe a scenario where that is
>likely?

Yes, The preferred route to a particular network changes requiring a
refresh of the cached data.  The NHS can send multiple Purge packets for
all destinations belonging to this network that are cached;  Or with
a mask, the NHS can send a single Purge packet with the associated
network mask...

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

>...and remember which way(s) to forward the Purge:  it has to be
>forwarded back along the same path that the original response messages
>went, rather than the current routing path, doesn't it?  It is
>precisely when routing is changing that the purges are most useful and
>the caches in intermediate nodes most useless, right?.

This intermdiate node subject applies to both Purges with or without
a mask.  Correct?

>>>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.

>Is this true? [ NHRP sounds more and more like a real routing protocol
>by the minute .... ]

Since the purge feature has been added, let's do it right.  Maybe
it was a mistake to add the purge feature to NHRP ???

>It may well be that the mask is a useful feature - I'm just playing
>devil's advocate here (as usual) in order to see a better
>justification for its inclusion:  the shorter the spec is, the better
>for everyone so long as it does its job, so any feature really needs
>good reasons, not to mention good explanatory text:  I've not seen
>much so far and you did issue a "mini-last-call" on its inclusion.
>
>Andrew

Have a nice day!
-- Russell