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

["Jose Saldana" <[e-mail]>]

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

> -----Mensaje original-----
> De: [e-mail] [mailto:[e-mail]] En nombre de
> FERNANDO PASCUAL BLANCO
> Enviado el: viernes, 07 de junio de 2013 9:56
> Para: [e-mail]; Diego R. Lopez; 'Mirko Sužnjević'
> CC: [e-mail]
> Asunto: Re: [tcmtf] TCMTF: Documents to be generated. Small modification
> 
> 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
> Telefónica Global Resources
> Network Automation and Dynamization
> TECHNOLOGY PEOPLE GROUP
> F [phone]
> M [phone]
> [e-mail]
> 
> 
> 
> 
> On 07/06/13 09:37, "Jose Saldana" <[e-mail]> wrote:
> 
> >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
> >
> >> -----Mensaje original-----
> >> De: [e-mail] [mailto:[e-mail]] En nombre
> >> de Diego R. Lopez Enviado el: jueves, 06 de junio de 2013 15:15
> >> Para: <[e-mail]>
> >> CC: <[e-mail]>rg>; Mirko Sužnjević; FERNANDO PASCUAL BLANCO
> >> Asunto: Re: [tcmtf] TCMTF: Documents to be generated. Small
> >> modification
> >>
> >> Hmmm... The necessary outcome of the negotiation is the setup. I'd
> >> keep the shorter name.
> >>
> >> Be goode,
> >>
> >> On 6 Jun 2013, at 15:05 , Jose Saldana wrote:
> >>
> >> > 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
> >> >
> >> >> -----Mensaje original-----
> >> >> De: [e-mail] [mailto:[e-mail]] En
> >> >> nombre de Mirko Sužnjevic Enviado el: jueves, 06 de junio de 2013
> >> >> 14:32
> >> >> Para: FERNANDO PASCUAL BLANCO; [e-mail]
> >> >> Asunto: Re: [tcmtf] TCMTF: Documents to be generated. Small
> >> >> modification
> >> >>
> >> >> Yes i think that is better.
> >> >> Mirko
> >> >>
> >> >> -----Original Message-----
> >> >> From: FERNANDO PASCUAL BLANCO [mailto:[e-mail]]
> >> >> Sent: Thursday, June 6, 2013 1:53 PM
> >> >> To: Mirko Sužnjević; [e-mail]
> >> >> Subject: Re: [tcmtf] TCMTF: Documents to be generated. Small
> >> >> modification
> >> >>
> >> >> 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
> >> >> [phone] M [phone] [e-mail]
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On 06/06/13 11:51, "Mirko Sužnjević" <[e-mail]>
> wrote:
> >> >>
> >> >>> 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: [e-mail] [mailto:[e-mail]] On
> >> >>> Behalf Of Jose Saldana
> >> >>> Sent: Wednesday, June 5, 2013 12:56 PM
> >> >>> To: [e-mail]
> >> >>> Cc: [e-mail]; [e-mail]; '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:[e-mail]] Enviado el:
> >> >>>> martes,
> >> >>>> 05 de marzo de 2013 17:07
> >> >>>> Para: [e-mail]
> >> >>>> CC: 'ken carlberg'; [e-mail]; [e-mail]
> >> >>>> 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: [e-mail] [mailto:[e-mail]] En
> >> >>>>>> nombre de ken carlberg Enviado el: miércoles, 27 de febrero de
> >> >>>>>> 2013
> >> >>>>>> 16:23
> >> >>>>>> Para: [e-mail]
> >> >>>>>> CC: [e-mail]; [e-mail]
> >> >>>>>> 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 <[e-mail]>
> >> >> 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: [e-mail] [mailto:[e-mail]]
> >> >>>>>>>> En nombre de ken carlberg Enviado el: martes, 19 de febrero
> >> >>>>>>>> de
> >> >>>>>>>> 2013
> >> >>>>>>>> 14:17
> >> >>>>>>>> Para: [e-mail]
> >> >>>>>>>> CC: [e-mail]; [e-mail]
> >> >>>>>>>> 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
> >> >>>>>>>> [e-mail]
> >> >>>>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
> >> >>>>>>>
> >> >>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> tcmtf mailing list
> >> >>>>>> [e-mail]
> >> >>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
> >> >>>>>
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> tcmtf mailing list
> >> >>> [e-mail]
> >> >>> https://www.ietf.org/mailman/listinfo/tcmtf
> >> >>> _______________________________________________
> >> >>> tcmtf mailing list
> >> >>> [e-mail]
> >> >>> https://www.ietf.org/mailman/listinfo/tcmtf
> >> >>
> >> >>
> >> >> ________________________________
> >> >>
> >> >> 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
> >> >> _______________________________________________
> >> >> tcmtf mailing list
> >> >> [e-mail]
> >> >> https://www.ietf.org/mailman/listinfo/tcmtf
> >> >
> >> > _______________________________________________
> >> > tcmtf mailing list
> >> > [e-mail]
> >> > https://www.ietf.org/mailman/listinfo/tcmtf
> >>
> >>
> >> --
> >> "Esta vez no fallaremos, Doctor Infierno"
> >>
> >> Dr Diego R. Lopez
> >> Telefonica I+D
> >> http://people.tid.es/diego.lopez/
> >>
> >> e-mail: [e-mail]
> >> Tel:    [phone]
> >> Mobile: [phone]
> >> -----------------------------------------
> >>
> >>
> >> ________________________________
> >>
> >> 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
> >> _______________________________________________
> >> tcmtf mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcmtf
> >
> 
> 
> ________________________________
> 
> 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
> _______________________________________________
> tcmtf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcmtf