Subject: draft-declercq-ppp-ds-sla-negotiation-00.txt

From: James Carlson <[email-masked]>
Date: Tue, 7 Mar 2000 14:09:18 -0500 (EST)

I noticed your recent Internet Draft contribution, and I have a few
comments.  First one overall comment:  shouldn't this be submitted to
the PPP Extensions working group?

On to the draft:

> 3.1 Summary of Operation
[...]
>    The basic operation will be that a PPP peer that requires negotiation
>    about  a  SLS  will  send  an  IPCP  CONFREQ  including a list of SLS
>    options.  Every SLS Option will contain a certain  service  the  peer
>    wants to have access to.  The receiving PPP peer will analyse all the
>    included options.  After parsing an SLS  Option,  the  receiving  PPP
>    peer can make the following decisions:

This style would appear to be counter to the normal semantics for PPP
option negotiation.  The usual way this works is that the
Configure-Request sender indicates what options it would like the peer
to adopt when sending data in the other direction.  In mapping this to
the SLS option, I would expect that the system supporting multiple
service levels would *offer* those services to the peer by way of
Configure-Request.   The peer would then Configure-Nak or
Configure-Reject the services it doesn't want and finally
Configure-Ack the set of services it does want.

(All of that assumes that negotiating this information within IPCP is
the right way to go.  I don't think it is.)

>    Cancelling a specific Service
> 
>       To cancel a specific  service,  the  'client'  can  send  an  IPCP
>       CONFREQ  message  containing  an appropriate IPCP SLS Option.  The
>       SLS Option Data field of that appropriate SLS Option must  contain
>       only  the  Service  ID  Parameter,  and  may not contain the other
>       mandatory and optional Service Parameters.
> 
>       If a provider receives an IPCP CONFREQ message containing  an  SLS
>       Option with a Data field containing only the Service ID Parameter,
>       this provider must cancel the service identified by the considered
>       Service ID.
> 
>    Altering a specific Service
> 
>       To alter a specific existing service, the  'client'  can  send  an
>       IPCP  CONFREQ  message  containing an appropriate IPCP SLS Option.
>       The SLS Option Data field of that  SLS  Option  must  contain  the
>       according  Service  ID  Parameter  and  all  the requested Service
>       Parameters (the  changed  Service  Parameters  and  the  unchanged
>       Service Parameters).
> 

I don't think that either of these works the manner intended.  Sending
IPCP Configure-Request will cause the peer's state machine to leave
Opened state and revert to either Req-Sent (RCR-) or Ack-Sent (RCR+).
Either way, IP traffic will abruptly halt and data will (most likely)
be lost at this point and (depending on the implementations used)
routing will be disturbed with a link flap.

I think it's more appropriate and more general to consider an IP-based
protocol to negotiate these profiles (not IPCP; along the same lines
as the way multicast groups are handled with IGMP or int-serv flows
are handled with RSVP).  Alternatively, it might be possible to do
this negotiation with a new NCP for PPP, although I think that's
certainly less desirable than a higher layer signaling solution.

> 4. Security Considerations
> 
>    No security considerations outside  these  described  in  [IPCP]  are
>    foreseen.

I think the granting of access to higher levels of service (above
standard DSCP==0 "best effort") probably has security implications
above those for basic IPCP.

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp