[Pppext] Suggesting Improvements in RFC 1990.

["Hariharasubramanian CS" <meetcarey at gmail.com>]

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