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

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

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