From mailman-bounces@core3.amsl.com Fri Feb 1 05:36:56 2008 Return-Path: X-Original-To: ietfarch-pppext-archive@core3.amsl.com Delivered-To: ietfarch-pppext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 359EB28DC42 for ; Fri, 1 Feb 2008 05:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sptsTUntmpF8 for ; Fri, 1 Feb 2008 05:36:12 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF91D28DBE0 for ; Fri, 1 Feb 2008 05:10:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pppext-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:03:16 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/pppext/pppext-archive%40megatron.ietf.org From mailman-bounces@core3.amsl.com Fri Feb 1 05:38:54 2008 Return-Path: X-Original-To: ietfarch-pppext-archive@core3.amsl.com Delivered-To: ietfarch-pppext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F090128D606 for ; Fri, 1 Feb 2008 05:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599] Received: from core3.amsl.com ([127.0.0.1]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrj8erg7pwCb for ; Fri, 1 Feb 2008 05:36:18 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289EB28D673 for ; Fri, 1 Feb 2008 05:10:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: pppext-archive@megatron.ietf.org X-No-Archive: yes Message-ID: Date: Fri, 01 Feb 2008 05:03:15 -0800 Precedence: bulk X-BeenThere: mailman@core3.amsl.com X-Mailman-Version: 2.1.9 List-Id: X-List-Administrivia: yes Sender: mailman-bounces@core3.amsl.com Errors-To: mailman-bounces@core3.amsl.com This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! http://www.ietf.org/mailman/options/pppext/pppext-archive%40megatron.ietf.org From pppext-bounces@ietf.org Sat Feb 16 04:21:17 2008 Return-Path: X-Original-To: ietfarch-pppext-archive@core3.amsl.com Delivered-To: ietfarch-pppext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6469428C16F; Sat, 16 Feb 2008 04:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=-2.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pimt1-oMA-vt; Sat, 16 Feb 2008 04:21:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8217E3A69F4; Sat, 16 Feb 2008 04:21:16 -0800 (PST) X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FF4C28C157 for ; Sat, 16 Feb 2008 04:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx6rUUHhjivx for ; Sat, 16 Feb 2008 04:21:15 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0067D3A69F4 for ; Sat, 16 Feb 2008 04:21:14 -0800 (PST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2008 07:21:13 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1GCLEJa020760; Sat, 16 Feb 2008 07:21:14 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m1GCLBWD015210; Sat, 16 Feb 2008 12:21:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 07:21:11 -0500 Received: from rtp-townsley-vpn3.cisco.com ([10.83.1.100]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Feb 2008 07:21:11 -0500 Message-ID: <47B6D52D.1000602@cisco.com> Date: Sat, 16 Feb 2008 13:21:01 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pppext@ietf.org References: <360414.24128.qm@web57206.mail.re3.yahoo.com> In-Reply-To: <360414.24128.qm@web57206.mail.re3.yahoo.com> X-OriginalArrivalTime: 16 Feb 2008 12:21:11.0582 (UTC) FILETIME=[6A9823E0:01C87096] Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: Derick Winkworth Subject: Re: [Pppext] [Int-area] PPP-to-ethernet X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > http://www.ietf.org/mailman/listinfo/int-area > _______________________________________________ Pppext mailing list Pppext@ietf.org http://www.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Sat Feb 16 06:07:12 2008 Return-Path: X-Original-To: ietfarch-pppext-archive@core3.amsl.com Delivered-To: ietfarch-pppext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0C4D28C139; Sat, 16 Feb 2008 06:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.272 X-Spam-Level: * X-Spam-Status: No, score=1.272 tagged_above=-999 required=5 tests=[AWL=0.709, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvNAJFr97IqT; Sat, 16 Feb 2008 06:07:11 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABC2728C19C; Sat, 16 Feb 2008 06:07:11 -0800 (PST) X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B2B728C15D for ; Sat, 16 Feb 2008 06:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzFu9vFHx3Q9 for ; Sat, 16 Feb 2008 06:07:09 -0800 (PST) Received: from web57202.mail.re3.yahoo.com (web57202.mail.re3.yahoo.com [216.252.111.218]) by core3.amsl.com (Postfix) with SMTP id 2B36628C1A1 for ; Sat, 16 Feb 2008 06:07:09 -0800 (PST) Received: (qmail 84324 invoked by uid 60001); 16 Feb 2008 14:07:07 -0000 X-YMail-OSG: 0pRfk.YVM1nSDHL276qnEXWBTqy4eXgeYa6dKAE.V5MLZN4dph.pf4wHw53e5Gif5TMIVGZErLylMnAgMwJodBIZ49RFFfqX0qDA7liEJVf6Femdp2gTxqGQUgme Received: from [67.53.228.87] by web57202.mail.re3.yahoo.com via HTTP; Sat, 16 Feb 2008 06:07:07 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Sat, 16 Feb 2008 06:07:07 -0800 (PST) From: Derick Winkworth To: pppext@ietf.org MIME-Version: 1.0 Message-ID: <449364.80898.qm@web57202.mail.re3.yahoo.com> Subject: Re: [Pppext] [Int-area] PPP-to-ethernet X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1653965164==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org --===============1653965164== Content-Type: multipart/alternative; boundary="0-465704980-1203170827=:80898" --0-465704980-1203170827=:80898 Content-Type: text/plain; charset=us-ascii 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 To: pppext@ietf.org Cc: Derick Winkworth 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Int-area mailing list > Int-area@ietf.org > 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 --0-465704980-1203170827=:80898 Content-Type: text/html; charset=us-ascii
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 <townsley@cisco.com>
To: pppext@ietf.org
Cc: Derick Winkworth <ccie15672@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@ietf.org
> http://www.ietf.org/mailman/listinfo/int-area
> 



Looking for last minute shopping deals? Find them fast with Yahoo! Search. --0-465704980-1203170827=:80898-- --===============1653965164== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org http://www.ietf.org/mailman/listinfo/pppext --===============1653965164==-- From pppext-bounces@ietf.org Tue Feb 19 14:22:48 2008 Return-Path: X-Original-To: ietfarch-pppext-archive@core3.amsl.com Delivered-To: ietfarch-pppext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDA5D3A6BB6; Tue, 19 Feb 2008 14:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.487 X-Spam-Level: X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jWq90WeXHq1; Tue, 19 Feb 2008 14:22:48 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF3EF3A6E1E; Tue, 19 Feb 2008 14:22:47 -0800 (PST) X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0AE03A6996 for ; Tue, 19 Feb 2008 14:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9w52CtClQ1jz for ; Tue, 19 Feb 2008 14:22:46 -0800 (PST) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id F1D8D28C6B9 for ; Tue, 19 Feb 2008 14:22:45 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1JMMhUj022622 for ; Tue, 19 Feb 2008 22:22:43 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1JMMg8I053057 for ; Tue, 19 Feb 2008 17:22:42 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1JMBNHG008207; Tue, 19 Feb 2008 17:11:23 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1JMBNPq008204; Tue, 19 Feb 2008 17:11:23 -0500 (EST) MIME-Version: 1.0 Message-ID: <18363.21513.890218.268181@gargle.gargle.HOWL> Date: Tue, 19 Feb 2008 17:11:21 -0500 From: James Carlson To: Derick Winkworth In-Reply-To: <449364.80898.qm@web57202.mail.re3.yahoo.com> References: <449364.80898.qm@web57202.mail.re3.yahoo.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: pppext@ietf.org Subject: Re: [Pppext] [Int-area] PPP-to-ethernet X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org 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 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@ietf.org http://www.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Feb 19 21:14:04 2008 Return-Path: X-Original-To: ietfarch-pppext-archive@core3.amsl.com Delivered-To: ietfarch-pppext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 156893A6A47; Tue, 19 Feb 2008 21:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.966 X-Spam-Level: X-Spam-Status: No, score=0.966 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gcbz0infG6cF; Tue, 19 Feb 2008 21:13:51 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBC793A6B75; Tue, 19 Feb 2008 21:13:51 -0800 (PST) X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95593A6A9C for ; Tue, 19 Feb 2008 21:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0baqIsf4TnT for ; Tue, 19 Feb 2008 21:13:49 -0800 (PST) Received: from web57203.mail.re3.yahoo.com (web57203.mail.re3.yahoo.com [216.252.111.219]) by core3.amsl.com (Postfix) with SMTP id 67F5E3A6A47 for ; Tue, 19 Feb 2008 21:13:49 -0800 (PST) Received: (qmail 21405 invoked by uid 60001); 20 Feb 2008 05:13:46 -0000 X-YMail-OSG: 95Ohe0kVM1lw5_RwVRg4CGN9E13ntV3zAyzXj6F9Bok0rnnv3Ncmk1smlg71_unHdwbqGLa72vORqibPq3qmGtPfsUwnhOTwd8UxST0lxwMYcxnYI9DDnEjndBc4vn5dCpyrZsmuQx4ggfE- Received: from [67.53.228.87] by web57203.mail.re3.yahoo.com via HTTP; Tue, 19 Feb 2008 21:13:46 PST X-Mailer: YahooMailRC/818.31 YahooMailWebService/0.7.162 Date: Tue, 19 Feb 2008 21:13:46 -0800 (PST) From: Derick Winkworth To: James Carlson MIME-Version: 1.0 Message-ID: <231655.18751.qm@web57203.mail.re3.yahoo.com> Cc: pppext@ietf.org Subject: Re: [Pppext] [Int-area] PPP-to-ethernet X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0127398320==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org --===============0127398320== Content-Type: multipart/alternative; boundary="0-1304015639-1203484426=:18751" --0-1304015639-1203484426=:18751 Content-Type: text/plain; charset=us-ascii 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 To: Derick Winkworth Cc: pppext@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 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 --0-1304015639-1203484426=:18751 Content-Type: text/html; charset=us-ascii
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@sun.com>
To: Derick Winkworth <ccie15672@yahoo.com>
Cc: pppext@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@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. --0-1304015639-1203484426=:18751-- --===============0127398320== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org http://www.ietf.org/mailman/listinfo/pppext --===============0127398320==-- From pppext-bounces@ietf.org Wed Feb 20 04:33:44 2008 Return-Path: X-Original-To: ietfarch-pppext-archive@core3.amsl.com Delivered-To: ietfarch-pppext-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2CD33A6A37; Wed, 20 Feb 2008 04:33:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.193 X-Spam-Level: X-Spam-Status: No, score=-1.193 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xqv1DvudMmDP; Wed, 20 Feb 2008 04:33:43 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94293A6A03; Wed, 20 Feb 2008 04:33:43 -0800 (PST) X-Original-To: pppext@core3.amsl.com Delivered-To: pppext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134023A6A03 for ; Wed, 20 Feb 2008 04:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-QmDOqNM42T for ; Wed, 20 Feb 2008 04:33:42 -0800 (PST) Received: from sca-ea-mail-2.sun.com (sca-ea-mail-2.Sun.COM [192.18.43.25]) by core3.amsl.com (Postfix) with ESMTP id 2086C3A69A3 for ; Wed, 20 Feb 2008 04:33:42 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by sca-ea-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1KCXa5Q026302 for ; Wed, 20 Feb 2008 12:33:36 GMT Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id m1KCXabF038531 for ; Wed, 20 Feb 2008 07:33:36 -0500 (EST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1KCMGSd010078; Wed, 20 Feb 2008 07:22:16 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.2+Sun/8.14.2/Submit) id m1KCMFCU010075; Wed, 20 Feb 2008 07:22:15 -0500 (EST) MIME-Version: 1.0 Message-ID: <18364.7031.193874.577563@gargle.gargle.HOWL> Date: Wed, 20 Feb 2008 07:22:15 -0500 From: James Carlson To: Derick Winkworth In-Reply-To: <231655.18751.qm@web57203.mail.re3.yahoo.com> References: <231655.18751.qm@web57203.mail.re3.yahoo.com> X-Mailer: VM 7.01 under Emacs 21.3.1 Cc: pppext@ietf.org Subject: Re: [Pppext] [Int-area] PPP-to-ethernet X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org 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 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@ietf.org http://www.ietf.org/mailman/listinfo/pppext