Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

From: "Putzolu, David" <[email-masked]>
Date: Tue, 1 Nov 2005 18:11:36 -0800

All,

The authors of the ForCES protocol have requested
working group last call and the document appears to
have stabilized and reached a technically complete state. 
URL:

http://ietf.org/internet-drafts/draft-ietf-forces-protocol-05.txt

This email begins a last call period for the ForCES
protocol document. This last call period is 
two weeks in length and ends on Tuesday, November 15th
one week after the ForCES meeting at IETF 64.

Please send to the list any suggested changes
and/or comments on this document.

Thanks,
David & Patrick

---

From: Alex Audu <[email-masked]>
Date: Wed, 9 Nov 2005 11:39:11 -0500

Hi All,
 
I read the latest protocol draft and these are my comments:  
 
The authors did a good job in documenting the structure of the messages in detail. That is great for
consistent API implementation and interoperability.  However, there was not the same attention 
given to documenting the protocol behavior.  This can easily lead to different implementations 
behaving differently - a classic interoperability problem.
 
There was an attempt to address some of this in the scenario section. But this section  only contains few examples and is typically not exhaustive. If there are normative beahoirs called out here, they should be moved into the protocol message description section for the respective messages. 
 
Also the protocol state machine needs more work. It needs to be redundancy-aware.  Remember that
accurate element state management is key to providing loss-free service.  
 
Please see attachment for full details of comments.
 
Regards,
Alex.
www.garlandsoftworx.com

 
-----Original Message-----
From: Putzolu, David <[email-masked]>
To: [email-masked]
Sent: Tue, 1 Nov 2005 18:11:36 -0800
Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

All,

Thanks,
David & Patrick

---

From: Alex Audu <[email-masked]>
Date: Wed, 9 Nov 2005 11:39:16 -0500

Hi All,

 

 
Regards,
Alex.
www.garlandsoftworx.com

 
-----Original Message-----
From: Putzolu, David <[email-masked]>
To: [email-masked]
Sent: Tue, 1 Nov 2005 18:11:36 -0800
Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

All,

Thanks,
David & Patrick

---

From: louati <[email-masked]>
Date: Mon, 14 Nov 2005 13:55:41 +0100

ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005Dear all,

I have read the ForCES Protocol Specification draft and it is very clear and well structured and written. I have checked also the technical level of this draft and it seems fine for me. I have just some comments and questions:
  a.. In section 3.3. Protocol Mechanisms, for both continue-execute-on-failure (3.3.1.1.5) and execute-until-failure (3.3.1.1.6) execution modes, is it possible to extend the description to several FEs case (distributed FEs). (just like the Atomic transaction execution mode description).
  a.. In section 6.4 Association Messages, each Message Header description (from CE to FE) provides almost all header fields except of two flags:
  - EM: Execution mode  and
  - TP: Transaction phase
  A brief description and possible values for these specific fields in each message would be helpful.
  a.. Page 28, using "execute-all-or-none" Atomic Transaction (AT) sentence should be better than using only "execute-all-or-none" sentence since AT flags is already used before in section 3.3.1
  a.. For the section (7. Protocol Scenarios), assuming that a new LFB wants to join an FE in a dynamic manner, in this case the LFB object FE will be upgraded with new attributes and capabilities. In this case, what kind of message the FE should send to the CE? Asso Setup Req !
  a.. In case when distributed FEs are integrated in separated boxes (physical separation between the CEs and FEs at the box level).  In such a configuration,
  is it possible to give a scenario example in section 7 to show the message exchange between CEs and FEs (several FEs can join or leave).
Best Regards,

Wajdi LOUATI
_________________________________
Wajdi LOUATI
Wireless Networks and Services Group 
Wireless Networks and Multimedia Services Department
Institut National des Télécommunications
9 rue Charles Fourier
91011 EVRY Cedex, France
_______________________________

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
  ----- Original Message ----- 
  From: Putzolu, David 
  To: [email-masked] 
  Sent: Wednesday, November 02, 2005 3:11 AM
  Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

  All,

  Thanks,
  David & Patrick

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 14 Nov 2005 07:58:10 -0500

