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

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

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:[e-mail]]
Sent: Tuesday, January 22, 2013 2:24 PM
To: Muthu Arul Mozhi Perumal (mperumal); 'FERNANDO PASCUAL BLANCO'
Cc: [e-mail]
Subject: RE: [tcmtf] RV: TCMTF: Document A: mechanism for a muxer to discover a de-muxer

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

- 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:[e-mail]]
Enviado el: martes, 22 de enero de 2013 5:34
Para: FERNANDO PASCUAL BLANCO; [e-mail]<mailto:[e-mail]>
CC: [e-mail]<mailto:[e-mail]>
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.
|   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:[e-mail]]
Sent: Monday, January 21, 2013 2:32 PM
To: Muthu Arul Mozhi Perumal (mperumal); [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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.

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

  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
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F [phone]
M [phone]
[e-mail]<mailto:[e-mail]>

From: "'Muthu Arul Mozhi Perumal (mperumal) '" <[e-mail]<mailto:[e-mail]>>
Date: lunes, 21 de enero de 2013 06:40
To: Fernando Pascual Blanco <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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...),

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: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of FERNANDO PASCUAL BLANCO
Sent: Wednesday, January 16, 2013 5:04 PM
To: [e-mail]<mailto:[e-mail]>; Muthu Arul Mozhi Perumal (mperumal)
Cc: [e-mail]<mailto:[e-mail]>
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 [phone]
M [phone]
[e-mail]<mailto:[e-mail]>

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


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:[e-mail]<mailto:[e-mail]> [mailto:[e-mail]] En nombre de Jose Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [e-mail]<mailto:[e-mail]>
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


________________________________

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