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

From: Vernon Schryver <[email-masked]>
Date: Tue, 7 Mar 2000 12:54:00 -0700 (MST)

> From: James Carlson <[email-masked]>
> To: [email-masked], [email-masked],
>         [email-masked], [email-masked]
> Cc: pppext <[email-masked]>

> 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?

Oh, I thought it was.  It clearly is in the PPP Extensions turf.
I hope the authors have subscribed or will subscribe to the PPP
mailing list at [email-masked]
See also http://www.ietf.org/html.charters/pppext-charter.html

> ...
> >    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 understood the authors to mean that the IPCP state machine should
fall down and re-negotiate from scratch.  If that's not what they
meant, then it obviously can't work.  The text should be changed
to make clear that IPCP will shut down at least momentarily.

I think no reasonable PPP implementation would lose any IP packets
due to such a hiccup, but I also realize that most deployed
implementations are unreasonable by that standard.

> 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.

I half disagree.  I think a new NCP to negotiate what is clearly an
aspect of IP would be wrong.  If you do it in PPP, it belongs in IPCP.
I agree that PPP is the wrong place to do this negotiating, unless you
assume that IP with such modified/negotiated Diff-Serv parameters will
never be run except over PPP, and that's certainly false.  There should
be a single mechanism for all such negotiating, and it should work and
work as much the same as possible over all media that carry IP packets.
That suggests it should use some kind of IP packets, from existing RSVP
tactics to new UDP, ICMP, or even SNMP schemes.

> > 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.

That's a good, if understated point.  At the very least, such a document
must contain a proof (in the professional mathematican's sense of an
arguement that convinces someone with mathematical maturity) that no
illicit fun and games are possible with such an IPCP option.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: 07 Mar 2000 15:45:18 -0500

> implementations are unreasonable by that standard.

The likely effect on routing protocols is even more interesting, I
think.  A good implementation should probably have a debouncing
function between IPCP states and OSPF LSA origination, but ...

> aspect of IP would be wrong.

Except that it's not so clearly an aspect of *just* IP.  The
differential queuing services negotiated here could just as easily
apply to diff-serv for MPLS over PPP, couldn't they?

(I do agree that putting it anywhere in PPP is likely a mistake.)

>  If you do it in PPP, it belongs in IPCP.

Yep; that's exactly what I was saying.  Pop it up to a more closely
related signaling function -- diffserv extensions to {insert your
favorite hop-by-hop signaling protocol here}.

-- 
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