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

[MANUEL NUÑEZ SANZ <[e-mail]>]

Hi,
    I see the link between 1 and 2, but I also think the negotiation mechanisms in 2 are also very linked with other ones  because you could need some information from the other parts to decide the best options. In brief, I think it is better not split unless the changes  in 2 were a lot in short time.

Regards,
   Manuel.

-----Mensaje original-----
De: [e-mail] [mailto:[e-mail]] En nombre de FERNANDO PASCUAL BLANCO
Enviado el: martes, 19 de marzo de 2013 18:41
Para: [e-mail]; 'ken carlberg'; [e-mail]
CC: [e-mail]
Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87

Hi Jose, Ken,

        My thought is that 3 should is very linked with the tunneling layer, so 3 should evolve only if tunnel mechanisms adopted by TCMTF evolve or if TCMTF adopt new tunneling layers. Because of that, I think that I see 1 together with 3, and define protocol extensions in the future if needed (BTW, my experience here is very short).
        On the other hand, it is true that 2 could be a different document, but I remember that it was included to provide a implementation guide to the protocol itself and bring it to the earth, and not only define TCMTF.
Anyway, I don´t know if 2 mechanisms will evolve so much, a part from the different capabilities set to be negotiated here.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F [phone]
M [phone]
[e-mail]




On 19/03/13 11:34, "Jose Saldana" <[e-mail]> wrote:

>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
>> >
>
>
>_______________________________________________
>tcmtf mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tcmtf


________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
tcmtf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tcmtf

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx