Subject: RE: Extending IPCP for Route Table Entries

From: Doug Kehn <[email-masked]>
Date: Tue, 20 May 2003 11:25:46 -0500

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'; [email-masked]
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         <[email-masked]>
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

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 10:36:55 -0600 (MDT)

> From: Doug Kehn <[email-masked]>

> features must be removed/reduced as every byte counts.

Are you sure that even a penny would be needed for the at most 2000 
instructions needed to implement the fragment of RIP required to
have the same effect as the proposed IPCP option?

Could you justify the implicit claim that it would cost more in the
CPE to implement the necessary fragment of RIP than to implement the
same functions with the propsed IPCP option?  I suspect that in fact
the IPCP implementation would require more code, because there are
more corner cases.  For example, you don't need to handle configure-Naks
and and configure-Rejs in the RIP case.  Both cases require the same
changes to the CPE's routing table.  Both require the same sanity
checking of the route itself.

Given the reported popularity of software n CPE that is not known for
its small size, such as Windows CE, worrying about 100 lines of C or
2000 machine instructions seems misplaced.

> from PPP because of the cost already invested in a PPP infrastructure.

What is a "networked interface" and how does it differ from at "point-to-point 
WAN interface?"  Both seem to involve PPP.

> problems.  If the Route-Add option isn't appealing, maybe reconsider Option

I can't find any such option in http://www.iana.org/assignments/ppp-numbers

Vernon Schryver    [email-masked]