Yeah, that last e-mail was not well thought out. Lets ignore that and refer to the first one I sent.
The original thought was just for router-to-router traffic, and the idea was, in the case of dissimilar media-types, to extend the functionality of local-switching/tcc to allow the remote PPP peer to form routing adjacencies to more than one router on an ethernet segment.
The reason, supposedly, for local-switching/tcc in the first place is to allow for L2VPN service within the same device in the same POP. Allowing this for dissimilar media types of course means that sites which may be an aggregation point for hundreds of PVCs or PPP links can be connected via ethernet rather than
many circuits/channels/etc. There is also the case that some sites simply may only be reachable with a particular media. At this point, the switching of dissimilar media types is done strictly on a "point-to-point" basis and in our own testing redundancy and fail over at the head-end ethernet connected site does not work well unless you are doing static routing and pointing to a VRRP or HSRP address. If you want dynamic routing, then it doesn't work as gracefully (or at all).
Here we thought, it would be great for scalability and redundancy if we could somehow allow the remote PPP device to peer, as I said, to multiple routers on the ethernet segment in a datacenter or across datacenters that are connected via ethernet. The address field in the PPP packet would always represent a router on the ethernet segment (either the router it is going to, or the router it came from). On a given ethernet segment,
multiple remote PPP devices would have virtual-mac addresses on the ethernet segment which the PE device is listening for and has mappings for to the remote PPP devices.
So the remote devices would need to support this functionality, and the PE devices in the CO would need to do the actual translating.
I am working on a presentation with diagrams at the moment. I'll send a link. I hope though that the above clarifies this somewhat.
----- Original Message ----
From: James Carlson <james.d.carlson at sun.com>
To: Derick Winkworth <ccie15672 at yahoo.com>
Cc: pppext at ietf.org
Sent: Tuesday, February 19, 2008 4:11:21 PM
Subject: Re: [Pppext] [Int-area] PPP-to-ethernet
Derick
Winkworth
writes:
>
I
coupled
the
router-discovery
piece
with
this
idea
because
I
imagined
we
would
limit
the
traffic
to
router-to-router
traffic,
and
not
allow
hosts
on
the
ethernet
segment
to
talk
directly
to
the
remote
PPP
device.
So
we
could
abandon
that
altogether
and
allow
any
host
to
talk
to
the
remote
PPP
device
directly,
especially
if
we
use
the
LSB
in
the
address
field
in
an
HDLC-like
way
to
allow
for
8
or
16
bit
address
field
length.
>
>
And
I
guess
if
we
go
a
step
further,
we
could
also
effectively
create
mappings
for
any
PPP
link
associated
with
the
ethernet
segment,
so
we
would
also
effectively
bridge
two
or
more
PPP
links
this
way.
If
I
understand
the
proposal
correctly
(and
it's
not
at
all
clear
to
me
that
I
do),
it
sounds
like
you're
proposing
yet
another
way
to
tunnel
PPP
over
other
media
--
in
this
case,
specifically
Ethernet,
but
perhaps
extensible
to
other
media.
But
why
do
we
need
another
way
to
do
this?
Is
the
standards-track
L2TP
effort
not
sufficient
for
the
task?
More
information
about
the
usage
case
(why
would
forwarding
PPP
traffic
itself
make
sense
here
rather
than
terminating
the
connection
and
routing
normally?)
and
the
chosen
solution
(why
invent
a
new
mechanism
rather
than
using
and
perhaps
extending
existing
ones?)
is
needed
in
order
to
move
forward.
--
James
Carlson,
Solaris
Networking
<
james.d.carlson at sun.com>
Sun
Microsystems
/
35
Network
Drive
71.232W
Vox
+1
781
442
2084
MS
UBUR02-212
/
Burlington
MA
01803-2757
42.496N
Fax
+1
781
442
1677
