From Martin.Stiemerling@neclab.eu Thu Feb 7 02:40:53 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB11C21F855F for ; Thu, 7 Feb 2013 02:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.472 X-Spam-Level: X-Spam-Status: No, score=-103.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmsGVpq7ycTV for ; Thu, 7 Feb 2013 02:40:53 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD021F855A for ; Thu, 7 Feb 2013 02:40:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 662B61030F0 for ; Thu, 7 Feb 2013 11:40:51 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ9XVAyvULRm for ; Thu, 7 Feb 2013 11:40:51 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 4BCD01030ED for ; Thu, 7 Feb 2013 11:40:46 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 7 Feb 2013 11:40:46 +0100 Message-ID: <511384AE.4020400@neclab.eu> Date: Thu, 7 Feb 2013 11:40:46 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Subject: Fwd: Nomcom 2012: Feedback on TSV Nominees References: <20130206152017.17915.96646.idtracker@ietfa.amsl.com> In-Reply-To: <20130206152017.17915.96646.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130206152017.17915.96646.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 10:40:53 -0000 Please, provide your feedback as soon as possible! MArtin -------- Original Message -------- Subject: Nomcom 2012: Feedback on TSV Nominees Date: Wed, 6 Feb 2013 07:20:17 -0800 From: NomCom Chair To: IETF Announcement List Thanks to everyone who helped the IETF Nominating Committee (Nomcom) by responding to our call for Transport (TSV) Area Director nominations. Three individuals accepted nominations for the TSV area director position. The Nomcom is therefore seeking input from the community about whether these nominees are a good fit for the TSV Area Director position. The Nomcom is therefore seeking community feedback about the following individuals: -- Spencer Dawkins -- Mark Townsley -- Margaret Wasserman -- Ken Carlberg -- Linda Dunbar -- Tom Haynes The Nomcom is happy to accept input from the community either via email to nomcom12@ietf.org or via our web tool: https://www.ietf.org/group/nomcom/2012/input/ Note that our webtool requires an ietf.org login, anyone can easily get an ietf.org account at: https://datatracker.ietf.org/accounts Note that the Nomcom is following the guidelines in RFC 5680 in making public the list of individuals who have agreed to be considered for the position of TSV Area Director. The Nomcom is operating on a very tight time schedule, and would appreciate input as soon as possible. To ensure your input is received in time to be useful to the Nomcom please send input on or before Monday, February 11. Thanks again for your help, - Matt Lepinski nomcom-chair@ietf.org -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From jsaldana@unizar.es Mon Feb 18 00:49:46 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3026821F86A8; Mon, 18 Feb 2013 00:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.522 X-Spam-Level: X-Spam-Status: No, score=-6.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neZ-o9kYN8c1; Mon, 18 Feb 2013 00:49:44 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 846C921F868B; Mon, 18 Feb 2013 00:49:43 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r1I8ndxo023168; Mon, 18 Feb 2013 09:49:40 +0100 From: "Jose Saldana" To: References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> In-Reply-To: <003001cdff0e$33658a50$9a309ef0$@unizar.es> Subject: RE: About the possibility of having a BOF about TCMTF in IETF87 Date: Mon, 18 Feb 2013 09:49:41 +0100 Organization: Universidad de Zaragoza Message-ID: <008601ce0db4$e4af6f60$ae0e4e20$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4VYfsQr5DqoVbCGYPdBLd2Eoe0JgoRmuw Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 08:49:46 -0000 Hi all, As you may know, we are thinking about presenting a BOF proposal for = IETF 87 in Berlin (July-August), with the aim of creating a Working Group. I have prepared a presentation about TCMTF, in order to show some = figures with the scenarios, the protocol stack, and some of the obtained = bandwidth savings (for some cases, they are about 70%). The presentation can be found here: http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_2013.pdf The draft of the charter is here: http://diec.unizar.es/~jsaldana/personal/ietf/tcmtf_charter_draft.pdf , = and also in this message: http://www.ietf.org/mail-archive/web/tcmtf/current/msg00191.html The mailing list we are using for preparing the BOF is tcmtf@ietf.org (https://www.ietf.org/mailman/listinfo/tcmtf)=20 If you have any suggestions for improvement, they will be welcome. Best regards, Jose Saldana -----Mensaje original----- De: tsv-area-bounces@ietf.org [mailto:tsv-area-bounces@ietf.org] En = nombre de Jose Saldana Enviado el: mi=E9rcoles, 30 de enero de 2013 18:21 Para: tsv-area@ietf.org; tcmtf@ietf.org CC: Gonzalo Camarillo; Martin Stiemerling Asunto: About the possibility of having a BOF about TCMTF in IETF87 Hi all. With this e-mail I would like to socialize TCMTF (Tunneling, Compressing = and Multiplexing Traffic Flows) within the IETF. We have the idea of = presenting a BOF proposal for IETF 87 in Berlin (July-August), with the aim of = creating a Working Group. In this message I will talk about the problem we are trying to solve, = and I will try to summarize the story of TCMTF within the IETF. - The main idea (see also the Charter proposal below) is to define a = method for saving bandwidth in real-time services which use tiny packets. Some examples of these services are online games, viceoconference, in = addition to VoIP. The overhead of the packets of these services is significant, so = the efficiency can be increased when a number of flows share the same path: packets belonging to different flows can be grouped together, adding a = small multiplexing delay as a counterpart. Currently, there exists an = efficiency improvement method for VoIP using RTP: RFC4170 (TCRTP). It considers = header compression by means of ECRTP; multiplexing by means of PPPMux; and tunneling by means of L2TPv3. However, in the last years, emerging = real-time services which do not use UDP/RTP protocols have become popular: some of them use UDP or even TCP. In addition, new header compression methods = have been defined (ROHC). So widening the scope of RFC4170 in order to = consider not only UDP/RTP but also other protocols is seen as convenient. The = same three layers would be used: header compression, multiplexing and = end-to-end tunneling. Some examples of the scenarios where grouping packets is possible are: aggregation networks of a network operator; a tunnel between two = premises of the same company; the access connection of an Internet Caf=E9 including = a high number of VoIP/gaming flows; an agreement between two network operators could allow them to compress a number of flows they are exchanging = between a pair of Internet Routers; a satellite connection used for collecting the data of a high number of sensors; etc.=20 - The story: * A first draft was written with cooperation of some people from = Transport and RAI Areas. Dan Wing, one of the authors of RFC4170, is also participating on TCMTF from the very beginning. This is the first = version (Feb 2012) http://tools.ietf.org/id/draft-saldana-tsvwg-tcmtf-00.txt * It was presented in the TSVWG session (Transport Area) IETF-83, Paris, March 27th 2012: http://www.ietf.org/proceedings/83/minutes/minutes-83-tsvwg.txt. The presentation is here: http://diec.unizar.es/~jsaldana/personal/present-saldana-tsvwg-tcmtf_v2.p= df * A specific mailing list was created (July 10th 2012): https://www.ietf.org/mailman/listinfo/tcmtf * A second draft was submitted (Dec 12th 2012), " Maximum Tolerable = Delays when using Tunneling Compressed Multiplexed Traffic Flows": http://datatracker.ietf.org/doc/draft-suznjevic-tsvwg-mtd-tcmtf/ * This is the current version of the initial draft: https://datatracker.ietf.org/doc/draft-saldana-tsvwg-tcmtf/. The number = of authors and contributors has been increased. - Many people have participated in the mailing list, mainly from network operators, network equipment manufacturers, a Space Agency (DLR) and Academia. - And finally, this is the current version of the Charter Proposal. We = have discussed and polished it in the list (http://www.ietf.org/mail-archive/web/tcmtf/current/threads.html), and = we have arrived to this agreement: *Description of Working Group v4* 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 higher when IPv6 is used, since 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 sending collected data in sensor networks using wireless or satellite scenarios). 2. The efficiency cannot be increased by the inclusion of a higher = number of samples in a single packet, since this would harm the delay requirements = of the service. But there exist some scenarios in which a number of flows = share the same path. In this case, packets belonging to different flows can be grouped together, adding a small multiplexing delay as a counterpart of bandwidth saving. This delay will have to be maintained under some = threshold in order to grant the delay requirements. Some examples of the scenarios where grouping packets is possible are: aggregation networks of a = network operator; a tunnel between two premises of the same company; the access connection of an Internet Caf=E9 including a high number of VoIP/gaming = flows; an agreement between two network operators could allow them to compress = a number of flows they are exchanging between a pair of Internet Routers; = a satellite connection used for collecting the data of a high number of sensors; etc. 3. VoIP using RTP is a clear example of a real-time service using small packets with high overhead. In order to improve efficiency, RFC4170 = (TCRTP) defined a method for grouping packets when a number of flows share a = path, considering three different layers: header compression by means of = ECRTP; multiplexing by means of PPPMux; tunneling by means of L2TPv3. 4. However, in the last years, emerging real-time services which do not = use UDP/RTP have become popular: some of them use UDP or even TCP. So there = is a need of widening the scope of RFC4170 in order to consider not only = UDP/RTP but also other protocols. The same structure of three layers will be considered: - 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: 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 then 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. 5. So the first objective of this group is to specify the protocol stack = for tunneling, compressing and multiplexing traffic flows (TCMTF). Since standard protocols are being used at each layer, the signaling methods = of those protocols will be used. Interactions with the Working Groups and = Areas in which these protocols are developed can be expected. However, the development of new compressing, multiplexing or tunneling protocols is = not an objective of this Working Group. In addition, since the current RFC = 4170 would be considered as one of the options, this RFC could be obsoleted. 6. As a first objective, a document (A) will define the different = options which can be used at each layer. 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. 7. If a pair multiplexer/de- multiplexer want to establish a tunnel, = they have first to use a mechanism to negotiate which concrete option would = they use in each layer: header compression, multiplexing and tunneling. This = will depend on the protocols that each extreme implements at each level, and = in the scenario. So document (A) will also include a negotiation mechanism = to decide the options to use at each layer (header compression, = multiplexing and tunneling) between multiplexer and de-multiplexer, and a mechanism = to setup/release a tunnel between a multiplexer and a de-multiplexer. 8. As a counterpart of the bandwidth saving, TCMTF may add some delay = and jitter. 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 useful recommendations in order to = decide which packet flows can or can not be multiplexed and how. The document = (B) will present a list of available traffic classification methods which = can be used for identification of the service or application to which a = particular flow belongs, as well as recommendations of the maximum delay and jitter = to be added depending of the identified service or application. 9. If other interesting features are identified, the group would = re-charter and include them, e.g., a mechanism for a multiplexer to discover a de-multiplexer, and vice versa; a mechanism to select an optimal = multiplexer and a de-multiplexer when there are more than one muxer/de-muxer for a = flow; dynamically applying TCMTF: a higher entity in charge of deciding when = and where, applying or not TCMTF, and what kind of TCMTF, and what = multiplexing period. Additional methods for estimating delay would also be required. 10. In addition, specific uses of TCMTF, such as in wireless and = satellite scenarios, could be considered, and it will be studied whether = modifications or extensions are required on the protocol. 11. Interactions with other Working Groups can be expected, since TCMTF = uses already defined protocols for compression, multiplexing and tunneling = (ROHC, PPPMux, MPLS, GRE, L2TP). =20 *Goals and Milestones* Specification of TCMTF protocol stack (A) and signaling mechanisms. Recommendations (B) of using existing traffic classification methods, maximum delay and jitter to add, depending on the service. ------------------ Thank you very much, Jose Saldana > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre=20 > de Martin Stiemerling Enviado el: martes, 29 de enero de 2013 12:54 > Para: jsaldana@unizar.es > CC: wes@mti-systems.com; tcmtf@ietf.org;=20 > Gonzalo.Camarillo@ericsson.com > Asunto: Re: [tcmtf] Improved version of the TCMTF Charter proposal=20 > (v3) >=20 > Hi Jose, >=20 > On 01/29/2013 11:57 AM, Jose Saldana wrote: > > Yes, Martin. The idea is that many interested people may attend IETF = > > Berlin in July: at least I know about interested people from U. > > Zaragoza, DLR, Telefonica, U. Zagreb, U. Stuttgart, who could attend = > > that BoF. And also co-authors from Cisco (Dan, Michael, and perhaps > > Muthu) may be there. Well, these are the news I have. In addition,=20 > > Mirko and I would also be able to organize the "online games traffic tutorial > there". >=20 > So Berlin is the place to make a BoF. >=20 > > > > So is your idea to have a BoF for discussing the TCMTF WG in Berlin? > > Do you prefer that possibility instead of the "DISPATCH" option that = > > Gonzalo suggested? If you confirm that, we would take it into=20 > > account in order to organize the summer calendar. >=20 > We do not have the DISPATCH option in the Transport Area. >=20 > My proposal is to start socializing the idea within the IETF and to=20 > aim for a BoF > in Berlin. Sending the proposal to the TSVAREA list might be a good = start. >=20 > Martin >=20 > > > > Thanks a lot, > > > > Jose > > PS: This is the option that Gonzalo suggested to Wes (November = 29th): > > "Hi Wes, > > > > sure. When the proponents have a charter proposal ready, feel free=20 > > to send it to the TSVAREA list for comments while informing all the=20 > > other lists. If you want, I can take care of informing the DISPATCH=20 > > list pointing to the relevant message in the TSVAREA list when you = send it. > > > > With respect to where discussions should take place, DISPATCH=20 > > participants will find it easier to send comments on the DISPATCH = list. > > However, if sending comments requires subscribing to a different=20 > > list and sending comments to a different crowd, many may not bother=20 > > commenting. I can monitor the discussions in DISPATCH and send you a = > > summary if needed. Since we are talking about very few lists, it=20 > > should be relatively easy to keep things under control. > > > > Cheers, > > > > Gonzalo" > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En=20 > >> nombre de Martin Stiemerling Enviado el: martes, 29 de enero de=20 > >> 2013 11:39 > >> Para: FERNANDO PASCUAL BLANCO > >> CC: wes@mti-systems.com; tcmtf@ietf.org; Matteo.Berioli@dlr.de;=20 > >> Gonzalo.Camarillo@ericsson.com; jsaldana@unizar.es > >> Asunto: Re: [tcmtf] Improved version of the TCMTF Charter proposal > >> (v3) > >> > >> Hi all, > >> > >> The BoF deadline for the upcoming meeting was Jan 28. > >> > >> Further, my understanding is the relevant proponents cannot make it = > >> to the IETF meeting in March in Orlando, but that there is a plan=20 > >> for the IETF meeting in Berlin in July 2013. > >> > >> Martin > >> > >> On 01/29/2013 11:13 AM, FERNANDO PASCUAL BLANCO wrote: > >>> Hi all, > >>> > >>> In my opinion the WG is needed. TCMTF discussion have=20 > >>> reach enough interest and enough roadmap to have a room for=20 > >>> itself, at least an small room. As Jose said, there are two enough = > >>> active drafts and there is potentially room for three more, and I=20 > >>> think this is a justification by itself. > >>> On the other hand, I also think that we are problem centered. > >>> At least being in a network operation feet I find TCMTF useful = enough. > >>> > >>> Regards, > >>> > >>> Fernando Pascual Blanco > >>> Telef=F3nica Global Resources > >>> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F=20 > >>> +34913128779 M +34682005168 fpb@tid.es > >>> > >>> > >>> > >>> > >>> On 29/01/13 10:56, "Jose Saldana" wrote: > >>> > >>>> Matteo, > >>>> > >>>> Thanks a lot. Well, in this case, I don't agree with you (only in = > >>>> this case). > >>>> > >>>> The idea with TCMTF was to create a "small" Working Group, the=20 > >>>> same way as they are created in other Areas (e.g. RAI). > >>>> > >>>> As Wes said in November, " In my opinion, it is something a=20 > >>>> separate WG should be created to handle, and not something to try = > >>>> to do inside the TSVWG, since there are already a handful of=20 > >>>> things TSVWG is wrestling with, and it creates too much "context=20 > >>>> switching" to have a lot of unrelated topics under work there." > >>>> > >>>> The question is that the TSVWG group has a lot of interesting=20 > >>>> things now, and it would be better to discuss TCMTF separately.=20 > >>>> In fact, since the Summer, we are discussing it in another=20 > >>>> mailing list. This is good, but in fact many people from TSVWG=20 > >>>> have not followed our > >> discussion. > >>>> > >>>> In addition, a lot of time has passed. TCMTF draft was presented=20 > >>>> in Paris > >>>> 10 > >>>> months ago. A lot of people from many institutions have become=20 > >>>> interested on it. We have two drafts and three more = possibilities. > >>>> > >>>> Neither am I an expert on IETF, but I understand that things have = > >>>> some > >>>> "momentum": if you let time go by, people may lose their = interest. > >>>> And curently interest does exist, as we have seen in the list. So = > >>>> why > > not > >> now? > >>>> > >>>> In addition, the new version of the Charter is more=20 > >>>> problem-centered (I hope). > >>>> > >>>> Thanks and best regards, > >>>> > >>>> Jose > >>>> > >>>> > >>>>> -----Mensaje original----- > >>>>> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En > >> nombre > >>>>> de Matteo.Berioli@dlr.de Enviado el: martes, 29 de enero de 2013 > >>>>> 9:18 > >>>>> Para: wes@mti-systems.com; jsaldana@unizar.es > >>>>> CC: tcmtf@ietf.org; Gonzalo.Camarillo@ericsson.com;=20 > >>>>> Martin.Stiemerling@neclab.eu > >>>>> Asunto: Re: [tcmtf] Improved version of the TCMTF Charter=20 > >>>>> proposal > >>>>> (v3) > >>>>> > >>>>> Dear all, > >>>>> > >>>>> I don't have a huge experience in IETF, but feel it is important = > >>>>> to > >>>> express my > >>>>> opinion this time. > >>>>> I have the feeling building a new WG is a bit premature,=20 > >>>>> considering that > >>>> we > >>>>> just have an Internet draft. > >>>>> I also find the discussion a bit documents-driven, rather than > >>>>> problems- driven. > >>>>> IMHO we could wait a bit, before creating the WG, to see whether = > >>>>> the ideas we have really solve real-world problems. > >>>>> > >>>>> That's it. Hope this helps. > >>>>> > >>>>> Matteo > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] On=20 > >>>>> Behalf Of Wesley Eddy > >>>>> Sent: 24 January 2013 06:16 > >>>>> To: jsaldana@unizar.es > >>>>> Cc: tcmtf@ietf.org; Gonzalo Camarillo; Martin Stiemerling > >>>>> Subject: Re: [tcmtf] Improved version of the TCMTF Charter=20 > >>>>> proposal > >>>>> (v3) > >>>>> > >>>>> On 1/23/2013 6:58 AM, Jose Saldana wrote: > >>>>>> Hello all. > >>>>>> > >>>>>> > >>>>>> > >>>>>> After reading the messages in the mailing list, I think we have = > >>>>>> arrived to a solution. Each of the documents has been discussed = > >>>>>> in a separate thread, so I have tried to take everything into account. > >>>>>> Documents (A) and (B) would be in the Charter. Documents (C)=20 > >>>>>> and > >>>>>> (D) would only be announced as possibilities for re-chartering, = > >>>>>> and Document (E) can wait a little. > >>>>>> > >>>>>> ... > >>>>> > >>>>> > >>>>> In my opinion, this is decent, though here are two criticisms: > >>>>> > >>>>> (1) In my opinion, it focuses too much on documents to be = produced, > >>>>> rather than fully and clearly motivating why the working = group > >>>>> is needed (i.e. to solve a problem, not to develop = documents), > >>>>> how it's scope is delimited (i.e. what it *won't* touch = isn't > >>>>> clear to me, along with what other areas/WGs need to be > >>>>> coordinated with), and what the end-goal is. > >>>>> > >>>>> (2) There's a focus on defining technical solutions prior to the > >>>>> mention of fleshing out and totally defining the use cases = / > >>>>> requirements. In my opinion, that appears backwards :). > >>>>> > >>>>> That said, I'm generally supportive of this work. In my=20 > >>>>> opinion, as an > >>>> AD, we > >>>>> would normally feel better having a BoF before forming a WG, for = > >>>>> two reasons (1) to get other areas (e.g. RAI) to be aware of=20 > >>>>> what's being proposed, and (2) to vet that there really is a=20 > >>>>> community of stakeholders that are engaged to do the work. In=20 > >>>>> this case, I think the 2nd point is evident from the mailing=20 > >>>>> list, and I don't have a concern about it at all. > >>>> I > >>>>> think the 1st point can be addressed through the responsible AD=20 > >>>>> coordinating with the IESG and the directorates or area mailing=20 > >>>>> lists that related areas have. > >>>>> Since I'm going away as an AD though, what really matters at the = > >>>>> moment is what Martin thinks :). > >>>>> > >>>>> -- > >>>>> Wes Eddy > >>>>> MTI Systems > >>>>> _______________________________________________ > >>>>> tcmtf mailing list > >>>>> tcmtf@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>>>> _______________________________________________ > >>>>> tcmtf mailing list > >>>>> tcmtf@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>>> > >>>> _______________________________________________ > >>>> tcmtf mailing list > >>>> tcmtf@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tcmtf > >>> > >>> > >>> ________________________________ > >>> > >>> Este mensaje se dirige exclusivamente a su destinatario. Puede=20 > >>> consultar > >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico = en el=20 > >> enlace situado m=E1s abajo. > >>> This message is intended exclusively for its addressee. We only=20 > >>> send and > >> receive email on the basis of the terms set out at: > >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > >>> > >> > >> -- > >> martin.stiemerling@neclab.eu > >> > >> NEC Laboratories Europe - Network Research Division NEC Europe=20 > >> Limited Registered Office: NEC House, 1 Victoria Road, London W3=20 > >> 6BL Registered in England 283=20 > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > >=20 > -- > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = > Registered Office: NEC House, 1 Victoria Road, London W3 6BL=20 > Registered in England 283=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From Martin.Stiemerling@neclab.eu Tue Feb 19 01:05:56 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F6021F8778 for ; Tue, 19 Feb 2013 01:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.493 X-Spam-Level: X-Spam-Status: No, score=-103.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NniJJMnIj3FN for ; Tue, 19 Feb 2013 01:05:55 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9814021F8726 for ; Tue, 19 Feb 2013 01:05:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BE4591032C4 for ; Tue, 19 Feb 2013 10:05:54 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZatcqleQGvPW for ; Tue, 19 Feb 2013 10:05:54 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A6FB81032BA for ; Tue, 19 Feb 2013 10:05:49 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 19 Feb 2013 10:05:49 +0100 Message-ID: <5123406D.5040509@neclab.eu> Date: Tue, 19 Feb 2013 10:05:49 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Subject: TSV Area meeting at IETF-86 in Orlando Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 09:05:56 -0000 Dear all, At the IETF 86 meeting, we're planning to hold a TSVAREA session in order to cover (at least) a briefing/tutorial on the state of SCTP, a general open discussion on AQM and potential for IETF work in this area, and a short information about the issue of filling the Transport Area Director position. If there are any other topics that you'd like to discuss, please let the ADs know right away so that we can get the agenda finalized into the timeslot. Wes and Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From carlberg@g11.org.uk Tue Feb 19 05:17:19 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9330521F8CBF; Tue, 19 Feb 2013 05:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bCZf-TLC0iD; Tue, 19 Feb 2013 05:17:18 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id A3C6E21F8CB1; Tue, 19 Feb 2013 05:17:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=lmMmwltiqZIfgDLUSCw71VK1hTWi/YfiIdKGnWDrBwo=; b=xq5ZgxFyfegkrScX+lCOPR0kOooxs5UZhmezNN/vw5yi23XmA9k2DhAwSO1z38hstX7maorbuQJhhQT4keQrVJCiaoW3neW7Qa87cu5jzmdu2NMGQ5EfpGF2Euk3lVda; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:33293 helo=[10.0.1.20]) by portland.eukhosting.net with esmtp (Exim 4.80) (envelope-from ) id 1U7n4M-000Yl7-Fl; Tue, 19 Feb 2013 13:17:14 +0000 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: About the possibility of having a BOF about TCMTF in IETF87 From: ken carlberg In-Reply-To: <008601ce0db4$e4af6f60$ae0e4e20$@unizar.es> Date: Tue, 19 Feb 2013 08:17:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <50F486E8-69AA-4A9D-970C-1F8EC1372B8D@g11.org.uk> References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> <008601ce0db4$e4af6f60$ae0e4e20$@unizar.es> To: jsaldana@unizar.es X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 13:17:19 -0000 Hola Jose, could you expand a bit more on your text in the proposed charter = regarding "signaling methods". Are you speaking in the more general = context of information stored in headers of various protocol up and down = the stack (ie, layers 3, 4, and 5/app)? Or, are you speaking of = concurrent resource signaling protocols like RSVP/RSVP-TE, or path = establishment protocols like MPLS? Or, some combination of both? -ken From jsaldana@unizar.es Fri Feb 22 02:39:25 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483D921F8E2C; Fri, 22 Feb 2013 02:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UIHP8wvIV4K; Fri, 22 Feb 2013 02:39:24 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6D84021F8E20; Fri, 22 Feb 2013 02:39:24 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r1MAd9LR012037; Fri, 22 Feb 2013 11:39:15 +0100 From: "Jose Saldana" To: "'ken carlberg'" References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> <008601ce0db4$e4af6f60$ae0e4e20$@unizar.es> <50F486E8-69AA-4A9D-970C-1F8EC1372B8D@g11.org.uk> In-Reply-To: <50F486E8-69AA-4A9D-970C-1F8EC1372B8D@g11.org.uk> Subject: RE: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87 Date: Fri, 22 Feb 2013 11:39:16 +0100 Organization: Universidad de Zaragoza Message-ID: <002801ce10e8$e070f7c0$a152e740$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4VYfsQr5DqoVbCGYPdBLd2Eoe0AJlfa8LAYNeKsOYEd4jcA== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:39:25 -0000 Hi Ken, Sorry for the delay. I think you are talking about Paragraph 5: 5. So the first objective of this group is to specify the protocol stack for tunneling, compressing and multiplexing traffic flows (TCMTF). Since standard protocols are being used at each layer, the signaling methods of those protocols will be used. Interactions with the Working Groups and Areas in which these protocols are developed can be expected. However, the development of new compressing, multiplexing or tunneling protocols is not an objective of this Working Group. In addition, since the current RFC 4170 would be considered as one of the options, this RFC could be obsoleted. Perhaps this is a bit confusing. When we say "at each layer", we are talking about "tunneling, compressing and multiplexing" layers. Perhaps this can be a bit confusing. What about this?: 5. So the first objective of this group is to specify the protocol stack for tunneling, compressing and multiplexing traffic flows (TCMTF). Since standard protocols are being used for tunneling, compressing and multiplexing layers, the signaling methods of those protocols will be used. Interactions with the Working Groups and Areas in which these protocols are developed can be expected. However, the development of new compressing, multiplexing or tunneling protocols is not an objective of this Working Group. In addition, since the current RFC 4170 would be considered as one of the options, this RFC could be obsoleted. Is this what you were asking? Thanks for your feedback. Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre de > ken carlberg > Enviado el: martes, 19 de febrero de 2013 14:17 > Para: jsaldana@unizar.es > CC: tcmtf@ietf.org; tsv-area@ietf.org > Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF in > IETF87 > > Hola Jose, > > could you expand a bit more on your text in the proposed charter regarding > "signaling methods". Are you speaking in the more general context of > information stored in headers of various protocol up and down the stack (ie, > layers 3, 4, and 5/app)? Or, are you speaking of concurrent resource > signaling protocols like RSVP/RSVP-TE, or path establishment protocols like > MPLS? Or, some combination of both? > > -ken > > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf From Martin.Stiemerling@neclab.eu Tue Feb 26 07:24:41 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D575121F8775 for ; Tue, 26 Feb 2013 07:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igWgojv7lIyW for ; Tue, 26 Feb 2013 07:24:37 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3B83521F8763 for ; Tue, 26 Feb 2013 07:24:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9C2E4103451 for ; Tue, 26 Feb 2013 16:24:33 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF4oAp-z-tM9 for ; Tue, 26 Feb 2013 16:24:33 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 8337D103450 for ; Tue, 26 Feb 2013 16:24:28 +0100 (CET) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 26 Feb 2013 16:24:07 +0100 Message-ID: <512CD397.2080505@neclab.eu> Date: Tue, 26 Feb 2013 16:24:07 +0100 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Subject: TSV AD "office hours" @IETF86 in Orlando Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: "tsv-ads@tools.ietf.org" List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 15:24:42 -0000 Hi there, This is an early but very tentative announcement of the TSV AD "office hours" at the IETF-86 meeting in Orlando. Tentative, because we do not yet know who will replace Wes as the new TSV AD, and if she or he will be available in the time slot mentioned below. The office hours are for the case there are things that you need to discuss with us in person and aren't able to pin us down any other time. The current time slot reserved for the office hours is 1300-1500 Wednesday Afternoon Session I We do not yet know the room number of the IESG room. The room will be announced soon. Thanks, Martin From carlberg@g11.org.uk Wed Feb 27 07:23:19 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC7221F84BB; Wed, 27 Feb 2013 07:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3ZwKM-6iJ7L; Wed, 27 Feb 2013 07:23:19 -0800 (PST) Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfa.amsl.com (Postfix) with ESMTP id 40E1921F84B2; Wed, 27 Feb 2013 07:23:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=g11.org.uk; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=7P3lFiwvOq2U/VjTU9sxnoC+kPRrDTkZYT8vhgkevTQ=; b=fnQ/VsMd8r4DIy99WBbY4b60cMwQmS7PMMZ3UKKWuMb3A1PjnwfYyouARD0aPXGSdwdE+jvWCss9OuOsmuTRWacWhiD2vzHA7F+0TLKGQDQNNT8YLkdOyZ4kFFSp03gx; Received: from c-98-218-170-72.hsd1.va.comcast.net ([98.218.170.72]:36211 helo=[10.0.1.20]) by portland.eukhosting.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UAiqg-002wUN-AB; Wed, 27 Feb 2013 15:23:15 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87 From: ken carlberg In-Reply-To: <002801ce10e8$e070f7c0$a152e740$@unizar.es> Date: Wed, 27 Feb 2013 10:23:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> <008601ce0db4$e4af6f60$ae0e4e20$@unizar.es> <50F486E8-69AA-4A9D-970C-1F8EC1372B8D@g11.org.uk> <002801ce10e8$e070f7c0$a152e740$@unizar.es> To: X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk X-Get-Message-Sender-Via: portland.eukhosting.net: acl_c_relayhosts_text_entry: carlberg@g11.org.uk|g11.org.uk Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:23:19 -0000 Hola Jose, sorry for the tardy reply. The altered text below is helpful, thanks. With respect to your candidate deliverables, it appears that you have = listed two for the proposed group: (A) a document that describes options = and negotiation mechanisms, and (B) a document describing = recommendations of which packet types should be multiplexed and a list = fo traffic classification methods. Have you considered a third document = that presents a more encompassing architecture or framework that would = include sample scenarios upon which your deliverables A & B are aimed = at? My impression is that you may want to point the reader of documents = A & B to the same reference model, and instead of repeating the same = text, it may be helpful to separate this into a separate document.=20 Also, would section 9 of your proposed charter lead one to consider a = requirements document? Many times, new groups start with a requirements = document, but since you have a good focus of what you want to = accomplish, perhaps your last deliverable could be a requirements = document that would guide any future work. -ken ps, I don't want to advocate more work, but rather just have you = consider other possibilities (and feel free to shoot them down :-) On Feb 22, 2013, at 5:39 AM, Jose Saldana wrote: > Hi Ken, >=20 > Sorry for the delay. I think you are talking about Paragraph 5: >=20 > 5. So the first objective of this group is to specify the protocol = stack for > tunneling, compressing and multiplexing traffic flows (TCMTF). Since > standard protocols are being used at each layer, the signaling methods = of > those protocols will be used. Interactions with the Working Groups and = Areas > in which these protocols are developed can be expected. However, the > development of new compressing, multiplexing or tunneling protocols is = not > an objective of this Working Group. In addition, since the current RFC = 4170 > would be considered as one of the options, this RFC could be = obsoleted. >=20 > Perhaps this is a bit confusing. When we say "at each layer", we are = talking > about "tunneling, compressing and multiplexing" layers. Perhaps this = can be > a bit confusing. What about this?: >=20 > 5. So the first objective of this group is to specify the protocol = stack for > tunneling, compressing and multiplexing traffic flows (TCMTF). Since > standard protocols are being used for tunneling, compressing and > multiplexing layers, the signaling methods of those protocols will be = used. > Interactions with the Working Groups and Areas in which these = protocols are > developed can be expected. However, the development of new = compressing, > multiplexing or tunneling protocols is not an objective of this = Working > Group. In addition, since the current RFC 4170 would be considered as = one of > the options, this RFC could be obsoleted. >=20 > Is this what you were asking? >=20 > Thanks for your feedback. >=20 > Jose >=20 >> -----Mensaje original----- >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de >> ken carlberg >> Enviado el: martes, 19 de febrero de 2013 14:17 >> Para: jsaldana@unizar.es >> CC: tcmtf@ietf.org; tsv-area@ietf.org >> Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF = in >> IETF87 >>=20 >> Hola Jose, >>=20 >> could you expand a bit more on your text in the proposed charter = regarding >> "signaling methods". Are you speaking in the more general context of >> information stored in headers of various protocol up and down the = stack > (ie, >> layers 3, 4, and 5/app)? Or, are you speaking of concurrent = resource >> signaling protocols like RSVP/RSVP-TE, or path establishment = protocols > like >> MPLS? Or, some combination of both? >>=20 >> -ken >>=20 >> _______________________________________________ >> tcmtf mailing list >> tcmtf@ietf.org >> https://www.ietf.org/mailman/listinfo/tcmtf >=20 From jsaldana@unizar.es Thu Feb 28 02:33:23 2013 Return-Path: X-Original-To: tsv-area@ietfa.amsl.com Delivered-To: tsv-area@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E1121F88CF; Thu, 28 Feb 2013 02:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cV3iwfPh1eNM; Thu, 28 Feb 2013 02:33:23 -0800 (PST) Received: from ortiz.unizar.es (ortiz.unizar.es [155.210.1.52]) by ietfa.amsl.com (Postfix) with ESMTP id 80BF921F8AD4; Thu, 28 Feb 2013 02:33:22 -0800 (PST) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by ortiz.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id r1SAXEuw005061; Thu, 28 Feb 2013 11:33:14 +0100 From: "Jose Saldana" To: "'ken carlberg'" References: <003001cdff0e$33658a50$9a309ef0$@unizar.es> <008601ce0db4$e4af6f60$ae0e4e20$@unizar.es> <50F486E8-69AA-4A9D-970C-1F8EC1372B8D@g11.org.uk> <002801ce10e8$e070f7c0$a152e740$@unizar.es> In-Reply-To: Subject: RE: [tcmtf] About the possibility of having a BOF about TCMTF in IETF87 Date: Thu, 28 Feb 2013 11:33:19 +0100 Organization: Universidad de Zaragoza Message-ID: <007101ce159f$06c8cf50$145a6df0$@unizar.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH4VYfsQr5DqoVbCGYPdBLd2Eoe0AJlfa8LAYNeKsMC4CsVHwL3AXLGl+yOu3A= Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Cc: tcmtf@ietf.org, tsv-area@ietf.org X-BeenThere: tsv-area@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jsaldana@unizar.es List-Id: IETF Transport and Services Area Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 10:33:23 -0000 Thanks, Ken. The idea is this: A main document (A) in which we explain the method, the scenarios and = the minimum signaling issues in order to make it work. The idea is that = document (A) would be self-contained. Since we are not defining new protocols = (i.e. already existing compressing, multiplexing and tunneling protocols are = to be used), we understand that this can be done in a single document. It = would include: 1- Protocol stack (it would be the "reference model") 2- a negotiation mechanism to decide the options to use at each layer 3- a mechanism to setup/release a tunnel between a multiplexer and a de-multiplexer Of course, another approach could be separating 1 from 2&3. However, we think this is not necessary since the method is not too complicated. Document (B) would only contain recommendations of how to better use the method proposed in document (A), i.e., classification and maximum = delays. So clearly document (B) would totally depend on the reference model of document (A). The idea of point 9 is to talk about some other interesting ideas which = are considered as "future work": - a mechanism for a multiplexer to discover a de-multiplexer - mechanism to select an optimal multiplexer and a de-multiplexer when = there are more than one muxer/de-muxer for a flow - dynamically applying TCMTF - etc. What do you think? Thanks again for your feedback. Thinking and explaining things is always = a good exercise! Jose > -----Mensaje original----- > De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En nombre = de > ken carlberg > Enviado el: mi=E9rcoles, 27 de febrero de 2013 16:23 > Para: jsaldana@unizar.es > CC: tcmtf@ietf.org; tsv-area@ietf.org > Asunto: Re: [tcmtf] About the possibility of having a BOF about TCMTF = in > IETF87 >=20 > Hola Jose, >=20 > sorry for the tardy reply. The altered text below is helpful, thanks. >=20 > With respect to your candidate deliverables, it appears that you have listed > two for the proposed group: (A) a document that describes options and > negotiation mechanisms, and (B) a document describing recommendations > of which packet types should be multiplexed and a list fo traffic classification > methods. Have you considered a third document that presents a more > encompassing architecture or framework that would include sample > scenarios upon which your deliverables A & B are aimed at? My = impression is > that you may want to point the reader of documents A & B to the same > reference model, and instead of repeating the same text, it may be = helpful > to separate this into a separate document. >=20 > Also, would section 9 of your proposed charter lead one to consider a > requirements document? Many times, new groups start with a > requirements document, but since you have a good focus of what you = want > to accomplish, perhaps your last deliverable could be a requirements > document that would guide any future work. >=20 > -ken >=20 > ps, I don't want to advocate more work, but rather just have you = consider > other possibilities (and feel free to shoot them down :-) >=20 >=20 > On Feb 22, 2013, at 5:39 AM, Jose Saldana wrote: >=20 > > Hi Ken, > > > > Sorry for the delay. I think you are talking about Paragraph 5: > > > > 5. So the first objective of this group is to specify the protocol > > stack for tunneling, compressing and multiplexing traffic flows > > (TCMTF). Since standard protocols are being used at each layer, the > > signaling methods of those protocols will be used. Interactions with > > the Working Groups and Areas in which these protocols are developed > > can be expected. However, the development of new compressing, > > multiplexing or tunneling protocols is not an objective of this > > Working Group. In addition, since the current RFC 4170 would be > considered as one of the options, this RFC could be obsoleted. > > > > Perhaps this is a bit confusing. When we say "at each layer", we are > > talking about "tunneling, compressing and multiplexing" layers. > > Perhaps this can be a bit confusing. What about this?: > > > > 5. So the first objective of this group is to specify the protocol > > stack for tunneling, compressing and multiplexing traffic flows > > (TCMTF). Since standard protocols are being used for tunneling, > > compressing and multiplexing layers, the signaling methods of those > protocols will be used. > > Interactions with the Working Groups and Areas in which these > > protocols are developed can be expected. However, the development of > > new compressing, multiplexing or tunneling protocols is not an > > objective of this Working Group. In addition, since the current RFC > > 4170 would be considered as one of the options, this RFC could be > obsoleted. > > > > Is this what you were asking? > > > > Thanks for your feedback. > > > > Jose > > > >> -----Mensaje original----- > >> De: tcmtf-bounces@ietf.org [mailto:tcmtf-bounces@ietf.org] En = nombre > >> de ken carlberg Enviado el: martes, 19 de febrero de 2013 14:17 > >> Para: jsaldana@unizar.es > >> CC: tcmtf@ietf.org; tsv-area@ietf.org > >> Asunto: Re: [tcmtf] About the possibility of having a BOF about = TCMTF > >> in > >> IETF87 > >> > >> Hola Jose, > >> > >> could you expand a bit more on your text in the proposed charter > >> regarding "signaling methods". Are you speaking in the more = general > >> context of information stored in headers of various protocol up and > >> down the stack > > (ie, > >> layers 3, 4, and 5/app)? Or, are you speaking of concurrent > >> resource signaling protocols like RSVP/RSVP-TE, or path = establishment > >> protocols > > like > >> MPLS? Or, some combination of both? > >> > >> -ken > >> > >> _______________________________________________ > >> tcmtf mailing list > >> tcmtf@ietf.org > >> https://www.ietf.org/mailman/listinfo/tcmtf > > >=20 > _______________________________________________ > tcmtf mailing list > tcmtf@ietf.org > https://www.ietf.org/mailman/listinfo/tcmtf