From owner-ietf-ppp-outgoing@merit.edu Mon Jan 1 19:51:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29469 for ; Mon, 1 Jan 2001 19:51:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A91C5DD93; Mon, 1 Jan 2001 19:50:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 340325DD9F; Mon, 1 Jan 2001 19:50:24 -0500 (EST) Received: from mail.via-net.net (unknown [208.46.234.15]) by segue.merit.edu (Postfix) with ESMTP id EEDD55DD93 for ; Mon, 1 Jan 2001 19:50:22 -0500 (EST) Received: from karl.xc.org (ppp021.via-net.net [208.46.234.148]) by mail.via-net.net (Post.Office MTA v3.5.3 release 223 ID# 0-52517U2500L250S0V35) with ESMTP id net; Mon, 1 Jan 2001 19:50:33 -0500 Message-Id: <4.3.2.7.2.20010101194956.04d78a20@mail.via-net.net> X-Sender: kfox@mail.via-net.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Jan 2001 19:50:21 -0500 To: ietf-ppp@merit.edu From: Karl Fox Subject: I have a new e-mail address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Please make a note of it. Thanks, Karl Fox Key fingerprint = 4159 B4AD 339D 4E2A 255F 9CC4 9DA9 CB4B B16D E2B1 From owner-ietf-ppp-outgoing@merit.edu Tue Jan 2 17:34:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23452 for ; Tue, 2 Jan 2001 17:34:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2A405DD8F; Tue, 2 Jan 2001 17:30:44 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B83E65DD97; Tue, 2 Jan 2001 17:30:44 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id AFA785DD8F for ; Tue, 2 Jan 2001 17:30:42 -0500 (EST) Received: from brucet-nt3.cisco.com (dhcp-128-107-141-187.cisco.com [128.107.141.187]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA06368; Tue, 2 Jan 2001 14:30:28 -0800 (PST) Message-Id: <4.3.1.0.20010102141723.01ce4cb8@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 02 Jan 2001 14:32:32 -0800 To: ietf-ppp@merit.edu From: Bruce A Thompson Subject: Next steps on PPP over AAL2 Cc: James Carlson , Matt Holdrege , Karl Fox Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu I just wanted to summarize what I think we have agreed to do on the next draft of PPP over AAL2. Draft-buffam-avt-crtp-over-aal2-01.txt will be split into 2 different drafts. Draft-ietf-pppext-crtp-over-aal2-01.txt will be a subset of the current draft. It will describe the base encapsulation including CRC usage, usage of I.366.1, usage of Q.2630.2, and required UUI codepoints. This draft will allow the use of 1 or more AAL2 CIDs in an implementation of CRTP over AAL2. This document will also address the CRC issues brought up in the last thread on PPP over AAL2. A second draft will be written that will describe how multiple AAL2 CIDs can be used to perform LFI for PPP over AAL2 on low speed links. I don't know what the title of this draft will be. I still haven't gotten any official blessing that PPP over AAL2 has been accepted as a working group item in PPPEXT. Does anyone know the procedure for this? I need to get this draft accepted as a working group item in PPPEXT before the next IETF mtg so work supporting this effort can get underway in the ITU. Bruce T Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Thu Jan 4 07:28:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02476 for ; Thu, 4 Jan 2001 07:28:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D87A5DDDF; Thu, 4 Jan 2001 07:27:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 78D515DDE2; Thu, 4 Jan 2001 07:27:40 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id BFFCE5DDDF for ; Thu, 4 Jan 2001 07:27:38 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02426; Thu, 4 Jan 2001 07:27:36 -0500 (EST) Message-Id: <200101041227.HAA02426@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-eap-srp-00.txt Date: Thu, 04 Jan 2001 07:27:36 -0500 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : PPP EAP SRP-SHA1 Authentication Protocol Author(s) : J. Carlson Filename : draft-ietf-pppext-eap-srp-00.txt Pages : 15 Date : 03-Jan-01 The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an Extensible Authentication Protocol (EAP) [2] framework to allow the use of multiple authentication mechanisms without fixing the mechanism to be used during initial link negotiation. This document defines an authentication mechanism for EAP called SRP-SHA1, and allows the use of the Secure Remote Password (SRP) [3] protocol as a PPP link authentication method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-eap-srp-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-eap-srp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-eap-srp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010103133811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-eap-srp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-eap-srp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010103133811.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Sun Jan 7 07:08:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07754 for ; Sun, 7 Jan 2001 07:08:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 414895DD93; Sun, 7 Jan 2001 07:07:43 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1B7155DD9F; Sun, 7 Jan 2001 07:07:43 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 0AD7C5DD93 for ; Sun, 7 Jan 2001 07:07:41 -0500 (EST) Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f07C7b422304; Sun, 7 Jan 2001 13:07:38 +0100 (MET) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id NAA12048; Sun, 7 Jan 2001 13:07:37 +0100 (MET) Received: from ericsson.com.au (7-124.epa.ericsson.se [146.11.7.124]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id NAA17817; Sun, 7 Jan 2001 13:07:34 +0100 (MET) Message-ID: <3A585C13.DB2CCA73@ericsson.com.au> Date: Sun, 07 Jan 2001 23:07:47 +1100 From: Ian Rytina X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bruce A Thompson Cc: ietf-ppp@merit.edu Subject: Re: Next steps on PPP over AAL2 References: <4.3.1.0.20010102141723.01ce4cb8@sigma.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi Bruce, Is this limited to CRTP ? I assume we would want other compression schemes to be carried over AAL2. In that case, maybe the draft should be draft-ietf-pppext-ppp-over-aal2-00.txt Regards, Ian. Bruce A Thompson wrote: > I just wanted to summarize what I think we have agreed to do on the next draft of PPP over AAL2. > > Draft-buffam-avt-crtp-over-aal2-01.txt will be split into 2 different drafts. Draft-ietf-pppext-crtp-over-aal2-01.txt will be a subset of the current draft. It will describe the base encapsulation including CRC usage, usage of I.366.1, usage of Q.2630.2, and required UUI codepoints. This draft will allow the use of 1 or more AAL2 CIDs in an implementation of CRTP over AAL2. This document will also address the CRC issues brought up in the last thread on PPP over AAL2. > > A second draft will be written that will describe how multiple AAL2 CIDs can be used to perform LFI for PPP over AAL2 on low speed links. I don't know what the title of this draft will be. > > I still haven't gotten any official blessing that PPP over AAL2 has been accepted as a working group item in PPPEXT. Does anyone know the procedure for this? I need to get this draft accepted as a working group item in PPPEXT before the next IETF mtg so work supporting this effort can get underway in the ITU. > > Bruce T > Bruce Thompson > Cisco Systems > email: brucet@cisco.com > office: (408)527-0446 > home office: (408)868-0112 > San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Mon Jan 8 11:22:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09352 for ; Mon, 8 Jan 2001 11:22:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B22C5DDE7; Mon, 8 Jan 2001 11:20:41 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C0BC5DDE5; Mon, 8 Jan 2001 11:20:41 -0500 (EST) Received: from cisco.com (sigma.cisco.com [171.69.63.142]) by segue.merit.edu (Postfix) with ESMTP id 305625DE21 for ; Mon, 8 Jan 2001 11:20:38 -0500 (EST) Received: from brucet-nt3.cisco.com (brucet-dsl3.cisco.com [10.19.64.188]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA29047; Mon, 8 Jan 2001 08:20:25 -0800 (PST) Message-Id: <4.3.1.0.20010108082013.0126dc78@sigma.cisco.com> X-Sender: brucet@sigma.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 08 Jan 2001 08:22:30 -0800 To: Ian Rytina From: Bruce A Thompson Subject: Re: Next steps on PPP over AAL2 Cc: ietf-ppp@merit.edu In-Reply-To: <3A585C13.DB2CCA73@ericsson.com.au> References: <4.3.1.0.20010102141723.01ce4cb8@sigma.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu At 11:07 PM 01/07/2001 +1100, Ian Rytina wrote: >Hi Bruce, > >Is this limited to CRTP ? It's not limited to CRTP. It's a general PPP transport. >I assume we would want other compression >schemes to be carried over AAL2. In that case, maybe the draft should >be draft-ietf-pppext-ppp-over-aal2-00.txt Yes it should. I got the file name wrong in my email. Thanks, Bruce T >Regards, > >Ian. > > >Bruce A Thompson wrote: > > > I just wanted to summarize what I think we have agreed to do on the next draft of PPP over AAL2. > > > > Draft-buffam-avt-crtp-over-aal2-01.txt will be split into 2 different drafts. Draft-ietf-pppext-crtp-over-aal2-01.txt will be a subset of the current draft. It will describe the base encapsulation including CRC usage, usage of I.366.1, usage of Q.2630.2, and required UUI codepoints. This draft will allow the use of 1 or more AAL2 CIDs in an implementation of CRTP over AAL2. This document will also address the CRC issues brought up in the last thread on PPP over AAL2. > > > > A second draft will be written that will describe how multiple AAL2 CIDs can be used to perform LFI for PPP over AAL2 on low speed links. I don't know what the title of this draft will be. > > > > I still haven't gotten any official blessing that PPP over AAL2 has been accepted as a working group item in PPPEXT. Does anyone know the procedure for this? I need to get this draft accepted as a working group item in PPPEXT before the next IETF mtg so work supporting this effort can get underway in the ITU. > > > > Bruce T > > Bruce Thompson > > Cisco Systems > > email: brucet@cisco.com > > office: (408)527-0446 > > home office: (408)868-0112 > > San Jose, CA Bruce Thompson Cisco Systems email: brucet@cisco.com office: (408)527-0446 home office: (408)868-0112 San Jose, CA From owner-ietf-ppp-outgoing@merit.edu Fri Jan 12 14:39:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15860 for ; Fri, 12 Jan 2001 14:39:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFD265DD93; Fri, 12 Jan 2001 14:39:24 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9DDAE5DDC0; Fri, 12 Jan 2001 14:39:24 -0500 (EST) Received: from mu.egroups.com (unknown [64.211.240.238]) by segue.merit.edu (Postfix) with SMTP id 230285DD98 for ; Fri, 12 Jan 2001 14:39:22 -0500 (EST) X-eGroups-Return: michael.koller@acterna.com Received: from [10.1.10.108] by mu.egroups.com with NNFMP; 12 Jan 2001 19:39:16 -0000 Date: Fri, 12 Jan 2001 19:39:11 -0000 From: "Michael Koller" To: ietf-ppp@merit.edu Subject: IPCP Option Required? Message-ID: <93nmgv+68ai@eGroups.com> User-Agent: eGroups-EW/0.82 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: eGroups Message Poster X-Originating-IP: 157.234.250.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Does anyone know if it is necessary to include an option when performing IPCP negotiation? Thanks. From owner-ietf-ppp-outgoing@merit.edu Fri Jan 12 14:44:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15968 for ; Fri, 12 Jan 2001 14:44:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D27C5DDE4; Fri, 12 Jan 2001 14:44:12 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1AA935DDC5; Fri, 12 Jan 2001 14:44:12 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id A3F605DD98 for ; Fri, 12 Jan 2001 14:44:10 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id f0CJhsD23614; Fri, 12 Jan 2001 14:43:54 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14943.24185.582336.22588@h006008986325.ne.mediaone.net> Date: Fri, 12 Jan 2001 14:43:53 -0500 (EST) To: "Michael Koller" Cc: ietf-ppp@merit.edu Subject: Re: IPCP Option Required? In-Reply-To: Michael Koller's message of 12 January 2001 19:39:11 References: <93nmgv+68ai@eGroups.com> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Michael Koller writes: > Does anyone know if it is necessary to include an option when > performing IPCP negotiation? Thanks. No, it's an option. However, see RFC 1547 for the reason this option was put into PPP. When you don't negotiate the addresses, you end up operating the way SLIP once did. It's far too easy to misconfigure the endpoints and end up with an unusable link (at best) or a complete disaster (forwarding loops and black holes). There are folks doing things with Mobile IP (see IS-835) where the IPCP IP-Address option isn't used, but in general I think you need a *really* compelling reason before you decide not to implement it. (And I'm not sure I believe the aforementioned folks are necessarily correct.) -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Jan 12 16:04:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24039 for ; Fri, 12 Jan 2001 16:04:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C8285DE8A; Fri, 12 Jan 2001 16:02:32 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A66E5DE89; Fri, 12 Jan 2001 16:02:32 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id 74DC05DE7D for ; Fri, 12 Jan 2001 16:02:30 -0500 (EST) Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA27502 for ; Fri, 12 Jan 2001 16:02:29 -0500 (EST) Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id QAA27493; Fri, 12 Jan 2001 16:02:29 -0500 (EST) Received: from md7102notes01.ins.lucent.com (md7102notes01.ins.lucent.com [135.114.92.192]) by homail.ho.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA04081; Fri, 12 Jan 2001 16:02:17 -0500 (EST) From: nn4@lucent.com Subject: Re: IPCP Option Required? To: James Carlson Cc: ietf-ppp@merit.edu Date: Fri, 12 Jan 2001 15:59:30 -0500 Message-ID: X-MIMETrack: Serialize by Router on Notes01/SVR/Yurie(Release 5.0.4 |June 8, 2000) at 01/12/2001 15:59:31 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu There are some DSL providers giving static IP addresses. If they use PPPoE to negotiate a session, and authentication determines a user, probably IPCP IP-Address could be avoided. But in this case the client and server have (though ppp does not have a client-server relationship, PPPoE has a client-server relationship, so I just use that way), apriori has an understanding of a common IP address. Maybe this be could a valid scenario of not using IPCP-IP address option or even if a static address is used, are the peers expected to negotiate it ? Thanks Naga James Carlson @merit.edu on 01/12/2001 02:43:53 PM Sent by: owner-ietf-ppp@merit.edu To: "Michael Koller" cc: ietf-ppp@merit.edu Subject: Re: IPCP Option Required? There are folks doing things with Mobile IP (see IS-835) where the IPCP IP-Address option isn't used, but in general I think you need a *really* compelling reason before you decide not to implement it. (And I'm not sure I believe the aforementioned folks are necessarily correct.) From owner-ietf-ppp-outgoing@merit.edu Fri Jan 12 16:12:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24629 for ; Fri, 12 Jan 2001 16:11:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF6DB5DF6D; Fri, 12 Jan 2001 16:09:57 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF37C5DF6B; Fri, 12 Jan 2001 16:09:57 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 15D3E5DF69 for ; Fri, 12 Jan 2001 16:09:55 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id f0CL9r615300; Fri, 12 Jan 2001 16:09:53 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14943.29345.2281.136980@h006008986325.ne.mediaone.net> Date: Fri, 12 Jan 2001 16:09:52 -0500 (EST) To: nn4@lucent.com Cc: ietf-ppp@merit.edu Subject: Re: IPCP Option Required? In-Reply-To: nn4@lucent.com's message of 12 January 2001 15:59:30 References: X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit nn4@lucent.com writes: > There are some DSL providers giving static IP addresses. OK. > If they use PPPoE to negotiate a session, and authentication determines > a user, probably IPCP IP-Address could be avoided. Why should it be? If it is avoided, then you are requiring that user to statically configure his IP address, and you're not checking for errors. Is that a good thing? Are the DSL customers all savvy enough to do this right every time? > But in this case the client and server have (though ppp does > not have a client-server relationship, PPPoE has a client-server > relationship, so I just use that way), apriori has an understanding of > a common IP address. Yes, as I said before, that's how things were done in the past with SLIP. That isn't a good thing. > Maybe this be could a valid scenario of not using IPCP-IP address option > or even if a static address is used, are the peers expected to negotiate it > ? I would strongly recommend that the peers still negotiate the endpoint addresses using the IPCP IP-Address option, even if the addresses are well known. And even if the addresses are configured on both ends of the link. The intent of the IPCP IP-Address option is *not* to assign addresses, though that's certainly the way it's commonly used. The intent is to avoid the kinds of broken configurations (and horrible text-based kludges) that were once common with SLIP. If you want to avoid IPCP IP-Address, you really should have a *compelling* need to do so. The only one I can think of is that you simply do not have access to any address because you're doing some kind of funky bridging. (Even then, I'd strongly recommend sending IPCP IP-Address with 0.0.0.0 just to see if the peer knows your address and will be so polite as to inform you.) -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Fri Jan 12 18:51:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27000 for ; Fri, 12 Jan 2001 18:51:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD5875DDCC; Fri, 12 Jan 2001 18:50:56 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C21D15DDD2; Fri, 12 Jan 2001 18:50:56 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 5D2D65DDCC for ; Fri, 12 Jan 2001 18:50:55 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id f0CNos201171 for ietf-ppp@merit.edu env-from ; Fri, 12 Jan 2001 16:50:54 -0700 (MST) Date: Fri, 12 Jan 2001 16:50:54 -0700 (MST) From: Vernon Schryver Message-Id: <200101122350.f0CNos201171@calcite.rhyolite.com> To: ietf-ppp@merit.edu Subject: Re: IPCP Option Required? Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: James Carlson > ... > > But in this case the client and server have (though ppp does > > not have a client-server relationship, PPPoE has a client-server > > relationship, so I just use that way), apriori has an understanding of > > a common IP address. > > Yes, as I said before, that's how things were done in the past with > SLIP. That isn't a good thing. That's a gross understatement, particularly when you compare the average SLIP user of 1986 with the average DSL user 15 years later. > ... > The intent of the IPCP IP-Address option is *not* to assign addresses, > though that's certainly the way it's commonly used. The intent is to > avoid the kinds of broken configurations (and horrible text-based > kludges) that were once common with SLIP. > .. It's sad that the IETF has almost lost the institutional memory of why IPCP exists. It's even sadder when you stop to realize that this stuff is all written down in more than one or two places. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Jan 16 13:03:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17819 for ; Tue, 16 Jan 2001 13:03:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id E71575DEA3; Tue, 16 Jan 2001 12:58:07 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5E2655E054; Tue, 16 Jan 2001 12:58:02 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id A5AC75DF24 for ; Tue, 16 Jan 2001 12:52:49 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id f0GHqhW13596 env-from ; Tue, 16 Jan 2001 10:52:43 -0700 (MST) Date: Tue, 16 Jan 2001 10:52:43 -0700 (MST) From: Vernon Schryver Message-Id: <200101161752.f0GHqhW13596@calcite.rhyolite.com> To: iab@isi.edu, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: re-chartering L2TP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: "W. Mark Townsley" > ... > > > Are you any more clued into the "committee minutia" and such at present? > > > Are you any less surprised to hear yourself commenting on it now? > > > > That sounds like a misleading statement in the sense that it implies > > that I did express an opinion on the charter last summer. I really > > don't think I did. > > This was not a statement, it was a question. Regardless of what you did > last summer (this sounds like a bad movie already) you were shocked that > you would have made comment on charter minutia at that time based on > your admitted lurking position in this group. I am curious as to why now > is any different than then. You either don't know yourself any better > now than you did then, or you are paying attention to this group's > actions more. That is an intentionally misleading statement. I did not express shock at having previously commented on the charter, but instead politely pointed out that I had not made such comments. Moreover, as we all know, "lurking" does not mean "ignoring," but instead denotes "quietly listening." If modifications to the charter of the L2TP working group were minor or required only to complete its work, they would be reasonable and in my personal view not worth arguing or even talking about. However, making the working group a permanent fixture, or more accurately, a permanently available rubber stamp for proprietary technically bad ideas are something else. As far as I can tell, Mr. Townsley has tried to substantially modify the charter of this working group without obtaining the consensus of mailing list. Contrary to his recent statement in another message, a passing reference to mention of a change in charter in IETF meeting minutes does not constitute a call for comments on such a change. I don't think he meant to do anything bad with the charter and I think he really believes that the group should last forever to handle tunneling anything over anything. I think that would conflict with the charters of other groups, but even if I'm wrong, it is a substantial enough change to require consideration by the rest of the IETF. Where are the words of the new charter, since it is now only proposed and no longer a fait accompli? > > > "L2" originally came from L2F, which (From RFC2341) referred to L2 as, > > > "link layer (i.e., HDLC, > > > async HDLC, or SLIP frames)." > > > > That is a misleading statement of the history of the working group as I > > recall it. The "L2" in the group's name came from the Cisco protocol, > > not from the reason Cisco named the protocol. The group was not created > > to deal with arbitrary L2 packets or protocols, but instead was created > > to deal with the multi-chassis problem. > > The group was created to merge PPTP and L2F. The multi-chassis problem > was *one* of the motivations for L2F at cisco. The multichassis problem > certainly was not the widest use of PPTP at the time. That is a red herring. PPTP is still not widely used to handle the multichassis problem. Contrary to Mr. Townsley's implication and to what I recall of his expressed preferneces over the years, the L2TP group was not chartered to be a general purpose tunnelling group, handling not only the tunneling of arbitrary layer 2 packets over IP as in the current issue, but arbitrary packets over other arbitrary layers. > > > if we have created something that can be built > > > upon, I see no good reason to start from scratch elsewhere. > > > > Protocols such as the lastest bad idea that has nothing to do with > > PPP are not building on L2TP. > > I think an open mind is a better route to take. That said, I see very > well crafted arguments in favor of using existing protocols (BCP and PPP > with L2TP) for the Ethernet over L2TP case. I prefer this type of > discussion in the group vs. a closed, "we only do PPP, go away if you > don't like it" approach. Such "we only do PPP" arguments are appropriate. IETF working groups are not supposed to become permanent fiefdoms nor universal solvents. They are supposed to do their chartered jobs and finish. The many years this working group required to approach its chartered goal and the continuing technically bad ideas such as the current one are good reasons to disband the working group sooner than later. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Jan 16 15:11:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20820 for ; Tue, 16 Jan 2001 15:11:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 499415DDFC; Tue, 16 Jan 2001 15:06:59 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A91285E114; Tue, 16 Jan 2001 14:59:03 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id 73CD55DEE2 for ; Tue, 16 Jan 2001 14:51:38 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id f0GJpWj15435 env-from ; Tue, 16 Jan 2001 12:51:32 -0700 (MST) Date: Tue, 16 Jan 2001 12:51:32 -0700 (MST) From: Vernon Schryver Message-Id: <200101161951.f0GJpWj15435@calcite.rhyolite.com> To: iab@isi.edu, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu > From: Danny McPherson > ... > > If modifications to the charter of the L2TP working group were minor > > or required only to complete its work, they would be reasonable and > > in my personal view not worth arguing or even talking about. However, > > making the working group a permanent fixture, or more accurately, a > > permanently available rubber stamp for proprietary technically bad > > ideas are something else. > > Where was this proposed? Until the recent proposal of a brand new Ethernet/IP tunneling protocol, I had assumed that changes to the charter were nominal. Judging from the reception of latest bad idea, my assumption was wrong, and so I'd like to see exactly what the proposed charter changes are. Does the new charter justify considering this Ethernet/IP tunneling protocol? I've been trying to get to the archive at http://www.ipsec.org/email/l2tp/ for some time, but it won't answer me. > ... > > Where are the words of the new charter, since it is now only proposed > > and no longer a fait accompli? > > Perhaps I'm confused, but how does sending an email to the > WG mailing list with the words ***Potential new charter*** > in the subject line constitute this 'stealth' behavior you're > alluding to. Let's assume for the sake of argument that I'm wrong and that there was nothing stealthy about the charter change. So let's look at the new charter and not just the tunneling protocols that it apparently justifies. > If your intent is to let it be know that you don't think > the work (i.e., tunneling of PDU types other than PPP via L2TP) > belongs in L2TP, I think you've succeeded in voicing YOUR > opinion. Do you think that the rest of the IETF or even just the PPP WG knows about the plans to have L2TP own all tunneling protocols or that they approve? I don't. It's past time for the L2TP group to finish. This latest Ethernet/IP tunneling issue is a classic example of why permanent WG's are dangerous. It is also why there is so much politicing on charters in all standards committees. The IEEE 100BASE-T vs. 100VG-AnyLAN issue on which reputations were wrecked that I mentioned before involved the IEEE equivalent of WG charters. That's not to say that things as bad are involved here but to point out that charters, PAR's, agendas and similar are where the most dangerous and often most indefensible political stuff happens. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Jan 16 15:40:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21254 for ; Tue, 16 Jan 2001 15:40:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A9AF5DE48; Tue, 16 Jan 2001 15:38:35 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A9F2F5DF2E; Tue, 16 Jan 2001 15:28:51 -0500 (EST) Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3]) by segue.merit.edu (Postfix) with ESMTP id A7A235DF30 for ; Tue, 16 Jan 2001 15:20:36 -0500 (EST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.1/8.11.1) id f0GKKUk15996 env-from ; Tue, 16 Jan 2001 13:20:30 -0700 (MST) Date: Tue, 16 Jan 2001 13:20:30 -0700 (MST) From: Vernon Schryver Message-Id: <200101162020.f0GKKUk15996@calcite.rhyolite.com> To: iab@isi.edu, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Please note that I did not invent the stealth charter change complaint. That the L2TP charter is being changed was pointed out to me privately by someone who had noticed the passing reference and thought it at best obscure. > From: "W. Mark Townsley" > ... > Rechartering to include a standard manner for extension of L2TP for > other transport types very well may extend its life, but does not > necessarily make it a permanent fixture. There will be no rubber stamps > in this group. On the contrary, the reception of the latest bad idea of Ethernet over IP has been a rubber stamp resisted only by Mr. Carlson's efforts. I'm sorry to keep saying "bad idea of Ethernet/IP" for the pain that doubtless causes. However, it is an unfortunate idea based on a lack of knowledge of both theoretical and deployed alternatives and of how actual PPP and L2TP systems work. That it should not have received the currency given by the L2TP WG is my intended point. > ... If you want to > talk rubber stamps, let's compare this to an individual submission that > gets an Informational RFC number with substantially less chance for > review. That's a red herring, particularly in view of my excessively repeated and longstanding complaints about that problem in forums where such complaints are less irrelevant than here. > My goal is to provide a forum for open discussion and technical review > for items relevant to L2TP. The original and current charter includes: > "Define and review the definition of any additional IETF AVPs which are > of interest to the group." So far, the drafts for other L2 types that > have been accepted into the group have added nothing more than > additional AVPs to the protocol. No new messages, no change to the state > machine, no change to the L2TP header, etc. In fact, at the Pittsburgh > meeting I was adamant about keeping the scope of the work to within this > range of extension. I believe the meeting synopsis reflects this. Let's take the next step and start to shut down the WG. > ... > That is why the IESG must approve the charter change. It is also why I > have already discussed this at length with one of our AD. I do not think > that the IESG will approve anything that will cause undue overlap of > engineering effort among the various groups. If this work is being done > elsewhere in the IETF, I will be more than happy to combine forces or > step aside if it will result in less code for all of us to write, deploy > and maintain. > ... > > Where are the words of the new charter, since it is now only proposed > > and no longer a fait accompli? > > Check the archive, I posted it just recently. I've been trying for a while, but have failed to get any packets from www.ipsec.org, not to mention joy from http://www.ipsec.org/email/l2tp/ > ... > > The many years this working group required to approach its chartered > > goal and the continuing technically bad ideas such as the current > > one are good reasons to disband the working group sooner than later. > > The alternative? No standard for what is now a highly deployed technique > for access on the Internet (that is, tunneling of PPP). ... That is an argument for shutting down the L2TP WG, not continuing it. Anything that is "a highly deployed technique" leaves no room for the IETF to do more document current practice. After documenting it, it might be appropriate to figure out a better replacement, but only after fully documenting and understanding the status quo. Instead the L2TP WG is charging off to generate replacements (plural) without considering that "highly deployed technique." > In fact, the WG probably stumbled in the past by NOT being more > open-minded. We completely disagree. > Experience tells me that thinking the WG has the power to > reduce writing of and deployment of code by telling people to "go away" > does not reduce the code I ultimately have to write and the number of > standards I have to support for essentially the same thing. Experience tells me that a WG has little or no effect on such things. The IETF and any WG is almost powerless to stop bad ideas. It's power is in promoting, not opposing. > ... > I think we have spent enough of everyone's time on this thread now. I > hope that it at least served the purpose for people understanding where > I am trying to lead this group. Feel free to disagree, but from this > point on I ask you to take it to the next level rather than waste more > of our time here. Given the lack of discussion in the WG mailing list on the de facto new charter that seems to cover tunneling anything over anything, I object to your effort to prevent consideration of it. Ignoring my ranting, so far only those who favor making the L2TP working group a permanent fixture in charge of all tunnelling in the IETF have spoken about the de facto charter. Vernon Schryver vjs@rhyolite.com From owner-ietf-ppp-outgoing@merit.edu Tue Jan 16 15:42:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21271 for ; Tue, 16 Jan 2001 15:42:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 99E135DDD9; Tue, 16 Jan 2001 15:40:14 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D03175DEB8; Tue, 16 Jan 2001 15:33:19 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id BD0C55DFC0 for ; Tue, 16 Jan 2001 15:23:52 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29884; Tue, 16 Jan 2001 12:23:38 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA12212; Tue, 16 Jan 2001 15:23:37 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0GKNvr31719; Tue, 16 Jan 2001 15:23:57 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14948.44508.787858.42895@gargle.gargle.HOWL> Date: Tue, 16 Jan 2001 15:23:56 -0500 (EST) From: James Carlson To: Vernon Schryver Cc: iab@isi.edu, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: Vernon Schryver's message of 16 January 2001 12:51:32 References: <200101161951.f0GJpWj15435@calcite.rhyolite.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Vernon Schryver writes: > Does the new charter justify considering this Ethernet/IP tunneling protocol? > I've been trying to get to the archive at http://www.ipsec.org/email/l2tp/ > for some time, but it won't answer me. The archives are at http://www.l2tp.net/. The archive location changed sometime around November 1999, but was not updated in the IETF documents. (Yes, I was also caught off guard by this change.) http://www.ietf.org/html.charters/l2tpext-charter.html -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Jan 17 20:41:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01126 for ; Wed, 17 Jan 2001 20:41:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 90B835DD9F; Wed, 17 Jan 2001 20:41:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7782A5DDE4; Wed, 17 Jan 2001 20:41:03 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 0E7925DD9F for ; Wed, 17 Jan 2001 20:41:02 -0500 (EST) Received: from luo-u10.cisco.com (luo-u10.cisco.com [171.69.71.113]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA03245; Wed, 17 Jan 2001 17:40:43 -0800 (PST) Date: Wed, 17 Jan 2001 17:40:29 -0800 (PST) From: Wei Luo To: Danny McPherson Cc: Pat.Calhoun@eng.sun.com, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: <200101170102.SAA24215@tcb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Just FYI: there does seem to have some kind of overlapping between the newly proposed L2TP charter and CEOT charter description. http://www.ietf.org/ietf/00dec/ceot-agenda.txt ---Wei On Tue, 16 Jan 2001, Danny McPherson wrote: > > > I think that we should be held more accountable for our work items, and > > we should have to justify adding "duplicate" work. > > Note that the only 'questionable duplication' is that of > EoL2TP versus L2TP/PPP/BCP. Even Mark's agreed that this > is indeed questionable, and as such, the associated merits > are still being debated on the mailing list. The EoL2TP > draft was merged with my original L2TP ES draft in order > to provide a common model for other payload types in L2TP, > hence the birth of the Service Type AVP. > > Other work along these lines that employs the Service Type > (e.g., FR & ATM over L2TP) are not being duplicated (with > IP-based tunneling -- to my knowledge). > > I guess part of the misunderstanding here lies on my > shoulders, as I've promised to make the related I-Ds > available by now, and have yet to do so. I've ran them > by some folks already, though I haven't officially posted > them as of yet, and their availability is perhaps > germane to this discussion. > > > -danny > From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 02:12:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20453 for ; Thu, 18 Jan 2001 02:12:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D1285DE20; Thu, 18 Jan 2001 02:11:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 39E335DE0E; Thu, 18 Jan 2001 02:11:58 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id BB0B65DD91 for ; Thu, 18 Jan 2001 02:11:56 -0500 (EST) Received: from luo-u10.cisco.com (luo-u10.cisco.com [171.69.71.113]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id XAA05353; Wed, 17 Jan 2001 23:11:38 -0800 (PST) Date: Wed, 17 Jan 2001 23:11:24 -0800 (PST) From: Wei Luo To: Danny McPherson Cc: "W. Mark Townsley" , iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: <200101180258.TAA06066@tcb.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu If that's the intent of CEOT, it sounds quite reasonable. I doubted that trying to unite any transport over packet oriented network in a single WG was a realistic thing to do. ---Wei On Wed, 17 Jan 2001, Danny McPherson wrote: > > And it was explicitly stated in the during the BOF session > that the intention was to specify requirement that should > be given to the relevant "encapsulation" protocols (e.g., > MPLS, L2TP) and the encapsulation protocol-specific work > should be conducted in those working groups. > > I believe the CEOT BOF minutes reflect this. > > -danny > > > As for tunneling mechanisms, the BOF charter speaks these as follows: > > > > The protocols used for tunnel management depend on the type of packet > > switch network deployed by the carrier. For example, LDP or RSVP-TE > > may be used to create and manage tunnels across a packet switched > From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 06:35:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22042 for ; Thu, 18 Jan 2001 06:35:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id C75B05DE51; Thu, 18 Jan 2001 06:32:49 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A084A5DE5C; Thu, 18 Jan 2001 06:32:49 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A1D7C5DE51 for ; Thu, 18 Jan 2001 06:32:47 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA10694; Thu, 18 Jan 2001 03:32:36 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA22716; Thu, 18 Jan 2001 06:32:35 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0IBWt939580; Thu, 18 Jan 2001 06:32:55 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14950.54375.544578.637374@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 06:32:55 -0500 (EST) From: James Carlson To: "W. Mark Townsley" Cc: Wei Luo , Danny McPherson , Pat.Calhoun@eng.sun.com, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: W. Mark Townsley's message of 17 January 2001 21:23:27 References: <3A66539F.E0D62ED6@cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit W. Mark Townsley writes: > My personal view is that if the IETF decides to take on circuit > emulation, the new WG should operate in a transport agnostic manner to > identify requirements for emulation of various circuit types over any > given packet network (the most obvious examples of which are IP and > MPLS). These requirements should feed into various working groups (such > as mpls, l2tpext, diffserv, rsvp, etc.) to provide the necessary > modifications to existing protocols to best meet the requirements. MPLS runs over many things, including PPP. If the circuit emulation protocols are written to run over MPLS, then nothing special needs to be done for L2TP, because CES/MPLS/PPP/L2TP will work. Again, one mechanism and one specification are better than many. (Running CES over MPLS makes a lot of sense. MPLS is efficient and scalable enough to displace ATM as a core protocol, and translating current CES services into an IETF standard is one of the few remaining barriers to eliminating ATM.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 12:44:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29385 for ; Thu, 18 Jan 2001 12:44:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C8C65DE87; Thu, 18 Jan 2001 12:43:42 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 346975DE93; Thu, 18 Jan 2001 12:43:42 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id BCFD35DE87 for ; Thu, 18 Jan 2001 12:43:33 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01672; Thu, 18 Jan 2001 09:43:23 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA29923; Thu, 18 Jan 2001 12:43:22 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0IHhg540572; Thu, 18 Jan 2001 12:43:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.11086.187149.472886@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 12:43:42 -0500 (EST) From: James Carlson To: danny@ambernetworks.com Cc: "W. Mark Townsley" , Wei Luo , iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: Danny McPherson's message of 18 January 2001 10:02:21 References: <200101181702.KAA10463@tcb.net> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Danny McPherson writes: > > MPLS runs over many things, including PPP. If the circuit emulation > > protocols are written to run over MPLS, then nothing special needs to > > be done for L2TP, because CES/MPLS/PPP/L2TP will work. Again, one > > mechanism and one specification are better than many. > > One small observation -- this requires that MPLS be > deployed ubiquitously throughout the *Internet* (read: > inter-provider as well). I assure you, it won't be > any time soon. No, it doesn't necessarily require that at all. It may require some mechanisms for tunneling over the non-MPLS portions of the path. Such as, for instance, MPLS/PPP/L2TP. But, then again, it may not. Who is currently buying CES that crosses provider boundaries? Why would we think it's so much more likely to occur with CES over (pick an IETF protocol)? I think operational considerations -- such as being able to hold a single provider to a contracted set of performance parameters -- will be likely to trump any "ubiquity" argument. (Besides, the point here is to displace equipment that happens to carry legacy CES services, *not* to invent new reasons and ways to carry CES.) In all of the cases that I know of where real CES is used -- AAL-1 with fancy clock adjustment deltas to carry async timing across the network -- it's a kludge (such as voice over TDM rather than voice over IP) that may well disappear in the future. Finding extended uses for it seems like a poor optimization. (Note that frames != circuits, and tunneling AAL-5 or Frame Relay may be another matter entirely, although the contractual issues are likely similar.) > Folks that I see supporting IP-based CES (e.g., ATM, FR & > even TDM) can [typically] easily support MPLS-based models. > However, folks don't necessarily want solutions that require > MPLS today. Can you flesh out the service model that has interprovider CES over IP as an integral component? Frankly, I can't say that I've talked to any carrier that was interested in anything like that, and it's a little surprising to hear it as a fundamental requirement. Perhaps I wasn't paying enough attention during one of those presentations (or perhaps the answer is proprietary), but I'd still like to know. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 13:08:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00113 for ; Thu, 18 Jan 2001 13:08:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id C54AB5DF14; Thu, 18 Jan 2001 13:03:07 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A6A7E5DEBB; Thu, 18 Jan 2001 13:03:07 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 0F2F25DEA6 for ; Thu, 18 Jan 2001 13:01:46 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00218; Thu, 18 Jan 2001 10:01:42 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA11094; Thu, 18 Jan 2001 13:01:42 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0II22P40612; Thu, 18 Jan 2001 13:02:02 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.12185.941513.76303@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 13:02:01 -0500 (EST) From: James Carlson To: "W. Mark Townsley" Cc: Wei Luo , Danny McPherson , Pat.Calhoun@eng.sun.com, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: W. Mark Townsley's message of 18 January 2001 11:16:33 References: <3A66539F.E0D62ED6@cisco.com> <14950.54375.544578.637374@gargle.gargle.HOWL> <3A6716E1.E8A20880@cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit W. Mark Townsley writes: > By the same token, MPLS runs over IP. (I assume you mean that IP can over MPLS. MPLS, as far as I know, can't run directly over IP.) > So if CES is defined for IP > (perhaps via L2TP) then CES/L2TP/IP/MPLS will work. I don't know if that's doable. CES on ATM incurs one octet of overhead (for timing adjustment information) in each 48 octet cell. Running the same cells over L2TP/IP/MPLS will incur (at least) 10 (L2TP without length, but with Ns/Nr) + 8 (UDP) + 20 (IP) + 4 (one MPLS shim header) = 42 octets of overhead for every 47 (nominal) octets of data. Increasing the packet size will increase the buffering requirements at the endpoints and the resulting link latency (which is strictly controlled for telephony applications; see G.114). If it's a tiny proportion of the overall traffic (which is not an unfair assumption for future applications), 89%+ overhead might not matter. For some carriers, it might rule out the application entirely. > Also, for CES/MPLS/PPP/L2TP/IP work would have to be done to translate > QoS parameters from MPLS down to the tunneled IP later. We're not done > just because the layers stack up. Same with above, though a great deal > of work has already been done to perform traffic engineering of IP/MPLS. I agree the QoS issues get very interesting, but I disagree that this is significantly different from the trouble of getting *any* kind of PPP QoS over L2TP/IP. That's a mechanism that needs to exist in L2TP independently of what protocol(s) a tunneled PPP session is carrying, and regardless of anything that CES and MPLS might do. MPLS over PPP over regular wires *does* work for both TE and QoS, because the mechanisms are obvious enough. If L2TP/IP can provide the right features, MPLS/PPP/L2TP/IP is no harder to get right. Similarly, if for CES/L2TP/IP you assume into existence some communication between CES and L2TP to demand the right QoS for the link and then again between L2TP and IP, then that same mechanism will work for MPLS/PPP/L2TP/IP. In other words, it's the same work either way. The only difference is in how the layers stack up, and what the resulting (in)efficiencies imply. -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 13:30:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00801 for ; Thu, 18 Jan 2001 13:30:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 661575DE7A; Thu, 18 Jan 2001 13:29:38 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4DF585DE6D; Thu, 18 Jan 2001 13:29:38 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B127C5DE5C for ; Thu, 18 Jan 2001 13:29:36 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAB20059; Thu, 18 Jan 2001 10:29:27 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18529; Thu, 18 Jan 2001 13:29:26 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0IITmt40681; Thu, 18 Jan 2001 13:29:48 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.13852.268297.795572@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 13:29:48 -0500 (EST) From: James Carlson To: danny@ambernetworks.com Cc: "W. Mark Townsley" , Wei Luo , iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: Danny McPherson's message of 18 January 2001 10:54:52 References: <200101181754.KAA13484@tcb.net> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Danny McPherson writes: > The problem here is that you're scoping CES to TDM, when > my intended representation of the term was meant to encompass > FR, PPP/cHDLC, ATM, Ethernet/802.n, even MPLS as well. Ah, ok. That's an interesting usage. I've only used "CES" to mean ATM Forum af-vtoa-0078.000, "Circuit Emulation Service Interoperability Specification Version 2.0," or something that functions in a very similar manner. That is to say, PDH circuits over some networking protocol. For Frame Relay, I suppose you're contemplating something like FRF.5 and FRF.8, and possibly FRF.10. I think that's doable. As noted much further below, I don't know that L2TP is the right home for this, but the general concept is certainly likely to be a worthwhile thing. (Consider that by having both MPLS<->ATM mechanical translation and FRF.8 translation defined, one could imagine a Frame Relay to MPLS/PPP/L2TP IWF fairly easily. Anything else will likely have to deal with the addressing issues from scratch.) I don't know what you mean by "PPP/cHDLC" (cHDLC?), but I think having multiple ways of putting PPP over L2TP would be a bad thing for the many reasons cited earlier. ATM over L2TP? I'm not sure what's meant by that. Something like the thoroughly dead CIF proposal? Or something else? What would be the need for this? MPLS and Ethernet, as already noted, already work over L2TP, because they both run fine over PPP. New standards for these aren't needed. > The inter-provider thing was simply an example, more so, > consider a network that hasn't or doesn't plan to either > deploy MPLS entirely to the edge, or perhaps at all. I don't happen to think that carriers are too religious about this. I don't think they care about pure IP versus IP/MPLS, nor about where the "edge" boundary is drawn. What matters is what solves the problem well and what the vendors (such as Cisco) are selling. Also, with the likely practice of bandwidth reselling [leading to interesting arbitrage situations], MPLS or something very like it *will* go to the edge of many, if not all, carrier's networks. > > Perhaps I > > wasn't paying enough attention during one of those presentations (or > > perhaps the answer is proprietary), but I'd still like to know. > > The primary application for IP (or MPLS) CES (C representing either > TDM or packet-based stuff) is to allow SPs to converge their services > onto a single core IP or IP/MPLS core network. The benefits of this > are obvious (I believe). Yes. However, that doesn't necessarily involve any xES over IP operation, nor does it say that provider boundaries must be handled, nor does it say that requiring MPLS as a part of the replacement story for CES providers is necessarily a bad answer. MPLS is used in the core now and is quite likely to spread as its services are needed. With the new definition of CES to include frame-based stuff, I can see a definite need to define ways to encapsulate it over IP. It's not as immediately obvious to me that L2TP is the absolute right answer, but it's also not obivous that it's entirely wrong. (As I think it is for traditional CES.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 16:06:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05432 for ; Thu, 18 Jan 2001 16:06:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id D54805E59B; Thu, 18 Jan 2001 15:37:29 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E945F5DF0E; Thu, 18 Jan 2001 15:13:42 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 242A05DF7A for ; Thu, 18 Jan 2001 14:56:43 -0500 (EST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18379; Thu, 18 Jan 2001 11:56:36 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06955; Thu, 18 Jan 2001 14:56:35 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0IJuuh40967; Thu, 18 Jan 2001 14:56:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.19080.370300.32021@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 14:56:56 -0500 (EST) From: James Carlson To: "W. Mark Townsley" Cc: Wei Luo , Danny McPherson , Pat.Calhoun@eng.sun.com, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: W. Mark Townsley's message of 18 January 2001 14:03:47 References: <3A66539F.E0D62ED6@cisco.com> <14950.54375.544578.637374@gargle.gargle.HOWL> <3A6716E1.E8A20880@cisco.com> <14951.12185.941513.76303@gargle.gargle.HOWL> <3A673E13.6653BF62@cisco.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit W. Mark Townsley writes: > > If it's a tiny proportion of the overall traffic (which is not an > > unfair assumption for future applications), 89%+ overhead might not > > matter. For some carriers, it might rule out the application > > entirely. > > You bring up a good point, but to say that because of this problem CES > over IP is intractable is a bit harsh. Perhaps. That's why I wrote "might rule out" rather than "would rule out." It would be a complex cost/benefit calculation for any carrier. (But, then, they're good at that sort of thing.) > I imagine you can do some kind of > cell reassembly to combat the cell tax problem that you mention, but I > am not up on all of the details here. These are the type of requirements > that CEOT could document. Yes, that's something they would look into. (I don't think that's the solution, though, since CES includes special cases to forward with partly empty cells in order to minimize delay. If 47 bytes is sometimes too many, it doesn't bode well for larger amortizations.) > > I agree the QoS issues get very interesting, but I disagree that this > > is significantly different from the trouble of getting *any* kind of > > PPP QoS over L2TP/IP. That's a mechanism that needs to exist in L2TP > > independently of what protocol(s) a tunneled PPP session is carrying, > > and regardless of anything that CES and MPLS might do. > > We are talking > > CES QoS mapped to L2TP/IP and then to MPLS vs. > CES QoS mapped to MPLS and then to PPP/L2TP/IP ... which then very well > may be run over MPLS in parts of the core. Not exactly. For IP-only parts of the network, we're talking CES/MPLS/PPP/L2TP/IP. For MPLS parts of the network, a simple IWF should be able to reduce this stack on tunnel entry into CES/MPLS (with, perhaps, an extra label pushed to represent the tunnel, if necessary). (Labels are like indirection. One more level always fixes all the problems. ;-}) > > MPLS over PPP over regular wires *does* work for both TE and QoS, > > because the mechanisms are obvious enough. If L2TP/IP can provide the > > right features, MPLS/PPP/L2TP/IP is no harder to get right. > > This is certainly an intriguing thought. But, I don't think we can > overlook that this does require MPLS in at least one point, if not two, > in your stack. I am not sure I understand why, after all the work the > IETF has done to build a ubiquitos and interoperable IP network, it > would require that MPLS exist for all CES scenerios. Talk about charter > creep... I'm suggesting that we optimize only those things that are in need of optimization and ignore the others. ATM is entrenched in the core not because it's good for IP and not necessarily for the QoS pixie dust, but because it makes a dandy Frame Relay transport (using FRF.8 IWF) and can carry legacy point-to-point circuits with CES, and (secondarily) because its VPs can be traffic-engineered where needed. To remove ATM, we must supply something that does approximately as well on those legacy supports. The issue is in the "approximately" part. Perhaps CES on L2TP, as heavy as it may be, is light enough to do the job with 50% of the effective bandwidth wasted. Perhaps not. Perhaps the lack of TE on IP isn't a barrier. That's certainly not a job for this group to determine, and I hope some other group does consider it carefully. Thus, we have the situation that we're putting the cart before the horse. We don't know that we need this transport mechanism because the necessary engineering (protocol design and network design) haven't been done. Should we expand the L2TP charter to include transport of CES just on spec or should we wait for the real thing? > We could continue to take this argument to its extreme as well. Get rid > of IPCP, IPXCP, BCP, etc. and carry it all over MPLS/PPP and then L2TP > if need be. MPLSCP becomes the only NCP you need for PPP. Actually, of course, that's not quite true. You still need IP in parallel in order to do MPLS signaling. MPLS static configuration is possible, and perhaps even likely in engineered CES applications, but otherwise not practically so. As for the others, they have at least the advantage of primacy -- they were there before MPLS. There are also practical matters. Unlike PPP, which is fairly simple and involves only the two peers, MPLS signaling is non-trivial and relies on a far more complex suite of protocols, including internal SPF trees derived from IGP (OSPF or IS-IS) calculations, and the infamous LDP/RSVP duo. And, of course, MPLS implies forwarding based on labels and label stack manipulation. I don't think it's unreasonable to argue that running MPLS for the mere sake of supporting (say) IPX is too much burden, but that running PPP for the sake of supporting BCP is not. (On the other hand, if it were helpful, stealing well-known label values to transport unsupported network protocols over individual PPP links would be an amusing hack. :-/ No, please, don't run out and do this!) Note, also, that one could choose to run UDP over IP over IP over Ethernet all the time just to be perverse. I don't think arbitrary stackings need to be considered. > Or, simply > carry PPP over MPLS to handle the "MP" part of label switching. Then all > we need to define is ATMCP, FRCP, etc. for each circuit type. We could > stack layers in a number of ways. I agree that each time we define a > fork, we should have very good reason to do so as we multiply the number > of interfaces that we have to support between layers. Where the layers work naturally without having to create new specifications, it's probably not bad that the protocols are as promiscuous as they are. We probably should think long and hard before adding yet another stacking combination, though. > > In other words, it's the same work either way. The only difference is > > in how the layers stack up, and what the resulting (in)efficiencies > > imply. > > I'm not sure it is precisely the same work either way, but with regard > to layer stacking I very much agree with you here. I was referring to the QoS interface issue. In your example case, you need to have (conceptually, at least) CES ask L2TP for a contract, which asks UDP/IP, which then asks MPLS or some other link layer. In my example case, I need to have CES ask MPLS for a contract, which asks PPP, which asks L2TP, which asks UDP/IP, and the link layer. QoS interfaces for MPLS are defined (RSVP), and the interaction with PPP (for non-L2TP systems) is already in place. Further, PPP already needs a way to request QoS from L2TP (as it might for any physical layer), and this need is independent of MPLS. So, then the work required is to get QoS parameters in and out of L2TP, which happens to be the same work needed in your example case, and the work is stuff that's already needed. I call that a wash, at least on the QoS front. The other work is the CES over ? work. I believe, based on the Kill ATM argument, the really burning need is for CES over MPLS, not for CES over L2TP. Thus, the best leverage is to do CES over MPLS first, and then either tunnel or reuse for L2TP. The alternative would appear to be to do the work twice -- once for MPLS and again for L2TP. (But, again, this isn't the L2TP wg's issue.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 16:30:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05775 for ; Thu, 18 Jan 2001 16:30:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 758DD5DEB1; Thu, 18 Jan 2001 16:22:03 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9DA9A5DEE4; Thu, 18 Jan 2001 15:53:10 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 940B45E368 for ; Thu, 18 Jan 2001 15:31:01 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25201; Thu, 18 Jan 2001 12:30:54 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA20119; Thu, 18 Jan 2001 15:30:53 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0IKVFK41058; Thu, 18 Jan 2001 15:31:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.21138.754803.70213@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 15:31:14 -0500 (EST) From: James Carlson To: danny@ambernetworks.com Cc: "W. Mark Townsley" , Wei Luo , Pat.Calhoun@eng.sun.com, iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: Danny McPherson's message of 18 January 2001 13:08:21 References: <200101182008.NAA18103@tcb.net> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Danny McPherson writes: > > Yes, that's something they would look into. (I don't think that's the > > solution, though, since CES includes special cases to forward with > > partly empty cells in order to minimize delay. If 47 bytes is > > sometimes too many, it doesn't bode well for larger amortizations.) > > However, if implementation could realize things such as, for > example, idle frame suppression or AIS suppression, etc.., > there could be great bandwidth savings. If you're getting a lot of benefit out of AIS suppression, you've got some mighty unhappy users. ;-} That being said, I mostly agree with your points. It's a complex analysis to determine if it works. (Having tried the statistical gain argument with more than one bell-person, I'm not wild about trying it again. But, hey, I'm fortunately not in that game at this point.) (For the specific CES case, I don't know if idle suppression buys anything. If it's channelized, any one channel active ruins your day. If it's unstructured, I suppose you could *guess* at the upper level protocol used, but what if you're wrong ... ? Eh, not my forte anyway.) > Not to mention it's effecting on grooming in carrier networks, > and circuit provisioning times, etc... Grooming becomes, I think, a disaster on IP. Unless you do some really unnatural things to your IGP, you end up with no grooming capability at all. (Ross Callon has said, in what I interpret as a Fermat's-last-theorem sort of way [proof too large for this tiny margin], that TE with datagram routing only and no explicit routing is doable. Such things are possible, but they make my lesser brain spin.) In contrast, MPLS is perfect for TE applications and grooming. In fact, it's even better than ATM, since MPLS allows arbitrary label stacking, but ATM's "labels" (VPI and VCI) are fixed at two deep. You can arrange to push labels to represent groomed chucks of traffic and engineer them as needed across your network. (Which likely plays into why the carrier's I've talked to are so unimpressed with statistical gain.) -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Jan 18 17:01:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06034 for ; Thu, 18 Jan 2001 17:01:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 912DD5E173; Thu, 18 Jan 2001 16:35:40 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E15A5DF59; Thu, 18 Jan 2001 16:27:15 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 908C65DFCB for ; Thu, 18 Jan 2001 16:07:24 -0500 (EST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04209; Thu, 18 Jan 2001 13:07:21 -0800 (PST) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA00588; Thu, 18 Jan 2001 16:07:21 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.11.1+Sun/8.11.1) id f0IL7gj41137; Thu, 18 Jan 2001 16:07:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14951.23326.115528.752124@gargle.gargle.HOWL> Date: Thu, 18 Jan 2001 16:07:42 -0500 (EST) From: James Carlson To: danny@ambernetworks.com Cc: "W. Mark Townsley" , Wei Luo , iesg@ietf.org, ietf-ppp@merit.edu, l2tp@l2tp.net Subject: Re: re-chartering L2TP In-Reply-To: Danny McPherson's message of 18 January 2001 13:04:32 References: <200101182004.NAA17987@tcb.net> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Danny McPherson writes: > Yeah, I didn't mean to include that over L2TP, though folks > support PPP (and cHDLC - the Cisco variant) over MPLS with > the same general model (see the kompella or martini l2vpn > drafts). You're right in that L2TP wouldn't require any work > for PPP. Ah, ok. Cisco HDLC over L2TP makes some sense to me, in the same way that SLIP and ARAP over L2TP make sense to me. Assuming someone wants to support these old protocols, these are additions I'd certainly support. They're obviously in the spirit (if not letter) of the L2TP charter. > To get rid of an ATM core network. I beleive Kireeti does a > nice job of providing introductory text explaining "Why?" in > the first part of his MPLS l2vpn draft. It could either call > for raw cell transport or AAL5 PDUs. Most of the document deals with the transport of frames and reads like an IWF proposal. To that extent, I think it does the job right. The cell portion is only three sentences in section 5.4. I as good about that as I do about CIF. (Time will tell and perhaps I'm wrong, but this seems likely to me to be far too little specification to satisfy the folks who would want to use such a service.) > Then general model this > would be accomplished in L2TP is similar to those defined in > (again) the kompella and martini MPLS l2vpn drafts. I hope > to make the L2TP drafts available RSN. As I remarked before, I don't see the direction from a CES-related working group. If one is starting, shouldn't we take the requirements from them, rather than bubbling up requirements from the bottom? In other words, since most of the interesting hard parts are in CES rather than in the CES<->L2TP mapping, don't those drafts belong in a CES working group rather than in L2TP? > Though it won't be inter-provider anytime soon and folks that > want to offer multi-services (IP, FR, ATM, Etc..) nationally or > internationally and are tier-2 (or don't own their own transport > networks) can realize some very compelling savings when using > standard IP transport services, rather than a number of 'pipes" > for each service. Hmm. OK, assuming that nested model works for these non-IP services, I'll agree that Frame Relay over some kind of IP tunnel is a useful thing. As I said before, I don't see that L2TP is *the* right way to do this, but I'm certainly not as adamant in opposition as to EoL2TP. > There are advantages for TDM over packet-based networks as well, > though this is obviously even more challenging. Jim Boyle's STS > ES draft hints at this, and there are lots of vendors that are > beginning to suport proprietary solutions. And these solutions > employ IP, MPLS, or both, for transport, and often require things > like jitter buffers on linecards for reordering and/or replay, > etc.. It depends on the application. If the application happens to be just data, this shouldn't be too bad. A little latency isn't too awful. Voice folks get really nervous about delay really quickly, because it makes the service awkward to use and wrecks silly things like FAX (G.114 again). Voice coders have a lot of delay and tend to squeeze the margins awfully low. (After allowing for 5us/mile.) > There are more providers (tier-*) that haven't deployed MPLS > today (at all) than have, I assure you. As such, I'm not sure > what "core" you're referring to. Worldcom/UUnet, for one. I agree that it's early in the deployment phase, but (unlike, say, IPv6) it's an easy sell for most tier-1s and I've yet to talk to one that hasn't talked seriously about deploying MPLS. (Cisco's influence is noticable here.) I just fear we're headed toward a profusion of drafts that ends in *-over-* (which would be a good April 1st RFC). -- James Carlson, Internet Engineering SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Jan 29 13:02:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06881 for ; Mon, 29 Jan 2001 13:02:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3F7F5DFDE; Mon, 29 Jan 2001 12:56:53 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ABAD05DFED; Mon, 29 Jan 2001 12:56:53 -0500 (EST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by segue.merit.edu (Postfix) with SMTP id D6B0E5DFDE for ; Mon, 29 Jan 2001 12:56:47 -0500 (EST) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Jan 2001 09:53:52 -0800 (Pacific Standard Time) Received: from inet-imc-01.redmond.corp.microsoft.com ([157.54.9.101]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Sun, 28 Jan 2001 21:42:14 -0800 Received: from corp-hub-01.redmond.corp.microsoft.com ([157.54.2.41]) by na-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 19 Jan 2001 06:16:51 -0800 Received: from TVP-MSG-02.europe.corp.microsoft.com ([157.58.33.54]) by corp-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 19 Jan 2001 05:52:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.12 Subject: RE: re-chartering L2TP Date: Fri, 19 Jan 2001 05:52:24 -0800 Message-ID: <1ABFC3AB07C00B4891A9F324009CF4C018E8D2@TVP-MSG-02.europe.corp.microsoft.com> Thread-Topic: re-chartering L2TP Thread-Index: AcCBdl8NHVCB3csWRPizKql6yc33CwApkOig From: "Mark Jeffrey" To: "James Carlson" , Cc: "W. Mark Townsley" , "Wei Luo" , , , X-OriginalArrivalTime: 29 Jan 2001 05:42:14.0608 (UTC) FILETIME=[3BC34500:01C089B6] Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA06881 I'm concerned that the real QoS requirements of carrying a circuit (E.g. a European E1 2Mbit/s PDH) are not well understood by everyone here. There are strong requirements, not only for low latency (to deal with the familiar echo problems / avoid expensive echo cancellation requirements), but because the equipment attached to the circuit (e.g. a PBX) expects the E1 to behave within spec. If there is any significant jitter in the delay, PDH frame slips will occur. Enough of these (not very many) and the PBX will take the line out of service as faulty. QoS has to be solved in every layer underlying MPLS or you can't deliver it to the circuit. If you don't build the network for QoS control from the bottom up (as ATM did), you can't add it on the top as an extra. My 2c. Mark Jeffrey Senior Consultant / Network Architect Microsoft Consulting Services EMEA Telecom Practice Tel: (+44) 118 909 3787 Fax: (+44) 118 909 6761 mailto:markjeff@microsoft.com http://www.microsoft.com/UK/ > -----Original Message----- > From: James Carlson [mailto:james.d.carlson@east.sun.com] > Sent: 18 January 2001 17:44 > To: danny@ambernetworks.com > Cc: W. Mark Townsley; Wei Luo; iesg@ietf.org; ietf-ppp@merit.edu; > l2tp@l2tp.net > Subject: Re: re-chartering L2TP > > > Danny McPherson writes: > > > MPLS runs over many things, including PPP. If the > circuit emulation > > > protocols are written to run over MPLS, then nothing > special needs to > > > be done for L2TP, because CES/MPLS/PPP/L2TP will work. Again, one > > > mechanism and one specification are better than many. > > > > One small observation -- this requires that MPLS be > > deployed ubiquitously throughout the *Internet* (read: > > inter-provider as well). I assure you, it won't be > > any time soon. > > No, it doesn't necessarily require that at all. It may require some > mechanisms for tunneling over the non-MPLS portions of the path. Such > as, for instance, MPLS/PPP/L2TP. But, then again, it may not. > > Who is currently buying CES that crosses provider boundaries? Why > would we think it's so much more likely to occur with CES over (pick > an IETF protocol)? > > I think operational considerations -- such as being able to hold a > single provider to a contracted set of performance parameters -- will > be likely to trump any "ubiquity" argument. (Besides, the point here > is to displace equipment that happens to carry legacy CES services, > *not* to invent new reasons and ways to carry CES.) > > In all of the cases that I know of where real CES is used -- AAL-1 > with fancy clock adjustment deltas to carry async timing across the > network -- it's a kludge (such as voice over TDM rather than voice > over IP) that may well disappear in the future. Finding extended uses > for it seems like a poor optimization. (Note that frames != circuits, > and tunneling AAL-5 or Frame Relay may be another matter entirely, > although the contractual issues are likely similar.) > > > Folks that I see supporting IP-based CES (e.g., ATM, FR & > > even TDM) can [typically] easily support MPLS-based models. > > However, folks don't necessarily want solutions that require > > MPLS today. > > Can you flesh out the service model that has interprovider CES over IP > as an integral component? Frankly, I can't say that I've talked to > any carrier that was interested in anything like that, and it's a > little surprising to hear it as a fundamental requirement. Perhaps I > wasn't paying enough attention during one of those presentations (or > perhaps the answer is proprietary), but I'd still like to know. > > -- > James Carlson, Internet Engineering > > SUN Microsystems / 1 Network Drive 71.234W Vox +1 > 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 > 781 442 1677 > Second Edition now available - http://people.ne.mediaone.net/carlson/ppp