From pppext-bounces@ietf.org Sat May 20 08:55:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhQyx-0008FG-R5; Sat, 20 May 2006 08:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhQyw-0008FA-Oz for pppext@ietf.org; Sat, 20 May 2006 08:54:58 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhPXM-0001nF-Ki for pppext@ietf.org; Sat, 20 May 2006 07:22:24 -0400 Received: from nf-out-0910.google.com ([64.233.182.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FhPJi-00031G-Hn for pppext@ietf.org; Sat, 20 May 2006 07:08:19 -0400 Received: by nf-out-0910.google.com with SMTP id i2so563975nfe for ; Sat, 20 May 2006 04:08:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=aoF1IrT2GJ5EK1SpliYxdG0VjqXzvokfQL8EhfLPWmnrC7laToWHI2YWYlxOruHEZ4iJuc2heLoCtq0QZcwmYXz5niBdR8qm5kXodEN2MoMDMSC7eS1c/AYZR29Pa+4E2WX/8uSjfJI3HZdJ06gVUfSpJ97mWjzMKe4OdLpihwA= Received: by 10.48.48.16 with SMTP id v16mr2152660nfv; Sat, 20 May 2006 04:08:17 -0700 (PDT) Received: by 10.49.63.3 with HTTP; Sat, 20 May 2006 04:08:17 -0700 (PDT) Message-ID: Date: Sat, 20 May 2006 04:08:17 -0700 From: "Hariharasubramanian CS" To: pppext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: -1.9 (-) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Subject: [Pppext] Suggesting Improvements in RFC 1990. 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: , Errors-To: pppext-bounces@ietf.org Group, This is to suggest some improvements in RFC 1990. There are 3 corrections. The first & the second corrections are for making the points clearer for the reader. The third one invites a functional change. Please review. Thanks in advance, Hariharasubramanian NetDevices India Pvt Ltd. Suggestion for Improvements in RFC 1990. Correction 1 Section 2: General Overview Page 4 "The packets to be transmitted using the multilink procedure are encapsulated according to the rules for PPP where the following options would have been manually configured: o No async control character Map o No Magic Number o No Link Quality Monitoring o Address and Control Field Compression o Protocol Field Compression o No Compound Frames o No Self-Describing-Padding According to the rules specified in RFC 1661, this means that an implementation MUST accept reassembled packets with and without leading zeroes present in the Protocol Field of the reassembled packet. Although it is explicitly forbidden below to include the Address and Control fields (usually, the two bytes FF 03) in the material to be fragmented, it is a good defensive programming practice to accept the packet anyway, ignoring the two bytes if present, as that is what RFC 1661 specifies. As a courtesy to implementations that perform better when certain alignment obtains, it is suggested that a determination be made when a bundle is created on whether to transmit leading zeroes by examining whether PFC has been negotiated on the first link admitted into a bundle. This determination should be kept in force so long as a bundle persists. Of course, individual links are permitted to have different settings for these options. As described below, member links SHOULD negotiate Self-Describing-Padding, even though pre-fragmented packets MUST NOT be padded. Since the Protocol Field Compression mode on the member link allows a sending system to include a leading byte of zero or not at its discretion, this is an alternative mechanism for generating even-length packets. I suggest we rewrite this section as:- The packets to be transmitted using the multilink procedure are encapsulated according to the rules for PPP where the following options would have been manually configured: o No async control character Map o No Magic Number o No Link Quality Monitoring o Address and Control Field Compression o Protocol Field Compression o No Compound Frames o No Self-Describing-Padding Of course, individual links are permitted to have different settings for these options. 2.1 Address and Control Field Compression: This document specifies that Address and Control Field Compression SHOULD BE used to encapsulate packets using multilink procedures. This means that it is explicitly forbidden to include the Address and Control fields (usually, the two bytes FF 03) in the material to be fragmented.. However, It is a good defensive programming practice to accept the packet anyway, ignoring the two bytes if present, as that is what RFC 1661 specifies. 2.2 Protocol-Field-Compression This document specifies that Protocol=96Field-Compression SHOULD BE used to encapsulate packets using multilink procedures. it is explicitly forbidden to include the leading zeros in the Protocol Field in the material to be fragmented.. However, according to the rules specified in RFC 1661, this means that an implementation MUST accept reassembled packets with and without leading zeroes present in the Protocol Field of the reassembled packet. Whether a bundle implements PFC and/or ACFC is dependent upon the first link admitted to the bundle. (This means that if the first link negotiates ACFC, then the bundle MUST NOT include Address and Control Fields in the material to be fragmented, irrespective of the ACFC mode of the other links.) This determination should be kept in force so long as the bundle persists. 2.3 Self-Describing Padding Member links SHOULD negotiate Self-Describing-Padding, even though pre-fragmented packets MUST NOT be padded. (This means that the material to be fragmented MUST NOT contain Pad octets, but the fragments themselves SHOULD contain Pad Octets.) Since the Protocol Field Compression mode on the member link allows a sending system to include a leading byte of zero or not at its discretion, this is an alternative mechanism for generating even-length packets. (More details in sec 3.1) ---------------------------------------------------------------------------= ----------- Correction 2: Section 3: Packet formats Page 6 "Address & Control and Protocol ID compression are assumed to be in effect. " I suggest we append this sentence with "in the material to be fragmented" ---------------------------------------------------------------------------= ---------------- Correction 3: Section 5.1.3 Endpoint Discriminator. Page 15 "This option is not required for multilink operation. If a system does not receive the Multilink MRRU option, but does receive the Endpoint Discriminator Option, and there is no manual configuration providing outside information, the implementation MUST NOT assume that multilink operation is being requested on this basis alone." I suggest this paragraph be changed as: Endpoint Discriminator option SHOULD BE included for multilink operation, to facilitate unambiguous bundle allotment. However, If a system does not receive the Multilink MRRU option, but does receive the Endpoint Discriminator Option, and there is no manual configuration providing outside information, the implementation MUST NOT assume that multilink operation is being requested on this basis alone. But, note that, without Endpoint Discriminator option, in the absence of manual configuration, it is possible that, two links of the same peer are connected to links of different peers, resulting in spurious behavior. ---------------------------------------------------------------------------= ---------------- _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sun May 21 15:30:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhtcv-0007Or-Mx; Sun, 21 May 2006 15:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fhtcu-0007Om-RT for pppext@ietf.org; Sun, 21 May 2006 15:30:08 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fhtcp-0005N9-3R for pppext@ietf.org; Sun, 21 May 2006 15:30:08 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 21 May 2006 15:30:03 -0400 X-IronPort-AV: i="4.05,152,1146456000"; d="scan'208"; a="89097493:sNHT35197960" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4LJU2TL006358; Sun, 21 May 2006 15:30:02 -0400 (EDT) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 21 May 2006 15:30:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Suggesting Improvements in RFC 1990. Date: Sun, 21 May 2006 15:30:01 -0400 Message-ID: <80BCC34EA5E72947AEFDD1D7920264C00192480B@xmb-rtp-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Suggesting Improvements in RFC 1990. Thread-Index: AcZ8DWw6YlByNlFPST6c4d3/e7U7NQA+PQnw From: "John Bray \(bray\)" To: "Hariharasubramanian CS" , X-OriginalArrivalTime: 21 May 2006 19:30:02.0767 (UTC) FILETIME=[F4DA61F0:01C67D0C] X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: 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: , Errors-To: pppext-bounces@ietf.org =20 > -----Original Message----- > From: Hariharasubramanian CS [mailto:meetcarey@gmail.com]=20 > Sent: Saturday, May 20, 2006 7:08 AM > To: pppext@ietf.org > Subject: [Pppext] Suggesting Improvements in RFC 1990. >=20 > Group, >=20 > This is to suggest some improvements in RFC 1990. There are 3 > corrections. The first=20 I believe your first "correction" would just add to the confusion. It also contains some unacceptable functional changes. See my comments below. > & the second corrections are for making the > points clearer for the reader. > The third one invites a functional > change. While I don't have major objections to your other two suggestions, I doubt they are significant enough to justify replacing RFC 1990. >=20 > Please review. > Thanks in advance, > Hariharasubramanian > NetDevices India Pvt Ltd. >=20 >=20 > Suggestion for Improvements in RFC 1990. >=20 > Correction 1 >=20 > Section 2: General Overview Page 4 >=20 > "The packets to be transmitted using the multilink procedure are > encapsulated according to the rules for PPP where the following > options would have been manually configured: >=20 > o No async control character Map > o No Magic Number > o No Link Quality Monitoring > o Address and Control Field Compression > o Protocol Field Compression > o No Compound Frames > o No Self-Describing-Padding >=20 > According to the rules specified in RFC 1661, this means that an > implementation MUST accept reassembled packets with and without > leading zeroes present in the Protocol Field of the reassembled > packet. Although it is explicitly forbidden below to include the > Address and Control fields (usually, the two bytes FF 03) in the > material to be fragmented, it is a good defensive programming > practice to accept the packet anyway, ignoring the two bytes if > present, as that is what RFC 1661 specifies. >=20 > As a courtesy to implementations that perform better when certain > alignment obtains, it is suggested that a determination be made when > a bundle is created on whether to transmit leading zeroes by > examining whether PFC has been negotiated on the first link admitted > into a bundle. This determination should be kept in force=20 > so long as > a bundle persists. >=20 > Of course, individual links are permitted to have different settings > for these options. As described below, member links SHOULD=20 > negotiate > Self-Describing-Padding, even though pre-fragmented packets MUST NOT > be padded. Since the Protocol Field Compression mode on the member > link allows a sending system to include a leading byte of=20 > zero or not > at its discretion, this is an alternative mechanism for generating > even-length packets. >=20 >=20 > I suggest we rewrite this section as:- >=20 > The packets to be transmitted using the multilink procedure are > encapsulated according to the rules for PPP where the following > options would have been manually configured: >=20 > o No async control character Map > o No Magic Number > o No Link Quality Monitoring > o Address and Control Field Compression > o Protocol Field Compression > o No Compound Frames > o No Self-Describing-Padding >=20 > Of course, individual links are permitted to have different > settings for these options. >=20 > 2.1 Address and Control Field Compression: >=20 > This document specifies that Address and Control Field Compression > SHOULD BE used to encapsulate packets using multilink procedures. This sentence does not make sense when put together with the next sentence. The Address and Control Fields are forbidden, so it does not make sense to talk about "Address and Control Field Compression". The use of the word "SHOULD", far from clarifying the text, will just add to the confusion. The FF 03 must be omitted, period. > This means that it is explicitly forbidden to include the Address > and Control fields (usually, the two bytes FF 03) in the material to > be fragmented.. However, It is a good defensive programming practice > to accept the packet anyway, ignoring the two bytes if present, as > that is what RFC 1661 specifies. >=20 > 2.2 Protocol-Field-Compression >=20 > This document specifies that Protocol-Field-Compression SHOULD BE > used to encapsulate packets using multilink procedures. it is > explicitly forbidden to include the leading zeros in the Protocol > Field in the material to be fragmented.. The RFC currently says no such thing, and this would be a significant functional change if adopted. As currently worded, the RFC *allows* implementations to compress the Protocol Field, but does not require them to. It merely *suggests* that PFC be applied if negotiated on the member links in order to keep the payload on an even boundary, but that is not a requirement. The only requirement is imposed on the receiver, which must be able to handle packets with or without the leading zero (as stated below). > However, according to the > rules specified in RFC 1661, this means that an implementation MUST > accept reassembled packets with and without leading zeroes present in > the Protocol Field of the reassembled packet. >=20 > Whether a bundle implements PFC and/or ACFC is dependent upon the > first link admitted to the bundle. (This means that if the first link > negotiates ACFC, then the bundle MUST NOT include Address and Control > Fields in the material to be fragmented, irrespective of the ACFC mode > of the other links.) This determination should be kept in force so > long as the bundle persists. Again, your discussion of ACFC is meaningless, since there are no Address and Control Fields to compress. And you are changing the *suggestion* to apply PFC based on the link setting to a requirement. That simply won't fly. >=20 > 2.3 Self-Describing Padding >=20 > Member links SHOULD negotiate Self-Describing-Padding, even though > pre-fragmented packets MUST NOT be padded. (This means that the > material to be fragmented MUST NOT contain Pad octets, but the > fragments themselves SHOULD contain Pad Octets.) Since the Protocol > Field Compression mode on the member link allows a sending system to > include a leading byte of zero or not at its discretion, this is an > alternative mechanism for generating even-length packets. (More > details in sec 3.1) Actually, if anything, I would prefer the "SHOULD" to be changed to "MAY". I don't think I have ever actually seen SDP applied in conjunction with multilink. >=20 > -------------------------------------------------------------- > ------------------------ > Correction 2: >=20 > Section 3: Packet formats Page 6 >=20 > "Address & Control and Protocol ID compression > are assumed to be in effect. " >=20 > I suggest we append this sentence with "in the material to=20 > be fragmented" You might want to add "and/or multilink encapsulated" since the packet is not necessarily fragmented. John >=20 > -------------------------------------------------------------- > ----------------------------- >=20 > Correction 3: >=20 > Section 5.1.3 Endpoint Discriminator. Page 15 >=20 >=20 > "This option is not required for multilink operation. If a system > does not receive the Multilink MRRU option, but does receive the > Endpoint Discriminator Option, and there is no manual configuration > providing outside information, the implementation MUST NOT assume > that multilink operation is being requested on this basis alone." >=20 > I suggest this paragraph be changed as: >=20 > Endpoint Discriminator option SHOULD BE included for multilink > operation, to facilitate unambiguous bundle allotment. However, If a > system does not receive the Multilink MRRU option, but does receive > the Endpoint Discriminator Option, and there is no manual > configuration providing outside information, the implementation MUST > NOT assume that multilink operation is being requested on this basis > alone. >=20 > But, note that, without Endpoint Discriminator option, in the absence > of manual configuration, it is possible that, two links of the same > peer are connected to links of different peers, resulting in spurious > behavior. >=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 May 23 08:16:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiVoO-0001z6-05; Tue, 23 May 2006 08:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiVoM-0001yw-VM for pppext@ietf.org; Tue, 23 May 2006 08:16:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiVoL-0004q1-U2 for pppext@ietf.org; Tue, 23 May 2006 08:16:30 -0400 Received: by ug-out-1314.google.com with SMTP id m3so1678136uge for ; Tue, 23 May 2006 05:16:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Bg5MIxcJwJg1OlEQOyTc4A8JLSDb7Ml+CYAoZky7HQyBHsHaUmMC0SW6x7KH6Xwh7j8Sgugs7d275zYPkGtLU/OJY2PO3fH8wZ204loiroE+2rJ5RqkgzakdYLfPU88Vxn+7f+KL4v7afj7sskHlieF7ONIyGOTKZDS3rVNkeog= Received: by 10.66.216.6 with SMTP id o6mr4535526ugg; Tue, 23 May 2006 05:16:28 -0700 (PDT) Received: by 10.67.30.18 with HTTP; Tue, 23 May 2006 05:16:28 -0700 (PDT) Message-ID: Date: Tue, 23 May 2006 17:46:28 +0530 From: "Hariharasubramanian CS" To: "John Bray (bray)" Subject: Re: [Pppext] Suggesting Improvements in RFC 1990. In-Reply-To: <80BCC34EA5E72947AEFDD1D7920264C00192480B@xmb-rtp-213.amer.cisco.com> MIME-Version: 1.0 References: <80BCC34EA5E72947AEFDD1D7920264C00192480B@xmb-rtp-213.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4da339c42fe5be09fa120bb0fcc4a575 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: , Content-Type: multipart/mixed; boundary="===============0302533397==" Errors-To: pppext-bounces@ietf.org --===============0302533397== Content-Type: multipart/alternative; boundary="----=_Part_66305_19453500.1148386588697" ------=_Part_66305_19453500.1148386588697 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 5/22/06, John Bray (bray) wrote: > > > > > -----Original Message----- > > From: Hariharasubramanian CS [mailto:meetcarey@gmail.com] > > Sent: Saturday, May 20, 2006 7:08 AM > > To: pppext@ietf.org > > Subject: [Pppext] Suggesting Improvements in RFC 1990. > > > > Group, > > > > This is to suggest some improvements in RFC 1990. There are 3 > > corrections. The first > > I believe your first "correction" would just add to the confusion. It > also contains some unacceptable functional changes. See my comments > below. > > > & the second corrections are for making the > > points clearer for the reader. > > The third one invites a functional > > change. > > While I don't have major objections to your other two suggestions, I > doubt they are significant enough to justify replacing RFC 1990. > > > > > Please review. > > Thanks in advance, > > Hariharasubramanian > > NetDevices India Pvt Ltd. > > > > > > Suggestion for Improvements in RFC 1990. > > > > Correction 1 > > > > Section 2: General Overview Page 4 > > > > "The packets to be transmitted using the multilink procedure are > > encapsulated according to the rules for PPP where the following > > options would have been manually configured: > > > > o No async control character Map > > o No Magic Number > > o No Link Quality Monitoring > > o Address and Control Field Compression > > o Protocol Field Compression > > o No Compound Frames > > o No Self-Describing-Padding > > > > According to the rules specified in RFC 1661, this means that an > > implementation MUST accept reassembled packets with and without > > leading zeroes present in the Protocol Field of the reassembled > > packet. Although it is explicitly forbidden below to include the > > Address and Control fields (usually, the two bytes FF 03) in the > > material to be fragmented, it is a good defensive programming > > practice to accept the packet anyway, ignoring the two bytes if > > present, as that is what RFC 1661 specifies. > > > > As a courtesy to implementations that perform better when certain > > alignment obtains, it is suggested that a determination be made when > > a bundle is created on whether to transmit leading zeroes by > > examining whether PFC has been negotiated on the first link admitted > > into a bundle. This determination should be kept in force > > so long as > > a bundle persists. > > > > Of course, individual links are permitted to have different settings > > for these options. As described below, member links SHOULD > > negotiate > > Self-Describing-Padding, even though pre-fragmented packets MUST NOT > > be padded. Since the Protocol Field Compression mode on the member > > link allows a sending system to include a leading byte of > > zero or not > > at its discretion, this is an alternative mechanism for generating > > even-length packets. > > > > > > I suggest we rewrite this section as:- > > > > The packets to be transmitted using the multilink procedure are > > encapsulated according to the rules for PPP where the following > > options would have been manually configured: > > > > o No async control character Map > > o No Magic Number > > o No Link Quality Monitoring > > o Address and Control Field Compression > > o Protocol Field Compression > > o No Compound Frames > > o No Self-Describing-Padding > > > > Of course, individual links are permitted to have different > > settings for these options. > > > > 2.1 Address and Control Field Compression: > > > > This document specifies that Address and Control Field Compression > > SHOULD BE used to encapsulate packets using multilink procedures. > > This sentence does not make sense when put together with the next > sentence. The Address and Control Fields are forbidden, so it does not > make sense to talk about "Address and Control Field Compression". The [HARI]John, You're mistaken here. When Address and Control Fields (ACF) are forbidden, it means that ACF compression is in place. Therefore my suggestion is to explicitly state "ACFC is used to encapsulate the material to be fragmented ". use of the word "SHOULD", far from clarifying the text, will just add to > the confusion. The FF 03 must be omitted, period. > This means that it is explicitly forbidden to include the Address > > and Control fields (usually, the two bytes FF 03) in the material to > > be fragmented.. However, It is a good defensive programming practice > > to accept the packet anyway, ignoring the two bytes if present, as > > that is what RFC 1661 specifies. > > > > 2.2 Protocol-Field-Compression > > > > This document specifies that Protocol-Field-Compression SHOULD BE > > used to encapsulate packets using multilink procedures. it is > > explicitly forbidden to include the leading zeros in the Protocol > > Field in the material to be fragmented.. > > The RFC currently says no such thing, and this would be a significant > functional change if adopted. As currently worded, the RFC *allows* > implementations to compress the Protocol Field, but does not require > them to. It merely *suggests* that PFC be applied if negotiated on the > member links in order to keep the payload on an even boundary, but that > is not a requirement. The only requirement is imposed on the receiver, > which must be able to handle packets with or without the leading zero > (as stated below). [HARI] IMHO it can stay in the SHOULD clause, as it should generally be followed by all. If you see this point as purely optional, then I would change it to MAY clause from SHOULD. > However, according to the > > rules specified in RFC 1661, this means that an implementation MUST > > accept reassembled packets with and without leading zeroes present in > > the Protocol Field of the reassembled packet. > > > > Whether a bundle implements PFC and/or ACFC is dependent upon the > > first link admitted to the bundle. (This means that if the first link > > negotiates ACFC, then the bundle MUST NOT include Address and Control > > Fields in the material to be fragmented, irrespective of the ACFC mode > > of the other links.) This determination should be kept in force so > > long as the bundle persists. > > Again, your discussion of ACFC is meaningless, since there are no > Address and Control Fields to compress. [HARI] I think I've already made my point clear. Pl go through this hyperlink. http://www1.ietf.org/mail-archive/web/pppext/current/msg00256.html And you are changing the > *suggestion* to apply PFC based on the link setting to a requirement. > That simply won't fly. [HARI] AFAIK, It was difficult for me to get an answer from the RFC for the following question: What is the RFC's stand on how the bundle should choose PFC mode, when the different member links negotiate different modes for the same PPP parameter ? (In other words, If there are two links, one negoitiates PFC and th= e other doesn't, then which one should the bundle adopt ? ) IMHO we should make some clear statement in the RFC in this regard. > > > 2.3 Self-Describing Padding > > > > Member links SHOULD negotiate Self-Describing-Padding, even though > > pre-fragmented packets MUST NOT be padded. (This means that the > > material to be fragmented MUST NOT contain Pad octets, but the > > fragments themselves SHOULD contain Pad Octets.) Since the Protocol > > Field Compression mode on the member link allows a sending system to > > include a leading byte of zero or not at its discretion, this is an > > alternative mechanism for generating even-length packets. (More > > details in sec 3.1) > > Actually, if anything, I would prefer the "SHOULD" to be changed to > "MAY". [HARI] Agreed. I don't think I have ever actually seen SDP applied in > conjunction with multilink. [HARI] But SDP SHOULD be negotiated on each link. > > > -------------------------------------------------------------- > > ------------------------ > > Correction 2: > > > > Section 3: Packet formats Page 6 > > > > "Address & Control and Protocol ID compression > > are assumed to be in effect. " > > > > I suggest we append this sentence with "in the material to > > be fragmented" > > You might want to add "and/or multilink encapsulated" since the packet > is not necessarily fragmented. > > John > > > > > -------------------------------------------------------------- > > ----------------------------- > > > > Correction 3: > > > > Section 5.1.3 Endpoint Discriminator. Page 15 > > > > > > "This option is not required for multilink operation. If a system > > does not receive the Multilink MRRU option, but does receive the > > Endpoint Discriminator Option, and there is no manual configuration > > providing outside information, the implementation MUST NOT assume > > that multilink operation is being requested on this basis alone." > > > > I suggest this paragraph be changed as: > > > > Endpoint Discriminator option SHOULD BE included for multilink > > operation, to facilitate unambiguous bundle allotment. However, If a > > system does not receive the Multilink MRRU option, but does receive > > the Endpoint Discriminator Option, and there is no manual > > configuration providing outside information, the implementation MUST > > NOT assume that multilink operation is being requested on this basis > > alone. > > > > But, note that, without Endpoint Discriminator option, in the absence > > of manual configuration, it is possible that, two links of the same > > peer are connected to links of different peers, resulting in spurious > > behavior. > > > > -------------------------------------------------------------- > > ----------------------------- > > > > _______________________________________________ > > Pppext mailing list > > Pppext@ietf.org > > https://www1.ietf.org/mailman/listinfo/pppext > > > ------=_Part_66305_19453500.1148386588697 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On 5/22/06, John Bray (bray) <bray@cis= co.com> wrote:


> -----Original Message-----
> From: Hariharasubramanian C= S [mailto:meetcarey@gmail.com]> Sent: Saturday, May 20, 2006 7:08 AM
> To: pppext@ietf.org
> Subject: [Pppext] Suggesting Improvements in RF= C 1990.
>
> Group,
>
> This is to suggest some impr= ovements in RFC 1990.  There are 3
> corrections. The first=

I believe your first "correction" would just add to the confusion= .  It
also contains some unacceptable functional changes. = ; See my comments
below.

> & the second corrections a= re for making the
> points clearer for the reader.
> The third one invites a fun= ctional
> change.

While I don't have major objections to your = other two suggestions, I
doubt they are significant enough to justify re= placing RFC 1990.

>
> Please review.
> Thanks in advance,
> Hari= harasubramanian
> NetDevices India Pvt Ltd.
>
>
>&n= bsp;            = ;            &n= bsp;    Suggestion for Improvements in RFC 1990.
>
> Correction 1
>
> = Section 2: General Overview Page 4
>
> "The packets to be = transmitted using the multilink procedure are
>   encapsula= ted according to the rules for PPP where the following
>   options would have been manually configured:
>>        o  No async= control character Map
>       &nb= sp;o  No Magic Number
>      =   o  No Link Quality Monitoring
>  &nbs= p;     o  Address and Control Field Comp= ression
>        o  Protoc= ol Field Compression
>        = ;o  No Compound Frames
>      = ;  o  No Self-Describing-Padding
>
> &= nbsp; According to the rules specified in RFC 1661, this means that an
&= gt;   implementation MUST accept reassembled packets with and wit= hout
>   leading zeroes present in the Protocol Field of the re= assembled
>   packet.  Although it is explicitly = forbidden below to include the
>   Address and Control fiel= ds (usually, the two bytes FF 03) in the
>   material to be fragmented, it is a good defensive prog= ramming
>   practice to accept the packet anyway, ignoring = the two bytes if
>   present, as that is what RFC 1661 spec= ifies.
>
>   As a courtesy to implementations that pe= rform better when certain
>   alignment obtains, it is suggested that a determinatio= n be made when
>   a bundle is created on whether to transm= it leading zeroes by
>   examining whether PFC has been neg= otiated on the first link admitted
>   into a bundle.  This determination should be= kept in force
> so long as
>   a bundle persists.>
>   Of course, individual links are permitted to have= different settings
>   for these options.  As de= scribed below, member links SHOULD
> negotiate
>   Self-Describing-Padding, even though= pre-fragmented packets MUST NOT
>   be padded.  = Since the Protocol Field Compression mode on the member
>  = link allows a sending system to include a leading byte of
> zero or not
>   at its discretion, this is an alte= rnative mechanism for generating
>   even-length packets.>
>
> I suggest we rewrite this section as:-
>
&g= t; The packets to be transmitted using the multilink procedure are
>  encapsulated according to the rules for PPP where the f= ollowing
>  options would have been manually configured:>
>       o  No async con= trol character Map
>        o=   No Magic Number
>        o  No Link Qu= ality Monitoring
>        o&n= bsp; Address and Control Field Compression
>   &n= bsp;    o  Protocol Field Compression
>=         o  No Compound Fr= ames
>        o  No= Self-Describing-Padding
>
>   Of course, individual links are permitted to h= ave different
> settings for these options.
>
> 2.1 Addre= ss and Control Field Compression:
>
>   This document= specifies that Address and Control Field Compression
> SHOULD BE   used to encapsulate packets using multilink = procedures.

This sentence does not make sense when put together with= the next
sentence.  The Address and Control Fields are forbid= den, so it does not
make sense to talk about "Address and Control Field Compression&qu= ot;.  The


[HARI]John, You're mistaken here. When Address and Control Fields (ACF) are= forbidden, it means
that ACF compression is in place. Therefore my suggestion is to explicitly state  "ACFC  is used to
 encapsulate the material to be fragmented ".

 

u= se of the word "SHOULD", far from clarifying the text, will just = add to
the confusion.  The FF 03 must be omitted, period.
 

> This means that it is explicitly forbidden to include the &= nbsp; Address
> and Control fields (usually, the two bytes FF 03) in the &nbs= p;material to
> be fragmented.. However, It is a good defensive progr= amming  practice
> to accept the packet anyway, ignoring th= e two bytes if  present, as
> that is what RFC 1661 specifies.
>
> 2.2 Protocol-Fiel= d-Compression
>
>     This document specifi= es that Protocol-Field-Compression SHOULD BE
> used to encapsulate pa= ckets using multilink procedures. it is
> explicitly forbidden to include the leading zeros in the Protocol<= br>> Field in the material to be fragmented..

The RFC currently s= ays no such thing, and this would be a significant
functional change if = adopted.  As currently worded, the RFC *allows*
implementations to compress the Protocol Field, but does not requirethem to.  It merely *suggests* that PFC be applied if negotiated= on the
member links in order to keep the payload on an even boundary, b= ut that
is not a requirement.  The only requirement is imposed on the= receiver,
which must be able to handle packets with or without the lead= ing zero
(as stated below).

 

[HARI] IMHO it can stay in the SHOULD clause, as it should generally be fol= lowed by all.
 If you see this point as purely optional, then I would change it to&n= bsp; MAY clause
from SHOULD.

 

&= gt; However, according to the
> rules specified in RFC 1661, this mea= ns that an   implementation MUST
> accept reassembled packets with and without  leading zer= oes present in
> the Protocol Field of the reassembled  pac= ket.
>
> Whether a bundle implements PFC and/or ACFC is depende= nt upon the
> first link admitted to the bundle. (This means that if = the first link
> negotiates ACFC, then the bundle MUST NOT include Address and Cont= rol
> Fields in the material to be fragmented, irrespective of the AC= FC mode
> of the other links.) This determination should be kept in f= orce so
> long as the bundle persists.

Again, your discussion of ACFC= is meaningless, since there are no
Address and Control Fields to compre= ss. 


[HARI] I think I've already made my point clear. Pl go through this hyperli= nk.
 
http://www1.ietf.org/mail-archive/web/pppext/current/msg00256.html<= br>

 

&= nbsp;And you are changing the
*suggestion* to apply PFC based on the lin= k setting to a requirement.
That simply won't fly.
 
[HARI] AFAIK, It was difficult for me to get an answer from the RFC for the= following question:

       What is the RFC's stand on how the bun= dle should choose PFC mode, when the
       different member links negotiate diffe= rent modes for the same PPP parameter ?
       (In other words, If there are two links, one negoitiates PFC  and the other doesn't, then which one
       should the bundle adopt ? )
IMHO we should make some clear statement in the RFC in this regard. &n= bsp;  


>
> = 2.3 Self-Describing Padding
>
>  Member links SHOULD = negotiate Self-Describing-Padding, even though
> pre-fragmented packets MUST NOT be padded. (This means that the> material to be fragmented MUST NOT contain Pad octets, but the
>= ; fragments themselves SHOULD contain Pad Octets.) Since the Protocol
> Field Compression mode on the member link allows a sending system to> include a leading byte of zero or not at its discretion, this is an<= br>> alternative mechanism for generating even-length packets. (More
> details in sec 3.1)

Actually, if anything, I would prefer t= he "SHOULD" to be changed to
"MAY".  


[HARI] Agreed.

I don't= think I have ever actually seen SDP applied in
conjunction with multili= nk.

[HARI] But SDP SHOULD be negotiated on each link.
 

&= gt;
> --------------------------------------------------------------<= br>> ------------------------
> Correction 2:
>
> Section 3: Packet formats Page 6
= >
> "Address & Control and Protocol ID compression
>= ;   are assumed to be in effect. "
>
> I suggest= we append  this sentence with "in the material to
> be fragmented"

You might want to add "and/or mult= ilink encapsulated" since the packet
is not necessarily fragmented.=

John

>
> ------------------------------------------= --------------------
> -----------------------------
>
> Correction 3:
>= ;
> Section 5.1.3 Endpoint Discriminator. Page 15
>
>
= > "This option is not required for multilink operation.  = If a system
>   does not receive the Multilink MRRU option, but does r= eceive the
>   Endpoint Discriminator Option, and there is = no manual configuration
>   providing outside information, = the implementation MUST NOT assume
>   that multilink operation is being requested on this ba= sis alone."
>
> I suggest this paragraph be changed as:>
>   Endpoint Discriminator option SHOULD BE included = for multilink
> operation, to facilitate unambiguous bundle allotment. However, If a> system does not receive the Multilink MRRU option, but does receive<= br>> the Endpoint Discriminator Option, and there is no manual
> c= onfiguration providing outside information, the implementation MUST
> NOT assume that multilink operation is being requested on this bas= is
> alone.
>
> But, note that, without Endpoint Discrimi= nator option, in the absence
> of manual configuration, it is possibl= e that, two links of the same
> peer are connected to links of different peers, resulting in spuri= ous
> behavior.
>
> -------------------------------------= -------------------------
> -----------------------------
>
> _______________________________________________
> Pppext mai= ling list
> Pppext@ietf.org> https://www= 1.ietf.org/mailman/listinfo/pppext
>

------=_Part_66305_19453500.1148386588697-- --===============0302533397== 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 --===============0302533397==-- From pppext-bounces@ietf.org Tue May 23 08:43:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWEe-0001zV-Hd; Tue, 23 May 2006 08:43:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWEd-0001zG-8S for pppext@ietf.org; Tue, 23 May 2006 08:43:39 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWEa-0005p5-OG for pppext@ietf.org; Tue, 23 May 2006 08:43:39 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-5.sun.com (8.12.10/8.12.9) with ESMTP id k4NChZaN011836 for ; Tue, 23 May 2006 05:43:35 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k4NChYAe008562 for ; Tue, 23 May 2006 08:43:35 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4NCi20c027274; Tue, 23 May 2006 08:44:02 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4NCi27G027271; Tue, 23 May 2006 08:44:02 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17523.914.677105.794260@gargle.gargle.HOWL> Date: Tue, 23 May 2006 08:44:02 -0400 From: James Carlson To: Hariharasubramanian CS Subject: Re: [Pppext] Suggesting Improvements in RFC 1990. In-Reply-To: Hariharasubramanian CS's message of 23 May 2006 17:46:28 References: <80BCC34EA5E72947AEFDD1D7920264C00192480B@xmb-rtp-213.amer.cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: "John Bray \(bray\)" , 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: , Errors-To: pppext-bounces@ietf.org Hariharasubramanian CS writes: > > This sentence does not make sense when put together with the next > > sentence. The Address and Control Fields are forbidden, so it does not > > make sense to talk about "Address and Control Field Compression". The > > > > [HARI]John, You're mistaken here. When Address and Control Fields (ACF) are > forbidden, it means > that ACF compression is in place. I'm afraid that's incorrect. When Address and Control Field compression is enabled on a regular PPP link, the sender *may* omit those fields. It is not required to omit them. The recipient is required to accept them if present. RFC 1990 specifies something different for the bundle level. It isn't just that ACFC is turned on; sending those fields is _incorrect_. > Therefore my suggestion is to explicitly > state "ACFC is used to > encapsulate the material to be fragmented ". That doesn't make sense to me, either. The Address and Control fields are part of HDLC, not part of PPP. The reason they're omitted from an MP fragment is that they simply form no part at all of the data being transferred. It's not a matter of "compression" of any sort, but of getting the layering right. They are prohibited, not merely compressed. What RFC 1990 _suggests_ is that recipients be lenient towards completely confused and broken peers that might insert these HDLC headers into the middle of a plainly PPP message. If I were to improve RFC 1990 at all, I might suggest removing this text and just saying that what belongs here is the PPP Protocol and Information fields alone, and that adding stray HDLC headers is illegal. > > > This document specifies that Protocol-Field-Compression SHOULD BE > > > used to encapsulate packets using multilink procedures. it is > > > explicitly forbidden to include the leading zeros in the Protocol > > > Field in the material to be fragmented.. > > > > The RFC currently says no such thing, and this would be a significant > > functional change if adopted. As currently worded, the RFC *allows* > > implementations to compress the Protocol Field, but does not require [...] > > [HARI] IMHO it can stay in the SHOULD clause, as it should generally be > followed by all. > If you see this point as purely optional, then I would change it to MAY > clause > from SHOULD. I think you're missing the point. Adding the clause "forbidding" the presence of a leading zero octet in the Protocol Field breaks compatibility. That behavior cannot be forbidden. The current text says this: According to the rules specified in RFC1661, this means that an implementation MUST accept reassembled packets with and without leading zeroes present in the Protocol Field of the reassembled packet. [...] This means exactly what it says. Receivers *must* be able to handle packets as though standard Protocol Field Compression were enabled, which means that the sender gets to choose whether it wants to compress away the leading zero octet *OR NOT*. We cannot now forbid the sending of the leading zero octet without creating a compatibility problem. > And you are changing the > > *suggestion* to apply PFC based on the link setting to a requirement. > > That simply won't fly. > > > [HARI] AFAIK, It was difficult for me to get an answer from the RFC for the > following question: > > What is the RFC's stand on how the bundle should choose PFC mode, > when the > different member links negotiate different modes for the same PPP > parameter ? It doesn't matter, because protocol field compression settings are completely independent for the member links and for the bundle. Each member link may choose to enable Protocol Field Compression. For those that do, the PPP Protocol Field "00 3D" may be expressed instead as "3D." Independently, the _bundle_ behaves as though Protocol Field Compression were always enabled. When the receiver reassembles the fragments, the receiver must be able to deal with either "00 21" or "21" for IP traffic (for example) in the reassembled message. There's no interaction between these two things. > (In other words, If there are two links, one negoitiates PFC and the > other doesn't, then which one > should the bundle adopt ? ) Neither. > IMHO we should make some clear statement in the RFC in this regard. The clear statement is already in the document. Of course, individual links are permitted to have different settings for these options. As described below, member links SHOULD negotiate Self-Describing-Padding, even though pre-fragmented packets MUST NOT be padded. Since the Protocol Field Compression mode on the member link allows a sending system to include a leading byte of zero or not at its discretion, this is an alternative mechanism for generating even-length packets. Member links have their own options. > I don't think I have ever actually seen SDP applied in > > conjunction with multilink. > > > [HARI] But SDP SHOULD be negotiated on each link. I don't know of any that do, in part because there are so few systems that use padding at _all_. The document doesn't match reality. (That unfortunately happens with RFCs.) This section should probably be rewritten. I think the issue here was making sure that padding, if it's used, is used properly on fragments. Fragments can't be padded unless SDP is used -- ad-hoc padding will corrupt the data. (But, then, why would anyone want to pad a fragment? If you're doing that, doesn't it mean that you have more data you could have sent instead of the pad?) Given that almost nobody pads, it's mostly a moot point. -- 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 May 23 08:53:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWNr-0006kP-UM; Tue, 23 May 2006 08:53:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiWNq-0006kK-Qt for pppext@ietf.org; Tue, 23 May 2006 08:53:10 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiWNq-0006Fy-91 for pppext@ietf.org; Tue, 23 May 2006 08:53:10 -0400 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 May 2006 08:53:11 -0400 X-IronPort-AV: i="4.05,160,1146456000"; d="scan'208"; a="89234847:sNHT35188754" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4NCr9TL006210; Tue, 23 May 2006 08:53:09 -0400 (EDT) Received: from xmb-rtp-213.amer.cisco.com ([64.102.31.112]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 08:53:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Suggesting Improvements in RFC 1990. Date: Tue, 23 May 2006 08:53:09 -0400 Message-ID: <80BCC34EA5E72947AEFDD1D7920264C001924BCB@xmb-rtp-213.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pppext] Suggesting Improvements in RFC 1990. Thread-Index: AcZ+YrxF5eTsqUJPSQmUcD0MGeAZXQAALDvA From: "John Bray \(bray\)" To: "Hariharasubramanian CS" X-OriginalArrivalTime: 23 May 2006 12:53:09.0780 (UTC) FILETIME=[D8086D40:01C67E67] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 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: , Errors-To: pppext-bounces@ietf.org I reiterate my earlier statement that I don't think your proposed wording changes are significant enough to justify replacing RFC 1990. However, see my responses inline. > -----Original Message----- > From: Hariharasubramanian CS [mailto:meetcarey@gmail.com]=20 > Sent: Tuesday, May 23, 2006 8:16 AM > To: John Bray (bray) > Cc: pppext@ietf.org > Subject: Re: [Pppext] Suggesting Improvements in RFC 1990. >=20 >=20 >=20 > On 5/22/06, John Bray (bray) wrote: >=20 >=20 >=20 > > -----Original Message----- > > From: Hariharasubramanian CS [mailto:meetcarey@gmail.com] > > Sent: Saturday, May 20, 2006 7:08 AM > > To: pppext@ietf.org =20 > > Subject: [Pppext] Suggesting Improvements in RFC 1990. > > > > Group, > > > > This is to suggest some improvements in RFC 1990. There are 3 > > corrections. The first > =09 > I believe your first "correction" would just add to the=20 > confusion. It > also contains some unacceptable functional changes. =20 > See my comments > below. > =09 > > & the second corrections are for making the=20 > > points clearer for the reader. > > The third one invites a functional > > change. > =09 > While I don't have major objections to your other two=20 > suggestions, I > doubt they are significant enough to justify replacing=20 > RFC 1990.=20 > =09 > > > > Please review. > > Thanks in advance, > > Hariharasubramanian > > NetDevices India Pvt Ltd. > > > > > > Suggestion for=20 > Improvements in RFC 1990. > > > > Correction 1 > > > > Section 2: General Overview Page 4 > > > > "The packets to be transmitted using the multilink=20 > procedure are > > encapsulated according to the rules for PPP where=20 > the following=20 > > options would have been manually configured: > > > > o No async control character Map > > o No Magic Number > > o No Link Quality Monitoring > > o Address and Control Field Compression=20 > > o Protocol Field Compression > > o No Compound Frames > > o No Self-Describing-Padding > > > > According to the rules specified in RFC 1661, this=20 > means that an > > implementation MUST accept reassembled packets with=20 > and without=20 > > leading zeroes present in the Protocol Field of the=20 > reassembled > > packet. Although it is explicitly forbidden below=20 > to include the > > Address and Control fields (usually, the two bytes=20 > FF 03) in the=20 > > material to be fragmented, it is a good defensive=20 > programming > > practice to accept the packet anyway, ignoring the=20 > two bytes if > > present, as that is what RFC 1661 specifies. > > > > As a courtesy to implementations that perform=20 > better when certain=20 > > alignment obtains, it is suggested that a=20 > determination be made when > > a bundle is created on whether to transmit leading zeroes by > > examining whether PFC has been negotiated on the=20 > first link admitted=20 > > into a bundle. This determination should be kept in force > > so long as > > a bundle persists. > > > > Of course, individual links are permitted to have=20 > different settings > > for these options. As described below, member links SHOULD=20 > > negotiate > > Self-Describing-Padding, even though pre-fragmented=20 > packets MUST NOT > > be padded. Since the Protocol Field Compression=20 > mode on the member > > link allows a sending system to include a leading byte of=20 > > zero or not > > at its discretion, this is an alternative mechanism=20 > for generating > > even-length packets. > > > > > > I suggest we rewrite this section as:- > > > > The packets to be transmitted using the multilink=20 > procedure are=20 > > encapsulated according to the rules for PPP where=20 > the following > > options would have been manually configured: > > > > o No async control character Map > > o No Magic Number > > o No Link Quality Monitoring > > o Address and Control Field Compression > > o Protocol Field Compression > > o No Compound Frames > > o No Self-Describing-Padding=20 > > > > Of course, individual links are permitted to have different > > settings for these options. > > > > 2.1 Address and Control Field Compression: > > > > This document specifies that Address and Control=20 > Field Compression=20 > > SHOULD BE used to encapsulate packets using=20 > multilink procedures. > =09 > This sentence does not make sense when put together=20 > with the next > sentence. The Address and Control Fields are=20 > forbidden, so it does not=20 > make sense to talk about "Address and Control Field=20 > Compression". The >=20 >=20 >=20 > [HARI]John, You're mistaken here. When Address and Control=20 > Fields (ACF) are forbidden, it means > that ACF compression is in place. Therefore my suggestion is=20 > to explicitly state "ACFC is used to > encapsulate the material to be fragmented ". Not quite. The Address and Control Fields we are discussing are used for PPP in HDLC-like Framing (RFC 1662). ACFC as specified in RFC 1661 is optional, meaning that transmitting peers need not omit them even if the option is negotiated. The Multilink payload is not using HDLC-like Framing (it is not a serial interface, it merely emulates one), and the Address and Control Fields are expressly prohibited. Talking about ACFC here just adds to the confusion IMO, and saying "SHOULD" will make matters worse. I think the text should simply have said that the material to be fragmented MUST NOT contain the Address and Control Fields and left it at that. >=20 > =20 >=20 >=20 > use of the word "SHOULD", far from clarifying the text,=20 > will just add to=20 > the confusion. The FF 03 must be omitted, period. >=20 > =20 >=20 >=20 > > This means that it is explicitly forbidden to include=20 > the Address=20 > > and Control fields (usually, the two bytes FF 03) in=20 > the material to > > be fragmented.. However, It is a good defensive=20 > programming practice > > to accept the packet anyway, ignoring the two bytes=20 > if present, as=20 > > that is what RFC 1661 specifies. > > > > 2.2 Protocol-Field-Compression > > > > This document specifies that=20 > Protocol-Field-Compression SHOULD BE > > used to encapsulate packets using multilink procedures. it is=20 > > explicitly forbidden to include the leading zeros in=20 > the Protocol > > Field in the material to be fragmented.. > =09 > The RFC currently says no such thing, and this would be=20 > a significant > functional change if adopted. As currently worded, the=20 > RFC *allows*=20 > implementations to compress the Protocol Field, but=20 > does not require > them to. It merely *suggests* that PFC be applied if=20 > negotiated on the > member links in order to keep the payload on an even=20 > boundary, but that=20 > is not a requirement. The only requirement is imposed=20 > on the receiver, > which must be able to handle packets with or without=20 > the leading zero > (as stated below). >=20 >=20 > =20 >=20 > [HARI] IMHO it can stay in the SHOULD clause, as it should=20 > generally be followed by all. That is precisely why it shouldn't say SHOULD. It *shouldn't* necessarily be followed by all. There are often good reasons for *not* using PFC on the multilink payload. > If you see this point as purely optional, then I would=20 > change it to MAY clause > from SHOULD.=20 It *is* purely optional. >=20 > =20 >=20 >=20 > > However, according to the > > rules specified in RFC 1661, this means that an =20 > implementation MUST=20 > > accept reassembled packets with and without leading=20 > zeroes present in > > the Protocol Field of the reassembled packet. > > > > Whether a bundle implements PFC and/or ACFC is=20 > dependent upon the > > first link admitted to the bundle. (This means that=20 > if the first link=20 > > negotiates ACFC, then the bundle MUST NOT include=20 > Address and Control > > Fields in the material to be fragmented, irrespective=20 > of the ACFC mode > > of the other links.) This determination should be=20 > kept in force so=20 > > long as the bundle persists. > =09 > Again, your discussion of ACFC is meaningless, since=20 > there are no > Address and Control Fields to compress.=20 >=20 >=20 >=20 > [HARI] I think I've already made my point clear. Pl go=20 > through this hyperlink.=20 > =20 > http://www1.ietf.org/mail-archive/web/pppext/current/msg00256.html I am quite familiar with ACFC, thanks. Again, omitting these fields from the packet is optional when ACFC is negotiated with HDLC-like framing, but it is mandatory when talking about the multilink payload. >=20 >=20 > =20 >=20 >=20 > And you are changing the > *suggestion* to apply PFC based on the link setting to=20 > a requirement.=20 > That simply won't fly. >=20 > =20 > [HARI] AFAIK, It was difficult for me to get an answer from=20 > the RFC for the following question: >=20 > What is the RFC's stand on how the bundle should=20 > choose PFC mode, when the=20 > different member links negotiate different modes for=20 > the same PPP parameter ?=20 > (In other words, If there are two links, one=20 > negoitiates PFC and the other doesn't, then which one > should the bundle adopt ? )=20 > IMHO we should make some clear statement in the RFC in this=20 > regard. =20 I don't think the RFC needs to make a clear statement. It is entirely an implementation decision, and since the receiving peer must be able to reassemble and process the packet either way, I don't think it matters. Trying to specify a precise behavior now will lead to interoperability problems, because many current implementations will not be in compliance with the new requirement. >=20 >=20 >=20 >=20 > > > > 2.3 Self-Describing Padding > > > > Member links SHOULD negotiate=20 > Self-Describing-Padding, even though=20 > > pre-fragmented packets MUST NOT be padded. (This=20 > means that the > > material to be fragmented MUST NOT contain Pad octets, but the > > fragments themselves SHOULD contain Pad Octets.)=20 > Since the Protocol > > Field Compression mode on the member link allows a=20 > sending system to > > include a leading byte of zero or not at its=20 > discretion, this is an > > alternative mechanism for generating even-length=20 > packets. (More=20 > > details in sec 3.1) > =09 > Actually, if anything, I would prefer the "SHOULD" to=20 > be changed to > "MAY". =20 >=20 >=20 >=20 > [HARI] Agreed. >=20 >=20 >=20 > I don't think I have ever actually seen SDP applied in > conjunction with multilink.=20 >=20 >=20 > [HARI] But SDP SHOULD be negotiated on each link. Why? John > =20 >=20 >=20 > > > > -------------------------------------------------------------- > > ------------------------=20 > > Correction 2: > > > > Section 3: Packet formats Page 6 > > > > "Address & Control and Protocol ID compression > > are assumed to be in effect. " > > > > I suggest we append this sentence with "in the material to=20 > > be fragmented" > =09 > You might want to add "and/or multilink encapsulated"=20 > since the packet > is not necessarily fragmented. > =09 > John > =09 > > > >=20 > --------------------------------------------------------------=20 > > ----------------------------- > > > > Correction 3: > > > > Section 5.1.3 Endpoint Discriminator. Page 15 > > > > > > "This option is not required for multilink operation.=20 > If a system=20 > > does not receive the Multilink MRRU option, but=20 > does receive the > > Endpoint Discriminator Option, and there is no=20 > manual configuration > > providing outside information, the implementation=20 > MUST NOT assume=20 > > that multilink operation is being requested on this=20 > basis alone." > > > > I suggest this paragraph be changed as: > > > > Endpoint Discriminator option SHOULD BE included=20 > for multilink > > operation, to facilitate unambiguous bundle=20 > allotment. However, If a > > system does not receive the Multilink MRRU option,=20 > but does receive > > the Endpoint Discriminator Option, and there is no manual > > configuration providing outside information, the=20 > implementation MUST=20 > > NOT assume that multilink operation is being=20 > requested on this basis > > alone. > > > > But, note that, without Endpoint Discriminator=20 > option, in the absence > > of manual configuration, it is possible that, two=20 > links of the same=20 > > peer are connected to links of different peers,=20 > resulting in spurious > > behavior. > > > > -------------------------------------------------------------- > > ----------------------------- > >=20 > > _______________________________________________ > > Pppext mailing list > > Pppext@ietf.org > > https://www1.ietf.org/mailman/listinfo/pppext=20 > > > =09 >=20 >=20 >=20 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue May 23 10:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiY2N-0004Rn-1z; Tue, 23 May 2006 10:39:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiY2M-0004Ri-My for pppext@ietf.org; Tue, 23 May 2006 10:39:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiY2L-0002hf-Bj for pppext@ietf.org; Tue, 23 May 2006 10:39:06 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 23 May 2006 07:39:03 -0700 X-IronPort-AV: i="4.05,161,1146466800"; d="scan'208"; a="281367204:sNHT1822670832" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k4NEd2Oi006124; Tue, 23 May 2006 07:39:02 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4NEd2B9000879; Tue, 23 May 2006 07:39:02 -0700 (PDT) Received: from cisco.com (lanzo-u10.cisco.com [64.102.48.21]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id HAA10362; Tue, 23 May 2006 07:38:30 -0700 (PDT) Message-Id: <200605231438.HAA10362@cisco.com> Date: Tue, 23 May 2006 10:38:54 -0400 (EDT) From: Mark Lanzo Subject: Re: [Pppext] Suggesting Improvements in RFC 1990. To: meetcarey@gmail.com In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii DKIM-Signature: a=rsa-sha1; q=dns; l=3624; t=1148395142; x=1149259142; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lanzo@cisco.com; z=From:Mark=20Lanzo=20 |Subject:Re=3A=20[Pppext]=20Suggesting=20Improvements=20in=20RFC=201990.; X=v=3Dcisco.com=3B=20h=3Dr85AnNSdL+Gr4lMBuL19roNeGA8=3D; b=MKFZjvuAifnO0gc64Cnu1p9lh2DTSrbUVqRIlsP8nhnaWsvGB8mMLmK31hrEsb2WbMA4WoW2 9TnMtKW0c/JI7ey5QXheu/o9KDJatCYa/rDO5L605JG09g52qBNbJNqp; Authentication-Results: sj-dkim-4.cisco.com; header.From=lanzo@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: , Errors-To: pppext-bounces@ietf.org On 23 May, Hariharasubramanian CS wrote: >> > The packets to be transmitted using the multilink procedure are >> > encapsulated according to the rules for PPP where the following >> > options would have been manually configured: >> > >> > o No async control character Map >> > o No Magic Number >> > o No Link Quality Monitoring >> > o Address and Control Field Compression >> > o Protocol Field Compression >> > o No Compound Frames >> > o No Self-Describing-Padding >> > >> > Of course, individual links are permitted to have different >> > settings for these options. >> > >> > 2.1 Address and Control Field Compression: >> > >> > This document specifies that Address and Control Field Compression >> > SHOULD BE used to encapsulate packets using multilink procedures. >> >> This sentence does not make sense when put together with the next >> sentence. The Address and Control Fields are forbidden, so it does not >> make sense to talk about "Address and Control Field Compression". The > > > > [HARI]John, You're mistaken here. When Address and Control Fields (ACF) are > forbidden, it means > that ACF compression is in place. Therefore my suggestion is to explicitly > state "ACFC is used to > encapsulate the material to be fragmented ". This is an MLP bundle under discussion, not an HDLC link. A bundle does not have HDLC framing nor any similar sort of framing which defines analogous Address and Control fields. You cannot compress that which is not there to begin with. ACFC is a concept which has no meaning or relevance to a bundle. Now, I will agree that the RFC wording is confusing since its wording suggests that Address/Control fields (and compression thereof) have any relevance whatsoever at the bundle level. It would be better if the RFC explained that packets at the bundle level are "pure PPP", consisting solely of PPP Protocol and Information fields and never contain any media-specific framing, but, I'd echo John's sentiment that it is not worth a new revision of RFC 1990 just to change this. > [HARI] AFAIK, It was difficult for me to get an answer from the RFC for the > following question: > > What is the RFC's stand on how the bundle should choose PFC mode, > when the > different member links negotiate different modes for the same PPP > parameter ? > (In other words, If there are two links, one negoitiates PFC and the > other doesn't, then which one > should the bundle adopt ? ) > > IMHO we should make some clear statement in the RFC in this regard. The RFC does have a clear statement about that: "As a courtesy to implementations that perform better when certain alignment obtains, it is suggested that a determination be made when a bundle is created on whether to transmit leading zeroes by examining whether PFC has been negotiated on the first link admitted" There is no requirement that the bundle choose its PFC mode based on any link's characteristics. One could never do it, always do it, or do it selectively by any criteria one wanted -- for example, balance the inner and outer Protocol fields on a Beginning fragment to always keep the fragment payload on an even boundary. I would interpolate that the intent behind the above suggestion is that unless a peer system has explicitly indicated that it does not mind receiving unaligned payloads (by negotiating PFC), that it is probably best if one not generate them at the bundle level either. -Mark _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue May 23 11:11:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYXV-00048N-VG; Tue, 23 May 2006 11:11:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYXU-000482-EM for pppext@ietf.org; Tue, 23 May 2006 11:11:16 -0400 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 1FiYXT-0003r7-6G for pppext@ietf.org; Tue, 23 May 2006 11:11:16 -0400 Received: from [209.31.94.10] (account karl HELO [172.30.1.207]) by lithik.com (CommuniGate Pro SMTP 4.3.6) with ESMTPSA id 1175191; Tue, 23 May 2006 11:11:08 -0400 In-Reply-To: <200605231438.HAA10362@cisco.com> References: <200605231438.HAA10362@cisco.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Karl Fox Subject: Re: [Pppext] Suggesting Improvements in RFC 1990. Date: Tue, 23 May 2006 11:11:06 -0400 To: pppext@ietf.org X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: pppext-bounces@ietf.org If someone were to ask me (which they haven't), I'd say leave RFC 1990 alone unless you fix it. By "fixing it" I mean combining two links, each with probability of failure p, and providing a combined link with probability of failure p^2 rather than 2p as RFC 1990 does. Karl P.S. I may be years out of date on this issue, but the last time I participated in an argument on the topic we couldn't come up with a way of making a single-link-failure not hose up the entire bundle, at least not until LQM shut it down and removed it from the bundle. Cleverer people than I may have solved this since then. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue May 23 11:28:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYo8-0004SY-PK; Tue, 23 May 2006 11:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiYo8-0004ST-2T for pppext@ietf.org; Tue, 23 May 2006 11:28:28 -0400 Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiYo6-0004aA-KR for pppext@ietf.org; Tue, 23 May 2006 11:28:28 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.6/8.13.6) with ESMTP id k4NFSJnN019166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Tue, 23 May 2006 09:28:19 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.6/8.13.6/Submit) id k4NFSJ3O019165 for pppext@ietf.org; Tue, 23 May 2006 09:28:19 -0600 (MDT) Date: Tue, 23 May 2006 09:28:19 -0600 (MDT) From: Vernon Schryver Message-Id: <200605231528.k4NFSJ3O019165@calcite.rhyolite.com> To: pppext@ietf.org Subject: RE: [Pppext] Suggesting Improvements in RFC 1990. In-Reply-To: <80BCC34EA5E72947AEFDD1D7920264C001924BCB@xmb-rtp-213.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: , Errors-To: pppext-bounces@ietf.org > From: "John Bray \(bray\)" > To: "Hariharasubramanian CS" > Cc: pppext@ietf.org > > I reiterate my earlier statement that I don't think your proposed > wording changes are significant enough to justify replacing RFC 1990. That would be entirely true even if most of proposed changes were not simply wrong. Replacing RFC 1990 would inevitiably introduce new placs where the wording confuses people. At this date, more than 10 years after the first interoperable implementations, there cannot be many significant bits of confusion. There are textbooks that explicate the current text. Combined with the RFC and the open source implmentations, they surely resolve any questions. If there were to be a new RFC, I would: - change the name of the protocol to match common practice. I've always tried to follow the RFC and call it "MP", but most people call it something like "MLPPP." - get rid of or deprecate Self-Describing-Padding. I disagree with James Carlson. I believe there are no existing implementations except perhaps student exercises that include Self-Describing-Padding. I always thought self-describing-padding was a solution in search of a problem and not just in MP. PPP implementations that lacked byte- agile DMA hardware could always use other tactics to reach an even number of bytes. Today, hardware often uses buses a lot wider than 16 bits and have mechanisms to make them look narrow. I think section 3.1 exists mostly to document a compromise between my steadfast objections to Self-Describing-Padding and some equally determined advocacy of it. - get rid of or deprecate section 5. Reliable PPP was another solution in search of a problem. I vaguely recalled that RFC 1663 was deprecated, but it is still PROPOSED STANDARD in the Index and I can't find the RFC deprecating it that I thought I recalled. Maybe I'm thinking of the RFC that reclaimed many dead and never used DHCP options. - get rid of most of the Endpoint Discriminator Option types and keep the couple that have actually been used, and might ever be used. But again, the unavoidable new errors in a new version are not justified by minor housecleaning. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue May 23 12:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia9J-0007s7-8X; Tue, 23 May 2006 12:54:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fia9H-0007s1-G0 for pppext@ietf.org; Tue, 23 May 2006 12:54:23 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fia9D-0007uO-2U for pppext@ietf.org; Tue, 23 May 2006 12:54:23 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id k4NGsHif028551 for ; Tue, 23 May 2006 09:54:18 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k4NGsGu9010864 for ; Tue, 23 May 2006 12:54:17 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4NGshj5028446; Tue, 23 May 2006 12:54:43 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4NGshxf028443; Tue, 23 May 2006 12:54:43 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17523.15954.366777.286132@gargle.gargle.HOWL> Date: Tue, 23 May 2006 12:54:42 -0400 From: James Carlson To: Vernon Schryver Subject: RE: [Pppext] Suggesting Improvements in RFC 1990. In-Reply-To: Vernon Schryver's message of 23 May 2006 09:28:19 References: <80BCC34EA5E72947AEFDD1D7920264C001924BCB@xmb-rtp-213.amer.cisco.com> <200605231528.k4NFSJ3O019165@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: , Errors-To: pppext-bounces@ietf.org Vernon Schryver writes: > - get rid of or deprecate Self-Describing-Padding. > I disagree with James Carlson. I believe there are no existing > implementations except perhaps student exercises that include > Self-Describing-Padding. How is that disagreeing with me? I also said there are no known implementations that do this, and the point of it at all is rather obscure and almost completely without merit on non-terminal fragments. -- 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 May 23 12:57:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaBz-0000EY-2u; Tue, 23 May 2006 12:57:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiaBy-0000ET-47 for pppext@ietf.org; Tue, 23 May 2006 12:57:10 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiaBw-00087p-Ly for pppext@ietf.org; Tue, 23 May 2006 12:57:10 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k4NGv7rM006582 for ; Tue, 23 May 2006 09:57:07 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k4NGv6iT011889 for ; Tue, 23 May 2006 12:57:07 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4NGvXBx028452; Tue, 23 May 2006 12:57:33 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4NGvXDJ028449; Tue, 23 May 2006 12:57:33 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17523.16125.590721.165626@gargle.gargle.HOWL> Date: Tue, 23 May 2006 12:57:33 -0400 From: James Carlson To: Karl Fox Subject: Re: [Pppext] Suggesting Improvements in RFC 1990. In-Reply-To: Karl Fox's message of 23 May 2006 11:11:06 References: <200605231438.HAA10362@cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: , Errors-To: pppext-bounces@ietf.org Karl Fox writes: > If someone were to ask me (which they haven't), I'd say leave RFC > 1990 alone unless you fix it. By "fixing it" I mean combining two > links, each with probability of failure p, and providing a combined > link with probability of failure p^2 rather than 2p as RFC 1990 does. If you mean on a packet-by-packet basis, then p^2 sounds like "path protection" (replication at the sender and discarding duplicates at the receiver). That's rather different from what the original goal seemed to be, and likely wouldn't fit many (if any) of the existing uses of MP. If you mean on a link basis, then I don't think such a fix is needed. It's a matter of implementation. -- 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 May 23 16:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fidh4-0005By-QD; Tue, 23 May 2006 16:41:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fidh3-00059Y-D9 for pppext@ietf.org; Tue, 23 May 2006 16:41:29 -0400 Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fidh2-0002wW-0I for pppext@ietf.org; Tue, 23 May 2006 16:41:29 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.6/8.13.6) with ESMTP id k4NKfDGK015400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Tue, 23 May 2006 14:41:13 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.6/8.13.6/Submit) id k4NKfCMi015399; Tue, 23 May 2006 14:41:12 -0600 (MDT) Date: Tue, 23 May 2006 14:41:12 -0600 (MDT) From: Vernon Schryver Message-Id: <200605232041.k4NKfCMi015399@calcite.rhyolite.com> To: james.d.carlson@sun.com Subject: RE: [Pppext] Suggesting Improvements in RFC 1990. In-Reply-To: <17523.15954.366777.286132@gargle.gargle.HOWL> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: pppext-bounces@ietf.org > From: James Carlson > To: Vernon Schryver > Cc: pppext@ietf.org > > - get rid of or deprecate Self-Describing-Padding. > > I disagree with James Carlson. I believe there are no existing > > implementations except perhaps student exercises that include > > Self-Describing-Padding. > > How is that disagreeing with me? I was being flip. > I also said there are no known > implementations that do this, and the point of it at all is rather > obscure and almost completely without merit on non-terminal fragments. You say "rather obscure and almost completely without merit on non-terminal fragments." That is an effusive recommendation compared to what I think about it. My views about it are more negative than "completely without merit." Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue May 23 16:47:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fidmb-0000HC-Ml; Tue, 23 May 2006 16:47:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fidmb-0000H7-4T for pppext@ietf.org; Tue, 23 May 2006 16:47:13 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FidmX-000347-RW for pppext@ietf.org; Tue, 23 May 2006 16:47:13 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id k4NKl9IH014966 for ; Tue, 23 May 2006 14:47:09 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id k4NKl8gu026057 for ; Tue, 23 May 2006 16:47:08 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id k4NKlbKn029504; Tue, 23 May 2006 16:47:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.6+Sun/8.13.6/Submit) id k4NKlars029501; Tue, 23 May 2006 16:47:36 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17523.29928.733661.323699@gargle.gargle.HOWL> Date: Tue, 23 May 2006 16:47:36 -0400 From: James Carlson To: Vernon Schryver Subject: RE: [Pppext] Suggesting Improvements in RFC 1990. In-Reply-To: Vernon Schryver's message of 23 May 2006 14:41:12 References: <17523.15954.366777.286132@gargle.gargle.HOWL> <200605232041.k4NKfCMi015399@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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: , Errors-To: pppext-bounces@ietf.org Vernon Schryver writes: > > I also said there are no known > > implementations that do this, and the point of it at all is rather > > obscure and almost completely without merit on non-terminal fragments. > > You say "rather obscure and almost completely without merit on > non-terminal fragments." That is an effusive recommendation compared > to what I think about it. My views about it are more negative than > "completely without merit." Fair enough. I agree with you and I don't think padding really makes any sense at all. Making SDP Historic (along with the bits you mentioned) might be a helpful move. But _if_ for some reason you really _must_ do it, then you can't just pad MP fragments arbitrarily, so the advice in the RFC was correct, if somewhat (or completely) misleading. -- 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 Mon May 29 20:05:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkrjZ-0003Sc-UP; Mon, 29 May 2006 20:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkrjY-0003S4-Os; Mon, 29 May 2006 20:05:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkrjY-0002r0-GB; Mon, 29 May 2006 20:05:16 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k4U05FHp025824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 30 May 2006 00:05:16 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FkrjX-0004xL-RH; Mon, 29 May 2006 20:05:15 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 29 May 2006 20:05:15 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: pppext mailing list , Internet Architecture Board , pppext chair , RFC Editor Subject: [Pppext] Document Action: 'Accommodating an MTU/MRU greater than 1492 in PPPoE' to Informational RFC 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: , Errors-To: pppext-bounces@ietf.org The IESG has approved the following document: - 'Accommodating an MTU/MRU greater than 1492 in PPPoE ' as an Informational RFC This document is the product of the Point-to-Point Protocol Extensions Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-03.txt Technical Summary 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. Working Group Summary "The consensus seems relatively weak to me, with a handful of PPPoE advocates strongly voicing support for the draft, and relative skepticism or apathy elsewhere. As it seems to be a minor change to an Informational protocol, and in general should enable some folks who are currently plagued with MTU problems to have a better experience, I think it's mostly helpful." Protocol Quality This spec was reviewed by the pppext WG and Mark Townsley. Note to RFC Editor OLD: No IANA action is required. NEW: This document defines a new value in a space that currently has no IANA registry. There is work in progress to define a registry [IANA], and that document already contains the value assigned here. No IANA action is required for this document. Please include an informative reference to draft-arberg-pppoe-iana-01.txt for [IANA] OLD: This allows it to test that the receiving side and any intermediate equipment can handle such packet size. NEW: This allows it to test that the receiving side and any intermediate Ethernet segments and equipment can handle such packet size. OLD: ... jumbo frames on Ethernet segments NEW: ... frames with Ethernet packet format, but exceeding the maximum packet lengthas defined by [REFERENCE - IEEE 802.3] Please include the following reference for the above change: [802.3-2005] Institute of Electrical and Electronic Engineers, IEEE Std 802.3-2005, "IEEE Standard for Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Draft amendment to - Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications - Media Access Control Parameters, Physical Layers and Management Parameters", December 2005. IESG Note As of this writing, no current IEEE standard supports the use of "jumbo frames" (MTU greater than 1500). Although this document contains recommended mechanisms to detect problems in the path, interoperability and reliability of non-standard extensions cannot be assured. Both implementors and users of the protocol described here should exercise caution in its use. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext