Why 2 AVPs?

Just looking at draft-ietf-l2tpext-ds-05.txt and wondering why there are two
identical AVPs defined, since the only differences between them seem to be
semantic & they occur is disjunct sets of messages...

Re: Why 2 AVPs?

At one point, people wanted to have the session DS AVP carried in
control channel messages as well to indicate the specified DS value
should be applied to all sessions of the same control channel.  Whereas,
the control connection DS AVP is solely for the control channel. 
Therefore, there was a need to differentiate the two.  That idea didn't
fly too long however, but we left them as they are for clarity purpose.

---Wei

> -------- Original Message --------
> Subject: [L2tpext] Why 2 AVPs?
> Date: Wed, 5 Jun 2002 23:03:28 -0700
> From: "Glen Zorn" <gwz <at> cisco.com>
> Reply-To: <gwz <at> cisco.com>
> To: <l2tpext <at> ietf.org>
> 
> Just looking at draft-ietf-l2tpext-ds-05.txt and wondering why there are two
> identical AVPs defined, since the only differences between them seem to be
> semantic & they occur is disjunct sets of messages...
> 
> _______________________________________________
> L2tpext mailing list
> L2tpext <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/l2tpext

RE: Why 2 AVPs?

Wei Luo [mailto://luo <at> cisco.com] writes:

> At one point, people wanted to have the session DS AVP carried in
> control channel messages as well to indicate the specified DS value
> should be applied to all sessions of the same control channel.  Whereas,
> the control connection DS AVP is solely for the control channel.
> Therefore, there was a need to differentiate the two.  That idea didn't
> fly too long however, but we left them as they are for clarity purpose.

OK.  The reason I'm asking is that I'm working on an update to RFC 2868 that
includes a DS-related attribute, so the question is, should there be 1
attribute or 2?

>
> ---Wei
>
> > -------- Original Message --------
> > Subject: [L2tpext] Why 2 AVPs?
> > Date: Wed, 5 Jun 2002 23:03:28 -0700
> > From: "Glen Zorn" <gwz <at> cisco.com>
> > Reply-To: <gwz <at> cisco.com>
> > To: <l2tpext <at> ietf.org>
> >
> > Just looking at draft-ietf-l2tpext-ds-05.txt and wondering why
> there are two
> > identical AVPs defined, since the only differences between them
> seem to be
> > semantic & they occur is disjunct sets of messages...
> >
> > _______________________________________________

Re: Why 2 AVPs?

Probably two attributes, as RFC 2868 covers both tunnel and session
level attributes, isn't it?

---Wei

Glen Zorn wrote:
> 
> Wei Luo [mailto://luo <at> cisco.com] writes:
> 
> > At one point, people wanted to have the session DS AVP carried in
> > control channel messages as well to indicate the specified DS value
> > should be applied to all sessions of the same control channel.  Whereas,
> > the control connection DS AVP is solely for the control channel.
> > Therefore, there was a need to differentiate the two.  That idea didn't
> > fly too long however, but we left them as they are for clarity purpose.
> 
> OK.  The reason I'm asking is that I'm working on an update to RFC 2868 that
> includes a DS-related attribute, so the question is, should there be 1
> attribute or 2?
> 
> >
> > ---Wei
> >
> > > -------- Original Message --------
> > > Subject: [L2tpext] Why 2 AVPs?
> > > Date: Wed, 5 Jun 2002 23:03:28 -0700
> > > From: "Glen Zorn" <gwz <at> cisco.com>
> > > Reply-To: <gwz <at> cisco.com>
> > > To: <l2tpext <at> ietf.org>
> > >

Size packet in L2TP standard

Dear sirs/madams,

In our work team, we are researching about the standard L2TP (RFC 2661)
and we have observed a possible weakness about it we would like to
comment you about, if it could result interesting as an improvement to
deal with in the standard.

After some investigation, we have a doubt about the implementation of
the L2TP packet size management mechanism, as it seems not to be
included in the proposed drafts nowadays. In a more detalied way we
haven't found any L2TP mechanism which lets two L2TP extremes (LNS and
LAC) to interact to carry out the following:

- Negotiation about packet size sent through the tunnel.

- To indicate MTU or MRU at the user's side. We have only found in "L2TP
Link Extension" draft the possibility of negociating LCP options from
both extremes LAC and LNS; including the possibility that: firstly LAC
provides a maximum MRU value; secondly, LNS starts the negotiation with
that value and finally it could be reduced if it is necessary.

This function must be useful to avoid problems like the ones presented
when IP fragmentation (gathered in RFC 2661) is employed.

Trying to be helpful, best regards.

Re: Size packet in L2TP standard

"Francisco Javier Munnoz Calle (JVT)" wrote:
> 
> Dear sirs/madams,
> 
> In our work team, we are researching about the standard L2TP (RFC 2661)
> and we have observed a possible weakness about it we would like to
> comment you about, if it could result interesting as an improvement to
> deal with in the standard.
> 
> After some investigation, we have a doubt about the implementation of
> the L2TP packet size management mechanism, as it seems not to be
> included in the proposed drafts nowadays. In a more detalied way we
> haven't found any L2TP mechanism which lets two L2TP extremes (LNS and
> LAC) to interact to carry out the following:
> 
> - Negotiation about packet size sent through the tunnel.

