RE: Extending IPCP for Route Table Entries

>From the outset, it has been acknowledged that this proposal duplicates what
could be done with a routing protocol.  The argument for the duplication is
that a routing protocol is "seen" as overkill when all that the Service
Providers are wanting to do is add a single (okay...maybe two) static route
entries on an interface.  Another factor to consider is the realization that
CPE cost is being driven down to that of a dial-up modem.  Cost reductions
are mainly realized through using lower density flash/RAM (when dealing with
100K+ magnitude every penny counts).  Lower memory density means that
features must be removed/reduced as every byte counts.

Also, Service Providers (I'm referring to broadband) use PPP because it
provides accountability and authentication.  It also resembles the familiar
dial-up model.  However, a problem arises as PPP termination moves off the
PC and on to the CPE.  The CPE now becomes a router but is straddled with a
point-to-point WAN interface when what is really needed is a networked
interface.  I don't see (my opinion of course) Service Providers moving away
from PPP because of the cost already invested in a PPP infrastructure.

At the expense of duplication could another method be found to solve the
problems.  If the Route-Add option isn't appealing, maybe reconsider Option
144 (Subnet mask) again.


-----Original Message-----
From: James Carlson
To: Doug Kehn
Cc: 'Vernon Schryver'; ietf-ppp@xxxxxxxxx
Sent: 5/20/03 10:24 AM
Subject: RE: Extending IPCP  for Route Table Entries

Doug Kehn writes:
> The CO PPP peer is to provide the route information.  The CO PPP peer
is
> telling the CPE to route packets on "this" interface.  The route
information
> could either be a network route or a host route.

That's exactly what RIP-2 and other routing protocols do.

> Each PPP interface has its own PPP state machine.  The analogy is
similar to
> having multiple ethernet NICs.

If you had multiple Ethernet NICs, where would you get your non-local
routes?  You wouldn't have an IPCP to modify.

If some solution works reasonably for Ethernet interfaces, why does
that solution not work for PPP?

> >   - which pair of PPP peers, the pair at the CPE or at the CO, sends
> >       the new IPCP option in an IPCP configure-Req?  My guess 
> > is the CO.
> > 
> 
> The intent was for the CPE to add the option in the Configure-Request.
The
> remote peer could then ACK, NAK, REJ the option just as it does with
the IP
> Address and DNS Address options.

Note that the Microsoft DNS address option is defined backwards and
should not be used as a model here.  It has the "CPE" side specifying
(via Configure-Request) its knowledge of (or lack thereof) the name
servers on the remote side, and requires the remote to correct
erroneous information with Configure-Nak.

> >    - why do you need a netmask for a point-to-point link?
> > 
> 
> A netmask isn't necessarily needed.  If a netmask were available (e.g.
> Option 144), the CPE could treat the point-to-point interface as if it
were
> a networked interface.

Huh?  PPP interfaces *are* network interfaces.

No netmask is required (or even really usable) because they're
point-to-point.

>  Instead of making a host route to the remote peer on
> the PPP interface, the CPE could make a network route [with the remote
peer
> as the gateway] on the PPP interface.
> 
> Without a netmask and in the presence of multiple PPP interfaces, the
CPE
> needs route entries in order to reach specific hosts on specific PPP
links.

... which brings us back to the purpose of routing protocols.

-- 
James Carlson, Solaris Networking         <james.d.carlson@xxxxxxxxxxxx>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677