Subject: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

From: "Jose Saldana" <[email-masked]>
Date: Wed, 16 Jan 2013 11:18:43 +0100

Fernando, Muthu, everyone,

Since there is no consensus about this, I think we should carry on with the
debate. Do you think the mechanism would be very complicated? Any new
ideas?:

- *dynamically establishing, modifying and releasing tunnels*

#1. A *mechanism for a muxer to discover a de-muxer (and vice versa)*.

There is still no consensus here:

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

Muthu: “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.” 

“#1 needs to be specified.”

Best regards,

Jose

De: [email-masked] [mailto:[email-masked]] En nombre de Jose
Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]
Asunto: [tcmtf] TCMTF: Document A discussion: content and charter

Document (A) refers to the main TCMTF draft, currently in
http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

1.- Content of the Document

Currently it contains the description of the question and the protocols
which could be used on each layer (tunneling, compressing, multiplexing). It
says that the signaling issues would be that of each protocol.

There is consensus (I think) about this: we should include some signaling
issues. The question is: What should we include in Draft A and what in Draft
C?

- *Auto-negotiation* 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.

This should be included in (A). I think there is consensus about this:

Juan Antonio: “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.”

Dan: “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.”

Fernando: “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.”

Does this mean that Document (A) will no longer be a Best Current Practice?
I think so.

- *dynamically establishing, modifying and releasing tunnels*

#1. A *mechanism for a muxer to discover a de-muxer (and vice versa)*.

There is still no consensus here:

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

Muthu: “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.” 

“#1 needs to be specified.”

#2. A mechanism to *elect an optimal muxer and a de-muxer when there are
more than one muxer/de-muxer for a flow*.

We agree: This can wait for Document (C).

                Fernando: “#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.”

                Muthu: “#2 can be added later.”

3. A mechanism to *setup/release a tunnel b/w a muxer and a de-muxer*.

We agree: This has to be included in (A).

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

                Muthu: “#3 many not require much specification.”

2.- Should we include it in the Charter now?

Of course, Document (A) should be in the charter.

Best regards,

Jose

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 16 Jan 2013 11:33:56 +0000

Hi Jose, Muthu,

I´m sure we will find a consensus about that :). What Muthu proposes sounds interesting to me but, to be honest, I think TCMTF establishing should be quite similar to the establishing procedures of tunnels defined in draft A (L2TP, GRE…), actually at network level TCMTF is a tunnel. Once established signaling will negotiate upper levels (multiplexing and HC) to perform TCMTF (draft A).

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]

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: miércoles, 16 de enero de 2013 11:18
To: "'Muthu Arul Mozhi Perumal (mperumal) '" <[email-masked]<mailto:[email-masked]>>, Fernando Pascual Blanco <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RV: [tcmtf] TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Since there is no consensus about this, I think we should carry on with the debate. Do you think the mechanism would be very complicated? Any new ideas?:

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

Muthu: “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.”

Best regards,

Jose

De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]<mailto:[email-masked]>
Asunto: [tcmtf] TCMTF: Document A discussion: content and charter

Document (A) refers to the main TCMTF draft, currently in http://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/

Currently it contains the description of the question and the protocols which could be used on each layer (tunneling, compressing, multiplexing). It says that the signaling issues would be that of each protocol.

There is consensus (I think) about this: we should include some signaling issues. The question is: What should we include in Draft A and what in Draft C?

- *Auto-negotiation* 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.

This should be included in (A). I think there is consensus about this:
Juan Antonio: “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.”

Dan: “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.”

Fernando: “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.”

Does this mean that Document (A) will no longer be a Best Current Practice? I think so.

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

Muthu: “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. A mechanism to *elect an optimal muxer and a de-muxer when there are more than one muxer/de-muxer for a flow*.

                Fernando: “#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.”

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

Best regards,

Jose

________________________________

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: Mon, 21 Jan 2013 05:40:44 +0000

Hi Fernando,

| I´m sure we will find a consensus about that :).

Sure..

|What Muthu proposes sounds interesting to me but, to be honest, I think TCMTF
|establishing should be quite similar to the establishing procedures of tunnels
|defined in draft A (L2TP, GRE...),

I agree the procedures for establishing the association b/w the muxer and the de-muxer could be similar to those of establishing a tunnel. However, I would like us to avoid two assumptions:
1. The other end of a tunnel is always TCMTF capable. I think this is more important when you already have a tunnel (say, IPSec tunnel) and would like to perform TCMTF on the fly.
2. A tunnel is always needed for performing TCMTF. If we aren't doing any compression, but only multiplexing, the outermost IP header would be intact and should suffice for routing the packets. There are satellite networks where reducing the packets per second (pps) for VoIP calls is more important -- they don't do any compression, but only multiplexing, and don't setup a tunnel as well. For e.g:
http://www.cisco.com/web/strategy/docs/gov/aag_c45-697642_v2.pdf
http://www.cisco.com/web/strategy/docs/gov/ip_multiplexing_agensler.pptx

Nevertheless, I think all this go into the signaling doc. If we require capability negotiation, I think we can combine it with the procedure for establishing the association b/w the muxer and the de-muxer. If we make capability negotiation as optional, we might want to keep those as separate procedures.

Muthu

From: [email-masked] [mailto:[email-masked]] On Behalf Of FERNANDO PASCUAL BLANCO
Sent: Wednesday, January 16, 2013 5:04 PM
To: [email-masked]; Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]
Subject: Re: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Hi Jose, Muthu,

I´m sure we will find a consensus about that :). What Muthu proposes sounds interesting to me but, to be honest, I think TCMTF establishing should be quite similar to the establishing procedures of tunnels defined in draft A (L2TP, GRE...), actually at network level TCMTF is a tunnel. Once established signaling will negotiate upper levels (multiplexing and HC) to perform TCMTF (draft A).

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]<mailto:[email-masked]>

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

Muthu: "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."

"#1 needs to be specified."

Best regards,

Jose

This should be included in (A). I think there is consensus about this:
Juan Antonio: "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."

Dan: "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."

Fernando: "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."

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

Muthu: "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."

"#1 needs to be specified."

                Fernando: "#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."

                Muthu: "#2 can be added later."

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

                Muthu: "#3 many not require much specification."

Best regards,

Jose

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Mon, 21 Jan 2013 09:01:30 +0000

Hi Muthu,

I agree that a tunnel is not always needed. But when you say signaling doc, are you referring finally to the draft A? We agreed on addressing capabilities negotiation on that draft.

Nevertheless, I think we should clarify two thinks:

  1.  The way a mux is instructed with the IP address (for example) of a demux. That procedure could be:
     *   Static (i.e. Configuration within the mux)
     *   Dynamic (i.e. Instructed from a higher entity like a policy manager) and could be (or not) described in draft C
  2.  The capabilities negotiation: once a mux knows the IP address of a demux can negotiate the capabilities of the different layers (tunnel, multiplex and compression). This is also described at the draft A.

Regards,

Fernando Pascual Blanco

From: "'Muthu Arul Mozhi Perumal (mperumal) '" <[email-masked]<mailto:[email-masked]>>
Date: lunes, 21 de enero de 2013 06:40
To: Fernando Pascual Blanco <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Hi Fernando,

|I´m sure we will find a consensus about that :).

Sure..

|What Muthu proposes sounds interesting to me but, to be honest, I think TCMTF
|establishing should be quite similar to the establishing procedures of tunnels
|defined in draft A (L2TP, GRE…),

Muthu

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of FERNANDO PASCUAL BLANCO
Sent: Wednesday, January 16, 2013 5:04 PM
To: [email-masked]<mailto:[email-masked]>; Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Hi Jose, Muthu,

What do you think?

Regards,

Fernando Pascual Blanco

Best regards,

Jose

De:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]<mailto:[email-masked]>
Asunto: [tcmtf] TCMTF: Document A discussion: content and charter

Best regards,

Jose

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 22 Jan 2013 04:34:14 +0000

Hi Fernando,

Yes, I was referring to draft A. However, I am now thinking it might be better if we devote draft A for the use cases and the protocol stack architecture, and write a new draft A-sig describing the negotiation procedures including automatic discovery/association and capability exchange. That way we can progress them independently in parallel and potentially explore multiple negotiation procedures (in the form of multiple drafts, if there is sufficient interest). In essence, I think we should separate out the use cases and architecture from the solutions.

|1. The way a mux is instructed with the IP address (for example) of a demux.
|   That procedure could be:
|   1. Static (i.e. Configuration within the mux)
|   2. Dynamic (i.e. Instructed from a higher entity like a policy manager)
|      and could be (or not) described in draft C

On dynamic, I would also like to add mux discovering the demux through negotiation -- this would be case when the mux sees a number of flows going to the same destination but doesn't know if the destination is capable of demuxing.

Muthu

From: FERNANDO PASCUAL BLANCO [mailto:[email-masked]]
Sent: Monday, January 21, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
Cc: [email-masked]
Subject: Re: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Hi Muthu,

  1.  The capabilities negotiation: once a mux knows the IP address of a demux can negotiate the capabilities of the different layers (tunnel, multiplex and compression). This is also described at the draft A.
Regards,

Fernando Pascual Blanco

Hi Fernando,

Sure..

Muthu

Hi Jose, Muthu,

What do you think?

Regards,

Fernando Pascual Blanco

Best regards,

Jose

Best regards,

Jose

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 22 Jan 2013 09:53:33 +0100

Muthu,

The approach we were thinking about was:

- A first Document (A), the current draft, including the architecture and
the basic signaling issues in order to avoid a too static protocol. I think
there was (rough) consensus about this.

- A second Document (C) (= A-sig), adding new signaling functionalities to
the basic ones.

Document (A) would be included in the Charter, and Document (C) would wait
until (A) is ready or almost ready.

This is a bit different from the approach you are proposing, but it may also
work. I think this approach is perhaps more “practical”: if we propose an
architecture and leave signaling for the future, nobody will believe this
can work. If we begin with the architecture+basic signaling, we will have
something that works from the beginning.

What do you think?

Thanks,

Jose

De: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]] 
Enviado el: martes, 22 de enero de 2013 5:34
Para: FERNANDO PASCUAL BLANCO; [email-masked]
CC: [email-masked]
Asunto: RE: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover
a de-muxer

Hi Fernando,

Yes, I was referring to draft A. However, I am now thinking it might be
better if we devote draft A for the use cases and the protocol stack
architecture, and write a new draft A-sig describing the negotiation
procedures including automatic discovery/association and capability
exchange. That way we can progress them independently in parallel and
potentially explore multiple negotiation procedures (in the form of multiple
drafts, if there is sufficient interest). In essence, I think we should
separate out the use cases and architecture from the solutions.

|1. The way a mux is instructed with the IP address (for example) of a
demux. 

On dynamic, I would also like to add mux discovering the demux through
negotiation -- this would be case when the mux sees a number of flows going
to the same destination but doesn't know if the destination is capable of
demuxing.

Muthu

From: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] 
Sent: Monday, January 21, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal); [email-masked]
Cc: [email-masked]
Subject: Re: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to
discover a de-muxer

Hi Muthu,

I agree that a tunnel is not always needed. But when you say signaling doc,
are you referring finally to the draft A? We agreed on addressing
capabilities negotiation on that draft. 

1.	The way a mux is instructed with the IP address (for example) of a
demux. That procedure could be: 

1.	Static (i.e. Configuration within the mux)
2.	Dynamic (i.e. Instructed from a higher entity like a policy manager)
and could be (or not) described in draft C

2.	The capabilities negotiation: once a mux knows the IP address of a
demux can negotiate the capabilities of the different layers (tunnel,
multiplex and compression). This is also described at the draft A.

Regards,

Fernando Pascual Blanco

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

[email-masked]

