Re: [Pppext] Suggesting Improvements in RFC 1990.

[Mark Lanzo <lanzo at cisco.com>]

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