These modes only apply to a single request.  If a CE is tying together 
multiple requests (to the same or different FEs) then the CE logic provides 
any failure relationship that is required.  The bits in the message header 
have no effect on this.
If we want to describe this, it would be in the Atomic transaction section, 
not with the header bits.

Yours,
Joel M. Halpern

At 07:55 AM 11/14/2005, louati wrote:
>In section 3.3. Protocol Mechanisms, for both continue-execute-on-failure 
>(3.3.1.1.5) and execute-until-failure (3.3.1.1.6) execution modes, is it 
>possible to extend the description to several FEs case (distributed FEs). 
>(just like the Atomic transaction execution mode description).

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Nov 2005 08:28:34 -0500

On Mon, 2005-14-11 at 13:55 +0100, louati wrote:
> Dear all,

Thanks for taking the time to review, Wajdi. Heres more extrapolation to
Joels response.

> I have read the ForCES Protocol Specification draft and it is very
> clear and well structured and written. I have checked also the
> technical level of this draft and it seems fine for me. I have just
> some comments and questions:
>         In section 3.3. Protocol Mechanisms, for both
>         continue-execute-on-failure (3.3.1.1.5) and
>         execute-until-failure (3.3.1.1.6) execution modes, is it
>         possible to extend the description to several FEs case
>         (distributed FEs). (just like the Atomic transaction execution
>         mode description).

Only the 'all-or-none' mode needs to be transactional and needs ensuring
of consistency. There is nothing stopping an implementation from meeting
the ACID properties for other modes - but we are not defining that. As
Joel said: "If a CE is tying together 
multiple requests (to the same or different FEs) then the CE logic
provides any failure relationship that is required."

>         In section 6.4 Association Messages, each Message Header
>         description (from CE to FE) provides almost all header fields
>         except of two flags:
>         - EM: Execution mode  and
>         - TP: Transaction phase

There is a pointer to go back to section 3.3.x in each of those. Isnt
that good enough?

>         Page 28, using "execute-all-or-none" Atomic Transaction (AT)
>         sentence should be better than using only
>         "execute-all-or-none" sentence since AT flags is already used
>         before in section 3.3.1

ok - just open a tracker for this. Also in the tracker, something i just
noticed while looking at what you are asking for - please put a pointer
to the priority section to define the importance of the priorities; i.e
is prio 1 more important than 2 etc

>         For the section (7. Protocol Scenarios), assuming that a new
>         LFB wants to join an FE in a dynamic manner, in this case the
>         LFB object FE will be upgraded with new attributes and
>         capabilities. In this case, what kind of message the FE should
>         send to the CE? Asso Setup Req !

The CE can set different parameters for the FEO.

>         In case when distributed FEs are integrated in separated boxes
>         (physical separation between the CEs and FEs at the box
>         level).  In such a configuration,
>         is it possible to give a scenario example in section 7 to show
>         the message exchange between CEs and FEs (several FEs can join
>         or leave).

There is no difference between CE/FEs being in separate boxes or within
one chasis or even both being in the same box for that matter.
So if you make that assumption - does the diagram help?

cheers,
jamal

---

From: Alex Audu <[email-masked]>
Date: Mon, 14 Nov 2005 10:09:20 -0500

Resending.  Previous posting didn't seem to make it through.
 
Regards,
Alex.
 
-----Original Message-----
From: Alex Audu <[email-masked]>
To: [email-masked]
Sent: Wed, 9 Nov 2005 11:39:16 -0500
Subject: Re: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

Hi All,

 

 
Regards,
Alex.
www.garlandsoftworx.com

 
-----Original Message-----
From: Putzolu, David <[email-masked]>
To: [email-masked]
Sent: Tue, 1 Nov 2005 18:11:36 -0800
Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

