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: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de
>> ken carlberg
>> Enviado el: miércoles, 27 de febrero de 2013 16:23
>> Para: jsaldana@unizar.es
>> CC: tcmtf@ietf.org; tsv-area@ietf.org
>> 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 <jsaldana@unizar.es> 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: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre
>>>> de ken carlberg Enviado el: martes, 19 de febrero de 2013 14:17
>>>> Para: jsaldana@unizar.es
>>>> CC: tcmtf@ietf.org; tsv-area@ietf.org
>>>> 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
>>>> tcmtf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/tcmtf
>>> 
>> 
>> _______________________________________________
>> tcmtf mailing list
>> tcmtf@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcmtf
> 