Subject: Re: [tcmtf] TCMTF: two kinds of services

From: "Jose Saldana" <[email-masked]>
Date: Mon, 8 Oct 2012 16:09:41 +0200

Fernando,

So you suggest we should distinguish between two different things (if I
understand well):

1.- dynamically negotiating TCMTF options and/or parameters between
multiplexer and demultiplexer. Some examples:

1.1. Negotiating the options (the different protocol stack options): We have
two mux/demux which want to establish a tunnel. If the first one says “I
have implementations of ROHC and ECRTP, PPPMux, GRE” and the other one says
“I implement ROHC, PPPMux, L2TP and GRE”. The only option to use is
ROHC-PPPMux-GRE.

1.2. Negotiating the parameters, if you have an RTT of 60ms, and you are
multiplexing VoIP, you can still add 40ms of multiplexing delay, since 100ms
is not a problem for VoIP. But if you notice that in a certain moment the
RTT grows, you may have to reduce the multiplexing delay. It must be taken
into account that the higher the multiplexing delay, the higher the number
of packets you can merge, and the higher the bandwidth saving.

2.- dynamically applying TCMTF: that would be a higher entity in charge of
deciding when and where, applying or not TCMTF, and what kind of TCMTF, and
what multiplexing period (which manly means added delay).

So I have four questions:

Q1) Can TCMTF protocol stack be defined before defining 1.1.? I mean, we
standardize the stack and in a case you use ROHC-PPPMux-L2TP; in another
case you use ECRTP-PPPMux-GRE, etc. But two TCMTF entities would always talk
the same way.

Q2) Is 1.1. “the third draft” proposal?

Q3) Is 1.2. a draft proposal? I don’t think so. If the multiplexer modifies
the multiplexing period, the demux does not need to know it. It simply
demultiplexes the packets as they arrive. So no signaling is required: the
multiplexer estimates the RTT and modifies the multiplexing period.

Q4) Is 2. a draft proposal? I don’t clearly see it… let’s keep on thinking.

Your “network operator opinion” is interesting here (and also others’
opinions, of course).

Thanks in advance,

Jose

De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] 
Enviado el: viernes, 28 de septiembre de 2012 13:20
Para: [email-masked]; [email-masked]
Asunto: Re: [tcmtf] TCMTF: two kinds of services

Hi Jose,

You are talking about dynamically apply TCMTF, and yes, this is a very
interesting aspect. This is different from the third draft you proposed in
order to dynamically negotiate TCMTF parameters between multiplexer and
demultiplexer, that would be a higher entity in charge of decide when and
where or not to apply TCMTF, and what kind of TCMTF. As operator, we have a
lot of knowledge in those kind of policies. I have several colleagues that
can talk about that issue.

Regards,

Fernando Pascual Blanco

Telefónica Global Resources

Network Automation and Dynamization

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: viernes 28 de septiembre de 2012 11:17
To: "[email-masked]" <[email-masked]>
Subject: [tcmtf] TCMTF: two kinds of services

This is another thought to be discussed. We can have two different
situations for multiplexing flows:

- delay-sensitive services (e.g., VoIP, online games). In this case, TCMTF
would add some delay, so it should only be used when bandwidth is scarce
(rush hours, new game release, etc.). If your network is working properly,
why do you need to save bandwidth and add a small delay to the clients? So
in rush hours there must be a counterpart in order to add some priority to
the tunneled packets. Otherwise you would penalize them: since they are
small and can be multiplexed, they are delayed.

- services sending small packets but not delay-sensitive (e.g., whatsapp,
m2m packets being generated every second). In this case TCMTF saves
bandwidth while adding some delay, but it is not critical.

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>
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 09 Oct 2012 07:40:42 +0000

Hi Jose,

Yes, I see distinction between  1 and 2, and I though in something more similar to 1.1 than to 1.2. Your questions:

Q1) Can TCMTF protocol stack be defined before defining 1.1.? I mean, we standardize the stack and in a case you use ROHC-PPPMux-L2TP; in another case you use ECRTP-PPPMux-GRE, etc. But two TCMTF entities would always talk the same way.