All,

Thanks,
David & Patrick

---

From: Weiming Wang <[email-masked]>
Date: Tue, 15 Nov 2005 00:12:46 +0800

Hi Alex,

Thanks very much for the detailed review of the protocol. I'l give a reply to
your valuble comments very soon, for I just came back from Vancouver. I suppose
others will also give the replies soon.

thanks again,
Weiming

-----Original Message-----
From: Alex Audu [email-masked]

Hi All,

The authors did a good job in documenting the structure of the messages in
detail. That is great for
consistent API implementation and interoperability.  However, there was not the
same attention
given to documenting the protocol behavior.  This can easily lead to different
implementations
behaving differently - a classic interoperability problem.

There was an attempt to address some of this in the scenario section. But this
section  only contains few examples and is typically not exhaustive. If there
are normative beahoirs called out here, they should be moved into the protocol
message description section for the respective messages.

Also the protocol state machine needs more work. It needs to be
redundancy-aware.  Remember that
accurate element state management is key to providing loss-free service.

Regards,
Alex.
www.garlandsoftworx.com

-----Original Message-----
From: Putzolu, David <[email-masked]>
To: [email-masked]
Sent: Tue, 1 Nov 2005 18:11:36 -0800
Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15,
2005

All,

Thanks,
David & Patrick

---

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 14 Nov 2005 11:15:01 -0500

Olla Alex,

On Mon, 2005-14-11 at 10:09 -0500, Alex Audu wrote:
> consistent API implementation and interoperability.  However, there
> was not the same attention given to documenting the protocol behavior.
> This can easily lead to different implementations 

If you give specific pointers we can work on it.

> There was an attempt to address some of this in the scenario section.
> But this section  only contains few examples and is typically not
> exhaustive. If there are normative behaviours called out here, they
> should be moved into the protocol message description section for the
> respective messages. 
>  

Pointers will help.
We are shooting for an interop - so we do hope to catch the obvious
issues.

> redundancy-aware.  Remember that accurate element state management is
> key to providing loss-free service.  

It has been decided on this protocol revision we just need the basics
going. So a lot of the HA approaches are gone for now. Next protocol
revision things will start showing up. We want simple solution first.

> Please see attachment for full details of comments.

Thanks for taking the time Alex!

Most of the issues you commented on should go on the tracker. There are
exceptions - things that need further discussions:
1) The HA states - refer to above.
2) FE/CE Manager - we are trying to be intentionaly vague. You can
implement them any which way you want. In our case for example a simple
FEM is DHCP. One time at startup it gets consulted. It is safer not to
go into the path of defining these.
3) Event Notification: We have decided not to have events from CE->FE so
we can get the first instance of the protocol out.
Those will have to be configs instead.

Do you have time to add the rest of them to the tracker? I believe they
are valid things we need to fix.

cheers,
jamal

---

From: "Guo, Xiaoyi" <[email-masked]>
Date: Tue, 15 Nov 2005 17:26:10 +0800

hi ,all 

Sorry for delay  review the protocol draft , and have a fast glance , 
 
i found  "a FE" and "an FE" all exist in this draft , which one should accpet ? :> 

other comments i will send later

cheers,

Xiaoyi
  ----- Original Message ----- 
  From: Alex Audu 
  To: [email-masked] 
  Sent: Monday, November 14, 2005 11:09 PM
  Subject: Fwd: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

  Regards,
  Alex.
   
  -----Original Message-----
  From: Alex Audu <[email-masked]>
  To: [email-masked]
  Sent: Wed, 9 Nov 2005 11:39:16 -0500
  Subject: Re: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

  Hi All,

  Regards,
  Alex.
  www.garlandsoftworx.com

  -----Original Message-----
  From: Putzolu, David <[email-masked]>
  To: [email-masked]
  Sent: Tue, 1 Nov 2005 18:11:36 -0800
  Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

  All,

  This email begins a last call period for the ForCES
  protocol document. This last call period is
  two weeks in length and ends on Tuesday, Novemb

