Re: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87

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

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:[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
> >