Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1

[FERNANDO PASCUAL BLANCO <[e-mail]>]

Hi all,

        I also agree with the idea of including the mux-demux signaling within
the draft A (as Dan said, they are capabilities negotiation). This draft
should be able to get two boxes with TCMTF fully working between them.
Under my point of view this includes the definition of the capabilities in
each node and the negotiation of that capabilities.
        On the other hand,  the selection of flows to be potentially TCMTFed
could be something undefined at the beginning (it may be statically
configured for example), but it is something that will NEED to be defined
to be dynamically enforced at the mux from a higher entity (policy
manager). That functionality would be addressed to a different draft in
the future, re-chartering the WG.
        Regarding the "dynamically establishing, modifying and releasing tunnels"
I also agree with Muthu that it is something that can be added later.

Regards,

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




On 10/01/13 10:26, "Muthu Arul Mozhi Perumal (mperumal)"
<[e-mail]> wrote:

>Along with it I think we also need a way for the muxer and de-muxer to
>discover each other. In a way it is a generalization of:
>> dynamically establishing, modifying and releasing tunnels
>
>Once we have that the muxer and de-muxer can setup a tunnel on-demand and
>don't have to assume that there is always a muxer/de-muxer at the other
>end of an existing tunnel.
>
>When a muxer/de-muxer discovers more than one de-muxer/muxer, we may also
>need a mechanism to elect a muxer and a de-muxer for a flow -- but, I
>think it can be added later.
>
>Muthu
>
>|-----Original Message-----
>|From: [e-mail] [mailto:[e-mail]] On Behalf
>Of JUAN ANTONIO CASTELL LUCIA
>|Sent: Thursday, January 10, 2013 2:46 AM
>|To: Dan Wing (dwing); [e-mail]; [e-mail]
>|Subject: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
>|
>|Hi all, I agree with Dan. The first kind of signaling
>("auto-negotiation") is needed from the
>|beginning if we don't want an extremely static protocol and therefore
>possibly difficult to get it
>|working, especially when in most of cases the peers belong to different
>entities/companies.
>|
>|I think the second kind of signaling (dynamic (de)activation) is very
>useful in many scenarios (e.g.
>|unexpected congestion in a segment of the network, or in the service
>provider that would accept that
>|extra delay or jitter in those circumstances), but it could be an
>extension that can be added later.
>|
>|Regards
>|
>|-----Mensaje original-----
>|De: [e-mail] [mailto:[e-mail]] En nombre de
>Dan Wing
>|Enviado el: miércoles, 09 de enero de 2013 17:24
>|Para: [e-mail]; [e-mail]
>|Asunto: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
>|
>|> -----Original Message-----
>|> From: Jose Saldana [mailto:[e-mail]]
>|> Sent: Wednesday, January 09, 2013 8:08 AM
>|> To: 'Dan Wing'; [e-mail]
>|> Subject: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
>|> 1
>|>
>|> Dan,
>|>
>|> The question is if we should include in the charter this objective:
>|> writing a document about two things which have somewhat appeared
>|> during the
>|> discussion:
>|>
>|> - Negotiation mechanisms to decide the options at each layer
>|> (compression, multiplexing and tunneling) between mux and demux.
>|> Perhaps the mux has ROHC, ECRTP and IPHC, and the demux only has ECRTP
>|> and IPHC, so the two machines will have to negotiate in order to
>|> decide which compression protocol use.
>|
>|We need that -- it is capabilities negotiation.  It is needed because
>the protocol will fail if one
>|side mistakenly thinks the other side has certain functionality, and
>because we will want to add some
>|fancy new compression in the year 2020 and will need to negotiate it.
>|
>|I don't think it needs to be a separate milestone or a separate
>document, though.
>|
>|> - dynamically establishing, modifying and releasing tunnels
>|
>|-d
>|
>|> Best regards,
>|>
>|> Jose
>|>
>|> > -----Mensaje original-----
>|> > De: Dan Wing [mailto:[e-mail]] Enviado el: miércoles, 09 de
>|> > enero de 2013 16:38
>|> > Para: [e-mail]; [e-mail]
>|> > Asunto: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
>|> > 1
>|> >
>|> > > -----Original Message-----
>|> > > From: [e-mail] [mailto:[e-mail]] On
>|> > > Behalf Of Jose Saldana
>|> > > Sent: Wednesday, January 09, 2013 1:48 AM
>|> > > To: [e-mail]
>|> > > Subject: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
>|> > > 1
>|> > >
>|> > > One question is if we should consider the creation of a specific
>|> > > draft about signaling issues.
>|> >
>|> > So, this is a 'problem statement', describing the problem we're
>|> > trying to
>|> solve
>|> > (e.g., the application's tolerance for TCMTF-induced jitter)?
>|> > Or, this is a document analyzing how we signal TCMTF capabilities to
>|> > the other end?
>|> >
>|> >
>|> > > In paragraph 5, I have written the idea, but I don't currently
>|> > > know if it is necessary at this stage: "a mechanism to negotiate
>|> > > which concrete option would they use in each layer".
>|> > >
>|> > >
>|> > >
>|> > > My opinion: We could first focus on drafts (A) and (B), and later
>|> > > re- charter the WG if necessary in order to consider this other
>|> document.
>|> >
>|> > Agreed.
>|> >
>|> > -d
>|> >
>|> >
>|> > >
>|> > >
>|> > >
>|> > > What do you think?
>|> > >
>|> > >
>|> > >
>|> > > Jose
>|> > >
>|> > >
>|
>|
>|_______________________________________________
>|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
>_______________________________________________
>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