Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts

From: "Beadles, Mark A." <[email-masked]>
Date: Wed, 20 Jan 1999 15:43:28 -0500

From:	Aydin Edguer [SMTP:[email-masked]]
>UUnet/Worldcom/MCI may not be offering these services.  UUnet/Worldcom/MCI
>may not need to use tunneling protocols to offer these services.  But
>there are already other service providers who are and do.

<corporate mode>
Please do not confuse Mr. Barkley's opinions with the opinions or products
of MCI WorldCom.  MCI WorldCom Advanced Networks has been a sponsor of the
L2TP bakeoffs for the last year or so, and is on the board of the CIUG, the
primary group responsible for L2TP interoperability testing. MCI WorldCom
offers, among its many products and services, tunneling.  Mr. Barkley is
certainly entitled to his opinion, as am I, but please do not get the
impression that MCI WorldCom does not offer tunneling services or intend to
continue to do so.  
</corporate mode>

+ Mark Anthony Beadles + MCI WorldCom Advanced Networks +
+  [email-masked]   +        http://www.wcom.net     +
+  Voice 614.723.1941  +          Fax 614.723.8407      +

> -----Original Message-----
> From:	Aydin Edguer [SMTP:[email-masked]]
> Sent:	Tuesday, January 19, 1999 9:29 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: (radius) WG LAST CALL on L2TP RADIUS Drafts
> 
> Sender: [email-masked]
> Received: from bast.livingston.com (bast.livingston.com [149.198.247.2])
> 	by hil-img-1.compuserve.com (8.8.6/8.8.6/2.17) with ESMTP id
> VAA19733
> 	for <[email-masked]>; Tue, 19 Jan 1999 21:29:01 -0500
> (EST)
> Received: from server.livingston.com (server.livingston.com
> [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id
> SAA17653; Tue, 19 Jan 1999 18:25:22 -0800 (PST)
> Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9)
> id SAA20928 for ietf-radius-outgoing; Tue, 19 Jan 1999 18:27:43 -0800
> (PST)
> From: Aydin Edguer <[email-masked]>
> Message-Id: <[email-masked]>
> Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts
> To: [email-masked]
> Date: Tue, 19 Jan 1999 21:25:55 -0500 (EST)
> Cc: [email-masked]
> In-Reply-To: <[email-masked]>
> from "Stuart A Barkley" at Jan 19, 99 08:52:22 pm
> X-Mailer: ELM [version 2.4 PL23]
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
> Sender: [email-masked]
> Precedence: bulk
> Reply-To: Aydin Edguer <[email-masked]>
> 
> > > > My arguments against this set of extensions consist of 2 major
> areas:
> > > > 
> > > >  - having a meaningful purpose
> > > 
> > > FACT: The tunneling protocols exist
> > > FACT: The tunneling protocols are in active use
> > > FACT: There must be a method to configure equipment for said protocols
> > 
> > Actually the one in question doesn't exist yet.  Its existence is yet
> > to be determined (although I expect that it will eventually happen
> > despite my misgivings). 
> 
> While most of our discussions have been about L2TP, since that is the
> most recent work, when I said "tunneling protocols exist", I really
> did mean *exist* in already approved IETF informational documents and
> *existing* products.
> 
> Please see:
>   RFC 1701 "Generic Routing Encapsulation (GRE)"
>   RFC 2107 "Ascend Tunnel Management Protocol - ATMP"
>   RFC 1853 "IP in IP Tunneling",
>   RFC 2341 "Layer Two Forwarding (L2F)"
> 
> I also did mean *exist* in vendor implementations -
>   Point-to-Point Tunneling Protocol (PPTP)
>   Bay Dial Virtual Services (DVS)
> 
> These are all *existing* protocols that are in use and that can be
> configured on different vendor NASes.  I know that more than one NAS
> vendor was providing means to support compulsory tunneling using these
> protocols.  But until the RADIUS tunnel drafts, the configuration was
> done in different proprietary ways.  Therefore, these drafts serve
> a useful purpose by allowing vendor interoperability of *existing*
> functionality, even assuming that L2TP is not approved as a standard.
> 
> Furthermore, due to the large number of vendors with interoperable L2TP
> implementations, as evidenced by the interoperability workshops, even
> if the IETF refuses to approve the L2TP draft as a standards track
> document, it *will* be released to customers, and will probably be made
> an informational document.
> 
> > > Therefore, as long as said tunneling protocols are still being used,
> > > there is a meaningful purpose for supporting RADIUS configuration of
> > > tunneling.
> > 
> > Not if the protocols serve no purpose.  What I am requesting is some
> > understandable new useful purpose, not just "its good" or "it already
> > exists".
> 
> It is not my purpose to supply a reason - it is the service providers
> who provide multi-million dollar orders to vendors that supply the
> reason.  Since most service providers are not part of this mailing
> list, asking here is not very useful.  Especially when, as members
> of this list give *existing* uses by service providers, you say that
> they are not sufficient reasons.  They may not be sufficient reasons
> for you, but they are for the current users and those are the people
> who will be using the work.
> 
> We have service providers who are offering to outsource network access
> to corporations.  These corporations are using multiple protocols on
> the LAN.  They use local equipment on their network to provide the same
> support to dial-in clients.  They therefore require that the service
> provider provide matching functionality.
> 
> This is done using tunneling protocols.
> 
> Similarly, these corporations are using private addresses on their LAN.
> They use local equipment on their network to provide the same support to
> dial-in clients.  They therefore require that the service provider
> provide matching functionality.
> 
> This is done using tunneling protocols.
> 
> UUnet/Worldcom/MCI may not be offering these services.  UUnet/Worldcom/MCI
> may not need to use tunneling protocols to offer these services.  But
> there are already other service providers who are and do.
> 
> The fact that RADIUS-WG is chartered to try to work on functionality that
> already exists is a good reason for the RADIUS-WG to consider "it already
> exists" to be sufficient for us to try to put it down on paper in a
> vendor-independent way.
> 
> > > As long as we need to configure L2TP on a NAS for
> > > a Dial in User, we need the current RADIUS tunnel drafts.
> > 
> > In C:
> > 
> > if (need_L2TP) {
> >     do_lots_of_work();
> > }
> 
> if (need_L2TP || need_L2F || need_PPTP || need_GRE || need_IP-IP) {
>     configure_existing_implementation_in_a_standard_way();
> }
> 
> -
> To unsubscribe, email [email-masked]' with
> 'unsubscribe ietf-radius' in the body of the message.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Mike O'Dell" <[email-masked]>
Date: Wed, 20 Jan 1999 16:59:15 -0500

ah yes - it happens in the best of families....

please do not confuse WANS opinions with those of UUNET,
where we do not offer tunneling and don't intend to start

	-mo
-

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 21 Jan 1999 12:04:32 -0800

>where we do not offer tunneling and don't intend to start

Why is it that this statement reminds me of Mr Watson's (IBM founder)
near 1949, when he stated that "only 12 computers would be needed in
the whole world"... ?

-

---

From: "Mike O'Dell" <[email-masked]>
Date: Thu, 21 Jan 1999 16:52:09 -0500

i note that IBM did OK anyway....

-

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 21 Jan 1999 13:49:34 -0800

>i note that IBM did OK anyway....

Yep, and last time I checked, it sold more than 12 computers... :-)

-

---

From: Glen Clark <[email-masked]>
Date: Thu, 21 Jan 1999 14:16:39 -0800

>near 1949, when he stated that "only 12 computers would be needed in

Only 12 computers are needed in the whole world.  The rest are just
processor envy ;-)

-