From pppext-bounces@ietf.org Fri Nov 04 12:41:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5Yi-00036J-Au; Fri, 04 Nov 2005 12:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5Yf-00036B-L1 for pppext@megatron.ietf.org; Fri, 04 Nov 2005 12:40:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03617 for ; Fri, 4 Nov 2005 12:40:34 -0500 (EST) Received: from rt.icann.org ([192.0.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5nf-0005UW-0b for pppext@ietf.org; Fri, 04 Nov 2005 12:56:30 -0500 Received: from rt.icann.org (localhost.icann.org [127.0.0.1]) by rt.icann.org (8.13.1/8.13.1) with ESMTP id jA4Hetl5006670 for ; Fri, 4 Nov 2005 09:40:55 -0800 (PST) (envelope-from www@rt.icann.org) Received: (from www@localhost) by rt.icann.org (8.13.1/8.13.1/Submit) id jA4HetL8006669; Fri, 4 Nov 2005 09:40:55 -0800 (PST) (envelope-from www) Date: Fri, 4 Nov 2005 09:40:55 -0800 (PST) From: "Michelle Cotton via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.icann.org RT-Ticket: rt.icann.org #3528 Managed-by: RT 3.2.2 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org Cc: pppext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rt.icann.org id jA4Hetl5006670 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2d1100b36d83fed07afbc292d8848e10 Content-Transfer-Encoding: quoted-printable Subject: [Pppext] [rt.icann.org #3528] FW: General Request for Assignments (ppp-numbers) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Reply-To: iana-prot-param@icann.org List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org PPPEXT Working Group: We are resending this message as we have not yet seen a response. Thank you for your assistance. Michelle Cotton IANA > [michelle.cotton - Mon Oct 10 11:44:50 2005]: >=20 > PPPEXT Working Group: >=20 > This is a follow-up to a recent request you were reviewing for IANA. > The Working Group Chair requested that the group wanted to see the I- D=20 > before making a decision. Below, please find the I-D sent to IANA by=20 > the requestor. >=20 > We will await your response. >=20 > Thank you, >=20 > Michelle Cotton > IANA >=20 > **************************************************************** >=20 > As requested, please find the I-D about our PPP extension. It is=20 called=20 > "Quantum Key Destribution within Point to Point Protocol (Q3P)"=20 written=20 > by Solange Ghernaouti-H=C3=A9lie and Mohamed Ali Sfaxi. >=20 > > Network Working Group Solange Ghernaouti-H=C3=A9= lie > > INTERNET-DRAFT Mohamed Ali=20 > Sfaxi > > University=20 > of Lausanne > > Expires: April, 29 2006 =20 > October 2005=20 > >=20 > >=20 > >=20 > > Quantum Key Destribution within Point=20 > > to Point Protocol (Q3P) > > draft-ghernaouti-sfaxi-ppp-qkd-00.txt > >=20 > >=20 > > Status of this Memo > >=20 > > By submitting this Internet-Draft, we certify that any applicable > > patent or other IPR claims of which we are aware have been=20 > disclosed, > > or will be disclosed, and any of which we become aware will be > > disclosed, in accordance with RFC 3668. > >=20 > > Internet-Drafts are working documents of the Internet Engineering > > Task Force (IETF), its areas, and its working groups. Note that > > other groups may also distribute working documents as > > Internet-Drafts. > >=20 > > Internet-Drafts are draft documents valid for a maximum of six > > months and may be updated, replaced, or obsoleted by other > > documents at any time. It is inappropriate to use Internet- Drafts > > as reference material or to cite them other than as "work in > > progress." > >=20 > > The list of current Internet-Drafts can be accessed at > > http://www.ietf.org/1id-abstracts.html > >=20 > > The list of Internet-Draft Shadow Directories can be accessed at > > http://www.ietf.org/shadow.html > >=20 > >=20 > > Abstract > >=20 > > The aim of this paper is to analyse the use of quantum > > cryptography within PPP. We propose a solution that integrates=20 > > quantum key distribution into PPP.=20 > >=20 > >=20 > > Terminology > >=20 > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 > > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20 > > "OPTIONAL" in this document are to be interpreted as described=20 in=20 > > RFC 2119 [9]. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Ghernaouti and Sfaxi [Page 1] > > =0C > > INTERNET-DRAFT Expires: April, 29 2006 > >=20 > >=20 > >=20 > > 1. Introduction > >=20 > > The point to point protocol (PPP) [RFC1661] is a data-layer=20 > > protocol ensuring a reliable data exchange over a point to point=20 > > link. When the connection is established and configured, the PPP=20 > > allows the data transfer of many protocols (IP, IPX,=20 AppleTalk=C2=85).=20 > > That's why; PPP is widely used in Internet environment. > >=20 > > The unique security of PPP as specified in the RFC 1661 is=20 limited=20 > > to the authentication phase. The two nodes use an authentication=20 > > protocol such as Password Authentication Protocol (PAP)=20 [RFC1334]=20 > > or Challenge Handshake Authentication Protocol (CHAP)[RFC1994].=20 In=20 > > 1996, Meyer published an additional security protocol for PPP=20 > > called ECP (Encryption Control Protocol) [RFC1968]. This=20 protocol=20 > > allows the use of the encryption in PPP frame. The ECP gives the=20 > > possibility to select the encryption algorithm and its=20 parameters.=20 > > This ensures the confidentiality and the integrity of the PPP=20 > > frame. The weakness of this use resides in the way of generating=20 > > and exchanging the encryption key. In fact, for all the=20 encryption=20 > > algorithms the secret key is assumed to be already shared=20 between=20 > > the communicating parties. So to enhance security, we propose=20 the=20 > > use of quantum cryptography to generate and to share the secret=20 > > key between the two nodes. > >=20 > > Quantum cryptography is the only method allowing the=20 distribution=20 > > of a secret key between two distant parties without transmitting=20 > > any secret over unsecure channel [1, 4]. the emitter and the=20 > > receiver will be able to share an encryption key for enciphering=20 > > confidential data. The secrecy of this shared key is=20 > unconditional =20 > > [8] by the fact that the secret is generated and exchanged based=20 > > on physic laws (instead of mathematical functions). That=C2=92s wh= y=20 we=20 > > propose to integrate the quantum key distribution (QKD) process=20 to=20 > > share secret key between two nodes. > >=20 > >=20 > > 2. Encryption Control Protocol (ECP) for Quantum Key Distribution=20 > > (QKD) > >=20 > > The Encryption Control Protocol (ECP) defines the negotiation of > > the encryption over PPP links. After using LCP to establish and=20 > > configure the data link, the encryption options and mechanisms=20 > > could be negotiated. The ECP packets exchange mechanism is nearly > > the same as the LCP mechanism. The ECP packets are encapsulating=20 > > into PPP frame (a packet per frame). The type is 0x8053 to=20 > > indicate the Encryption Control Protocol. Two additional=20 messages=20 > > are added to the code field: the Reset-Request and Reset-Ack=20 > > message. These two messages are used to restart the encryption=20 > > negotiation. An encrypted packet is encapsulated in the PPP=20 > > information field where the PPP protocol field indicates type=20 > > 0x0053 (encrypted datagram). The ECP packet is presented in=20 > > figure 1 > >=20 > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + > > | Type | Length | Values... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >=20 > > Figure 1 - The Encryption Type Configuration Option format > >=20 > >=20 > > Ghernaouti and Sfaxi [Page=20 2] > > =0C > >=20 > > INTERNET-DRAFT Expires: April, 29=20 2006 > >=20 > >=20 > > ECP packet, the type represents the encryption protocol option to > > be negotiated (for instance type 1 is DES encryption). The=20 number=20 > > of octets in the packet is contained in the length field. The=20 > > values field gives additional data or option needed for the=20 > > encryption protocol. Up to now, there are only 4 encryption > > algorithms (type 0 =3D OUI, type 1 =3D DES, type 2 =3D 3DES, type = 3 =3D > > DES modified) that could be used [5]. > >=20 > > 3. Integrating QKD in PPP: QKD-PPP (Q3P) > >=20 > > In order to exchange the encryption key, a key exchange protocol > > is necessary. In this section, we present how to integrate QKD=20 in=20 > > PPP > >=20 > >=20 > > 3.1 ECP-QKD format > >=20 > > To establish and configure the quantum key distribution between=20 > > the two nodes, it is necessary to exchange some data between=20 > > them. We propose a specific ECP packet format to carry QKD=20 > > parameters (Figure 2): > >=20 > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + > > | Type | Length | Key-Length > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + > > | TTL |T| =20 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- > >=20 > > Figure 2 - ECP packet carrying a QKD protocol > >=20 > >=20 > > Type field: > > As in the ECP standard packet the type field gives information=20 > > about the option of encryption protocol negotiated. For this=20 > > case, we will use an unassigned number for the QKD protocol.=20 The=20 > > selected QKD protocol is BB84 and the request to obtain an=20 > > assigned number for this protocol is on going in IANA =20 > > organisation [5]. > >=20 > > Length field: > > The length is number of octets in the packet and it is more=20 than=20 > > =C2=945=C2=94 octets (1 octet for the type, 1 octet for the packe= t=20 length,=20 > > 2 octets for the key length and one octet for the TTL and the T=20 > > field). > >=20 > > Key-length field: > > This field indicates the length of the encryption key. It is=20 > > ended on 16 bits and represents the size of the key in octet.=20 The=20 > > key size is comprised between 1 to 65535 octets. The size can=20 be=20 > > viewed as huge but we consider the possibility to use the One=20 > > Time Pad function as the encryption algorithm. In this case, the > > key size must be equal to the PPP-data size [11]. > >=20 > >=20 > > Ghernaouti and Sfaxi [Page=20 3] > > =0C > > INTERNET-DRAFT Expires: April, 29=20 2006 > >=20 > > TTL field: > > This field can represent either the number of messages or the=20 > > amount of time (in second) during which a key could be used in=20 > > the encryption mechanism. When the max number of messages is=20 > > reached or the deadline expires, the QKD starts. > >=20 > > T field: > > The T field specifies if the TTL field concerns the number of > > messages or the amount of time. If the value is =C2=941=C2=94, th= e TTL=20 > > field corresponds to the amount of time in second. If it is=20 =C2=940=C2=94,=20 > > the TTL is the number of messages per key. > >=20 > > 3.2 The Q3P operating mode > >=20 > > We adapt PPP connection steps [RFC1661] to integrate QKD process > > as shown Figure 3. The three first steps of Q3P are identical=20 > > with PPP (phase 1 to 3). After authenticating the two nodes,=20 the=20 > > negotiation of the encryption parameters starts. In this phase,=20 > > the encryption algorithm with its parameters is negotiated. > > If the two nodes do not need to use encryption, then the=20 network=20 > > phase starts. Else, if an encryption key is required, a QKD=20 > phase =20 > > begins. For Encryption negotiation (4) the nodes negotiate the=20 > > key length and the TTL by sending an adequate ECP packet. After=20 > > that (in 5), a quantum cryptography exchange starts. At the end=20 > > of the quantum key distribution phase, both nodes share a=20 secret=20 > > key, the encryption algorithm and the TTL of the key. This key=20 is > > used in the network phase (6) while sending data. The data is=20 > > enciphered thanks to the encryption key and the algorithm. When=20 > > the TTL is expired, a new QKD phase starts. The end of the =20 > > communication is the same as the PPP.=20 > > (1) (2) (3)=20 > > +------+ +-----------+ +--------------+ > > | | UP | | OPENED | =20 |SUCCESS/NONE > > | Dead |------->| Establish |----------->| Authenticate |---+ > > | | | | | | | > > +------+ +-----------+ +--------------+ | > > ^ | | | > > | FAIL | FAIL | | > > +<--------------+ +----------+ | > > | | (4) | > > | | +--------------+ | > > | | | Encryption |<-+=20 > > | | | Negotiation | > > | | +--------------+ > > | | | > > | | TLL | Key needed/None > > | | expires \|/=20 > > | | +---------+ > > | | +---->| QKD |----+ > > | | | (5) +---------+ | > > | | | | > > | | | | > > | +-----------+ | | +---------+ | > > | DOWN | | | +-------| | | > > +-------------| Terminate | | | Network |<-+ > > | |<---+<-----------| | Key > > +-----------+ CLOSING +---------+=20 generated/ > > (7) (6) None > >=20 > > Figure 3 - Proposed Q3P steps and operating mode > >=20 > > Ghernaouti and Sfaxi [Page=20 4] > > =0C > > INTERNET-DRAFT Expires: April, 29=20 2006 > >=20 > >=20 > > The Figure 4 gives more details about Q3P operating mode. The=20 > > modification are little so that the adaptation of the PPP=20 > > operating mode is easy to realise. > >=20 > >=20 > > 1- Dead state (Initial state): > > a. When detecting an Up event then go the Establish phase > > 2- Establish phase: > > a. Configuration packets are exchanged (LCP) > > b. When finishing configuring the link connection go to the > > Authentication phase > > 3- Authentication phase: > > a. If required, the peer has to authenticate himself. > > b. If the authentication succeed or it is not required then go=20 > > to Encryption negotiation phase else go to terminate phase > > 4- Encryption Negotiation phase: > > a. If required, the two nodes negotiate the encryption=20 protocol=20 > > parameters and the quantum key exchange parameters (such as=20 > > TTL, Key length). If not required, go the Network phase > > b. After the end of the negotiation, go to QKD phase > > 5- QKD phase:=09 > > a. The source and the detector share a secret key exchanged=20 > > using quantum cryptography > > b. When the secret key is ready go to Network phase > > 6- Network phase: > > a. The two node exchange data > > b. When the encryption TTL expires go to QKD phase > > c. If the communication is finished, go to terminate phase (a=20 > > close event is generated) > > 7- Terminate phase: > > a. Terminate messages are exchange, when finish go to Dead=20 state > >=20 > > Figure 4 : The Q3P algorithm > >=20 > > 4. Conclusion > >=20 > > For some needs, it is important to have the option to secure=20 > > efficiently the data transmission between two adjacent nodes.=20 > > Using quantum cryptography in conjunction with PPP offer a=20 higher=20 > > level of security. Our study points out the adaptation of=20 > > the PPP protocol to integrate quantum key exchange (Q3P). The > > modifications to PPP are identified (packet format and operating=20 > > mode). > > Applying quantum key exchange and one-time-pad function at OSI=20 > > layer 2 is not only possible but will upgrade considerably, with=20 a=20 > > low cost and less effort (modification, performances,), the=20 > > security level of a transmission between two adjacent nodes. > >=20 > >=20 > > 5. Security considerations > >=20 > > Our proposition do not damage PPP security mechanism but enhance=20 > > if by the use of quantum key echange.=20 > > The unconditional security of quantum key distribution has been=20 > > already proven.=20 > >=20 > > Ghernaouti and Sfaxi [Page=20 5] > > =0C > > INTERNET-DRAFT Expires: April, 29=20 2006 > >=20 > > 6. Authors Address > >=20 > > Solange Ghernaouti-Helie > > HEC,=20 > > University of Lausanne > > 1015 Lausanne, Switzerland. > > EMail: sgh@unil.ch > >=20 > >=20 > > Mohamed Ali Sfaxi > > HEC,=20 > > University of Lausanne > > 1015 Lausanne, Switzerland. > > EMail: mohamedali.sfaxi@unil.ch > >=20 > >=20 > >=20 > > 7 . References > >=20 > > [1] Bennet, C; Brassard, G (1984). IEEE International Conference=20 > > on Computers, Systems, and Signal Processing. IEEE Press,=20 LOS=20 > > ALAMITOS > >=20 > > [2] Elliott, C (2002). =C2=94Building the quantum network=C2=94. N= ew=20 Journal=20 > > of Physics 4 (46.1-46.12) > >=20 > > [3] Elliott, C; Pearson, D; Troxel, G (2003). =C2=94Quantum > > Cryptography in Practice=C2=94. > >=20 > > [4] Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002).=20 =C2=94Quantum=20 > > Cryptography=C2=94. Reviews of Modern Physics 74 (2002). > > =20 > >=20 > > [5] Ghernaouti H=C2=B4elie, S; Sfaxi, M.A; Ribordy, G; Gay, O (200= 5).=20 > > =C2=93Using Quantum Key Distribution within IPSEC to secure MA= N=20 > > communications=C2=94. MAN 2005 conference. > >=20 > > [6] Guenther, C (2003) =C2=94The Relevance of Quantum Cryptography= in > > Modern Cryptographic Systems=C2=94. GSEC Partical Requirements= =20 > > (v1.4b). > > =20 http://www.giac.org/practical/GSEC/Christoph_Guenther_GSEC.pdf > >=20 > >=20 > > [7] Internet Assigned Numbers Authority - IANA (2005). > > http://www.iana.org/numbers.html > >=20 > > [8] Paterson, K.G; Piper, f; Schack, R (2004). =C2=94Why Quantum=20 > > Cryptography?=C2=94. http://eprint.iacr.org/2004/156.pdf > >=20 > >=20 > > Ghernaouti and Sfaxi [Page=20 6] > > =0C > > INTERNET-DRAFT Expires: April, 29=20 2006 > >=20 > >=20 > > [9] Bradner, S., "Key words for use in RFCs to Indicate=20 > > Requirement Levels", BCP 14, RFC 2119, Internet Engineering=20 > > Task Force, March 1997. > >=20 > > [10]Schneier, B (1996). =C2=94Applied Cryptography=C2=94 Second Ed= ition.=20 New=20 > > York: John Wiley & Sons, 1996 > >=20 > > [11]Shannon, C.E (1949). =C2=94Communication theory of secrecy > > systems=C2=94. Bell System Technical Journal 28-4.=20 > > =20 > >=20 > >=20 > > Intellectual Property Statement > >=20 > > The IETF takes no position regarding the validity or scope of any > > Intellectual Property Rights or other rights that might be=20 claimed > > to pertain to the implementation or use of the technology=20 > > described in this document or the extent to which any license=20 > > under such rights might or might not be available; nor does it=20 > > represent that it has made any independent effort to identify=20 any=20 > > such rights. > >=20 > > Information on the procedures with respect to rights in RFC > > documents can be found in BCP 78 and BCP 79. > >=20 > > Copies of IPR disclosures made to the IETF Secretariat and any > > assurances of licenses to be made available, or the result of an > > attempt made to obtain a general license or permission for the=20 use > > of such proprietary rights by implementers or users of this > > specification can be obtained from the IETF on-line IPR=20 repository > > at http://www.ietf.org/ipr. > >=20 > > The IETF invites any interested party to bring to its attention=20 > > any copyrights, patents or patent applications, or other=20 > > proprietary rights that may cover technology that may be=20 required=20 > > to implement this standard. Please address the information to=20 the=20 > > IETF at ietf-ipr@ietf.org. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Ghernaouti and Sfaxi [Page=20 7] > > =0C > > INTERNET-DRAFT Expires: April, 29=20 2006 > >=20 > >=20 > > Full Copyright Statement > >=20 > > Copyright (C) The Internet Society (2005). This document is > > subject to the rights, licenses and restrictions contained in BCP > > 78, and except as set forth therein, the authors retain all their > > rights. > >=20 > > This document and the information contained herein are provided=20 on > > an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY=20 THAT > > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR > > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > > PARTICULAR PURPOSE. > >=20 > >=20 > > Acknowledgement > >=20 > > Funding for the RFC Editor function is currently provided by the > > Internet Society. > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > > Ghernaouti and Sfaxi [Page=20 8] > >=20 > >=20 >=20 >=20 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Nov 04 13:38:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6Sd-0005BF-AF; Fri, 04 Nov 2005 13:38:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY6Sc-00059U-0Z for pppext@megatron.ietf.org; Fri, 04 Nov 2005 13:38:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06497 for ; Fri, 4 Nov 2005 13:38:21 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY6hY-000718-OV for pppext@ietf.org; Fri, 04 Nov 2005 13:54:17 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jA4IcYdK008409 for ; Fri, 4 Nov 2005 10:38:35 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jA4IcYH2019163 for ; Fri, 4 Nov 2005 13:38:34 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jA4IcYmR029976; Fri, 4 Nov 2005 13:38:34 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jA4IcYmV029973; Fri, 4 Nov 2005 13:38:34 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17259.43690.450328.543393@gargle.gargle.HOWL> Date: Fri, 4 Nov 2005 13:38:34 -0500 From: James Carlson To: iana-prot-param@icann.org Subject: Re: [Pppext] [rt.icann.org #3528] FW: General Request for Assignments (ppp-numbers) In-Reply-To: Michelle Cotton via RT's message of 4 November 2005 09:40:55 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Michelle Cotton via RT writes: > We are resending this message as we have not yet seen a response. We've been discussing the issues with the draft authors. The current group consensus (taken on Monday, October 31st) is that the draft as presented does not provide sufficient justification for allocating a code point for this purpose. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Nov 09 02:48:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZkhI-0002Cy-5J; Wed, 09 Nov 2005 02:48:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZkhH-0002Cq-Ev for pppext@megatron.ietf.org; Wed, 09 Nov 2005 02:48:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20148 for ; Wed, 9 Nov 2005 02:48:16 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZkxE-0003YT-OL for pppext@ietf.org; Wed, 09 Nov 2005 03:05:14 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id EC2FFFFAB2E; Tue, 8 Nov 2005 23:48:20 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14710-01; Tue, 8 Nov 2005 23:48:20 -0800 (PST) Received: from PARBETM2XP (login-1-300.redback.com [155.53.12.153]) by prattle.redback.com (Postfix) with ESMTP id 424F3FFAB2D; Tue, 8 Nov 2005 23:48:20 -0800 (PST) From: "Peter Arberg" To: Date: Tue, 8 Nov 2005 23:48:10 -0800 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXlAe24OPo3FPXmQlCIzJdKjzKnIQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051109074820.424F3FFAB2D@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Subject: [Pppext] New internet-draft for IANA consideration for PPPoE X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi, A new internet-draft, intended as a BCP, which discuss IANA consideration for PPPoE Tags, have been submitted. "IANA Considerations for PPP over Ethernet (PPPoE)" draft-arberg-pppoe-iana-00.txt http://www.ietf.org/internet-drafts/draft-arberg-pppoe-iana-00.txt It is submitted as an individual draft, and we would really appreciate the comments from the pppext list on the draft. thanks, Peter _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Nov 21 21:58:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeOMN-0006iH-Em; Mon, 21 Nov 2005 21:58:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeOML-0006f4-AJ for pppext@megatron.ietf.org; Mon, 21 Nov 2005 21:58:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24272 for ; Mon, 21 Nov 2005 21:57:39 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeOet-0000gw-T7 for pppext@ietf.org; Mon, 21 Nov 2005 22:17:29 -0500 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id jAM2w7Km011333; Mon, 21 Nov 2005 21:58:07 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id VAA24189; Mon, 21 Nov 2005 21:58:07 -0500 (EST) Message-Id: <200511220258.VAA24189@breeze.research.telcordia.com> To: pppext@ietf.org Date: Mon, 21 Nov 2005 21:58:06 -0500 From: Ashutosh Dutta X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Pppext] IPCP option for SIP server X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org I was trying to find the status of the draft "draft-song-pppext-sip-support.txt", and came across the following announcement, http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip-support.txt. which says there are already ways to take care of this and thus this never became an informational RFC. I could not find it in the email archive. Can somebody please point me to the right draft where it explains as to how to take care of assigning SIP server over PPP link? It is very important to determine the IP address of the outbound SIP proxy using PPP option. Thanks Ashutosh Dutta Telcordia Applied Research _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Nov 21 22:38:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeOyq-00045u-I7; Mon, 21 Nov 2005 22:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeOyp-00045m-8E for pppext@megatron.ietf.org; Mon, 21 Nov 2005 22:38:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27487 for ; Mon, 21 Nov 2005 22:37:25 -0500 (EST) Received: from 66.237.112.74.ptr.us.xo.net ([66.237.112.74] helo=lithik.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EePHO-0001u2-8X for pppext@ietf.org; Mon, 21 Nov 2005 22:57:15 -0500 Received: from [24.93.124.171] (account karl HELO [10.0.0.3]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1135447; Mon, 21 Nov 2005 22:37:58 -0500 In-Reply-To: <200511220258.VAA24189@breeze.research.telcordia.com> References: <200511220258.VAA24189@breeze.research.telcordia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FB4903B-51AD-4F27-952D-C31C2239327F@columbus.rr.com> Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] IPCP option for SIP server Date: Mon, 21 Nov 2005 22:37:56 -0500 To: Ashutosh Dutta X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org How about RFC 3361 (for IPv4; RFC 3319 for v6)? Karl On Nov 21, 2005, at 9:58 PM, Ashutosh Dutta wrote: > I was trying to find the status of the draft > "draft-song-pppext-sip-support.txt", and came across the following > announcement, > > http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip- > support.txt. > > which says there are already ways to take care of this and thus this > never became an informational RFC. I could not find it in the email > archive. Can somebody please point me to the right draft where it > explains as to how to take care of assigning SIP server over PPP link? > > It is very important to determine the IP address of the outbound SIP > proxy using PPP option. > > Thanks > Ashutosh Dutta > Telcordia Applied Research _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 01:40:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRpd-0004uM-Mp; Tue, 22 Nov 2005 01:40:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRpZ-0004s8-Af for pppext@megatron.ietf.org; Tue, 22 Nov 2005 01:40:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06670 for ; Tue, 22 Nov 2005 01:39:57 -0500 (EST) Received: from 66.237.112.74.ptr.us.xo.net ([66.237.112.74] helo=lithik.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeR3F-0000IA-MI for pppext@ietf.org; Tue, 22 Nov 2005 00:50:46 -0500 Received: from [24.93.124.171] (account karl HELO [10.0.0.3]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1135462; Tue, 22 Nov 2005 00:31:31 -0500 In-Reply-To: <200511220446.XAA29200@breeze.research.telcordia.com> References: <200511220446.XAA29200@breeze.research.telcordia.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <300B20FA-9648-4143-B5BE-3568CC1A218F@columbus.rr.com> Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] IPCP option for SIP server Date: Tue, 22 Nov 2005 00:31:27 -0500 To: Ashutosh Dutta X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org It is relevant to a WAN environment. DHCP runs over UDP, which runs over IP, which runs over PPP. DHCP is a flexible, well-defined protocol that is easy to implement. No protocol changes are needed. Karl On Nov 21, 2005, at 11:46 PM, Ashutosh Dutta wrote: > Karl, thanks for your email. > > RFC 3361, and RFC 3319 talk about DHCP option for V4/V6 > respectively. I was more curious about PPP that is more relevant for > Wan environment. > > Thanks > Ashutosh > > >> How about RFC 3361 (for IPv4; RFC 3319 for v6)? >> >> Karl >> >> On Nov 21, 2005, at 9:58 PM, Ashutosh Dutta wrote: >>> I was trying to find the status of the draft >>> "draft-song-pppext-sip-support.txt", and came across the following >>> announcement, >>> >>> http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip- >>> support.txt. >>> >>> which says there are already ways to take care of this and thus >>> this >>> never became an informational RFC. I could not find it in the >>> email >>> archive. Can somebody please point me to the right draft >>> where it >>> explains as to how to take care of assigning SIP server over PPP >>> link? >>> >>> It is very important to determine the IP address of the outbound SIP >>> proxy using PPP option. >>> >>> Thanks >>> Ashutosh Dutta >>> Telcordia Applied Research > > Ashutosh _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 01:42:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRr4-0005WR-2s; Tue, 22 Nov 2005 01:42:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeRr3-0005W8-Bt for pppext@megatron.ietf.org; Tue, 22 Nov 2005 01:42:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07601 for ; Tue, 22 Nov 2005 01:41:31 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeQMC-0004c0-Ne for pppext@ietf.org; Tue, 22 Nov 2005 00:06:17 -0500 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id jAM4kiKm016999; Mon, 21 Nov 2005 23:46:44 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id XAA29200; Mon, 21 Nov 2005 23:46:44 -0500 (EST) Message-Id: <200511220446.XAA29200@breeze.research.telcordia.com> To: Karl Fox Subject: Re: [Pppext] IPCP option for SIP server In-reply-to: Your message of "Mon, 21 Nov 2005 22:37:56 EST." <5FB4903B-51AD-4F27-952D-C31C2239327F@columbus.rr.com> Date: Mon, 21 Nov 2005 23:46:44 -0500 From: Ashutosh Dutta X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Karl, thanks for your email. RFC 3361, and RFC 3319 talk about DHCP option for V4/V6 respectively. I was more curious about PPP that is more relevant for Wan environment. Thanks Ashutosh > How about RFC 3361 (for IPv4; RFC 3319 for v6)? > > Karl > > On Nov 21, 2005, at 9:58 PM, Ashutosh Dutta wrote: > > I was trying to find the status of the draft > > "draft-song-pppext-sip-support.txt", and came across the following > > announcement, > > > > http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip- > > support.txt. > > > > which says there are already ways to take care of this and thus this > > never became an informational RFC. I could not find it in the email > > archive. Can somebody please point me to the right draft where it > > explains as to how to take care of assigning SIP server over PPP link? > > > > It is very important to determine the IP address of the outbound SIP > > proxy using PPP option. > > > > Thanks > > Ashutosh Dutta > > Telcordia Applied Research Ashutosh _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 07:33:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXKp-00007d-89; Tue, 22 Nov 2005 07:33:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXKn-00007A-MZ for pppext@megatron.ietf.org; Tue, 22 Nov 2005 07:33:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11026 for ; Tue, 22 Nov 2005 07:32:36 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeXdO-00007f-FQ for pppext@ietf.org; Tue, 22 Nov 2005 07:52:31 -0500 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id jAMCWqKm022123; Tue, 22 Nov 2005 07:32:52 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id HAA23003; Tue, 22 Nov 2005 07:32:52 -0500 (EST) Message-Id: <200511221232.HAA23003@breeze.research.telcordia.com> To: Karl Fox Subject: Re: [Pppext] IPCP option for SIP server In-reply-to: Your message of "Tue, 22 Nov 2005 00:31:27 EST." <300B20FA-9648-4143-B5BE-3568CC1A218F@columbus.rr.com> Date: Tue, 22 Nov 2005 07:32:52 -0500 From: Ashutosh Dutta X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Karl, in a 3GPP2 environment where the client gets an IP address from PDSN over PPP link, my PDSN acts like a NAS which is also a PPP server, and I may not have a DHCP server in that case. I have used DHCP in LAN environment with SIP option. Thanks Ashutosh > It is relevant to a WAN environment. DHCP runs over UDP, which runs > over IP, which runs over PPP. DHCP is a flexible, well-defined > protocol that is easy to implement. No protocol changes are needed. > > Karl > > On Nov 21, 2005, at 11:46 PM, Ashutosh Dutta wrote: > > Karl, thanks for your email. > > > > RFC 3361, and RFC 3319 talk about DHCP option for V4/V6 > > respectively. I was more curious about PPP that is more relevant for > > Wan environment. > > > > Thanks > > Ashutosh > > > > > >> How about RFC 3361 (for IPv4; RFC 3319 for v6)? > >> > >> Karl > >> > >> On Nov 21, 2005, at 9:58 PM, Ashutosh Dutta wrote: > >>> I was trying to find the status of the draft > >>> "draft-song-pppext-sip-support.txt", and came across the following > >>> announcement, > >>> > >>> http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip- > >>> support.txt. > >>> > >>> which says there are already ways to take care of this and thus > >>> this > >>> never became an informational RFC. I could not find it in the > >>> email > >>> archive. Can somebody please point me to the right draft > >>> where it > >>> explains as to how to take care of assigning SIP server over PPP > >>> link? > >>> > >>> It is very important to determine the IP address of the outbound SIP > >>> proxy using PPP option. > >>> > >>> Thanks > >>> Ashutosh Dutta > >>> Telcordia Applied Research > > > > Ashutosh > Ashutosh _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 08:18:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXzo-0001UH-6L; Tue, 22 Nov 2005 08:15:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeXzl-0001Tn-TI for pppext@megatron.ietf.org; Tue, 22 Nov 2005 08:15:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15792 for ; Tue, 22 Nov 2005 08:14:56 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeYIF-0002XT-HE for pppext@ietf.org; Tue, 22 Nov 2005 08:34:53 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id jAMDFN4u028858 for ; Tue, 22 Nov 2005 05:15:23 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jAMDFMH2017654 for ; Tue, 22 Nov 2005 08:15:22 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAMDFH4h002232; Tue, 22 Nov 2005 08:15:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAMDFHec002229; Tue, 22 Nov 2005 08:15:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17283.6629.136462.717680@gargle.gargle.HOWL> Date: Tue, 22 Nov 2005 08:15:17 -0500 From: James Carlson To: Ashutosh Dutta Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: Ashutosh Dutta's message of 22 November 2005 07:32:52 References: <300B20FA-9648-4143-B5BE-3568CC1A218F@columbus.rr.com> <200511221232.HAA23003@breeze.research.telcordia.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 2.0 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Ashutosh Dutta writes: > > Karl, in a 3GPP2 environment where the client gets an IP address from > PDSN over PPP link, my PDSN acts like a NAS which is also a PPP > server, and I may not have a DHCP server in that case. A "DHCP server" is no more difficult than an IP node that can send and receive UDP packets. If you don't have that, then it seems unlikely to me that you've got a functioning IP network at all. Note that you don't need stateful behavior to solve the problem. A simple DHCPINFORM will do the trick. > I have used DHCP in LAN environment with SIP option. And that's a good reason why it should *not* be added to PPP. It's redundant work. A much better reason to avoid adding it to PPP is that it won't work right. Consider the following network: N1 <---PPP---> N2 <---Ethernet/other---> SIP server In this case, you'd want N1 to learn about the IP address of the SIP server that exists behind N2. But the PPP (and IPCP) negotiation on the PPP link terminates with N2. This means that N2 needs to somehow "know" that the SIP server exists and what its address is. This implies that either N2 behaves as a proxy between this new IPCP configuration option and DHCP, or that N2 has fragile statically configured data for that address. Either way, you're committing all of us (collectively) to producing new ad-hoc extensions to IPCP that are proxied one-by-one into DHCP or some local configuration that must be managed. That solution is far more complex and much less extensible than just having N2 behave as a generic DHCP/BOOTP relay on behalf of N1, and allowing those protocols to do what they're already designed to do. The same problem afflicts the ill-considered DNS name server address option, and I don't think we need to replicate that mistake. Once, I think, was plenty. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 08:20:25 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeY4P-0002u1-8g; Tue, 22 Nov 2005 08:20:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeY4N-0002sV-SW for pppext@megatron.ietf.org; Tue, 22 Nov 2005 08:20:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16263 for ; Tue, 22 Nov 2005 08:19:44 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeYN1-0002mr-Vo for pppext@ietf.org; Tue, 22 Nov 2005 08:39:41 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 22 Nov 2005 05:20:13 -0800 X-IronPort-AV: i="3.97,361,1125903600"; d="scan'208"; a="233160708:sNHT25615052" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id jAMDJg6w028431; Tue, 22 Nov 2005 05:20:11 -0800 (PST) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Nov 2005 08:20:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] IPCP option for SIP server Date: Tue, 22 Nov 2005 08:20:07 -0500 Message-ID: <80BCC34EA5E72947AEFDD1D7920264C0D43936@xmb-rtp-213.amer.cisco.com> Thread-Topic: [Pppext] IPCP option for SIP server Thread-Index: AcXvYXrIDKkbzMGCSBmp1wmG/ayi0wABMBog From: "John Bray \(bray\)" To: "Ashutosh Dutta" X-OriginalArrivalTime: 22 Nov 2005 13:20:08.0722 (UTC) FILETIME=[75D0DF20:01C5EF67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org As Karl says, DHCP is a very simple protocol which is easy to implement. In fact, it is simpler than PPP. Just add it. John > -----Original Message----- > From: pppext-bounces@ietf.org=20 > [mailto:pppext-bounces@ietf.org] On Behalf Of Ashutosh Dutta > Sent: Tuesday, November 22, 2005 7:33 AM > To: Karl Fox > Cc: pppext@ietf.org > Subject: Re: [Pppext] IPCP option for SIP server=20 >=20 >=20 > Karl, in a 3GPP2 environment where the client gets an IP address from > PDSN over PPP link, my PDSN acts like a NAS which is also a PPP > server, and I may not have a DHCP server in that case. >=20 > I have used DHCP in LAN environment with SIP option. >=20 > Thanks > Ashutosh >=20 > > It is relevant to a WAN environment. DHCP runs over UDP,=20 > which runs =20 > > over IP, which runs over PPP. DHCP is a flexible, well-defined =20 > > protocol that is easy to implement. No protocol changes are needed. > >=20 > > Karl > >=20 > > On Nov 21, 2005, at 11:46 PM, Ashutosh Dutta wrote: > > > Karl, thanks for your email. > > > > > > RFC 3361, and RFC 3319 talk about DHCP option for V4/V6 > > > respectively. I was more curious about PPP that is more=20 > relevant for > > > Wan environment. > > > > > > Thanks > > > Ashutosh > > > > > > > > >> How about RFC 3361 (for IPv4; RFC 3319 for v6)? > > >> > > >> Karl > > >> > > >> On Nov 21, 2005, at 9:58 PM, Ashutosh Dutta wrote: > > >>> I was trying to find the status of the draft > > >>> "draft-song-pppext-sip-support.txt", and came across=20 > the following > > >>> announcement, > > >>> > > >>>=20 > http://www.ietf.org/IESG/Announcements/rfcno-draft-song-pppext-sip- > > >>> support.txt. > > >>> > > >>> which says there are already ways to take care of =20 > this and thus =20 > > >>> this > > >>> never became an informational RFC. I could not find=20 > it in the =20 > > >>> email > > >>> archive. Can somebody please point me to the right draft =20 > > >>> where it > > >>> explains as to how to take care of assigning SIP server=20 > over PPP =20 > > >>> link? > > >>> > > >>> It is very important to determine the IP address of the=20 > outbound SIP > > >>> proxy using PPP option. > > >>> > > >>> Thanks > > >>> Ashutosh Dutta > > >>> Telcordia Applied Research > > > > > > Ashutosh > >=20 >=20 > Ashutosh=20 >=20 > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext >=20 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 09:17:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYxw-0003yH-5h; Tue, 22 Nov 2005 09:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeYxu-0003y9-Qj for pppext@megatron.ietf.org; Tue, 22 Nov 2005 09:17:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21876 for ; Tue, 22 Nov 2005 09:17:03 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZGW-0005YZ-90 for pppext@ietf.org; Tue, 22 Nov 2005 09:37:00 -0500 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id jAMEHRKm029493; Tue, 22 Nov 2005 09:17:27 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA28490; Tue, 22 Nov 2005 09:17:26 -0500 (EST) Message-Id: <200511221417.JAA28490@breeze.research.telcordia.com> To: James Carlson Subject: Re: [Pppext] IPCP option for SIP server In-reply-to: Your message of "Tue, 22 Nov 2005 08:15:17 EST." <17283.6629.136462.717680@gargle.gargle.HOWL> Date: Tue, 22 Nov 2005 09:17:26 -0500 From: Ashutosh Dutta X-Spam-Score: 2.0 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James, appreciate your thoughtful reply. As you have mentioned there is certainly better way around to take care of this scenario if one has a DHCP server sitting in the network where the NAS server is connected. I was refering to the case where the PPP server is configured to give away the addresses and may not have any DHCP server configured in the network to rely upon, in that case only way to provide SIP server, DNS server etc. to the mobile obtaining the IP address may need a mechanism where these parameters get stored locally in a NAS server and are given out as part of IP address dispensing. Regards Ashutosh > Ashutosh Dutta writes: > > > > Karl, in a 3GPP2 environment where the client gets an IP address from > > PDSN over PPP link, my PDSN acts like a NAS which is also a PPP > > server, and I may not have a DHCP server in that case. > > A "DHCP server" is no more difficult than an IP node that can send and > receive UDP packets. If you don't have that, then it seems unlikely > to me that you've got a functioning IP network at all. > > Note that you don't need stateful behavior to solve the problem. A > simple DHCPINFORM will do the trick. > > > I have used DHCP in LAN environment with SIP option. > > And that's a good reason why it should *not* be added to PPP. It's > redundant work. > > A much better reason to avoid adding it to PPP is that it won't work > right. Consider the following network: > > N1 <---PPP---> N2 <---Ethernet/other---> SIP server > > In this case, you'd want N1 to learn about the IP address of the SIP > server that exists behind N2. But the PPP (and IPCP) negotiation on > the PPP link terminates with N2. This means that N2 needs to somehow > "know" that the SIP server exists and what its address is. > > This implies that either N2 behaves as a proxy between this new IPCP > configuration option and DHCP, or that N2 has fragile statically > configured data for that address. > > Either way, you're committing all of us (collectively) to producing > new ad-hoc extensions to IPCP that are proxied one-by-one into DHCP or > some local configuration that must be managed. That solution is far > more complex and much less extensible than just having N2 behave as a > generic DHCP/BOOTP relay on behalf of N1, and allowing those protocols > to do what they're already designed to do. > > The same problem afflicts the ill-considered DNS name server address > option, and I don't think we need to replicate that mistake. Once, I > think, was plenty. > > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Ashutosh _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 11:40:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebBs-0003Is-9R; Tue, 22 Nov 2005 11:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebBl-0003HK-Go for pppext@megatron.ietf.org; Tue, 22 Nov 2005 11:40:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09472 for ; Tue, 22 Nov 2005 11:39:32 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EebUM-0004oT-7i for pppext@ietf.org; Tue, 22 Nov 2005 11:59:29 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id jAMGe5dK009406 for ; Tue, 22 Nov 2005 08:40:05 -0800 (PST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jAMGe5H2028337 for ; Tue, 22 Nov 2005 11:40:05 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAMGe4Ig002971; Tue, 22 Nov 2005 11:40:04 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAMGe4fj002968; Tue, 22 Nov 2005 11:40:04 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17283.18916.745413.568358@gargle.gargle.HOWL> Date: Tue, 22 Nov 2005 11:40:04 -0500 From: James Carlson To: Ashutosh Dutta Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: Ashutosh Dutta's message of 22 November 2005 09:17:26 References: <17283.6629.136462.717680@gargle.gargle.HOWL> <200511221417.JAA28490@breeze.research.telcordia.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 2.0 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Ashutosh Dutta writes: > James, appreciate your thoughtful reply. As you have mentioned there > is certainly better way around to take care of this scenario if one > has a DHCP server sitting in the network where the NAS server is > connected. Where "DHCP server" is no more complex an answer than "new IPCP option." In fact, the former is *less* complex because it involves existing standards, while the latter requires forcing manufacturers to add the option of interest and then deploying brand new software (and/or hardware) to solve the problem. Using existing mechanisms is generally a better idea, if you have a choice. > I was refering to the case where the PPP server is configured to give > away the addresses and may not have any DHCP server configured in the > network to rely upon, in that case only way to provide SIP server, DNS > server etc. to the mobile obtaining the IP address may need a > mechanism where these parameters get stored locally in a NAS server > and are given out as part of IP address dispensing. As I wrote: > > In this case, you'd want N1 to learn about the IP address of the SIP > > server that exists behind N2. But the PPP (and IPCP) negotiation on > > the PPP link terminates with N2. This means that N2 needs to somehow > > "know" that the SIP server exists and what its address is. You still have to have information on the SIP server's side of that PPP link that somehow tells the PPP termination equipment the IP address of the proper SIP server. There are multiple ways to do this, but they're all much less robust and less desirable than just using a simple DHCP exchange. As I wrote: > > This implies that either N2 behaves as a proxy between this new IPCP > > configuration option and DHCP, or that N2 has fragile statically > > configured data for that address. > > > > Either way, you're committing all of us (collectively) to producing > > new ad-hoc extensions to IPCP that are proxied one-by-one into DHCP or > > some local configuration that must be managed. That solution is far > > more complex and much less extensible than just having N2 behave as a > > generic DHCP/BOOTP relay on behalf of N1, and allowing those protocols > > to do what they're already designed to do. I don't see any good way out of that problem. There are few ways for N2 to have any *reliable* knowledge of the SIP server's address, and the ways that do exist imply duplicative effort within IPCP to rebuild all of the options currently available in DHCP. I see no point to doing that, when sending and receiving UDP datagrams is trivial. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 11:45:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebHH-0005lq-8c; Tue, 22 Nov 2005 11:45:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebHF-0005kc-Bn for pppext@megatron.ietf.org; Tue, 22 Nov 2005 11:45:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10135 for ; Tue, 22 Nov 2005 11:45:14 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EebZf-00056i-6M for pppext@ietf.org; Tue, 22 Nov 2005 12:05:12 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jAMGjXD7001025 for ; Tue, 22 Nov 2005 09:45:33 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jAMGjVH2000706 for ; Tue, 22 Nov 2005 11:45:32 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAMGjI5m002984; Tue, 22 Nov 2005 11:45:18 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAMGjI2D002981; Tue, 22 Nov 2005 11:45:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17283.19230.16884.567612@gargle.gargle.HOWL> Date: Tue, 22 Nov 2005 11:45:18 -0500 From: James Carlson To: Ashutosh Dutta Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: Ashutosh Dutta's message of 22 November 2005 09:17:26 References: <17283.6629.136462.717680@gargle.gargle.HOWL> <200511221417.JAA28490@breeze.research.telcordia.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Ashutosh Dutta writes: > I was refering to the case where the PPP server is configured to give > away the addresses and may not have any DHCP server configured in the > network to rely upon, in that case only way to provide SIP server, DNS > server etc. to the mobile obtaining the IP address may need a > mechanism where these parameters get stored locally in a NAS server > and are given out as part of IP address dispensing. Note that DHCP itself needn't necessarily be involved in the IP address allocation strategy at all. It's possible to use DHCP to distribute configuration details without doing stateful address allocation. See the DHCPINFORM messages (cited earlier) for details. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 12:11:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebgR-0000Jt-ON; Tue, 22 Nov 2005 12:11:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EebgQ-0000JO-EO for pppext@megatron.ietf.org; Tue, 22 Nov 2005 12:11:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13556 for ; Tue, 22 Nov 2005 12:11:16 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eebz6-0006gI-IW for pppext@ietf.org; Tue, 22 Nov 2005 12:31:13 -0500 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id jAMHBKKm013762; Tue, 22 Nov 2005 12:11:21 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA06996; Tue, 22 Nov 2005 12:11:20 -0500 (EST) Message-Id: <200511221711.MAA06996@breeze.research.telcordia.com> To: James Carlson Subject: Re: [Pppext] IPCP option for SIP server In-reply-to: Your message of "Tue, 22 Nov 2005 11:45:18 EST." <17283.19230.16884.567612@gargle.gargle.HOWL> Date: Tue, 22 Nov 2005 12:11:20 -0500 From: Ashutosh Dutta X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > Ashutosh Dutta writes: > > I was refering to the case where the PPP server is configured to give > > away the addresses and may not have any DHCP server configured in the > > network to rely upon, in that case only way to provide SIP server, DNS > > server etc. to the mobile obtaining the IP address may need a > > mechanism where these parameters get stored locally in a NAS server > > and are given out as part of IP address dispensing. > > Note that DHCP itself needn't necessarily be involved in the IP > address allocation strategy at all. It's possible to use DHCP to > distribute configuration details without doing stateful address > allocation. See the DHCPINFORM messages (cited earlier) for details. James agreed, PPP server itself can keep the IP address pool and dispense it and DHCPINFORM can probably get other server details using DHCPINFORM. Only requirement is then to have a DHCP server in the backend and have a DHCPclient of some sort in the NAS server. Thanks Ashutosh > > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 12:43:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAu-0004bP-1M; Tue, 22 Nov 2005 12:43:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EecAs-0004aA-07 for pppext@megatron.ietf.org; Tue, 22 Nov 2005 12:43:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17075 for ; Tue, 22 Nov 2005 12:42:41 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EecOh-0007yT-JT for pppext@ietf.org; Tue, 22 Nov 2005 12:57:43 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jAMHcI3F012731 for ; Tue, 22 Nov 2005 10:38:18 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jAMHcHWc017410 for ; Tue, 22 Nov 2005 12:38:17 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jAMHcHPd003190; Tue, 22 Nov 2005 12:38:17 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jAMHcHUS003187; Tue, 22 Nov 2005 12:38:17 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17283.22409.82105.121294@gargle.gargle.HOWL> Date: Tue, 22 Nov 2005 12:38:17 -0500 From: James Carlson To: Ashutosh Dutta Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: Ashutosh Dutta's message of 22 November 2005 12:11:20 References: <17283.19230.16884.567612@gargle.gargle.HOWL> <200511221711.MAA06996@breeze.research.telcordia.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Ashutosh Dutta writes: > > Note that DHCP itself needn't necessarily be involved in the IP > > address allocation strategy at all. It's possible to use DHCP to > > distribute configuration details without doing stateful address > > allocation. See the DHCPINFORM messages (cited earlier) for details. > > James agreed, PPP server itself can keep the IP address pool and > dispense it and DHCPINFORM can probably get other server details using > DHCPINFORM. Only requirement is then to have a DHCP server in the > backend and have a DHCPclient of some sort in the NAS server. If you instead put that client in the remote node ("N1" in my diagram) rather than in the NAS ("N2" in my diagram, though I was intentionally showing PPP itself as a symmetric link), then you don't need any PPP changes at all, and you can get *ALL* of the other configuration features of DHCP for free without needing to change IPCP for each one. That's the point. There's an existing solution that works well, is widely deployed, and is quite easy to implement. We thus don't need another. In addition to that, adding SIP configuration here would just beg other questions. Should Ethernet have a way to do this as well, perhaps via 802.1X extensions? Why shouldn't all L2 protocols do this? What happens if the remote node supports both DHCP and the proposed IPCP option, and queries to these return different answers? Which one is considered authoritative and why? Adding new features to an existing protocol isn't a matter of "could," but rather a matter of "must." In other words, we do it as a last resort because nothing else can reasonably be made to work. That's not the case here. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Nov 22 18:50:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eehu2-00021T-Mj; Tue, 22 Nov 2005 18:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eehtj-0001m1-7g; Tue, 22 Nov 2005 18:50:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29810; Tue, 22 Nov 2005 18:49:24 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeiCS-0004yn-Uo; Tue, 22 Nov 2005 19:09:25 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Eehth-0005Zy-KZ; Tue, 22 Nov 2005 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 22 Nov 2005 18:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pppext@ietf.org Subject: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org --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 : Accommodating an MTU/MRU greater than 1492 in PPPoE Author(s) : P. Arberg, et al. Filename : draft-arberg-pppoe-mtu-gt1492-02.txt Pages : 7 Date : 2005-11-22 Point-to-Point Protocol Over Ethernet (PPPoE), as described in RFC 2516 [1], mandates a maximum negotiated MRU of 1492. This document outlines a solution to relax that restriction and allow a maximum negotiated MRU greater than 1492 to minimize fragmentation in next generation broadband networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-arberg-pppoe-mtu-gt1492-02.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-arberg-pppoe-mtu-gt1492-02.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: <2005-11-22163446.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-arberg-pppoe-mtu-gt1492-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-arberg-pppoe-mtu-gt1492-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-22163446.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --NextPart-- From pppext-bounces@ietf.org Wed Nov 23 08:28:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeufP-0003Nt-Vj; Wed, 23 Nov 2005 08:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeufO-0003Nm-S9 for pppext@megatron.ietf.org; Wed, 23 Nov 2005 08:28:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29551 for ; Wed, 23 Nov 2005 08:27:25 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeuyD-0000xF-6z for pppext@ietf.org; Wed, 23 Nov 2005 08:47:34 -0500 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id jANDRYKm003985; Wed, 23 Nov 2005 08:27:34 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id IAA01530; Wed, 23 Nov 2005 08:27:34 -0500 (EST) Message-Id: <200511231327.IAA01530@breeze.research.telcordia.com> To: James Carlson Subject: Re: [Pppext] IPCP option for SIP server In-reply-to: Your message of "Tue, 22 Nov 2005 12:38:17 EST." <17283.22409.82105.121294@gargle.gargle.HOWL> Date: Wed, 23 Nov 2005 08:27:34 -0500 From: Ashutosh Dutta X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > > James agreed, PPP server itself can keep the IP address pool and > > dispense it and DHCPINFORM can probably get other server details using > > DHCPINFORM. Only requirement is then to have a DHCP server in the > > backend and have a DHCPclient of some sort in the NAS server. > > If you instead put that client in the remote node ("N1" in my diagram) > rather than in the NAS ("N2" in my diagram, though I was intentionally > showing PPP itself as a symmetric link), then you don't need any PPP > changes at all, and you can get *ALL* of the other configuration > features of DHCP for free without needing to change IPCP for each one. > James, I can think of some optimization issue such as follows: By running DHCPclient on the mobile while the mobile is using CDMA2000 RAN, one uses PPP to obtain an IP address and DHCPclient to obtain other server parameters and one needs to run both the daemons on the client to get fully configured. PPP has to happen and then DHCP. For a rapidly moving client this may add to some optimization issue. Thus if the client is moving between PDSNs this may be bit overkill but may work out well if the same client moves between CDMA2000 network and WiFi for example. Thanks Ashutosh _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Nov 23 09:07:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EevHG-0001pd-F7; Wed, 23 Nov 2005 09:07:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EevHE-0001oS-Sp for pppext@megatron.ietf.org; Wed, 23 Nov 2005 09:07:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04877 for ; Wed, 23 Nov 2005 09:06:31 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eeva1-0003Cz-OG for pppext@ietf.org; Wed, 23 Nov 2005 09:26:41 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id jANE75D7028873 for ; Wed, 23 Nov 2005 07:07:06 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jANE75H2019796 for ; Wed, 23 Nov 2005 09:07:05 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jANE75tK006156; Wed, 23 Nov 2005 09:07:05 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jANE75As006153; Wed, 23 Nov 2005 09:07:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17284.30601.11967.29171@gargle.gargle.HOWL> Date: Wed, 23 Nov 2005 09:07:05 -0500 From: James Carlson To: Ashutosh Dutta Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: Ashutosh Dutta's message of 23 November 2005 08:27:34 References: <17283.22409.82105.121294@gargle.gargle.HOWL> <200511231327.IAA01530@breeze.research.telcordia.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Ashutosh Dutta writes: > James, I can think of some optimization issue such as follows: > > By running DHCPclient on the mobile while the mobile is using CDMA2000 > RAN, one uses PPP to obtain an IP address and DHCPclient to obtain > other server parameters and one needs to run both the daemons on the > client to get fully configured. What "daemons?" That's an implementation issue. As for DHCP, we're talking about a single UDP packet exchange -- send, receive. That's it; it's stateless. One round trip time, and no "daemons" required. > PPP has to happen and then DHCP. For a > rapidly moving client this may add to some optimization issue. I think that's nonsense because it ignores the larger picture. When you switch SIP servers, you lose whatever state you had with the previous server. You likely need to redo computationally complex operations such as public key crypto to secure the new connection. That's probably the least of the worries. However, this is IP. IP doesn't care when links go up and down. There's no reason you can't switch PPP links and keep the *same* SIP server address over the transition. Then, if you feel compelled to do so, issue a DHCPINFORM message when you have the time, and if the reply specifies a new SIP server address, switch. You can do make-before-break and avoid any loss of service. In addition to this, we're talking about a single round trip time. Unless that cell phone is just doing nothing at all, any activity it might do over IP dwarfs that one packet exchange. Finally, if you're using a SIP server, the information you get back includes things such as host names and addresses of other systems to contact. Again, the actual exchanges involved in even the lightest transaction there dwarf the time it takes to discover the SIP server address from a relatively local DHCP server. So, I don't buy it. I don't see how this is a worthwhile optimization in any case, and it seems quite obvious that it's not generally useful (nodes one or more hops away from the PPP link have no way to know what was negotiated) and hard to deploy. > Thus if the client is moving between PDSNs this may be bit overkill > but may work out well if the same client moves between CDMA2000 > network and WiFi for example. The same issues exist there. And, in fact, the implementation with DHCP alone is *much* simpler, because you don't have to deal with determining whether this new IPCP option (for the CDMA2000 link) or DHCP (on WiFi) is authoritative. Just rely on the DHCP answer in any case. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Nov 23 09:44:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eevr7-0002sB-8f; Wed, 23 Nov 2005 09:44:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eevr5-0002ql-WB for pppext@megatron.ietf.org; Wed, 23 Nov 2005 09:44:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09914 for ; Wed, 23 Nov 2005 09:43:35 -0500 (EST) Received: from 66.237.112.74.ptr.us.xo.net ([66.237.112.74] helo=lithik.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eew9x-0005eF-9Q for pppext@ietf.org; Wed, 23 Nov 2005 10:03:46 -0500 Received: from [24.93.124.171] (account karl HELO [10.0.0.3]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1135796; Wed, 23 Nov 2005 09:44:10 -0500 In-Reply-To: <17284.30601.11967.29171@gargle.gargle.HOWL> References: <17283.22409.82105.121294@gargle.gargle.HOWL> <200511231327.IAA01530@breeze.research.telcordia.com> <17284.30601.11967.29171@gargle.gargle.HOWL> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C1D5ABE-1760-43AA-B355-B0791471F7C7@columbus.rr.com> Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] IPCP option for SIP server Date: Wed, 23 Nov 2005 09:44:03 -0500 To: James Carlson X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org And of course, we should all remember that the only issue of official concern to this audience is, "Is a protocol change necessary?" The answer has already been established: No. DHCP is the perfect solution for this problem. Karl On Nov 23, 2005, at 9:07 AM, James Carlson wrote: > Ashutosh Dutta writes: >> James, I can think of some optimization issue such as follows: >> >> By running DHCPclient on the mobile while the mobile is using >> CDMA2000 >> RAN, one uses PPP to obtain an IP address and DHCPclient to >> obtain >> other server parameters and one needs to run both the daemons on >> the >> client to get fully configured. > What "daemons?" That's an implementation issue. > > As for DHCP, we're talking about a single UDP packet exchange -- send, > receive. That's it; it's stateless. One round trip time, and no > "daemons" required. > >> PPP has to happen and then DHCP. For a >> rapidly moving client this may add to some optimization issue. > I think that's nonsense because it ignores the larger picture. > > When you switch SIP servers, you lose whatever state you had with the > previous server. You likely need to redo computationally complex > operations such as public key crypto to secure the new connection. > That's probably the least of the worries. > > However, this is IP. IP doesn't care when links go up and down. > There's no reason you can't switch PPP links and keep the *same* SIP > server address over the transition. Then, if you feel compelled to do > so, issue a DHCPINFORM message when you have the time, and if the > reply specifies a new SIP server address, switch. > > You can do make-before-break and avoid any loss of service. > > In addition to this, we're talking about a single round trip time. > Unless that cell phone is just doing nothing at all, any activity it > might do over IP dwarfs that one packet exchange. > > Finally, if you're using a SIP server, the information you get back > includes things such as host names and addresses of other systems to > contact. Again, the actual exchanges involved in even the lightest > transaction there dwarf the time it takes to discover the SIP server > address from a relatively local DHCP server. > > So, I don't buy it. I don't see how this is a worthwhile optimization > in any case, and it seems quite obvious that it's not generally useful > (nodes one or more hops away from the PPP link have no way to know > what was negotiated) and hard to deploy. > >> Thus if the client is moving between PDSNs this may be bit >> overkill >> but may work out well if the same client moves between >> CDMA2000 >> network and WiFi for example. > The same issues exist there. And, in fact, the implementation with > DHCP alone is *much* simpler, because you don't have to deal with > determining whether this new IPCP option (for the CDMA2000 link) or > DHCP (on WiFi) is authoritative. Just rely on the DHCP answer in any > case. > > -- > James Carlson, KISS Network > > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Nov 23 11:02:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eex4K-0005Bb-TN; Wed, 23 Nov 2005 11:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eex4I-0005BH-T9 for pppext@megatron.ietf.org; Wed, 23 Nov 2005 11:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19581 for ; Wed, 23 Nov 2005 11:01:18 -0500 (EST) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EexNA-0001zf-Dr for pppext@ietf.org; Wed, 23 Nov 2005 11:21:29 -0500 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id jANG1eOx036649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Wed, 23 Nov 2005 09:01:40 -0700 (MST) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id jANG1eSk036648 for pppext@ietf.org; Wed, 23 Nov 2005 09:01:40 -0700 (MST) Date: Wed, 23 Nov 2005 09:01:40 -0700 (MST) From: Vernon Schryver Message-Id: <200511231601.jANG1eSk036648@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: <0C1D5ABE-1760-43AA-B355-B0791471F7C7@columbus.rr.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: Karl Fox > And of course, we should all remember that the only issue of official > concern to this audience is, "Is a protocol change necessary?" The > answer has already been established: No. DHCP is the perfect > solution for this problem. Exactly. We heard the "optimization" arguments many times over the years. They are utterly wrong, and always come from either people who have no implementation experience or from people in big, disfunctional organzations who feel that they can add code to their employer's PPP implementation but not its DHCP implementation. The other person in this case is probably in the first group, since otherwise there would be no claims that DHCP would not already be in use for getting the other parameters that are already in DHCP but not in IPCP. For example, isn't cellphone likely to want to do email? Someone recently asked me privately about adding timezone name and offset or Olson database pointer to IPCP. That he accepted the pointer to DHCP was a pleasant change of pace, but then he has been around for a while. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Nov 23 11:08:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexAB-0006qg-U5; Wed, 23 Nov 2005 11:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexAA-0006q7-Ib for pppext@megatron.ietf.org; Wed, 23 Nov 2005 11:08:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20292 for ; Wed, 23 Nov 2005 11:07:20 -0500 (EST) Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EexSz-0002O1-27 for pppext@ietf.org; Wed, 23 Nov 2005 11:27:31 -0500 Received: from breeze.research.telcordia.com (breeze.research.telcordia.com [192.4.16.9]) by thumper.research.telcordia.com (8.12.9/8.12.9) with ESMTP id jANG7dKm015888; Wed, 23 Nov 2005 11:07:39 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by breeze.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA08589; Wed, 23 Nov 2005 11:07:39 -0500 (EST) Message-Id: <200511231607.LAA08589@breeze.research.telcordia.com> To: James Carlson Subject: Re: [Pppext] IPCP option for SIP server In-reply-to: Your message of "Wed, 23 Nov 2005 09:07:05 EST." <17284.30601.11967.29171@gargle.gargle.HOWL> Date: Wed, 23 Nov 2005 11:07:38 -0500 From: Ashutosh Dutta X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org James, Your points are well taken and I have really enjoyed having a good technical discussion on this topic here. I realize DHCP can do the trick over PPP link to get the server address configuration parameters. Just to reiterate, there are cases where each PDSN may have a different outbound proxy associated with it. Thus as the mobile mobile moves between PDSNs within the same DNS domain or AAA domain , it may end up getting a new outbound proxy or P-CSCF (in IMS language) during each transition. The point I was trying to make was that timing associated with outbound proxy configuration should not be neglected and should be considered during any handover optimization. Of course there are many ways it can be done, such as make-before-break as you have indicated. I was hoping if it can as well be done during the PPP negotiation phase itself, but DHCP appears to be cleaner solution at the moment, albeit an extra pair of message exchange. Regards Ashutosh > Ashutosh Dutta writes: > > James, I can think of some optimization issue such as follows: > > > > By running DHCPclient on the mobile while the mobile is using CDMA2000 > > RAN, one uses PPP to obtain an IP address and DHCPclient to obtain > > other server parameters and one needs to run both the daemons on the > > client to get fully configured. > > What "daemons?" That's an implementation issue. > > As for DHCP, we're talking about a single UDP packet exchange -- send, > receive. That's it; it's stateless. One round trip time, and no > "daemons" required. > > > PPP has to happen and then DHCP. For a > > rapidly moving client this may add to some optimization issue. > > I think that's nonsense because it ignores the larger picture. > > When you switch SIP servers, you lose whatever state you had with the > previous server. You likely need to redo computationally complex > operations such as public key crypto to secure the new connection. > That's probably the least of the worries. > > However, this is IP. IP doesn't care when links go up and down. > There's no reason you can't switch PPP links and keep the *same* SIP > server address over the transition. Then, if you feel compelled to do > so, issue a DHCPINFORM message when you have the time, and if the > reply specifies a new SIP server address, switch. > > You can do make-before-break and avoid any loss of service. > > In addition to this, we're talking about a single round trip time. > Unless that cell phone is just doing nothing at all, any activity it > might do over IP dwarfs that one packet exchange. > > Finally, if you're using a SIP server, the information you get back > includes things such as host names and addresses of other systems to > contact. Again, the actual exchanges involved in even the lightest > transaction there dwarf the time it takes to discover the SIP server > address from a relatively local DHCP server. > > So, I don't buy it. I don't see how this is a worthwhile optimization > in any case, and it seems quite obvious that it's not generally useful > (nodes one or more hops away from the PPP link have no way to know > what was negotiated) and hard to deploy. > > > Thus if the client is moving between PDSNs this may be bit overkill > > but may work out well if the same client moves between CDMA2000 > > network and WiFi for example. > > The same issues exist there. And, in fact, the implementation with > DHCP alone is *much* simpler, because you don't have to deal with > determining whether this new IPCP option (for the CDMA2000 link) or > DHCP (on WiFi) is authoritative. Just rely on the DHCP answer in any > case. > > -- > James Carlson, KISS Network > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 Ashutosh _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Nov 23 11:24:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexQI-0002Mx-Nm; Wed, 23 Nov 2005 11:24:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexQH-0002Lw-JP for pppext@megatron.ietf.org; Wed, 23 Nov 2005 11:24:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22611 for ; Wed, 23 Nov 2005 11:24:01 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eexj9-0003Um-V5 for pppext@ietf.org; Wed, 23 Nov 2005 11:44:13 -0500 Received: from c-67-182-139-247.hsd1.wa.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.51) id 1EexQ8-00089z-Ua; Wed, 23 Nov 2005 11:24:33 -0500 Received: by internaut.com (Postfix, from userid 1000) id 45B065EC09; Wed, 23 Nov 2005 08:24:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 38BB65EC08; Wed, 23 Nov 2005 08:24:32 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Wed, 23 Nov 2005 08:24:32 -0800 (PST) From: Bernard Aboba To: Ashutosh Dutta Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: <200511231327.IAA01530@breeze.research.telcordia.com> Message-ID: References: <200511231327.IAA01530@breeze.research.telcordia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: pppext@ietf.org, James Carlson , Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > By running DHCPclient on the mobile while the mobile is using CDMA2000 > RAN, one uses PPP to obtain an IP address and DHCPclient to obtain > other server parameters and one needs to run both the daemons on the > client to get fully configured. PPP has to happen and then DHCP. For a > rapidly moving client this may add to some optimization issue. Actually, the opposite is true. Doing IP configuration down in the link layer rather than in a single uniform way in the Internet layer would require hosts to implement a different configuration mechanism for each link type. As hosts become increasingly multi-homed, this could lead to interoperability problems, code bloat, and slow handoffs. Since this question keeps coming up again and again, perhaps we need a document describing the basic principles. A somewhat sketchy beginning is available here: http://www.drizzle.com/~aboba/IAB/draft-iab-config-secure-00.txt _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Wed Nov 23 11:33:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexZA-00069q-EI; Wed, 23 Nov 2005 11:33:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EexZ8-00069g-CQ for pppext@megatron.ietf.org; Wed, 23 Nov 2005 11:33:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23437 for ; Wed, 23 Nov 2005 11:33:09 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eexrw-000434-Gc for pppext@ietf.org; Wed, 23 Nov 2005 11:53:22 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id jANGXg3F007365 for ; Wed, 23 Nov 2005 09:33:42 -0700 (MST) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id jANGXgWc000131 for ; Wed, 23 Nov 2005 11:33:42 -0500 (EST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id jANGXg1m006798; Wed, 23 Nov 2005 11:33:42 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id jANGXg7u006795; Wed, 23 Nov 2005 11:33:42 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17284.39398.210429.744696@gargle.gargle.HOWL> Date: Wed, 23 Nov 2005 11:33:42 -0500 From: James Carlson To: Ashutosh Dutta Subject: Re: [Pppext] IPCP option for SIP server In-Reply-To: Ashutosh Dutta's message of 23 November 2005 11:07:38 References: <17284.30601.11967.29171@gargle.gargle.HOWL> <200511231607.LAA08589@breeze.research.telcordia.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org, Karl Fox X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Ashutosh Dutta writes: > Just to reiterate, there are cases where each PDSN may have a > different outbound proxy associated with it. Thus as the mobile > mobile moves between PDSNs within the same DNS domain or AAA > domain , it may end up getting a new outbound proxy or P-CSCF > (in IMS language) during each transition. I agree that overconstrained problems are difficult to solve. That doesn't mean that adding options to PPP is really the right answer. > The point I was > trying to make was that timing associated with outbound proxy > configuration should not be neglected and should be considered > during any handover optimization. Of course there are many ways > it can be done, such as make-before-break as you have > indicated. I was hoping if it can as well be done during the > PPP negotiation phase itself, but DHCP appears to be cleaner > solution at the moment, albeit an extra pair of message > exchange. I agree that performance is important, but I wouldn't suggest a micro- optimization such as this (moving an option from one protocol to another) unless we've got hard data showing that this is an important consideration (compared to all the other issues; there's no need to optimize away 1% of the problem) and that there aren't more global optimizations possible. Such as, for instance, fixing the deployment so that these SIP servers are accessible from adjacent cells. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Nov 24 05:07:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfE0v-00032n-Q5; Thu, 24 Nov 2005 05:07:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfE0u-00031F-Is for pppext@megatron.ietf.org; Thu, 24 Nov 2005 05:07:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10416 for ; Thu, 24 Nov 2005 05:06:55 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1+ihNLR5PgEs10ajsiUP5HQhzUBBfdTwHY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfEJv-00067p-ML for pppext@ietf.org; Thu, 24 Nov 2005 05:27:17 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX19QWcUMszSB1fJqQ0lY2MA5WL825QjjX/4@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jAOA7TTS008932 for ; Thu, 24 Nov 2005 10:07:32 GMT Date: Thu, 24 Nov 2005 10:07:29 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: pppext@ietf.org Message-ID: Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi, I have a question about this draft: Why would it not suffice to simply specify a "I can ignore the RFC2516 1492 limit" tag in PADI and PADRs? Indeed, why do you even need to signal this? :) The problem, AIUI, is not a lack of a MTU-negotiation feature in PPP, but just that limit. So all that needs to be signalled is the removal of that limit, rather than an additional MxU value - if it even needs to be signalled seperately.. Signalling an additional value seems to complicate things to my mind, further it raises questions about exactly what it represents (ie the MxU of which underlying link exactly?) and who should be setting it (the DSLAM, the BAS? What if both want to set it?). regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The last thing one knows in constructing a work is what to put first. -- Blaise Pascal _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Nov 24 08:52:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHWc-0001yg-Pr; Thu, 24 Nov 2005 08:52:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHWa-0001yY-TO for pppext@megatron.ietf.org; Thu, 24 Nov 2005 08:52:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02090 for ; Thu, 24 Nov 2005 08:51:52 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfHpc-0006SN-BN for pppext@ietf.org; Thu, 24 Nov 2005 09:12:15 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D141612B86B7; Thu, 24 Nov 2005 05:52:19 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25356-09; Thu, 24 Nov 2005 05:52:19 -0800 (PST) Received: from PARBETM2XP (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 80D1C12B86B6; Thu, 24 Nov 2005 05:52:18 -0800 (PST) From: "Peter Arberg" To: "'Paul Jakma'" , Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt Date: Thu, 24 Nov 2005 14:52:14 +0100 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcXw30vM3w2uZB9ES1icpOOXWPZtqgAGt4wQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051124135218.80D1C12B86B6@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi Paul, I have answered your questions inline in the email. > Hi, > > I have a question about this draft: > > Why would it not suffice to simply specify a "I can ignore the > RFC2516 1492 limit" tag in PADI and PADRs? Indeed, why do you even > need to signal this? :) This was discussed initially, as it was also our first thinking, but for optimization purpose it was suggested to include the max. payload number as well. The idea of the new option was to have the PPPoE client communicate in the PADI and PADR the maximum MTU/MRU it can deal with. Then the PPPoE server will have a good hint to immediately select a proper value for the MRU to propose in its LCP config_req. This would make the regular case more streamlined. > The problem, AIUI, is not a lack of a MTU-negotiation feature in PPP, > but just that limit. So all that needs to be signalled is the removal > of that limit, rather than an additional MxU value - if it even needs > to be signalled seperately.. Correct, this is simply a message from the PPPoE client that it can handle a PPP MRU negotiation upto limit-value. > Signalling an additional value seems to complicate things to my mind, > further it raises questions about exactly what it represents (ie the > MxU of which underlying link exactly?) and who should be setting it > (the DSLAM, the BAS? What if both want to set it?). It was not the intention to complicate things, simply to make the negotiation more streamlined. And when the TAG had to be included, it did not seem like an issue to include the max MxU number. The number is only to be set by the PPPoE client side, never from the server (BRAS) side, the PPPoE server will echo the clients value back as a okay lets do PPP MRU negotiation to settle on a value. cheers, Peter > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > The last thing one knows in constructing a work is what to put first. > -- Blaise Pascal > > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Nov 24 09:13:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHr3-0001bW-AG; Thu, 24 Nov 2005 09:13:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfHr2-0001bK-5R for pppext@megatron.ietf.org; Thu, 24 Nov 2005 09:13:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04745 for ; Thu, 24 Nov 2005 09:12:59 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/ZD+0jQQiyALzc/TSkUJKD19JlNRh2anA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfIA5-0007PX-BY for pppext@ietf.org; Thu, 24 Nov 2005 09:33:23 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1896rHSCksIwQ/8sluG5nVG2ZZcSA2PuvY@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jAOEDVqm012378; Thu, 24 Nov 2005 14:13:35 GMT Date: Thu, 24 Nov 2005 14:13:31 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Peter Arberg Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt In-Reply-To: <20051124135218.80D1C12B86B6@prattle.redback.com> Message-ID: References: <20051124135218.80D1C12B86B6@prattle.redback.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org On Thu, 24 Nov 2005, Peter Arberg wrote: > This was discussed initially, as it was also our first thinking, > but for optimization purpose it was suggested to include the max. > payload number as well. I did try look over the previous discussions, I read the thread where it was suggested to introduce new tags, I didn't see any discussion of including a payload size though - never mind the rationale for doing so. > The idea of the new option was to have the PPPoE client communicate > in the PADI and PADR the maximum MTU/MRU it can deal with. Then the > PPPoE server will have a good hint to immediately select a proper > value for the MRU to propose in its LCP config_req. This would make > the regular case more streamlined. Right, I did read the RFC. ;) It doesn't give any rationale for why it's a good idea to include a "Max-Payload" value in the tag though. > It was not the intention to complicate things, simply to make the > negotiation more streamlined. And when the TAG had to be included, > it did not seem like an issue to include the max MxU number. It's an additional piece of state for: a) implementations to have to track and hence get wrong b) future refinements to have to bear in mind wrt backward-compatibility. Making it be just a "remove the RFC2561 limit" flag simply reduces things back to normal PPP, at least wrt MRU/MTU negotiation. > The number is only to be set by the PPPoE client side, never from > the server (BRAS) side, the PPPoE server will echo the clients > value back as a okay lets do PPP MRU negotiation to settle on a > value. Why can't the client just start doing MRU/MTU negotiation as part of PPP setup, as it will have to do anyway? Why add an additional value into the mix? This Max-Payload value seems quite redundant. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "The medium is the message." -- Marshall McLuhan _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Nov 24 18:38:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQfc-0005gc-UK; Thu, 24 Nov 2005 18:38:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfQfb-0005fQ-LN for pppext@megatron.ietf.org; Thu, 24 Nov 2005 18:38:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11358 for ; Thu, 24 Nov 2005 18:37:46 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfQyl-0004jd-7D for pppext@ietf.org; Thu, 24 Nov 2005 18:58:15 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id DFDC0B61367; Thu, 24 Nov 2005 15:38:12 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13975-08; Thu, 24 Nov 2005 15:38:12 -0800 (PST) Received: from PARBETM2XP (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 5B661B61365; Thu, 24 Nov 2005 15:38:11 -0800 (PST) From: "Peter Arberg" To: "'Paul Jakma'" Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt Date: Fri, 25 Nov 2005 00:38:06 +0100 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcXxAUtE4HQI+Rp8SS22nXUsQS4D2QACj8MQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051124233811.5B661B61365@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > -----Original Message----- > From: Paul Jakma [mailto:paul@clubi.ie] > Sent: 24. november 2005 15:14 > To: Peter Arberg > Cc: pppext@ietf.org > Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt > > On Thu, 24 Nov 2005, Peter Arberg wrote: > > > This was discussed initially, as it was also our first thinking, > > but for optimization purpose it was suggested to include the max. > > payload number as well. > > I did try look over the previous discussions, I read the thread where > it was suggested to introduce new tags, I didn't see any discussion > of including a payload size though - never mind the rationale for > doing so. sorry, should have said, discussed initially between co-authors and people in the ack. section.. > > The idea of the new option was to have the PPPoE client communicate > > in the PADI and PADR the maximum MTU/MRU it can deal with. Then the > > PPPoE server will have a good hint to immediately select a proper > > value for the MRU to propose in its LCP config_req. This would make > > the regular case more streamlined. > > Right, I did read the RFC. ;) > > It doesn't give any rationale for why it's a good idea to include a > "Max-Payload" value in the tag though. > > > It was not the intention to complicate things, simply to make the > > negotiation more streamlined. And when the TAG had to be included, > > it did not seem like an issue to include the max MxU number. > > It's an additional piece of state for: > > a) implementations to have to track and hence get wrong > > b) future refinements to have to bear in mind wrt > backward-compatibility. > > Making it be just a "remove the RFC2561 limit" flag simply reduces > things back to normal PPP, at least wrt MRU/MTU negotiation. > > > The number is only to be set by the PPPoE client side, never from > > the server (BRAS) side, the PPPoE server will echo the clients > > value back as a okay lets do PPP MRU negotiation to settle on a > > value. > > Why can't the client just start doing MRU/MTU negotiation as part of > PPP setup, as it will have to do anyway? Why add an additional value > into the mix? The problem is that not all PPP hosts do perform a MRU negotiation, it is optional. And further more we also have seen PPPoE clients who perform a MRU negotiation of 1500 but can not accept the value. The PPPoE MRU Tag is intented for 2 purposes, the one is for "normal" PPPoE clients who wish to negotiate a higher MRU, and as such this is a way for the BRAS to know this is a new client and it is safe to negotiate above 1492, all the way up to the Max-Payload value, yes this could have been handled with out the value, with a simple flag Tag, if we could be sure all clients will perform MRU negotiation. The second case is the setup where a DSLAM will act as a PPPoA to oE interworking device, and initiate the PPPoE discovery phase. In this case the DSLAM knows we are dealing with a PPP(oA) host and as such can send the Max-Payload value of 1500. Could this have been handled with a simple flag Tag, yes I guess it could. The problem is inbetween, I know it is proabably not a real life situation, but you never know, if a "normal" PPPoE client can handle higher than 1492, but can not handle 1500 ?? agree sounds far out, this case could not be handled without the value in the Tag, as long as you not know for sure that the client will perform a MRU negotiation, and many don't. So as far as I remember, this was the reason along with the fact to streamline the MRU negotiation, where the BRAS knows what value to suggest in the initial MRU negotiation so it do not have to go back and forth, it was an intention to help speed up the negotiation. And then we never saw it as a problem to include the value, and neither did any of the PPPoE client vendors we discussed it with, agreeing to include a new PPPoE Tag was the biggest problem, the value seemed a small topic compared to that. cheers, Peter > > This Max-Payload value seems quite redundant. > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > "The medium is the message." > -- Marshall McLuhan > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Nov 25 02:20:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfXsu-00076z-W2; Fri, 25 Nov 2005 02:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfXsu-000763-5O for pppext@megatron.ietf.org; Fri, 25 Nov 2005 02:20:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20025 for ; Fri, 25 Nov 2005 02:19:59 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX19CL1QNvjgeuQwbogl6I8Pr4P1HATl+1xc=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfYC7-00027w-1s for pppext@ietf.org; Fri, 25 Nov 2005 02:40:31 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/uUKlKgw7gBwSS5mb5R3KF3UoR4llG31k@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jAP7KV96023733; Fri, 25 Nov 2005 07:20:35 GMT Date: Fri, 25 Nov 2005 07:20:31 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Peter Arberg Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt In-Reply-To: <20051124233811.5B661B61365@prattle.redback.com> Message-ID: References: <20051124233811.5B661B61365@prattle.redback.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi Peter, On Fri, 25 Nov 2005, Peter Arberg wrote: > The problem is that not all PPP hosts do perform a MRU negotiation, > it is optional. And further more we also have seen PPPoE clients > who perform a MRU negotiation of 1500 but can not accept the value. That's fine though surely? If a client doesn't do negotiation (e.g. it doesnt or isnt capable of > 1492 MRU/MTU), it doesn't negotiate. Simple. The MRU is 1492, unless it indicates it's a 2561bis PPPoE implementation by adding the tag, in which case normal PPP defaults apply. As for clients getting it wrong, what's to prevent them getting it wrong if Max-Payload also carries a value? One would hope though that any PPPoE implementation which is updated to support either a Max-Payload or "Ignore the 2561 limit tag" is then tested to make sure negotiation (as well as 1500 default) actually works. > The PPPoE MRU Tag is intented for 2 purposes, the one is for > "normal" PPPoE clients who wish to negotiate a higher MRU, and as > such this is a way for the BRAS to know this is a new client and it > is safe to negotiate above 1492, all the way up to the Max-Payload > value, yes this could have been handled with out the value, with a > simple flag Tag, if we could be sure all clients will perform MRU > negotiation. See above, why ever would an implementation be updated to include a tag and then /not/ support either the PPP 1500 default, or negotiation if larger sizes were desired? If the problem is quality of implementations, then adding further variables into the mix (an additional "Max-Payload" value) does not seem any more likely to improve their quality ;). > interworking device, and initiate the PPPoE discovery phase. In > this case the DSLAM knows we are dealing with a PPP(oA) host and as > such can send the Max-Payload value of 1500. Could this have been > handled with a simple flag Tag, yes I guess it could. Right. Unless you're envisaging that the "Max-Payload" is /not/ known to the BAS, but only to some DSLAM further along the path. In which case I can see why you'd want a DSLAM to be able to 'interject' and add this "Max-Payload" hint. However, the draft seems to envisage that PPPoE will be run between DSLAM and BAS, hence the BAS /is/ quite aware of it - and there was mention before that the path MTU would be known in advance to the operators. Even so, such case, to my mind, would raise further questions about exactly /who/ is allowed to add Max-Payload along the way, whether Max-Payload may be replaced if it already exists (only downward change makes sense I guess) and error cases. Etc. None of which is covered in the draft, afaict. > The problem is inbetween, I know it is proabably not a real life > situation, but you never know, if a "normal" PPPoE client can > handle higher than 1492, but can not handle 1500 ?? agree sounds > far out, this case could not be handled without the value in the > Tag, as long as you not know for sure that the client will perform > a MRU negotiation, and many don't. Why would a PPPoE implementation be updated to support a "Ignore-2561-MRU-Limit" tag and then not support either the default of 1500, or any other negotiated MRU? :) > So as far as I remember, this was the reason along with the fact to > streamline the MRU negotiation, where the BRAS knows what value to > suggest in the initial MRU negotiation so it do not have to go back > and forth, it was an intention to help speed up the negotiation. How much of an overhead would this be really, compared to the rest of PPP LCP and IPCP? (Which already is pretty much "instant" on decent links, at least as far as a human can tell). Further, isn't it likely that the vast majority of deployments will simply use the default 1500 PPP MxU? In which case no negotiation would be needed at all. > And then we never saw it as a problem to include the value, and > neither did any of the PPPoE client vendors we discussed it with, > agreeing to include a new PPPoE Tag was the biggest problem, the > value seemed a small topic compared to that. The tag seems uncontraversial, its required to signal the lifting of a quite needless/silly restriction in 2561. However inventing additional MxU negotiation mechanisms on top of that, when PPP already provides: a) The value nearly everyone will want to use (1500) as a *default* b) A perfectly fine MRU negotiation mechanism[1] Seems redundant. If there is no need for it, then why include it? If so: at best it does no harm and nothing else, at worst it's yet another thing for an implementation to get wrong, no? Including a value is also more baggage for future RFC authors to potentially have to consider wrt backward-compatibility issues - having just a 'flag' tag reduces PPPoE back to normal PPP wrt MxU (so even if future RFC authors fail to consider that tag and only consider 'plain' PPP, it won't make any difference). I.e. I think it just might be simpler all round to /not/ include a value, unless there is a pressing reason to do so. "Well, it's easy to put a value in there" doesn't seem a good enough reason - what problem does it solve? If none, why add it? > cheers, > Peter 1. Which is what should have been specified for the 1492 MTU which 2561 wanted, rather than encode it as a hard-limit into the RFC, then we'd not be having this conversation now. ;) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: "What if" is a trademark of Hewlett Packard, so stop using it in your sentences without permission, or risk being sued. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Nov 25 07:39:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efcr6-0005QY-2g; Fri, 25 Nov 2005 07:39:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efcr4-0005Nl-0c for pppext@megatron.ietf.org; Fri, 25 Nov 2005 07:39:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19769 for ; Fri, 25 Nov 2005 07:38:23 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfdAK-0004aD-5U for pppext@ietf.org; Fri, 25 Nov 2005 07:59:00 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 1129FD318CD; Fri, 25 Nov 2005 04:38:52 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10941-06; Fri, 25 Nov 2005 04:38:51 -0800 (PST) Received: from PARBETM2XP (login-1-300.redback.com [155.53.12.153]) by prattle.redback.com (Postfix) with ESMTP id 63450D318CB; Fri, 25 Nov 2005 04:38:50 -0800 (PST) From: "Peter Arberg" To: "'Paul Jakma'" Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt Date: Fri, 25 Nov 2005 13:38:45 +0100 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXxkMHdIb6mPQ8DTx2cFYfceizFNgAJi8rA Message-Id: <20051125123850.63450D318CB@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi Paul, I used a wrong word, > > The problem is that not all PPP hosts do perform a MRU negotiation, > > it is optional. And further more we also have seen PPPoE clients > > who perform a MRU negotiation of 1500 but can not accept the value. It should have been "handle" instead of "accept". We have seen PPPoE clients negotiate MRU 1500, but can not handle packets received with a payload of 1500. I agree on your comments, that the reasoning for the value is not strong, it is the small differences there decided to add the value instead of leaving the flag only. 1. handle all cases where MRU not negotiated, also a client between 1492 and 1500 2. set the hint for the MRU suggestion to speed up negotiation I agree RFC2516 could have been worded different, and we would not have had this draft at all, but that's history and difficult to change ;) I'm not sure what "backward-compatibility issues" you refer to, but remember that the value in no way removes or changes the PPP MRU negotiation, it is simply a out-of-band hint for the PPPoE server to what MRU max value the client will be able to handle, but the PPP negotiation will be used to agree on this. I have no problem making the value optional, so if the Tag is used with a 0-length data section, it will by default say a 1500 Max-Payload, but at the same time I do not see a need to change it unless there is more people who see a problem using the value. It would be good to hear if anybody else on the list see a problem with the inclusion of the value in the PPPoE Tag. thanks, Peter > -----Original Message----- > From: Paul Jakma [mailto:paul@clubi.ie] > Sent: 25. november 2005 08:21 > To: Peter Arberg > Cc: pppext@ietf.org > Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt > > Hi Peter, > > On Fri, 25 Nov 2005, Peter Arberg wrote: > > > The problem is that not all PPP hosts do perform a MRU negotiation, > > it is optional. And further more we also have seen PPPoE clients > > who perform a MRU negotiation of 1500 but can not accept the value. > > That's fine though surely? > > If a client doesn't do negotiation (e.g. it doesnt or isnt capable of > > 1492 MRU/MTU), it doesn't negotiate. Simple. The MRU is 1492, > unless it indicates it's a 2561bis PPPoE implementation by adding the > tag, in which case normal PPP defaults apply. > > As for clients getting it wrong, what's to prevent them getting it > wrong if Max-Payload also carries a value? One would hope though that > any PPPoE implementation which is updated to support either a > Max-Payload or "Ignore the 2561 limit tag" is then tested to make > sure negotiation (as well as 1500 default) actually works. > > > The PPPoE MRU Tag is intented for 2 purposes, the one is for > > "normal" PPPoE clients who wish to negotiate a higher MRU, and as > > such this is a way for the BRAS to know this is a new client and it > > is safe to negotiate above 1492, all the way up to the Max-Payload > > value, yes this could have been handled with out the value, with a > > simple flag Tag, if we could be sure all clients will perform MRU > > negotiation. > > See above, why ever would an implementation be updated to include a > tag and then /not/ support either the PPP 1500 default, or > negotiation if larger sizes were desired? > > If the problem is quality of implementations, then adding further > variables into the mix (an additional "Max-Payload" value) does not > seem any more likely to improve their quality ;). > > > interworking device, and initiate the PPPoE discovery phase. In > > this case the DSLAM knows we are dealing with a PPP(oA) host and as > > such can send the Max-Payload value of 1500. Could this have been > > handled with a simple flag Tag, yes I guess it could. > > Right. > > Unless you're envisaging that the "Max-Payload" is /not/ known to the > BAS, but only to some DSLAM further along the path. In which case I > can see why you'd want a DSLAM to be able to 'interject' and add this > "Max-Payload" hint. However, the draft seems to envisage that PPPoE > will be run between DSLAM and BAS, hence the BAS /is/ quite aware of > it - and there was mention before that the path MTU would be known > in advance to the operators. > > Even so, such case, to my mind, would raise further questions about > exactly /who/ is allowed to add Max-Payload along the way, whether > Max-Payload may be replaced if it already exists (only downward > change makes sense I guess) and error cases. Etc. None of which is > covered in the draft, afaict. > > > The problem is inbetween, I know it is proabably not a real life > > situation, but you never know, if a "normal" PPPoE client can > > handle higher than 1492, but can not handle 1500 ?? agree sounds > > far out, this case could not be handled without the value in the > > Tag, as long as you not know for sure that the client will perform > > a MRU negotiation, and many don't. > > Why would a PPPoE implementation be updated to support a > "Ignore-2561-MRU-Limit" tag and then not support either the default > of 1500, or any other negotiated MRU? :) > > > So as far as I remember, this was the reason along with the fact to > > streamline the MRU negotiation, where the BRAS knows what value to > > suggest in the initial MRU negotiation so it do not have to go back > > and forth, it was an intention to help speed up the negotiation. > > How much of an overhead would this be really, compared to the rest of > PPP LCP and IPCP? (Which already is pretty much "instant" on decent > links, at least as far as a human can tell). > > Further, isn't it likely that the vast majority of deployments will > simply use the default 1500 PPP MxU? In which case no negotiation > would be needed at all. > > > And then we never saw it as a problem to include the value, and > > neither did any of the PPPoE client vendors we discussed it with, > > agreeing to include a new PPPoE Tag was the biggest problem, the > > value seemed a small topic compared to that. > > The tag seems uncontraversial, its required to signal the lifting of > a quite needless/silly restriction in 2561. However inventing > additional MxU negotiation mechanisms on top of that, when PPP > already provides: > > a) The value nearly everyone will want to use (1500) as a *default* > > b) A perfectly fine MRU negotiation mechanism[1] > > Seems redundant. > > If there is no need for it, then why include it? If so: at best it > does no harm and nothing else, at worst it's yet another thing for an > implementation to get wrong, no? > > Including a value is also more baggage for future RFC authors to > potentially have to consider wrt backward-compatibility issues - > having just a 'flag' tag reduces PPPoE back to normal PPP wrt MxU (so > even if future RFC authors fail to consider that tag and only > consider 'plain' PPP, it won't make any difference). > > I.e. I think it just might be simpler all round to /not/ include a > value, unless there is a pressing reason to do so. "Well, it's easy > to put a value in there" doesn't seem a good enough reason - what > problem does it solve? If none, why add it? > > > cheers, > > Peter > > 1. Which is what should have been specified for the 1492 MTU which > 2561 wanted, rather than encode it as a hard-limit into the RFC, then > we'd not be having this conversation now. ;) > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > "What if" is a trademark of Hewlett Packard, so stop using it in your > sentences without permission, or risk being sued. > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Nov 25 08:39:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfdnT-0006uE-Df; Fri, 25 Nov 2005 08:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfdnR-0006u0-Ip for pppext@megatron.ietf.org; Fri, 25 Nov 2005 08:39:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25877 for ; Fri, 25 Nov 2005 08:38:45 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/epKhVN3hwg/Cq0i/p8+M3S8R+ThH2kIQ=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efe6i-0006rI-7I for pppext@ietf.org; Fri, 25 Nov 2005 08:59:20 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1+IMXUEHnsEBvciSpUMXTYBvnxdKWAAOME@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jAPDdCwL027824; Fri, 25 Nov 2005 13:39:16 GMT Date: Fri, 25 Nov 2005 13:39:12 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Peter Arberg Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt In-Reply-To: <20051125123850.63450D318CB@prattle.redback.com> Message-ID: References: <20051125123850.63450D318CB@prattle.redback.com> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org On Fri, 25 Nov 2005, Peter Arberg wrote: > It should have been "handle" instead of "accept". We have seen > PPPoE clients negotiate MRU 1500, but can not handle packets > received with a payload of 1500. Ah well. :) > I agree RFC2516 could have been worded different, and we would not > have had this draft at all, but that's history and difficult to > change ;) Indeed ;). > I'm not sure what "backward-compatibility issues" you refer to, Nor do I, but adding special-cases to protocols is what makes them progressively harder to revise. Hence, try avoid adding them unless required. > but remember that the value in no way removes or changes the PPP > MRU negotiation, it is simply a out-of-band hint for the PPPoE > server to what MRU max value the client will be able to handle, but > the PPP negotiation will be used to agree on this. It's more than a hint, it's a "MUST" for the server. Further, what happens if the client is also PPPoE? client<----PPPoE---->DSLAM<---------BAS The PPP session (and LCP MxU negotiation) is between the client and BAS, but the DSLAM handles the PPPoE session. What exactly is to happen here wrt the Max-Payload value? It's not specified is it? What happens if the right of the BAS looks like: BAS-------ISP Where the BAS is essentially just punting the PPP session on /again/ to another ISP (this is, sadly, how wholesale DSL via $incumbent_telco is provisioned in my country). The DSLAM may not have visibility of the MTU of this latter link (which might not be same size as the other). I.e. To my mind, adding ability for intermediaries to inject a hint opens the following questions: 1. What should occur if there are multiple intermediaries able to add this hint? The answer to that is probably not too tough (only ever allowed to reduce Max-Payload). But leads to: 2. What if some of the 'segments' are not PPPoE? (And hence, not able to 'forward' this Max-Payload tag) That one seems more difficult. ;) You could answer 2 with "well, operators will know in advance what the path MTU is and configure it statically", which is (if we assume PPPoE is acceptable) fine - but then why bother with putting the value in? Further, what if the 'client' also transposes the PPP connection from one transport to another? It gets messy really quickly imho. If you specify a mechanism to dynamically insert path-MTU hints into this PPP wrapper protocol then, IMHO, you also need to deal with the weird and wonderful ways this hint could be used, abused and interact. > I have no problem making the value optional, so if the Tag is used > with a 0-length data section, it will by default say a 1500 > Max-Payload, but at the same time I do not see a need to change it > unless there is more people who see a problem using the value. Well, see above for at least two problems with this value. > It would be good to hear if anybody else on the list see a problem > with the inclusion of the value in the PPPoE Tag. We could turn the poll the other way around: Does anyone think the tag should include the Max-Payload? ;) regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: Cheese -- milk's leap toward immortality. -- Clifton Fadiman, "Any Number Can Play" _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sun Nov 27 21:16:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgYZZ-0004Mh-76; Sun, 27 Nov 2005 21:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgYZX-0004MY-ME for pppext@megatron.ietf.org; Sun, 27 Nov 2005 21:16:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23152 for ; Sun, 27 Nov 2005 21:16:07 -0500 (EST) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgYtK-0000vN-7V for pppext@ietf.org; Sun, 27 Nov 2005 21:37:18 -0500 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id E955C1190C3B; Sun, 27 Nov 2005 18:16:33 -0800 (PST) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03482-08; Sun, 27 Nov 2005 18:16:33 -0800 (PST) Received: from PARBETM2XP (login003.redback.com [155.53.12.55]) by prattle.redback.com (Postfix) with ESMTP id 98B351190C3C; Sun, 27 Nov 2005 18:16:32 -0800 (PST) From: "Peter Arberg" To: "'Paul Jakma'" Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt Date: Sun, 27 Nov 2005 21:16:21 -0500 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcXxxasEEAVUG3HwTSSdEF0dSfpUsgB+JbZw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051128021632.98B351190C3C@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org snip.. > > client<----PPPoE---->DSLAM<---------BAS > > The PPP session (and LCP MxU negotiation) is between the client and > BAS, but the DSLAM handles the PPPoE session. What exactly is to > happen here wrt the Max-Payload value? It's not specified is it? I do not understand your comment, the DSLAM handles the PPPoE session, I think we have a slight misunderstanding here. The DSLAM will not be involved in any native PPPoE sessions initiated by a CPE equipment, and the Max-Payload Tag is only added by the PPPoE client who initiates the PPPoE discovery stage. So in you picture the "client" adds the Max-Payload Tag value and the DSLAM have no idea, and is not suppose to have any idea of what is going on in a PPPoE session. > > What happens if the right of the BAS looks like: > > BAS-------ISP > > Where the BAS is essentially just punting the PPP session on /again/ > to another ISP (this is, sadly, how wholesale DSL via > $incumbent_telco is provisioned in my country). The DSLAM may not > have visibility of the MTU of this latter link (which might not be > same size as the other). Yes this is a common PPP wholesale scenario, and the internet-draft do not make any suggestions to how the PPPoE MTU hint should be forwarded in the L2TP session. We have had some multivendor discussions on this with a few carriers, but the draft was not intended to take care of this, as we initially wanted to make sure we could increase the PPPoE MxU, and then another L2TP specific work can take the next step and make sure to expand the work. And yes we do have a suggestion to how this can be signaled in the L2TP, but different place, different discussion. > I.e. To my mind, adding ability for intermediaries to inject a hint > opens the following questions: This is not intended, it is intended to be a client-server Tag only no intermidiate systems should use/add or remove this tag. > 1. What should occur if there are multiple intermediaries able to add > this hint? They should not, this is only added by the client who initiates the PPPoE discovery phase, and used by/echoed back by the PPPoE server who is the other peer in the PPPoE discovery phase. > The answer to that is probably not too tough (only ever allowed to > reduce Max-Payload). But leads to: > > 2. What if some of the 'segments' are not PPPoE? (And hence, not able > to 'forward' this Max-Payload tag) again, the tag is not intended to take care of the underlying L2 MTU of the network, this is why we make the note: --- The procedure described in this document do not strictly conform to IEEE standards for Ethernet packet size, but rely on a widely deployed behavior of supporting jumbo frames on Ethernet segments. --- > > That one seems more difficult. ;) > > You could answer 2 with "well, operators will know in advance what > the path MTU is and configure it statically", which is (if we assume > PPPoE is acceptable) fine - but then why bother with putting the > value in? Further, what if the 'client' also transposes the PPP > connection from one transport to another? It gets messy really > quickly imho. > > If you specify a mechanism to dynamically insert path-MTU hints into > this PPP wrapper protocol then, IMHO, you also need to deal with the > weird and wonderful ways this hint could be used, abused and > interact. The Tag is a client-server information, not intended for any intermediate systems, this is not any different than any other PPPoE tag defined. > > I have no problem making the value optional, so if the Tag is used > > with a 0-length data section, it will by default say a 1500 > > Max-Payload, but at the same time I do not see a need to change it > > unless there is more people who see a problem using the value. > > Well, see above for at least two problems with this value. > > > It would be good to hear if anybody else on the list see a problem > > with the inclusion of the value in the PPPoE Tag. > > We could turn the poll the other way around: > Does anyone think the tag should include the Max-Payload? nice try, but read the draft again, as you can see at least 2 vendor companies and 1 carrier are co-authors, in the ack. section several other people from both vendor and carrier world is listed. The draft have been presented on the DSL Forum meeting in Philadelphia and no people objected to the value. I have listed 2 major reasons why it was included, and there are multi-vendor implementations today based on this suggestion in test at carriers network. I'm not saying this is a reason it should not be changed, I'm simply saying it shows that people have agreed to the suggestion, and we need some real good reasons to change it, better than future backward compatibility, and it seems more complicated than needed. thanks, Peter > > ;) > > regards, > -- > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > Cheese -- milk's leap toward immortality. > -- Clifton Fadiman, "Any Number Can Play" > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Nov 28 10:45:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglBd-0002mn-MF; Mon, 28 Nov 2005 10:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglBc-0002mc-Mh for pppext@megatron.ietf.org; Mon, 28 Nov 2005 10:45:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21934 for ; Mon, 28 Nov 2005 10:44:16 -0500 (EST) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EglVV-000261-97 for pppext@ietf.org; Mon, 28 Nov 2005 11:05:34 -0500 Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 15:44:39 +0000 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Nov 2005 15:44:39 +0000 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Nov 2005 10:44:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt Date: Mon, 28 Nov 2005 10:44:37 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280189CF5F@proton.jnpr.net> Thread-Topic: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt Thread-Index: AcXxxasEEAVUG3HwTSSdEF0dSfpUsgB+JbZwABx/frA= From: "Tom Mistretta" To: , "Paul Jakma" X-OriginalArrivalTime: 28 Nov 2005 15:44:38.0263 (UTC) FILETIME=[A3BE5870:01C5F432] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org The value in this tag was not added just for convenience. - While I am not going to defend it, it's possible to use jumbo-frames larger than 1500 (as opposed to in-between 1492 and 1500). - Additional negotiations and retries during LCP shouldn't be trivialized. - PPPoE has had a troubled history, partially due to assumptions that were made by different implementations (MxU, retry behavior etc). The use of an unqualified flag runs the risk of continuing that trend, either by placing assumptions on values or overloading the flag for other purposes. We are advocates of the specific value. Tom =20 -----Original Message----- From: pppext-bounces@ietf.org [mailto:pppext-bounces@ietf.org] On Behalf Of Peter Arberg Sent: Sunday, November 27, 2005 9:16 PM To: 'Paul Jakma' Cc: pppext@ietf.org Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt snip.. >=20 > client<----PPPoE---->DSLAM<---------BAS >=20 > The PPP session (and LCP MxU negotiation) is between the client and=20 > BAS, but the DSLAM handles the PPPoE session. What exactly is to=20 > happen here wrt the Max-Payload value? It's not specified is it? I do not understand your comment, the DSLAM handles the PPPoE session, I think we have a slight misunderstanding here. The DSLAM will not be involved in any native PPPoE sessions initiated by a CPE equipment, and the Max-Payload Tag is only added by the=20 PPPoE client who initiates the PPPoE discovery stage. So in you picture the "client" adds the Max-Payload Tag value and the DSLAM have no idea, and is not suppose to have any idea of what is going on in a PPPoE session. >=20 > What happens if the right of the BAS looks like: >=20 > BAS-------ISP >=20 > Where the BAS is essentially just punting the PPP session on /again/=20 > to another ISP (this is, sadly, how wholesale DSL via=20 > $incumbent_telco is provisioned in my country). The DSLAM may not=20 > have visibility of the MTU of this latter link (which might not be=20 > same size as the other). Yes this is a common PPP wholesale scenario, and the internet-draft do not make any suggestions to how the PPPoE MTU hint should be forwarded in the L2TP session. We have had some multivendor discussions on this with a few carriers, but the draft was not intended to take care of this, as we initially wanted to make sure we could increase the PPPoE MxU, and then another L2TP specific work can take the next step and make sure to expand the work. And yes we do have a suggestion to how this can be signaled in the L2TP, but different place, different discussion. > I.e. To my mind, adding ability for intermediaries to inject a hint=20 > opens the following questions: This is not intended, it is intended to be a client-server Tag only no intermidiate systems should use/add or remove this tag. > 1. What should occur if there are multiple intermediaries able to add=20 > this hint? They should not, this is only added by the client who initiates the=20 PPPoE discovery phase, and used by/echoed back by the PPPoE server who is the other peer in the PPPoE discovery phase. > The answer to that is probably not too tough (only ever allowed to=20 > reduce Max-Payload). But leads to: >=20 > 2. What if some of the 'segments' are not PPPoE? (And hence, not able > to 'forward' this Max-Payload tag) again, the tag is not intended to take care of the underlying L2 MTU of the network, this is why we make the note: --- The procedure described in this document do not strictly conform=20 to IEEE standards for Ethernet packet size, but rely on a widely=20 deployed behavior of supporting jumbo frames on Ethernet segments. --- >=20 > That one seems more difficult. ;) >=20 > You could answer 2 with "well, operators will know in advance what=20 > the path MTU is and configure it statically", which is (if we assume=20 > PPPoE is acceptable) fine - but then why bother with putting the=20 > value in? Further, what if the 'client' also transposes the PPP=20 > connection from one transport to another? It gets messy really=20 > quickly imho. >=20 > If you specify a mechanism to dynamically insert path-MTU hints into=20 > this PPP wrapper protocol then, IMHO, you also need to deal with the=20 > weird and wonderful ways this hint could be used, abused and=20 > interact. The Tag is a client-server information, not intended for any intermediate systems, this is not any different than any other PPPoE tag defined. > > I have no problem making the value optional, so if the Tag is used=20 > > with a 0-length data section, it will by default say a 1500=20 > > Max-Payload, but at the same time I do not see a need to change it=20 > > unless there is more people who see a problem using the value. >=20 > Well, see above for at least two problems with this value. >=20 > > It would be good to hear if anybody else on the list see a problem > > with the inclusion of the value in the PPPoE Tag. >=20 > We could turn the poll the other way around: > Does anyone think the tag should include the Max-Payload? nice try, but read the draft again, as you can see at least 2 vendor companies and 1 carrier are co-authors, in the ack. section several other people from both vendor and carrier world is listed. The draft have been presented on the DSL Forum meeting in Philadelphia and no people objected to the value. I have listed 2 major reasons why it was included, and there are multi-vendor implementations today based on this suggestion in test at carriers network. I'm not saying this is a reason it should not be changed, I'm simply=20 saying it shows that people have agreed to the suggestion, and we need some real good reasons to change it, better than future backward compatibility, and it seems more complicated than needed. thanks, Peter >=20 > ;) >=20 > regards, > --=20 > Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A > Fortune: > Cheese -- milk's leap toward immortality. > -- Clifton Fadiman, "Any Number Can Play" >=20 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Nov 28 18:39:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egsaz-0007ba-Fl; Mon, 28 Nov 2005 18:39:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egsay-0007bU-N6 for pppext@megatron.ietf.org; Mon, 28 Nov 2005 18:39:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09557 for ; Mon, 28 Nov 2005 18:38:54 -0500 (EST) Received: from hibernia.jakma.org ([212.17.55.49] ident=[U2FsdGVkX1/cviuEyA2bwoOSqN7r7Gsp40WhCw+j8mA=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egsuu-0001d7-T2 for pppext@ietf.org; Mon, 28 Nov 2005 19:00:18 -0500 Received: from sheen.jakma.org (IDENT:U2FsdGVkX1/9rQE703TFIjB5w9jfH4lY2QczmSiRgZM@sheen.jakma.org [212.17.55.53]) by hibernia.jakma.org (8.13.1/8.13.1) with ESMTP id jASNdEkg031444; Mon, 28 Nov 2005 23:39:19 GMT Date: Mon, 28 Nov 2005 23:39:14 +0000 (GMT) From: Paul Jakma X-X-Sender: paul@sheen.jakma.org To: Tom Mistretta Subject: RE: [Pppext] comment on draft-arberg-pppoe-mtu-gt1492-02.txt In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C280189CF5F@proton.jnpr.net> Message-ID: References: <9BD5D7887235424FA97DFC223CAE3C280189CF5F@proton.jnpr.net> Mail-Copies-To: paul@hibernia.jakma.org Mail-Followup-To: paul@hibernia.jakma.org X-NSA: al aqsar jihad musharef jet-A1 avgas ammonium qran inshallah allah al-akbar martyr iraq saddam hammas hisballah rabin ayatollah korea vietnam revolt mustard gas british airways washington peroxide cool MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on hibernia.jakma.org X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi Tom, Peter, On Mon, 28 Nov 2005, Tom Mistretta wrote: > > The value in this tag was not added just for convenience. > > - While I am not going to defend it, it's possible to use jumbo-frames > larger than 1500 (as opposed to in-between 1492 and 1500). > > - Additional negotiations and retries during LCP shouldn't be > trivialized. > - PPPoE has had a troubled history, partially due to assumptions > that were made by different implementations (MxU, retry behavior > etc). The use of an unqualified flag runs the risk of continuing > that trend, either by placing assumptions on values or overloading > the flag for other purposes. The flag would return PPPoE to normal PPP wrt the default and MxU negotiation (which would /not/ be needed for 1500 - it'd be the default). Anything greater requires LCP negotiation as per normal PPP, as does the draft btw. I think this is an opportunity to /reduce/ divergence of PPPoE from PPP. Previous divergence in PPPoE is exactly why this draft is required. Introducing yet further divergence seems unwise to me, particularly when there appears to be no good protocol reasons for it. The quality of implementation issues seem to be utterly irrelevant to me, if an implementation can not get: if (Max-Payload tag present) initial/default MTU is standard-PPP (1500) else initial/default MTU is RFC2561 (1492) right, it has bigger problems, and I'm not sure how you could trust that such implementations would describe the value they intend to use in Max-Payload correctly. I can easily imagine an implementation being coded to think that the Max-Payload value indicates a /default/ MTU, that it can specify values in this field and then /not/ have to do LCP negotiation for that value (which the draft requires). That seems quite plausible given the concerns regarding ability to implement reliably even just the above psuedo-code. I.e. adding a value just /increases/ the scope for assumptions, imho. > We are advocates of the specific value. Well, I've given my feedback. I obviously disagree, but I'll leave it at that and defer to experience of implementors. regards, -- Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A Fortune: The gent who wakes up and finds himself a success hasn't been asleep. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext