Re: [GSMP] ReturnReceipt and events

[Avri Doria <[e-mail]>]

Hi Georg,

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

> Avri Doria wrote:
>> 3.1.2 of the GSMP requirements  state that Return Receipt should not 
>> be
>> permitted for events.  As the return receipt was the response to a
>> requirement in the earlier version of the protocol, I do not believe
>> this is the correct response to the problem
>
> 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.

>
>> As for the problem of knowing which controller responds to the 
>> receipt,
>> I think that one is out of bounds for the GSMP protocol as currently
>> specified.  Currently the switch responds to any controller it has an
>> adjacency with.  All masters are equal and it up to them to decide 
>> what
>> needs to be done.  I think the same philosophy should go for notifying
>> them of events. I think that switch satisfies its return receipt
>> requirements by receiving the first one.
>
> 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.

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

There was a lot of discussion several years ago about what information 
should be conveyed in such an event.  The conclusion was only its 
system identifier and the fact that is has come or gone.  It is up to 
controllers at that point to coordinate among themselves.


> The controllers should already be communicating with each other.

Yeah, this is just to make sure that they can, in case they did not do 
so prior to establishing adjacency.

>
> I would like to hear some more comments about how this should work...

Me too.

>
>
>>  At that point, the switch can
>> 'know' that the message has been received in the control plane, which 
>> is
>> all that really matters.
>>
>> On the other hand, if for some reason it is critical to know that all
>> controllers have received the event, then the switch is free to count
>> receipts against the adjacency count the switch has.
>>
>> If consensus is that the switch should have finer control of such 
>> things
>> and should know which controller it is talking to and which it is
>> responding to, then the entire notion of multiple controllers needs to
>> be reviewed and issues having to do with per message controller 
>> identity
>> and with unicast and broadcast of responses and events needs to be
>> considered.  I would prefer to avoid this unless it is necessary for 
>> any
>> of the functionality we need for GMPLS support.
>
> I have always assumed that the switch will always send the response to
> the controller it received the request from.

That is my assumption too.

> It is the controllers
> responsibility to syncronise current state of the partition, but I 
> think
> we require too much from the controllers if we allow a response to be
> sent to any controller.


i agree.

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

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.

Other opinions?


thanks for the comments.

a.


_______________________________________________
GSMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gsmp