[tcmtf] TCMTF: Document A discussion: content and charter

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

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