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

["Jose Saldana" <[e-mail]>]

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]
CC: [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]
Cc: [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: 

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

Telefónica Global Resources

Network Automation and Dynamization

TECHNOLOGY PEOPLE GROUP

F [phone]

M [phone]

[e-mail]

 

From: "'Muthu Arul Mozhi Perumal (mperumal) '" <[e-mail]>
Date: lunes, 21 de enero de 2013 06:40
To: Fernando Pascual Blanco <[e-mail]>es>, "[e-mail]"
<[e-mail]>
Cc: "[e-mail]" <[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]] On Behalf Of
FERNANDO PASCUAL BLANCO
Sent: Wednesday, January 16, 2013 5:04 PM
To: [e-mail]; Muthu Arul Mozhi Perumal (mperumal)
Cc: [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]

 

From: "[e-mail]" <[e-mail]>
Organization: Universidad de Zaragoza
Reply-To: "[e-mail]" <[e-mail]>
Date: miércoles, 16 de enero de 2013 11:18
To: "'Muthu Arul Mozhi Perumal (mperumal) '" <[e-mail]>om>, Fernando
Pascual Blanco <[e-mail]>
Cc: "[e-mail]" <[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]] En nombre de Jose
Saldana
Enviado el: martes, 15 de enero de 2013 11:56
Para: [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