Subject: Re: [tcmtf] TCMTF: Documents to be generated. Small modification

From: Mirko Sužnjević <[email-masked]>
Date: Thu, 6 Jun 2013 09:51:04 +0000

Hello,
I think these names are ok. Maybe we should discuss the second one in more detail.
Perhaps include negotiation in the name of the draft so its purpose is evident from the title? As the purpose of that draft is to establish which particular parameters will be used. 
My suggestions are:
TCMTF - negotiation signalling
TCMTF - negotiation process
TCMTF - parameter signalling
Or something along those lines?
Mirko

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Wednesday, June 5, 2013 12:56 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'ken carlberg'; Martin Stiemerling
Subject: [tcmtf] TCMTF: Documents to be generated. Small modification

In the conf-call of yesterday it was also clear that for the IETF it is better to split Document A into two documents:

- The "TCMTF reference model" (1): the protocol stack and scenarios. It should be said that each protocol at each layer will use its own signaling mechanisms.

- The "TCMTF-specific signaling": there are some things we will need to
deploy:
	- a negotiation mechanism (2) to decide the options to use at each layer (e.g. a mux and demux agree on using ROHC+PPPMux+GRE)
	- a mechanism to setup/release a TCMTF tunnel (3)between a multiplexer and a de-multiplexer

The current draft is the TCMTF "reference model", since it does not talk about specific signaling issues.

By now, we don't have to propose the "TCMTF specific signaling". It would be something to be deployed if the Working Group is created.

This same idea was proposed by Ken Carlberg in February. The advantages of this new distribution of the documents are (quoting Ken):

> One thing to keep in mind is that it is possible that (2) and (3)
> (below) can change over time and yet (1) (the reference model) does 
> not, then it may be best to separate (1) from the other items.

> a more encompassing architecture or framework that would include 
> sample scenarios upon which your deliverables A & B are aimed at?  My 
> impression is that you may want to point the reader of documents A & B 
> to the same reference model, and instead of repeating the same text, 
> it may be helpful to separate this into a separate document.

Once discussed, I would create a new charter proposal including these changes.

Do you like these short names for the documents?

- "TCMTF reference model".
https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/ 

- "TCMTF-specific signaling". Future work

- "TCMTF recommendations".
http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

Your feedback will be welcome. Thanks!

Jose

> -----Mensaje original-----
> De: ken carlberg [mailto:[email-masked]] Enviado el: martes, 05 
> de marzo de 2013 17:07
> Para: [email-masked]
> CC: 'ken carlberg'; [email-masked]; [email-masked]
> Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF 
> in
> IETF87
> 
> Hola Jose,
> 
> Thanks for the expanded explanation, and again, apologies for the 
> tardy repsonse.  Its helpful to understand that document A and B are 
> sequential
to
> each other.  One thing to keep in mind is that if its possible that 2 
> and
3
> (below) can change over time and yet 1 (the reference model) does not, 
> then it may be best to separate 1 from the other items.
> 
> as for what you outline as a discussion point for future work, it 
> seems
fine.  I
> just have a personal bias that if you have a clear idea of the things
you'd like
> to accomplish in the future, then having a requirements document would 
> be helpful to focus those thoughts without having to have one 
> particular solution.  But that's a discussion point that could be 
> brought up during
the
> BoF, or sometime afterwards.
> 
> cheers,
> 
> -ken
> 
> 
> > A main document (A) in which we explain the method, the scenarios 
> > and the minimum signaling issues in order to make it work. The idea 
> > is that document
> > (A) would be self-contained. Since we are not defining new protocols
(i.e.
> > already existing compressing, multiplexing and tunneling protocols 
> > are to be used), we understand that this can be done in a single document.
> > It would
> > include:
> >
> > 1- Protocol stack (it would be the "reference model")
> > 2- a negotiation mechanism to decide the options to use at each 
> > layer
> > 3- a mechanism to setup/release a tunnel between a multiplexer and a 
> > de-multiplexer
> >
> > Of course, another approach could be separating 1 from 2&3. However, 
> > we think this is not necessary since the method is not too complicated.
> >
> >
> > Document (B) would only contain recommendations of how to better use 
> > the method proposed in document (A), i.e., classification and 
> > maximum
> delays.
> >
> > So clearly document (B) would totally depend on the reference model 
> > of document (A).
> >
> >
> > The idea of point 9 is to talk about some other interesting ideas 
> > which are considered as "future work":
> > - a mechanism for a multiplexer to discover a de-multiplexer
> > - mechanism to select an optimal multiplexer and a de-multiplexer 
> > when there are more than one muxer/de-muxer for a flow
> > - dynamically applying TCMTF
> > - etc.
> >
> > What do you think?
> >
> > Thanks again for your feedback. Thinking and explaining things is 
> > always a good exercise!
> >
> > Jose
> >
> >> -----Mensaje original-----
> >> De: [email-masked] [mailto:[email-masked]] En 
> >> nombre de ken carlberg Enviado el: miércoles, 27 de febrero de 2013
> >> 16:23
> >> Para: [email-masked]
> >> CC: [email-masked]; [email-masked]
> >> Asunto: Re: [tcmtf] About the possibility of having a BOF about 
> >> TCMTF in
> >> IETF87
> >>
> >> Hola Jose,
> >>
> >> sorry for the tardy reply.  The altered text below is helpful, thanks.
> >>
> >> With respect to your candidate deliverables, it appears that you 
> >> have
> > listed
> >> two for the proposed group: (A) a document that describes options 
> >> and negotiation mechanisms, and (B) a document describing
> recommendations
> >> of which packet types should be multiplexed and a list fo traffic
> > classification
> >> methods.  Have you considered a third document that presents a more 
> >> encompassing architecture or framework that would include sample 
> >> scenarios upon which your deliverables A & B are aimed at?  My 
> >> impression
> > is
> >> that you may want to point the reader of documents A & B to the 
> >> same reference model, and instead of repeating the same text, it 
> >> may be helpful to separate this into a separate document.
> >>
> >> Also, would section 9 of your proposed charter lead one to consider 
> >> a requirements document?  Many times, new groups start with a 
> >> requirements document, but since you have a good focus of what you 
> >> want to accomplish, perhaps your last deliverable could be a 
> >> requirements document that would guide any future work.
> >>
> >> -ken
> >>
> >> ps, I don't want to advocate more work, but rather just have you 
> >> consider other possibilities (and feel free to shoot them down :-)
> >>
> >>
> >> On Feb 22, 2013, at 5:39 AM, Jose Saldana <[email-masked]> wrote:
> >>
> >>> Hi Ken,
> >>>
> >>> Sorry for the delay. I think you are talking about Paragraph 5:
> >>>
> >>> 5. So the first objective of this group is to specify the protocol 
> >>> stack for tunneling, compressing and multiplexing traffic flows 
> >>> (TCMTF). Since standard protocols are being used at each layer, 
> >>> the signaling methods of those protocols will be used.
> >>> Interactions with the Working Groups and Areas in which these 
> >>> protocols are developed can be expected. However, the development 
> >>> of new compressing, multiplexing or tunneling protocols is not an 
> >>> objective of this Working Group. In addition, since the current 
> >>> RFC 4170 would be
> >> considered as one of the options, this RFC could be obsoleted.
> >>>
> >>> Perhaps this is a bit confusing. When we say "at each layer", we 
> >>> are talking about "tunneling, compressing and multiplexing" layers.
> >>> Perhaps this can be a bit confusing. What about this?:
> >>>
> >>> 5. So the first objective of this group is to specify the protocol 
> >>> stack for tunneling, compressing and multiplexing traffic flows 
> >>> (TCMTF). Since standard protocols are being used for tunneling, 
> >>> compressing and multiplexing layers, the signaling methods of 
> >>> those
> >> protocols will be used.
> >>> Interactions with the Working Groups and Areas in which these 
> >>> protocols are developed can be expected. However, the development
> of
> >>> new compressing, multiplexing or tunneling protocols is not an 
> >>> objective of this Working Group. In addition, since the current 
> >>> RFC
> >>> 4170 would be considered as one of the options, this RFC could be
> >> obsoleted.
> >>>
> >>> Is this what you were asking?
> >>>
> >>> Thanks for your feedback.
> >>>
> >>> Jose
> >>>
> >>>> -----Mensaje original-----
> >>>> De: [email-masked] [mailto:[email-masked]] En 
> >>>> nombre de ken carlberg Enviado el: martes, 19 de febrero de 2013
> >>>> 14:17
> >>>> Para: [email-masked]
> >>>> CC: [email-masked]; [email-masked]
> >>>> Asunto: Re: [tcmtf] About the possibility of having a BOF about 
> >>>> TCMTF in
> >>>> IETF87
> >>>>
> >>>> Hola Jose,
> >>>>
> >>>> could you expand a bit more on your text in the proposed charter 
> >>>> regarding "signaling methods".  Are you speaking in the more 
> >>>> general context of information stored in headers of various 
> >>>> protocol up and down the stack
> >>> (ie,
> >>>> layers 3, 4, and 5/app)?  Or, are you  speaking of concurrent 
> >>>> resource signaling protocols like RSVP/RSVP-TE, or path 
> >>>> establishment protocols
> >>> like
> >>>> MPLS?  Or, some combination of both?
> >>>>
> >>>> -ken
> >>>>
> >>>> _______________________________________________
> >>>> tcmtf mailing list
> >>>> [email-masked]
> >>>> https://www.ietf.org/mailman/listinfo/tcmtf
> >>>
> >>
> >> _______________________________________________
> >> tcmtf mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/tcmtf
> >

