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

["Muthu Arul Mozhi Perumal (mperumal)" <[e-mail]>]

Hi Fernando,

|        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.

I think it is the opposite -- in local environments you can provision/associate them manually. However, in a multi-vendor environment over the Internet this should happen automatically.

|        #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.

Agree.

|        #3 I think should be included in the draft A, since it is a
|mechanism within the TFMTF protocol itself.

Agree.

Muthu

|-----Original Message-----
|From: [e-mail] [mailto:[e-mail]] On Behalf Of FERNANDO PASCUAL BLANCO
|Sent: Thursday, January 10, 2013 6:04 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 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
|_______________________________________________
|tcmtf mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/tcmtf