RE: [Pppext] Suggesting Improvements in RFC 1990.

["John Bray \(bray\)" <bray at cisco.com>]

> -----Original Message-----
> From: Hariharasubramanian CS [mailto:meetcarey at gmail.com] 
> Sent: Saturday, May 20, 2006 7:08 AM
> To: pppext at 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
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).

> 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.  And you are changing the
*suggestion* to apply PFC based on the link setting to a requirement.
That simply won't fly.

> 
> 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".  I don't think I have ever actually seen SDP applied in
conjunction with multilink.

> 
> --------------------------------------------------------------
> ------------------------
> 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 at ietf.org
> https://www1.ietf.org/mailman/listinfo/pppext
> 

_______________________________________________
Pppext mailing list
Pppext at ietf.org
https://www1.ietf.org/mailman/listinfo/pppext