Re: ppp draft issues - offset padding field

On 6/26/2007 4:47 PM, Ignacio Goyret said the following:
> At 04:33 PM 6/26/2007 -0400, Carlos Pignataro wrote:
>>> I would like to propose one of the following two alternatives:
>>>
>>> 1) eliminate the offset padding field altogether.
>>>    This is my preferred choice.
>>>
>>> 2) if we decide to keep the offset padding field, it should be
>>>    somehow negotiated with the sender side.
>>>
>>>
>>> If option #2 was preferred, the negotiation could be done the
>>> same way that it is done in RFC3573: each side tells the other
>>> how far they are willing to go.
>>>
>>> A new AVP would be sent on the ICRQ/ICRP/OCRQ/OCRP to indicate
>>> the willingness of the message sender's side to insert an offset
>>> and how long that offset might be. If the AVP is not included,
>>> it means the message sender will not insert any offset (regardless
>>> of any received Offset Size AVP).
>> Rather than a session-level negotiation, how about a tunnel-level
>> SCCRQ/SCCRP capability advertisement, much like the "Pseudowire
>> Capabilities List" or the "Modem On-Hold Capable AVP" from Section 4.1
>> of RFC3573. A "Offset Capability" AVP can indicate how big of an offset
>> the sender is willing to insert, if requested at session-level.
> 
> 
> Sure, session-level or tunnel-level is fine by me.
> 
> I would still like to make this feature disappear though and go
> for the simpler solution of just removing something that has
> questionable value.
> 
> 
>> It could even be the same AVP number
>> (with semantics depending on the type of message in which the AVP is
>> in), or (my preference) a new AVP.
> 
> I think it will be better if it is a new AVP.

Yes, I agree.

> It is cleaner and it makes parsing and displaying much easier.
> I don't think there is any AVP that has more than personality and
> I think it is better to keep it that way.

There is one, from RFC3931:

      The Control Connection Tie Breaker AVP, Attribute Type 5,
...
      Note that in [RFC2661], this AVP is referred to as the "Tie
      Breaker AVP" and is applicable only to a control connection.  In
      L2TPv3, the AVP serves the same purpose of tie breaking, but is
      applicable to a control connection or a session.  The Control
      Connection Tie Breaker AVP (present only in Control Connection
      messages) and Session Tie Breaker AVP (present only in Session
      messages), are described separately in this document, but share
      the same Attribute type of 5.
...
      The Session Tie Breaker AVP, Attribute Type 5, is used to break

But I agree that having separate AVPs is cleaner. Also, I think the
potential flexibility in leaving it is the safer path, and setting the
"Offset Capability" to zero effectively makes this feature disappear if
desired by an implementation.

Thanks,

--Carlos (as editor).

> 
> Cheers,
> -Ignacio
> 

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems