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 >