Yes, of course. You can define a protocol negotiation before define the possibilities.

Yes, I think that fits with the concept of "Dynamic Signaling draft".

Q3) Is 1.2. a draft proposal? I don’t think so. If the multiplexer modifies the multiplexing period, the demux does not need to know it. It simply demultiplexes the packets as they arrive. So no signaling is required: the multiplexer estimates the RTT and modifies the multiplexing period.

I fully agree: added delay is something that demultiplexer does not need to know.

I do not know, but I think it is something that should appear somewhere. Dynamic decisions over network is something that operators like to do: a central policy manager deciding where and when to apply network optimizations (TCMTF) would be very valuable. That functionality could also be added to existing elements in network operator core networks that are currently making similar things.

Regards,

Fernando Pascual Blanco

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: lunes 8 de octubre de 2012 16:09
To: Fernando Pascual Blanco <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [tcmtf] TCMTF: two kinds of services

Fernando,

So you suggest we should distinguish between two different things (if I understand well):

1.- dynamically negotiating TCMTF options and/or parameters between multiplexer and demultiplexer. Some examples:

1.1.Negotiating the options (the different protocol stack options): We have two mux/demux which want to establish a tunnel. If the first one says “I have implementations of ROHC and ECRTP, PPPMux, GRE” and the other one says “I implement ROHC, PPPMux, L2TP and GRE”. The only option to use is ROHC-PPPMux-GRE.

1.2.Negotiating the parameters, if you have an RTT of 60ms, and you are multiplexing VoIP, you can still add 40ms of multiplexing delay, since 100ms is not a problem for VoIP. But if you notice that in a certain moment the RTT grows, you may have to reduce the multiplexing delay. It must be taken into account that the higher the multiplexing delay, the higher the number of packets you can merge, and the higher the bandwidth saving.

2.- dynamically applying TCMTF: that would be a higher entity in charge of deciding when and where, applying or not TCMTF, and what kind of TCMTF, and what multiplexing period (which manly means added delay).

Q1) Can TCMTF protocol stack be defined before defining 1.1.? I mean, we standardize the stack and in a case you use ROHC-PPPMux-L2TP; in another case you use ECRTP-PPPMux-GRE, etc. But two TCMTF entities would always talk the same way.

Q3) Is 1.2. a draft proposal? I don’t think so. If the multiplexer modifies the multiplexing period, the demux does not need to know it. It simply demultiplexes the packets as they arrive. So no signaling is required: the multiplexer estimates the RTT and modifies the multiplexing period.

Your “network operator opinion” is interesting here (and also others’ opinions, of course).

Thanks in advance,

Jose

De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]]
Enviado el: viernes, 28 de septiembre de 2012 13:20
Para: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [tcmtf] TCMTF: two kinds of services

Hi Jose,

You are talking about dynamically apply TCMTF, and yes, this is a very interesting aspect. This is different from the third draft you proposed in order to dynamically negotiate TCMTF parameters between multiplexer and demultiplexer, that would be a higher entity in charge of decide when and where or not to apply TCMTF, and what kind of TCMTF. As operator, we have a lot of knowledge in those kind of policies. I have several colleagues that can talk about that issue.

Regards,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]<mailto:[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: viernes 28 de septiembre de 2012 11:17
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [tcmtf] TCMTF: two kinds of services

This is another thought to be discussed. We can have two different situations for multiplexing flows:

- delay-sensitive services (e.g., VoIP, online games). In this case, TCMTF would add some delay, so it should only be used when bandwidth is scarce (rush hours, new game release, etc.). If your network is working properly, why do you need to save bandwidth and add a small delay to the clients? So in rush hours there must be a counterpart in order to add some priority to the tunneled packets. Otherwise you would penalize them: since they are small and can be multiplexed, they are delayed.

- services sending small packets but not delay-sensitive (e.g., whatsapp, m2m packets being generated every second). In this case TCMTF saves bandwidth while adding some delay, but it is not critical.

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: Mirja Kuehlewind <[email-masked]>
Date: Tue, 9 Oct 2012 14:24:17 +0200

Hi Jose,

> multiplexer estimates the RTT and modifies the multiplexing period.
How does the multiplexer know the RTT?

Mirja

-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973
email: [email-masked]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 9 Oct 2012 16:40:01 +0200

Well, it was part of the example. However, your question is interesting,
since we are talking about delay-sensitive services: if you build a tunnel
to save bandwidth and, at the same time, you add an unacceptable delay, it
makes no sense.

I don't know if you want to suggest the possibility of developing a method
for estimating RTT. But do you think it is necessary to develop it? I am
sure something already exists. In fact, online games use "ping" as delay
estimation. Do you know if a standard method for estimating RTT exists?

Thanks, and let us keep on thinking,

Jose

> -----Mensaje original-----
> De: Mirja Kuehlewind [mailto:[email-masked]]
> Enviado el: martes, 09 de octubre de 2012 14:24
> Para: [email-masked]; [email-masked]
> CC: 'FERNANDO PASCUAL BLANCO'
> > Q3) Is 1.2. a draft proposal? I don’t think so. If the multiplexer
> > modifies the multiplexing period, the demux does not need to know it.
> > It simply demultiplexes the packets as they arrive. So no signaling is
> > required: the multiplexer estimates the RTT and modifies the
> multiplexing period.
> >
> > De: FERNANDO PASCUAL BLANCO [mailto:[email-masked]] Enviado el: viernes,
> > 28 de septiembre de 2012 13:20
> > interesting aspect. This is different from the third draft you
> > proposed in order to dynamically negotiate TCMTF parameters between
> > multiplexer and demultiplexer, that would be a higher entity in charge
> > of decide when and where or not to apply TCMTF, and what kind of
> > TCMTF. As operator, we have a lot of knowledge in those kind of
> > policies. I have several colleagues that can talk about that issue.
> >
> >
> >
> > Regards,
> >
> >
> >
> > Fernando Pascual Blanco
> >
> > - delay-sensitive services (e.g., VoIP, online games). In this case,
> > TCMTF would add some delay, so it should only be used when bandwidth
> > is scarce (rush hours, new game release, etc.). If your network is
> > working properly, why do you need to save bandwidth and add a small
> > delay to the clients? So in rush hours there must be a counterpart in
> > order to add some priority to the tunneled packets. Otherwise you
> > would penalize them: since they are small and can be multiplexed, they
> are delayed.
> >
> >
> >
> > - services sending small packets but not delay-sensitive (e.g.,
> > whatsapp, m2m packets being generated every second). In this case
> > TCMTF saves bandwidth while adding some delay, but it is not critical.
> >
> >
> >
> >
> >
> > 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:
> University of Stuttgart, Germany Pfaffenwaldring 47, D-70569 Stuttgart
> 
> tel: +49(0)711/685-67973

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 9 Oct 2012 18:02:04 +0200

Hi Jose,

usually a box somewhere in the network does not know the e2e delay of a single 
transmission. The endsystem might. Moreover, RTT might change during a 
transmission. Thus making a decision based on RTT somewhere in the network 
isn't that easy. 

I guess, at least some kind of additional signaling is required which requires 
further cooperation between the parties or introduces further contrains e.g. 
limitation to TCP flows that uses the timestamp option and thus already 
provide RTT info, but the TCP syntax needs to be interpreted.

I'm following your discussion but I have the feeling that the whole thing is 
getting more and more complex as this issue about RTT. I guess for a first 
meeting it would make more sense to focus on the more simpler cases first. 
Are you currently writting a charter text?

Mirja

On Tuesday 09 October 2012 16:40:01 Jose Saldana wrote:
> > > Q4) Is 2. a draft proposal? I don’t clearly see it… let’s keep on
>
> thinking.
>
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

tel: +49(0)711/685-67973

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 9 Oct 2012 18:27:57 +0200

Mirja,

Yes, in fact my plan is sending the charter (first version) tomorrow, after
polishing it a bit.

There are two options:

a) Only considering the main draft (protocol stack) and the "informational"
draft with recommendations of maximum delays for each service. A final
comment saying "if further needs were identified, the WG would be
rechartered".

b) Considering from the beginning the other options we have talked about.
The question is that some of them are not clear by now.

