Subject: [L2tpext] I-D ACTION:draft-ietf-l2tpext-l2tp-base-04.txt

From: [email-masked]
Date: Fri, 08 Nov 2002 13:39:14 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF.

	Title		: Layer Two Tunneling Protocol (Version 3)'L2TPv3'
	Author(s)	: J. Lau, W. Townsley
	Filename	: draft-ietf-l2tpext-l2tp-base-04.txt
	Pages		: 80
	Date		: 2002-11-8
	
This document describes the Layer Two Tunneling Protocol (L2TP).
L2TP tunnels Layer 2 packets across an intervening network in a way
that is as transparent as possible to both end-users and
applications.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-l2tp-base-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-l2tpext-l2tp-base-04.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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-l2tpext-l2tp-base-04.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.

---

From: [email-masked]
Date: Mon, 11 Nov 2002 09:46:00 +0200

i noticed that this new version of l2tpv3 draft did include Application
ID AVP, but it didn't include an application specific value for
Result Code AVP.  

what is the reason for omitting application specific result code and
thus also application specific error codes?

-- juha

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: [email-masked]
Date: Mon, 11 Nov 2002 09:46:00 +0200

-- juha

---

From: Jed Lau <[email-masked]>
Date: Mon, 11 Nov 2002 01:01:39 -0800

Hi Juha,

Each application can still define its own set of Result Codes and Error Codes
(if applicable): "Additional service-specific Result Codes are defined outside
this document."  However, I don't think any application-specific codes should
be defined in the base draft.  We've tried to limit the Result and Error Codes
that are enumerated in the base draft to those that apply generally on a
protocol level.

Jed

---

From: Jed Lau <[email-masked]>
Date: Mon, 11 Nov 2002 01:01:39 -0800

Hi Juha,

Jed

---

From: [email-masked]
Date: Mon, 11 Nov 2002 11:41:55 +0200

Jed Lau writes:

 > Each application can still define its own set of Result Codes and
 > Error Codes (if applicable): "Additional service-specific Result
 > Codes are defined outside this document."  However, I don't think any
 > application-specific codes should be defined in the base draft.
 > We've tried to limit the Result and Error Codes that are enumerated
 > in the base draft to those that apply generally on a protocol level.

my proposal was to define a SINGLE application specific Result Code:

 0xXXXX Session disconnected for the application specific reason
         indicated in Error Code

and then the application rfc would define the application specific error
codes (if any).  

that way the application rfcs would never need to go to iana to ask for
any new result code or error code code points.

-- juha

---

From: [email-masked]
Date: Mon, 11 Nov 2002 11:41:55 +0200

-- juha

---

From: [email-masked]
Date: Mon, 11 Nov 2002 11:47:13 +0200

W. Mark Townsley writes:

 > It seems that you are suggesting the same for the Result and Error
 > codes, correct?

yes, see my previous reply.

-- juha

---

From: [email-masked]
Date: Mon, 11 Nov 2002 11:47:13 +0200

-- juha

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 11 Nov 2002 10:43:21 +0100

As with the Application ID, the question really boils down to attribute number 
space. The Application ID AVP effectively gives one the ability to define his 
own attribute number space and value format, outside of L2TP. One could argue 
that utilizing L2TP attribute number space and value format could work just as 
well, but that the extra indirection adds some flexibility, particularly if 
defining parameters for use across multiple tunneling protocols. It seems that 
you are suggesting the same for the Result and Error codes, correct?

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 11 Nov 2002 10:43:21 +0100

- Mark

---

From: Jed Lau <[email-masked]>
Date: Mon, 11 Nov 2002 02:03:52 -0800

> any new result code or error code code points.

Thanks for the clarification, Juha.  I understand your point now.  Even still,
I don't think application-specific issues should be logged as Error Codes.  The
draft states the following: "The Error Codes... pertain to types of errors that
are not specific to any particular L2TP request, but rather to protocol or
message format errors."  If you look at the currently defined list of Error
Codes, they are either basically all protocol issues, which apply generally. 
Payload-, service-, and/or application-specific issues are probably more
appropriately logged as Result Codes, which are more "specific to a particular
L2TP request".