---

From: Alex Audu <[email-masked]>
Date: Tue, 15 Nov 2005 09:20:26 -0500

I think "An FE"  reads better.  I believe it is the phonetically correct alternative due to the beginning "e"
sound in the pronounciation of "FE" as a word.
 
Cheers,
Alex.
www.garlandsoftworx.com

-----Original Message-----
From: Guo, Xiaoyi <[email-masked]>
To: [email-masked]
Sent: Tue, 15 Nov 2005 17:26:10 +0800
Subject: Re: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

hi ,all 

 

cheers,
 
Xiaoyi
----- Original Message ----- 
From: Alex Audu 
To: [email-masked] 
Sent: Monday, November 14, 2005 11:09 PM
Subject: Fwd: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

Regards,
Alex.
 
-----Original Message-----
From: Alex Audu <[email-masked]>
To: [email-masked]
Sent: Wed, 9 Nov 2005 11:39:16 -0500
Subject: Re: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

Hi All,

 

 
Regards,
Alex.
www.garlandsoftworx.com

 
-----Original Message-----
From: Putzolu, David <[email-masked]>
To: [email-masked]
Sent: Tue, 1 Nov 2005 18:11:36 -0800
Subject: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

All,

---

From: Alex Audu <[email-masked]>
Date: Tue, 15 Nov 2005 09:29:06 -0500

Hey Jamal,
 
I provided details in the attachment I included in my original post. If that didn't make it hrough, I have
provided the attachment again with this e-mail.  
 
Cheers,
Alex.
www.garlandsoftworx.com
 
-----Original Message-----
From: Jamal Hadi Salim <[email-masked]>
To: [email-masked]
Sent: Mon, 14 Nov 2005 11:15:01 -0500
Subject: Re: Fwd: ForCES Protocol Working Group Last Call - ends Tuesday, November 15, 2005

Olla Alex,

Pointers will help.

cheers,
jamal

---

From: Jamal Hadi Salim <[email-masked]>
Date: Tue, 15 Nov 2005 11:06:11 -0500

Xiaoyi,

Please open a tracker issue on this and other mechanical/editorial
issues. For things which are discussion points on the protocol post on
the list.

cheers,
jamal

On Tue, 2005-15-11 at 09:20 -0500, Alex Audu wrote:
> I think "An FE"  reads better.  I believe it is the phonetically
> correct alternative due to the beginning "e"
>         There was an attempt to address some of this in the scenario
>         section. But this section  only contains few examples and is
>         typically not exhaustive. If there are normative beahoirs
>         called out here, they should be moved into the
>         protocol message description section for the respective
>         messages. 
>

---

From: "Furquan A. Ansari" <[email-masked]>
Date: Tue, 15 Nov 2005 15:05:58 -0500

Hi All,
    Just thought of adding some comments on the draft - before the last 
call is done....

1) 3.3.4.1 Batching.... It's unclear from the text about how batching 
should be achieved. Is there
any indication from the PL layer to the TML layer that there will be 
more PDUs to come and
the TML should wait so that it can batch things up? Otherwise, TML would 
simply ship out
the PDU as soon as it is received. Batching would introduce a bufferring 
requirement in the
TML and if so, there may need to be an explicit indication from the PL 
layer that a set of PL
PDUs are to be batched.

2) There are about 6 references to the word "byte" - As has been done 
with a lot of other
RFCs, I think it would be completely unambigous only if we mean "octet" 
rather than "byte".
(Byte is computer vendor dependent definition - though 8bits in 99% 
cases - still
octet is unambigous). I would like to see the refences to byte be 
replaced with octets.