From: "'Muthu Arul Mozhi Perumal (mperumal) '" <[email-masked]>
Date: lunes, 21 de enero de 2013 06:40
To: Fernando Pascual Blanco <[email-masked]>, "[email-masked]"
<[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to
discover a de-muxer

Hi Fernando,

Sure..

|What Muthu proposes sounds interesting to me but, to be honest, I think
TCMTF 

|establishing should be quite similar to the establishing procedures of
tunnels 

I agree the procedures for establishing the association b/w the muxer and
the de-muxer could be similar to those of establishing a tunnel. However, I
would like us to avoid two assumptions:

1. The other end of a tunnel is always TCMTF capable. I think this is more
important when you already have a tunnel (say, IPSec tunnel) and would like
to perform TCMTF on the fly.

2. A tunnel is always needed for performing TCMTF. If we aren't doing any
compression, but only multiplexing, the outermost IP header would be intact
and should suffice for routing the packets. There are satellite networks
where reducing the packets per second (pps) for VoIP calls is more important
-- they don't do any compression, but only multiplexing, and don't setup a
tunnel as well. For e.g:

Nevertheless, I think all this go into the signaling doc. If we require
capability negotiation, I think we can combine it with the procedure for
establishing the association b/w the muxer and the de-muxer. If we make
capability negotiation as optional, we might want to keep those as separate
procedures.

Muthu

From: [email-masked] [mailto:[email-masked]] On Behalf Of
FERNANDO PASCUAL BLANCO
Sent: Wednesday, January 16, 2013 5:04 PM
To: [email-masked]; Muthu Arul Mozhi Perumal (mperumal)
Cc: [email-masked]
Subject: Re: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to
discover a de-muxer

Hi Jose, Muthu,

I´m sure we will find a consensus about that :). What Muthu proposes sounds
interesting to me but, to be honest, I think TCMTF establishing should be
quite similar to the establishing procedures of tunnels defined in draft A
(L2TP, GRE…), actually at network level TCMTF is a tunnel. Once established
signaling will negotiate upper levels (multiplexing and HC) to perform TCMTF
(draft A).

What do you think?

Regards,

Fernando Pascual Blanco

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

[email-masked]

From: "[email-masked]" <[email-masked]>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]" <[email-masked]>
Date: miércoles, 16 de enero de 2013 11:18
To: "'Muthu Arul Mozhi Perumal (mperumal) '" <[email-masked]>, Fernando
Pascual Blanco <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RV: [tcmtf] TCMTF: Document A: mechanism for a muxer to discover a
de-muxer

 

Best regards,

Jose

De:[email-masked] [mailto:[email-masked]] En nombre de Jose
Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [email-masked]
Asunto: [tcmtf] TCMTF: Document A discussion: content and charter

 

 

 

 

 

Best regards,

Jose

  _____  

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

---

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Tue, 22 Jan 2013 09:37:32 +0000

Hi Jose,

|This is a bit different from the approach you are proposing, but
|it may also work.

It would..

|I think this approach is perhaps more "practical":
|if we propose an architecture and leave signaling for the future,
|nobody will believe this can work. If we begin with the architecture+basic
|signaling, we will have something that works from the beginning.

I wasn't suggesting we leave signaling for the future and I agree we should begin with the architecture + basic signaling. I was only suggesting we devote another I-D for signaling (i.e A-sig would include basic signaling). That way we can progress them independently..for e.g we can WGLC the architecture as soon as it is ready, without having to wait for signaling.

I am a fan of smaller I-Ds than a larger one :)

Muthu

From: Jose Saldana [mailto:[email-masked]]
Sent: Tuesday, January 22, 2013 2:24 PM
To: Muthu Arul Mozhi Perumal (mperumal); 'FERNANDO PASCUAL BLANCO'
Cc: [email-masked]
Subject: RE: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Muthu,

- A first Document (A), the current draft, including the architecture and the basic signaling issues in order to avoid a too static protocol. I think there was (rough) consensus about this.
Juan Antonio: "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."

- A second Document (C) (= A-sig), adding new signaling functionalities to the basic ones.

Document (A) would be included in the Charter, and Document (C) would wait until (A) is ready or almost ready.

This is a bit different from the approach you are proposing, but it may also work. I think this approach is perhaps more "practical": if we propose an architecture and leave signaling for the future, nobody will believe this can work. If we begin with the architecture+basic signaling, we will have something that works from the beginning.

What do you think?

Thanks,

Jose

De: Muthu Arul Mozhi Perumal (mperumal) [mailto:[email-masked]]
Enviado el: martes, 22 de enero de 2013 5:34
Para: FERNANDO PASCUAL BLANCO; [email-masked]<mailto:[email-masked]>
CC: [email-masked]<mailto:[email-masked]>
Asunto: RE: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

Hi Fernando,

Muthu

To: Muthu Arul Mozhi Perumal (mperumal); [email-masked]<mailto:[email-masked]>

Hi Muthu,

Fernando Pascual Blanco

Hi Fernando,

Sure..

Muthu

Hi Jose, Muthu,

What do you think?

Regards,

Fernando Pascual Blanco

Best regards,

Jose

Best regards,

Jose