Two side points: First, if we did just have one Result Code that indicated an
application-specific Error Code, would *every* application-specific reason that
resulted in sending a CDN be correctly labeled as an "error"?  Probably not,
which means that you'll need application-specific Result Codes anyway, i.e. to
describe those scenarios in which the session request is valid but simply
refused by the peer for the stated reason (or put differently, not an "error",
but simply a "result").  Second, even if it were only the Error Codes that were
enumerated in application-specific documents, wouldn't those Error Code number
assignments still need to be managed by IANA?

Thanks.

Jed

---

From: Jed Lau <[email-masked]>
Date: Mon, 11 Nov 2002 02:03:52 -0800

Thanks.

Jed

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 11 Nov 2002 11:07:31 +0100

> any new result code or error code code points.

Which is sort of the whole point of the Application ID. One trip to IANA per 
application, and ultimate flexibility within. As such, it makes sense that if we 
have the Application ID AVP at all, then we should have this new result code 
defined in the base draft as well. As I see it, either both or neither.

In general, the only real negative to the added indirection of the application 
ID that I feel worth pointing out is that the new freedom each application will 
have in formatting their AVPs may actually make code a little more difficult to 
write and interoperate in L2TP. I believe all of our L2TP implementations today 
likely have reasonably generic code such that adding/parsing new AVPs is as 
simple as including new entries in a table and a few extra lines of code. These 
routines produce AVPs have been tested with one another and create AVPs that are 
known to interoperate well. The application ID and result code, while adding 
additional levels of flexibility for information passing, does require that each 
implementation learn a particular application's way of formatting values which 
could vary largely from one application to the next. This flexibility is the 
whole point, but it could lead to more complex message formatting and 
potentially some associated interoperability hangups.

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 11 Nov 2002 11:07:31 +0100

- Mark

---

From: [email-masked]
Date: Mon, 11 Nov 2002 13:16:54 +0200

Jed Lau writes:

 > Even still, I don't think application-specific issues should be
 > logged as Error Codes.  The draft states the following: "The Error
 > Codes... pertain to types of errors that are not specific to any
 > particular L2TP request, but rather to protocol or message format
 > errors."  

in the examples i have given, application specific error codes specify
application specific protocol errors, e.g:

           <0x0001, "Requesting PE does not belong to the VPN">
           <0x0002, "Requested PE does not belong to the VPN">

but i'm not qualified to argue about the original intent of l2tp error
codes. 

what i'm saying is that it should be possible for an l2tp application
rfc to ask a single code point from iana, i.e., one for the application
id.  then the l2tp specification should include a means for that
application rfc to define application specific reason codes for session
termination without a need to ask new code points from iana.  

i don't really care how it is done, as long as the mechanism is there.
if my proposal to have this result code

is not a good one, then invent something that is better in line with the
intent of result and error codes.

 > Two side points: First, if we did just have one Result Code that
 > indicated an application-specific Error Code, would *every*
 > application-specific reason that resulted in sending a CDN be
 > correctly labeled as an "error"?  

no.  it would be possible to use any of the general result codes.

 > Probably not, which means that
 > you'll need application-specific Result Codes anyway, i.e. to
 > describe those scenarios in which the session request is valid but
 > simply refused by the peer for the stated reason (or put differently,
 > not an "error", but simply a "result").  

you may have a point there.  may be we would need a "reason code" in
place of "error code".

 > Second, even if it were only
 > the Error Codes that were enumerated in application-specific
 > documents, wouldn't those Error Code number assignments still need to
 > be managed by IANA?

no, if result code specifies "application specified reason", then the
"reason code" code points would have only meaning that is local to the
application.

-- juha

---

From: [email-masked]
Date: Mon, 11 Nov 2002 13:16:54 +0200

-- juha