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

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

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