ReturnReceipt and events

Short description of issue: Return Receipt should not be permitted for 
Events

Submitter name: avri doria

Submitter email address: [email protected]

Date first submitted:     030916

Reference: none

Document: base
Comment type: T

Priority: S

Section: 3.1.1

Rationale/Explanation of issue:   

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,

Full description of problem:

The problem, as i understand it, is that the switch will not know which 
event the controller is responding to since there is no transaction 
identifier. A second part of the problem involves knowing which 
controller is responding.   I don't think removing the receipt 
capability is the right answer.  I do agree there is a problem.

I think the problem is that the notion of transaction identifier needs 
to be fixed for messages that originate in the switch.  And I don't 
understand, in the context of GSMP, why knowing which controller has 
responded is important.

Requested change:   

In addition to changing the wording for transaction identifiers to 
indicate that they can originate in the switch as well as the 
controller, events need to include a transaction identifier.  But there 
should be a convention so that the identifiers don't collide.  W. Wang 
et al. in  draft-wang-forces-grmp-00.txt  has  a convention in the GRMP 
draft for transactions originating from the switch (in their case a fe).

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.

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