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

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

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