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

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

Thanks, Ken.

The idea is this:

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