Re: ReturnReceipt and events

Avri Doria wrote:
> Hi Georg,
> 
> On måndag, sep 22, 2003, at 18:07 Asia/Seoul, Georg Kullgren wrote:
> 
>> Avri Doria wrote:

>> I can't see why Return Receipt is needed, but if there is a requirement
>> for it...
> 
> 
> Well if there is an event that the switch must make sure is reliably
> conveyed (because the Controller has configured it to do so), there is
> no way to do that, that i can see, without requiring an ack, i,.e. a
> return receipt.

Yes, I agree that this is the way to do it if the event has to be
reliably transmitted. What I don't get is why it has to be reliably
transmitted.

On the other hand, if we allow it we at least won't end up with a
crippled protocol if when we discover there is a need for reliable events...

>> This is where I got confused concerning Return Receipts.
>> If the switch should be satisfied after receiving the first receipt,
>> this should be clearly stated in the draft.
> 
> 
> Well that is the indeed the question i am trying to clear up.  The
> current spec is ambiguous on this.  And I agree with you that the spec
> should not be ambiguous on this.

Ok.

> 
>> And, if we require this amount of communication between multiple
>> controllers then I don't see the reason for the Adjacency Update Event.
>
> 
> The adjacency is just to let the controllers know that there are
> others.  While it is isn't for the switch to coordinate their
> activities, it seems to make sense that there should at least be an
> indication that one has either come or gone.  This can be especially
> important when one of the adjacencies is lost as there may be no other
> way for the controllers to discover that otherwise.

Ok.


>> One transaction should be handled by one controller. When the
>> transaction is complete the other controllers will be updated with the
>> new information (don't know how. Not in our scope.).
>> Events are a different but I would prefer to require each controller to
>> respond to a ReturnReceipt.
> 
> 
> I am fine with this option, though it does require a more complicated
> arrangement, e.g timers and retransmission, keeping track of who has
> responded, etc..

Yes, but I don't think this will have a big impact on the
implementation. The timers and retransmission part is already there in
case no controller returns a receipt. Keeping track of who has responded
is added though, but that should be easy to add.

> 
> Also with the flow control mechanisms it is possible that one or more of
> the controls might indicate they don't want to receive the events.  This
> is allowed and could be due to controller specialization.  So making
> sure that all except those who don't care about the event is more
> complicated.  And I don't know if and why it would be necessary.

Still, I don't think it is much different from checking that the receipt
is for the right event. Only difference is that we now also have to
check the transaction id.


Regards
/Georg
-- 
------------------------------------------------------------------------
Georg Kullgren            Nortel Networks AB    [email protected]
Systems Architect         S:t Eriksgatan 115 A  Tel:   +46-8-50 88 36 18
Routing Architecture Lab  SE-113 85 Stockholm   Mobile: +46-703-14 36 18
ATI Strategic Protocols   Sweden                Fax:   +46-8-50 88 35 01