Subject: RE: [Forces-protocol] PL/TML Interface

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Sat, 24 Apr 2004 20:22:28 -0700

Hi Jamal, Weiming

Thanks for your replies. It seems like we have come to a consensus on
the hand-waving or implicit approach, which is great. I'll post some
text on the other topics.

Regards
Hormuzd

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
Sent: Friday, April 23, 2004 5:43 AM
To: Wang,Weiming
Cc: [email-masked]; Khosravi, Hormuzd M
Subject: Re: [Forces-protocol] PL/TML Interface

Weimig/Hormuzd,
Apologies for disappearing - important customer fire.

On Fri, 2004-04-23 at 00:00, Wang,Weiming wrote:
> Hormuzd,
> 
> My understandind of handwaving approach David presented below using
multicast
> add route as an example is that the FEid(s) and the message type is
used as a
> waving signal to TML to implicitly ask for the defined service in the
TML.  This
> is opposite to the explicit approach in that the latter may use an
explicit flag
> to indicate such service requirement. Do I misunderstand something
here?

I think it is implicit unless i misread it. I dont see the PL worrying
about sending a list of FEids though. I think that should be the TMLs
problem. PL sends a single address (CE/FEid), the TML may translate or
rewrite it.
To take an example of a PL sending a broad/multicast FEid:
-if TML is capable of broad/multicast, the single message is sent.
- if TML is not capable of broad/multicast, then it will take that FEid,
do an internal lookup, come up with a list of unicast FEids and
unicast-send to each. 

> Actually my another thought (as I posted before) is to let the
protocol layer
> more flexible to use TML by allowing some configurations from Pl to
TML based on
> the TML capabilities . The configuration may be some thing like "ple
use #xx
> service template for message type xx when the message asks for
multicast". This

I think that message type alone is insufficient. Since message type is a
static item, we need flags to override default behaviors. 
To borrow an example from netlink2, we used the ACK flag to indicate
that a message/transaction was to be reliably delivered.
Even on an example of an ADD ROUTE, if i choose not to have a specific
ADD ROUTE reliably delivered for whatever reason, i should be able to
override the message type decision by NOT setting the ACK flag.
Corrollary: In a message type where reliability is not needed, i should
still be able to request for a specific message to be reliably delivered
by setting a flag such as the ACK.

TMLs should be defining something of the nature:
1) This TML is capable of both unicast and multicast
2) When a message has to be delivered reliably, operation is:
send on multicast UDP, if no response send on TCP and wait for upto y
seconds for a response. Notify PL on success if it asked for ACK. Notify
PL on failure always.
3) etc

> approach is actually consistent with the handwaving approach, only
with more
> flexibility in that protocol customers may have more choices other
than that
> defined by TML requirements. I think this is also useful for more
flexible
> vendor supports.  But I just don't want to push this too hard now
because I
> agree with you that we now need to move forward much more quickly.
> 
> Anyway, I have no doubt  to use the handwaving approach. I'm also
anxious to
> hear what Jamal thinks.

I agree we need to move past this IO stall but lets verify that the
implicit approach will work. Heres an attempt at listing the
requirements:

1) Reliability:
A ACK flag on the header should be sufficient on the header.
2) Congestion control:
I think this is a behavior of the TML that PL should have no control
over, no?
3) HA:
We may decide we want the PL to make decisions. Nothing in the protocol
header is necessary; events from TML<->PL are necessary though

4) Security
Like congestion control, PL has no say.

5) Uni/multi/broadcast addressing/delivery
The FEid/CEid is all the PL cares about. The TML takes care of the rest.
Somehow the PL needs to be notified of the semantics of the IDs.
Or we could come up with a scheme like the one we started discussing
much earlier on to have specific IDs allocated for different things.

6) Timeliness:
Not sure how at this point. But one should be able to say
"obsolete the message if it doesnt make it in 200ms".

7) Capability exchange
I think this is again like CC and security the responsiblity of the
TML??

8)The FEM/CEM interface
TML responsibility

9) Batching:
Responsibility of PL and PL alone?

10) transactional operations (2pc etc)
Responsibility of PL and PL alone?

I may have missed others.

Overall, it seems to me like the implicit approach should work. 
There are still some holes for example when i wanna ask for "just a
little more from the TML" like #6 above. Another "just a little more"
example would to say offload something like a LFB heartbeat from the PL
and tell the TML:
"I want you to send this msg unreliably, if you dont receive a response
two times, i want you to attempt to deliver it reliably with two more
retransmits and then tell me when that fails, otherwise i am not
interested but i will ask you later for all failure stats"
OK, that was long - but you get my message.

Thoughts?

cheers,
jamal

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

---

From: [email-masked]
Date: Mon, 26 Apr 2004 09:12:54 -0400

Hello,

Comments are inline.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Khosravi,
> Hormuzd M
> Sent: Saturday, April 24, 2004 11:22 PM
> To: [email-masked]; Wang,Weiming
> Cc: [email-masked]
> Subject: RE: [Forces-protocol] PL/TML Interface
> 
> 
> Hi Jamal, Weiming
> 

> header is necessary; events from TML<->PL are necessary though

<RamG>
TML needs to be informed how it needs to interact with CE and FE's. 
FE and CE's may have specific configuration. Either that needs to be
conveyed to TML eitehr during the startup or during the configuration.

Switchover operations can be dynamic and requires dynamic reassocition for HA,
this reqiures updates from PL layer to TML otherwise TML will be opearation on 
stale configuration.
<RamG>

> I think this is again like CC and security the responsiblity of the

<RamG>
PL has a play in this.
<Ramg>

> OK, that was long - but you get my message.

Regards
Ramg