Re: Hybrid TMLs

"Khosravi, Hormuzd M" <[email protected]>
Newsgroups gmane.ietf.forces
Message-ID <F50A4280B6033741B1DD2B4E902258B10243D8EF@orsmsx411.amr.corp.intel.com>
Weiming

I strongly think we should focus on getting the Model draft out for LC
at the moment....lets not distract the WG with TML discussions at this
point.

If we don't get the Model draft out for LC before IETF meeting, then you
can forget about all the work we have done for many years...

Thanks
Hormuzd

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Wang,Weiming
Sent: Tuesday, October 03, 2006 12:05 PM
To: [email protected]
Subject: Re: [FORCES] Hybrid TMLs

Allen,

In the discussion, when we mention a mandatory TML, we actually mean a
mandatory type of TML, i.e., only one TML transmission means (say
TCP+DCCP) is allowed. 

I also incline to keeping one TML instance for simplixity.

thanks,
weiming

----- Original Message ----- 
From: "Deleganes, Ellen M" <[email protected]>

Weiming,

I'm apparently confused by your mail. I don't think the intention is to
be restrictive to allow only one TML instance, but to find a way to
ensure that a CE is only required to support one TML instance. A CE may
support multiple if desired, but that should not be a requirement.

My concern is that if a CE is required to support multiple TML instances
that will slow down deployment because it adds to the complexity of the
implementation.

Regards,
Ellen

-----Original Message-----
From: Forwarding and Control Element Separation
[mailto:[email protected]] On Behalf Of Wang,Weiming
Sent: Tuesday, October 03, 2006 9:25 AM
To: [email protected]
Subject: Re: Hybrid TMLs

Joel,

Only a mandatory TML makes all our thoughts to separate PL from TML much
less meaning.  It's even not better and more restricted than to mandate
that "all TMLs be same in one NE" to solve the question. But this is
still quite restricted for ForCES deployments. 

I incline the scheme to keep one TML instance in any case, while making
a statement in the TML service primitves that a TML with Hybrid TML
media is allowed under condition that the hybrid TML implmentation is
responsible to provide services specified by the TML service primitves
document to PL uniformly. 

While at the same time, it may be of help for future use to assign an
TML id for an opened TML instance, even we only allow one TML instance
for one CE/FE. 

thanks,
Weiming

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

> This is one of the reasons why there needs to be a mandatory to
implement TML.
> I am inclined to observe that
> Given the existence of at least one common TML, it is permitted for 
> the CE to simply use a TML that is common across all FEs.
> A CE which has support for multiple TMLs, and which can manage the 
> selection and management issues of using such (including, if used, 
> multicast) is free to choose to use multiple TMLs to speak to 
> different FEs in the NE.
> 
> I.e. a single TML works, but we have no reason to prohibit multiple 
> TMLs, if someone builds a CE that can do it.
> 
> Yours,
> Joel Halpern
> 
> At 11:23 AM 10/3/2006, Wang,Weiming wrote:
> >Hi,
> >
> >When I'm considering the TML service primitive, I come upon a 
> >question on the TML instances.
> >
> >Considering a case with one CE and multiple FEs,  it is possible FEs 
> >may use different TML media for ForCES protocol transportation. This 
> >actually implies the CE have to support more than one TML instances, 
> >or the CE TML must be an all in one TML, with different TML media 
> >supported by one TML layer.
> >
> >There are several questions here:
> >1. Shall our charter support different TML media in one ForCES NE?
> >2. If yes, then what scheme shall we adopt, multiple TML instances 
> >or allowing a hybrid TML? Or, do we have other alternatives? I just 
> >can see questions for either of the schemes.
> >
> >Thanks a lot for any thoughts.
> >
> >Weiming
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.