_______________________________________________
tcmtf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 06 Jun 2013 11:52:59 +0000

And what about:

TCMTF - negotiation protocol

Do you found it more descriptive?

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

On 06/06/13 11:51, "Mirko Sužnjević" <[email-masked]> wrote:

>Perhaps include negotiation in the name of the draft so its purpose is
>evident from the title? As the purpose of that draft is to establish
>which particular parameters will be used.
>My suggestions are:
>In the conf-call of yesterday it was also clear that for the IETF it is
>better to split Document A into two documents:
>
>- The "TCMTF reference model" (1): the protocol stack and scenarios. It
>should be said that each protocol at each layer will use its own
>signaling mechanisms.
>
>       - a negotiation mechanism (2) to decide the options to use at each layer
>(e.g. a mux and demux agree on using ROHC+PPPMux+GRE)
>By now, we don't have to propose the "TCMTF specific signaling". It would
>be something to be deployed if the Working Group is created.
>
>This same idea was proposed by Ken Carlberg in February. The advantages
>of this new distribution of the documents are (quoting Ken):
>

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Mirko Sužnjević <[email-masked]>
Date: Thu, 6 Jun 2013 12:31:37 +0000

Yes i think that is better.
Mirko

-----Original Message-----
From: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] 
Sent: Thursday, June 6, 2013 1:53 PM
To: Mirko Sužnjević; [email-masked]
Subject: Re: [tcmtf] TCMTF: Documents to be generated. Small modification

And what about:

Regards,

Fernando Pascual Blanco

On 06/06/13 11:51, "Mirko Sužnjević" <[email-masked]> wrote:

