Subject: [Forces-protocol] Notes from ForCES protocol meeting call

From: Robert Haas <[email-masked]>
Date: Tue, 11 May 2004 03:32:02 +0200

I sent this to everybody I heard on the call, feel free
to edit and forward to rest of team once it is correct.

Administrivia: David Putzolu and Robert Haas taking notes, Jamal was
drawing out a diagram of header fields.

Participants: David (1st half only), Hormuzd, Jamal, Weiming, Robert, 
Patrick, Ram (on and off).

---

Header fields review

16 bits - question whether 16 bits (64k) is enough if it
is bytes? Maybe it should be words?

Need to finalize the flags in the header still.

---

Message body discussion

Jamal: What's in the message body?  It is a TLV - what will
it look like inside?
Example of adding an IPv4 route

Common header: Command type = "config"
TLV contained would have:
   Type = "add LFB entry" (could have been delete or modify)
   Length = (TBD)
   Value contains:
     LFB instance ID
     LFB type ID
     Flags needed
     Indicator that it is a IPv4 route being added
     The new IP route

Weiming pointed out we may have messages to a whole FE
rather than single LFB, all agreed.

Common header: Command type = "config"
TLV contained would have
   Type = "change FE config entry"
   Length = (TBD)
   Value contains:
     Indicator of what you are changing on the FE
     The parameters of what you are changing on the FE

Robert: Do we know how the model team has hinted to
configure LFBs? They may have some sort of TLV
that we may decide to coordinate with. We should review
what the model team comes up with.

Jamal: Model team may put TLV within TLV - one big outer
TLV for the add route containing a bunch of smaller TLVs
within it.  Model team may not have been clear - we
should come up with this and also see what model team
has.  We should come up with this because it will affect
the common header as well.

Robert: When we do batching do we ever put two different
command types e.g. a config and a query command into a
single message? Probably not so seems OK to keep command
type in common header.

Some discussion on where LFB type belongs - decided
to initially put 16 bits into common header for this.
If the LFB type is in the header, and no LFB instance
ID is in the TLV, then all LFBs of the given type in a
FE are addressed.  Some reserved value of LFB type in
common header means to look in the TLVs to figure out
what specific LFB instances are addressed.	

Hormuzd volunteered to send out a couple sample drawings
of packet drawings for a message to all LFBs on a particular
point and another to a specific instance of a LFB.

---

Flags discussion & subsequence #s inside TLVs

Discussed Weiming's email of Monday 8:40AM that discussed
batching & atomicity, Jamal OK with it.

Robert: Is there an example of using batching without
atomicity?  Why do we use batching in non-atomic cases.
Seems like main reason for batching is to provide
atomicity.

Jamal: Example of atomicity: Add this route and the NHLFE
together - do not add one without the other.

Robert: If I send two add route TLVs together I could set
atomic flag to make them atomic, or not set atomic and they
could succeed/fail independently. Could also use atomic
flag to say TLVs across messages need to be atomic together.

Example of batching over 4 messages: 1, 2, 3, 4
1&2 need to be atomic together, 3&4 need to be atomic together

1 has batchflag 1 (start batch), atomicflag 1 (atomic)
(FE sees batchflag 1 and atomic 1, knows #1 is start of xaction)
2 has batchflag 0 (end batch), atomicflag 1 (atomic)
(FE sees batchflag 0, knows end of atomic op and commits 1 & 2)

3 has batchflag 1 (start batch), atomicflag 1 (atomic)
(FE sees batchflag 1 and atomic 1, knows #3 is start of xaction)
4 has batchflag 0 (end batch), atomicflag 1 (atomic)
(FE sees batchflag 0, knows end of atomic op and commits 3 & 4)

Another example: Adding 1000 routes in a PL message. Are they
always atomic?

Robert: NFSv4 example, use same template to respond, replacing
route value with OK or FAILED fields for each route.  In success
case just ACK whole message, only send detailed full message
back on partial failures.

Weiming: There may be many TLVs in one message.  In this case
default-atomic is fine - the flags are used for signaling
between separate messages.  E.g. if you have 100 routes you
want to add atomically, send 1 message. If you want them to
not be atomic, send separate messages.

(Robert continues taking minutes at this point)

Hormuzd: NPF can make non-atomic operations (TLVs) in the same message 
using array of commands in the reply flagged.

Weiming: TLVs in the same message should always be treated as atomic. To 
complex otherwise.

3 bits priority flags, 2 batch bits (start, stop, nothing, middle), 2 
ACK bits, 1 atomicity bit.

Weiming: what about asking for NACKs, i.e., a response if the operation 
is unsuccessful only. Use 2 ACK bits instead of a single bit.

LFBTypeID 16 bits with a special Opaque type (means look into the 
message, needed if there are LFBs of multiple types in the same message).

Splitting the address space for CE and FE ID will be proposed in te 
draft text.

Weiming: source ID and dest ID are too generic names. Proposes Source 
Element ID, or Source ForCES Element ID.

Weiming: OK to have command types for config-response and query-response.

---------------
FE to CE config msg (peering)

Jamal: CE must be signaled of config operations performed directly on 
the FE. It this an event to the CE or a config(-resp) msg ?

Hormuzd: This should be an event.

Robert: There can be a config-response to whoever sent the config, and 
an event to whoever subscribed to such events.

Jamal: the event can encapsulate the config message for simplicity.

----------------
FEM-CEM

Jamal: own FE ID, CE ID and TML configuration information are passed to 
the FE at boot-up. When a new FE joins the NE, the FEM will indicate the 
change. The FE FSM can be affected by the assumption whether the FEM 
remains active after boot-up.

Jamal will take the action item and share his experiences.

----------------
Protocol message types:

Hormuzd: meaning of subscribe/unsubscribe is different from config.
Weiming: use command type "event", and operation type subscribe.
Robert: how is the event modeled in the LFB ? Is this like any other LFB 
attribute ? If yes, it can be acted upon using a config message to 
subscribe.

Below are the three possibilities how event subscription can be 
specified in a ForCES message.
cmd type: the command type in the common header.
operation type:  the type in the TLV.

              cmd type    operation type
    CE    ---------------------------------->    FE

              subscribe        -
          ----------------------------------> (Hormuzd's preference)

               event        subscribe
          ---------------------------------->  (Weiming+Robert)

               config      event-subscribe
          ---------------------------------->  (Weiming)

Note that the event cmd type is also used from the FE to the CE to 
advertise events.

We need to find out which one of the three possibilities above we want 
to follow.

_______________________________________________
Forces-protocol mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/forces-protocol

---

From: "Weiming Wang" <[email-masked]>
Date: Tue, 11 May 2004 09:51:50 +0800

Robert,

Ligang also attended.

Cheers,
Weiming

---

From: Jamal Hadi Salim <[email-masked]>
Date: 12 May 2004 06:48:29 -0400

>           ---------------------------------->  (Weiming)

I dont see any difference vetween the last two. They seem cleaner than
the first one, but i cant really conclude that until i see how the
message body looks like. 
Seems to me like you need to specify which is/are the event(s) of
interest. Also you should be able to subscribe to multiple events in one
PL message. 

Lets also discuss the events being sent from CE->FE while we are talking
about this.

cheers,
jamal