I think the opinions of the Area Directors will be very important here: if
they want to start the WG soon, I think option a) would be better (according
to my short experience).

But first, we should hear the opinion of everyone in the list. Thanks,

Jose

> Enviado el: martes, 09 de octubre de 2012 18:02
> usually a box somewhere in the network does not know the e2e delay of a
> single transmission. The endsystem might. Moreover, RTT might change
> during a transmission. Thus making a decision based on RTT somewhere in
> the network isn't that easy.
> 
> > Well, it was part of the example. However, your question is
> > interesting, since we are talking about delay-sensitive services: if
> > you build a tunnel to save bandwidth and, at the same time, you add an
> > unacceptable delay, it makes no sense.
> >
> > I don't know if you want to suggest the possibility of developing a
> > method for estimating RTT. But do you think it is necessary to develop
> > it? I am sure something already exists. In fact, online games use
> > "ping" as delay estimation. Do you know if a standard method for
> estimating RTT exists?
> >
> > > > You are talking about dynamically apply TCMTF, and yes, this is a
> > > > very interesting aspect. This is different from the third draft
> > > > you proposed in order to dynamically negotiate TCMTF parameters
> > > > between multiplexer and demultiplexer, that would be a higher
> > > > entity in charge of decide when and where or not to apply TCMTF,
> > > > and what kind of TCMTF. As operator, we have a lot of knowledge in
> > > > those kind of policies. I have several colleagues that can talk
about that
> issue.
> > > > - delay-sensitive services (e.g., VoIP, online games). In this
> > > > case, TCMTF would add some delay, so it should only be used when
> > > > bandwidth is scarce (rush hours, new game release, etc.). If your
> > > > network is working properly, why do you need to save bandwidth and
> > > > add a small delay to the clients? So in rush hours there must be a
> > > > counterpart in order to add some priority to the tunneled packets.
> > > > Otherwise you would penalize them: since they are small and can be
> > > > multiplexed, they
> > >
> > > are delayed.
> > >
> > > > 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:

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 10 Oct 2012 09:58:25 +0200

Dear all,

As Gonzalo and Mirja suggested, I have written a first draft of the Charter
for a (possible) Working Group about TCMTF. In order to make discussion
easier, I have put a number at the beginning of each paragraph, and I have
denoted the three proposed documents as (A), (B) and (C).

There are two options, in my opinion:

a) Only considering the main draft (A) and the "informational" one (B). If
further documents are necessary, the group could be rechartered. In this
case, paragraph 6 would be a part of paragraph 7. This is the option Mirja
suggested, in order to simplify things (I guess).

Wes and Martin: I think your opinions as Area Directors are crucial at this
stage: if you want to start the WG soon, I think option a) would be better.

Of course, I hope more people will participate in the improvement of the
Charter. Your feedback will be greatly appreciated.

Well, here it goes. Best regards,

Jose

------------------

Description of Working Group (version 0)

1. In the last years we are witnessing the raise of new real-time services
that use the Internet for the delivery of interactive multimedia
applications: VoIP, videoconferencing, telemedicine, video vigilance, online
gaming, etc. Due to the need of interactivity, many of these services use
small packets (some tens of bytes), since they have to send frequent updates
to the other extreme of the communication. Therefore, its overhead is
significant, and it becomes even worse when IPv6 is used, as the basic IPv6
header is twice the size of the IPv4 one. In addition, some other services
also send small packets, but they are not delay-sensitive (e.g., instant
messaging, m2m packets being generated every second).

2. In order to mitigate this bad network efficiency, when a number of flows
shares a path, packets can be grouped, considering three different layers:

- Header compression: Taking into account that real-time applications use
different headers (RTP/UDP, UDP or even TCP), different protocols can be
used: no compression, ECRTP, IPHC and ROHC.

- Multiplexing a number of payloads into a single packet. If a number of
flows share a path between an origin and a destination, a multiplexer can
build a bigger packet in which a number of payloads share a common header. A
demultiplexer is necessary at the end of the common path, so as to rebuild
the packets as they were originally sent. PPPMux will be the main option.
Other ones are not discarded.

