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

From: Derick Winkworth <[email-masked]>
Date: Tue, 19 Feb 2008 21:13:46 -0800 (PST)

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 <[email-masked]>
To: Derick Winkworth <[email-masked]>
Cc: [email-masked]
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  

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

      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

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

---

From: James Carlson <[email-masked]>
Date: Wed, 20 Feb 2008 07:22:15 -0500

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

I'm not sure why anything special is needed for that.  It's
commonplace to run routing protocols over PPP links and not too
unusual to use proxy-ARP'd links.

But to what benefit?  A PPP link is a single interface.  You don't get
any routing-related advantages by pretending that it does anything
other than connecting two distinct nodes together, and thus has
exactly two peers, do you?

My guess is that you're trying to cover for a lack of routing prowess
in the box that terminates the PPP link itself.  Adding complexity in
the form of tunneled links doesn't sound to me like a good way to fix
that problem.

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

I don't understand.  This is done *today* using L2TP.  It's even done
using the non-standard PPPoE.  What new mechanism is required?

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

Really?  That sounds like an equipment limitation or bug rather than a
statement about the protocol itself.

RIP-2, OSPF, IS-IS, and BGP all work fine for me over PPP links.  HSRP
and VRRP are inapplicable for point-to-point links, as they're not
broadcast-type links, but why would you need those special "dumb host"
hacks anyway?

I'm confused about what problem is really being solved here.

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

I don't agree with your stated rationale for doing this (it doesn't
really help at all with routing), but the solution you're describing
is already available.

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

Somewhat.  But you still haven't explained why the existing tunneling
protocols are insufficient for the task.  I don't think we should
create any new protocols until we understand why the existing ones
don't do the job they were designed to do.

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