Re: [GSMP] ReturnReceipt and events

[Georg Kullgren <[e-mail]>]

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


> To paraphrase
> 
>         first bit = 0           Controller generated Transaction Identifier
>         first bit = 1           Switch generated Transaction Identifier
> 
> I would like to adopt this convention for GSMP.

Sounds good to me.


> 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.
And, if we require this amount of communication between multiple
controllers then I don't see the reason for the Adjacency Update Event.
The controllers should already be communicating with each other.

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


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


Regards
/Georg
-- 
------------------------------------------------------------------------
Georg Kullgren            Nortel Networks AB    [e-mail]
Systems Architect         S:t Eriksgatan 115 A  Tel:   [phone]
Routing Architecture Lab  SE-113 85 Stockholm   Mobile: [phone]
ATI Strategic Protocols   Sweden                Fax:   [phone]


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