- Tunneling will be used to send the multiplexed packets end-to-end. The
options in this layer are L2TP, GRE and MPLS.

3. So the first objective of this group is to develop a document (A) that
will specify the protocol stack for compressing, multiplexing and tunneling
traffic flows. Since only standard protocols are being used, each layer will
use its own signaling methods. Thus, the intended status of this document is
"best current practice". In addition, since it "includes" the current RFC
4170, as one of the options, this RFC would be obsoleted.

4. The objective of this first document (A) is to define the different
options which can be used at each layer, not the definition of new protocols
for any of the layers. Only specific problems caused by the interaction
between layers will have to be issued, and suitable extensions may have to
be added to the involved protocols.

5. In addition, TCMTF may save bandwidth but, as a counterpart, some delay
and jitter will be added. This is not a problem for the services which are
not sensitive to delay. However, regarding delay-sensitive services, the
Working Group will also develop a document (B) with recommendations about
the maximum delay and jitter to be added to each kind of service or
application. Empirical research studies with real users will be necessary in
order to establish this set of recommendations.

6. Finally, a document (C) for defining a mechanism for negotiating TCMTF
options between multiplexer and demultiplexer should be developed. If two
mux/demux want to establish a tunnel, they have first to negotiate which
concrete option would they use in each layer: header compression,
multiplexing and tunneling. This will depend on the implementations they
include, and in the scenario.

7. If other interesting features are identified, the group would recharter
and include them (e.g. dynamically applying TCMTF: that would be a higher
entity in charge of deciding when and where, applying or not TCMTF, and what
kind of TCMTF, and what multiplexing period, which manly means added delay.
Additional methods for estimating RTT would also be required).

8. Interactions with other groups can be expected, since TCMTF uses already
defined protocols (ROHC, PPPMux, MPLS, GRE, L2TP).

9. Goals and Milestones
Specification of TCMTF protocol stack (A)
Recommendations of maximum delay depending on the service (B)
Mechanism for negotiating TCMTF options between multiplexer and
demultiplexor (C)

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 10 Oct 2012 10:23:27 +0200

Hi All,

> options in this layer are L2TP, GRE and MPLS.

I was wondering if the group might be interested in exploring also other form of tunnelling, e.g., LISP.

Obviously, since LISP is an experimental effort, it cannot be tagged as "best current practice" and included in document (A).

However, the group may have a slightly "larger" scope and include alternative forms of tunnelling (and/or multiplexing and/or header compression) (may be documented separately).

Thoughts?

ciao

Luigi

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 10 Oct 2012 13:48:09 +0200

Luigi,

Where would you include LISP here? With GRE/L2TP, or with MPLS?

We are also thinking about including other tunneling schemes, as VLAN, etc.

(to be seen in Courier letters)

    TCP/IP   UDP/IP  RTP/UDP/IP
         \     |     /
          \    |    /                     ------------------------------
           \   |   /
Nothing or ROHC or ECRTP or IPHC             header compressing layer
               |
               |                          ------------------------------
               |
   PPPMUX or other mux protocols                multiplexing layer
               |
              / \                         ------------------------------
             /   \
            /     \
   GRE or L2TP     \                              tunneling layer
          |        MPLS
          |                               ------------------------------
          IP

Thanks,

Jose

> De: [email-masked] [mailto:[email-masked]] En nombre de
> Luigi Iannone
> Enviado el: miércoles, 10 de octubre de 2012 10:23
> Para: [email-masked]
> CC: [email-masked]
> > - Tunneling will be used to send the multiplexed packets end-to-end.
> > The options in this layer are L2TP, GRE and MPLS.
> >
> 
> I was wondering if the group might be interested in exploring also other
form
> of tunnelling, e.g., LISP.
> 
> Obviously, since LISP is an experimental effort, it cannot be tagged as
"best
> current practice" and included in document (A).
> 
> However, the group may have a slightly "larger" scope and include
> alternative forms of tunnelling (and/or multiplexing and/or header
> compression) (may be documented separately).
> 
> Thoughts?
> 
> ciao
> 
> Luigi
> 
> 
>

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Wed, 10 Oct 2012 14:02:32 +0200

