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

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

Hi Muthu,

        Regarding #1, to be honest, I am not completely sure of the need to
specify a mechanism to discover muxes and demuxes between them. I think
those kind of mechanisms have more sense in local environments but I´m not
sure if it applies here. At least at the beginning this associations can
be done manually.
        #2 is more related to the higher entity that has to decide whether a flow
should be TCMTFed or not, and under my point of view it can be addressed
in a different draft.
        #3 I think should be included in the draft A, since it is a mechanism
within the TFMTF protocol itself.

        What do you think?

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 12:52, "Muthu Arul Mozhi Perumal (mperumal)"
<[e-mail]> wrote:

>Hi Fernando,
>
>I think there are 3 parts to:
>dynamically establishing, modifying and releasing tunnels
>
>1. A mechanism for a muxer to discover a de-muxer (and vice versa).
>2. A mechanism to elect an optimal muxer and a de-muxer when there
>   are more than one muxer/de-muxer for a flow.
>3. A mechanism to setup/release a tunnel b/w a muxer and a de-muxer.
>
>#1 needs to be specified.
>#2 can be added later.
>#3 many not require much specification.
>
>Muthu
>
>|-----Original Message-----
>|From: FERNANDO PASCUAL BLANCO [mailto:[e-mail]]
>|Sent: Thursday, January 10, 2013 3:21 PM
>|To: Muthu Arul Mozhi Perumal (mperumal); JUAN ANTONIO CASTELL LUCIA; Dan
>Wing (dwing);
>|[e-mail]; [e-mail]
>|Subject: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
>|
>|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


________________________________

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