>       - a negotiation mechanism (2) to decide the options to use at 
>each layer (e.g. a mux and demux agree on using ROHC+PPPMux+GRE)
>By now, we don't have to propose the "TCMTF specific signaling". It 
>would be something to be deployed if the Working Group is created.
>
>> impression is that you may want to point the reader of documents A & 
>> B to the same reference model, and instead of repeating the same 
>> text, it may be helpful to separate this into a separate document.
>
>
>> (below) can change over time and yet 1 (the reference model) does 
>> not, then it may be best to separate 1 from the other items.
>>
>> to accomplish in the future, then having a requirements document 
>> would be helpful to focus those thoughts without having to have one 
>> > 3- a mechanism to setup/release a tunnel between a multiplexer and 
>> > a de-multiplexer
>> >
>> > Of course, another approach could be separating 1 from 2&3. 
>> > However, we think this is not necessary since the method is not too
>>complicated.
>> >
>> >
>> > Document (B) would only contain recommendations of how to better 
>> > use the method proposed in document (A), i.e., classification and 
>> > maximum
>> delays.
>> >
>> >> methods.  Have you considered a third document that presents a 
>> >> more encompassing architecture or framework that would include 
>> >> sample scenarios upon which your deliverables A & B are aimed at?  
>> >> My impression
>> > is
>> >> Also, would section 9 of your proposed charter lead one to 
>> >> consider a requirements document?  Many times, new groups start 
>> >> with a requirements document, but since you have a good focus of 
>> >> what you want to accomplish, perhaps your last deliverable could 
>> >> be a requirements document that would guide any future work.
>> >>
>> >> -ken
>> >>
>> >>> 5. So the first objective of this group is to specify the 
>> >>> protocol stack for tunneling, compressing and multiplexing 
>> >>> traffic flows (TCMTF). Since standard protocols are being used at 
>> >>> each layer, the signaling methods of those protocols will be used.
>> >>> 5. So the first objective of this group is to specify the 
>> >>> protocol stack for tunneling, compressing and multiplexing 
>> >>> traffic flows (TCMTF). Since standard protocols are being used 
>> >>> for tunneling, compressing and multiplexing layers, the signaling 
>> >>> methods of those
>> >> protocols will be used.

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 6 Jun 2013 15:05:17 +0200

One question:

The new second draft should include:

- The negotiation
- The setup/release a TCMTF tunnel between a mux and a demux

Do you think "TCMTF - negotiation protocol" also includes the second idea?

Would it be better "TCMTF - negotiation and setup" ?

Thanks!

Jose

> De: [email-masked] [mailto:[email-masked]] En nombre de
> Mirko Sužnjevic
> Enviado el: jueves, 06 de junio de 2013 14:32
> Para: FERNANDO PASCUAL BLANCO; [email-masked]
> Asunto: Re: [tcmtf] TCMTF: Documents to be generated. Small modification
> 
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 06 Jun 2013 13:15:21 +0000

Hmmm... The necessary outcome of the negotiation is the setup. I'd keep the shorter name.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 7 Jun 2013 09:37:26 +0200

Ok then.

We can use these document names in the new version of the Charter (I will
try to rewrite it by Tuesday):

- TCMTF - reference model:
	the protocol stack and scenarios. It should be said that each
protocol at each layer will use its own signaling mechanisms.
	https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

- TCMTF - negotiation protocol:
	- a mechanism to setup/release a TCMTF tunnel between a multiplexer
and a de-multiplexer, including the negotiation mechanism to decide the
options to use at each layer

- TCMTF - recommendations: 
	useful recommendations in order to decide which packet flows can or
can not be multiplexed and how. A list of available traffic classification
methods which can be used for identification of the service or application
to which a particular flow belongs, as well as recommendations of the
maximum delay and jitter to be added depending of the identified service or
application.
	http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/

Any comments?

Jose

