headers
Mark Townsley | 16 Feb 2008 13:21
Picon
Favicon

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Derick Winkworth | 16 Feb 2008 15:07
Picon
Favicon

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

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 associa ted 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 <townsley <at> cisco.com>
To: pppext <at> ietf.org
Cc: Derick Winkworth <ccie15672 <at> yahoo.com>
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
> Int-area <at> ietf.org
> http://www.ietf.org/mailman/listinfo/int-area
> 



Looking for last minute shopping deals? Find them fast with Yahoo! Search. 
_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
http://www.ietf.org/mailman/listinfo/pppext
Permalink | Reply | 1 comment |
headers
James Carlson | 19 Feb 2008 23:11
Picon

Re: [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
_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
http://www.ietf.org/mailman/listinfo/pppext
Permalink | Reply | 0 comments |
headers
Derick Winkworth | 20 Feb 2008 06:13
Picon
Favicon

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

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 PP P 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-e thernet

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


Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. 
_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
http://www.ietf.org/mailman/listinfo/pppext
Permalink | Reply | 501 comments |
headers
James Carlson | 20 Feb 2008 13:22
Picon

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

Derick Winkworth writes:
> 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.  

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

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.

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

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              <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
_______________________________________________
Pppext mailing list
Pppext <at> ietf.org
http://www.ietf.org/mailman/listinfo/pppext
Permalink | Reply | 501 comments |

Gmane