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

From: "Jose Saldana" <[email-masked]>
Date: Wed, 9 Jan 2013 10:47:47 +0100

One question is if we should consider the creation of a specific draft about
signaling issues. 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.

What do you think?

Jose

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jan 2013 07:37:40 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jose Saldana
> Sent: Wednesday, January 09, 2013 1:48 AM
> To: [email-masked]
> 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

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 9 Jan 2013 17:07:36 +0100

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.

- dynamically establishing, modifying and releasing tunnels

Best regards,

Jose

> -----Mensaje original-----
> De: Dan Wing [mailto:[email-masked]]
> Enviado el: miércoles, 09 de enero de 2013 16:38
> Para: [email-masked]; [email-masked]
> Asunto: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
> 
> So, this is a 'problem statement', describing the problem we're trying to
solve
> (e.g., the application's tolerance for TCMTF-induced jitter)?

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 9 Jan 2013 08:23:42 -0800

> From: Jose Saldana [mailto:[email-masked]]
> Sent: Wednesday, January 09, 2013 8:08 AM
> To: 'Dan Wing'; [email-masked]
> 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.

-d

> > > From: [email-masked] [mailto:[email-masked]] On
> > > Behalf Of Jose Saldana
> > > One question is if we should consider the creation of a specific
> > > draft about signaling issues.
> >
> > to
> > 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
> > >
> > >

---

From: JUAN ANTONIO CASTELL LUCIA <[email-masked]>
Date: Wed, 09 Jan 2013 21:16:11 +0000

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: [email-masked] [mailto:[email-masked]] En nombre de Dan Wing
Enviado el: miércoles, 09 de enero de 2013 17:24
Para: [email-masked]; [email-masked]
Asunto: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1

> writing a document about two things which have somewhat appeared
> during the
> discussion:
>
> (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.

-d

> > De: Dan Wing [mailto:[email-masked]] Enviado el: miércoles, 09 de
> > enero de 2013 16:38
> > > 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

_______________________________________________
tcmtf mailing list
[email-masked]
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

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 10 Jan 2013 09:26:48 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of JUAN ANTONIO CASTELL LUCIA
|Sent: Thursday, January 10, 2013 2:46 AM
|To: Dan Wing (dwing); [email-masked]; [email-masked]
|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: [email-masked] [mailto:[email-masked]] En nombre de Dan Wing
|Enviado el: miércoles, 09 de enero de 2013 17:24
|Para: [email-masked]; [email-masked]
|Asunto: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
|
|> -----Original Message-----
|> From: Jose Saldana [mailto:[email-masked]]
|> Sent: Wednesday, January 09, 2013 8:08 AM
|> To: 'Dan Wing'; [email-masked]
|> 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:[email-masked]] Enviado el: miércoles, 09 de
|> > enero de 2013 16:38
|> > Para: [email-masked]; [email-masked]
|> > Asunto: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
|> > 1
|> >
|> > > -----Original Message-----
|> > > From: [email-masked] [mailto:[email-masked]] On
|> > > Behalf Of Jose Saldana
|> > > Sent: Wednesday, January 09, 2013 1:48 AM
|> > > To: [email-masked]
|> > > 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
[email-masked]
|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
[email-masked]
|https://www.ietf.org/mailman/listinfo/tcmtf

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 10 Jan 2013 09:51:18 +0000

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 +34913128779
M +34682005168
[email-masked]

On 10/01/13 10:26, "Muthu Arul Mozhi Perumal (mperumal)"
<[email-masked]> 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:
>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
>

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Thu, 10 Jan 2013 11:52:24 +0000

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:[email-masked]]
|Sent: Thursday, January 10, 2013 3:21 PM
|To: Muthu Arul Mozhi Perumal (mperumal); JUAN ANTONIO CASTELL LUCIA; Dan Wing (dwing);
[email-masked]; [email-masked]
|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 +34913128779
|M +34682005168
[email-masked]
|
|
|
|
|On 10/01/13 10:26, "Muthu Arul Mozhi Perumal (mperumal)"
|<[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf
|>Of JUAN ANTONIO CASTELL LUCIA
|>|Sent: Thursday, January 10, 2013 2:46 AM
|>|To: Dan Wing (dwing); [email-masked]; [email-masked]
|>|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: [email-masked] [mailto:[email-masked]] En nombre de
|>Dan Wing
|>|Enviado el: miércoles, 09 de enero de 2013 17:24
|>|Para: [email-masked]; [email-masked]
|>|Asunto: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
|>|
|>|> -----Original Message-----
|>|> From: Jose Saldana [mailto:[email-masked]]
|>|> Sent: Wednesday, January 09, 2013 8:08 AM
|>|> To: 'Dan Wing'; [email-masked]
|>|> 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:[email-masked]] Enviado el: miércoles, 09 de
|>|> > enero de 2013 16:38
|>|> > Para: [email-masked]; [email-masked]
|>|> > Asunto: RE: [tcmtf] Questions regarding the TCMTF WG Chart proposal.
|>|> > 1
|>|> >
|>|> > > -----Original Message-----
|>|> > > From: [email-masked] [mailto:[email-masked]] On
|>|> > > Behalf Of Jose Saldana
|>|> > > Sent: Wednesday, January 09, 2013 1:48 AM
|>|> > > To: [email-masked]
|>|> > > 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
|>[email-masked]
|>|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
|>[email-masked]
|>|https://www.ietf.org/mailman/listinfo/tcmtf
|>_______________________________________________
|>tcmtf mailing list
|>[email-masked]
|>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

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 10 Jan 2013 12:33:38 +0000

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

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Fri, 11 Jan 2013 08:34:54 +0000

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: [email-masked] [mailto:[email-masked]] 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);
[email-masked]; [email-masked]
|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 +34913128779
|M +34682005168
[email-masked]
|
|
|
|
|On 10/01/13 12:52, "Muthu Arul Mozhi Perumal (mperumal)"
|<[email-masked]> 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:[email-masked]]
|>|Sent: Thursday, January 10, 2013 3:21 PM
|>|To: Muthu Arul Mozhi Perumal (mperumal); JUAN ANTONIO CASTELL LUCIA; Dan
|>Wing (dwing);
|>[email-masked]; [email-masked]
|>|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 +34913128779
|>|M +34682005168
|>[email-masked]
|>|
|>|
|>|
|>|
|>|On 10/01/13 10:26, "Muthu Arul Mozhi Perumal (mperumal)"
|>|<[email-masked]> 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: [email-masked] [mailto:[email-masked]] On Behalf
|>|>Of JUAN ANTONIO CASTELL LUCIA
|>|>|Sent: Thursday, January 10, 2013 2:46 AM
|>|>|To: Dan Wing (dwing); [email-masked]; [email-masked]
|>|>|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: [email-masked] [mailto:[email-masked]] En nombre de
|>|>Dan Wing
|>|>|Enviado el: miércoles, 09 de enero de 2013 17:24
|>|>|Para: [email-masked]; [email-masked]
|>|>|Asunto: Re: [tcmtf] Questions regarding the TCMTF WG Chart proposal. 1
|>|>|
|>|>|> -----Original Message-----
|>|>|> From: Jose Saldana [mailto:[email-masked]]
|>|>|> Sent: Wednesday, January 09, 2013 8:08 AM
|>|>|> To: 'Dan Wing'; [email-masked]
|>|>|> 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:[email-masked]] Enviado el: miércoles, 09 de
|>|>|> > enero de 2013 16:38
|>|>|> > Para: [email-masked]; [email-masked]
|>|>|> > Asunto: RE: [tcmtf] Questions regarding the TCMTF WG Chart
|>proposal.
|>|>|> > 1
|>|>|> >
|>|>|> > > -----Original Message-----
|>|>|> > > From: [email-masked] [mailto:[email-masked]] On
|>|>|> > > Behalf Of Jose Saldana
|>|>|> > > Sent: Wednesday, January 09, 2013 1:48 AM
|>|>|> > > To: [email-masked]
|>|>|> > > 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
|>|>[email-masked]
|>|>|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
|>|>[email-masked]
|>|>|https://www.ietf.org/mailman/listinfo/tcmtf
|>|>_______________________________________________
|>|>tcmtf mailing list
|>|>[email-masked]
|>|>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
[email-masked]
|https://www.ietf.org/mailman/listinfo/tcmtf