Subject: section 5 changes

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 20 Sep 2005 14:01:08 -0400

Again lots of changes here, so i am not gonna supply a diff.
Please review closely - hopefully we can close before meeting.
I will post the next thing once i see substantial activity on this one.

Some of the changes made are:
- New additional flags
- lots of text rearrangement and cleanup

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Wed, 21 Sep 2005 09:20:14 +0800

Jamal,

That's really great. It looks much better than before. 

Only one more change is needed,  that is, the part on ACK flag that I proposed, because we now agree to allow HB messages also use this flag.  The related change on the HB message definition (section 6.9) is also needed then. I can try to make the section 6.9 change and I hope you make the change in this section 3, is it all right?

Thanks so much.
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 21 Sep 2005 06:22:38 -0400

On Wed, 2005-21-09 at 09:20 +0800, Weiming Wang wrote:
> Only one more change is needed,  that is, the part on ACK flag 
> that I proposed, because we now agree to allow HB messages also 
> use this flag.  

Are you still talking about section 5? I looked at the ACK section and
didnt find a good place to mention HB.

> The related change on the HB message definition 
> (section 6.9) is also needed then. I can try to make the section 
> 6.9 change and I hope you make the change in this section 3, 
> is it all right?
> 

Yes, indeed.

cheers,
jamal

---

From: Weiming Wang <[email-masked]>
Date: Wed, 21 Sep 2005 22:54:50 +0800

----- Original Message ----- 

> didnt find a good place to mention HB.

! The 1st place is: 

       - ACK: ACK indicator(2 bit)
           The ACK indicator flag is only used by a Config Message
           sender to indicate the message receiver whether or not a
           config response is required by the sender.  Note that all
           other messages than Config Message MUST ignore this flag.

! propose to change to:

- ACK: ACK indicator(2 bits)
The ACK indicator flag is only used by a sender of Config Message (Section 6.5) or Heartbeat Message (Section 6.9) to indicate the message receiver whether or not a response is required by the sender for the message.  Note that all other messages MUST ignore this flag.

! The 2nd place is:

        Also note that messages other than Config Message, ...

! should be changed to:

        Also note that messages other than Config Message and Heartbeat Message, ...

! 3rd place is:
          +   Association Teardown Message, Packet Redirect Message,
               and Heartbeat Message never expect responses.

! should change to:

          +   Association Teardown Message and Packet Redirect Message
              never expect responses.

Thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Sep 2005 09:53:02 -0400

I had thought we had agreed to a 64 bit correlator rather than a 32 bit 
correlator and a 32 b it sequence number (which is not defined as a 
sequence number, but still named that.)

Should the paragraph after the table of ACK modes say that the failure 
results in an ACK if the ACK indicator has been set to 'FailureACK' or 
'AlwaysACK'?  I realize that if the indicator is set to 'AlwaysACK', the 
the ack will occur on success as well.  I am just afraid that the wording 
may lead a lax coder to code the failure branch to only test for 'FailureACK'.

The TLV nesting structure does not match the XML LFB definition 
structure.  Nesting Path-DATA TLVs is an optimization, not a mapping of the 
XML.

In the TLV diagram, the "variable" before "TLV Length" looks odd

In the ILV section, we should note that the I values have only local scope, 
defined by the data declarations of the appropriate scope from the LFB 
definition.  Otherwise a reader may expect ILVs to have global uniqueness, 
and they don't.

Yours,
Joel

PS: Sorry I could not get to this earlier.

---

From: Weiming Wang <[email-masked]>
Date: Thu, 22 Sep 2005 22:23:12 +0800

Jamal,

Thanks very much for the review.

----- Original Message -----
From: "Joel M. Halpern" <[email-masked]>

> sequence number, but still named that.)
Joel,  I think the issue on 64bits correlator or 32-32 SN and correlator is
still pending as in issue 47.  In fact,  the more I think it, the more I feel
the necessity for the SN need.  Just lets try to thik it inversely, if there is
no such SN, we actually has removed any possibility for PL layer to order back
messages. I just think such ordering may be necessary for some usages where some
application layer  of Redirected messages itself do not supply  ordering back
function while the order is important for the application.  Note that redirect
message application level is an open level, we may not be able to limit it to
SNMP, RIP, etc, where ordering is not a problem, we may easily go to the point
that ordering at ForCES layer is helpful for some applications in a very near
future for ForCES deployment.

> may lead a lax coder to code the failure branch to only test for 'FailureACK'.
That makes it  nice  to programmers.  Jamal, could you help to add some text?
Thanks.

> definition.  Otherwise a reader may expect ILVs to have global uniqueness,
I agree. The I local scope  should be mentioned  in the text.

Thanks,
Weiming

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 22 Sep 2005 11:43:17 -0400

Let me separate the issues a little.

Redirect packets are, by definition, IP packets that are intended to flow 
over the internet.  They are either packets arriving at the FE, which the 
FE concludes the CE should process, or packets the CE has handed to the FE 
for transmission.  The Internet is not an order preserving media.  There is 
clearly no requirement for order preservation either within the stream of 
redirect packets or between that stream and the control stream.  [Clearly, 
gratuitious misordering is undesirable, but that is not what is being 
discussed.]

For control, the TML is required to provide reliable transport.  We have 
not required that it provide in order delivery.  I would hope we won't put 
on such a requirement.

Note that a correlator will allow the CE to locally reorder responses (if 
it chooses and needs to), since the CE can know what order it sent the 
requests to which the responses are being received.

We could mandate a uni-directional sequence number for messages originated 
on either side.  However, use of that would be a local matter to that side, 
as the receiver would never care about the order.  As such,  that is one 
possible use of the correlator.

Finally, we could claim that we need to know the sequence of transmission 
between locally originated messages and responses (i.e. order between 
responses from the FE and notifications from the FE.)
I do not belive the protocol needs this.
And the text for the section as written does not provide this.
We did discuss preserving the sequence number for this purpose, and the 
rough consensus I heard was that it was not needed.
If we really need it, we can put it back.  Please explain why it is needed.

Yours,
Joel M. Halpern