> Diego R. Lopez
> Enviado el: jueves, 06 de junio de 2013 15:15
> Para: <[email-masked]>
> CC: <[email-masked]>; Mirko Sužnjević; FERNANDO PASCUAL BLANCO
> >> De: [email-masked] [mailto:[email-masked]] En nombre
> >> de Mirko Sužnjevic Enviado el: jueves, 06 de junio de 2013 14:32
> >>> Perhaps include negotiation in the name of the draft so its purpose
> >>> is evident from the title? As the purpose of that draft is to
> >>> establish which particular parameters will be used.
> >>> My suggestions are:
> >>> In the conf-call of yesterday it was also clear that for the IETF it
> >>> is better to split Document A into two documents:
> >>>
> >>> - The "TCMTF reference model" (1): the protocol stack and scenarios.
> >>> It should be said that each protocol at each layer will use its own
> >>> signaling mechanisms.
> >>>
> >>> This same idea was proposed by Ken Carlberg in February. The
> >>> advantages of this new distribution of the documents are (quoting
Ken):
> >>>> My impression is that you may want to point the reader of documents
> >>>> A & B to the same reference model, and instead of repeating the
> >>>> same text, it may be helpful to separate this into a separate
document.
> >>>> De: ken carlberg [mailto:[email-masked]] Enviado el: martes,
> >>>> 05 de marzo de 2013 17:07
> >>>> Para: [email-masked]
> >>>> tardy repsonse.  Its helpful to understand that document A and B
> >>>> are sequential
> >>> to
> >>>> each other.  One thing to keep in mind is that if its possible that
> >>>> 2 and
> >>> 3
> >>>>> and the minimum signaling issues in order to make it work. The
> >>>>> idea is that document
> >>>>> So clearly document (B) would totally depend on the reference
> >>>>> model of document (A).
> >>>>>
> >>>>>
> >>>>>>> at each layer, the signaling methods of those protocols will be
used.
> >>>>>>> of new compressing, multiplexing or tunneling protocols is not
> >>>>>>> an objective of this Working Group. In addition, since the
> >>>>>>> current RFC 4170 would be
> >>>>>>> for tunneling, compressing and multiplexing layers, the
> >>>>>>> signaling methods of those
> >>>>>> protocols will be used.
> >>>>>>>> could you expand a bit more on your text in the proposed
> >>>>>>>> charter regarding "signaling methods".  Are you speaking in the
> >>>>>>>> more general context of information stored in headers of
> >>>>>>>> various protocol up and down the stack
> >>>>>>> (ie,
> >> Este mensaje se dirige exclusivamente a su destinatario. Puede
> >> consultar nuestra política de envío y recepción de correo electrónico
> >> en el enlace situado más abajo.
> >> This message is intended exclusively for its addressee. We only send
> >> and receive email on the basis of the terms set out at:

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Fri, 07 Jun 2013 07:56:06 +0000

Hi Jose,

        I have doubts about the description of the second document, why are you
focusing the description on the tunneling layer? I understand that there
will be two options: a dialog (protocol) to negotiate every option at each
layer or three dialogs to negotiate each layer, but in that case the
tunnel layer will not be different from others. What do you think about a
description less tunnel oriented?

Regards,

Fernando Pascual Blanco

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 7 Jun 2013 10:51:51 +0200

You are right, Fernando. The question is that in the end everything travels
in a tunnel. But this may sound confusing, since tunneling is just one of
the layers. What about this?

We can talk about a "TCMTF session" or a "TCMTF communication" instead of
"TCMTF tunnel".

I prefer "TCMTF session":

- TCMTF - negotiation protocol:
	- a mechanism to setup/release a *TCMTF session* between a
multiplexer and a de-multiplexer, including the negotiation mechanism to
decide the options to use at each layer (header compression, multiplexing
and tunneling)

Which one do you prefer? Other names?

Thanks!

Jose

> FERNANDO PASCUAL BLANCO
> Enviado el: viernes, 07 de junio de 2013 9:56
> Para: [email-masked]; Diego R. Lopez; 'Mirko Sužnjević'
> CC: [email-masked]
>         I have doubts about the description of the second document, why
are
> you focusing the description on the tunneling layer? I understand that
there
> layer or three dialogs to negotiate each layer, but in that case the
tunnel
> layer will not be different from others. What do you think about a
description
> less tunnel oriented?
> >We can use these document names in the new version of the Charter (I
> >will try to rewrite it by Tuesday):
> >
> >       - a mechanism to setup/release a TCMTF tunnel between a
> >multiplexer and a de-multiplexer, including the negotiation mechanism
> >to decide the options to use at each layer
> >
> >
> >       useful recommendations in order to decide which packet flows can
> >or can not be multiplexed and how. A list of available traffic
> >classification methods which can be used for identification of the
> >service or application to which a particular flow belongs, as well as
> >recommendations of the maximum delay and jitter to be added depending
> >of the identified service or application.
> >> de Diego R. Lopez Enviado el: jueves, 06 de junio de 2013 15:15
> >> > Do you think "TCMTF - negotiation protocol" also includes the
> >> > second
> >idea?
> >> >
> >> >> nombre de Mirko Sužnjevic Enviado el: jueves, 06 de junio de 2013
> >> >> 14:32
> >> >> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP
> F
> >> >> +34913128779 M +34682005168 [email-masked]
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>> Perhaps include negotiation in the name of the draft so its
> >> >>> purpose is evident from the title? As the purpose of that draft
> >> >>> is to establish which particular parameters will be used.
> >> >>> My suggestions are:
> >> >>> In the conf-call of yesterday it was also clear that for the IETF
> >> >>> it is better to split Document A into two documents:
> >> >>>
> >> >>> It should be said that each protocol at each layer will use its
> >> >>> own signaling mechanisms.
> >> >>>
> >> >>>      - a negotiation mechanism (2) to decide the options to use
> >> >>> at each layer (e.g. a mux and demux agree on using
> ROHC+PPPMux+GRE)
> >> >>> The current draft is the TCMTF "reference model", since it does
> >> >>> not talk about specific signaling issues.
> >> >>>
> >> >>> By now, we don't have to propose the "TCMTF specific signaling".
> >> >>> It would be something to be deployed if the Working Group is
> created.
> >> >>>
> >> >>>> (below) can change over time and yet (1) (the reference model)
> >> >>>> does not, then it may be best to separate (1) from the other
items.
> >> >>>> My impression is that you may want to point the reader of
> >> >>>> documents A & B to the same reference model, and instead of
> >> >>>> repeating the same text, it may be helpful to separate this into
> >> >>>> a separate
> >document.
> >> >>>
> >> >>>
> >> >>>> Thanks for the expanded explanation, and again, apologies for
> >> >>>> the tardy repsonse.  Its helpful to understand that document A
> >> >>>> and B are sequential
> >> >>> to
> >> >>>> (below) can change over time and yet 1 (the reference model)
> >> >>>> does not, then it may be best to separate 1 from the other items.
> >> >>>>
> >> >>>> as for what you outline as a discussion point for future work,
> >> >>>> it seems
> >> >>> fine.  I
> >> >>>> would be helpful to focus those thoughts without having to have
> >> >>>> one particular solution.  But that's a discussion point that
> >> >>>> could be brought up during
> >> >>> the
> >> >>>>> A main document (A) in which we explain the method, the
> >> >>>>> scenarios and the minimum signaling issues in order to make it
> >> >>>>> work. The idea is that document
> >> >>>>> already existing compressing, multiplexing and tunneling
> >> >>>>> protocols are to be used), we understand that this can be done
> >> >>>>> in a single
> >> >>>> document.
> >> >>>>> It would
> >> >>>>> include:
> >> >>>>>
> >> >>>>> 3- a mechanism to setup/release a tunnel between a multiplexer
> >> >>>>> and a de-multiplexer
> >> >>>>>
> >> >>>>> Document (B) would only contain recommendations of how to
> >> >>>>> better use the method proposed in document (A), i.e.,
> >> >>>>> classification and maximum
> >> >>>> delays.
> >> >>>>>
> >> >>>>> The idea of point 9 is to talk about some other interesting
> >> >>>>> ideas which are considered as "future work":
> >> >>>>> - mechanism to select an optimal multiplexer and a
> >> >>>>> de-multiplexer when there are more than one muxer/de-muxer
> for
> >> >>>>> a flow
> >> >>>>> Thanks again for your feedback. Thinking and explaining things
> >> >>>>> is always a good exercise!
> >> >>>>>
> >> >>>>> Jose
> >> >>>>>
> >> >>>>>> Asunto: Re: [tcmtf] About the possibility of having a BOF
> >> >>>>>> about TCMTF in
> >> >>>>>> IETF87
> >> >>>>>>
> >> >>>>>> Hola Jose,
> >> >>>>>>
> >> >>>>>> With respect to your candidate deliverables, it appears that
> >> >>>>>> you have
> >> >>>>> listed
> >> >>>>>> two for the proposed group: (A) a document that describes
> >> >>>>>> options and negotiation mechanisms, and (B) a document
> >> >>>>>> describing
> >> >>>> recommendations
> >> >>>>>> that you may want to point the reader of documents A & B to
> >> >>>>>> the same reference model, and instead of repeating the same
> >> >>>>>> consider a requirements document?  Many times, new groups
> >> >>>>>> start with a requirements document, but since you have a good
> >> >>>>>> focus of what you want to accomplish, perhaps your last
> >> >>>>>> deliverable could be a requirements document that would guide
> any future work.
> >> >>>>>>
> >> >>>>>> -ken
> >> >>>>>>
> >> >>>>>> ps, I don't want to advocate more work, but rather just have
> >> >>>>>> you consider other possibilities (and feel free to shoot them
> >> >>>>>> down
> >> >>>>>> :-)
> >> >>>>>>
> >> >>>>>>
> >> >>>>>>> traffic flows (TCMTF). Since standard protocols are being
> >> >>>>>>> used at each layer, the signaling methods of those protocols
> >> >>>>>>> will be
> >used.
> >> >>>>>>> of new compressing, multiplexing or tunneling protocols is
> >> >>>>>>> not an objective of this Working Group. In addition, since
> >> >>>>>>> the current RFC 4170 would be
> >> >>>>>>> Perhaps this is a bit confusing. When we say "at each layer",
> >> >>>>>>> we are talking about "tunneling, compressing and multiplexing"
> >layers.
> >> >>>>>>> traffic flows (TCMTF). Since standard protocols are being
> >> >>>>>>> used for tunneling, compressing and multiplexing layers, the
> >> >>>>>>> new compressing, multiplexing or tunneling protocols is not
> >> >>>>>>> current RFC
> >> >>>>>>>> De: [email-masked] [mailto:[email-masked]]
> >> >>>>>>>> En nombre de ken carlberg Enviado el: martes, 19 de febrero
> >> >>>>>>>> de
> >> >>>>>>>> 2013
> >> >>>>>>>> 14:17
> >> >>>>>>>> Para: [email-masked]
> >> >>>>>>>> Asunto: Re: [tcmtf] About the possibility of having a BOF
> >> >>>>>>>> about TCMTF in
> >> >>>>>>>> IETF87
> >> >>>>>>>>
> >> >>>>>>>> Hola Jose,
> >> >>>>>>>>
> >> >>>>>>>> charter regarding "signaling methods".  Are you speaking in
> >> >>>>>>>> the more general context of information stored in headers of
> >> >>>>>>>> layers 3, 4, and 5/app)?  Or, are you  speaking of
> >> >>>>>>>> concurrent resource signaling protocols like RSVP/RSVP-TE,
> >> >>>>>>>> or path establishment protocols
> >> >>>>>>> like
> >> >> consultar nuestra política de envío y recepción de correo
> >> >> electrónico en el enlace situado más abajo.
> >> >> This message is intended exclusively for its addressee. We only
> >> >> send and receive email on the basis of the terms set out at:

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Fri, 07 Jun 2013 08:54:38 +0000

It sounds very good!

Saludos,

Fernando Pascual Blanco