Perhaps VLAN can not be considered as a tunnelscheme. In fact we are 
thinking about replacing MPLS for Layer 2 transport and then specify 
MPLS tunnels or VLAN technologies and so on.

Julián

---

From: Luigi Iannone <[email-masked]>
Date: Thu, 11 Oct 2012 09:11:18 +0200

Hi Jose,

I would put LISP in two different layers.

You can consider LISP as composed of two main parts: 

1. the encap/decap operations (i.e., the tunnelling) 

2. the mapping system (basically controlling which traffic is tunnelled).

The first can be used  at the tunnelling layer, beside GRE/MPLS/L2TP (having multiple options is always a good thing ;-) ), to perform the tunnelling. Some parts of the LISP header might be exploited to carry TE information (e.g., the Instance ID can be used as QoS tag).

The second can be used at Mux/Demux layer. The LISP mapping system might be extended to perform tcmtf negotiation by  leveraging on a particular form of mappings. The advantage is that there is already quite a bit of signalling machinery out there that can be easily re-used/extended.

Ciao

Luigi

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 17 Oct 2012 14:46:50 +0000

Hi Luigi,

        I understand the use of LISP as a tunnel, and I´m not an expert (as you are) in LISP. Could you please explain us how do you think LISP mapping system could help to perform TCMTF negotiation?

        We have two things here: the first one is the negotiation between multiplexer and demultiplexer on what capabilities are supported in every end. The second one would be to identify what flows should be tunneled, multiplexed and or compressed and under what terms.

        Thank you for your interest!

B.R.

Fernando

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luigi Iannone
Sent: jueves, 11 de octubre de 2012 9:11
To: [email-masked]
Cc: [email-masked]
Subject: Re: [tcmtf] TCMTF: two kinds of services

Hi Jose,

Ciao

Luigi

On 10 Oct. 2012, at 13:48 , Jose Saldana <[email-masked]> wrote:

>> De: [email-masked] [mailto:[email-masked]] En nombre
>> de Luigi Iannone Enviado el: miércoles, 10 de octubre de 2012 10:23
>> Para: [email-masked]
>> CC: [email-masked]

---

From: "Jose Saldana" <[email-masked]>
Date: Fri, 19 Oct 2012 18:04:28 +0200

Luigi,

What about this protocol stack for LISP within TCMTF?

    TCP/IP   UDP/IP  RTP/UDP/IP

         \     |     /

           \   |   /

               |

               |

           /   |     \

          /    |      \                   ------------------------------

         /    LISP     \

        /      |        \

GRE or L2TP   UDP        \                        tunneling layer

       |       |        MPLS

       |       |                           ------------------------------

       IP      IP

I don’t know if LISP could be included into TCMTF draft. What do you think?
Should it be defined inside the LISP WG?

We have to talk about that LISP signaling which could be used in TCMTF, as
you say.

Thanks,

Jose

> Enviado el: jueves, 11 de octubre de 2012 9:11

> The first can be used  at the tunnelling layer, beside GRE/MPLS/L2TP
(having

> multiple options is always a good thing ;-) ), to perform the tunnelling.
Some

> parts of the LISP header might be exploited to carry TE information (e.g.,
the

> Instance ID can be used as QoS tag).

> The second can be used at Mux/Demux layer. The LISP mapping system

> might be extended to perform tcmtf negotiation by  leveraging on a

> particular form of mappings. The advantage is that there is already quite
a bit

> of signalling machinery out there that can be easily re-used/extended.

> On 10 Oct. 2012, at 13:48 , Jose Saldana < <mailto:[email-masked]>
[email-masked]> wrote:

> > We are also thinking about including other tunneling schemes, as VLAN,

> etc.

> >> De:  <mailto:[email-masked]> [email-masked] [
<mailto:[email-masked]> mailto:[email-masked]] En nombre

> >> Para:  <mailto:[email-masked]> [email-masked]

> >> CC:  <mailto:[email-masked]> [email-masked]

> >> On 10 Oct. 2012, at 09:58 , Jose Saldana < <mailto:[email-masked]>
[email-masked]> wrote:

> >> I was wondering if the group might be interested in exploring also

> >> other

> >> Obviously, since LISP is an experimental effort, it cannot be tagged

> >> as

> >>  <mailto:[email-masked]> [email-masked]

> >>  <https://www.ietf.org/mailman/listinfo/tcmtf>

>  <mailto:[email-masked]> [email-masked]

>  <https://www.ietf.org/mailman/listinfo/tcmtf>

---

From: Luigi Iannone <[email-masked]>
Date: Sun, 21 Oct 2012 16:13:41 +0200

Hi Jose,

comments inline.

> (to be seen in Courier letters)

The graph looks good to me.

Concerning whether or not to include it in the draft, may be it is not necessary to include details about LISP just mention that can be used. The usage of LISP, because of its experimental nature compare to other tunnelling options, can be documented in a different document, which, if people are interested, I can (with your help) write.

> Should it be defined inside the LISP WG?

I`ll let the LISP WG chairs answer on this point.
Nevertheless, IMHO,  the LISP WG is chartered for the main spec. Other usages of LISP can be discussed in other, more pertinent, WGs. Obviously some form of collaboration will be necessary at least to make the LISP WG aware of how other WGs plan to use LISP.

> We have to talk about that LISP signaling which could be used in TCMTF, as you say.

As I said before, these details can be documented elsewhere. If LISP is mentioned in the main draft, then it can also be stated that the re-use of the LISP signalling machinery in the context of TCMTF is explored in a different document.

ciao

L.

> > The first can be used  at the tunnelling layer, beside GRE/MPLS/L2TP (having
> > multiple options is always a good thing ;-) ), to perform the tunnelling. Some
> > parts of the LISP header might be exploited to carry TE information (e.g., the
> > particular form of mappings. The advantage is that there is already quite a bit

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 21 Oct 2012 14:56:04 -0400

As a general comment from a chair, a document which references LISP does 
not need to be done in he LISP WG.  (Telling us about it is 
appreciated.)  A document which defines how to use LISP to do something 
needs to be coordinated with the LISP WG.

Yours,
Joel

On 10/21/2012 10:13 AM, Luigi Iannone wrote:
> Hi Jose,
>
> comments inline.
>
>
> On 19 Oct. 2012, at 18:04 , Jose Saldana <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Luigi,
> Concerning whether or not to include it in the draft, may be it is not
> necessary to include details about LISP just mention that can be used.
> The usage of LISP, because of its experimental nature compare to other
> tunnelling options, can be documented in a different document, which, if
> people are interested, I can (with your help) write.
>
>
> Nevertheless, IMHO,  the LISP WG is chartered for the main spec. Other
> usages of LISP can be discussed in other, more pertinent, WGs. Obviously
> some form of collaboration will be necessary at least to make the LISP
> WG aware of how other WGs plan to use LISP.
>
> As I said before, these details can be documented elsewhere. If LISP is
> mentioned in the main draft, then it can also be stated that the re-use
> of the LISP signalling machinery in the context of TCMTF is explored in
> a different document.
>
> ciao
>
> L.
>
>
>> Thanks,
>> Jose
>> >De:[email-masked]
>> <mailto:[email-masked]>[mailto:[email-masked]
>> <mailto:[email-masked]>] En nombre de
>> >Luigi Iannone
>> >Para:[email-masked] <mailto:[email-masked]>
>> >CC:[email-masked] <mailto:[email-masked]>
>> > On 10 Oct. 2012, at 13:48 , Jose Saldana <[email-masked] <mailto:[email-masked]>> wrote:
>> >
>> > > Luigi,
>> > >
>> > >> De:[email-masked]
>> <mailto:[email-masked]>[mailto:[email-masked]] En nombre
>> > >> Para:[email-masked] <mailto:[email-masked]>
>> > >> CC:[email-masked] <mailto:[email-masked]>
>> > >> On 10 Oct. 2012, at 09:58 , Jose Saldana <[email-masked] <mailto:[email-masked]>> wrote:
>> > >>
>> > >>[email-masked] <mailto:[email-masked]>
>> >[email-masked] <mailto:[email-masked]>
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>