3) ID assignment: For all the ID range assignments, I think it would 
make sense to
start from +1 rather than 0 of that range. By this I mean, we really 
don't want
0x00000000 to actually mean that it is an FEID. This could actually be 
the unassigned
value for that device which has to be configured with some value. We 
should start
from 0x00000001 - 0x3FFFFFFF for the FEID range
similarly, if the TS switch is actually only meant to do type selection, 
it would be the
same case with CEID and multicast ID - i.e. by first just looking at the 
TS bits, I
have figured that it is FE,CE or multicast, and the remaining bits would 
start the
range from x0000000

4) Sec 5.2 and 5.3 - TLV and ILV "L" length part does not explicitly 
specify
what is the size of each unit (is it octets, words, Dwords like in main 
header etc.)
(obviously, I would imagine it would be in octets - but let's clarify it)

5) Could we replace "combo" with "combination" throughtout the text? 
It's more
formal that way.

6) ....

Sorry, I have to run and haven't had the chance to go though the rest of 
the
document. I will try to do so.

Thanks,

-- 
Furquan Ansari
Bell Labs Research			Ph : 732-949-5249
Holmdel, NJ				Fax: 732-949-4556

---

From: Jamal Hadi Salim <[email-masked]>
Date: Wed, 16 Nov 2005 13:44:28 -0500

> TML and if so, there may need to be an explicit indication from the PL 

I agree the TML/PL primitives would need to take care of these; however,
isnt the TP header flag and whats described in 3.3.1.1.3  sufficient?

> octet is unambigous). I would like to see the refences to byte be 

Good point - needs to go on the tracker

> have figured that it is FE,CE or multicast, and the remaining bits would 

Make sense; tracker issue - I know that ID 0x0 is reserved.

> (obviously, I would imagine it would be in octets - but let's clarify it)

Tracker

> 5) Could we replace "combo" with "combination" throughtout the text? 

tracker

> document. I will try to do so.

Also, just enter them in the tracker - they automatically get copied to
the list
Thanks for putting the time Furquan.

cheers,
jamal

---

From: "Furquan A. Ansari" <[email-masked]>
Date: Wed, 16 Nov 2005 15:01:13 -0500

Jamal,

    Check below....

>isnt the TP header flag and whats described in 3.3.1.1.3  sufficient?
I would assume that transaction protocol and the TP header flag usage 
should be applicable independent of the batching mode. I may want to 
perform a transaction between the CE and FE by simply sending a
sequence of 5 messages carried as separate PDUs and perform the 
transaction. Or, I could also perform the same transaction by batching 
all 5 messages in one PDU. So, the way I think - trasaction is between 
the CE and FE whereas batching requirements are between PL and TML. And, 
yes you are right, TML/PL service primitives would need to take care of 
it. (So, should we assume that the TML draft will provide
the necessary definitions/primitives required for batching?)

Thanks,

---

From: Weiming Wang <[email-masked]>
Date: Sat, 19 Nov 2005 22:52:38 +0800

Furquan and Jamal,

----- Original Message -----
From: Furquan A. Ansari

Hi All,

I would assume that transaction protocol and the TP header flag usage should be
applicable independent of the batching mode. I may want to perform a transaction
between the CE and FE by simply sending a
sequence of 5 messages carried as separate PDUs and perform the transaction. Or,
I could also perform the same transaction by batching all 5 messages in one PDU.
So, the way I think - trasaction is between the CE and FE whereas batching
requirements are between PL and TML. And, yes you are right, TML/PL service
primitives would need to take care of it. (So, should we assume that the TML
draft will provide
the necessary definitions/primitives required for batching?)
[Weiming] I suppose you are discussing the batching of messages rather than
operations inside one message. I think now we only mentioned the inter-massage
batching more from the conceptual point of view in the protocol, i.e., we
mentioned this batching but we don't have specific mechanism for it.  I agree
with Furquan that EM and TP have nothing to do with it, but I don't agree with
the idea that PL/TML service primitive can do anyting for batching, because we
don't have anything in PL to treat it. Batching is more the TML itself
entertainment.  To let a atomic transaction controlled by TP flags link to TML
batching is not a practical solution for the batching, I think.

Thanks,
Weiming