Hi all. I would like to know your feedback (especially from tcmtf co-authors) about this proposal of Ken:
- Currently, we are thinking about document A including these things: 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 - The proposal of Ken is to split this into two documents: I, including 1) II, including 2) and 3) As Ken says, "One thing to keep in mind is that if it's possible that 2 and 3 (below) can change over time and yet 1 (the reference model) does not,(...)" What do you think? Would this complicate or simplify things? Considering the possibility of having a Working Group, would it be a better approach to split the problem this way? Thanks a lot, Ken and everyone! Jose > -----Mensaje original----- > De: ken carlberg [mailto:[email protected]] > Enviado el: martes, 05 de marzo de 2013 17:07 > Para: [email protected] > CC: 'ken carlberg'; [email protected]; [email protected] > 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 protected] [mailto:[email protected]] En nombre > >> de ken carlberg Enviado el: miércoles, 27 de febrero de 2013 16:23 > >> Para: [email protected] > >> CC: [email protected]; [email protected] > >> 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 protected]> 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 protected] [mailto:[email protected]] En > >>>> nombre de ken carlberg Enviado el: martes, 19 de febrero de 2013 > >>>> 14:17 > >>>> Para: [email protected] > >>>> CC: [email protected]; [email protected] > >>>> 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 protected] > >>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>> > >> > >> _______________________________________________ > >> tcmtf mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/tcmtf > >
