Subject: RE: PL<-->TML WAS(Re: [Forces-protocol] topic 7: HA

From: "Khosravi, Hormuzd M" <[email-masked]>
Date: Fri, 9 Apr 2004 16:22:22 -0700

Jamal,

-----Original Message-----
From: Jamal Hadi Salim [mailto:[email-masked]] 
> 
> I don't believe we need to define APIs between PL and TML, it is true
> that we have separated the 2 layers but introducing and standardizing
> new interfaces will introduce unwanted complexity and delay in getting
> an interoperable protocol out. In any case, any protocol
implementation
> will consists of both layers working together and cannot operate with
> just one. 

True on introducing more complexities - not sure i agree on the
"unwanted" part. Maybe this is something that we need to decide on first
before moving forward. Do we wanna say it that Forces can work only on
the spefic TMLs? 

[HK] No we don't, but that doesn't mean we need to define and
standardize an API. Look at GSMP for example, it doesn't define an API
but can still function on multiple TMLs. Why cant we use a similar
approach ?

> The interfaces between the layers is completely implementation
> dependent. 

I think it may be beyond "implementation" specific now that we have
decided to go TMLs, no? I still would like our customers to use their
own TMLs as long as they provide "services" to the PL layer for the
items you mention: reliability, congestion control, security, HA etc.
Infact in their own private environment i would like to care less if
they present those services to the PL layer or not. Seems to me like
this would provide greater spread for Forces.

I believe we need to decide on this issue before moving forward.

[HK] Sure your customers can use their own TMLs, infact that is the
idea. But as you said, what is important are the services or
requirements for TMLs such as reliability, etc.

> Another thing which is needed is Protocol Messages which will help
> interaction between PL and TML. This is what Weiming is talking about,
I
> believe. I will send out some text on Protocol Messages which will
> hopefully get us started in that direction.

Go ahead and do that although i dont think the fundamental difference
between us at this point has to do with how to replace multiple TMLs.
I believe that the TML is a provider of services centred around
transport. As in any such layering there needs to be (hate to use that
evil word) an API between the two. Whether that takes the form of a
protocol is not the issue.

[HK] Sure the layering will need an API in some implementations, but we
don't need to define those APIs. Lets leave this to the vendors who
implement the protocol. In any case, do you really think we can
standardize APIs in the IETF ?

> Another point I would like to bring out is that we need to come up
with
> one or max 2 HA schemes which will make most sense for our protocol.
If
> we keep adding new schemes and features we will never get to a single
> interoperable solution. We need to decide which scheme will work best
> for our case. I will send out some specific text in this regard in a
> separate email.

It seems to me like more than one scheme could be supported. But i do
agree with you that if it turns out to be a swiss knife it will not be
very useful. 
When you send those emails, please make sure you have the appropriate
subject heading to allow for maximum feedback.

[HK] I will do that. Thanks for your comments !
Seems like the list is finally working in reasonable time :-)

Regards
Hormuzd

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

---

From: Jamal Hadi Salim <[email-masked]>
Date: 14 Apr 2004 11:36:40 -0400

> but can still function on multiple TMLs. Why cant we use a similar

Any particular GSMP RFCs/drafts? 
Hopefully it will provide an alternative approach, otherwise i dont see
how to escape the defining of such services that the TML exposes.

> requirements for TMLs such as reliability, etc.

Right, but exposing the abilities of the TML to meet the desires of the
the PL needs an interface defined.

> standardize APIs in the IETF ?

We need to define an interface that TMLs can attach to (or looked at
from the other side PLs can attach to). 
Whether its a protocol between TML and PL(TCP would be fine to me) or an
API is not as important - the important piece is an agreement that such
an interface is needed to begin with.
I dont think the IETF is adverse to standardizing on some sane APIs
when it is sensible; example:
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-sctpsocket-08.txt

cheers,
jamal