Subject: [GSMP] ReturnReceipt and events

From: Avri Doria <[email-masked]>
Date: Tue, 16 Sep 2003 14:40:04 +0900

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

Submitter name: avri doria

Submitter email address: [email-masked]

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.

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

---

From: Georg Kullgren <[email-masked]>
Date: Mon, 22 Sep 2003 11:07:37 +0200

Avri Doria wrote:
> 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

Sounds good to me.

> 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.
> 
> 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    [email-masked]
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

---

From: Avri Doria <[email-masked]>
Date: Mon, 22 Sep 2003 19:13:13 +0900

Hi Georg,

> I can't see why Return Receipt is needed, but if there is a requirement

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.

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

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

>> things
> the controller it received the request from.

That is my assumption too.

> It is the controllers

i agree.

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

---

From: Georg Kullgren <[email-masked]>
Date: Mon, 22 Sep 2003 13:39:10 +0200

> no way to do that, that i can see, without requiring an ack, i,.e. a

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

> should not be ambiguous on this.

Ok.

> way for the controllers to discover that otherwise.

Ok.

> arrangement, e.g timers and retransmission, keeping track of who has

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

---

From: Kenneth Sundell <[email-masked]>
Date: Wed, 24 Sep 2003 18:38:08 +0200

Hi,

I have actually never seen a requirement for the ReturnReceipt other 
than the one in <draft-ietf-gsmp-reqs-06.txt>. But maybe I have missed it.
A controller could always poll the event count from time to time and 
detect missing/lost events by utilizing the Event Sequence Number field. 
So the question is, do we think this is enough for asynchronous events 
or do we really want them to be reliable?
 
Cheers,
Ken