Subject: Re: [Pppext] [Int-area] PPP-to-ethernet

From: Derick Winkworth <[email-masked]>
Date: Sat, 16 Feb 2008 06:07:07 -0800 (PST)

All:

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.

Derick

PS - Also thanks Mark for moving this to a more appropriate place

----- Original Message ----
From: Mark Townsley <[email-masked]>
To: [email-masked]
Cc: Derick Winkworth <[email-masked]>
Sent: Saturday, February 16, 2008 7:21:01 AM
Subject: Re: [Int-area] PPP-to-ethernet

Taking 
this 
to 
the 
pppext 
mailing 
list.

- 
Mark

Derick 
Winkworth 
wrote:
All:
Mulitple 
router 
vendors 
have 
a 
feature 
in 
which 
you 
can 
essentially 
"bridge" 
a 
PPP 
link 
to 
an 
ethernet 
link. 
Cisco 
calls 
this 
feature 
"local-switching." 
Juniper 
calls 
it 
"translational 
cross-connects."
I 
find 
that 
both 
of 
these 
vendors 
implementations 
have 
their 
shortcomings, 
and 
I 
think 
there 
could 
be 
some 
benefit 
to 
creating 
a 
standard 
for 
accomplishing 
this. 
I 
am 
not 
aware 
of 
any 
standard 
for 
doing 
this.
My 
thought 
was 
essentially 
using 
the 
address 
field 
as 
defined 
in 
RFC 
1662. 
Differing 
addresses 
in 
this 
field 
would 
be 
used 
by 
the 
translating 
router 
to 
forward 
traffic 
to 
differing 
neighboring 
routers 
on 
the 
ethernet 
segment. 
So 
there 
would 
effectively 
be 
a 
PPP-address-TO-Ethernet-MAC 
table. 
Neighboring 
routers 
would 
be 
discovered 
via 
IGMP 
or 
IRDP 
(as 
Cisco 
kind 
of 
does 
it 
today, 
but 
"not 
really") 
on 
the 
ethernet 
segment. 
Routers 
responding 
would 
have 
PPP 
addresses 
created 
for 
them 
in 
a 
state-table, 
which 
is 
link-scoped. 
So 
there 
would 
be 
a 
different 
table 
for 
every 
PPP 
link.
At 
the 
IP 
layer, 
the 
remote-end 
PPP 
device 
would 
obviously 
have 
an 
address 
that 
is 
native 
to 
the 
IP 
subnet 
of 
the 
ethernet 
link.
Anyway, 
anyone 
have 
any 
thoughts 
on 
this?
Derick
------------------------------------------------------------------------
Looking 
for 
last 
minute 
shopping 
deals? 
Find 
them 
fast 
with 
Yahoo! 
Search. 
<http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping> 
------------------------------------------------------------------------
_______________________________________________
Int-area 
mailing 
list
[email-masked]
http://www.ietf.org/mailman/listinfo/int-area

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

_______________________________________________
Pppext mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pppext

---

From: James Carlson <[email-masked]>
Date: Tue, 19 Feb 2008 17:11:21 -0500

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

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              <[email-masked]>
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
_______________________________________________
Pppext mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/pppext