There are a number of ways to negotiate or configure MTU sizes throughout a
network or at the end hosts, depending on where you are trying to make the
adjustment. For L2TP, the most general and straightforward is via PPP. If the
MTU (with appended L2TP/PPP headers) is known between the LAC and LNS, there are
two chances to negotiate this correctly. The PPP MRU option may be negotiated
first at the LAC, then again if LCP is renegotiated at the LNS. This is part of
RFC 2661, the "Link Extensions" draft you mentioned is not required.

When the MTU is not managed across the network in an ideal manner, a large PPP
MRU is expected by SLA at the client, or the PPP client is broken (sending PPP
packets larger than that which was negotiated), alternatives must be sought. In
these cases, either the connectivity between the LAC and LNS will need to

A Couple of Questions

I-D ACTION:draft-mistretta-l2tp-infomsg-00.txt

FYI.

>To: IETF-Announce:; <at> loki.ietf.org
>From: Internet-Drafts <at> ietf.org
>Subject: I-D ACTION:draft-mistretta-l2tp-infomsg-00.txt
>Date: Wed, 26 Jun 2002 06:42:09 -0400
>
>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: L2TP Call Information Messages
>	Author(s)	: T. Mistretta et al.
>	Filename	: draft-mistretta-l2tp-infomsg-00.txt
>	Pages		: 15
>	Date		: 25-Jun-02
>	
>This document defines additional L2TP AVPs to communicate
>informational ASCII text messages between the tunnel endpoints during
>call establishment. The message contents are not interpreted by the
>receiving endpoint in any way but can be used for logging or
>debugging purposes.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-mistretta-l2tp-infomsg-00.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-mistretta-l2tp-infomsg-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 <at> ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-mistretta-l2tp-infomsg-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.
>Content-Type: text/plain
>Content-ID:	<20020625141929.I-D <at> ietf.org>
>
>ENCODING mime
>FILE /internet-drafts/draft-mistretta-l2tp-infomsg-00.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-mistretta-l2tp-infomsg-00.txt>

I-D ACTION:draft-townsley-pwe3-l2tpv3-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Pseudowires and L2TPv3
	Author(s)	: W. Townsley
	Filename	: draft-townsley-pwe3-l2tpv3-00.txt
	Pages		: 18
	Date		: 26-Jun-02
	
This document provides an overview of the Layer 2 Tunneling Protocol
(L2TPv3), presented in a manner which highlights its applicability
for Pseudo Wire Emulation Edge to Edge (PWE3). It is intended as a
guide for architects, new implementers, and those adding
functionality to L2TPv3 in support of new pseudowire types.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-townsley-pwe3-l2tpv3-00.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-townsley-pwe3-l2tpv3-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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-townsley-pwe3-l2tpv3-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.

I-D ACTION:draft-ietf-l2tpext-atmext-rfc3301-bis-00.txt

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 : ATM Access Network 
                          Extensions
	Author(s)	: Y. T'Joens, B. Sales, P. Crivellari
	Filename	: draft-ietf-l2tpext-atmext-rfc3301-bis-00.txt
	Pages		: 18
	Date		: 26-Jun-02
	
L2TP [RFC2661] specifies a protocol for tunnelling PPP packets over
packet based networks and over IP networks in particular. L2TP
[RFC2661] supports remote access by ISDN and PSTN networks. This
document augments the procedures described in [RFC2661] to further
support ATM SVC or PVC based access networks. The extensions defined
within this document allow for asymmetric bi-directional call
establishment and service selection in the ATM access network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2tpext-atmext-rfc3301-bis-00.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-atmext-rfc3301-bis-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 <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-l2tpext-atmext-rfc3301-bis-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.