From routing-discussion-admin@ietf.org Sun Jul 6 13:44:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18019 for ; Sun, 6 Jul 2003 13:44:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZDYP-0005Wl-6G; Sun, 06 Jul 2003 13:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xqx4-0003Iw-Mq for routing-discussion@optimus.ietf.org; Wed, 02 Jul 2003 19:23:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01167; Wed, 2 Jul 2003 19:23:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xqx1-0005CY-00; Wed, 02 Jul 2003 19:23:47 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19Xqx1-0005B5-00; Wed, 02 Jul 2003 19:23:47 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 37F1523C4C; Wed, 2 Jul 2003 16:23:29 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h62NN7YB013404; Wed, 2 Jul 2003 16:23:07 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 16:23:07 -0700 From: Greg Shepherd To: agenda@ietf.org, , , , , , Cc: Alex Zinin , Bill Fenner , Keyur Patel , Greg Shepherd Subject: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 02 Jul 2003 23:23:07.0552 (UTC) FILETIME=[E50ABA00:01C340F0] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 16:23:07 -0700 (PDT) Multicast Last-Mile Solutions BOF DESCRIPTION: Successful content distribution business plans have been hampered by the all-or-nothing nature of a multicast routed infrastructure. Several drafts have arisen over the past few years to address the last-mile multicast deployment gap, but have all lost momentum for various reasons. Recent efforts on yet another draft have revealed the need to have all affected parties participate in the effort in order to provide a comprehensive yet simple and deployable solution. A content owner which wishes to build a buisness model around multicast distribution is hampered by the current limited scope of multicast deployment. Their only option today is to purchase multicast transit services from their provider of choice which does not ensure the path between their content and their customers is multicast enabled. The administrative control of the multicast topology in this relationship is restricted to the provider and the content customer. The missing step on the path to full multicast deployment will require a solution which allows the content owner the benefits of multicast replication, independent of the radius of the multicast deployment. The purpose of this BOF is to bring together operators, content providers/owners, application and protocol implementors to discuss the problem and worked towards a mutually desired solution. The expected outcome will be an evaluation of interest, a better defined problem statement, directions for any future progress from the BOF participants. AGENDA: 1. Agenda Bashing (all) 2. Problem description (shep - 10min) 3. Discussion of current gaps and future direction (from the floor) WEB REFERNCE: http://www.shepfarm.com/multicast/last-mile RELEVANT PAST WORK: (this list is possibly incomplete - please send updates) http://www.shepfarm.com/multicast/upim/draft-ietf-mboned-auto-multicast-01.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneling-00.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-umtp-07.txt http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00.txt http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.txt MAILLIST: http://www.shepfarm.com/mailman/listinfo/mtp _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Sun Jul 6 13:44:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18034 for ; Sun, 6 Jul 2003 13:44:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZDYk-0005Xq-SM for routing-discussion-archive@odin.ietf.org; Sun, 06 Jul 2003 13:44:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66HiMK5021310 for routing-discussion-archive@odin.ietf.org; Sun, 6 Jul 2003 13:44:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZDYP-0005Wl-6G; Sun, 06 Jul 2003 13:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Xqx4-0003Iw-Mq for routing-discussion@optimus.ietf.org; Wed, 02 Jul 2003 19:23:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01167; Wed, 2 Jul 2003 19:23:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Xqx1-0005CY-00; Wed, 02 Jul 2003 19:23:47 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19Xqx1-0005B5-00; Wed, 02 Jul 2003 19:23:47 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 37F1523C4C; Wed, 2 Jul 2003 16:23:29 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h62NN7YB013404; Wed, 2 Jul 2003 16:23:07 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Jul 2003 16:23:07 -0700 From: Greg Shepherd To: agenda@ietf.org, , , , , , Cc: Alex Zinin , Bill Fenner , Keyur Patel , Greg Shepherd Subject: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 02 Jul 2003 23:23:07.0552 (UTC) FILETIME=[E50ABA00:01C340F0] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 2 Jul 2003 16:23:07 -0700 (PDT) Multicast Last-Mile Solutions BOF DESCRIPTION: Successful content distribution business plans have been hampered by the all-or-nothing nature of a multicast routed infrastructure. Several drafts have arisen over the past few years to address the last-mile multicast deployment gap, but have all lost momentum for various reasons. Recent efforts on yet another draft have revealed the need to have all affected parties participate in the effort in order to provide a comprehensive yet simple and deployable solution. A content owner which wishes to build a buisness model around multicast distribution is hampered by the current limited scope of multicast deployment. Their only option today is to purchase multicast transit services from their provider of choice which does not ensure the path between their content and their customers is multicast enabled. The administrative control of the multicast topology in this relationship is restricted to the provider and the content customer. The missing step on the path to full multicast deployment will require a solution which allows the content owner the benefits of multicast replication, independent of the radius of the multicast deployment. The purpose of this BOF is to bring together operators, content providers/owners, application and protocol implementors to discuss the problem and worked towards a mutually desired solution. The expected outcome will be an evaluation of interest, a better defined problem statement, directions for any future progress from the BOF participants. AGENDA: 1. Agenda Bashing (all) 2. Problem description (shep - 10min) 3. Discussion of current gaps and future direction (from the floor) WEB REFERNCE: http://www.shepfarm.com/multicast/last-mile RELEVANT PAST WORK: (this list is possibly incomplete - please send updates) http://www.shepfarm.com/multicast/upim/draft-ietf-mboned-auto-multicast-01.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneling-00.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-umtp-07.txt http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00.txt http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.txt MAILLIST: http://www.shepfarm.com/mailman/listinfo/mtp _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Sun Jul 6 17:21:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22810 for ; Sun, 6 Jul 2003 17:21:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZGwR-0002ir-49; Sun, 06 Jul 2003 17:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZGwN-0002id-8U for routing-discussion@optimus.ietf.org; Sun, 06 Jul 2003 17:20:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22806 for ; Sun, 6 Jul 2003 17:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZGwK-0004mh-00 for routing-discussion@ietf.org; Sun, 06 Jul 2003 17:20:56 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19ZGwJ-0004me-00 for routing-discussion@ietf.org; Sun, 06 Jul 2003 17:20:56 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA08586; Sun, 6 Jul 2003 14:20:06 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id OAA03133; Sun, 6 Jul 2003 14:20:42 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h66LKbj05800; Sun, 6 Jul 2003 14:20:37 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 6 Jul 2003 17:20:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcND5mbzkYQdQyuAQrmTp60qt/Z+awAHOcJA From: "Manfredi, Albert E" To: "Greg Shepherd" , , , X-OriginalArrivalTime: 06 Jul 2003 21:20:40.0219 (UTC) FILETIME=[7357AEB0:01C34404] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 6 Jul 2003 17:20:39 -0400 Content-Transfer-Encoding: quoted-printable Interesting subject. From what I'm told, one of the big obstacles in = enabling multicast all the way through is that use of multicast reduces = the revenues ISPs can expect for providing network services? That's a = plausible reason. Are there others? Security? Bert > -----Original Message----- > From: Greg Shepherd [mailto:shep@procket.com] > Sent: Wednesday, July 02, 2003 7:23 PM > To: agenda@ietf.org; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; > magma@innovationslab.net; routing-discussion@ietf.org; > wg-multicast@internet2.edu; mboned@network-services.uoregon.edu > Cc: Alex Zinin; Bill Fenner; Keyur Patel; Greg Shepherd > Subject: BOF Agenda - Multicast Last-Mile Solutions >=20 >=20 >=20 > Multicast Last-Mile Solutions BOF >=20 > DESCRIPTION: >=20 > Successful content distribution business plans have been=20 > hampered by the > all-or-nothing nature of a multicast routed infrastructure.=20 > Several drafts > have arisen over the past few years to address the last-mile multicast > deployment gap, but have all lost momentum for various reasons. Recent > efforts on yet another draft have revealed the need to have=20 > all affected > parties participate in the effort in order to provide a=20 > comprehensive yet > simple and deployable solution. >=20 > A content owner which wishes to build a buisness model around=20 > multicast > distribution is hampered by the current limited scope of multicast > deployment. Their only option today is to purchase multicast transit > services from their provider of choice which does not ensure the path > between their content and their customers is multicast enabled. The > administrative control of the multicast topology in this=20 > relationship is > restricted to the provider and the content customer. The=20 > missing step on > the path to full multicast deployment will require a solution which > allows the content owner the benefits of multicast replication, > independent of the radius of the multicast deployment. >=20 > The purpose of this BOF is to bring together operators, content > providers/owners, application and protocol implementors to discuss the > problem and worked towards a mutually desired solution. The expected > outcome will be an evaluation of interest, a better defined problem > statement, directions for any future progress from the BOF > participants. >=20 > AGENDA: >=20 > 1. Agenda Bashing (all) > 2. Problem description (shep - 10min) > 3. Discussion of current gaps and future direction (from the floor) >=20 > WEB REFERNCE: > http://www.shepfarm.com/multicast/last-mile >=20 > RELEVANT PAST WORK: (this list is possibly incomplete - please send > updates) > http://www.shepfarm.com/multicast/upim/draft-ietf-mboned-auto- multicast-01.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneli= ng-00.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-umtp-07.txt http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00= .txt http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.tx= t MAILLIST: http://www.shepfarm.com/mailman/listinfo/mtp _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Sun Jul 6 17:21:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22825 for ; Sun, 6 Jul 2003 17:21:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZGwc-0002jq-CQ for routing-discussion-archive@odin.ietf.org; Sun, 06 Jul 2003 17:21:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h66LLE7C010522 for routing-discussion-archive@odin.ietf.org; Sun, 6 Jul 2003 17:21:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZGwR-0002ir-49; Sun, 06 Jul 2003 17:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZGwN-0002id-8U for routing-discussion@optimus.ietf.org; Sun, 06 Jul 2003 17:20:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22806 for ; Sun, 6 Jul 2003 17:20:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZGwK-0004mh-00 for routing-discussion@ietf.org; Sun, 06 Jul 2003 17:20:56 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19ZGwJ-0004me-00 for routing-discussion@ietf.org; Sun, 06 Jul 2003 17:20:56 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA08586; Sun, 6 Jul 2003 14:20:06 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id OAA03133; Sun, 6 Jul 2003 14:20:42 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h66LKbj05800; Sun, 6 Jul 2003 14:20:37 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 6 Jul 2003 17:20:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcND5mbzkYQdQyuAQrmTp60qt/Z+awAHOcJA From: "Manfredi, Albert E" To: "Greg Shepherd" , , , X-OriginalArrivalTime: 06 Jul 2003 21:20:40.0219 (UTC) FILETIME=[7357AEB0:01C34404] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 6 Jul 2003 17:20:39 -0400 Content-Transfer-Encoding: quoted-printable Interesting subject. From what I'm told, one of the big obstacles in = enabling multicast all the way through is that use of multicast reduces = the revenues ISPs can expect for providing network services? That's a = plausible reason. Are there others? Security? Bert > -----Original Message----- > From: Greg Shepherd [mailto:shep@procket.com] > Sent: Wednesday, July 02, 2003 7:23 PM > To: agenda@ietf.org; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; > magma@innovationslab.net; routing-discussion@ietf.org; > wg-multicast@internet2.edu; mboned@network-services.uoregon.edu > Cc: Alex Zinin; Bill Fenner; Keyur Patel; Greg Shepherd > Subject: BOF Agenda - Multicast Last-Mile Solutions >=20 >=20 >=20 > Multicast Last-Mile Solutions BOF >=20 > DESCRIPTION: >=20 > Successful content distribution business plans have been=20 > hampered by the > all-or-nothing nature of a multicast routed infrastructure.=20 > Several drafts > have arisen over the past few years to address the last-mile multicast > deployment gap, but have all lost momentum for various reasons. Recent > efforts on yet another draft have revealed the need to have=20 > all affected > parties participate in the effort in order to provide a=20 > comprehensive yet > simple and deployable solution. >=20 > A content owner which wishes to build a buisness model around=20 > multicast > distribution is hampered by the current limited scope of multicast > deployment. Their only option today is to purchase multicast transit > services from their provider of choice which does not ensure the path > between their content and their customers is multicast enabled. The > administrative control of the multicast topology in this=20 > relationship is > restricted to the provider and the content customer. The=20 > missing step on > the path to full multicast deployment will require a solution which > allows the content owner the benefits of multicast replication, > independent of the radius of the multicast deployment. >=20 > The purpose of this BOF is to bring together operators, content > providers/owners, application and protocol implementors to discuss the > problem and worked towards a mutually desired solution. The expected > outcome will be an evaluation of interest, a better defined problem > statement, directions for any future progress from the BOF > participants. >=20 > AGENDA: >=20 > 1. Agenda Bashing (all) > 2. Problem description (shep - 10min) > 3. Discussion of current gaps and future direction (from the floor) >=20 > WEB REFERNCE: > http://www.shepfarm.com/multicast/last-mile >=20 > RELEVANT PAST WORK: (this list is possibly incomplete - please send > updates) > http://www.shepfarm.com/multicast/upim/draft-ietf-mboned-auto- multicast-01.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneli= ng-00.txt http://www.shepfarm.com/multicast/upim/draft-finlayson-umtp-07.txt http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00= .txt http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.tx= t MAILLIST: http://www.shepfarm.com/mailman/listinfo/mtp _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 10:05:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25618 for ; Mon, 7 Jul 2003 10:05:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWc1-0002HV-KV; Mon, 07 Jul 2003 10:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWbs-0002Gz-Jv for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 10:04:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25486 for ; Mon, 7 Jul 2003 10:04:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWbq-0004Ve-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:04:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19ZWbp-0004Va-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:04:49 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA04611; Mon, 7 Jul 2003 07:04:08 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id HAA08603; Mon, 7 Jul 2003 07:04:43 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67E4cj18450; Mon, 7 Jul 2003 07:04:38 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 10:04:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEYpvRf/g9KaLyTYab4cFwV7BHnAALHSTw From: "Manfredi, Albert E" To: "Jon Crowcroft" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 14:04:41.0433 (UTC) FILETIME=[B5E77490:01C34490] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:04:41 -0400 Content-Transfer-Encoding: quoted-printable Jon Crowcroft wrote: > since practically no access ISPs allow multicast, how do they know it > reduces revenue?=20 >=20 > this is a typical armchair economist argument But I suspect it's the major obstacle in its deployment. We've implemented RFC 1112/2236 quite successfully, and it's pretty much = the only way to go, when using IP for *control system* communications. = Problem is, commercial gear that supports multicast is not all that = plentiful. Like firewalls, for example. Seems to be "ooops, you didn't = say multicast." > obviously if all the users using simultaneous unicast switched to > multicast this MIGHT be true, but the real point is that it enables > new sources, applications and services, and might therefore INCREASE > revenue....noone can say for sure... >=20 > i think the technical obstacles (cable tv modem head end, DSLAM, and > other minimal support for igmp magic, security, charging for group > size and other stuff are the critical points and think this BOG Is an > althogether > Most Exellent Idea Agreed. Determining group size, btw, is itself not so easy to do, since = membership need not be announced if another member has already multicast = his join report to the router. Maybe an accurate method for determining = group size will be an important topic? Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 10:05:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25633 for ; Mon, 7 Jul 2003 10:05:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWcO-0002Ic-I3 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 10:05:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67E5O9t008835 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 10:05:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWc1-0002HV-KV; Mon, 07 Jul 2003 10:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWbs-0002Gz-Jv for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 10:04:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25486 for ; Mon, 7 Jul 2003 10:04:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWbq-0004Ve-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:04:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19ZWbp-0004Va-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:04:49 -0400 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id HAA04611; Mon, 7 Jul 2003 07:04:08 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id HAA08603; Mon, 7 Jul 2003 07:04:43 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67E4cj18450; Mon, 7 Jul 2003 07:04:38 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 10:04:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEYpvRf/g9KaLyTYab4cFwV7BHnAALHSTw From: "Manfredi, Albert E" To: "Jon Crowcroft" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 14:04:41.0433 (UTC) FILETIME=[B5E77490:01C34490] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:04:41 -0400 Content-Transfer-Encoding: quoted-printable Jon Crowcroft wrote: > since practically no access ISPs allow multicast, how do they know it > reduces revenue?=20 >=20 > this is a typical armchair economist argument But I suspect it's the major obstacle in its deployment. We've implemented RFC 1112/2236 quite successfully, and it's pretty much = the only way to go, when using IP for *control system* communications. = Problem is, commercial gear that supports multicast is not all that = plentiful. Like firewalls, for example. Seems to be "ooops, you didn't = say multicast." > obviously if all the users using simultaneous unicast switched to > multicast this MIGHT be true, but the real point is that it enables > new sources, applications and services, and might therefore INCREASE > revenue....noone can say for sure... >=20 > i think the technical obstacles (cable tv modem head end, DSLAM, and > other minimal support for igmp magic, security, charging for group > size and other stuff are the critical points and think this BOG Is an > althogether > Most Exellent Idea Agreed. Determining group size, btw, is itself not so easy to do, since = membership need not be announced if another member has already multicast = his join report to the router. Maybe an accurate method for determining = group size will be an important topic? Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 10:06:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25732 for ; Mon, 7 Jul 2003 10:06:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWcz-0002Mk-KH; Mon, 07 Jul 2003 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWcx-0002KV-PB for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 10:05:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25656 for ; Mon, 7 Jul 2003 10:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWcv-0004We-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:05:57 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 19ZWcu-0004Wb-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:05:57 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67EViA24701 for ; Mon, 7 Jul 2003 20:01:44 +0530 Received: from alok ([203.124.140.97]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67EVh824695 for ; Mon, 7 Jul 2003 20:01:43 +0530 Message-ID: <029a01c34491$6ead3e60$81c802c0@alok> From: "Alok Dube" To: Subject: decison process in routing protocols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 19:39:43 +0530 Content-Transfer-Encoding: 7bit Hi, I have a basic question on routing. Is it possible to develop an accurate "cost based" decision process in a routing protocol if the information passed to a routing node is based on the "decision process" run by another node? Isn't "decision process" supposed to be local to each peer? -thanks Alok _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 10:06:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25749 for ; Mon, 7 Jul 2003 10:06:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWd1-0002OA-1u for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 10:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67E63Cm009162 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 10:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWcz-0002Mk-KH; Mon, 07 Jul 2003 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWcx-0002KV-PB for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 10:05:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25656 for ; Mon, 7 Jul 2003 10:05:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWcv-0004We-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:05:57 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 19ZWcu-0004Wb-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:05:57 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67EViA24701 for ; Mon, 7 Jul 2003 20:01:44 +0530 Received: from alok ([203.124.140.97]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67EVh824695 for ; Mon, 7 Jul 2003 20:01:43 +0530 Message-ID: <029a01c34491$6ead3e60$81c802c0@alok> From: "Alok Dube" To: Subject: decison process in routing protocols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 19:39:43 +0530 Content-Transfer-Encoding: 7bit Hi, I have a basic question on routing. Is it possible to develop an accurate "cost based" decision process in a routing protocol if the information passed to a routing node is based on the "decision process" run by another node? Isn't "decision process" supposed to be local to each peer? -thanks Alok _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 10:25:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27252 for ; Mon, 7 Jul 2003 10:25:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWvN-0003Tv-Mo; Mon, 07 Jul 2003 10:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWuW-0003TP-Pf for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 10:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27223 for ; Mon, 7 Jul 2003 10:24:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWuU-0004kM-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:24:06 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19ZWuT-0004jT-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:24:05 -0400 Received: from maroon.juniper.net (maroon.juniper.net [172.17.28.131]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h67ENTu52628; Mon, 7 Jul 2003 07:23:29 -0700 (PDT) (envelope-from lenny@juniper.net) Received: from localhost (lenny@localhost) by maroon.juniper.net (8.11.6/8.11.3) with ESMTP id h67ENSh77837; Mon, 7 Jul 2003 07:23:28 -0700 (PDT) (envelope-from lenny@juniper.net) X-Authentication-Warning: maroon.juniper.net: lenny owned process doing -bs From: Leonard Giuliano To: "Manfredi, Albert E" cc: Jon Crowcroft , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: <20030707070909.X66497@maroon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 07:23:28 -0700 (PDT) On Mon, 7 Jul 2003, Manfredi, Albert E wrote: -) Jon Crowcroft wrote: -) -) > since practically no access ISPs allow multicast, how do they know it -) > reduces revenue? -) > -) > this is a typical armchair economist argument -) -) But I suspect it's the major obstacle in its deployment. -) Not really. It's usually the first thing that (uninformed) ISP product managers come up with, but on the list of reasons why mcast isn't deployed everywhere, the unicast-revenue-cannibalizing argument is fairly far down on the list. This argument would make more sense if there actually was unicast traffic that mcast could cannibalize. We are talking mainly about video here, and for all practical purposes, there really is no video of any kind of critical mass on the Internet today. The reason is simple- there's no business plan that could support unicast video. Anyone who tried to do it is now out of business or just gave up after realizing that you are just throwing money away if you want to do video over unicast. As Jon pointed out, the reality is that mcast traffic would be NEW content that is not currently possible/viable with unicast, rather than traffic that's available via unicast but transported more efficiently than unicast. New traffic on the network means hopefully new revenue, so your unicast content and revenue stays constant, while mcast simply augments it. -Lenny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 11:15:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27251 for ; Mon, 7 Jul 2003 10:25:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWvY-0003V4-7I for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 10:25:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67EPChi013453 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 10:25:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWvN-0003Tv-Mo; Mon, 07 Jul 2003 10:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZWuW-0003TP-Pf for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 10:24:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27223 for ; Mon, 7 Jul 2003 10:24:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZWuU-0004kM-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:24:06 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19ZWuT-0004jT-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 10:24:05 -0400 Received: from maroon.juniper.net (maroon.juniper.net [172.17.28.131]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h67ENTu52628; Mon, 7 Jul 2003 07:23:29 -0700 (PDT) (envelope-from lenny@juniper.net) Received: from localhost (lenny@localhost) by maroon.juniper.net (8.11.6/8.11.3) with ESMTP id h67ENSh77837; Mon, 7 Jul 2003 07:23:28 -0700 (PDT) (envelope-from lenny@juniper.net) X-Authentication-Warning: maroon.juniper.net: lenny owned process doing -bs From: Leonard Giuliano To: "Manfredi, Albert E" cc: Jon Crowcroft , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: <20030707070909.X66497@maroon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 07:23:28 -0700 (PDT) On Mon, 7 Jul 2003, Manfredi, Albert E wrote: -) Jon Crowcroft wrote: -) -) > since practically no access ISPs allow multicast, how do they know it -) > reduces revenue? -) > -) > this is a typical armchair economist argument -) -) But I suspect it's the major obstacle in its deployment. -) Not really. It's usually the first thing that (uninformed) ISP product managers come up with, but on the list of reasons why mcast isn't deployed everywhere, the unicast-revenue-cannibalizing argument is fairly far down on the list. This argument would make more sense if there actually was unicast traffic that mcast could cannibalize. We are talking mainly about video here, and for all practical purposes, there really is no video of any kind of critical mass on the Internet today. The reason is simple- there's no business plan that could support unicast video. Anyone who tried to do it is now out of business or just gave up after realizing that you are just throwing money away if you want to do video over unicast. As Jon pointed out, the reality is that mcast traffic would be NEW content that is not currently possible/viable with unicast, rather than traffic that's available via unicast but transported more efficiently than unicast. New traffic on the network means hopefully new revenue, so your unicast content and revenue stays constant, while mcast simply augments it. -Lenny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 11:54:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00893 for ; Mon, 7 Jul 2003 11:54:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYIW-0000IV-W4; Mon, 07 Jul 2003 11:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYHw-0000CN-Nj for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 11:52:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00833 for ; Mon, 7 Jul 2003 11:52:21 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYHv-0005qI-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:52:23 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ZYHq-0005p5-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:52:20 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h67HeZlq013279; Mon, 7 Jul 2003 10:40:35 -0700 To: David Meyer cc: Jon Crowcroft , "Manfredi, Albert E" , Greg Shepherd , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <20030707081620.A24670@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:40:34 -0700 (PDT) On Mon, 7 Jul 2003, David Meyer wrote: > >> since practically no access ISPs allow multicast, how do they know it > >> reduces revenue? > >> > >> this is a typical armchair economist argument > > No ISP/carrier that I have ever worked for (or even, that > I know of, where ISP == "IP Transport Bandwidth > Provider") has ever been able to demonstrate any kind of > CAPEX savings due to multicast. In fact, the places where it > might be most useful (tail circuits) provide the opposite > incentive to the bandwidth provider (why would I provide > you a technology that allows you to buy less of my > product [bandwidth]?) As Lenny pointed out, any 'savings' assumes canabilizing unicast content for multicast. BUT a large-audience multicast transport service could bring a whole new range of content at a much higher quality (read bit-rate) which could be a completely different service to sell. Its not about saving bandwidth in the core. Its about creating a transport service which allows successfull biz-models/services for content owners which are ISP customers. Having profitable customers is a good thing. > OTOH, perhaps that's a selling point when marketing to > large content providers or the like. The reality, > however, is that such custmers (and in fact, most large > consumers of b/w) want carrier diverse facilities, kinda > blowing away that argument in any event. Clearly there > are cross-incentives here. Yup, I've seen the same. But I also think a large content owner wants first the largest audience possible. > >> obviously if all the users using simultaneous unicast switched to > >> multicast this MIGHT be true, but the real point is that it enables > >> new sources, applications and services, and might therefore INCREASE > >> revenue....noone can say for sure... > >> > >> i think the technical obstacles (cable tv modem head end, DSLAM, and > >> other minimal support for igmp magic, security, charging for group > >> size and other stuff are the critical points and think this BOG Is an > >> althogether > >> Most Exellent Idea > > Yep. Thanks for your support Dave, Greg > Dave > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 11:54:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00911 for ; Mon, 7 Jul 2003 11:54:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYJ6-0000L4-R8 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 11:53:57 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Fraq4001296 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 11:53:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYIW-0000IV-W4; Mon, 07 Jul 2003 11:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYHw-0000CN-Nj for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 11:52:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00833 for ; Mon, 7 Jul 2003 11:52:21 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYHv-0005qI-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:52:23 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19ZYHq-0005p5-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:52:20 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h67HeZlq013279; Mon, 7 Jul 2003 10:40:35 -0700 To: David Meyer cc: Jon Crowcroft , "Manfredi, Albert E" , Greg Shepherd , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <20030707081620.A24670@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:40:34 -0700 (PDT) On Mon, 7 Jul 2003, David Meyer wrote: > >> since practically no access ISPs allow multicast, how do they know it > >> reduces revenue? > >> > >> this is a typical armchair economist argument > > No ISP/carrier that I have ever worked for (or even, that > I know of, where ISP == "IP Transport Bandwidth > Provider") has ever been able to demonstrate any kind of > CAPEX savings due to multicast. In fact, the places where it > might be most useful (tail circuits) provide the opposite > incentive to the bandwidth provider (why would I provide > you a technology that allows you to buy less of my > product [bandwidth]?) As Lenny pointed out, any 'savings' assumes canabilizing unicast content for multicast. BUT a large-audience multicast transport service could bring a whole new range of content at a much higher quality (read bit-rate) which could be a completely different service to sell. Its not about saving bandwidth in the core. Its about creating a transport service which allows successfull biz-models/services for content owners which are ISP customers. Having profitable customers is a good thing. > OTOH, perhaps that's a selling point when marketing to > large content providers or the like. The reality, > however, is that such custmers (and in fact, most large > consumers of b/w) want carrier diverse facilities, kinda > blowing away that argument in any event. Clearly there > are cross-incentives here. Yup, I've seen the same. But I also think a large content owner wants first the largest audience possible. > >> obviously if all the users using simultaneous unicast switched to > >> multicast this MIGHT be true, but the real point is that it enables > >> new sources, applications and services, and might therefore INCREASE > >> revenue....noone can say for sure... > >> > >> i think the technical obstacles (cable tv modem head end, DSLAM, and > >> other minimal support for igmp magic, security, charging for group > >> size and other stuff are the critical points and think this BOG Is an > >> althogether > >> Most Exellent Idea > > Yep. Thanks for your support Dave, Greg > Dave > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 13:48:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05092 for ; Mon, 7 Jul 2003 13:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Za4r-0008KG-9r; Mon, 07 Jul 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Za49-0008J0-9j for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 13:46:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05024 for ; Mon, 7 Jul 2003 13:46:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Za47-0007Qr-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:46:15 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19Za46-0007QK-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:46:14 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 6A30C344D8; Mon, 7 Jul 2003 11:02:51 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h67HjhYB022190; Mon, 7 Jul 2003 10:45:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: decison process in routing protocols Message-ID: Thread-Topic: decison process in routing protocols Thread-Index: AcNEkQMfL67c456kT223XXhLlVXZlQAHfntQ From: "Tony Li" To: "Alok Dube" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:45:43 -0700 Content-Transfer-Encoding: quoted-printable A decision process can be run anywhere that has complete and accurate information. Conversely, anyplace (including locally) that does not have complete and accurate information cannot successfully run a decision process. Thus, locality is only an implementation issue. From that perspective, however, having a failure that makes it impossible for data to make it to or from the decision process would make the forwarding engine effectively useless. Protecting against such failures requires more redundancy and more system complexity. Therefore, remote decision processes are not very common. Tony | -----Original Message----- | From: Alok Dube [mailto:alok.dube@apara.com]=20 | Sent: Monday, July 07, 2003 7:10 AM | To: routing-discussion@ietf.org | Subject: decison process in routing protocols | =20 | =20 | Hi, | =20 | I have a basic question on routing. | =20 | Is it possible to develop an accurate "cost based"=20 | decision process in a | routing protocol if the information passed to a routing=20 | node is based on the | "decision process" run by another node? | =20 | Isn't "decision process" supposed to be local to each peer? | =20 | -thanks | Alok | =20 | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 13:48:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05103 for ; Mon, 7 Jul 2003 13:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Za5n-0008RS-JA for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 13:48:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Hlxw6032446 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 13:47:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Za4r-0008KG-9r; Mon, 07 Jul 2003 13:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Za49-0008J0-9j for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 13:46:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05024 for ; Mon, 7 Jul 2003 13:46:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Za47-0007Qr-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:46:15 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19Za46-0007QK-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:46:14 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 6A30C344D8; Mon, 7 Jul 2003 11:02:51 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h67HjhYB022190; Mon, 7 Jul 2003 10:45:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: decison process in routing protocols Message-ID: Thread-Topic: decison process in routing protocols Thread-Index: AcNEkQMfL67c456kT223XXhLlVXZlQAHfntQ From: "Tony Li" To: "Alok Dube" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 10:45:43 -0700 Content-Transfer-Encoding: quoted-printable A decision process can be run anywhere that has complete and accurate information. Conversely, anyplace (including locally) that does not have complete and accurate information cannot successfully run a decision process. Thus, locality is only an implementation issue. From that perspective, however, having a failure that makes it impossible for data to make it to or from the decision process would make the forwarding engine effectively useless. Protecting against such failures requires more redundancy and more system complexity. Therefore, remote decision processes are not very common. Tony | -----Original Message----- | From: Alok Dube [mailto:alok.dube@apara.com]=20 | Sent: Monday, July 07, 2003 7:10 AM | To: routing-discussion@ietf.org | Subject: decison process in routing protocols | =20 | =20 | Hi, | =20 | I have a basic question on routing. | =20 | Is it possible to develop an accurate "cost based"=20 | decision process in a | routing protocol if the information passed to a routing=20 | node is based on the | "decision process" run by another node? | =20 | Isn't "decision process" supposed to be local to each peer? | =20 | -thanks | Alok | =20 | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 13:59:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05426 for ; Mon, 7 Jul 2003 13:59:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaGX-0000oe-BH for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 13:59:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Hx5Up003136 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 13:59:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaGS-0000nJ-FP; Mon, 07 Jul 2003 13:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaFZ-0000lp-Ta for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 13:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05369 for ; Mon, 7 Jul 2003 13:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZaFX-0007d5-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:58:03 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 19ZaFX-0007d1-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:58:03 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67INtA29283 for ; Mon, 7 Jul 2003 23:53:55 +0530 Received: from alok (PPP-219-65-134-209.bng.vsnl.net.in [219.65.134.209]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67INp829274; Mon, 7 Jul 2003 23:53:51 +0530 Message-ID: <001601c344b1$db245f40$81c802c0@alok> From: "Alok Dube" To: "Tony Li" Cc: References: Subject: Re: decison process in routing protocols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 23:31:49 +0530 Content-Transfer-Encoding: 7bit Hi Tony, What confuses me is this: how would "running a decison process at any place which has complete and accurate information" work fine at any place but the node at which needs to compute the path to an end point from "its" perspective? or is each node where we "run the decision process" supposed to compute the path from the "end node's perspective"(the place where the node is supposed to put that information as a result of the decision process) or from "its perspective"? -thanks Alok ----- Original Message ----- From: "Tony Li" To: "Alok Dube" ; Sent: Monday, July 07, 2003 11:15 PM Subject: RE: decison process in routing protocols > > > A decision process can be run anywhere that has complete > and accurate information. Conversely, anyplace (including > locally) that does not have complete and accurate information > cannot successfully run a decision process. > > Thus, locality is only an implementation issue. From that > perspective, however, having a failure that makes it impossible > for data to make it to or from the decision process would make > the forwarding engine effectively useless. Protecting against > such failures requires more redundancy and more system complexity. > Therefore, remote decision processes are not very common. > > Tony > > > | -----Original Message----- > | From: Alok Dube [mailto:alok.dube@apara.com] > | Sent: Monday, July 07, 2003 7:10 AM > | To: routing-discussion@ietf.org > | Subject: decison process in routing protocols > | > | > | Hi, > | > | I have a basic question on routing. > | > | Is it possible to develop an accurate "cost based" > | decision process in a > | routing protocol if the information passed to a routing > | node is based on the > | "decision process" run by another node? > | > | Isn't "decision process" supposed to be local to each peer? > | > | -thanks > | Alok > | > | > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 14:25:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06361 for ; Mon, 7 Jul 2003 14:25:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zafd-0002X1-Ga; Mon, 07 Jul 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zaf1-0002Vp-54 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:24:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06276 for ; Mon, 7 Jul 2003 14:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zaey-0000Gn-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:24:20 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zaex-0000Gi-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:24:20 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19Zaeg-0004wg-00; Mon, 07 Jul 2003 19:24:02 +0100 Date: Mon, 7 Jul 2003 19:24:01 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Tony Li cc: Alok Dube , "" Subject: RE: decison process in routing protocols In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19Zaeg-0004wg-00*8W/JgzZ2a9U* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Tony Li wrote: > A decision process can be run anywhere that has complete > and accurate information. Conversely, anyplace (including > locally) that does not have complete and accurate information > cannot successfully run a decision process. > > Thus, locality is only an implementation issue. But locality determines what information is _known_ to be complete and accurate. Hence split horizon and poison reverse, no? (Okay, Alok asked about cost and I'm considering cost as distance.) L. > From that > perspective, however, having a failure that makes it impossible > for data to make it to or from the decision process would make > the forwarding engine effectively useless. Protecting against > such failures requires more redundancy and more system complexity. > Therefore, remote decision processes are not very common. > > Tony > > > | -----Original Message----- > | From: Alok Dube [mailto:alok.dube@apara.com] > | Sent: Monday, July 07, 2003 7:10 AM > | To: routing-discussion@ietf.org > | Subject: decison process in routing protocols > | > | > | Hi, > | > | I have a basic question on routing. > | > | Is it possible to develop an accurate "cost based" > | decision process in a > | routing protocol if the information passed to a routing > | node is based on the > | "decision process" run by another node? > | > | Isn't "decision process" supposed to be local to each peer? > | > | -thanks > | Alok > | > | > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 14:36:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06948 for ; Mon, 7 Jul 2003 14:36:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaqG-0003Lo-TT; Mon, 07 Jul 2003 14:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZapT-0003L9-FN for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06861 for ; Mon, 7 Jul 2003 14:35:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZapQ-0000Td-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:35:08 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19ZapP-0000T0-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:35:08 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02160; Mon, 7 Jul 2003 14:34:34 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14049; Mon, 7 Jul 2003 14:34:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jul 2003 14:34:35 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6F4A@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Tony Li'" , Alok Dube , routing-discussion@ietf.org Subject: RE: decison process in routing protocols MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 14:34:33 -0400 -> A decision process can be run anywhere that has complete -> and accurate information. Conversely, anyplace (including -> locally) that does not have complete and accurate information -> cannot successfully run a decision process. -> -> Thus, locality is only an implementation issue. From that -> perspective, however, having a failure that makes it impossible -> for data to make it to or from the decision process would make -> the forwarding engine effectively useless. Protecting against -> such failures requires more redundancy and more system complexity. -> Therefore, remote decision processes are not very common. That said, remote decision processes are inevitable in certain situations. For example, inter-area/AS source routing requires some kind of distributed routing information (mostly from borders routers) to make an apt decision. Distributed routing decisions (with partial information) is common in mobile ad-hoc networks. Theoretical foundation do exists for distributed routing algorithms. Recently, MPLS is started using such algos. In the past there is some work in IP distributed routing called "open router". Where multiple forwarding planes are controlled by one are many control plane decision processes. SS7 also does a kind of distributed out-of-band decisions. Venkata. -> Tony -> -> -> | -----Original Message----- -> | From: Alok Dube [mailto:alok.dube@apara.com] -> | Sent: Monday, July 07, 2003 7:10 AM -> | To: routing-discussion@ietf.org -> | Subject: decison process in routing protocols -> | -> | -> | Hi, -> | -> | I have a basic question on routing. -> | -> | Is it possible to develop an accurate "cost based" -> | decision process in a -> | routing protocol if the information passed to a routing -> | node is based on the -> | "decision process" run by another node? -> | -> | Isn't "decision process" supposed to be local to each peer? -> | -> | -thanks -> | Alok -> | -> | -> | _______________________________________________ -> | routing-discussion mailing list -> | routing-discussion@ietf.org -> | https://www1.ietf.org/mailman/listinfo/routing-discussion -> | -> -> _______________________________________________ -> routing-discussion mailing list -> routing-discussion@ietf.org -> https://www1.ietf.org/mailman/listinfo/routing-discussion -> _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 14:38:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07085 for ; Mon, 7 Jul 2003 14:38:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZasD-0003mf-1Q for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 14:38:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Ic1P0014539 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 14:38:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZasC-0003lh-FV; Mon, 07 Jul 2003 14:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZarR-0003Ys-9c for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:37:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07030 for ; Mon, 7 Jul 2003 14:37:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZarO-0000Vx-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:37:10 -0400 Received: from sc-f100-01.extremenetworks.com ([63.251.106.30] helo=extrgate1.extremenetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19ZarN-0000UT-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:37:10 -0400 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Jul 2003 11:36:18 -0700 Message-ID: <1B8A2DD33C49824F8D9021678C127213DF4606@sc-msexch-04.extremenetworks.com> From: Shehzad Merchant To: "'Lloyd Wood'" Cc: Alok Dube , routing-discussion@ietf.org, Tony Li Subject: RE: decison process in routing protocols MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 11:36:32 -0700 The decision process is both a policy and implementation issue. If the remote node has the policy information to execute the decision process on behalf of other nodes, and has "accurate and complete" topology information as the other nodes would see it (for example a network wide view of the topology as in a link state protocol), conceivably it could execute the decision process on behalf of other nodes if one chooses to implement things that way. -S -----Original Message----- From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] Sent: Monday, July 07, 2003 11:24 AM To: Tony Li Cc: Alok Dube; routing-discussion@ietf.org Subject: RE: decison process in routing protocols On Mon, 7 Jul 2003, Tony Li wrote: > A decision process can be run anywhere that has complete > and accurate information. Conversely, anyplace (including > locally) that does not have complete and accurate information > cannot successfully run a decision process. > > Thus, locality is only an implementation issue. But locality determines what information is _known_ to be complete and accurate. Hence split horizon and poison reverse, no? (Okay, Alok asked about cost and I'm considering cost as distance.) L. > From that > perspective, however, having a failure that makes it impossible > for data to make it to or from the decision process would make > the forwarding engine effectively useless. Protecting against > such failures requires more redundancy and more system complexity. > Therefore, remote decision processes are not very common. > > Tony > > > | -----Original Message----- > | From: Alok Dube [mailto:alok.dube@apara.com] > | Sent: Monday, July 07, 2003 7:10 AM > | To: routing-discussion@ietf.org > | Subject: decison process in routing protocols > | > | > | Hi, > | > | I have a basic question on routing. > | > | Is it possible to develop an accurate "cost based" > | decision process in a > | routing protocol if the information passed to a routing > | node is based on the > | "decision process" run by another node? > | > | Isn't "decision process" supposed to be local to each peer? > | > | -thanks > | Alok > | > | > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 14:45:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05427 for ; Mon, 7 Jul 2003 13:59:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaGS-0000nJ-FP; Mon, 07 Jul 2003 13:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaFZ-0000lp-Ta for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 13:58:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05369 for ; Mon, 7 Jul 2003 13:58:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZaFX-0007d5-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:58:03 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 19ZaFX-0007d1-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 13:58:03 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67INtA29283 for ; Mon, 7 Jul 2003 23:53:55 +0530 Received: from alok (PPP-219-65-134-209.bng.vsnl.net.in [219.65.134.209]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67INp829274; Mon, 7 Jul 2003 23:53:51 +0530 Message-ID: <001601c344b1$db245f40$81c802c0@alok> From: "Alok Dube" To: "Tony Li" Cc: References: Subject: Re: decison process in routing protocols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 23:31:49 +0530 Content-Transfer-Encoding: 7bit Hi Tony, What confuses me is this: how would "running a decison process at any place which has complete and accurate information" work fine at any place but the node at which needs to compute the path to an end point from "its" perspective? or is each node where we "run the decision process" supposed to compute the path from the "end node's perspective"(the place where the node is supposed to put that information as a result of the decision process) or from "its perspective"? -thanks Alok ----- Original Message ----- From: "Tony Li" To: "Alok Dube" ; Sent: Monday, July 07, 2003 11:15 PM Subject: RE: decison process in routing protocols > > > A decision process can be run anywhere that has complete > and accurate information. Conversely, anyplace (including > locally) that does not have complete and accurate information > cannot successfully run a decision process. > > Thus, locality is only an implementation issue. From that > perspective, however, having a failure that makes it impossible > for data to make it to or from the decision process would make > the forwarding engine effectively useless. Protecting against > such failures requires more redundancy and more system complexity. > Therefore, remote decision processes are not very common. > > Tony > > > | -----Original Message----- > | From: Alok Dube [mailto:alok.dube@apara.com] > | Sent: Monday, July 07, 2003 7:10 AM > | To: routing-discussion@ietf.org > | Subject: decison process in routing protocols > | > | > | Hi, > | > | I have a basic question on routing. > | > | Is it possible to develop an accurate "cost based" > | decision process in a > | routing protocol if the information passed to a routing > | node is based on the > | "decision process" run by another node? > | > | Isn't "decision process" supposed to be local to each peer? > | > | -thanks > | Alok > | > | > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 14:48:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07512 for ; Mon, 7 Jul 2003 14:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb23-0004XC-Kr for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 14:48:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67ImBCe017419 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 14:48:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb1t-0004Vz-Aq; Mon, 07 Jul 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb1X-0004Vb-4J for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:47:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07487 for ; Mon, 7 Jul 2003 14:47:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zb1U-0000hO-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:47:36 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 19Zb1T-0000hL-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:47:35 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67JDQA30306 for ; Tue, 8 Jul 2003 00:43:27 +0530 Received: from alok (PPP-219-65-135-24.bng.vsnl.net.in [219.65.135.24]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67JDO830300 for ; Tue, 8 Jul 2003 00:43:24 +0530 Message-ID: <009a01c344b8$c66fe900$81c802c0@alok> From: "Alok Dube" To: References: <39469E08BD83D411A3D900204840EC55FB6F4A@vie-msgusr-01.dc.fore.com> Subject: Re: decison process in routing protocols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 00:21:21 +0530 Content-Transfer-Encoding: 7bit > In the past there is some work in IP distributed routing > called "open router". Where multiple forwarding planes are > controlled by one are many control plane decision processes. > SS7 also does a kind of distributed out-of-band decisions. Hi, do these compute the "decison process for the best route" from the "forwarding plane's" perspective? -thanks Alok _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 14:49:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07569 for ; Mon, 7 Jul 2003 14:49:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb2r-0004dq-3t; Mon, 07 Jul 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb2L-0004YL-A2 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07498 for ; Mon, 7 Jul 2003 14:48:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zb2I-0000i4-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:48:26 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19Zb2H-0000i0-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:48:25 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA24522; Mon, 7 Jul 2003 11:47:46 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id LAA11902; Mon, 7 Jul 2003 11:48:21 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67ImGj12033; Mon, 7 Jul 2003 11:48:16 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 14:48:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEn6yZSwg0fhMxT1K79RjsDLGcqQAFFj8A From: "Manfredi, Albert E" To: Cc: "routing-discussion" , "wg-multicast" , "mboned" , X-OriginalArrivalTime: 07 Jul 2003 18:48:15.0481 (UTC) FILETIME=[53112690:01C344B8] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 14:48:15 -0400 Content-Transfer-Encoding: quoted-printable Greg Shepherd wrote: > As Lenny pointed out, any 'savings' assumes canabilizing=20 > unicast content > for multicast. BUT a large-audience multicast transport service could > bring a whole new range of content at a much higher quality (read > bit-rate) which could be a completely different service to=20 > sell. Sounds like digital TV (DTV) over the Internet. That would seem like a = no-brainer to me too, but it isn't a no-brainer to the ISPs if they = think they can make more revenues by using INefficient means of = transport. That's been the problem all along. For non-commercial = applications, no argument at all. Multicast is often the only sensible = answer. Add reliable transport to UDP multicast, like RFCs 2357, 2887, = 3048, and 3453, and its usefulness is self evident even for other than = streaming media traffic. > Its not > about saving bandwidth in the core. I guess I'm missing this part. Why is not saving bandwidth in the core = important as well? Take DTV distribution as the example. I would think = that you'd set up a multicast with its scope limited to a TV market = size, so as not to infringe on the TV affiliates in other markets. The = routers inside this area would need to dedicate a lot less bandwidth to = DTV streams if they could create multicast trees instead of unicast = streams to each edge router, no? > But I also think a large content owner wants > first the largest audience possible. I agree, for the content provider. Not necessarily for the distribution = system provider. He simply wants the highest revenues for distributing = the product. You'd either need to convince the ISPs that they can profitably = distribute content with multicast that would be unprofitable with = unicast, or you'd need a killer app that MUST use multicast. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 14:49:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07581 for ; Mon, 7 Jul 2003 14:49:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb2r-0004eq-SD for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 14:49:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67In1Oh017900 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 14:49:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb2r-0004dq-3t; Mon, 07 Jul 2003 14:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb2L-0004YL-A2 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:48:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07498 for ; Mon, 7 Jul 2003 14:48:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zb2I-0000i4-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:48:26 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19Zb2H-0000i0-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:48:25 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id LAA24522; Mon, 7 Jul 2003 11:47:46 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id LAA11902; Mon, 7 Jul 2003 11:48:21 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67ImGj12033; Mon, 7 Jul 2003 11:48:16 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 14:48:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEn6yZSwg0fhMxT1K79RjsDLGcqQAFFj8A From: "Manfredi, Albert E" To: Cc: "routing-discussion" , "wg-multicast" , "mboned" , X-OriginalArrivalTime: 07 Jul 2003 18:48:15.0481 (UTC) FILETIME=[53112690:01C344B8] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 14:48:15 -0400 Content-Transfer-Encoding: quoted-printable Greg Shepherd wrote: > As Lenny pointed out, any 'savings' assumes canabilizing=20 > unicast content > for multicast. BUT a large-audience multicast transport service could > bring a whole new range of content at a much higher quality (read > bit-rate) which could be a completely different service to=20 > sell. Sounds like digital TV (DTV) over the Internet. That would seem like a = no-brainer to me too, but it isn't a no-brainer to the ISPs if they = think they can make more revenues by using INefficient means of = transport. That's been the problem all along. For non-commercial = applications, no argument at all. Multicast is often the only sensible = answer. Add reliable transport to UDP multicast, like RFCs 2357, 2887, = 3048, and 3453, and its usefulness is self evident even for other than = streaming media traffic. > Its not > about saving bandwidth in the core. I guess I'm missing this part. Why is not saving bandwidth in the core = important as well? Take DTV distribution as the example. I would think = that you'd set up a multicast with its scope limited to a TV market = size, so as not to infringe on the TV affiliates in other markets. The = routers inside this area would need to dedicate a lot less bandwidth to = DTV streams if they could create multicast trees instead of unicast = streams to each edge router, no? > But I also think a large content owner wants > first the largest audience possible. I agree, for the content provider. Not necessarily for the distribution = system provider. He simply wants the highest revenues for distributing = the product. You'd either need to convince the ISPs that they can profitably = distribute content with multicast that would be unprofitable with = unicast, or you'd need a killer app that MUST use multicast. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 14:55:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07882 for ; Mon, 7 Jul 2003 14:55:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb8f-0004xi-7u; Mon, 07 Jul 2003 14:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb8J-0004xM-LO for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07771 for ; Mon, 7 Jul 2003 14:54:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zb8G-0000pn-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:54:36 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zb8F-0000pe-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:54:36 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19Zb83-0005xK-00; Mon, 07 Jul 2003 19:54:23 +0100 Date: Mon, 7 Jul 2003 19:54:21 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Leonard Giuliano cc: "Manfredi, Albert E" , Jon Crowcroft , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <20030707070909.X66497@maroon.juniper.net> Message-ID: References: <20030707070909.X66497@maroon.juniper.net> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19Zb83-0005xK-00*hgecRxdPhlM* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Leonard Giuliano wrote: > Not really. It's usually the first thing that (uninformed) ISP product > managers come up with, but on the list of reasons why mcast isn't deployed > everywhere, the unicast-revenue-cannibalizing argument is fairly far down > on the list. That's really a billing problem, not a multicast problem. You just explain to the ISP that they can charge multiple customers for the same multicast packet, but that their accounting systems need work to do that properly. (multicast makes a lot of sense in a satellite broadcast environment, where link utilisation matters. If you can resell your constrained capacity, multicast increases, not decreases, your revenue.) L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 14:55:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07898 for ; Mon, 7 Jul 2003 14:55:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb8i-0004zI-Q3 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 14:55:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67It4kP019157 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 14:55:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb8f-0004xi-7u; Mon, 07 Jul 2003 14:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb8J-0004xM-LO for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:54:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07771 for ; Mon, 7 Jul 2003 14:54:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zb8G-0000pn-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:54:36 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zb8F-0000pe-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:54:36 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19Zb83-0005xK-00; Mon, 07 Jul 2003 19:54:23 +0100 Date: Mon, 7 Jul 2003 19:54:21 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Leonard Giuliano cc: "Manfredi, Albert E" , Jon Crowcroft , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <20030707070909.X66497@maroon.juniper.net> Message-ID: References: <20030707070909.X66497@maroon.juniper.net> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19Zb83-0005xK-00*hgecRxdPhlM* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Leonard Giuliano wrote: > Not really. It's usually the first thing that (uninformed) ISP product > managers come up with, but on the list of reasons why mcast isn't deployed > everywhere, the unicast-revenue-cannibalizing argument is fairly far down > on the list. That's really a billing problem, not a multicast problem. You just explain to the ISP that they can charge multiple customers for the same multicast packet, but that their accounting systems need work to do that properly. (multicast makes a lot of sense in a satellite broadcast environment, where link utilisation matters. If you can resell your constrained capacity, multicast increases, not decreases, your revenue.) L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 15:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09314 for ; Mon, 7 Jul 2003 15:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbP9-0005yS-Ib for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 15:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67JC3ht022950 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 15:12:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbP5-0005xL-Tx; Mon, 07 Jul 2003 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbP4-0005wr-8w for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09252 for ; Mon, 7 Jul 2003 15:11:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZbP0-0001Ab-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:11:54 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19ZbOz-0001AA-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:11:53 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h67JAlt105684; Mon, 7 Jul 2003 14:10:47 -0500 Message-Id: <5.2.0.9.2.20030707140014.02100ec0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Lloyd Wood From: Bill Nickless Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Cc: routing-discussion , wg-multicast , mboned In-Reply-To: References: <20030707070909.X66497@maroon.juniper.net> <20030707070909.X66497@maroon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 14:10:34 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 07:54 PM 7/7/2003 +0100, Lloyd Wood wrote: >(multicast makes a lot of sense in a satellite broadcast environment, > where link utilisation matters. If you can resell your > constrained capacity, multicast increases, not decreases, your > revenue.) Exactly right. I ran into an example of that recently. Check out Nanometrics Seismological Instruments. They market satellite networks of seismometers. http://www.nanometrics.ca/products/naqs.htm Nanometrics uses UDP/IP over multicast for transport of data across the satellite channel. It's a slick setup. From that web page: NAQS Server has all the hooks to support large network configurations in mission critical installations. NAQS Server supports UDP/IP multicast. This permits fully independent installations to operate concurrently, simultaneously processing data from the same remote stations. With two or more NAQS Server systems operating in parallel, customers can migrate system configuration changes and software updates from a secondary test installation to the primary NAQS Server system. This approach to system administration effectively eliminates system down time due to incorrect configuration. Nanometrics' big selling point is how efficiently they use the space segment bandwidth for a seismological sensor network. Their example: Nanometrics recommends allocation 6.6kbps for a typical 3 channel 100sps seismograph station. This provides the bandwidth required for continuous first-difference compressed data, error-correction retransmission and protocol overheads. A single carrier of 112 kbps can support 17 such channels: 16 remotes and 1 central hub. Libra can efficiently support networks of any number of remotes by configuring data rates and adding carriers as needed. Intelsat, which operates satellites around the world, publishes $5800 per year as their standard tariff rate for a five year, 100 kHz Ku-Band spot beam lease. If a network consists of 16 remotes, the monthly operating cost of each is $30. (Disclosure statement: I'm not connected with Nanometrics in any way, either as an investor, customer, or vendor. I sat through one of their presentations a few weeks ago and was positively impressed.) === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwnFtawgm7ipJDXBAQGThQP/W/OhB75s55JUYBbjeaB9zR78yFDYoZLd iJq/zU3TnvVd/smJ/WI9BsFj+JL0uJh4Uuvtvw1RVYUcEavGuAWVbP4+vMrvIqoV GwhzI2Q0QzapjTxZlMiaE21jf/kuu/b8/GIdAUGKKXHjMYsmcC3+zfN/ZL9ZCO/p GvsTaNfVN6w= =eDzy -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 15:12:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09312 for ; Mon, 7 Jul 2003 15:12:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbP5-0005xL-Tx; Mon, 07 Jul 2003 15:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbP4-0005wr-8w for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:11:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09252 for ; Mon, 7 Jul 2003 15:11:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZbP0-0001Ab-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:11:54 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19ZbOz-0001AA-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:11:53 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h67JAlt105684; Mon, 7 Jul 2003 14:10:47 -0500 Message-Id: <5.2.0.9.2.20030707140014.02100ec0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Lloyd Wood From: Bill Nickless Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Cc: routing-discussion , wg-multicast , mboned In-Reply-To: References: <20030707070909.X66497@maroon.juniper.net> <20030707070909.X66497@maroon.juniper.net> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 14:10:34 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 07:54 PM 7/7/2003 +0100, Lloyd Wood wrote: >(multicast makes a lot of sense in a satellite broadcast environment, > where link utilisation matters. If you can resell your > constrained capacity, multicast increases, not decreases, your > revenue.) Exactly right. I ran into an example of that recently. Check out Nanometrics Seismological Instruments. They market satellite networks of seismometers. http://www.nanometrics.ca/products/naqs.htm Nanometrics uses UDP/IP over multicast for transport of data across the satellite channel. It's a slick setup. From that web page: NAQS Server has all the hooks to support large network configurations in mission critical installations. NAQS Server supports UDP/IP multicast. This permits fully independent installations to operate concurrently, simultaneously processing data from the same remote stations. With two or more NAQS Server systems operating in parallel, customers can migrate system configuration changes and software updates from a secondary test installation to the primary NAQS Server system. This approach to system administration effectively eliminates system down time due to incorrect configuration. Nanometrics' big selling point is how efficiently they use the space segment bandwidth for a seismological sensor network. Their example: Nanometrics recommends allocation 6.6kbps for a typical 3 channel 100sps seismograph station. This provides the bandwidth required for continuous first-difference compressed data, error-correction retransmission and protocol overheads. A single carrier of 112 kbps can support 17 such channels: 16 remotes and 1 central hub. Libra can efficiently support networks of any number of remotes by configuring data rates and adding carriers as needed. Intelsat, which operates satellites around the world, publishes $5800 per year as their standard tariff rate for a five year, 100 kHz Ku-Band spot beam lease. If a network consists of 16 remotes, the monthly operating cost of each is $30. (Disclosure statement: I'm not connected with Nanometrics in any way, either as an investor, customer, or vendor. I sat through one of their presentations a few weeks ago and was positively impressed.) === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwnFtawgm7ipJDXBAQGThQP/W/OhB75s55JUYBbjeaB9zR78yFDYoZLd iJq/zU3TnvVd/smJ/WI9BsFj+JL0uJh4Uuvtvw1RVYUcEavGuAWVbP4+vMrvIqoV GwhzI2Q0QzapjTxZlMiaE21jf/kuu/b8/GIdAUGKKXHjMYsmcC3+zfN/ZL9ZCO/p GvsTaNfVN6w= =eDzy -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 15:15:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06362 for ; Mon, 7 Jul 2003 14:25:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zafm-0002Y4-4O for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 14:25:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67IPASu009797 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 14:25:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zafd-0002X1-Ga; Mon, 07 Jul 2003 14:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zaf1-0002Vp-54 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:24:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06276 for ; Mon, 7 Jul 2003 14:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zaey-0000Gn-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:24:20 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zaex-0000Gi-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:24:20 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19Zaeg-0004wg-00; Mon, 07 Jul 2003 19:24:02 +0100 Date: Mon, 7 Jul 2003 19:24:01 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Tony Li cc: Alok Dube , "" Subject: RE: decison process in routing protocols In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19Zaeg-0004wg-00*8W/JgzZ2a9U* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Tony Li wrote: > A decision process can be run anywhere that has complete > and accurate information. Conversely, anyplace (including > locally) that does not have complete and accurate information > cannot successfully run a decision process. > > Thus, locality is only an implementation issue. But locality determines what information is _known_ to be complete and accurate. Hence split horizon and poison reverse, no? (Okay, Alok asked about cost and I'm considering cost as distance.) L. > From that > perspective, however, having a failure that makes it impossible > for data to make it to or from the decision process would make > the forwarding engine effectively useless. Protecting against > such failures requires more redundancy and more system complexity. > Therefore, remote decision processes are not very common. > > Tony > > > | -----Original Message----- > | From: Alok Dube [mailto:alok.dube@apara.com] > | Sent: Monday, July 07, 2003 7:10 AM > | To: routing-discussion@ietf.org > | Subject: decison process in routing protocols > | > | > | Hi, > | > | I have a basic question on routing. > | > | Is it possible to develop an accurate "cost based" > | decision process in a > | routing protocol if the information passed to a routing > | node is based on the > | "decision process" run by another node? > | > | Isn't "decision process" supposed to be local to each peer? > | > | -thanks > | Alok > | > | > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 15:25:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06950 for ; Mon, 7 Jul 2003 14:36:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaqI-0003Mf-P7 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 14:36:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Ia2uL012934 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 14:36:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZaqG-0003Lo-TT; Mon, 07 Jul 2003 14:36:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZapT-0003L9-FN for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:35:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06861 for ; Mon, 7 Jul 2003 14:35:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZapQ-0000Td-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:35:08 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19ZapP-0000T0-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:35:08 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA02160; Mon, 7 Jul 2003 14:34:34 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA14049; Mon, 7 Jul 2003 14:34:36 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Jul 2003 14:34:35 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6F4A@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Tony Li'" , Alok Dube , routing-discussion@ietf.org Subject: RE: decison process in routing protocols MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 14:34:33 -0400 -> A decision process can be run anywhere that has complete -> and accurate information. Conversely, anyplace (including -> locally) that does not have complete and accurate information -> cannot successfully run a decision process. -> -> Thus, locality is only an implementation issue. From that -> perspective, however, having a failure that makes it impossible -> for data to make it to or from the decision process would make -> the forwarding engine effectively useless. Protecting against -> such failures requires more redundancy and more system complexity. -> Therefore, remote decision processes are not very common. That said, remote decision processes are inevitable in certain situations. For example, inter-area/AS source routing requires some kind of distributed routing information (mostly from borders routers) to make an apt decision. Distributed routing decisions (with partial information) is common in mobile ad-hoc networks. Theoretical foundation do exists for distributed routing algorithms. Recently, MPLS is started using such algos. In the past there is some work in IP distributed routing called "open router". Where multiple forwarding planes are controlled by one are many control plane decision processes. SS7 also does a kind of distributed out-of-band decisions. Venkata. -> Tony -> -> -> | -----Original Message----- -> | From: Alok Dube [mailto:alok.dube@apara.com] -> | Sent: Monday, July 07, 2003 7:10 AM -> | To: routing-discussion@ietf.org -> | Subject: decison process in routing protocols -> | -> | -> | Hi, -> | -> | I have a basic question on routing. -> | -> | Is it possible to develop an accurate "cost based" -> | decision process in a -> | routing protocol if the information passed to a routing -> | node is based on the -> | "decision process" run by another node? -> | -> | Isn't "decision process" supposed to be local to each peer? -> | -> | -thanks -> | Alok -> | -> | -> | _______________________________________________ -> | routing-discussion mailing list -> | routing-discussion@ietf.org -> | https://www1.ietf.org/mailman/listinfo/routing-discussion -> | -> -> _______________________________________________ -> routing-discussion mailing list -> routing-discussion@ietf.org -> https://www1.ietf.org/mailman/listinfo/routing-discussion -> _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 15:25:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07083 for ; Mon, 7 Jul 2003 14:38:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZasC-0003lh-FV; Mon, 07 Jul 2003 14:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZarR-0003Ys-9c for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:37:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07030 for ; Mon, 7 Jul 2003 14:37:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZarO-0000Vx-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:37:10 -0400 Received: from sc-f100-01.extremenetworks.com ([63.251.106.30] helo=extrgate1.extremenetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19ZarN-0000UT-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:37:10 -0400 Received: by extrgate1.extremenetworks.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Jul 2003 11:36:18 -0700 Message-ID: <1B8A2DD33C49824F8D9021678C127213DF4606@sc-msexch-04.extremenetworks.com> From: Shehzad Merchant To: "'Lloyd Wood'" Cc: Alok Dube , routing-discussion@ietf.org, Tony Li Subject: RE: decison process in routing protocols MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 11:36:32 -0700 The decision process is both a policy and implementation issue. If the remote node has the policy information to execute the decision process on behalf of other nodes, and has "accurate and complete" topology information as the other nodes would see it (for example a network wide view of the topology as in a link state protocol), conceivably it could execute the decision process on behalf of other nodes if one chooses to implement things that way. -S -----Original Message----- From: Lloyd Wood [mailto:l.wood@eim.surrey.ac.uk] Sent: Monday, July 07, 2003 11:24 AM To: Tony Li Cc: Alok Dube; routing-discussion@ietf.org Subject: RE: decison process in routing protocols On Mon, 7 Jul 2003, Tony Li wrote: > A decision process can be run anywhere that has complete > and accurate information. Conversely, anyplace (including > locally) that does not have complete and accurate information > cannot successfully run a decision process. > > Thus, locality is only an implementation issue. But locality determines what information is _known_ to be complete and accurate. Hence split horizon and poison reverse, no? (Okay, Alok asked about cost and I'm considering cost as distance.) L. > From that > perspective, however, having a failure that makes it impossible > for data to make it to or from the decision process would make > the forwarding engine effectively useless. Protecting against > such failures requires more redundancy and more system complexity. > Therefore, remote decision processes are not very common. > > Tony > > > | -----Original Message----- > | From: Alok Dube [mailto:alok.dube@apara.com] > | Sent: Monday, July 07, 2003 7:10 AM > | To: routing-discussion@ietf.org > | Subject: decison process in routing protocols > | > | > | Hi, > | > | I have a basic question on routing. > | > | Is it possible to develop an accurate "cost based" > | decision process in a > | routing protocol if the information passed to a routing > | node is based on the > | "decision process" run by another node? > | > | Isn't "decision process" supposed to be local to each peer? > | > | -thanks > | Alok > | > | > | _______________________________________________ > | routing-discussion mailing list > | routing-discussion@ietf.org > | https://www1.ietf.org/mailman/listinfo/routing-discussion > | > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 15:27:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10557 for ; Mon, 7 Jul 2003 15:27:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbdg-0006eJ-Sw; Mon, 07 Jul 2003 15:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbcs-0006b2-Om for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10507 for ; Mon, 7 Jul 2003 15:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbcr-0001Oc-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:26:13 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19Zbcq-0001OZ-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:26:12 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA14928; Mon, 7 Jul 2003 12:25:28 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA18064; Mon, 7 Jul 2003 12:26:03 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67JPvj00629; Mon, 7 Jul 2003 12:25:58 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 15:25:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEu8+IeFMVNX3FSkWsmkufdo1kNgAAISGQ From: "Manfredi, Albert E" To: "Bill Nickless" , "Lloyd Wood" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 19:25:08.0812 (UTC) FILETIME=[7A50A8C0:01C344BD] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 15:25:08 -0400 Content-Transfer-Encoding: quoted-printable > At 07:54 PM 7/7/2003 +0100, Lloyd Wood wrote: > >(multicast makes a lot of sense in a satellite broadcast environment, > > where link utilisation matters. If you can resell your > > constrained capacity, multicast increases, not decreases, your > > revenue.) >=20 > Exactly right. I ran into an example of that recently. Sorry, but I had exactly the opposite reaction. Over a broadcast channel, such as satellite, it seems to me, any sort of = encapsulation is just fine. At the receiving end*s*, the receivers can = easily reformat the packet to be unicast or multicast, to enable the = appropriate routing where routing matters. The broadcast channel's individual streams can be differentiated in any = number of ways, including the use of Class D addresses certainly. But = that makes a weak argument for IP Multicast, I think. For instance, = what's wrong with using PIDs in MPEG-2 Transport Stream? Or what about = differentiating based only on a LLC/SNAP header ID? Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 15:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10775 for ; Mon, 7 Jul 2003 15:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbkP-0006xN-Nu; Mon, 07 Jul 2003 15:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbjn-0006wx-BF for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:33:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10711 for ; Mon, 7 Jul 2003 15:33:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbjm-0001UC-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:33:22 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zbjl-0001U9-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:33:21 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19ZbjY-0007Ea-00; Mon, 07 Jul 2003 20:33:08 +0100 Date: Mon, 7 Jul 2003 20:33:07 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: Bill Nickless , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19ZbjY-0007Ea-00*xvSbDe6inag* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Manfredi, Albert E wrote: > > At 07:54 PM 7/7/2003 +0100, Lloyd Wood wrote: > > >(multicast makes a lot of sense in a satellite broadcast environment, > > > where link utilisation matters. If you can resell your > > > constrained capacity, multicast increases, not decreases, your > > > revenue.) > > > > Exactly right. I ran into an example of that recently. > > Sorry, but I had exactly the opposite reaction. > > Over a broadcast channel, such as satellite, it seems to me, any > sort of encapsulation is just fine. At the receiving end*s*, the > receivers can easily reformat the packet to be unicast or multicast, > to enable the appropriate routing where routing matters. what do you mean by 'reformat the packet'? > The broadcast channel's individual streams can be differentiated in > any number of ways, including the use of Class D addresses > certainly. But that makes a weak argument for IP Multicast, I think. > For instance, what's wrong with using PIDs in MPEG-2 Transport > Stream? Or what about differentiating based only on a LLC/SNAP > header ID? You'd have to indicate that the multicast packet was a multicast packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down the layers. L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 15:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10776 for ; Mon, 7 Jul 2003 15:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbkS-0006zq-9c for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 15:34:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67JY4hN026884 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 15:34:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbkP-0006xN-Nu; Mon, 07 Jul 2003 15:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbjn-0006wx-BF for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:33:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10711 for ; Mon, 7 Jul 2003 15:33:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbjm-0001UC-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:33:22 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zbjl-0001U9-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:33:21 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19ZbjY-0007Ea-00; Mon, 07 Jul 2003 20:33:08 +0100 Date: Mon, 7 Jul 2003 20:33:07 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: Bill Nickless , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19ZbjY-0007Ea-00*xvSbDe6inag* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Manfredi, Albert E wrote: > > At 07:54 PM 7/7/2003 +0100, Lloyd Wood wrote: > > >(multicast makes a lot of sense in a satellite broadcast environment, > > > where link utilisation matters. If you can resell your > > > constrained capacity, multicast increases, not decreases, your > > > revenue.) > > > > Exactly right. I ran into an example of that recently. > > Sorry, but I had exactly the opposite reaction. > > Over a broadcast channel, such as satellite, it seems to me, any > sort of encapsulation is just fine. At the receiving end*s*, the > receivers can easily reformat the packet to be unicast or multicast, > to enable the appropriate routing where routing matters. what do you mean by 'reformat the packet'? > The broadcast channel's individual streams can be differentiated in > any number of ways, including the use of Class D addresses > certainly. But that makes a weak argument for IP Multicast, I think. > For instance, what's wrong with using PIDs in MPEG-2 Transport > Stream? Or what about differentiating based only on a LLC/SNAP > header ID? You'd have to indicate that the multicast packet was a multicast packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down the layers. L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 15:35:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07513 for ; Mon, 7 Jul 2003 14:48:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb1t-0004Vz-Aq; Mon, 07 Jul 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zb1X-0004Vb-4J for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:47:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07487 for ; Mon, 7 Jul 2003 14:47:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zb1U-0000hO-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:47:36 -0400 Received: from [64.106.140.220] (helo=mail.apara.com) by ietf-mx with esmtp (Exim 4.12) id 19Zb1T-0000hL-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:47:35 -0400 Received: from mail.apara.com (localhost.localdomain [127.0.0.1]) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67JDQA30306 for ; Tue, 8 Jul 2003 00:43:27 +0530 Received: from alok (PPP-219-65-135-24.bng.vsnl.net.in [219.65.135.24]) (authenticated) by mail.apara.com (8.11.6/8.11.6) with ESMTP id h67JDO830300 for ; Tue, 8 Jul 2003 00:43:24 +0530 Message-ID: <009a01c344b8$c66fe900$81c802c0@alok> From: "Alok Dube" To: References: <39469E08BD83D411A3D900204840EC55FB6F4A@vie-msgusr-01.dc.fore.com> Subject: Re: decison process in routing protocols MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 00:21:21 +0530 Content-Transfer-Encoding: 7bit > In the past there is some work in IP distributed routing > called "open router". Where multiple forwarding planes are > controlled by one are many control plane decision processes. > SS7 also does a kind of distributed out-of-band decisions. Hi, do these compute the "decison process for the best route" from the "forwarding plane's" perspective? -thanks Alok _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 15:42:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11271 for ; Mon, 7 Jul 2003 15:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZbsD-0007fN-Gp for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 15:42:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Jg5mI029458 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 15:42:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbs9-0007dS-VP; Mon, 07 Jul 2003 15:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbr9-0007cs-Sx for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:40:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11142 for ; Mon, 7 Jul 2003 15:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbr8-0001aP-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:40:58 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19Zbr7-0001aM-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:40:57 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA12100; Mon, 7 Jul 2003 12:40:54 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA02823; Mon, 7 Jul 2003 12:40:53 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67Jelj00152; Mon, 7 Jul 2003 12:40:48 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 15:40:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEvqCrXuNTy30tQdqlShz3pt9HcQAACGsA From: "Manfredi, Albert E" To: "Lloyd Wood" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 19:40:48.0191 (UTC) FILETIME=[AA3A84F0:01C344BF] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 15:40:47 -0400 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > Manfredi, Albert E wrote: >=20 > > Sorry, but I had exactly the opposite reaction. > > > > Over a broadcast channel, such as satellite, it seems to me, any > > sort of encapsulation is just fine. At the receiving end*s*, the > > receivers can easily reformat the packet to be unicast or multicast, > > to enable the appropriate routing where routing matters. >=20 > what do you mean by 'reformat the packet'? Reincapsulate the frame that was broadcast over the broadcast medium. = That frame can be used by multiple systems, presumably, only one of = which would need to worry about IP routing, multicast or otherwise. > > The broadcast channel's individual streams can be differentiated in > > any number of ways, including the use of Class D addresses > > certainly. But that makes a weak argument for IP Multicast, I think. > > For instance, what's wrong with using PIDs in MPEG-2 Transport > > Stream? Or what about differentiating based only on a LLC/SNAP > > header ID? >=20 > You'd have to indicate that the multicast packet was a multicast > packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down > the layers. My fundamental disagreement with bringing up a broadcast channel is that = the broadcast channel per se couldn't care less. There are no difficult = routing decisions to be made in the satellite or other broadcast link. = The broadcast channel is the equivalent of a single Ethernet link along = the way, in a wired internet. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 15:53:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11885 for ; Mon, 7 Jul 2003 15:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc2m-00006j-IK; Mon, 07 Jul 2003 15:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc2j-00006W-AQ for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:52:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11869 for ; Mon, 7 Jul 2003 15:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zc2h-0001oi-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:52:55 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zc2h-0001oe-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:52:55 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19Zc2W-0007i7-00; Mon, 07 Jul 2003 20:52:44 +0100 Date: Mon, 7 Jul 2003 20:52:43 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19Zc2W-0007i7-00*YV08B5QJBmU* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Manfredi, Albert E wrote: > Lloyd Wood wrote: > > > Manfredi, Albert E wrote: > > > > > Sorry, but I had exactly the opposite reaction. > > > > > > Over a broadcast channel, such as satellite, it seems to me, any > > > sort of encapsulation is just fine. At the receiving end*s*, the > > > receivers can easily reformat the packet to be unicast or multicast, > > > to enable the appropriate routing where routing matters. > > > > what do you mean by 'reformat the packet'? > > Reincapsulate the frame that was broadcast over the broadcast > medium. That frame can be used by multiple systems, presumably, only > one of which would need to worry about IP routing, multicast or > otherwise. interesting way of looking at things. Not sure it's workable. I don't see where IP routing comes in. > > > The broadcast channel's individual streams can be differentiated in > > > any number of ways, including the use of Class D addresses > > > certainly. But that makes a weak argument for IP Multicast, I think. > > > For instance, what's wrong with using PIDs in MPEG-2 Transport > > > Stream? Or what about differentiating based only on a LLC/SNAP > > > header ID? > > > > You'd have to indicate that the multicast packet was a multicast > > packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down > > the layers. > > My fundamental disagreement with bringing up a broadcast channel is > that the broadcast channel per se couldn't care less. the terminals receiving from that channel, however, do care when discriminating. Channels are fundamentally physical, they don't care. A shared link medium is, however, a different beast. > There are no difficult routing decisions to be made in the satellite > or other broadcast link. The broadcast channel is the equivalent of > a single Ethernet link along the way, in a wired internet. Collision management is rather different. As it happens, Ethernet indicates multicast packets in its frame structure via its own multicast address. There's a mapping. (And if you have multiple spotbeams on the satellite, each broadcasting to multiple terminals you have complex packet/frame replication/identification issues.) L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 15:53:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11887 for ; Mon, 7 Jul 2003 15:53:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc2p-00006w-7O for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 15:53:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Jr3kH000425 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 15:53:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc2m-00006j-IK; Mon, 07 Jul 2003 15:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zc2j-00006W-AQ for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:52:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11869 for ; Mon, 7 Jul 2003 15:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zc2h-0001oi-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:52:55 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zc2h-0001oe-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:52:55 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19Zc2W-0007i7-00; Mon, 07 Jul 2003 20:52:44 +0100 Date: Mon, 7 Jul 2003 20:52:43 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19Zc2W-0007i7-00*YV08B5QJBmU* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Manfredi, Albert E wrote: > Lloyd Wood wrote: > > > Manfredi, Albert E wrote: > > > > > Sorry, but I had exactly the opposite reaction. > > > > > > Over a broadcast channel, such as satellite, it seems to me, any > > > sort of encapsulation is just fine. At the receiving end*s*, the > > > receivers can easily reformat the packet to be unicast or multicast, > > > to enable the appropriate routing where routing matters. > > > > what do you mean by 'reformat the packet'? > > Reincapsulate the frame that was broadcast over the broadcast > medium. That frame can be used by multiple systems, presumably, only > one of which would need to worry about IP routing, multicast or > otherwise. interesting way of looking at things. Not sure it's workable. I don't see where IP routing comes in. > > > The broadcast channel's individual streams can be differentiated in > > > any number of ways, including the use of Class D addresses > > > certainly. But that makes a weak argument for IP Multicast, I think. > > > For instance, what's wrong with using PIDs in MPEG-2 Transport > > > Stream? Or what about differentiating based only on a LLC/SNAP > > > header ID? > > > > You'd have to indicate that the multicast packet was a multicast > > packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down > > the layers. > > My fundamental disagreement with bringing up a broadcast channel is > that the broadcast channel per se couldn't care less. the terminals receiving from that channel, however, do care when discriminating. Channels are fundamentally physical, they don't care. A shared link medium is, however, a different beast. > There are no difficult routing decisions to be made in the satellite > or other broadcast link. The broadcast channel is the equivalent of > a single Ethernet link along the way, in a wired internet. Collision management is rather different. As it happens, Ethernet indicates multicast packets in its frame structure via its own multicast address. There's a mapping. (And if you have multiple spotbeams on the satellite, each broadcasting to multiple terminals you have complex packet/frame replication/identification issues.) L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 16:15:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10555 for ; Mon, 7 Jul 2003 15:27:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbdo-0006fF-LI for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 15:27:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67JRCKb025618 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 15:27:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbdg-0006eJ-Sw; Mon, 07 Jul 2003 15:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbcs-0006b2-Om for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:26:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10507 for ; Mon, 7 Jul 2003 15:26:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbcr-0001Oc-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:26:13 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19Zbcq-0001OZ-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:26:12 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA14928; Mon, 7 Jul 2003 12:25:28 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA18064; Mon, 7 Jul 2003 12:26:03 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67JPvj00629; Mon, 7 Jul 2003 12:25:58 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 15:25:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEu8+IeFMVNX3FSkWsmkufdo1kNgAAISGQ From: "Manfredi, Albert E" To: "Bill Nickless" , "Lloyd Wood" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 19:25:08.0812 (UTC) FILETIME=[7A50A8C0:01C344BD] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 15:25:08 -0400 Content-Transfer-Encoding: quoted-printable > At 07:54 PM 7/7/2003 +0100, Lloyd Wood wrote: > >(multicast makes a lot of sense in a satellite broadcast environment, > > where link utilisation matters. If you can resell your > > constrained capacity, multicast increases, not decreases, your > > revenue.) >=20 > Exactly right. I ran into an example of that recently. Sorry, but I had exactly the opposite reaction. Over a broadcast channel, such as satellite, it seems to me, any sort of = encapsulation is just fine. At the receiving end*s*, the receivers can = easily reformat the packet to be unicast or multicast, to enable the = appropriate routing where routing matters. The broadcast channel's individual streams can be differentiated in any = number of ways, including the use of Class D addresses certainly. But = that makes a weak argument for IP Multicast, I think. For instance, = what's wrong with using PIDs in MPEG-2 Transport Stream? Or what about = differentiating based only on a LLC/SNAP header ID? Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 16:22:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13295 for ; Mon, 7 Jul 2003 16:22:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcUr-0002Rl-Ok; Mon, 07 Jul 2003 16:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcU1-0002Py-CT for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13217 for ; Mon, 7 Jul 2003 16:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcTz-0002C3-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:21:07 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 19ZcTy-0002Bt-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:21:06 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA25802; Mon, 7 Jul 2003 15:20:59 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id PAA16825; Mon, 7 Jul 2003 15:20:58 -0500 (CDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67KKv108407; Mon, 7 Jul 2003 15:20:57 -0500 (CDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 16:20:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEwj4M/p/rIGNTT9295V+Gqst6UAAAH8lw From: "Manfredi, Albert E" To: "Lloyd Wood" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 20:20:52.0800 (UTC) FILETIME=[437CBC00:01C344C5] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 16:20:52 -0400 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > Manfredi, Albert E wrote: > > > My fundamental disagreement with bringing up a broadcast channel is > > that the broadcast channel per se couldn't care less. >=20 > the terminals receiving from that channel, however, do care when > discriminating. Channels are fundamentally physical, they don't care. > A shared link medium is, however, a different beast. Okay, maybe we need examples to stay on the same page. Greg Shepherd = mentioned high bit rate streams as a good reason to use IP multicast vs = unicast. So let's take satellite DTV distribution as an example. The head end uplinks DTV program streams to the satellite. They come = back as MPEG streams, identified by a physical channel and a PID within = that channel. So far, NO indication of multicast anything. Just unique = IDs for each bitstream, so they can be differentiated at the receiving = ends. Now this signal can be immediately decoded and used by a satellite = receiver, or it can be encapsulated in IP Multicast packet, then in an = Ethernet frame, for distribution over a wired internet of some kind. The = broadcast link does not make for an interesting "must have" for IP = multicast, in this TV example. Okay, forget TV. If the satellite link is a more intrinsic part of this = internet, i.e. a leg in an otherwise routed IP network, then use of IP = multicast in this particular leg of the network is not really any more = or less compelling than transmitting IP multicast packets over a wired = link. Could be Ethernet, could be a wave-divided optical link, could be = a SONET STS frame, could be a T3 or T1 phone link. I think that to make IP multicast compelling, ISPs have to be convinced = that it's to their advantage. One important piece MIGHT be to come up = with a scheme that can accurately count group membership. IGMP does NOT = provide such a technique as of now. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 16:22:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13310 for ; Mon, 7 Jul 2003 16:22:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcV3-0002Wg-Q5 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 16:22:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67KMD9x009704 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 16:22:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcUr-0002Rl-Ok; Mon, 07 Jul 2003 16:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcU1-0002Py-CT for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13217 for ; Mon, 7 Jul 2003 16:21:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZcTz-0002C3-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:21:07 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx with esmtp (Exim 4.12) id 19ZcTy-0002Bt-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:21:06 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id PAA25802; Mon, 7 Jul 2003 15:20:59 -0500 (CDT) Received: from stl-hub-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id PAA16825; Mon, 7 Jul 2003 15:20:58 -0500 (CDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by stl-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67KKv108407; Mon, 7 Jul 2003 15:20:57 -0500 (CDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 16:20:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEwj4M/p/rIGNTT9295V+Gqst6UAAAH8lw From: "Manfredi, Albert E" To: "Lloyd Wood" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 20:20:52.0800 (UTC) FILETIME=[437CBC00:01C344C5] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 16:20:52 -0400 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > Manfredi, Albert E wrote: > > > My fundamental disagreement with bringing up a broadcast channel is > > that the broadcast channel per se couldn't care less. >=20 > the terminals receiving from that channel, however, do care when > discriminating. Channels are fundamentally physical, they don't care. > A shared link medium is, however, a different beast. Okay, maybe we need examples to stay on the same page. Greg Shepherd = mentioned high bit rate streams as a good reason to use IP multicast vs = unicast. So let's take satellite DTV distribution as an example. The head end uplinks DTV program streams to the satellite. They come = back as MPEG streams, identified by a physical channel and a PID within = that channel. So far, NO indication of multicast anything. Just unique = IDs for each bitstream, so they can be differentiated at the receiving = ends. Now this signal can be immediately decoded and used by a satellite = receiver, or it can be encapsulated in IP Multicast packet, then in an = Ethernet frame, for distribution over a wired internet of some kind. The = broadcast link does not make for an interesting "must have" for IP = multicast, in this TV example. Okay, forget TV. If the satellite link is a more intrinsic part of this = internet, i.e. a leg in an otherwise routed IP network, then use of IP = multicast in this particular leg of the network is not really any more = or less compelling than transmitting IP multicast packets over a wired = link. Could be Ethernet, could be a wave-divided optical link, could be = a SONET STS frame, could be a T3 or T1 phone link. I think that to make IP multicast compelling, ISPs have to be convinced = that it's to their advantage. One important piece MIGHT be to come up = with a scheme that can accurately count group membership. IGMP does NOT = provide such a technique as of now. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 16:30:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11272 for ; Mon, 7 Jul 2003 15:42:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbs9-0007dS-VP; Mon, 07 Jul 2003 15:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zbr9-0007cs-Sx for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 15:40:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11142 for ; Mon, 7 Jul 2003 15:40:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zbr8-0001aP-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:40:58 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx with esmtp (Exim 4.12) id 19Zbr7-0001aM-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 15:40:57 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA12100; Mon, 7 Jul 2003 12:40:54 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA02823; Mon, 7 Jul 2003 12:40:53 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h67Jelj00152; Mon, 7 Jul 2003 12:40:48 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 7 Jul 2003 15:40:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNEvqCrXuNTy30tQdqlShz3pt9HcQAACGsA From: "Manfredi, Albert E" To: "Lloyd Wood" Cc: "routing-discussion" , "wg-multicast" , "mboned" X-OriginalArrivalTime: 07 Jul 2003 19:40:48.0191 (UTC) FILETIME=[AA3A84F0:01C344BF] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 15:40:47 -0400 Content-Transfer-Encoding: quoted-printable Lloyd Wood wrote: > Manfredi, Albert E wrote: >=20 > > Sorry, but I had exactly the opposite reaction. > > > > Over a broadcast channel, such as satellite, it seems to me, any > > sort of encapsulation is just fine. At the receiving end*s*, the > > receivers can easily reformat the packet to be unicast or multicast, > > to enable the appropriate routing where routing matters. >=20 > what do you mean by 'reformat the packet'? Reincapsulate the frame that was broadcast over the broadcast medium. = That frame can be used by multiple systems, presumably, only one of = which would need to worry about IP routing, multicast or otherwise. > > The broadcast channel's individual streams can be differentiated in > > any number of ways, including the use of Class D addresses > > certainly. But that makes a weak argument for IP Multicast, I think. > > For instance, what's wrong with using PIDs in MPEG-2 Transport > > Stream? Or what about differentiating based only on a LLC/SNAP > > header ID? >=20 > You'd have to indicate that the multicast packet was a multicast > packet via PID or LLC/SNAP _as well_ - tightly coupling semantics down > the layers. My fundamental disagreement with bringing up a broadcast channel is that = the broadcast channel per se couldn't care less. There are no difficult = routing decisions to be made in the satellite or other broadcast link. = The broadcast channel is the equivalent of a single Ethernet link along = the way, in a wired internet. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 16:44:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14399 for ; Mon, 7 Jul 2003 16:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcq9-00047y-Kw; Mon, 07 Jul 2003 16:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcpo-00045x-9p for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:43:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14376 for ; Mon, 7 Jul 2003 16:43:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zcpm-0002Uf-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:43:38 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19Zcpl-0002UJ-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:43:37 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9C61D34441; Mon, 7 Jul 2003 14:00:15 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h67Kh7YB028808; Mon, 7 Jul 2003 13:43:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: decison process in routing protocols Message-ID: Thread-Topic: decison process in routing protocols Thread-Index: AcNEuHYMHZJBI06JSXG5Rp429sqBWAAD9gLQ From: "Tony Li" To: "Alok Dube" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 13:43:07 -0700 Content-Transfer-Encoding: quoted-printable They have to make the exact SAME decisions that the process would make if it was running locally. Tony | -----Original Message----- | From: Alok Dube [mailto:alok.dube@apara.com]=20 | Sent: Monday, July 07, 2003 11:51 AM | To: routing-discussion@ietf.org | Subject: Re: decison process in routing protocols | =20 | =20 | > In the past there is some work in IP distributed routing | > called "open router". Where multiple forwarding planes are | > controlled by one are many control plane decision processes. | > SS7 also does a kind of distributed out-of-band decisions. | =20 | Hi, | =20 | do these compute the "decison process for the best route" from the | "forwarding plane's" perspective? | =20 | -thanks | Alok | =20 | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 16:54:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14843 for ; Mon, 7 Jul 2003 16:54:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zczo-0004h6-SO; Mon, 07 Jul 2003 16:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zczg-0004gp-8F for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:53:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14829 for ; Mon, 7 Jul 2003 16:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zczd-0002cX-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:53:49 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zczc-0002cC-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:53:49 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19ZczS-0001cD-00; Mon, 07 Jul 2003 21:53:38 +0100 Date: Mon, 7 Jul 2003 21:53:37 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19ZczS-0001cD-00*aAAoCLt2HVo* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Manfredi, Albert E wrote: > I think that to make IP multicast compelling, ISPs have to be > convinced that it's to their advantage. One important piece MIGHT be > to come up with a scheme that can accurately count group membership. > IGMP does NOT provide such a technique as of now. This is why I like core-based trees; I had core-based trees counting group members in my PhD thesis. (Since a core has upstream state, I don't view it as IGMP snooping; more proxying/aggregation). L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 16:54:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14845 for ; Mon, 7 Jul 2003 16:54:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zczr-0004hf-S4 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 16:54:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Ks3Qw018055 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 16:54:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zczo-0004h6-SO; Mon, 07 Jul 2003 16:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zczg-0004gp-8F for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:53:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14829 for ; Mon, 7 Jul 2003 16:53:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zczd-0002cX-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:53:49 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19Zczc-0002cC-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:53:49 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19ZczS-0001cD-00; Mon, 07 Jul 2003 21:53:38 +0100 Date: Mon, 7 Jul 2003 21:53:37 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: "Manfredi, Albert E" cc: routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.7 required=5.5 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_PINE, USER_IN_WHITELIST autolearn=ham version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19ZczS-0001cD-00*aAAoCLt2HVo* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Mon, 7 Jul 2003, Manfredi, Albert E wrote: > I think that to make IP multicast compelling, ISPs have to be > convinced that it's to their advantage. One important piece MIGHT be > to come up with a scheme that can accurately count group membership. > IGMP does NOT provide such a technique as of now. This is why I like core-based trees; I had core-based trees counting group members in my PhD thesis. (Since a core has upstream state, I don't view it as IGMP snooping; more proxying/aggregation). L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 16:58:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15058 for ; Mon, 7 Jul 2003 16:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd3h-0005DH-Fx; Mon, 07 Jul 2003 16:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd3L-00059r-Nd for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:57:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15035 for ; Mon, 7 Jul 2003 16:57:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zd3J-0002g1-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:57:37 -0400 Received: from garlic.amaranth.net ([208.254.46.17]) by ietf-mx with esmtp (Exim 4.12) id 19Zd3I-0002fp-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:57:36 -0400 Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.7/8.11.7) with ESMTP id h67KvXO10604 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Mon, 7 Jul 2003 16:57:34 -0400 Message-Id: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: "routing-discussion" From: Daniel Senie Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Cc: "wg-multicast" , "mboned" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 16:57:22 -0400 At 04:20 PM 7/7/2003, Manfredi, Albert E wrote: >I think that to make IP multicast compelling, ISPs have to be convinced >that it's to their advantage. That's called CUSTOMER DEMAND. Where's the killer app? > One important piece MIGHT be to come up with a scheme that can > accurately count group membership. IGMP does NOT provide such a technique > as of now. ISPs will still not care about it, even if you have provided better accounting, unless there's a demand. IP Multicast requires additional skills and equipment to deploy, debug and maintain. In the absence of applications, there's no market. The "chicken and egg" issue is the need to have SOME valid, required use, and a compelling reason for deployment. To date, that has just not existed. In reality, there are a handful of actual ISPs you'd need to convince in the USA marketplace for Multicast to work. If this technology is to be used on the public networks, then Comcast, Charter, Time Warner, Verizon, SBC and a handful of others would need to get it working on their broadband networks. Get them, and the rest will follow. Multicast to the last mile only makes sense to, say Comcast, if there's a good chance of having more than one in 100 people watching in a neighborhood (the point at which multicast might save them some traffic to distribution nodes). Multicast certainly has proven useful in private networks. In public use, I don't see any significant change in the availability to consumers in the last 7 years. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 16:58:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15062 for ; Mon, 7 Jul 2003 16:58:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd3k-0005EP-9J for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 16:58:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Kw4ef020101 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 16:58:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd3h-0005DH-Fx; Mon, 07 Jul 2003 16:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zd3L-00059r-Nd for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:57:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15035 for ; Mon, 7 Jul 2003 16:57:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zd3J-0002g1-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:57:37 -0400 Received: from garlic.amaranth.net ([208.254.46.17]) by ietf-mx with esmtp (Exim 4.12) id 19Zd3I-0002fp-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:57:36 -0400 Received: from Willow.senie.com (amaranth.ne.client2.attbi.com [24.34.18.226]) (authenticated (0 bits)) by garlic.amaranth.net (8.11.7/8.11.7) with ESMTP id h67KvXO10604 (using TLSv1/SSLv3 with cipher RC4-SHA (128 bits) verified NO); Mon, 7 Jul 2003 16:57:34 -0400 Message-Id: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> X-Sender: dts@mail.amaranth.net X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: "routing-discussion" From: Daniel Senie Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Cc: "wg-multicast" , "mboned" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 16:57:22 -0400 At 04:20 PM 7/7/2003, Manfredi, Albert E wrote: >I think that to make IP multicast compelling, ISPs have to be convinced >that it's to their advantage. That's called CUSTOMER DEMAND. Where's the killer app? > One important piece MIGHT be to come up with a scheme that can > accurately count group membership. IGMP does NOT provide such a technique > as of now. ISPs will still not care about it, even if you have provided better accounting, unless there's a demand. IP Multicast requires additional skills and equipment to deploy, debug and maintain. In the absence of applications, there's no market. The "chicken and egg" issue is the need to have SOME valid, required use, and a compelling reason for deployment. To date, that has just not existed. In reality, there are a handful of actual ISPs you'd need to convince in the USA marketplace for Multicast to work. If this technology is to be used on the public networks, then Comcast, Charter, Time Warner, Verizon, SBC and a handful of others would need to get it working on their broadband networks. Get them, and the rest will follow. Multicast to the last mile only makes sense to, say Comcast, if there's a good chance of having more than one in 100 people watching in a neighborhood (the point at which multicast might save them some traffic to distribution nodes). Multicast certainly has proven useful in private networks. In public use, I don't see any significant change in the availability to consumers in the last 7 years. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 17:06:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15606 for ; Mon, 7 Jul 2003 17:06:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdBS-0005iP-B3; Mon, 07 Jul 2003 17:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdAn-0005hO-C2 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:05:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15534 for ; Mon, 7 Jul 2003 17:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZdAl-0002pL-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:05:19 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ZdAk-0002pG-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:05:18 -0400 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19ZdAj-000LUp-G7; Mon, 07 Jul 2003 21:05:17 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ZGhw-00044E-Q4; Sun, 06 Jul 2003 23:06:04 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Senie Cc: "routing-discussion" , "wg-multicast" , "mboned" Subject: RE: BOF Agenda - Multicast Last-Mile Solutions References: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 6 Jul 2003 23:06:04 +0200 Content-Transfer-Encoding: 7bit there is more traffic about multicast than actual wan multicast. there is massively more intranet multicast use than internet. the reasons are that there is money in the latter and none in the former. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 17:06:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15608 for ; Mon, 7 Jul 2003 17:06:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdBX-0005ju-Oz for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 17:06:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67L67D9022039 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 17:06:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdBS-0005iP-B3; Mon, 07 Jul 2003 17:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdAn-0005hO-C2 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:05:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15534 for ; Mon, 7 Jul 2003 17:05:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZdAl-0002pL-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:05:19 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ZdAk-0002pG-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:05:18 -0400 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19ZdAj-000LUp-G7; Mon, 07 Jul 2003 21:05:17 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ZGhw-00044E-Q4; Sun, 06 Jul 2003 23:06:04 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Daniel Senie Cc: "routing-discussion" , "wg-multicast" , "mboned" Subject: RE: BOF Agenda - Multicast Last-Mile Solutions References: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 6 Jul 2003 23:06:04 +0200 Content-Transfer-Encoding: 7bit there is more traffic about multicast than actual wan multicast. there is massively more intranet multicast use than internet. the reasons are that there is money in the latter and none in the former. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 17:10:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15992 for ; Mon, 7 Jul 2003 17:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdFJ-0006Cz-SU; Mon, 07 Jul 2003 17:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdEy-0006Ar-0A for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:09:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15905 for ; Mon, 7 Jul 2003 17:09:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZdEv-0002vc-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:09:37 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19ZdEv-0002vV-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:09:37 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19ZdEf-00023C-00; Mon, 07 Jul 2003 22:09:21 +0100 Date: Mon, 7 Jul 2003 22:09:19 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Randy Bush cc: Daniel Senie , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.5 required=5.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19ZdEf-00023C-00*Tja32FdMwS6* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Sun, 6 Jul 2003, Randy Bush wrote: > there is more traffic about multicast than actual wan multicast. > there is massively more intranet multicast use than internet. the > reasons are that there is money in the latter and none in the > former. okay, there's no money in multicast. there's no money in p2p filesharing apps. do any p2p filesharing apps try and use multicast? L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 17:13:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16304 for ; Mon, 7 Jul 2003 17:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdIF-0006hl-0k; Mon, 07 Jul 2003 17:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdHx-0006gJ-F3 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:12:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16219 for ; Mon, 7 Jul 2003 17:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZdHv-0002zy-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:12:43 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ZdHu-0002zv-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:12:42 -0400 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19ZdHs-000Lni-KZ; Mon, 07 Jul 2003 21:12:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ZGp6-000457-7J; Sun, 06 Jul 2003 23:13:28 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Lloyd Wood Cc: Daniel Senie , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions References: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 6 Jul 2003 23:13:27 +0200 Content-Transfer-Encoding: 7bit > there's no money in p2p filesharing apps. two differences o p2p file sharing requires nothing in core o there is money in it for the end users i.e. the benefit lies where the cost lies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 17:13:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16308 for ; Mon, 7 Jul 2003 17:13:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdIH-0006jX-LK for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 17:13:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67LD5hk025859 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 17:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdIF-0006hl-0k; Mon, 07 Jul 2003 17:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdHx-0006gJ-F3 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:12:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16219 for ; Mon, 7 Jul 2003 17:12:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZdHv-0002zy-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:12:43 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ZdHu-0002zv-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:12:42 -0400 Received: from [127.0.0.1] (helo=roam.psg.com ident=root) by psg.com with esmtp (Exim 4.14) id 19ZdHs-000Lni-KZ; Mon, 07 Jul 2003 21:12:40 +0000 Received: from localhost ([127.0.0.1] helo=roam.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.20) id 19ZGp6-000457-7J; Sun, 06 Jul 2003 23:13:28 +0200 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Lloyd Wood Cc: Daniel Senie , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions References: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 6 Jul 2003 23:13:27 +0200 Content-Transfer-Encoding: 7bit > there's no money in p2p filesharing apps. two differences o p2p file sharing requires nothing in core o there is money in it for the end users i.e. the benefit lies where the cost lies _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 17:30:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14401 for ; Mon, 7 Jul 2003 16:44:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZcqD-00049K-K9 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 16:44:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67Ki5Di015927 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 16:44:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcq9-00047y-Kw; Mon, 07 Jul 2003 16:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zcpo-00045x-9p for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 16:43:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14376 for ; Mon, 7 Jul 2003 16:43:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zcpm-0002Uf-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:43:38 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19Zcpl-0002UJ-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 16:43:37 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 9C61D34441; Mon, 7 Jul 2003 14:00:15 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h67Kh7YB028808; Mon, 7 Jul 2003 13:43:07 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: decison process in routing protocols Message-ID: Thread-Topic: decison process in routing protocols Thread-Index: AcNEuHYMHZJBI06JSXG5Rp429sqBWAAD9gLQ From: "Tony Li" To: "Alok Dube" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 13:43:07 -0700 Content-Transfer-Encoding: quoted-printable They have to make the exact SAME decisions that the process would make if it was running locally. Tony | -----Original Message----- | From: Alok Dube [mailto:alok.dube@apara.com]=20 | Sent: Monday, July 07, 2003 11:51 AM | To: routing-discussion@ietf.org | Subject: Re: decison process in routing protocols | =20 | =20 | > In the past there is some work in IP distributed routing | > called "open router". Where multiple forwarding planes are | > controlled by one are many control plane decision processes. | > SS7 also does a kind of distributed out-of-band decisions. | =20 | Hi, | =20 | do these compute the "decison process for the best route" from the | "forwarding plane's" perspective? | =20 | -thanks | Alok | =20 | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 17:56:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17892 for ; Mon, 7 Jul 2003 17:56:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdy0-0000ei-7M for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 17:56:12 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67LuCjd002520 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 17:56:12 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdxp-0000dR-BZ; Mon, 07 Jul 2003 17:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdx0-0000bo-82 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17823 for ; Mon, 7 Jul 2003 17:55:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zdwx-0003SN-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:55:07 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19Zdww-0003Rj-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:55:06 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h67LsZt184212; Mon, 7 Jul 2003 16:54:35 -0500 Message-Id: <5.2.0.9.2.20030707163604.0344d9a0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "Manfredi, Albert E" From: Bill Nickless Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Cc: "routing-discussion" , "wg-multicast" , "mboned" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 16:54:28 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 04:20 PM 7/7/2003 -0400, Manfredi, Albert E wrote: >I think that to make IP multicast compelling, ISPs have to be convinced >that it's to their advantage. One important piece MIGHT be to come up with >a scheme that can accurately count group membership. IGMP does NOT provide >such a technique as of now. In the context of RFC 966, that's an excellent criticism. Recall that the work described in RFC 966 was originally designed/implemented to support the V distributed system on a Metcalfe Ethernet. Quoting: On a philosophical point, there has been considerable reluctance to make open use of multicast on local networks because it was network-specific and not provided across the Internet. We were originally of that school. However, we recognized that our "hidden" uses of multicast in the V distributed system were essential unless we resorted to dramatically poorer solutions - wired-in addresses. We also recognized, as described in this paper, that an adequate multicast facility for the Internet was feasible. As a consequence, we now argue that multicast is an important and basic facility to provide in local networks and internetworks. In the context of a Metcalfe Ethernet supporting a distributed system, group membership operations can be entirely contained in the host. Each host merely discards data on the shared bus that is not addressed to them, or the Host Group addresses for which they have no interested processes. In the context of multicast flooding between Metcalfe Ethernets, the requirement is to discover where there is zero vs. one (or more) Host Group Members on the subnet. IGMPv1/2 were designed to meet this requirement. In the context of today's IEEE 802 networks, with full-duplex links supporting a single host on each IEEE 802.1 bridge port, additional group membership information is required. IGMP snooping/spoofing attempts to discover the set of IEEE 802.1 bridged segments with interested receiver(s). My position on IGMP snooping/spoofing is probably clear to all. :-) But to address your point, I agree that we should look at more sophisticated group management techniques--at the link layer and the internetwork layer. At the risk of repeating myself, the IP over Infiniband and IP over IEEE 1394 (Firewire) specifications do a much better job of multicast group membership management than is commonly done on IEEE 802 networks today. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwnsGKwgm7ipJDXBAQFb3AP/W3i1SMaX+DC17qPYwlR45nvgGXe6kTs6 zAHtMdUika8Sav/Q/AXPpdnIPR+w33QULGn7f3rP8CfmeYxTHAcHxZxCc/SepMWu BftaMEpVhtDokAEdsU9w2saz52FlW5+I9h6/eLTluGglU7ELbSeW4ZSGuJWMJUcQ wQx4HfySbe8= =nwRW -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 7 18:00:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15991 for ; Mon, 7 Jul 2003 17:10:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdFM-0006Dh-D6 for routing-discussion-archive@odin.ietf.org; Mon, 07 Jul 2003 17:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h67LA4AH023890 for routing-discussion-archive@odin.ietf.org; Mon, 7 Jul 2003 17:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdFJ-0006Cz-SU; Mon, 07 Jul 2003 17:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZdEy-0006Ar-0A for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:09:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15905 for ; Mon, 7 Jul 2003 17:09:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZdEv-0002vc-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:09:37 -0400 Received: from prue.eim.surrey.ac.uk ([131.227.76.5] ident=exim) by ietf-mx with esmtp (Exim 4.12) id 19ZdEv-0002vV-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:09:37 -0400 Received: from artemis.ee.surrey.ac.uk ([131.227.88.18] ident=eep1lw) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 19ZdEf-00023C-00; Mon, 07 Jul 2003 22:09:21 +0100 Date: Mon, 7 Jul 2003 22:09:19 +0100 (BST) From: Lloyd Wood X-X-Sender: eep1lw@artemis.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Randy Bush cc: Daniel Senie , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: References: <5.2.1.1.2.20030707164713.02b514b8@mail.amaranth.net> Organization: speaking for none X-url: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-106.5 required=5.5 tests=BAYES_00,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES,USER_AGENT_PINE,USER_IN_WHITELIST version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *19ZdEf-00023C-00*Tja32FdMwS6* (SECM, UniS) Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: On Sun, 6 Jul 2003, Randy Bush wrote: > there is more traffic about multicast than actual wan multicast. > there is massively more intranet multicast use than internet. the > reasons are that there is money in the latter and none in the > former. okay, there's no money in multicast. there's no money in p2p filesharing apps. do any p2p filesharing apps try and use multicast? L. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 7 18:45:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17889 for ; Mon, 7 Jul 2003 17:56:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdxp-0000dR-BZ; Mon, 07 Jul 2003 17:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zdx0-0000bo-82 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 17:55:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17823 for ; Mon, 7 Jul 2003 17:55:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zdwx-0003SN-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:55:07 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19Zdww-0003Rj-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 17:55:06 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h67LsZt184212; Mon, 7 Jul 2003 16:54:35 -0500 Message-Id: <5.2.0.9.2.20030707163604.0344d9a0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: "Manfredi, Albert E" From: Bill Nickless Subject: RE: BOF Agenda - Multicast Last-Mile Solutions Cc: "routing-discussion" , "wg-multicast" , "mboned" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 16:54:28 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 04:20 PM 7/7/2003 -0400, Manfredi, Albert E wrote: >I think that to make IP multicast compelling, ISPs have to be convinced >that it's to their advantage. One important piece MIGHT be to come up with >a scheme that can accurately count group membership. IGMP does NOT provide >such a technique as of now. In the context of RFC 966, that's an excellent criticism. Recall that the work described in RFC 966 was originally designed/implemented to support the V distributed system on a Metcalfe Ethernet. Quoting: On a philosophical point, there has been considerable reluctance to make open use of multicast on local networks because it was network-specific and not provided across the Internet. We were originally of that school. However, we recognized that our "hidden" uses of multicast in the V distributed system were essential unless we resorted to dramatically poorer solutions - wired-in addresses. We also recognized, as described in this paper, that an adequate multicast facility for the Internet was feasible. As a consequence, we now argue that multicast is an important and basic facility to provide in local networks and internetworks. In the context of a Metcalfe Ethernet supporting a distributed system, group membership operations can be entirely contained in the host. Each host merely discards data on the shared bus that is not addressed to them, or the Host Group addresses for which they have no interested processes. In the context of multicast flooding between Metcalfe Ethernets, the requirement is to discover where there is zero vs. one (or more) Host Group Members on the subnet. IGMPv1/2 were designed to meet this requirement. In the context of today's IEEE 802 networks, with full-duplex links supporting a single host on each IEEE 802.1 bridge port, additional group membership information is required. IGMP snooping/spoofing attempts to discover the set of IEEE 802.1 bridged segments with interested receiver(s). My position on IGMP snooping/spoofing is probably clear to all. :-) But to address your point, I agree that we should look at more sophisticated group management techniques--at the link layer and the internetwork layer. At the risk of repeating myself, the IP over Infiniband and IP over IEEE 1394 (Firewire) specifications do a much better job of multicast group membership management than is commonly done on IEEE 802 networks today. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwnsGKwgm7ipJDXBAQFb3AP/W3i1SMaX+DC17qPYwlR45nvgGXe6kTs6 zAHtMdUika8Sav/Q/AXPpdnIPR+w33QULGn7f3rP8CfmeYxTHAcHxZxCc/SepMWu BftaMEpVhtDokAEdsU9w2saz52FlW5+I9h6/eLTluGglU7ELbSeW4ZSGuJWMJUcQ wQx4HfySbe8= =nwRW -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 01:47:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27791 for ; Tue, 8 Jul 2003 01:47:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJg-0002bR-5F; Tue, 08 Jul 2003 01:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZ2h-0004Bi-Fn for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 12:40:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02557 for ; Mon, 7 Jul 2003 12:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZ2f-0006Q0-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:40:42 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZZ2f-0006Pb-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:40:41 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h67GeNUI025355; Mon, 7 Jul 2003 09:40:23 -0700 From: David Meyer To: Greg Shepherd Cc: shep@shepfarm.com, Jon Crowcroft , "Manfredi, Albert E" , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Message-ID: <20030707094023.A25302@1-4-5.net> References: <20030707092419.A25060@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@procket.com on Mon, Jul 07, 2003 at 09:35:46AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 09:40:23 -0700 >> > could/would/should/...As we all know, this whole >> > discussion is 10+ years old. I really don't see anything >> > new here. >> >> Good point! ...and that is the problem. So I guess you're saying that we >> need something new? What I meant is what I said. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 01:47:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27795 for ; Tue, 8 Jul 2003 01:47:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJh-0002fr-G2; Tue, 08 Jul 2003 01:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlF1-0002XX-Q5 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 01:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27700 for ; Tue, 8 Jul 2003 01:42:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZlEy-0006RD-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 01:42:12 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[iLvOUQ8sfbglsVVpp13ef2amUY6pR5U3]) by ietf-mx with esmtp (Exim 4.12) id 19ZlEx-0006RA-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 01:42:11 -0400 Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19ZlEv-0006yH-00; Tue, 08 Jul 2003 06:42:09 +0100 To: Lloyd Wood cc: Randy Bush , Daniel Senie , routing-discussion , wg-multicast , mboned , Jon.Crowcroft@cl.cam.ac.uk Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message from Lloyd Wood of "Mon, 07 Jul 2003 22:09:19 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31087.1057642927.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 06:42:07 +0100 there is a large body of end system multicast work based on p2p infrastructures despite some provider ideas of what customers want... that said, core, transit and edge ip level multicast are mostly irrel. to the p2p group comms use...the problem is not usually sender capacity efficiency, or even concurrent reception...its more just a tool for the job see scribe, esm, splitstream and CAN based cast papers (and s/w) while i am all for money, i wish it would stop dominating engineering discussions...build it well, and they will come... In missive , Lloyd Wood typed: >>On Sun, 6 Jul 2003, Randy Bush wrote: >> >>> there is more traffic about multicast than actual wan multicast. >>> there is massively more intranet multicast use than internet. the >>> reasons are that there is money in the latter and none in the >>> former. >> >>okay, there's no money in multicast. >>there's no money in p2p filesharing apps. >>do any p2p filesharing apps try and use multicast? >> >>L. >> >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 01:47:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27834 for ; Tue, 8 Jul 2003 01:47:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJq-0002jR-2I for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 01:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h685lDgE010352 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 01:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJe-0002av-4D; Tue, 08 Jul 2003 01:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRSS-0005ip-C0 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 04:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17339 for ; Mon, 7 Jul 2003 04:34:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRSP-00026Q-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 04:34:45 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[HninhkT0M7nsf3GXLY59qLiELji9Z2XH]) by ietf-mx with esmtp (Exim 4.12) id 19ZRSO-00026K-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 04:34:44 -0400 Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19ZRSG-0004ex-00; Mon, 07 Jul 2003 09:34:36 +0100 To: "Manfredi, Albert E" cc: Greg Shepherd , routing-discussion , wg-multicast , mboned , Jon.Crowcroft@cl.cam.ac.uk Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message from "Manfredi, Albert E" of "Sun, 06 Jul 2003 17:20:39 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10928.1057566875.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 09:34:35 +0100 since practically no access ISPs allow multicast, how do they know it reduces revenue? this is a typical armchair economist argument obviously if all the users using simultaneous unicast switched to multicast this MIGHT be true, but the real point is that it enables new sources, applications and services, and might therefore INCREASE revenue....noone can say for sure... i think the technical obstacles (cable tv modem head end, DSLAM, and other minimal support for igmp magic, security, charging for group size and other stuff are the critical points and think this BOG Is an althogether Most Exellent Idea In missive , "Manfredi, Albert E" typed: >>Interesting subject. From what I'm told, one of the big obstacles in = >>enabling multicast all the way through is that use of multicast reduces = >>the revenues ISPs can expect for providing network services? That's a = >>plausible reason. Are there others? Security? >> >>Bert >> >> >>> -----Original Message----- >>> From: Greg Shepherd [mailto:shep@procket.com] >>> Sent: Wednesday, July 02, 2003 7:23 PM >>> To: agenda@ietf.org; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; >>> magma@innovationslab.net; routing-discussion@ietf.org; >>> wg-multicast@internet2.edu; mboned@network-services.uoregon.edu >>> Cc: Alex Zinin; Bill Fenner; Keyur Patel; Greg Shepherd >>> Subject: BOF Agenda - Multicast Last-Mile Solutions >>>=20 >>>=20 >>>=20 >>> Multicast Last-Mile Solutions BOF >>>=20 >>> DESCRIPTION: >>>=20 >>> Successful content distribution business plans have been=20 >>> hampered by the >>> all-or-nothing nature of a multicast routed infrastructure.=20 >>> Several drafts >>> have arisen over the past few years to address the last-mile multicast >>> deployment gap, but have all lost momentum for various reasons. Recent >>> efforts on yet another draft have revealed the need to have=20 >>> all affected >>> parties participate in the effort in order to provide a=20 >>> comprehensive yet >>> simple and deployable solution. >>>=20 >>> A content owner which wishes to build a buisness model around=20 >>> multicast >>> distribution is hampered by the current limited scope of multicast >>> deployment. Their only option today is to purchase multicast transit >>> services from their provider of choice which does not ensure the path >>> between their content and their customers is multicast enabled. The >>> administrative control of the multicast topology in this=20 >>> relationship is >>> restricted to the provider and the content customer. The=20 >>> missing step on >>> the path to full multicast deployment will require a solution which >>> allows the content owner the benefits of multicast replication, >>> independent of the radius of the multicast deployment. >>>=20 >>> The purpose of this BOF is to bring together operators, content >>> providers/owners, application and protocol implementors to discuss the >>> problem and worked towards a mutually desired solution. The expected >>> outcome will be an evaluation of interest, a better defined problem >>> statement, directions for any future progress from the BOF >>> participants. >>>=20 >>> AGENDA: >>>=20 >>> 1. Agenda Bashing (all) >>> 2. Problem description (shep - 10min) >>> 3. Discussion of current gaps and future direction (from the floor) >>>=20 >>> WEB REFERNCE: >>> http://www.shepfarm.com/multicast/last-mile >>>=20 >>> RELEVANT PAST WORK: (this list is possibly incomplete - please send >>> updates) >>> http://www.shepfarm.com/multicast/upim/draft-ietf-mboned-auto- >>multicast-01.txt >>http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneli= >>ng-00.txt >>http://www.shepfarm.com/multicast/upim/draft-finlayson-umtp-07.txt >>http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00= >>.txt >>http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.tx= >>t >> >>MAILLIST: >>http://www.shepfarm.com/mailman/listinfo/mtp >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 01:47:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27908 for ; Tue, 8 Jul 2003 01:47:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJq-0002jJ-29 for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 01:47:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h685lDrX010354 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 01:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJh-0002fr-G2; Tue, 08 Jul 2003 01:47:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlF1-0002XX-Q5 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 01:42:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27700 for ; Tue, 8 Jul 2003 01:42:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZlEy-0006RD-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 01:42:12 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[iLvOUQ8sfbglsVVpp13ef2amUY6pR5U3]) by ietf-mx with esmtp (Exim 4.12) id 19ZlEx-0006RA-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 01:42:11 -0400 Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19ZlEv-0006yH-00; Tue, 08 Jul 2003 06:42:09 +0100 To: Lloyd Wood cc: Randy Bush , Daniel Senie , routing-discussion , wg-multicast , mboned , Jon.Crowcroft@cl.cam.ac.uk Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message from Lloyd Wood of "Mon, 07 Jul 2003 22:09:19 BST." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31087.1057642927.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 06:42:07 +0100 there is a large body of end system multicast work based on p2p infrastructures despite some provider ideas of what customers want... that said, core, transit and edge ip level multicast are mostly irrel. to the p2p group comms use...the problem is not usually sender capacity efficiency, or even concurrent reception...its more just a tool for the job see scribe, esm, splitstream and CAN based cast papers (and s/w) while i am all for money, i wish it would stop dominating engineering discussions...build it well, and they will come... In missive , Lloyd Wood typed: >>On Sun, 6 Jul 2003, Randy Bush wrote: >> >>> there is more traffic about multicast than actual wan multicast. >>> there is massively more intranet multicast use than internet. the >>> reasons are that there is money in the latter and none in the >>> former. >> >>okay, there's no money in multicast. >>there's no money in p2p filesharing apps. >>do any p2p filesharing apps try and use multicast? >> >>L. >> >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 01:47:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27923 for ; Tue, 8 Jul 2003 01:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJg-0002f2-U0; Tue, 08 Jul 2003 01:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zaxw-0004HQ-8f for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07324 for ; Mon, 7 Jul 2003 14:43:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zaxt-0000dU-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:43:53 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19Zaxs-0000cm-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:43:52 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h67Igrt138790; Mon, 7 Jul 2003 13:42:53 -0500 Message-Id: <5.2.0.9.2.20030707125826.0220d828@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Greg Shepherd From: Bill Nickless Subject: Re: [Mtp] Re: BOF Agenda - Multicast Last-Mile Solutions Cc: mboned , wg-multicast , routing-discussion , mtp@shepfarm.com In-Reply-To: References: <20030707092419.A25060@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 13:42:47 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 09:35 AM 7/7/2003 -0700, Greg Shepherd wrote: >As I stated in the BOF overview, I would just like to describe the problem >collectively. We can then turn to if/how it can be solved - either by >putting together existing pieces or creating some missing piece. But we >have to start by agreeing on the problem, AND agreeing on what a solution >should achieve. I won't be able to make it to Vienna. Y'all had better take good notes! At the risk of repeating myself, here's my take on it. (Focusing on IPv4, without loss of generality to IPv6): RFC 966 answered that question almost 20 years ago: Multicast has two primary uses, namely distributed binding and multi-destination delivery. As a binding mechanism, multicast is a robust and often more efficient alternative to the use of name servers for finding a particular object or service when a particular host address is not known. For example, in a distributed file system, all the file servers may be associated with one well-known multicast address. To bind a file name to a particular server, a client sends a query packet containing the file name to the file server multicast address, for delivery to all the file servers. The server that recognizes the file name then responds to the client, allowing subsequent interaction directly with that server host. Even when name servers are employed, multicast can be used as the first step in the binding process, that is, finding a name server. Multi-destination delivery is useful to several applications, including: - distributed, replicated databases [6,9]. - conferencing [11]. - distributed parallel computation, including distributed gaming [2]. Ideally, multicast transmission to a set of hosts is not more complicated or expensive for the sender than transmission to a single host. Similarly, multicast transmission should not be more expensive for the networks and gateways than traversing the shortest path tree that connects the sending host to the hosts identified by the multicast address. (Bill here again) Bottom line: I believe we should start with RFC 966. RFC 1112 targets an Internet that no longer exists, and LAN technology that has long since been superceded. For some time I've wanted to help write an RFC-1112-bis. I'm very much looking forward to the results of this BOF. Again--take good notes! === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwm/K6wgm7ipJDXBAQHURgP+KHN5kuwgZFPMIRUNIsaPPINZzPd+Q2v2 3aPtB9YfIadNW9Ia0ENaH3X06+uwfVA6VK5ZPFLqJQh4K6Bh4yrggpzWYhxclDio aNYkJsPHXzGoCUbiEzdLF4eg40mxR2DA0t5WzjwOAwMKqudvVJWyIvHcuRP04LgU RXWZsj013Zs= =37Vd -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 01:47:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27929 for ; Tue, 8 Jul 2003 01:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJf-0002bB-4X; Tue, 08 Jul 2003 01:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYnH-0003Dy-4b for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 12:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02135 for ; Mon, 7 Jul 2003 12:24:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYnF-0006HQ-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:24:45 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZYnD-0006Gy-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:24:44 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h67GOJwc025162; Mon, 7 Jul 2003 09:24:19 -0700 From: David Meyer To: shep@shepfarm.com Cc: Jon Crowcroft , "Manfredi, Albert E" , Greg Shepherd , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Message-ID: <20030707092419.A25060@1-4-5.net> References: <20030707081620.A24670@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@shepfarm.com on Mon, Jul 07, 2003 at 10:40:34AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 09:24:19 -0700 >> > No ISP/carrier that I have ever worked for (or even, that >> > I know of, where ISP == "IP Transport Bandwidth >> > Provider") has ever been able to demonstrate any kind of >> > CAPEX savings due to multicast. In fact, the places where it >> > might be most useful (tail circuits) provide the opposite >> > incentive to the bandwidth provider (why would I provide >> > you a technology that allows you to buy less of my >> > product [bandwidth]?) >> >> As Lenny pointed out, any 'savings' assumes canabilizing unicast content >> for multicast. BUT a large-audience multicast transport service could >> bring a whole new range of content at a much higher quality (read >> bit-rate) which could be a completely different service to >> sell. So you are saying that you have a technology that is looking for a "whole new range of content at a much higher quality"? OK. I don't disagree that multicast is a technology looking for such an application (at least in the inter-domain space; we all know that there are many enterprise applications). >> Its not about saving bandwidth in the core. Yes. History and experience has shown us that this much is clear. >> Its about creating a transport service which allows >> successfull biz-models/services for content owners which are >> ISP customers. could/would/should/...As we all know, this whole discussion is 10+ years old. I really don't see anything new here. >> Having profitable customers is a good thing. I don't think any one is arguing that profitability isn't a good thing (or if they were, I didn't undertstand that from the thread). >> > OTOH, perhaps that's a selling point when marketing to >> > large content providers or the like. The reality, >> > however, is that such custmers (and in fact, most large >> > consumers of b/w) want carrier diverse facilities, kinda >> > blowing away that argument in any event. Clearly there >> > are cross-incentives here. >> >> Yup, I've seen the same. But I also think a large content owner wants >> first the largest audience possible. This would seem to be the case if there is a positive correlation between maximizing ROIC and/or minimizing OPEX, and audience size. It is not clear (at least not clear to me) that this is necessarily the case. >> > >> obviously if all the users using simultaneous unicast switched to >> > >> multicast this MIGHT be true, but the real point is that it enables >> > >> new sources, applications and services, and might therefore INCREASE >> > >> revenue....noone can say for sure... >> > >> >> > >> i think the technical obstacles (cable tv modem head end, DSLAM, and >> > >> other minimal support for igmp magic, security, charging for group >> > >> size and other stuff are the critical points and think this BOG Is an >> > >> althogether >> > >> Most Exellent Idea >> > >> > Yep. >> >> Thanks for your support Dave, Sure. Hopefully we can tackle some of the thorny problems that have plagued multicast deployment (and have been pointed out in this thread). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 02:01:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00140 for ; Tue, 8 Jul 2003 02:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlXB-0003tI-1B; Tue, 08 Jul 2003 02:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlWR-0003ov-FP for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 02:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28689 for ; Tue, 8 Jul 2003 02:00:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZlWN-0006en-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:00:11 -0400 Received: from web42001.mail.yahoo.com ([66.218.93.169]) by ietf-mx with smtp (Exim 4.12) id 19ZlWN-0006ed-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:00:11 -0400 Message-ID: <20030708055941.84709.qmail@web42001.mail.yahoo.com> Received: from [203.200.20.226] by web42001.mail.yahoo.com via HTTP; Tue, 08 Jul 2003 01:59:41 EDT From: Tulip Rasputin Subject: Inserting multiple entries in FIB To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 01:59:41 -0400 (EDT) Hi, What approximate percentage (%) of routers deployed out there in the field are actually able to inject multiple entries for load balancing in their forwarding table for forwarding the traffic? I understand that most of the modern routers can. What i am more interested in hearing is the fraction of routers deployed *out* there in the live networks which support this. Regards, Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 02:01:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00144 for ; Tue, 8 Jul 2003 02:01:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlXE-0003vV-A7 for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 02:01:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68614Wr015064 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 02:01:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlXB-0003tI-1B; Tue, 08 Jul 2003 02:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlWR-0003ov-FP for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 02:00:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28689 for ; Tue, 8 Jul 2003 02:00:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZlWN-0006en-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:00:11 -0400 Received: from web42001.mail.yahoo.com ([66.218.93.169]) by ietf-mx with smtp (Exim 4.12) id 19ZlWN-0006ed-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:00:11 -0400 Message-ID: <20030708055941.84709.qmail@web42001.mail.yahoo.com> Received: from [203.200.20.226] by web42001.mail.yahoo.com via HTTP; Tue, 08 Jul 2003 01:59:41 EDT From: Tulip Rasputin Subject: Inserting multiple entries in FIB To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 01:59:41 -0400 (EDT) Hi, What approximate percentage (%) of routers deployed out there in the field are actually able to inject multiple entries for load balancing in their forwarding table for forwarding the traffic? I understand that most of the modern routers can. What i am more interested in hearing is the fraction of routers deployed *out* there in the live networks which support this. Regards, Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 02:09:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08509 for ; Tue, 8 Jul 2003 02:09:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zlex-00053X-02; Tue, 08 Jul 2003 02:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZleH-0004yp-9s for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 02:08:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07256 for ; Tue, 8 Jul 2003 02:08:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZleD-0006hE-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:08:17 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19ZleD-0006h4-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:08:17 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id A780C23C39; Mon, 7 Jul 2003 23:13:00 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6867lYB014716; Mon, 7 Jul 2003 23:07:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Inserting multiple entries in FIB Message-ID: Thread-Topic: Inserting multiple entries in FIB Thread-Index: AcNFFnYNbinZ74YUQRuk2ER69L9RPQAAJ1iw From: "Tony Li" To: "Tulip Rasputin" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 23:07:47 -0700 Content-Transfer-Encoding: quoted-printable Please define "out there". Brands C, J and P all do. Tony | -----Original Message----- | From: Tulip Rasputin [mailto:tulip_rasputin@yahoo.ca]=20 | Sent: Monday, July 07, 2003 11:00 PM | To: routing-discussion@ietf.org | Subject: Inserting multiple entries in FIB | =20 | =20 | Hi, | =20 | What approximate percentage (%) of routers deployed out=20 | there in the field are actually able to | inject multiple entries for load balancing in their=20 | forwarding table for forwarding the traffic? | =20 | I understand that most of the modern routers can. What i=20 | am more interested in hearing is the | fraction of routers deployed *out* there in the live=20 | networks which support this. | =20 | Regards, | Rasputin | =20 | ___________________________________________________________ | ___________=20 | Post your free ad now! http://personals.yahoo.ca | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 02:31:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11434 for ; Tue, 8 Jul 2003 02:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zm0D-0006ki-Ao; Tue, 08 Jul 2003 02:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zlzr-0006jH-HG for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 02:30:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11401 for ; Tue, 8 Jul 2003 02:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zlzn-0006ry-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:30:35 -0400 Received: from web42004.mail.yahoo.com ([66.218.93.172]) by ietf-mx with smtp (Exim 4.12) id 19Zlzn-0006rk-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:30:35 -0400 Message-ID: <20030708063005.93393.qmail@web42004.mail.yahoo.com> Received: from [203.200.20.226] by web42004.mail.yahoo.com via HTTP; Tue, 08 Jul 2003 02:30:05 EDT From: Tulip Rasputin Subject: RE: Inserting multiple entries in FIB To: Tony.Li@procket.com Cc: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 02:30:05 -0400 (EDT) Tony, I meant out there in the actual ISP deployments! :-) Thanks for the help! Regards, Rasputin ----- Original Message ----- From: "Tony Li" To: "Tulip Rasputin" ; Sent: Tuesday, July 08, 2003 11:37 AM Subject: RE: Inserting multiple entries in FIB Please define "out there". Brands C, J and P all do. Tony | -----Original Message----- | From: Tulip Rasputin [mailto:tulip_rasputin@yahoo.ca] | Sent: Monday, July 07, 2003 11:00 PM | To: routing-discussion@ietf.org | Subject: Inserting multiple entries in FIB | | | Hi, | | What approximate percentage (%) of routers deployed out | there in the field are actually able to | inject multiple entries for load balancing in their | forwarding table for forwarding the traffic? | | I understand that most of the modern routers can. What i | am more interested in hearing is the | fraction of routers deployed *out* there in the live | networks which support this. | | Regards, | Rasputin | ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 02:35:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27836 for ; Tue, 8 Jul 2003 01:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJq-0002je-2p for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 01:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h685lDJg010355 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 01:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJg-0002bR-5F; Tue, 08 Jul 2003 01:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZZ2h-0004Bi-Fn for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 12:40:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02557 for ; Mon, 7 Jul 2003 12:40:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZZ2f-0006Q0-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:40:42 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZZ2f-0006Pb-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:40:41 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h67GeNUI025355; Mon, 7 Jul 2003 09:40:23 -0700 From: David Meyer To: Greg Shepherd Cc: shep@shepfarm.com, Jon Crowcroft , "Manfredi, Albert E" , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Message-ID: <20030707094023.A25302@1-4-5.net> References: <20030707092419.A25060@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@procket.com on Mon, Jul 07, 2003 at 09:35:46AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 09:40:23 -0700 >> > could/would/should/...As we all know, this whole >> > discussion is 10+ years old. I really don't see anything >> > new here. >> >> Good point! ...and that is the problem. So I guess you're saying that we >> need something new? What I meant is what I said. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 02:35:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27924 for ; Tue, 8 Jul 2003 01:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJe-0002b3-Kq; Tue, 08 Jul 2003 01:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXjN-0006kc-Mw for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 11:16:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29391 for ; Mon, 7 Jul 2003 11:16:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXjM-0005Ni-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:16:40 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZXjL-0005N9-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:16:39 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h67FGKBC024732; Mon, 7 Jul 2003 08:16:20 -0700 From: David Meyer To: Jon Crowcroft Cc: "Manfredi, Albert E" , Greg Shepherd , routing-discussion , wg-multicast , mboned Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Message-ID: <20030707081620.A24670@1-4-5.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Jon.Crowcroft@cl.cam.ac.uk on Mon, Jul 07, 2003 at 09:34:35AM +0100 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 08:16:20 -0700 >> since practically no access ISPs allow multicast, how do they know it >> reduces revenue? >> >> this is a typical armchair economist argument No ISP/carrier that I have ever worked for (or even, that I know of, where ISP == "IP Transport Bandwidth Provider") has ever been able to demonstrate any kind of CAPEX savings due to multicast. In fact, the places where it might be most useful (tail circuits) provide the opposite incentive to the bandwidth provider (why would I provide you a technology that allows you to buy less of my product [bandwidth]?) OTOH, perhaps that's a selling point when marketing to large content providers or the like. The reality, however, is that such custmers (and in fact, most large consumers of b/w) want carrier diverse facilities, kinda blowing away that argument in any event. Clearly there are cross-incentives here. >> obviously if all the users using simultaneous unicast switched to >> multicast this MIGHT be true, but the real point is that it enables >> new sources, applications and services, and might therefore INCREASE >> revenue....noone can say for sure... >> >> i think the technical obstacles (cable tv modem head end, DSLAM, and >> other minimal support for igmp magic, security, charging for group >> size and other stuff are the critical points and think this BOG Is an >> althogether >> Most Exellent Idea Yep. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 02:35:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27838 for ; Tue, 8 Jul 2003 01:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJq-0002jM-21 for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 01:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h685lDn1010359 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 01:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJe-0002b3-Kq; Tue, 08 Jul 2003 01:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZXjN-0006kc-Mw for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 11:16:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29391 for ; Mon, 7 Jul 2003 11:16:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZXjM-0005Ni-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:16:40 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZXjL-0005N9-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 11:16:39 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h67FGKBC024732; Mon, 7 Jul 2003 08:16:20 -0700 From: David Meyer To: Jon Crowcroft Cc: "Manfredi, Albert E" , Greg Shepherd , routing-discussion , wg-multicast , mboned Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Message-ID: <20030707081620.A24670@1-4-5.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from Jon.Crowcroft@cl.cam.ac.uk on Mon, Jul 07, 2003 at 09:34:35AM +0100 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 08:16:20 -0700 >> since practically no access ISPs allow multicast, how do they know it >> reduces revenue? >> >> this is a typical armchair economist argument No ISP/carrier that I have ever worked for (or even, that I know of, where ISP == "IP Transport Bandwidth Provider") has ever been able to demonstrate any kind of CAPEX savings due to multicast. In fact, the places where it might be most useful (tail circuits) provide the opposite incentive to the bandwidth provider (why would I provide you a technology that allows you to buy less of my product [bandwidth]?) OTOH, perhaps that's a selling point when marketing to large content providers or the like. The reality, however, is that such custmers (and in fact, most large consumers of b/w) want carrier diverse facilities, kinda blowing away that argument in any event. Clearly there are cross-incentives here. >> obviously if all the users using simultaneous unicast switched to >> multicast this MIGHT be true, but the real point is that it enables >> new sources, applications and services, and might therefore INCREASE >> revenue....noone can say for sure... >> >> i think the technical obstacles (cable tv modem head end, DSLAM, and >> other minimal support for igmp magic, security, charging for group >> size and other stuff are the critical points and think this BOG Is an >> althogether >> Most Exellent Idea Yep. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 02:35:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27833 for ; Tue, 8 Jul 2003 01:47:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJq-0002j5-1U for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 01:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h685lDP7010358 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 01:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJg-0002f2-U0; Tue, 08 Jul 2003 01:47:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zaxw-0004HQ-8f for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 14:43:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07324 for ; Mon, 7 Jul 2003 14:43:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zaxt-0000dU-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:43:53 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19Zaxs-0000cm-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 14:43:52 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h67Igrt138790; Mon, 7 Jul 2003 13:42:53 -0500 Message-Id: <5.2.0.9.2.20030707125826.0220d828@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Greg Shepherd From: Bill Nickless Subject: Re: [Mtp] Re: BOF Agenda - Multicast Last-Mile Solutions Cc: mboned , wg-multicast , routing-discussion , mtp@shepfarm.com In-Reply-To: References: <20030707092419.A25060@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 13:42:47 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 09:35 AM 7/7/2003 -0700, Greg Shepherd wrote: >As I stated in the BOF overview, I would just like to describe the problem >collectively. We can then turn to if/how it can be solved - either by >putting together existing pieces or creating some missing piece. But we >have to start by agreeing on the problem, AND agreeing on what a solution >should achieve. I won't be able to make it to Vienna. Y'all had better take good notes! At the risk of repeating myself, here's my take on it. (Focusing on IPv4, without loss of generality to IPv6): RFC 966 answered that question almost 20 years ago: Multicast has two primary uses, namely distributed binding and multi-destination delivery. As a binding mechanism, multicast is a robust and often more efficient alternative to the use of name servers for finding a particular object or service when a particular host address is not known. For example, in a distributed file system, all the file servers may be associated with one well-known multicast address. To bind a file name to a particular server, a client sends a query packet containing the file name to the file server multicast address, for delivery to all the file servers. The server that recognizes the file name then responds to the client, allowing subsequent interaction directly with that server host. Even when name servers are employed, multicast can be used as the first step in the binding process, that is, finding a name server. Multi-destination delivery is useful to several applications, including: - distributed, replicated databases [6,9]. - conferencing [11]. - distributed parallel computation, including distributed gaming [2]. Ideally, multicast transmission to a set of hosts is not more complicated or expensive for the sender than transmission to a single host. Similarly, multicast transmission should not be more expensive for the networks and gateways than traversing the shortest path tree that connects the sending host to the hosts identified by the multicast address. (Bill here again) Bottom line: I believe we should start with RFC 966. RFC 1112 targets an Internet that no longer exists, and LAN technology that has long since been superceded. For some time I've wanted to help write an RFC-1112-bis. I'm very much looking forward to the results of this BOF. Again--take good notes! === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwm/K6wgm7ipJDXBAQHURgP+KHN5kuwgZFPMIRUNIsaPPINZzPd+Q2v2 3aPtB9YfIadNW9Ia0ENaH3X06+uwfVA6VK5ZPFLqJQh4K6Bh4yrggpzWYhxclDio aNYkJsPHXzGoCUbiEzdLF4eg40mxR2DA0t5WzjwOAwMKqudvVJWyIvHcuRP04LgU RXWZsj013Zs= =37Vd -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 02:35:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27837 for ; Tue, 8 Jul 2003 01:47:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJq-0002jj-31 for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 01:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h685lDk3010357 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 01:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJf-0002bB-4X; Tue, 08 Jul 2003 01:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYnH-0003Dy-4b for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 12:24:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02135 for ; Mon, 7 Jul 2003 12:24:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYnF-0006HQ-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:24:45 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZYnD-0006Gy-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:24:44 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h67GOJwc025162; Mon, 7 Jul 2003 09:24:19 -0700 From: David Meyer To: shep@shepfarm.com Cc: Jon Crowcroft , "Manfredi, Albert E" , Greg Shepherd , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Message-ID: <20030707092419.A25060@1-4-5.net> References: <20030707081620.A24670@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@shepfarm.com on Mon, Jul 07, 2003 at 10:40:34AM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 09:24:19 -0700 >> > No ISP/carrier that I have ever worked for (or even, that >> > I know of, where ISP == "IP Transport Bandwidth >> > Provider") has ever been able to demonstrate any kind of >> > CAPEX savings due to multicast. In fact, the places where it >> > might be most useful (tail circuits) provide the opposite >> > incentive to the bandwidth provider (why would I provide >> > you a technology that allows you to buy less of my >> > product [bandwidth]?) >> >> As Lenny pointed out, any 'savings' assumes canabilizing unicast content >> for multicast. BUT a large-audience multicast transport service could >> bring a whole new range of content at a much higher quality (read >> bit-rate) which could be a completely different service to >> sell. So you are saying that you have a technology that is looking for a "whole new range of content at a much higher quality"? OK. I don't disagree that multicast is a technology looking for such an application (at least in the inter-domain space; we all know that there are many enterprise applications). >> Its not about saving bandwidth in the core. Yes. History and experience has shown us that this much is clear. >> Its about creating a transport service which allows >> successfull biz-models/services for content owners which are >> ISP customers. could/would/should/...As we all know, this whole discussion is 10+ years old. I really don't see anything new here. >> Having profitable customers is a good thing. I don't think any one is arguing that profitability isn't a good thing (or if they were, I didn't undertstand that from the thread). >> > OTOH, perhaps that's a selling point when marketing to >> > large content providers or the like. The reality, >> > however, is that such custmers (and in fact, most large >> > consumers of b/w) want carrier diverse facilities, kinda >> > blowing away that argument in any event. Clearly there >> > are cross-incentives here. >> >> Yup, I've seen the same. But I also think a large content owner wants >> first the largest audience possible. This would seem to be the case if there is a positive correlation between maximizing ROIC and/or minimizing OPEX, and audience size. It is not clear (at least not clear to me) that this is necessarily the case. >> > >> obviously if all the users using simultaneous unicast switched to >> > >> multicast this MIGHT be true, but the real point is that it enables >> > >> new sources, applications and services, and might therefore INCREASE >> > >> revenue....noone can say for sure... >> > >> >> > >> i think the technical obstacles (cable tv modem head end, DSLAM, and >> > >> other minimal support for igmp magic, security, charging for group >> > >> size and other stuff are the critical points and think this BOG Is an >> > >> althogether >> > >> Most Exellent Idea >> > >> > Yep. >> >> Thanks for your support Dave, Sure. Hopefully we can tackle some of the thorny problems that have plagued multicast deployment (and have been pointed out in this thread). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 02:35:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27796 for ; Tue, 8 Jul 2003 01:47:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJf-0002bJ-Jt; Tue, 08 Jul 2003 01:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYyS-0003Xv-8C for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 12:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02386 for ; Mon, 7 Jul 2003 12:36:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYyQ-0006Mz-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:36:18 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19ZYyP-0006Md-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:36:18 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D876734471; Mon, 7 Jul 2003 09:52:54 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h67GZlYB020162; Mon, 7 Jul 2003 09:35:47 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 09:35:46 -0700 From: Greg Shepherd To: David Meyer Cc: shep@shepfarm.com, Jon Crowcroft , "Manfredi, Albert E" , routing-discussion , wg-multicast , mboned , Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <20030707092419.A25060@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Jul 2003 16:35:46.0992 (UTC) FILETIME=[D165FB00:01C344A5] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 09:35:46 -0700 (PDT) On Mon, 7 Jul 2003, David Meyer wrote: > >> > No ISP/carrier that I have ever worked for (or even, that > >> > I know of, where ISP == "IP Transport Bandwidth > >> > Provider") has ever been able to demonstrate any kind of > >> > CAPEX savings due to multicast. In fact, the places where it > >> > might be most useful (tail circuits) provide the opposite > >> > incentive to the bandwidth provider (why would I provide > >> > you a technology that allows you to buy less of my > >> > product [bandwidth]?) > >> > >> As Lenny pointed out, any 'savings' assumes canabilizing unicast content > >> for multicast. BUT a large-audience multicast transport service could > >> bring a whole new range of content at a much higher quality (read > >> bit-rate) which could be a completely different service to > >> sell. > > So you are saying that you have a technology that is > looking for a "whole new range of content at a much > higher quality"? OK. I don't disagree that multicast is > a technology looking for such an application (at least in > the inter-domain space; we all know that there are many > enterprise applications). I think there are already plenting of applications. As we, the choir, have been preaching to ourselves for years, this must be content driven in that its the content owners who stand to benifit from a multicast transport biz model. > >> Its not about saving bandwidth in the core. > > Yes. History and experience has shown us that this much > is clear. > > >> Its about creating a transport service which allows > >> successfull biz-models/services for content owners which are > >> ISP customers. > > could/would/should/...As we all know, this whole > discussion is 10+ years old. I really don't see anything > new here. Good point! ...and that is the problem. So I guess you're saying that we need something new? As I stated in the BOF overview, I would just like to describe the problem collectively. We can then turn to if/how it can be solved - either by putting together existing pieces or creating some missing piece. But we have to start by agreeing on the problem, AND agreeing on what a solution should achieve. Thanks, Greg > >> Having profitable customers is a good thing. > > I don't think any one is arguing that profitability isn't > a good thing (or if they were, I didn't undertstand that > from the thread). > > >> > OTOH, perhaps that's a selling point when marketing to > >> > large content providers or the like. The reality, > >> > however, is that such custmers (and in fact, most large > >> > consumers of b/w) want carrier diverse facilities, kinda > >> > blowing away that argument in any event. Clearly there > >> > are cross-incentives here. > >> > >> Yup, I've seen the same. But I also think a large content owner wants > >> first the largest audience possible. > > This would seem to be the case if there is a positive > correlation between maximizing ROIC and/or minimizing > OPEX, and audience size. It is not clear (at least not > clear to me) that this is necessarily the case. > > >> > >> obviously if all the users using simultaneous unicast switched to > >> > >> multicast this MIGHT be true, but the real point is that it enables > >> > >> new sources, applications and services, and might therefore INCREASE > >> > >> revenue....noone can say for sure... > >> > >> > >> > >> i think the technical obstacles (cable tv modem head end, DSLAM, and > >> > >> other minimal support for igmp magic, security, charging for group > >> > >> size and other stuff are the critical points and think this BOG Is an > >> > >> althogether > >> > >> Most Exellent Idea > >> > > >> > Yep. > >> > >> Thanks for your support Dave, > > Sure. Hopefully we can tackle some of the thorny problems > that have plagued multicast deployment (and have been > pointed out in this thread). > > Dave > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 02:35:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27835 for ; Tue, 8 Jul 2003 01:47:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJq-0002jB-1q for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 01:47:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h685lDH1010353 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 01:47:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJf-0002bJ-Jt; Tue, 08 Jul 2003 01:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZYyS-0003Xv-8C for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 12:36:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02386 for ; Mon, 7 Jul 2003 12:36:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZYyQ-0006Mz-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:36:18 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19ZYyP-0006Md-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 12:36:18 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id D876734471; Mon, 7 Jul 2003 09:52:54 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h67GZlYB020162; Mon, 7 Jul 2003 09:35:47 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 7 Jul 2003 09:35:46 -0700 From: Greg Shepherd To: David Meyer Cc: shep@shepfarm.com, Jon Crowcroft , "Manfredi, Albert E" , routing-discussion , wg-multicast , mboned , Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <20030707092419.A25060@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 07 Jul 2003 16:35:46.0992 (UTC) FILETIME=[D165FB00:01C344A5] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 09:35:46 -0700 (PDT) On Mon, 7 Jul 2003, David Meyer wrote: > >> > No ISP/carrier that I have ever worked for (or even, that > >> > I know of, where ISP == "IP Transport Bandwidth > >> > Provider") has ever been able to demonstrate any kind of > >> > CAPEX savings due to multicast. In fact, the places where it > >> > might be most useful (tail circuits) provide the opposite > >> > incentive to the bandwidth provider (why would I provide > >> > you a technology that allows you to buy less of my > >> > product [bandwidth]?) > >> > >> As Lenny pointed out, any 'savings' assumes canabilizing unicast content > >> for multicast. BUT a large-audience multicast transport service could > >> bring a whole new range of content at a much higher quality (read > >> bit-rate) which could be a completely different service to > >> sell. > > So you are saying that you have a technology that is > looking for a "whole new range of content at a much > higher quality"? OK. I don't disagree that multicast is > a technology looking for such an application (at least in > the inter-domain space; we all know that there are many > enterprise applications). I think there are already plenting of applications. As we, the choir, have been preaching to ourselves for years, this must be content driven in that its the content owners who stand to benifit from a multicast transport biz model. > >> Its not about saving bandwidth in the core. > > Yes. History and experience has shown us that this much > is clear. > > >> Its about creating a transport service which allows > >> successfull biz-models/services for content owners which are > >> ISP customers. > > could/would/should/...As we all know, this whole > discussion is 10+ years old. I really don't see anything > new here. Good point! ...and that is the problem. So I guess you're saying that we need something new? As I stated in the BOF overview, I would just like to describe the problem collectively. We can then turn to if/how it can be solved - either by putting together existing pieces or creating some missing piece. But we have to start by agreeing on the problem, AND agreeing on what a solution should achieve. Thanks, Greg > >> Having profitable customers is a good thing. > > I don't think any one is arguing that profitability isn't > a good thing (or if they were, I didn't undertstand that > from the thread). > > >> > OTOH, perhaps that's a selling point when marketing to > >> > large content providers or the like. The reality, > >> > however, is that such custmers (and in fact, most large > >> > consumers of b/w) want carrier diverse facilities, kinda > >> > blowing away that argument in any event. Clearly there > >> > are cross-incentives here. > >> > >> Yup, I've seen the same. But I also think a large content owner wants > >> first the largest audience possible. > > This would seem to be the case if there is a positive > correlation between maximizing ROIC and/or minimizing > OPEX, and audience size. It is not clear (at least not > clear to me) that this is necessarily the case. > > >> > >> obviously if all the users using simultaneous unicast switched to > >> > >> multicast this MIGHT be true, but the real point is that it enables > >> > >> new sources, applications and services, and might therefore INCREASE > >> > >> revenue....noone can say for sure... > >> > >> > >> > >> i think the technical obstacles (cable tv modem head end, DSLAM, and > >> > >> other minimal support for igmp magic, security, charging for group > >> > >> size and other stuff are the critical points and think this BOG Is an > >> > >> althogether > >> > >> Most Exellent Idea > >> > > >> > Yep. > >> > >> Thanks for your support Dave, > > Sure. Hopefully we can tackle some of the thorny problems > that have plagued multicast deployment (and have been > pointed out in this thread). > > Dave > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 02:35:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27925 for ; Tue, 8 Jul 2003 01:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZlJe-0002av-4D; Tue, 08 Jul 2003 01:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZRSS-0005ip-C0 for routing-discussion@optimus.ietf.org; Mon, 07 Jul 2003 04:34:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17339 for ; Mon, 7 Jul 2003 04:34:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZRSP-00026Q-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 04:34:45 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[HninhkT0M7nsf3GXLY59qLiELji9Z2XH]) by ietf-mx with esmtp (Exim 4.12) id 19ZRSO-00026K-00 for routing-discussion@ietf.org; Mon, 07 Jul 2003 04:34:44 -0400 Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19ZRSG-0004ex-00; Mon, 07 Jul 2003 09:34:36 +0100 To: "Manfredi, Albert E" cc: Greg Shepherd , routing-discussion , wg-multicast , mboned , Jon.Crowcroft@cl.cam.ac.uk Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message from "Manfredi, Albert E" of "Sun, 06 Jul 2003 17:20:39 EDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10928.1057566875.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 07 Jul 2003 09:34:35 +0100 since practically no access ISPs allow multicast, how do they know it reduces revenue? this is a typical armchair economist argument obviously if all the users using simultaneous unicast switched to multicast this MIGHT be true, but the real point is that it enables new sources, applications and services, and might therefore INCREASE revenue....noone can say for sure... i think the technical obstacles (cable tv modem head end, DSLAM, and other minimal support for igmp magic, security, charging for group size and other stuff are the critical points and think this BOG Is an althogether Most Exellent Idea In missive , "Manfredi, Albert E" typed: >>Interesting subject. From what I'm told, one of the big obstacles in = >>enabling multicast all the way through is that use of multicast reduces = >>the revenues ISPs can expect for providing network services? That's a = >>plausible reason. Are there others? Security? >> >>Bert >> >> >>> -----Original Message----- >>> From: Greg Shepherd [mailto:shep@procket.com] >>> Sent: Wednesday, July 02, 2003 7:23 PM >>> To: agenda@ietf.org; pim@catarina.usc.edu; idmr@cs.ucl.ac.uk; >>> magma@innovationslab.net; routing-discussion@ietf.org; >>> wg-multicast@internet2.edu; mboned@network-services.uoregon.edu >>> Cc: Alex Zinin; Bill Fenner; Keyur Patel; Greg Shepherd >>> Subject: BOF Agenda - Multicast Last-Mile Solutions >>>=20 >>>=20 >>>=20 >>> Multicast Last-Mile Solutions BOF >>>=20 >>> DESCRIPTION: >>>=20 >>> Successful content distribution business plans have been=20 >>> hampered by the >>> all-or-nothing nature of a multicast routed infrastructure.=20 >>> Several drafts >>> have arisen over the past few years to address the last-mile multicast >>> deployment gap, but have all lost momentum for various reasons. Recent >>> efforts on yet another draft have revealed the need to have=20 >>> all affected >>> parties participate in the effort in order to provide a=20 >>> comprehensive yet >>> simple and deployable solution. >>>=20 >>> A content owner which wishes to build a buisness model around=20 >>> multicast >>> distribution is hampered by the current limited scope of multicast >>> deployment. Their only option today is to purchase multicast transit >>> services from their provider of choice which does not ensure the path >>> between their content and their customers is multicast enabled. The >>> administrative control of the multicast topology in this=20 >>> relationship is >>> restricted to the provider and the content customer. The=20 >>> missing step on >>> the path to full multicast deployment will require a solution which >>> allows the content owner the benefits of multicast replication, >>> independent of the radius of the multicast deployment. >>>=20 >>> The purpose of this BOF is to bring together operators, content >>> providers/owners, application and protocol implementors to discuss the >>> problem and worked towards a mutually desired solution. The expected >>> outcome will be an evaluation of interest, a better defined problem >>> statement, directions for any future progress from the BOF >>> participants. >>>=20 >>> AGENDA: >>>=20 >>> 1. Agenda Bashing (all) >>> 2. Problem description (shep - 10min) >>> 3. Discussion of current gaps and future direction (from the floor) >>>=20 >>> WEB REFERNCE: >>> http://www.shepfarm.com/multicast/last-mile >>>=20 >>> RELEVANT PAST WORK: (this list is possibly incomplete - please send >>> updates) >>> http://www.shepfarm.com/multicast/upim/draft-ietf-mboned-auto- >>multicast-01.txt >>http://www.shepfarm.com/multicast/upim/draft-finlayson-mboned-autotunneli= >>ng-00.txt >>http://www.shepfarm.com/multicast/upim/draft-finlayson-umtp-07.txt >>http://www.shepfarm.com/multicast/upim/draft-keyur-pim-host-extensions-00= >>.txt >>http://www.shepfarm.com/multicast/upim/draft-jibiki-iwata-msdp-idmf-00.tx= >>t >> >>MAILLIST: >>http://www.shepfarm.com/mailman/listinfo/mtp >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 02:55:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08512 for ; Tue, 8 Jul 2003 02:09:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zlez-00055Z-Fr for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 02:09:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68695ml019490 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 02:09:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zlex-00053X-02; Tue, 08 Jul 2003 02:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZleH-0004yp-9s for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 02:08:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07256 for ; Tue, 8 Jul 2003 02:08:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZleD-0006hE-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:08:17 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19ZleD-0006h4-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:08:17 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id A780C23C39; Mon, 7 Jul 2003 23:13:00 -0700 (PDT) Received: from EXCHANGE0-0.na.procket.com (exchange0a.na.procket.com [10.1.7.7]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6867lYB014716; Mon, 7 Jul 2003 23:07:48 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Inserting multiple entries in FIB Message-ID: Thread-Topic: Inserting multiple entries in FIB Thread-Index: AcNFFnYNbinZ74YUQRuk2ER69L9RPQAAJ1iw From: "Tony Li" To: "Tulip Rasputin" , Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 7 Jul 2003 23:07:47 -0700 Content-Transfer-Encoding: quoted-printable Please define "out there". Brands C, J and P all do. Tony | -----Original Message----- | From: Tulip Rasputin [mailto:tulip_rasputin@yahoo.ca]=20 | Sent: Monday, July 07, 2003 11:00 PM | To: routing-discussion@ietf.org | Subject: Inserting multiple entries in FIB | =20 | =20 | Hi, | =20 | What approximate percentage (%) of routers deployed out=20 | there in the field are actually able to | inject multiple entries for load balancing in their=20 | forwarding table for forwarding the traffic? | =20 | I understand that most of the modern routers can. What i=20 | am more interested in hearing is the | fraction of routers deployed *out* there in the live=20 | networks which support this. | =20 | Regards, | Rasputin | =20 | ___________________________________________________________ | ___________=20 | Post your free ad now! http://personals.yahoo.ca | =20 | _______________________________________________ | routing-discussion mailing list | routing-discussion@ietf.org | https://www1.ietf.org/mailman/listinfo/routing-discussion | =20 _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 03:20:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11435 for ; Tue, 8 Jul 2003 02:31:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zm0I-0006mc-Oj for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 02:31:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h686V6KT026013 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 02:31:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zm0D-0006ki-Ao; Tue, 08 Jul 2003 02:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Zlzr-0006jH-HG for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 02:30:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11401 for ; Tue, 8 Jul 2003 02:30:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Zlzn-0006ry-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:30:35 -0400 Received: from web42004.mail.yahoo.com ([66.218.93.172]) by ietf-mx with smtp (Exim 4.12) id 19Zlzn-0006rk-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 02:30:35 -0400 Message-ID: <20030708063005.93393.qmail@web42004.mail.yahoo.com> Received: from [203.200.20.226] by web42004.mail.yahoo.com via HTTP; Tue, 08 Jul 2003 02:30:05 EDT From: Tulip Rasputin Subject: RE: Inserting multiple entries in FIB To: Tony.Li@procket.com Cc: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 02:30:05 -0400 (EDT) Tony, I meant out there in the actual ISP deployments! :-) Thanks for the help! Regards, Rasputin ----- Original Message ----- From: "Tony Li" To: "Tulip Rasputin" ; Sent: Tuesday, July 08, 2003 11:37 AM Subject: RE: Inserting multiple entries in FIB Please define "out there". Brands C, J and P all do. Tony | -----Original Message----- | From: Tulip Rasputin [mailto:tulip_rasputin@yahoo.ca] | Sent: Monday, July 07, 2003 11:00 PM | To: routing-discussion@ietf.org | Subject: Inserting multiple entries in FIB | | | Hi, | | What approximate percentage (%) of routers deployed out | there in the field are actually able to | inject multiple entries for load balancing in their | forwarding table for forwarding the traffic? | | I understand that most of the modern routers can. What i | am more interested in hearing is the | fraction of routers deployed *out* there in the live | networks which support this. | | Regards, | Rasputin | ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 10:53:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25141 for ; Tue, 8 Jul 2003 10:53:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztp4-0006Xn-86; Tue, 08 Jul 2003 10:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztob-0006XB-H9 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 10:51:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25102 for ; Tue, 8 Jul 2003 10:51:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZtoY-0002HP-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 10:51:30 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19ZtoX-0002HA-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 10:51:29 -0400 Received: from laptoy770.fictitious.org (b2-pc148.avici.com [10.2.100.178]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h68Eor322516; Tue, 8 Jul 2003 10:50:53 -0400 (EDT) Message-Id: <200307081450.h68Eor322516@maildev.avici.com> To: Tulip Rasputin cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Inserting multiple entries in FIB In-reply-to: Your message of "Tue, 08 Jul 2003 01:59:41 EDT." <20030708055941.84709.qmail@web42001.mail.yahoo.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 10:51:27 -0400 In message <20030708055941.84709.qmail@web42001.mail.yahoo.com>, Tulip Rasputin writes: > Hi, > > What approximate percentage (%) of routers deployed out there in the field ar > e actually able to > inject multiple entries for load balancing in their forwarding table for forw > arding the traffic? > > I understand that most of the modern routers can. What i am more interested i > n hearing is the > fraction of routers deployed *out* there in the live networks which support t > his. > > Regards, > Rasputin My guess is very close to 100% if not exactly 100% in the tier-1 providers and same possibly for the tier 2. I don't know of any router that has been deployed in an ISP that does not support ECMP. Most or all tier-1 ISPs consider lack of ECMP support to be so serious an ommission that they will not deploy a router that does not have it. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 10:53:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25156 for ; Tue, 8 Jul 2003 10:53:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztpk-0006gA-1V for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 10:52:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68EqinN025664 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 10:52:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztp4-0006Xn-86; Tue, 08 Jul 2003 10:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Ztob-0006XB-H9 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 10:51:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25102 for ; Tue, 8 Jul 2003 10:51:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZtoY-0002HP-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 10:51:30 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19ZtoX-0002HA-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 10:51:29 -0400 Received: from laptoy770.fictitious.org (b2-pc148.avici.com [10.2.100.178]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h68Eor322516; Tue, 8 Jul 2003 10:50:53 -0400 (EDT) Message-Id: <200307081450.h68Eor322516@maildev.avici.com> To: Tulip Rasputin cc: routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Inserting multiple entries in FIB In-reply-to: Your message of "Tue, 08 Jul 2003 01:59:41 EDT." <20030708055941.84709.qmail@web42001.mail.yahoo.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 08 Jul 2003 10:51:27 -0400 In message <20030708055941.84709.qmail@web42001.mail.yahoo.com>, Tulip Rasputin writes: > Hi, > > What approximate percentage (%) of routers deployed out there in the field ar > e actually able to > inject multiple entries for load balancing in their forwarding table for forw > arding the traffic? > > I understand that most of the modern routers can. What i am more interested i > n hearing is the > fraction of routers deployed *out* there in the live networks which support t > his. > > Regards, > Rasputin My guess is very close to 100% if not exactly 100% in the tier-1 providers and same possibly for the tier 2. I don't know of any router that has been deployed in an ISP that does not support ECMP. Most or all tier-1 ISPs consider lack of ECMP support to be so serious an ommission that they will not deploy a router that does not have it. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 12:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29909 for ; Tue, 8 Jul 2003 12:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZvUa-0004pQ-TZ; Tue, 08 Jul 2003 12:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZvUC-0004p3-B2 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 12:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29876 for ; Tue, 8 Jul 2003 12:38:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZvUA-0003Qi-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 12:38:34 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZvUA-0003Qa-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 12:38:34 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h68GcHRt001037; Tue, 8 Jul 2003 09:38:17 -0700 From: David Meyer To: mtp@shepfarm.com Cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: the more things change, the more they stay the same (last mile problem...) Message-ID: <20030708093817.A1010@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 09:38:17 -0700 It just occurred to me that the first draft I wrote in MBONED outlined the inter-domain problems we were having deploying multicast (many/all of which seem to still exist, sadly), and that a similar exercise may be useful in the context of the last mile problem. Further, it seems that some of the issues outlined in that (now ancient) draft apply to the last mile problem. See http://www.1-4-5.net/~dmm/draft-ietf-mboned-imrp-some-issues-01.txt Dave [Maybe I should update this one...] _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 12:39:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29924 for ; Tue, 8 Jul 2003 12:39:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZvUi-0004rb-8g for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 12:39:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68Gd8Qv018624 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 12:39:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZvUa-0004pQ-TZ; Tue, 08 Jul 2003 12:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ZvUC-0004p3-B2 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 12:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29876 for ; Tue, 8 Jul 2003 12:38:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ZvUA-0003Qi-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 12:38:34 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19ZvUA-0003Qa-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 12:38:34 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h68GcHRt001037; Tue, 8 Jul 2003 09:38:17 -0700 From: David Meyer To: mtp@shepfarm.com Cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: the more things change, the more they stay the same (last mile problem...) Message-ID: <20030708093817.A1010@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 09:38:17 -0700 It just occurred to me that the first draft I wrote in MBONED outlined the inter-domain problems we were having deploying multicast (many/all of which seem to still exist, sadly), and that a similar exercise may be useful in the context of the last mile problem. Further, it seems that some of the issues outlined in that (now ancient) draft apply to the last mile problem. See http://www.1-4-5.net/~dmm/draft-ietf-mboned-imrp-some-issues-01.txt Dave [Maybe I should update this one...] _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 18:10:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13107 for ; Tue, 8 Jul 2003 18:10:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0dx-0002ml-5f; Tue, 08 Jul 2003 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0d7-0002jv-08 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 18:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12888 for ; Tue, 8 Jul 2003 18:08:04 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a0d4-0007Zz-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:08:06 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19a0d3-0007Zu-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:08:05 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h68Nuhlq016769; Tue, 8 Jul 2003 16:56:43 -0700 To: Randy Bush cc: Daniel Senie , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 16:56:43 -0700 (PDT) On Sun, 6 Jul 2003, Randy Bush wrote: > there is more traffic about multicast than actual wan multicast. > there is massively more intranet multicast use than internet. the > reasons are that there is money in the latter and none in the > former. Good point! But I would have to argue that we do not know if there is money in interdomain multicast simply because is doesn't exist on any usable scale. The benefits of multicast intradomain are quite easily realized as it is most often a single administrative domain - if you want it everywhere, go turn it on. Interdomain does not have that luxury. Its an all-or-nothing proposition. Every router in the path (across multiple administrative domains) must be mcast enabled or it doesn't work. So current penetration I'd guess to be well under 10%. Even a core network which is mcast enabled and would like to offer/sell multicast service really has nothing to sell. Sure, their network is enabled but that really accounts for nothing without all the other networks in the path to the receivers (content customers) also being enabled. Greg > randy > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 18:10:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13121 for ; Tue, 8 Jul 2003 18:10:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0ea-0002r7-1P for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 18:09:40 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68M9eld010966 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 18:09:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0dx-0002ml-5f; Tue, 08 Jul 2003 18:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0d7-0002jv-08 for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 18:08:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12888 for ; Tue, 8 Jul 2003 18:08:04 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a0d4-0007Zz-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:08:06 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19a0d3-0007Zu-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:08:05 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h68Nuhlq016769; Tue, 8 Jul 2003 16:56:43 -0700 To: Randy Bush cc: Daniel Senie , routing-discussion , wg-multicast , mboned , mtp@shepfarm.com Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 16:56:43 -0700 (PDT) On Sun, 6 Jul 2003, Randy Bush wrote: > there is more traffic about multicast than actual wan multicast. > there is massively more intranet multicast use than internet. the > reasons are that there is money in the latter and none in the > former. Good point! But I would have to argue that we do not know if there is money in interdomain multicast simply because is doesn't exist on any usable scale. The benefits of multicast intradomain are quite easily realized as it is most often a single administrative domain - if you want it everywhere, go turn it on. Interdomain does not have that luxury. Its an all-or-nothing proposition. Every router in the path (across multiple administrative domains) must be mcast enabled or it doesn't work. So current penetration I'd guess to be well under 10%. Even a core network which is mcast enabled and would like to offer/sell multicast service really has nothing to sell. Sure, their network is enabled but that really accounts for nothing without all the other networks in the path to the receivers (content customers) also being enabled. Greg > randy > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 18:11:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13300 for ; Tue, 8 Jul 2003 18:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0fu-00038l-57; Tue, 08 Jul 2003 18:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0fq-00038W-8E for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 18:10:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13221 for ; Tue, 8 Jul 2003 18:10:53 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a0fn-0007e5-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:10:55 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19a0fm-0007e1-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:10:54 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h68NxVlq016801; Tue, 8 Jul 2003 16:59:31 -0700 To: Randy Bush cc: Lloyd Wood , Daniel Senie , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 16:59:30 -0700 (PDT) On Sun, 6 Jul 2003, Randy Bush wrote: > > there's no money in p2p filesharing apps. > > two differences > o p2p file sharing requires nothing in core > o there is money in it for the end users > i.e. the benefit lies where the cost lies Agreed! And the cost of transmitting streaming content to a large audience via unicast is piled high on the content owner/distributor. So they can read and understand mcast, build a biz-plan around mcast distribution, and even turn-up mcast transit with their provider of choice - but they still don't have any usable mcast penetration to realize the cost benefits. There is a missing piece. Greg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 18:11:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13314 for ; Tue, 8 Jul 2003 18:11:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0fx-00039y-Dp for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 18:11:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68MB5Tx012125 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 18:11:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0fu-00038l-57; Tue, 08 Jul 2003 18:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a0fq-00038W-8E for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 18:10:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13221 for ; Tue, 8 Jul 2003 18:10:53 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a0fn-0007e5-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:10:55 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19a0fm-0007e1-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 18:10:54 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h68NxVlq016801; Tue, 8 Jul 2003 16:59:31 -0700 To: Randy Bush cc: Lloyd Wood , Daniel Senie , routing-discussion , wg-multicast , mboned Subject: RE: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 16:59:30 -0700 (PDT) On Sun, 6 Jul 2003, Randy Bush wrote: > > there's no money in p2p filesharing apps. > > two differences > o p2p file sharing requires nothing in core > o there is money in it for the end users > i.e. the benefit lies where the cost lies Agreed! And the cost of transmitting streaming content to a large audience via unicast is piled high on the content owner/distributor. So they can read and understand mcast, build a biz-plan around mcast distribution, and even turn-up mcast transit with their provider of choice - but they still don't have any usable mcast penetration to realize the cost benefits. There is a missing piece. Greg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 8 19:01:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14760 for ; Tue, 8 Jul 2003 19:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a1SH-0006Dl-5G; Tue, 08 Jul 2003 19:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a1Rz-0006DF-Rt for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 19:00:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14743 for ; Tue, 8 Jul 2003 19:00:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a1Rw-0000ai-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 19:00:40 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19a1Rw-0000aD-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 19:00:40 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h68NDFJh015856 for ; Tue, 8 Jul 2003 19:13:15 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h68N03Xs024411 for ; Tue, 8 Jul 2003 19:00:03 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h68N0AC04550; Tue, 8 Jul 2003 16:00:10 -0700 (PDT) Message-Id: <200307082300.h68N0AC04550@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: routing-discussion@ietf.org Subject: Open Routing Area meeting in Vienna Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 16:00:09 -0700 Hiya folks, Alex and I managed to both assume that the other one was going to schedule the routing area meeting for Vienna -- oops! Luckily, we have very forgiving people in charge of the scheduling, so we were able to get a room: Hall NO on Thursday afternoon, 1530-1730. (This is on the online agenda, but didn't make it into the printed version.) We will begin with the usual status reports from the working groups and BOFs that meet. We'll start the open mic time with a discussion of reuse of routing protocols for things that look less and less like routing, and we'll see where things go from there. A more complete agenda will follow. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 8 19:50:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14761 for ; Tue, 8 Jul 2003 19:01:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a1SL-0006F3-5g for routing-discussion-archive@odin.ietf.org; Tue, 08 Jul 2003 19:01:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h68N15WS023967 for routing-discussion-archive@odin.ietf.org; Tue, 8 Jul 2003 19:01:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a1SH-0006Dl-5G; Tue, 08 Jul 2003 19:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19a1Rz-0006DF-Rt for routing-discussion@optimus.ietf.org; Tue, 08 Jul 2003 19:00:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14743 for ; Tue, 8 Jul 2003 19:00:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19a1Rw-0000ai-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 19:00:40 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19a1Rw-0000aD-00 for routing-discussion@ietf.org; Tue, 08 Jul 2003 19:00:40 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h68NDFJh015856 for ; Tue, 8 Jul 2003 19:13:15 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h68N03Xs024411 for ; Tue, 8 Jul 2003 19:00:03 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h68N0AC04550; Tue, 8 Jul 2003 16:00:10 -0700 (PDT) Message-Id: <200307082300.h68N0AC04550@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: routing-discussion@ietf.org Subject: Open Routing Area meeting in Vienna Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 8 Jul 2003 16:00:09 -0700 Hiya folks, Alex and I managed to both assume that the other one was going to schedule the routing area meeting for Vienna -- oops! Luckily, we have very forgiving people in charge of the scheduling, so we were able to get a room: Hall NO on Thursday afternoon, 1530-1730. (This is on the online agenda, but didn't make it into the printed version.) We will begin with the usual status reports from the working groups and BOFs that meet. We'll start the open mic time with a discussion of reuse of routing protocols for things that look less and less like routing, and we'll see where things go from there. A more complete agenda will follow. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 11:58:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07213 for ; Wed, 9 Jul 2003 11:58:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHKT-0007IM-Dt; Wed, 09 Jul 2003 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aG4o-0006rx-OH for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 10:37:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03073 for ; Wed, 9 Jul 2003 10:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aG4f-000705-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 10:37:37 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19aG4e-0006ze-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 10:37:36 -0400 Received: from columbia.edu (curta.cc.columbia.edu [128.59.39.150]) (user=alan mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h69EbE3P021797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Jul 2003 10:37:18 -0400 (EDT) Message-ID: <3F0C289A.7030403@columbia.edu> From: Alan Crosswell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030501 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shep@shepfarm.com CC: Randy Bush , Lloyd Wood , Daniel Senie , routing-discussion , wg-multicast , mboned Subject: Re: BOF Agenda - Multicast Last-Mile Solutions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 10:37:14 -0400 Content-Transfer-Encoding: 7bit > There is a missing piece. > There are too many pieces: Namely CDNs like Akamai freeflow streaming. /a _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 11:58:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07228 for ; Wed, 9 Jul 2003 11:58:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHKc-0007K1-D4 for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 11:58:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69FwAn7028096 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 11:58:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHKT-0007IM-Dt; Wed, 09 Jul 2003 11:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aG4o-0006rx-OH for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 10:37:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03073 for ; Wed, 9 Jul 2003 10:37:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aG4f-000705-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 10:37:37 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.59.238] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 19aG4e-0006ze-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 10:37:36 -0400 Received: from columbia.edu (curta.cc.columbia.edu [128.59.39.150]) (user=alan mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.12.8p1/8.12.8) with ESMTP id h69EbE3P021797 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Jul 2003 10:37:18 -0400 (EDT) Message-ID: <3F0C289A.7030403@columbia.edu> From: Alan Crosswell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030501 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shep@shepfarm.com CC: Randy Bush , Lloyd Wood , Daniel Senie , routing-discussion , wg-multicast , mboned Subject: Re: BOF Agenda - Multicast Last-Mile Solutions References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 10:37:14 -0400 Content-Transfer-Encoding: 7bit > There is a missing piece. > There are too many pieces: Namely CDNs like Akamai freeflow streaming. /a _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 12:04:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07597 for ; Wed, 9 Jul 2003 12:04:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHQL-00083e-SM for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 12:04:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69G45Ik030939 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 12:04:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHQI-00081f-Lj; Wed, 09 Jul 2003 12:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHPc-0007z7-1l for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 12:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07550 for ; Wed, 9 Jul 2003 12:03:16 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHPa-00005x-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 12:03:18 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aHPZ-00005n-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 12:03:17 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h69Hpflq018325; Wed, 9 Jul 2003 10:51:41 -0700 To: Alan Crosswell cc: Randy Bush , Lloyd Wood , Daniel Senie , routing-discussion , wg-multicast , mboned Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <3F0C289A.7030403@columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 10:51:41 -0700 (PDT) On Wed, 9 Jul 2003, Alan Crosswell wrote: > > > There is a missing piece. > > > > There are too many pieces: Namely CDNs like Akamai freeflow streaming. > /a Too many non-standard pieces that do not leverage multicast. Greg > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 12:55:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07595 for ; Wed, 9 Jul 2003 12:04:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHQI-00081f-Lj; Wed, 09 Jul 2003 12:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aHPc-0007z7-1l for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 12:03:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07550 for ; Wed, 9 Jul 2003 12:03:16 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aHPa-00005x-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 12:03:18 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aHPZ-00005n-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 12:03:17 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h69Hpflq018325; Wed, 9 Jul 2003 10:51:41 -0700 To: Alan Crosswell cc: Randy Bush , Lloyd Wood , Daniel Senie , routing-discussion , wg-multicast , mboned Subject: Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: <3F0C289A.7030403@columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 10:51:41 -0700 (PDT) On Wed, 9 Jul 2003, Alan Crosswell wrote: > > > There is a missing piece. > > > > There are too many pieces: Namely CDNs like Akamai freeflow streaming. > /a Too many non-standard pieces that do not leverage multicast. Greg > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 16:49:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21426 for ; Wed, 9 Jul 2003 16:49:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLr9-00033p-EE; Wed, 09 Jul 2003 16:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLqy-00033N-Ra for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 16:47:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21312 for ; Wed, 9 Jul 2003 16:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLqw-0003GV-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 16:47:50 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aLqv-0003G6-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 16:47:50 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69KlXsp011863; Wed, 9 Jul 2003 13:47:33 -0700 From: David Meyer To: mtp@shepfarm.com Cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709134733.A11761@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 13:47:33 -0700 I guess the more things change, the more they stay the same. So another thing occurred to me while reading the Multicast Last-Mile Solutions drafts on Greg's site: Why are we defining yet another ad-hoc signaling protocol (that is one way to looks at these proposals)? The IETF literature is littered with signaling proposals, some host-based, some router-based, at varying degrees of generality. Straw person: why not have the host send a PATH message towards the source (since it knows the source) and have the first multicast capable router in the path send back the its tunnel endpoint, have the host set up GRE (or user space encap) to that router and ... What I am suggesting is we really don't have a general purpose host-to-router signaling protocol (well, maybe). So if we pick one of the current drafts (or a hybrid, or even new), will we have to build a new signaling infrastructure for the next feature not supported by the directly connected routers? Seems like we should be able to answer this question in a more general way than is done in these drafts. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 16:49:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21441 for ; Wed, 9 Jul 2003 16:49:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLro-0003OJ-Tq for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 16:48:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Kmirf012979 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 16:48:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLr9-00033p-EE; Wed, 09 Jul 2003 16:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aLqy-00033N-Ra for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 16:47:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21312 for ; Wed, 9 Jul 2003 16:47:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aLqw-0003GV-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 16:47:50 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aLqv-0003G6-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 16:47:50 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69KlXsp011863; Wed, 9 Jul 2003 13:47:33 -0700 From: David Meyer To: mtp@shepfarm.com Cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709134733.A11761@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 13:47:33 -0700 I guess the more things change, the more they stay the same. So another thing occurred to me while reading the Multicast Last-Mile Solutions drafts on Greg's site: Why are we defining yet another ad-hoc signaling protocol (that is one way to looks at these proposals)? The IETF literature is littered with signaling proposals, some host-based, some router-based, at varying degrees of generality. Straw person: why not have the host send a PATH message towards the source (since it knows the source) and have the first multicast capable router in the path send back the its tunnel endpoint, have the host set up GRE (or user space encap) to that router and ... What I am suggesting is we really don't have a general purpose host-to-router signaling protocol (well, maybe). So if we pick one of the current drafts (or a hybrid, or even new), will we have to build a new signaling infrastructure for the next feature not supported by the directly connected routers? Seems like we should be able to answer this question in a more general way than is done in these drafts. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 17:09:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22291 for ; Wed, 9 Jul 2003 17:09:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMBR-00054V-AY; Wed, 09 Jul 2003 17:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMAa-0004zB-Es for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22253 for ; Wed, 9 Jul 2003 17:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMAY-0003VO-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:06 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19aMAX-0003V9-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:05 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 964F334482; Wed, 9 Jul 2003 14:24:46 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.1.1.43]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h69L7YYB029395; Wed, 9 Jul 2003 14:07:34 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id h69L7YJm006506; Wed, 9 Jul 2003 14:07:34 -0700 Message-Id: <200307092107.h69L7YJm006506@dino-pc.procket.com> From: Dino Farinacci To: dmm@1-4-5.net Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org In-reply-to: <20030709134733.A11761@1-4-5.net> (message from David Meyer on Wed, 9 Jul 2003 13:47:33 -0700) Subject: Re: [Mtp] the more things change, the more they stay the same References: <20030709134733.A11761@1-4-5.net> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:07:34 -0700 >> Straw person: why not have the host send a PATH message >> towards the source (since it knows the source) and have >> the first multicast capable router in the path send back >> the its tunnel endpoint, have the host set up GRE (or >> user space encap) to that router and ... Are you suggesting to use RSVP? Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 17:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22293 for ; Wed, 9 Jul 2003 17:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMBR-00054d-Qk; Wed, 09 Jul 2003 17:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMAx-00051S-Vc for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:08:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22272 for ; Wed, 9 Jul 2003 17:08:28 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMAv-0003VU-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:29 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aMAu-0003VR-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:29 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h69Muvlq018896; Wed, 9 Jul 2003 15:56:57 -0700 To: David Meyer cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709134733.A11761@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 15:56:57 -0700 (PDT) On Wed, 9 Jul 2003, David Meyer wrote: > > I guess the more things change, the more they stay the > same. > > So another thing occurred to me while reading the > Multicast Last-Mile Solutions drafts on Greg's site: Why > are we defining yet another ad-hoc signaling protocol > (that is one way to looks at these proposals)? The IETF > literature is littered with signaling proposals, some > host-based, some router-based, at varying degrees of > generality. Agreed. > Straw person: why not have the host send a PATH message > towards the source (since it knows the source) and have > the first multicast capable router in the path send back > the its tunnel endpoint, have the host set up GRE (or > user space encap) to that router and ... Well, that is quite similar (from a straw prospective) to what I'd like. My personal preference is for user-space so it could be easily deployed. But why not just translate the destination address? You know the receiver address so change the destination address of the replicated mcast stream for each unicast reciever. No encap, no decap, no fragmentation. The trouble has been that many of the proposal seem to get mired in 'features' outside of a routed infrastructure, or steers toward a biz-plan of deploying special-purpose boxes (reading between the lines..). > What I am suggesting is we really don't have a general > purpose host-to-router signaling protocol (well, > maybe). IGMP sure.. but its link-local. IF IGMP (and PIM as well) were capable of multi-hop signalling from the beginning, we wouldn't have this gap. > So if we pick one of the current drafts (or a > hybrid, or even new), will we have to build a new > signaling infrastructure for the next feature not > supported by the directly connected routers? Sorry, I don't follow.. Can you clarify? > Seems like we should be able to answer this question in a > more general way than is done in these drafts. And I hope to use the BOF to set some direction. Greg > Dave > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 17:14:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22548 for ; Wed, 9 Jul 2003 17:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMGH-0005bd-Ly; Wed, 09 Jul 2003 17:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMFX-0005aP-5b for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22497 for ; Wed, 9 Jul 2003 17:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMFU-0003Z2-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:13:13 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMFT-0003Yq-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:13:12 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LCtYB012261; Wed, 9 Jul 2003 14:12:55 -0700 From: David Meyer To: Dino Farinacci Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709141255.A12203@1-4-5.net> References: <20030709134733.A11761@1-4-5.net> <200307092107.h69L7YJm006506@dino-pc.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307092107.h69L7YJm006506@dino-pc.procket.com>; from dino@procket.com on Wed, Jul 09, 2003 at 02:07:34PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:12:55 -0700 On Wed, Jul 09, 2003 at 02:07:34PM -0700, Dino Farinacci wrote: >> >> Straw person: why not have the host send a PATH message >> >> towards the source (since it knows the source) and have >> >> the first multicast capable router in the path send back >> >> the its tunnel endpoint, have the host set up GRE (or >> >> user space encap) to that router and ... >> >> Are you suggesting to use RSVP? Not really. Just wondering if there is a more general way to solve the problem (rather than cooking up a yet another special purpose solution for this case). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 17:25:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22961 for ; Wed, 9 Jul 2003 17:25:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMR0-0006us-RA for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 17:25:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69LP6IJ026568 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 17:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMQw-0006th-1x; Wed, 09 Jul 2003 17:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMQK-0006sv-NN for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:24:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22942 for ; Wed, 9 Jul 2003 17:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMQI-0003hn-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:24:22 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMQH-0003hN-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:24:21 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LO44N012415; Wed, 9 Jul 2003 14:24:04 -0700 From: David Meyer To: shep@shepfarm.com Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709142404.B12203@1-4-5.net> References: <20030709134733.A11761@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@shepfarm.com on Wed, Jul 09, 2003 at 03:56:57PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:24:04 -0700 >> > So if we pick one of the current drafts (or a >> > hybrid, or even new), will we have to build a new >> > signaling infrastructure for the next feature not >> > supported by the directly connected routers? >> >> Sorry, I don't follow.. Can you clarify? It would seem that the general form of this particular deployment problem is: The router on directly the directly connected network, or that router and some number of subsequent routers in the path towards some resource, can't or won't do . Now, what is being discussed here is an instantiation for the special case of multicast (or in the case of a few of the drafts, even narrower: SSM). Now, what happens when I have a different , say ? Is what is the signaling built for useful useful when deploying , or do I have to go build the (new) signaling protocol? It's more a discussion about the Internet architecture (in general) and less about multicast, although if we could build something general, instantiating it with this case (multicast) would be nice example. Does that help? Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 17:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23478 for ; Wed, 9 Jul 2003 17:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMeT-0008F9-Gz; Wed, 09 Jul 2003 17:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMe4-0008EH-Jh for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23399 for ; Wed, 9 Jul 2003 17:38:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMe2-0003rs-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:38:34 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19aMdz-0003rR-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:38:32 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA00211; Wed, 9 Jul 2003 14:37:39 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id OAA06758; Wed, 9 Jul 2003 14:38:16 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h69LaUP04832; Wed, 9 Jul 2003 14:36:30 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jul 2003 17:36:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mtp] the more things change, the more they stay the same Message-ID: Thread-Topic: [Mtp] the more things change, the more they stay the same Thread-Index: AcNGXtojUd0H7kgOT0eK/wX9ftsmlAAAQjkA From: "Manfredi, Albert E" To: , "David Meyer" Cc: , , , X-OriginalArrivalTime: 09 Jul 2003 21:36:34.0249 (UTC) FILETIME=[2B3A5B90:01C34662] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:36:33 -0400 Content-Transfer-Encoding: quoted-printable > David Meyer wrote: > > > Straw person: why not have the host send a PATH message > > towards the source (since it knows the source) and have > > the first multicast capable router in the path send back > > the its tunnel endpoint, have the host set up GRE (or > > user space encap) to that router and ... Greg Shepherd wrote: =20 > Well, that is quite similar (from a straw prospective) to what I'd > like. My personal preference is for user-space so it could be easily > deployed. But why not just translate the destination address?=20 > You know the > receiver address so change the destination address of the=20 > replicated mcast > stream for each unicast reciever. No encap, no decap, no=20 > fragmentation. Not sure what problem we are trying to solve here. If it's the problem = of end users being able to accept Class D packets, then this won't work = unless IGMP is changed slightly. That is, the multicast-enabled router = currently does NOT have a complete list of every member of the group. = Because IGMP allows hosts on any given subnet to not send a report if = they've heard someone else already respond to the router's query with a = join report for their group. So to translate the Class D address to a = unicast address, and replicate the packet, would need a slight mod to = IGMP. But if that's a goal, I agree with Greg. If we're trying simply to get a good count of membership, the same basic = problem exists. But I would think the fix is simple enough, although it makes IGMP or = multicasting in general somewhat less scalable. Just make every host = member of the multicast group respond with a report. You could even use = the router's unique IP address to respond, rather than the multicast = address. If there's a need to have the source of the multicast get a current = membership total, each router can in turn provide membership totals to = the source address of the multicast. This still scales better than = having individual hosts reply to the source! My vote would be to allow IGMP reports to be sent by EACH member, but to = still use the multicast address in the packets to the each host member. = And to have the multicast routers close the gap to the source, rather = than each end user. Somehow, it hurts (me) to see RSVP signaling used as a replacement for = IGMP. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 17:39:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23483 for ; Wed, 9 Jul 2003 17:39:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMea-0008GH-2r for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 17:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Ld8cT031756 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 17:39:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMeT-0008F9-Gz; Wed, 09 Jul 2003 17:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMe4-0008EH-Jh for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:38:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23399 for ; Wed, 9 Jul 2003 17:38:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMe2-0003rs-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:38:34 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19aMdz-0003rR-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:38:32 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id OAA00211; Wed, 9 Jul 2003 14:37:39 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id OAA06758; Wed, 9 Jul 2003 14:38:16 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h69LaUP04832; Wed, 9 Jul 2003 14:36:30 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 9 Jul 2003 17:36:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mtp] the more things change, the more they stay the same Message-ID: Thread-Topic: [Mtp] the more things change, the more they stay the same Thread-Index: AcNGXtojUd0H7kgOT0eK/wX9ftsmlAAAQjkA From: "Manfredi, Albert E" To: , "David Meyer" Cc: , , , X-OriginalArrivalTime: 09 Jul 2003 21:36:34.0249 (UTC) FILETIME=[2B3A5B90:01C34662] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:36:33 -0400 Content-Transfer-Encoding: quoted-printable > David Meyer wrote: > > > Straw person: why not have the host send a PATH message > > towards the source (since it knows the source) and have > > the first multicast capable router in the path send back > > the its tunnel endpoint, have the host set up GRE (or > > user space encap) to that router and ... Greg Shepherd wrote: =20 > Well, that is quite similar (from a straw prospective) to what I'd > like. My personal preference is for user-space so it could be easily > deployed. But why not just translate the destination address?=20 > You know the > receiver address so change the destination address of the=20 > replicated mcast > stream for each unicast reciever. No encap, no decap, no=20 > fragmentation. Not sure what problem we are trying to solve here. If it's the problem = of end users being able to accept Class D packets, then this won't work = unless IGMP is changed slightly. That is, the multicast-enabled router = currently does NOT have a complete list of every member of the group. = Because IGMP allows hosts on any given subnet to not send a report if = they've heard someone else already respond to the router's query with a = join report for their group. So to translate the Class D address to a = unicast address, and replicate the packet, would need a slight mod to = IGMP. But if that's a goal, I agree with Greg. If we're trying simply to get a good count of membership, the same basic = problem exists. But I would think the fix is simple enough, although it makes IGMP or = multicasting in general somewhat less scalable. Just make every host = member of the multicast group respond with a report. You could even use = the router's unique IP address to respond, rather than the multicast = address. If there's a need to have the source of the multicast get a current = membership total, each router can in turn provide membership totals to = the source address of the multicast. This still scales better than = having individual hosts reply to the source! My vote would be to allow IGMP reports to be sent by EACH member, but to = still use the multicast address in the packets to the each host member. = And to have the multicast routers close the gap to the source, rather = than each end user. Somehow, it hurts (me) to see RSVP signaling used as a replacement for = IGMP. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 17:43:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23832 for ; Wed, 9 Jul 2003 17:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiP-0000cI-Kw for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 17:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Lh5GG002262 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 17:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiL-0000XQ-8a; Wed, 09 Jul 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMhO-0000Nu-3D for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23710 for ; Wed, 9 Jul 2003 17:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMhL-0003y9-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:41:59 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMhK-0003wo-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:41:58 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LfgeI012688; Wed, 9 Jul 2003 14:41:42 -0700 From: David Meyer To: Greg Shepherd Cc: shep@shepfarm.com, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709144142.A12511@1-4-5.net> References: <20030709142404.B12203@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@procket.com on Wed, Jul 09, 2003 at 02:29:09PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:41:42 -0700 >> Yup, thanks. I understood the desire for a general purpose solution, but >> wasn't clear whether you already had an example. I guess I was just being >> hopefull. ;-) It turns out that you might be able to choose, depending on how much you want to implement in a host. RSVP is a signaling protocol that could be used to do this, and is extensible, and can be/is implemented in user space on the host side (an objective for the last mile work, as I understand it). Going to the other end spectrum you find things like the control plane specified in draft-ietf-l2tpext-l2tp-base* (L2TPv3 control plane). If you keep going you get to draft-kompella-mpls-l2vpn-*, and the like. I'm really not advocating any solution at this point. What I was after was some more general thinking about the problem (in the event that turns out to be useful). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 17:43:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23835 for ; Wed, 9 Jul 2003 17:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiP-0000cd-LL for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 17:43:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69Lh5Ut002263 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 17:43:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiM-0000YK-Iv; Wed, 09 Jul 2003 17:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiH-0000XB-Tl for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:42:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23787 for ; Wed, 9 Jul 2003 17:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMiF-0003zf-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:42:55 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMiE-0003z0-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:42:54 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LgcOi012716; Wed, 9 Jul 2003 14:42:38 -0700 From: David Meyer To: Radia Perlman - Boston Center for Networking Cc: dino@procket.com, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709144238.A12692@1-4-5.net> References: <200307092129.h69LTss19167@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307092129.h69LTss19167@sydney.East.Sun.COM>; from Radia.Perlman@Sun.COM on Wed, Jul 09, 2003 at 05:29:54PM -0400 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:42:38 -0700 On Wed, Jul 09, 2003 at 05:29:54PM -0400, Radia Perlman - Boston Center for Networking wrote: >> Dave Meyer said: >> >> >>a more general way >> >> to solve the problem (rather than cooking up a yet >> >> another special purpose solution for this case). >> >> What do you mean by "more general way"? Something that would >> be useful for more than multicast? Something that would be >> useful for more than SSM style multicast? >> >> I'm trying to get people to be specific rather >> than using vague terms like "not architecturally pure" or "yet another >> special purpose mechanism", >> that sound pejorative, yet don't really convey information. Please accept my apology. I didn't mean or think anything like that. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 17:55:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22296 for ; Wed, 9 Jul 2003 17:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMBX-00057p-6f for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 17:09:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69L97d6019617 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 17:09:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMBR-00054V-AY; Wed, 09 Jul 2003 17:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMAa-0004zB-Es for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:08:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22253 for ; Wed, 9 Jul 2003 17:08:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMAY-0003VO-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:06 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19aMAX-0003V9-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:05 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 964F334482; Wed, 9 Jul 2003 14:24:46 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.1.1.43]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h69L7YYB029395; Wed, 9 Jul 2003 14:07:34 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id h69L7YJm006506; Wed, 9 Jul 2003 14:07:34 -0700 Message-Id: <200307092107.h69L7YJm006506@dino-pc.procket.com> From: Dino Farinacci To: dmm@1-4-5.net Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org In-reply-to: <20030709134733.A11761@1-4-5.net> (message from David Meyer on Wed, 9 Jul 2003 13:47:33 -0700) Subject: Re: [Mtp] the more things change, the more they stay the same References: <20030709134733.A11761@1-4-5.net> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:07:34 -0700 >> Straw person: why not have the host send a PATH message >> towards the source (since it knows the source) and have >> the first multicast capable router in the path send back >> the its tunnel endpoint, have the host set up GRE (or >> user space encap) to that router and ... Are you suggesting to use RSVP? Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 17:55:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22295 for ; Wed, 9 Jul 2003 17:09:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMBX-00057s-7D for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 17:09:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69L97F0019619 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 17:09:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMBR-00054d-Qk; Wed, 09 Jul 2003 17:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMAx-00051S-Vc for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:08:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22272 for ; Wed, 9 Jul 2003 17:08:28 -0400 (EDT) From: shep@shepfarm.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMAv-0003VU-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:29 -0400 Received: from shepfarm.com ([198.58.3.10] helo=wilbur ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aMAu-0003VR-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:08:29 -0400 Received: from shepfarm.com (IDENT:shep@shepfarm.com [198.58.3.10]) by wilbur (8.12.9/8.11.3) with ESMTP id h69Muvlq018896; Wed, 9 Jul 2003 15:56:57 -0700 To: David Meyer cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709134733.A11761@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 15:56:57 -0700 (PDT) On Wed, 9 Jul 2003, David Meyer wrote: > > I guess the more things change, the more they stay the > same. > > So another thing occurred to me while reading the > Multicast Last-Mile Solutions drafts on Greg's site: Why > are we defining yet another ad-hoc signaling protocol > (that is one way to looks at these proposals)? The IETF > literature is littered with signaling proposals, some > host-based, some router-based, at varying degrees of > generality. Agreed. > Straw person: why not have the host send a PATH message > towards the source (since it knows the source) and have > the first multicast capable router in the path send back > the its tunnel endpoint, have the host set up GRE (or > user space encap) to that router and ... Well, that is quite similar (from a straw prospective) to what I'd like. My personal preference is for user-space so it could be easily deployed. But why not just translate the destination address? You know the receiver address so change the destination address of the replicated mcast stream for each unicast reciever. No encap, no decap, no fragmentation. The trouble has been that many of the proposal seem to get mired in 'features' outside of a routed infrastructure, or steers toward a biz-plan of deploying special-purpose boxes (reading between the lines..). > What I am suggesting is we really don't have a general > purpose host-to-router signaling protocol (well, > maybe). IGMP sure.. but its link-local. IF IGMP (and PIM as well) were capable of multi-hop signalling from the beginning, we wouldn't have this gap. > So if we pick one of the current drafts (or a > hybrid, or even new), will we have to build a new > signaling infrastructure for the next feature not > supported by the directly connected routers? Sorry, I don't follow.. Can you clarify? > Seems like we should be able to answer this question in a > more general way than is done in these drafts. And I hope to use the BOF to set some direction. Greg > Dave > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 18:00:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22549 for ; Wed, 9 Jul 2003 17:14:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMGI-0005d8-Ue for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 17:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69LE2Ii021610 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 17:14:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMGH-0005bd-Ly; Wed, 09 Jul 2003 17:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMFX-0005aP-5b for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:13:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22497 for ; Wed, 9 Jul 2003 17:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMFU-0003Z2-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:13:13 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMFT-0003Yq-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:13:12 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LCtYB012261; Wed, 9 Jul 2003 14:12:55 -0700 From: David Meyer To: Dino Farinacci Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709141255.A12203@1-4-5.net> References: <20030709134733.A11761@1-4-5.net> <200307092107.h69L7YJm006506@dino-pc.procket.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307092107.h69L7YJm006506@dino-pc.procket.com>; from dino@procket.com on Wed, Jul 09, 2003 at 02:07:34PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:12:55 -0700 On Wed, Jul 09, 2003 at 02:07:34PM -0700, Dino Farinacci wrote: >> >> Straw person: why not have the host send a PATH message >> >> towards the source (since it knows the source) and have >> >> the first multicast capable router in the path send back >> >> the its tunnel endpoint, have the host set up GRE (or >> >> user space encap) to that router and ... >> >> Are you suggesting to use RSVP? Not really. Just wondering if there is a more general way to solve the problem (rather than cooking up a yet another special purpose solution for this case). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 18:10:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22960 for ; Wed, 9 Jul 2003 17:25:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMQw-0006th-1x; Wed, 09 Jul 2003 17:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMQK-0006sv-NN for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:24:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22942 for ; Wed, 9 Jul 2003 17:24:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMQI-0003hn-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:24:22 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMQH-0003hN-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:24:21 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LO44N012415; Wed, 9 Jul 2003 14:24:04 -0700 From: David Meyer To: shep@shepfarm.com Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709142404.B12203@1-4-5.net> References: <20030709134733.A11761@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@shepfarm.com on Wed, Jul 09, 2003 at 03:56:57PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:24:04 -0700 >> > So if we pick one of the current drafts (or a >> > hybrid, or even new), will we have to build a new >> > signaling infrastructure for the next feature not >> > supported by the directly connected routers? >> >> Sorry, I don't follow.. Can you clarify? It would seem that the general form of this particular deployment problem is: The router on directly the directly connected network, or that router and some number of subsequent routers in the path towards some resource, can't or won't do . Now, what is being discussed here is an instantiation for the special case of multicast (or in the case of a few of the drafts, even narrower: SSM). Now, what happens when I have a different , say ? Is what is the signaling built for useful useful when deploying , or do I have to go build the (new) signaling protocol? It's more a discussion about the Internet architecture (in general) and less about multicast, although if we could build something general, instantiating it with this case (multicast) would be nice example. Does that help? Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 18:30:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23830 for ; Wed, 9 Jul 2003 17:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiM-0000YK-Iv; Wed, 09 Jul 2003 17:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiH-0000XB-Tl for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:42:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23787 for ; Wed, 9 Jul 2003 17:42:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMiF-0003zf-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:42:55 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMiE-0003z0-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:42:54 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LgcOi012716; Wed, 9 Jul 2003 14:42:38 -0700 From: David Meyer To: Radia Perlman - Boston Center for Networking Cc: dino@procket.com, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709144238.A12692@1-4-5.net> References: <200307092129.h69LTss19167@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307092129.h69LTss19167@sydney.East.Sun.COM>; from Radia.Perlman@Sun.COM on Wed, Jul 09, 2003 at 05:29:54PM -0400 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:42:38 -0700 On Wed, Jul 09, 2003 at 05:29:54PM -0400, Radia Perlman - Boston Center for Networking wrote: >> Dave Meyer said: >> >> >>a more general way >> >> to solve the problem (rather than cooking up a yet >> >> another special purpose solution for this case). >> >> What do you mean by "more general way"? Something that would >> be useful for more than multicast? Something that would be >> useful for more than SSM style multicast? >> >> I'm trying to get people to be specific rather >> than using vague terms like "not architecturally pure" or "yet another >> special purpose mechanism", >> that sound pejorative, yet don't really convey information. Please accept my apology. I didn't mean or think anything like that. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 18:30:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23831 for ; Wed, 9 Jul 2003 17:43:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMiL-0000XQ-8a; Wed, 09 Jul 2003 17:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMhO-0000Nu-3D for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23710 for ; Wed, 9 Jul 2003 17:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMhL-0003y9-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:41:59 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19aMhK-0003wo-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:41:58 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h69LfgeI012688; Wed, 9 Jul 2003 14:41:42 -0700 From: David Meyer To: Greg Shepherd Cc: shep@shepfarm.com, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709144142.A12511@1-4-5.net> References: <20030709142404.B12203@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shep@procket.com on Wed, Jul 09, 2003 at 02:29:09PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:41:42 -0700 >> Yup, thanks. I understood the desire for a general purpose solution, but >> wasn't clear whether you already had an example. I guess I was just being >> hopefull. ;-) It turns out that you might be able to choose, depending on how much you want to implement in a host. RSVP is a signaling protocol that could be used to do this, and is extensible, and can be/is implemented in user space on the host side (an objective for the last mile work, as I understand it). Going to the other end spectrum you find things like the control plane specified in draft-ietf-l2tpext-l2tp-base* (L2TPv3 control plane). If you keep going you get to draft-kompella-mpls-l2vpn-*, and the like. I'm really not advocating any solution at this point. What I was after was some more general thinking about the problem (in the event that turns out to be useful). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 18:32:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27035 for ; Wed, 9 Jul 2003 18:32:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNTm-0004SO-LI; Wed, 09 Jul 2003 18:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNTS-0004S4-6p for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 18:31:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27020 for ; Wed, 9 Jul 2003 18:31:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aNTP-0004dD-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:31:39 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19aNTO-0004cz-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:31:38 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h69MUjt55948; Wed, 9 Jul 2003 17:30:45 -0500 Message-Id: <5.2.0.9.2.20030709172506.02b9fde0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Keyur Patel , Leonard Giuliano From: Bill Nickless Subject: Re: [Mtp] the more things change, the more they stay the same Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org In-Reply-To: <3F0C9535.3080308@cisco.com> References: <20030709134733.A11761@1-4-5.net> <20030709142404.B12203@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 17:30:39 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 03:20 PM 7/9/2003 -0700, Keyur Patel wrote: >Single signaling infrastructure should work for SSM and ASM model. One >could use well known anycast address to direct all the control traffic to >a specific location within a network. > >-Keyur ...or towards an IPv6 embedded RP address. (Hi Pakkola!) Earlier, Lenny wrote: >Making the source host a tunnel endpoint is already supported. This is >called unicast. Yes, at Layer 3. But not at Layer 4 and higher. The people I work with care about Layer 4 (and above). More generally, I predict that enabling the Layer 4 service will drive deployment at Layer 3 and below. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwyXkqwgm7ipJDXBAQGIZAP/cGIJdl/Uq5xzRtNaATQMZ9GuKF0/CS4x ACOy6ifIhgQxR2Z8Vc/fa/ENO4eH1QqBfOtrpbtPqhS2glw8RE5sTKiW2WOl3DSr P8waRwnYUgMWxzWqD+zuYbRrj7U7jxzTbhDhZgu8rnzSJA4lIp+ooVDe1tPXuBJF axLleIctV3A= =ltzL -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 18:32:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27054 for ; Wed, 9 Jul 2003 18:32:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNTy-0004TU-Dt for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 18:32:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h69MWE2O017189 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 18:32:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNTm-0004SO-LI; Wed, 09 Jul 2003 18:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNTS-0004S4-6p for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 18:31:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27020 for ; Wed, 9 Jul 2003 18:31:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aNTP-0004dD-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:31:39 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19aNTO-0004cz-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:31:38 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h69MUjt55948; Wed, 9 Jul 2003 17:30:45 -0500 Message-Id: <5.2.0.9.2.20030709172506.02b9fde0@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Keyur Patel , Leonard Giuliano From: Bill Nickless Subject: Re: [Mtp] the more things change, the more they stay the same Cc: mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org In-Reply-To: <3F0C9535.3080308@cisco.com> References: <20030709134733.A11761@1-4-5.net> <20030709142404.B12203@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 17:30:39 -0500 -----BEGIN PGP SIGNED MESSAGE----- At 03:20 PM 7/9/2003 -0700, Keyur Patel wrote: >Single signaling infrastructure should work for SSM and ASM model. One >could use well known anycast address to direct all the control traffic to >a specific location within a network. > >-Keyur ...or towards an IPv6 embedded RP address. (Hi Pakkola!) Earlier, Lenny wrote: >Making the source host a tunnel endpoint is already supported. This is >called unicast. Yes, at Layer 3. But not at Layer 4 and higher. The people I work with care about Layer 4 (and above). More generally, I predict that enabling the Layer 4 service will drive deployment at Layer 3 and below. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPwyXkqwgm7ipJDXBAQGIZAP/cGIJdl/Uq5xzRtNaATQMZ9GuKF0/CS4x ACOy6ifIhgQxR2Z8Vc/fa/ENO4eH1QqBfOtrpbtPqhS2glw8RE5sTKiW2WOl3DSr P8waRwnYUgMWxzWqD+zuYbRrj7U7jxzTbhDhZgu8rnzSJA4lIp+ooVDe1tPXuBJF axLleIctV3A= =ltzL -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 20:05:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29945 for ; Wed, 9 Jul 2003 20:05:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOvl-0003nL-Sa; Wed, 09 Jul 2003 20:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOvg-0003mw-Tr for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 20:04:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29929 for ; Wed, 9 Jul 2003 20:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOve-0005Wu-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:04:55 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19aOve-0005Wk-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:04:54 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h69NvF3j021223; Wed, 9 Jul 2003 19:57:15 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h6A049Xs022051; Wed, 9 Jul 2003 20:04:09 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h6A04GZ18656; Wed, 9 Jul 2003 17:04:16 -0700 (PDT) Message-Id: <200307100004.h6A04GZ18656@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: joelja@darkwing.uoregon.edu Subject: Re: [Mtp] the more things change, the more they stay the same Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:04:15 -0700 On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > It was never clear to me why a host to router signaling mechanism had > to be different from the router to router signaling mechanism. Here's one reason: because if we had this conversation in 1993 we would have made the host to router signalling mechanism DVMRP, or maybe we would have been looking toward the future and made it MOSPF. The generalization of that is the goal is to be able to evolve the routing protocol independently of the host<>router interface. Since there are orders of magnitudes more hosts to change than routers when a protocol changes, this theoretically makes the infrastructure more able to change piecemeal. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 20:05:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29960 for ; Wed, 9 Jul 2003 20:05:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOvx-0003oy-Pl for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 20:05:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A05DZt014676 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 20:05:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOvl-0003nL-Sa; Wed, 09 Jul 2003 20:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOvg-0003mw-Tr for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 20:04:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29929 for ; Wed, 9 Jul 2003 20:04:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOve-0005Wu-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:04:55 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19aOve-0005Wk-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:04:54 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h69NvF3j021223; Wed, 9 Jul 2003 19:57:15 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h6A049Xs022051; Wed, 9 Jul 2003 20:04:09 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h6A04GZ18656; Wed, 9 Jul 2003 17:04:16 -0700 (PDT) Message-Id: <200307100004.h6A04GZ18656@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: joelja@darkwing.uoregon.edu Subject: Re: [Mtp] the more things change, the more they stay the same Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:04:15 -0700 On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > It was never clear to me why a host to router signaling mechanism had > to be different from the router to router signaling mechanism. Here's one reason: because if we had this conversation in 1993 we would have made the host to router signalling mechanism DVMRP, or maybe we would have been looking toward the future and made it MOSPF. The generalization of that is the goal is to be able to evolve the routing protocol independently of the host<>router interface. Since there are orders of magnitudes more hosts to change than routers when a protocol changes, this theoretically makes the infrastructure more able to change piecemeal. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 9 20:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00210 for ; Wed, 9 Jul 2003 20:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aP0b-0004Tc-QH; Wed, 09 Jul 2003 20:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aP0K-0004T8-NE for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 20:09:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00176 for ; Wed, 9 Jul 2003 20:09:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aP0I-0005aD-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:09:42 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19aP0H-0005a1-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:09:42 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6A08lu39189; Wed, 9 Jul 2003 17:08:47 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200307100008.h6A08lu39189@merlot.juniper.net> To: Lorenzo Vicisano cc: Joel Jaeggli , wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org, pusateri@juniper.net Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: Message from Lorenzo Vicisano of "Wed, 09 Jul 2003 15:06:22 PDT." <20030709150622.F1057@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22682.1057795727.1@juniper.net> From: Tom Pusateri Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 17:08:47 -0700 In message <20030709150622.F1057@cisco.com> you write: >On Wed, Jul 09, 2003 at 02:52:46PM -0700, Joel Jaeggli wrote: >> On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: >> >> > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: >> > > >> > > It was never clear to me why a host to router signaling mechanism had >> > > to be different from the router to router signaling mechanism. >> > >> > one reason is because a host just needs to signal that is wants to >> > receive multicast on a link, while a router cooperates with other >> > routers to forward multicast in some optimized way. Hence the >> > statement "I want to receive from this link" is typically not >> > sufficient. >> >> so why can't I just send an s,g join towards s using pim instead of nicely >> using igmp to get my first hop router to do it for me? > >because you, the host, would have to have routing information to find >out who the 1st hop towards the source is... you would also have to >take part to the PIM routing protocol to find out who's responsible to >forward in your lan for that source. > > Lorenzo More than that, routers are particular about the state they keep and who they exchange routing information with. Running PIM on the hosts is a fast way to get PIM turned off on the routers. I won't be at the BOF so here are some suggestions I would like to see come out of this work: 1. I don't think we should throw out the idea of a new signaling protocol too quickly. If we can reuse someone else's packet formats, then great but the characteristics of the signaling should be decided first and then we can determine if an existing protocol will fit our needs. The characteristics I would like to see are: a. Host application can send join requests without any special privileges on the largest variety of operating systems. This speeds deployment and puts users in control without having to get approval from Administrators. This dictates that the protocol be UDP or TCP based. b. A server or router listening to these join requests should not have to guess what type of join this is. The server may be doing encapsulation or it may be doing header rewriting (translating from multicast to unicast). It needs to know how many "users" it can handle and know if resources become limited that it can drop these hosts instead of dropping something like real multicast PIM neighbor adjacencies which will affect many "users". A way to clearly distinguish this application is essential if you want router/switch vendors to be willing to replicate or accept tunnel requests at the edge of your network. 2. Don't make encapsulation a requirement. This complicates the host implementation requiring it to decapsulate. While this may be one way to get the multicast to the hosts, simply having servers sit at the edge of a network and replicating a multicast stream to a bunch of hosts by replacing the multicast destination address with the hosts unicast address eliminates much complication from the host application. It simply sees a regular UDP unicast stream coming in. 3. The address the join is sent to should be specified the same way as the group and the source address is learned. This will likely be in the SDP description. The join address may in fact be the source, or it may be an anycast address or some other invention. But we're free to try different approaches and we don't lock ourselves in. 4. The join should use the router alert option in the IP header. This will allow routers along the path from the receiver to the source to process the unicast join or send it to a server it knows about. Lets nail down some more requirements of the signaling protocol and then decide if we need to invent something new or we can reuse some existing mechanism. Thanks, Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 9 20:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00209 for ; Wed, 9 Jul 2003 20:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aP0e-0004Ua-Q7 for routing-discussion-archive@odin.ietf.org; Wed, 09 Jul 2003 20:10:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6A0A4oF017261 for routing-discussion-archive@odin.ietf.org; Wed, 9 Jul 2003 20:10:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aP0b-0004Tc-QH; Wed, 09 Jul 2003 20:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aP0K-0004T8-NE for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 20:09:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00176 for ; Wed, 9 Jul 2003 20:09:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aP0I-0005aD-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:09:42 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19aP0H-0005a1-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:09:42 -0400 Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6A08lu39189; Wed, 9 Jul 2003 17:08:47 -0700 (PDT) (envelope-from pusateri@juniper.net) Message-Id: <200307100008.h6A08lu39189@merlot.juniper.net> To: Lorenzo Vicisano cc: Joel Jaeggli , wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org, pusateri@juniper.net Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: Message from Lorenzo Vicisano of "Wed, 09 Jul 2003 15:06:22 PDT." <20030709150622.F1057@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22682.1057795727.1@juniper.net> From: Tom Pusateri Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 17:08:47 -0700 In message <20030709150622.F1057@cisco.com> you write: >On Wed, Jul 09, 2003 at 02:52:46PM -0700, Joel Jaeggli wrote: >> On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: >> >> > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: >> > > >> > > It was never clear to me why a host to router signaling mechanism had >> > > to be different from the router to router signaling mechanism. >> > >> > one reason is because a host just needs to signal that is wants to >> > receive multicast on a link, while a router cooperates with other >> > routers to forward multicast in some optimized way. Hence the >> > statement "I want to receive from this link" is typically not >> > sufficient. >> >> so why can't I just send an s,g join towards s using pim instead of nicely >> using igmp to get my first hop router to do it for me? > >because you, the host, would have to have routing information to find >out who the 1st hop towards the source is... you would also have to >take part to the PIM routing protocol to find out who's responsible to >forward in your lan for that source. > > Lorenzo More than that, routers are particular about the state they keep and who they exchange routing information with. Running PIM on the hosts is a fast way to get PIM turned off on the routers. I won't be at the BOF so here are some suggestions I would like to see come out of this work: 1. I don't think we should throw out the idea of a new signaling protocol too quickly. If we can reuse someone else's packet formats, then great but the characteristics of the signaling should be decided first and then we can determine if an existing protocol will fit our needs. The characteristics I would like to see are: a. Host application can send join requests without any special privileges on the largest variety of operating systems. This speeds deployment and puts users in control without having to get approval from Administrators. This dictates that the protocol be UDP or TCP based. b. A server or router listening to these join requests should not have to guess what type of join this is. The server may be doing encapsulation or it may be doing header rewriting (translating from multicast to unicast). It needs to know how many "users" it can handle and know if resources become limited that it can drop these hosts instead of dropping something like real multicast PIM neighbor adjacencies which will affect many "users". A way to clearly distinguish this application is essential if you want router/switch vendors to be willing to replicate or accept tunnel requests at the edge of your network. 2. Don't make encapsulation a requirement. This complicates the host implementation requiring it to decapsulate. While this may be one way to get the multicast to the hosts, simply having servers sit at the edge of a network and replicating a multicast stream to a bunch of hosts by replacing the multicast destination address with the hosts unicast address eliminates much complication from the host application. It simply sees a regular UDP unicast stream coming in. 3. The address the join is sent to should be specified the same way as the group and the source address is learned. This will likely be in the SDP description. The join address may in fact be the source, or it may be an anycast address or some other invention. But we're free to try different approaches and we don't lock ourselves in. 4. The join should use the router alert option in the IP header. This will allow routers along the path from the receiver to the source to process the unicast join or send it to a server it knows about. Lets nail down some more requirements of the signaling protocol and then decide if we need to invent something new or we can reuse some existing mechanism. Thanks, Tom _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 10:35:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04995 for ; Thu, 10 Jul 2003 10:35:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acVi-0005HA-Nz; Thu, 10 Jul 2003 10:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acVb-0005GN-K4 for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 10:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04951 for ; Thu, 10 Jul 2003 10:34:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acVZ-0003Q5-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:34:53 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19acVY-0003PQ-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:34:52 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19468; Thu, 10 Jul 2003 10:34:19 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12550; Thu, 10 Jul 2003 10:34:19 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MQTH4>; Thu, 10 Jul 2003 10:34:19 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6F52@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Bill Fenner'" , joelja@darkwing.uoregon.edu Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: RE: [Mtp] the more things change, the more they stay the same MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 10:34:18 -0400 -> From: Bill Fenner [mailto:fenner@research.att.com] -> On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: -> > -> > It was never clear to me why a host to router signaling -> mechanism had -> > to be different from the router to router signaling mechanism. -> -> Here's one reason: because if we had this conversation in 1993 we -> would have made the host to router signalling mechanism DVMRP, or -> maybe we would have been looking toward the future and made it MOSPF. -> -> The generalization of that is the goal is to be able to evolve -> the routing protocol independently of the host<>router interface. -> Since there are orders of magnitudes more hosts to change than -> routers when a protocol changes, this theoretically makes the -> infrastructure more able to change piecemeal. Another good reason is based on end-to-end principle of the Internet. Core of the Internet is best effort (was intended to be, at least). If we would like to support quality of service, we are supposed to signal more parameters in the host<>router than router<>router to do admission control before entering the network. So, the requirements are different (light weight, not so granular signalling in the core etc) from user<>router interface to router<>router interface. I am not sure how much (or, how) multicasting fits into such end-to-end signaling principle. If I have an HDTV and paid for premium VoD service, will I be getting better picture, sound quality than my neighbor who is subscribed to a basic service ? Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 10:35:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05010 for ; Thu, 10 Jul 2003 10:35:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acVq-0005IH-I0 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 10:35:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AEZARu020348 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 10:35:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acVi-0005HA-Nz; Thu, 10 Jul 2003 10:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acVb-0005GN-K4 for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 10:34:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04951 for ; Thu, 10 Jul 2003 10:34:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acVZ-0003Q5-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:34:53 -0400 Received: from mailgate.pit.comms.marconi.com ([169.144.68.6]) by ietf-mx with esmtp (Exim 4.12) id 19acVY-0003PQ-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:34:52 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19468; Thu, 10 Jul 2003 10:34:19 -0400 (EDT) Received: from uspitsmsgrtr01.pit.comms.marconi.com (uspitsmsgrtr01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12550; Thu, 10 Jul 2003 10:34:19 -0400 (EDT) Received: by uspitsmsgrtr01.pit.comms.marconi.com with Internet Mail Service (5.5.2653.19) id <3P1MQTH4>; Thu, 10 Jul 2003 10:34:19 -0400 Message-ID: <39469E08BD83D411A3D900204840EC55FB6F52@vie-msgusr-01.dc.fore.com> From: "Naidu, Venkata" To: "'Bill Fenner'" , joelja@darkwing.uoregon.edu Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: RE: [Mtp] the more things change, the more they stay the same MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 10:34:18 -0400 -> From: Bill Fenner [mailto:fenner@research.att.com] -> On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: -> > -> > It was never clear to me why a host to router signaling -> mechanism had -> > to be different from the router to router signaling mechanism. -> -> Here's one reason: because if we had this conversation in 1993 we -> would have made the host to router signalling mechanism DVMRP, or -> maybe we would have been looking toward the future and made it MOSPF. -> -> The generalization of that is the goal is to be able to evolve -> the routing protocol independently of the host<>router interface. -> Since there are orders of magnitudes more hosts to change than -> routers when a protocol changes, this theoretically makes the -> infrastructure more able to change piecemeal. Another good reason is based on end-to-end principle of the Internet. Core of the Internet is best effort (was intended to be, at least). If we would like to support quality of service, we are supposed to signal more parameters in the host<>router than router<>router to do admission control before entering the network. So, the requirements are different (light weight, not so granular signalling in the core etc) from user<>router interface to router<>router interface. I am not sure how much (or, how) multicasting fits into such end-to-end signaling principle. If I have an HDTV and paid for premium VoD service, will I be getting better picture, sound quality than my neighbor who is subscribed to a basic service ? Venkata. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 10:57:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05828 for ; Thu, 10 Jul 2003 10:57:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acqz-0006w8-Kw; Thu, 10 Jul 2003 10:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acqX-0006vP-EI for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 10:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05753 for ; Thu, 10 Jul 2003 10:56:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acqU-0003ca-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:56:30 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19acqT-0003cG-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:56:30 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6AEuCOM017902; Thu, 10 Jul 2003 07:56:12 -0700 From: David Meyer To: mboned@network-services.uoregon.edu Cc: wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? Message-ID: <20030710075612.A17872@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 07:56:12 -0700 Here's something I've been discussing with the ADs (and hoping to learn the lessons of the MADDOGs "experience"). I put it on the mboned agenda, so we can also discuss this there. As always, comments greatly appreciated. Dave --- This note proposes the creation the Internet Multicast Documentation, Oversight, and Coordination (IMDOC) function. The IMDOC, residing in mboned, will serve as the locus of documentation, cross-coordination, and oversight function for the muticast activity in the IETF at large, and will create two crucial missing pieces of the multicast puzzle: (i). A comprehensive IETF multicast framework document, and (ii). the Internet Multicast Reference Architecture (IMRA). Both are discussed briefly below. IMDOC documents will be published in the mboned working group and will: (i). Provide a comprehensive framework document. This document will cover all multicast issues under consideration within IETF, and will provide a systematic way determining when new working groups are needed. (ii). Provide the Internet Multicast Reference Architecture document. Importantly, the IMRA will cover both intra and inter-domain multicast architectures. (iii). Outline domain-specific problem spaces (for example, as was done in mboned with draft-ietf-mboned-imrp-some-issues-01.txt). (iv). Preserve the archival knowledge of what has worked and what hasn't, and why. This knowledge is currently folklore (or very ad hoc at best). The IMDOC coordination and oversight functions will be organized by the mboned working group in conjunction with the appropriate working group chairs and area directors. The following list of areas (which are in scope for the IMDOC) is not intended to exhaustive, but rather to illustrate the requirement for oversight and coordination: (i). Addressing Including dynamic address assignment (malloc, etc), IANA issues (IPv4 and IPv6, e.g. RFC 3171/BCP51), scoping mechanisms and methodologies, multicast address derivation (e.g. RFCs 2770 and 3138) and Unicast Based Addresses (IPv6). (ii). Source discovery Including in-band source discovery methods such as BSR (which touches pim) and embedded RP (which touches ipv6)), and out-of-band mechanisms such as proposed for SSM (which touches ssm), and their associated applications and APIs (which touches mmusic). Examples of documents in this area include RFC 3569. (iii). Security Including key exchange (which touches msec), and data encryption (which touches ipsec), as well as the general problem of a security architecture for multicast. (iv). L2 aliasing For example, 802.x (which touches ipoib and others), IGMP/MLD Snooping, CGMP, PIM Snooping, and RGMP (which touches on MAGMA). (v). Routing For example, BGP4+ and associated extensions which effect multicast, Multi-Topology IGPs. (vi). Forwarding Including discussions on all PIM forwarding modes, DVMPR, CBT, etc. Also includes issues associated with RP mapping approached for PIM-SM, and general discussions on ASM vs. SSM models (covering bidirectional and unidirectional status as well) (vii). Reliable Transport Including discussions on RMT generated building blocks as well as issues associated with PGM. Covers FEC, CC, etc. (viii). Session Control Will include issues associated with source and receiver control, example MSNIP, RTS/CTS issues, floor-control, etc. (ix). Application Layer Issues Examples include BCPs for writing multicast applications (e.g. RFC 3170), discussions on default address use, traffic patterns (example implications of bursty traffic, low frequency traffic), and APIs for SSM. (x). Tunneling Including any potential new dynamic tunneling proposals which come from Last Mile Multicast, etc. (xi). VPN Both L2 (pwe3, l2vpn), and L3 (ppvpn, l3vpn) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 10:57:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05839 for ; Thu, 10 Jul 2003 10:57:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acr7-0006xU-IT for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 10:57:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AEv9GX026734 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 10:57:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acqz-0006w8-Kw; Thu, 10 Jul 2003 10:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19acqX-0006vP-EI for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 10:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05753 for ; Thu, 10 Jul 2003 10:56:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19acqU-0003ca-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:56:30 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19acqT-0003cG-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 10:56:30 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6AEuCOM017902; Thu, 10 Jul 2003 07:56:12 -0700 From: David Meyer To: mboned@network-services.uoregon.edu Cc: wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? Message-ID: <20030710075612.A17872@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 07:56:12 -0700 Here's something I've been discussing with the ADs (and hoping to learn the lessons of the MADDOGs "experience"). I put it on the mboned agenda, so we can also discuss this there. As always, comments greatly appreciated. Dave --- This note proposes the creation the Internet Multicast Documentation, Oversight, and Coordination (IMDOC) function. The IMDOC, residing in mboned, will serve as the locus of documentation, cross-coordination, and oversight function for the muticast activity in the IETF at large, and will create two crucial missing pieces of the multicast puzzle: (i). A comprehensive IETF multicast framework document, and (ii). the Internet Multicast Reference Architecture (IMRA). Both are discussed briefly below. IMDOC documents will be published in the mboned working group and will: (i). Provide a comprehensive framework document. This document will cover all multicast issues under consideration within IETF, and will provide a systematic way determining when new working groups are needed. (ii). Provide the Internet Multicast Reference Architecture document. Importantly, the IMRA will cover both intra and inter-domain multicast architectures. (iii). Outline domain-specific problem spaces (for example, as was done in mboned with draft-ietf-mboned-imrp-some-issues-01.txt). (iv). Preserve the archival knowledge of what has worked and what hasn't, and why. This knowledge is currently folklore (or very ad hoc at best). The IMDOC coordination and oversight functions will be organized by the mboned working group in conjunction with the appropriate working group chairs and area directors. The following list of areas (which are in scope for the IMDOC) is not intended to exhaustive, but rather to illustrate the requirement for oversight and coordination: (i). Addressing Including dynamic address assignment (malloc, etc), IANA issues (IPv4 and IPv6, e.g. RFC 3171/BCP51), scoping mechanisms and methodologies, multicast address derivation (e.g. RFCs 2770 and 3138) and Unicast Based Addresses (IPv6). (ii). Source discovery Including in-band source discovery methods such as BSR (which touches pim) and embedded RP (which touches ipv6)), and out-of-band mechanisms such as proposed for SSM (which touches ssm), and their associated applications and APIs (which touches mmusic). Examples of documents in this area include RFC 3569. (iii). Security Including key exchange (which touches msec), and data encryption (which touches ipsec), as well as the general problem of a security architecture for multicast. (iv). L2 aliasing For example, 802.x (which touches ipoib and others), IGMP/MLD Snooping, CGMP, PIM Snooping, and RGMP (which touches on MAGMA). (v). Routing For example, BGP4+ and associated extensions which effect multicast, Multi-Topology IGPs. (vi). Forwarding Including discussions on all PIM forwarding modes, DVMPR, CBT, etc. Also includes issues associated with RP mapping approached for PIM-SM, and general discussions on ASM vs. SSM models (covering bidirectional and unidirectional status as well) (vii). Reliable Transport Including discussions on RMT generated building blocks as well as issues associated with PGM. Covers FEC, CC, etc. (viii). Session Control Will include issues associated with source and receiver control, example MSNIP, RTS/CTS issues, floor-control, etc. (ix). Application Layer Issues Examples include BCPs for writing multicast applications (e.g. RFC 3170), discussions on default address use, traffic patterns (example implications of bursty traffic, low frequency traffic), and APIs for SSM. (x). Tunneling Including any potential new dynamic tunneling proposals which come from Last Mile Multicast, etc. (xi). VPN Both L2 (pwe3, l2vpn), and L3 (ppvpn, l3vpn) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 11:16:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06930 for ; Thu, 10 Jul 2003 11:16:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad9M-0000rG-OQ; Thu, 10 Jul 2003 11:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad8P-0000eE-Eo for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 11:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06746 for ; Thu, 10 Jul 2003 11:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ad8O-0003qh-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:15:00 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19ad8N-0003pS-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:14:59 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h6AF7D3j029379; Thu, 10 Jul 2003 11:07:13 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h6AFE6Xs005213; Thu, 10 Jul 2003 11:14:10 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h6AFEBl26071; Thu, 10 Jul 2003 08:14:11 -0700 (PDT) Message-Id: <200307101514.h6AFEBl26071@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: joelja@darkwing.uoregon.edu Subject: Re: [Mtp] the more things change, the more they stay the same Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 08:14:10 -0700 >except that it's hasn't in practice because we have two things that w e >than have to evolve in parallel. Indeed. However, look at how long it's taking to get from IGMPv2 to IGMPv3 stacks. At the time that IGMPv2 was the "sweet spot" of IGMP, i.e. the time that all that implementation and deployment was happening, DVMRP was the "sweet spot" of routing protocols -- PIM was this bright new opportunity poking its head over the horizon and MOSPF was much more well developed. If the host<>router communication was the routing protocol, all of the end routers would *still* be trying to talk DVMRP to the hosts, and there would be a tiny minority that talked PIM, even though PIM is ubiquitous in the network and there are no significant bits of DVMRP routing. Now, just because it made sense in the past doesn't mean that it still makes sense now -- maybe PIM is the end-all and be-all and that's all we should care about. But it seems unlikely to me that a) revving routing protocols in the host is any easier than revving IGMP in the host. b) PIM is the only routing protocol we ever want to have. Maybe the problem with IGMP was that it was implemented in the kernel, and we should have let the kernel collect the membership information, reference-count sockets and program the multicast filter and such but then it should have notified a daemon of the memberships and the daemon could talk whatever protocol is needed. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 11:16:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06932 for ; Thu, 10 Jul 2003 11:16:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad9X-0000ua-D5 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 11:16:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AFGBce003492 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 11:16:11 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad9M-0000rG-OQ; Thu, 10 Jul 2003 11:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ad8P-0000eE-Eo for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 11:15:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06746 for ; Thu, 10 Jul 2003 11:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ad8O-0003qh-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:15:00 -0400 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19ad8N-0003pS-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:14:59 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id h6AF7D3j029379; Thu, 10 Jul 2003 11:07:13 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h6AFE6Xs005213; Thu, 10 Jul 2003 11:14:10 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h6AFEBl26071; Thu, 10 Jul 2003 08:14:11 -0700 (PDT) Message-Id: <200307101514.h6AFEBl26071@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: joelja@darkwing.uoregon.edu Subject: Re: [Mtp] the more things change, the more they stay the same Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 08:14:10 -0700 >except that it's hasn't in practice because we have two things that w e >than have to evolve in parallel. Indeed. However, look at how long it's taking to get from IGMPv2 to IGMPv3 stacks. At the time that IGMPv2 was the "sweet spot" of IGMP, i.e. the time that all that implementation and deployment was happening, DVMRP was the "sweet spot" of routing protocols -- PIM was this bright new opportunity poking its head over the horizon and MOSPF was much more well developed. If the host<>router communication was the routing protocol, all of the end routers would *still* be trying to talk DVMRP to the hosts, and there would be a tiny minority that talked PIM, even though PIM is ubiquitous in the network and there are no significant bits of DVMRP routing. Now, just because it made sense in the past doesn't mean that it still makes sense now -- maybe PIM is the end-all and be-all and that's all we should care about. But it seems unlikely to me that a) revving routing protocols in the host is any easier than revving IGMP in the host. b) PIM is the only routing protocol we ever want to have. Maybe the problem with IGMP was that it was implemented in the kernel, and we should have let the kernel collect the membership information, reference-count sockets and program the multicast filter and such but then it should have notified a daemon of the memberships and the daemon could talk whatever protocol is needed. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 12:11:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09144 for ; Thu, 10 Jul 2003 12:11:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0d-0005Lv-SA; Thu, 10 Jul 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMVy-0007DI-TM for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:30:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23112 for ; Wed, 9 Jul 2003 17:30:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMVw-0003lG-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:30:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19aMVv-0003lD-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:30:11 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h69LU91J015729; Wed, 9 Jul 2003 15:30:09 -0600 (MDT) Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h69LTss19167; Wed, 9 Jul 2003 17:29:54 -0400 (EDT) Message-Id: <200307092129.h69LTss19167@sydney.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Mtp] the more things change, the more they stay the same To: dino@procket.com, dmm@1-4-5.net Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: V4hF2YpCPES1eLFtUjh7xg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:29:54 -0400 (EDT) Dave Meyer said: >>a more general way >> to solve the problem (rather than cooking up a yet >> another special purpose solution for this case). What do you mean by "more general way"? Something that would be useful for more than multicast? Something that would be useful for more than SSM style multicast? I'm trying to get people to be specific rather than using vague terms like "not architecturally pure" or "yet another special purpose mechanism", that sound pejorative, yet don't really convey information. And Joel said: >>It was never clear to me why a host to router signaling mechanism had >>to be different from the router to router signaling mechanism. Yes, I agree with this. The fewer protocols that need to be defined, the better. Radia _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 12:11:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09148 for ; Thu, 10 Jul 2003 12:11:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0e-0005M3-Cb; Thu, 10 Jul 2003 12:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMrz-0001Ie-7W for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:52:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24155 for ; Wed, 9 Jul 2003 17:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMrw-00046z-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:52:56 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aMrv-00046r-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:52:55 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h69LqnDu026215 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 14:52:49 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Lorenzo Vicisano cc: David Meyer , , , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709142820.E1057@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:52:46 -0700 (PDT) On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > > > It was never clear to me why a host to router signaling mechanism had > > to be different from the router to router signaling mechanism. > > one reason is because a host just needs to signal that is wants to > receive multicast on a link, while a router cooperates with other > routers to forward multicast in some optimized way. Hence the > statement "I want to receive from this link" is typically not > sufficient. so why can't I just send an s,g join towards s using pim instead of nicely using igmp to get my first hop router to do it for me? > Lorenzo > > > > > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > > > > I guess the more things change, the more they stay the > > > same. > > > > > > So another thing occurred to me while reading the > > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > > are we defining yet another ad-hoc signaling protocol > > > (that is one way to looks at these proposals)? The IETF > > > literature is littered with signaling proposals, some > > > host-based, some router-based, at varying degrees of > > > generality. > > > > > > Straw person: why not have the host send a PATH message > > > towards the source (since it knows the source) and have > > > the first multicast capable router in the path send back > > > the its tunnel endpoint, have the host set up GRE (or > > > user space encap) to that router and ... > > > > > > What I am suggesting is we really don't have a general > > > purpose host-to-router signaling protocol (well, > > > maybe). So if we pick one of the current drafts (or a > > > hybrid, or even new), will we have to build a new > > > signaling infrastructure for the next feature not > > > supported by the directly connected routers? > > > > > > Seems like we should be able to answer this question in a > > > more general way than is done in these drafts. > > > > > > Dave > > > _______________________________________________ > > > Mtp mailing list > > > Mtp@shepfarm.com > > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > > > > -- > > -------------------------------------------------------------------------- > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > resort of the scoundrel. With all due respect to an enlightened but > > inferior lexicographer I beg to submit that it is the first. > > -- Ambrose Bierce, "The Devil's Dictionary" > > > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 12:11:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09151 for ; Thu, 10 Jul 2003 12:11:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0c-0005LS-7m; Thu, 10 Jul 2003 12:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMJu-0006N3-8i for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:17:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22677 for ; Wed, 9 Jul 2003 17:17:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMJs-0003cr-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:17:44 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aMJq-0003cm-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:17:43 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h69LHfDu002409 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 14:17:41 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: David Meyer cc: mtp@shepfarm.com, , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709134733.A11761@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:17:38 -0700 (PDT) It was never clear to me why a host to router signaling mechanism had to be different from the router to router signaling mechanism. On Wed, 9 Jul 2003, David Meyer wrote: > > I guess the more things change, the more they stay the > same. > > So another thing occurred to me while reading the > Multicast Last-Mile Solutions drafts on Greg's site: Why > are we defining yet another ad-hoc signaling protocol > (that is one way to looks at these proposals)? The IETF > literature is littered with signaling proposals, some > host-based, some router-based, at varying degrees of > generality. > > Straw person: why not have the host send a PATH message > towards the source (since it knows the source) and have > the first multicast capable router in the path send back > the its tunnel endpoint, have the host set up GRE (or > user space encap) to that router and ... > > What I am suggesting is we really don't have a general > purpose host-to-router signaling protocol (well, > maybe). So if we pick one of the current drafts (or a > hybrid, or even new), will we have to build a new > signaling infrastructure for the next feature not > supported by the directly connected routers? > > Seems like we should be able to answer this question in a > more general way than is done in these drafts. > > Dave > _______________________________________________ > Mtp mailing list > Mtp@shepfarm.com > http://www.shepfarm.com/mailman/listinfo/mtp > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 12:11:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09191 for ; Thu, 10 Jul 2003 12:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0d-0005Ln-Bk; Thu, 10 Jul 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMVU-0007C8-AG for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:29:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23094 for ; Wed, 9 Jul 2003 17:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMVR-0003kl-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:42 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19aMVR-0003ka-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:41 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 6D07423C59; Wed, 9 Jul 2003 14:37:23 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h69LTBYB000491; Wed, 9 Jul 2003 14:29:11 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Jul 2003 14:29:09 -0700 From: Greg Shepherd To: David Meyer Cc: shep@shepfarm.com, , , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709142404.B12203@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 09 Jul 2003 21:29:09.0725 (UTC) FILETIME=[224560D0:01C34661] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:29:09 -0700 (PDT) On Wed, 9 Jul 2003, David Meyer wrote: > >> > So if we pick one of the current drafts (or a > >> > hybrid, or even new), will we have to build a new > >> > signaling infrastructure for the next feature not > >> > supported by the directly connected routers? > >> > >> Sorry, I don't follow.. Can you clarify? > > It would seem that the general form of this particular > deployment problem is: > > The router on directly the directly connected network, > or that router and some number of subsequent routers > in the path towards some resource, can't or won't do > . > > Now, what is being discussed here is an instantiation > for the special case of multicast (or in the case > of a few of the drafts, even narrower: SSM). > > Now, what happens when I have a different , say > ? Is what is the signaling built for useful > useful when deploying , or do I have to go build > the (new) signaling protocol? > > It's more a discussion about the Internet architecture > (in general) and less about multicast, although if we > could build something general, instantiating it with > this case (multicast) would be nice example. > > Does that help? Yup, thanks. I understood the desire for a general purpose solution, but wasn't clear whether you already had an example. I guess I was just being hopefull. ;-) Thanks again, Greg > Dave > > > _______________________________________________ > Mtp mailing list > Mtp@shepfarm.com > http://www.shepfarm.com/mailman/listinfo/mtp > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 12:11:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09203 for ; Thu, 10 Jul 2003 12:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0f-0005MJ-Ep; Thu, 10 Jul 2003 12:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNJK-0003pE-Ar for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 18:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26632 for ; Wed, 9 Jul 2003 18:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aNJH-0004VG-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:21:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aNJG-0004UG-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:21:10 -0400 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h69MKcrm015706; Wed, 9 Jul 2003 15:20:38 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-74.cisco.com [128.107.163.74]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AID70896; Wed, 9 Jul 2003 15:27:03 -0700 (PDT) Message-ID: <3F0C9535.3080308@cisco.com> From: Keyur Patel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer CC: shep@shepfarm.com, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same References: <20030709134733.A11761@1-4-5.net> <20030709142404.B12203@1-4-5.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 15:20:37 -0700 Content-Transfer-Encoding: 7bit Dave: David Meyer wrote: >>>> So if we pick one of the current drafts (or a >>>> hybrid, or even new), will we have to build a new >>>> signaling infrastructure for the next feature not >>>> supported by the directly connected routers? >>>> Single signaling infrastructure should work for SSM and ASM model. One could use well known anycast address to direct all the control traffic to a specific location within a network. -Keyur >>>> >>>> >>>Sorry, I don't follow.. Can you clarify? >>> >>> > > It would seem that the general form of this particular > deployment problem is: > > The router on directly the directly connected network, > or that router and some number of subsequent routers > in the path towards some resource, can't or won't do > . > > Now, what is being discussed here is an instantiation > for the special case of multicast (or in the case > of a few of the drafts, even narrower: SSM). > > > Now, what happens when I have a different , say > ? Is what is the signaling built for useful > useful when deploying , or do I have to go build > the (new) signaling protocol? > > It's more a discussion about the Internet architecture > (in general) and less about multicast, although if we > could build something general, instantiating it with > this case (multicast) would be nice example. > > Does that help? > > Dave > > >_______________________________________________ >Mtp mailing list >Mtp@shepfarm.com >http://www.shepfarm.com/mailman/listinfo/mtp > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 12:11:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09233 for ; Thu, 10 Jul 2003 12:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005i3-64 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKfK021209 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0d-0005Lv-SA; Thu, 10 Jul 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMVy-0007DI-TM for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:30:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23112 for ; Wed, 9 Jul 2003 17:30:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMVw-0003lG-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:30:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19aMVv-0003lD-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:30:11 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h69LU91J015729; Wed, 9 Jul 2003 15:30:09 -0600 (MDT) Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h69LTss19167; Wed, 9 Jul 2003 17:29:54 -0400 (EDT) Message-Id: <200307092129.h69LTss19167@sydney.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Mtp] the more things change, the more they stay the same To: dino@procket.com, dmm@1-4-5.net Cc: wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: V4hF2YpCPES1eLFtUjh7xg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:29:54 -0400 (EDT) Dave Meyer said: >>a more general way >> to solve the problem (rather than cooking up a yet >> another special purpose solution for this case). What do you mean by "more general way"? Something that would be useful for more than multicast? Something that would be useful for more than SSM style multicast? I'm trying to get people to be specific rather than using vague terms like "not architecturally pure" or "yet another special purpose mechanism", that sound pejorative, yet don't really convey information. And Joel said: >>It was never clear to me why a host to router signaling mechanism had >>to be different from the router to router signaling mechanism. Yes, I agree with this. The fewer protocols that need to be defined, the better. Radia _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 12:11:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09229 for ; Thu, 10 Jul 2003 12:11:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005h2-1K for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKBV021211 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0c-0005La-Oi; Thu, 10 Jul 2003 12:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMUz-0007C1-QZ for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:29:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23091 for ; Wed, 9 Jul 2003 17:29:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMUx-0003kZ-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:11 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19aMUw-0003jy-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:10 -0400 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h69LSLpp002909; Wed, 9 Jul 2003 14:28:22 -0700 (PDT) Received: (from lorenzo@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA10800; Wed, 9 Jul 2003 14:28:21 -0700 (PDT) From: Lorenzo Vicisano To: Joel Jaeggli Cc: David Meyer , mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709142820.E1057@cisco.com> References: <20030709134733.A11761@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:28:20 -0700 On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > It was never clear to me why a host to router signaling mechanism had > to be different from the router to router signaling mechanism. one reason is because a host just needs to signal that is wants to receive multicast on a link, while a router cooperates with other routers to forward multicast in some optimized way. Hence the statement "I want to receive from this link" is typically not sufficient. Lorenzo > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > I guess the more things change, the more they stay the > > same. > > > > So another thing occurred to me while reading the > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > are we defining yet another ad-hoc signaling protocol > > (that is one way to looks at these proposals)? The IETF > > literature is littered with signaling proposals, some > > host-based, some router-based, at varying degrees of > > generality. > > > > Straw person: why not have the host send a PATH message > > towards the source (since it knows the source) and have > > the first multicast capable router in the path send back > > the its tunnel endpoint, have the host set up GRE (or > > user space encap) to that router and ... > > > > What I am suggesting is we really don't have a general > > purpose host-to-router signaling protocol (well, > > maybe). So if we pick one of the current drafts (or a > > hybrid, or even new), will we have to build a new > > signaling infrastructure for the next feature not > > supported by the directly connected routers? > > > > Seems like we should be able to answer this question in a > > more general way than is done in these drafts. > > > > Dave > > _______________________________________________ > > Mtp mailing list > > Mtp@shepfarm.com > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > -- > -------------------------------------------------------------------------- > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > In Dr. Johnson's famous dictionary patriotism is defined as the last > resort of the scoundrel. With all due respect to an enlightened but > inferior lexicographer I beg to submit that it is the first. > -- Ambrose Bierce, "The Devil's Dictionary" > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 12:11:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09228 for ; Thu, 10 Jul 2003 12:11:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0v-0005dt-O1 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKGr021193 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0e-0005M3-Cb; Thu, 10 Jul 2003 12:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMrz-0001Ie-7W for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:52:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24155 for ; Wed, 9 Jul 2003 17:52:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMrw-00046z-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:52:56 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aMrv-00046r-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:52:55 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h69LqnDu026215 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 14:52:49 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Lorenzo Vicisano cc: David Meyer , , , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709142820.E1057@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:52:46 -0700 (PDT) On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > > > It was never clear to me why a host to router signaling mechanism had > > to be different from the router to router signaling mechanism. > > one reason is because a host just needs to signal that is wants to > receive multicast on a link, while a router cooperates with other > routers to forward multicast in some optimized way. Hence the > statement "I want to receive from this link" is typically not > sufficient. so why can't I just send an s,g join towards s using pim instead of nicely using igmp to get my first hop router to do it for me? > Lorenzo > > > > > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > > > > I guess the more things change, the more they stay the > > > same. > > > > > > So another thing occurred to me while reading the > > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > > are we defining yet another ad-hoc signaling protocol > > > (that is one way to looks at these proposals)? The IETF > > > literature is littered with signaling proposals, some > > > host-based, some router-based, at varying degrees of > > > generality. > > > > > > Straw person: why not have the host send a PATH message > > > towards the source (since it knows the source) and have > > > the first multicast capable router in the path send back > > > the its tunnel endpoint, have the host set up GRE (or > > > user space encap) to that router and ... > > > > > > What I am suggesting is we really don't have a general > > > purpose host-to-router signaling protocol (well, > > > maybe). So if we pick one of the current drafts (or a > > > hybrid, or even new), will we have to build a new > > > signaling infrastructure for the next feature not > > > supported by the directly connected routers? > > > > > > Seems like we should be able to answer this question in a > > > more general way than is done in these drafts. > > > > > > Dave > > > _______________________________________________ > > > Mtp mailing list > > > Mtp@shepfarm.com > > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > > > > -- > > -------------------------------------------------------------------------- > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > resort of the scoundrel. With all due respect to an enlightened but > > inferior lexicographer I beg to submit that it is the first. > > -- Ambrose Bierce, "The Devil's Dictionary" > > > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 12:11:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09279 for ; Thu, 10 Jul 2003 12:11:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0j-0005UP-1B; Thu, 10 Jul 2003 12:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ads6-0004PQ-Fe for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 12:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08764 for ; Thu, 10 Jul 2003 12:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ads4-0004Jy-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:02:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19ads3-0004Jp-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:02:11 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6AG22bI009194; Thu, 10 Jul 2003 10:02:02 -0600 (MDT) Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h6AG21s29103; Thu, 10 Jul 2003 12:02:01 -0400 (EDT) Message-Id: <200307101602.h6AG21s29103@sydney.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Mtp] the more things change, the more they stay the same To: lorenzo@cisco.com, pusateri@juniper.net Cc: mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org, wg-multicast@internet2.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LTmDkVCOZJAYD8QADsgdrg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 12:02:01 -0400 (EDT) Re Tom Pusateri's note: >the characteristics of the signaling should be decided first >and then we can determine if an existing protocol will fit our needs. Yes, exactly! The characteristics I would like to see are: a. Host application can send join requests without any special privileges on the largest variety of operating systems. This speeds deployment and puts users in control without having to get approval from Administrators. This dictates that the protocol be UDP or TCP based. Can an application send a UDP or TCP based packet with router alert in the IP header without special privileges? I believe the packet needs to have router alert on in order for it to have destination address=a unicast address (so non-multicast routers will forward it normally). If router alert needs to be on, then I suspect the daemon will have to have privileges on the host, and there's no reason for a UDP or TCP header since it will have to be using raw sockets. 2. Don't make encapsulation a requirement. This complicates the host implementation requiring it to decapsulate. While this may be one way to get the multicast to the hosts, simply having servers sit at the edge of a network and replicating a multicast stream to a bunch of hosts by replacing the multicast destination address with the hosts unicast address eliminates much complication from the host application. It simply sees a regular UDP unicast stream coming in. Perhaps, though you can't simply remove "G" from the header. It has to be preserved somewhere. So perhaps data should have a multicast header after or instead of the UDP header that contains G, the tree root perhaps, whatever else might be considered important. And then the encoding need not be IP in IP tunneling. 3. The address the join is sent to should be specified the same way as the group and the source address is learned. This will likely be in the SDP description. The join address may in fact be the source, or it may be an anycast address or some other invention. But we're free to try different approaches and we don't lock ourselves in. If the group is (S,G) then that meets what you're saying. If the group is just G, then there could be a global constant anycast address (and you have to make sure someone in your domain is advertising that address). Or perhaps it could be a configuration parameter on the endnode (what anycast address to use for joining groups in general (even SSM groups), or specifically just for ASM groups. 4. The join should use the router alert option in the IP header. This will allow routers along the path from the receiver to the source to process the unicast join or send it to a server it knows about. Ah yes. That was why I thought it would have to be raw sockets, and not just an unprivileged UDP/TCP application. So is this in fact possible? Radia _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 12:13:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09575 for ; Thu, 10 Jul 2003 12:13:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005i7-7c for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKXb021195 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0f-0005MJ-Ep; Thu, 10 Jul 2003 12:11:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aNJK-0003pE-Ar for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 18:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26632 for ; Wed, 9 Jul 2003 18:21:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aNJH-0004VG-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:21:11 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aNJG-0004UG-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:21:10 -0400 Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h69MKcrm015706; Wed, 9 Jul 2003 15:20:38 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-74.cisco.com [128.107.163.74]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AID70896; Wed, 9 Jul 2003 15:27:03 -0700 (PDT) Message-ID: <3F0C9535.3080308@cisco.com> From: Keyur Patel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer CC: shep@shepfarm.com, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same References: <20030709134733.A11761@1-4-5.net> <20030709142404.B12203@1-4-5.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 09 Jul 2003 15:20:37 -0700 Content-Transfer-Encoding: 7bit Dave: David Meyer wrote: >>>> So if we pick one of the current drafts (or a >>>> hybrid, or even new), will we have to build a new >>>> signaling infrastructure for the next feature not >>>> supported by the directly connected routers? >>>> Single signaling infrastructure should work for SSM and ASM model. One could use well known anycast address to direct all the control traffic to a specific location within a network. -Keyur >>>> >>>> >>>Sorry, I don't follow.. Can you clarify? >>> >>> > > It would seem that the general form of this particular > deployment problem is: > > The router on directly the directly connected network, > or that router and some number of subsequent routers > in the path towards some resource, can't or won't do > . > > Now, what is being discussed here is an instantiation > for the special case of multicast (or in the case > of a few of the drafts, even narrower: SSM). > > > Now, what happens when I have a different , say > ? Is what is the signaling built for useful > useful when deploying , or do I have to go build > the (new) signaling protocol? > > It's more a discussion about the Internet architecture > (in general) and less about multicast, although if we > could build something general, instantiating it with > this case (multicast) would be nice example. > > Does that help? > > Dave > > >_______________________________________________ >Mtp mailing list >Mtp@shepfarm.com >http://www.shepfarm.com/mailman/listinfo/mtp > > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 12:14:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09695 for ; Thu, 10 Jul 2003 12:14:05 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005i6-6y for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKR4021194 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0g-0005MR-33; Thu, 10 Jul 2003 12:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOjl-0002Vd-9O for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 19:52:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29546 for ; Wed, 9 Jul 2003 19:52:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOjj-0005Pp-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 19:52:35 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aOji-0005Pm-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 19:52:34 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h69NqSDu022296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 16:52:28 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Lorenzo Vicisano cc: David Meyer , , , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709150622.F1057@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 16:52:24 -0700 (PDT) On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: > > because you, the host, would have to have routing information to find > out who the 1st hop towards the source is... Do situations exist where a host that isn't running an igp or egp has multiple first hop routers available on the interface that it's default route is pointing out (excluding the special case of hsrp)? > you would also have to > take part to the PIM routing protocol to find out who's responsible to > forward in your lan for that source. yes > Lorenzo > > > > > > Lorenzo > > > > > > > > > > > > > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > > > > > > > > > > I guess the more things change, the more they stay the > > > > > same. > > > > > > > > > > So another thing occurred to me while reading the > > > > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > > > > are we defining yet another ad-hoc signaling protocol > > > > > (that is one way to looks at these proposals)? The IETF > > > > > literature is littered with signaling proposals, some > > > > > host-based, some router-based, at varying degrees of > > > > > generality. > > > > > > > > > > Straw person: why not have the host send a PATH message > > > > > towards the source (since it knows the source) and have > > > > > the first multicast capable router in the path send back > > > > > the its tunnel endpoint, have the host set up GRE (or > > > > > user space encap) to that router and ... > > > > > > > > > > What I am suggesting is we really don't have a general > > > > > purpose host-to-router signaling protocol (well, > > > > > maybe). So if we pick one of the current drafts (or a > > > > > hybrid, or even new), will we have to build a new > > > > > signaling infrastructure for the next feature not > > > > > supported by the directly connected routers? > > > > > > > > > > Seems like we should be able to answer this question in a > > > > > more general way than is done in these drafts. > > > > > > > > > > Dave > > > > > _______________________________________________ > > > > > Mtp mailing list > > > > > Mtp@shepfarm.com > > > > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > > > > > > > > > > -- > > > > -------------------------------------------------------------------------- > > > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > > > resort of the scoundrel. With all due respect to an enlightened but > > > > inferior lexicographer I beg to submit that it is the first. > > > > -- Ambrose Bierce, "The Devil's Dictionary" > > > > > > > > > > > -- > > -------------------------------------------------------------------------- > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > resort of the scoundrel. With all due respect to an enlightened but > > inferior lexicographer I beg to submit that it is the first. > > -- Ambrose Bierce, "The Devil's Dictionary" > > > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 12:32:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10901 for ; Thu, 10 Jul 2003 12:32:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeKv-0007v8-Rl; Thu, 10 Jul 2003 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeFg-0007nw-9R for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 12:26:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10695 for ; Thu, 10 Jul 2003 12:26:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aeFe-0004n0-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:26:34 -0400 Received: from bay8-dav23.bay8.hotmail.com ([64.4.26.80] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19aeFd-0004mx-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:26:34 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Jul 2003 09:26:02 -0700 Received: from 156.106.205.10 by bay8-dav23.bay8.hotmail.com with DAV; Thu, 10 Jul 2003 16:26:01 +0000 X-Originating-IP: [156.106.205.10] X-Originating-Email: [sjkoh12@hotmail.com] From: "Seok Joo Koh" To: "David Meyer" , Cc: , , References: <20030710075612.A17872@1-4-5.net> Subject: Re: [Mtp] Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: X-OriginalArrivalTime: 10 Jul 2003 16:26:02.0222 (UTC) FILETIME=[F41668E0:01C346FF] Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 01:26:47 +0900 Content-Transfer-Encoding: 7bit Dave, Sounds great and a brief question below. > (ix). Application Layer Issues > > Examples include BCPs for writing multicast > applications (e.g. RFC 3170), discussions on > default address use, traffic patterns (example > implications of bursty traffic, low frequency > traffic), and APIs for SSM. > > (x). Tunneling > > Including any potential new dynamic tunneling > proposals which come from Last Mile Multicast, etc. > Don't we need to include Overlay Multicast (or Application-Level Multicast) as an example ? I think it could be considered as an enhancement of the traditional IP multicast model, and it may also address the tunneling issue described above. Overlay multicast may be considered as an inter-domain multicast scheme, in which each domain uses ASM or SSM, and the unicast (tunnelled or not) will be used between different domains. In overlay multicast model, the control (or signaling) messages will be based on the UDP/TCP transport. Thanks, Seok J. Koh _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 12:32:39 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10916 for ; Thu, 10 Jul 2003 12:32:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeL7-0007wR-SA for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:32:14 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGWDp5030506 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:32:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeKv-0007v8-Rl; Thu, 10 Jul 2003 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeFg-0007nw-9R for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 12:26:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10695 for ; Thu, 10 Jul 2003 12:26:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aeFe-0004n0-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:26:34 -0400 Received: from bay8-dav23.bay8.hotmail.com ([64.4.26.80] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 19aeFd-0004mx-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:26:34 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 10 Jul 2003 09:26:02 -0700 Received: from 156.106.205.10 by bay8-dav23.bay8.hotmail.com with DAV; Thu, 10 Jul 2003 16:26:01 +0000 X-Originating-IP: [156.106.205.10] X-Originating-Email: [sjkoh12@hotmail.com] From: "Seok Joo Koh" To: "David Meyer" , Cc: , , References: <20030710075612.A17872@1-4-5.net> Subject: Re: [Mtp] Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: X-OriginalArrivalTime: 10 Jul 2003 16:26:02.0222 (UTC) FILETIME=[F41668E0:01C346FF] Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 01:26:47 +0900 Content-Transfer-Encoding: 7bit Dave, Sounds great and a brief question below. > (ix). Application Layer Issues > > Examples include BCPs for writing multicast > applications (e.g. RFC 3170), discussions on > default address use, traffic patterns (example > implications of bursty traffic, low frequency > traffic), and APIs for SSM. > > (x). Tunneling > > Including any potential new dynamic tunneling > proposals which come from Last Mile Multicast, etc. > Don't we need to include Overlay Multicast (or Application-Level Multicast) as an example ? I think it could be considered as an enhancement of the traditional IP multicast model, and it may also address the tunneling issue described above. Overlay multicast may be considered as an inter-domain multicast scheme, in which each domain uses ASM or SSM, and the unicast (tunnelled or not) will be used between different domains. In overlay multicast model, the control (or signaling) messages will be based on the UDP/TCP transport. Thanks, Seok J. Koh _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 13:01:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09143 for ; Thu, 10 Jul 2003 12:11:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0i-0005Tb-Dn; Thu, 10 Jul 2003 12:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adK8-0001Rq-19 for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 11:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07340 for ; Thu, 10 Jul 2003 11:27:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adK5-0003zO-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:27:06 -0400 Received: from cefni.aber.ac.uk ([144.124.16.40]) by ietf-mx with esmtp (Exim 4.12) id 19adK5-0003zG-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=cefni.aber.ac.uk) by cefni.aber.ac.uk with esmtp (Exim 3.35 #3) id 19adJo-0007s9-02; Thu, 10 Jul 2003 16:26:48 +0100 Received: from moin.dcs.aber.ac.uk ([193.60.11.36] helo=aber.ac.uk) by cefni.aber.ac.uk with esmtp (Exim 3.35 #3) id 19adJW-0007o5-02; Thu, 10 Jul 2003 16:26:30 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: David Meyer cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org, dap@aber.ac.uk From: Dave Price Subject: Re: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? In-reply-to: Your message of Thu, 10 Jul 2003 07:56:12 -0700. <20030710075612.A17872@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <5013.1057850790@aber.ac.uk> X-Sophos-Scanned: from dap@aber.ac.uk virus scanned OK X-UWA-Mid: 19adJW-0007o5-02 X-UWA-Originating-IP: 193.60.11.36 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 16:26:30 +0100 Dear All, dmm@1-4-5.net said: > Here's something I've been discussing with the ADs > (and hoping to learn the lessons of the MADDOGs > "experience"). > I put it on the mboned agenda, so we can also discuss this > there. As always, comments greatly appreciated. excellent. I'll not be at the meeting, but this proposal strikes me as a really good idea. Dave Price -- Dave Price, Technical Director, Telematics Group Email: dap@aber.ac.uk PHONE: +44 1970 622428 FAX: +44 1970 622455 Post: Computer Science, University of Wales, Penglais, Aberystwyth, WALES, UK, SY23 3DB. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:01:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09269 for ; Thu, 10 Jul 2003 12:11:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005hh-3z for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKJc021189 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0i-0005Tb-Dn; Thu, 10 Jul 2003 12:11:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19adK8-0001Rq-19 for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 11:27:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07340 for ; Thu, 10 Jul 2003 11:27:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19adK5-0003zO-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:27:06 -0400 Received: from cefni.aber.ac.uk ([144.124.16.40]) by ietf-mx with esmtp (Exim 4.12) id 19adK5-0003zG-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 11:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=cefni.aber.ac.uk) by cefni.aber.ac.uk with esmtp (Exim 3.35 #3) id 19adJo-0007s9-02; Thu, 10 Jul 2003 16:26:48 +0100 Received: from moin.dcs.aber.ac.uk ([193.60.11.36] helo=aber.ac.uk) by cefni.aber.ac.uk with esmtp (Exim 3.35 #3) id 19adJW-0007o5-02; Thu, 10 Jul 2003 16:26:30 +0100 X-Mailer: exmh version 2.0.2 2/24/98 To: David Meyer cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org, dap@aber.ac.uk From: Dave Price Subject: Re: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? In-reply-to: Your message of Thu, 10 Jul 2003 07:56:12 -0700. <20030710075612.A17872@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <5013.1057850790@aber.ac.uk> X-Sophos-Scanned: from dap@aber.ac.uk virus scanned OK X-UWA-Mid: 19adJW-0007o5-02 X-UWA-Originating-IP: 193.60.11.36 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 16:26:30 +0100 Dear All, dmm@1-4-5.net said: > Here's something I've been discussing with the ADs > (and hoping to learn the lessons of the MADDOGs > "experience"). > I put it on the mboned agenda, so we can also discuss this > there. As always, comments greatly appreciated. excellent. I'll not be at the meeting, but this proposal strikes me as a really good idea. Dave Price -- Dave Price, Technical Director, Telematics Group Email: dap@aber.ac.uk PHONE: +44 1970 622428 FAX: +44 1970 622455 Post: Computer Science, University of Wales, Penglais, Aberystwyth, WALES, UK, SY23 3DB. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 13:01:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09145 for ; Thu, 10 Jul 2003 12:11:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0g-0005MZ-NQ; Thu, 10 Jul 2003 12:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aPIp-0005Bj-JN for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 20:28:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00644 for ; Wed, 9 Jul 2003 20:28:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aPIn-0005h1-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:28:49 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aPIm-0005gy-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:28:48 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h6A0SlDu013377 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 17:28:47 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Bill Fenner cc: wg-multicast@internet2.edu, , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <200307100004.h6A04GZ18656@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:28:42 -0700 (PDT) On Wed, 9 Jul 2003, Bill Fenner wrote: > > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > > > It was never clear to me why a host to router signaling mechanism had > > to be different from the router to router signaling mechanism. > > Here's one reason: because if we had this conversation in 1993 we > would have made the host to router signalling mechanism DVMRP, or > maybe we would have been looking toward the future and made it MOSPF. > > The generalization of that is the goal is to be able to evolve > the routing protocol independently of the host<>router interface. > Since there are orders of magnitudes more hosts to change than > routers when a protocol changes, this theoretically makes the > infrastructure more able to change piecemeal. except that it's hasn't in practice because we have two things that w e than have to evolve in parallel. > Bill > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:01:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09204 for ; Thu, 10 Jul 2003 12:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0v-0005cE-AL for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKVd021192 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0g-0005MZ-NQ; Thu, 10 Jul 2003 12:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aPIp-0005Bj-JN for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 20:28:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00644 for ; Wed, 9 Jul 2003 20:28:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aPIn-0005h1-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:28:49 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aPIm-0005gy-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 20:28:48 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h6A0SlDu013377 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 17:28:47 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Bill Fenner cc: wg-multicast@internet2.edu, , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <200307100004.h6A04GZ18656@windsor.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 17:28:42 -0700 (PDT) On Wed, 9 Jul 2003, Bill Fenner wrote: > > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > > > It was never clear to me why a host to router signaling mechanism had > > to be different from the router to router signaling mechanism. > > Here's one reason: because if we had this conversation in 1993 we > would have made the host to router signalling mechanism DVMRP, or > maybe we would have been looking toward the future and made it MOSPF. > > The generalization of that is the goal is to be able to evolve > the routing protocol independently of the host<>router interface. > Since there are orders of magnitudes more hosts to change than > routers when a protocol changes, this theoretically makes the > infrastructure more able to change piecemeal. except that it's hasn't in practice because we have two things that w e than have to evolve in parallel. > Bill > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:01:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09238 for ; Thu, 10 Jul 2003 12:11:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005hz-5R for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKob021214 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0d-0005Ln-Bk; Thu, 10 Jul 2003 12:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMVU-0007C8-AG for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:29:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23094 for ; Wed, 9 Jul 2003 17:29:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMVR-0003kl-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:42 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19aMVR-0003ka-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:41 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 6D07423C59; Wed, 9 Jul 2003 14:37:23 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h69LTBYB000491; Wed, 9 Jul 2003 14:29:11 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 9 Jul 2003 14:29:09 -0700 From: Greg Shepherd To: David Meyer Cc: shep@shepfarm.com, , , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709142404.B12203@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 09 Jul 2003 21:29:09.0725 (UTC) FILETIME=[224560D0:01C34661] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:29:09 -0700 (PDT) On Wed, 9 Jul 2003, David Meyer wrote: > >> > So if we pick one of the current drafts (or a > >> > hybrid, or even new), will we have to build a new > >> > signaling infrastructure for the next feature not > >> > supported by the directly connected routers? > >> > >> Sorry, I don't follow.. Can you clarify? > > It would seem that the general form of this particular > deployment problem is: > > The router on directly the directly connected network, > or that router and some number of subsequent routers > in the path towards some resource, can't or won't do > . > > Now, what is being discussed here is an instantiation > for the special case of multicast (or in the case > of a few of the drafts, even narrower: SSM). > > Now, what happens when I have a different , say > ? Is what is the signaling built for useful > useful when deploying , or do I have to go build > the (new) signaling protocol? > > It's more a discussion about the Internet architecture > (in general) and less about multicast, although if we > could build something general, instantiating it with > this case (multicast) would be nice example. > > Does that help? Yup, thanks. I understood the desire for a general purpose solution, but wasn't clear whether you already had an example. I guess I was just being hopefull. ;-) Thanks again, Greg > Dave > > > _______________________________________________ > Mtp mailing list > Mtp@shepfarm.com > http://www.shepfarm.com/mailman/listinfo/mtp > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:01:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09206 for ; Thu, 10 Jul 2003 12:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0w-0005gI-SA for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKG5021188 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0c-0005LS-7m; Thu, 10 Jul 2003 12:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMJu-0006N3-8i for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:17:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22677 for ; Wed, 9 Jul 2003 17:17:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMJs-0003cr-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:17:44 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aMJq-0003cm-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:17:43 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h69LHfDu002409 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 14:17:41 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: David Meyer cc: mtp@shepfarm.com, , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709134733.A11761@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:17:38 -0700 (PDT) It was never clear to me why a host to router signaling mechanism had to be different from the router to router signaling mechanism. On Wed, 9 Jul 2003, David Meyer wrote: > > I guess the more things change, the more they stay the > same. > > So another thing occurred to me while reading the > Multicast Last-Mile Solutions drafts on Greg's site: Why > are we defining yet another ad-hoc signaling protocol > (that is one way to looks at these proposals)? The IETF > literature is littered with signaling proposals, some > host-based, some router-based, at varying degrees of > generality. > > Straw person: why not have the host send a PATH message > towards the source (since it knows the source) and have > the first multicast capable router in the path send back > the its tunnel endpoint, have the host set up GRE (or > user space encap) to that router and ... > > What I am suggesting is we really don't have a general > purpose host-to-router signaling protocol (well, > maybe). So if we pick one of the current drafts (or a > hybrid, or even new), will we have to build a new > signaling infrastructure for the next feature not > supported by the directly connected routers? > > Seems like we should be able to answer this question in a > more general way than is done in these drafts. > > Dave > _______________________________________________ > Mtp mailing list > Mtp@shepfarm.com > http://www.shepfarm.com/mailman/listinfo/mtp > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 13:01:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09199 for ; Thu, 10 Jul 2003 12:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0c-0005La-Oi; Thu, 10 Jul 2003 12:11:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aMUz-0007C1-QZ for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 17:29:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23091 for ; Wed, 9 Jul 2003 17:29:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aMUx-0003kZ-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:11 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19aMUw-0003jy-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 17:29:10 -0400 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h69LSLpp002909; Wed, 9 Jul 2003 14:28:22 -0700 (PDT) Received: (from lorenzo@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA10800; Wed, 9 Jul 2003 14:28:21 -0700 (PDT) From: Lorenzo Vicisano To: Joel Jaeggli Cc: David Meyer , mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709142820.E1057@cisco.com> References: <20030709134733.A11761@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 14:28:20 -0700 On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > It was never clear to me why a host to router signaling mechanism had > to be different from the router to router signaling mechanism. one reason is because a host just needs to signal that is wants to receive multicast on a link, while a router cooperates with other routers to forward multicast in some optimized way. Hence the statement "I want to receive from this link" is typically not sufficient. Lorenzo > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > I guess the more things change, the more they stay the > > same. > > > > So another thing occurred to me while reading the > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > are we defining yet another ad-hoc signaling protocol > > (that is one way to looks at these proposals)? The IETF > > literature is littered with signaling proposals, some > > host-based, some router-based, at varying degrees of > > generality. > > > > Straw person: why not have the host send a PATH message > > towards the source (since it knows the source) and have > > the first multicast capable router in the path send back > > the its tunnel endpoint, have the host set up GRE (or > > user space encap) to that router and ... > > > > What I am suggesting is we really don't have a general > > purpose host-to-router signaling protocol (well, > > maybe). So if we pick one of the current drafts (or a > > hybrid, or even new), will we have to build a new > > signaling infrastructure for the next feature not > > supported by the directly connected routers? > > > > Seems like we should be able to answer this question in a > > more general way than is done in these drafts. > > > > Dave > > _______________________________________________ > > Mtp mailing list > > Mtp@shepfarm.com > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > -- > -------------------------------------------------------------------------- > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > In Dr. Johnson's famous dictionary patriotism is defined as the last > resort of the scoundrel. With all due respect to an enlightened but > inferior lexicographer I beg to submit that it is the first. > -- Ambrose Bierce, "The Devil's Dictionary" > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:01:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09257 for ; Thu, 10 Jul 2003 12:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005hU-3Q for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKWf021215 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0j-0005UP-1B; Thu, 10 Jul 2003 12:11:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ads6-0004PQ-Fe for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 12:02:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08764 for ; Thu, 10 Jul 2003 12:02:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ads4-0004Jy-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:02:12 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19ads3-0004Jp-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 12:02:11 -0400 Received: from sydney.East.Sun.COM ([129.148.9.16]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h6AG22bI009194; Thu, 10 Jul 2003 10:02:02 -0600 (MDT) Received: from sr1-ubur-05 (sr1-ubur-05 [129.148.9.84]) by sydney.East.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with SMTP id h6AG21s29103; Thu, 10 Jul 2003 12:02:01 -0400 (EDT) Message-Id: <200307101602.h6AG21s29103@sydney.East.Sun.COM> From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: [Mtp] the more things change, the more they stay the same To: lorenzo@cisco.com, pusateri@juniper.net Cc: mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org, wg-multicast@internet2.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LTmDkVCOZJAYD8QADsgdrg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 12:02:01 -0400 (EDT) Re Tom Pusateri's note: >the characteristics of the signaling should be decided first >and then we can determine if an existing protocol will fit our needs. Yes, exactly! The characteristics I would like to see are: a. Host application can send join requests without any special privileges on the largest variety of operating systems. This speeds deployment and puts users in control without having to get approval from Administrators. This dictates that the protocol be UDP or TCP based. Can an application send a UDP or TCP based packet with router alert in the IP header without special privileges? I believe the packet needs to have router alert on in order for it to have destination address=a unicast address (so non-multicast routers will forward it normally). If router alert needs to be on, then I suspect the daemon will have to have privileges on the host, and there's no reason for a UDP or TCP header since it will have to be using raw sockets. 2. Don't make encapsulation a requirement. This complicates the host implementation requiring it to decapsulate. While this may be one way to get the multicast to the hosts, simply having servers sit at the edge of a network and replicating a multicast stream to a bunch of hosts by replacing the multicast destination address with the hosts unicast address eliminates much complication from the host application. It simply sees a regular UDP unicast stream coming in. Perhaps, though you can't simply remove "G" from the header. It has to be preserved somewhere. So perhaps data should have a multicast header after or instead of the UDP header that contains G, the tree root perhaps, whatever else might be considered important. And then the encoding need not be IP in IP tunneling. 3. The address the join is sent to should be specified the same way as the group and the source address is learned. This will likely be in the SDP description. The join address may in fact be the source, or it may be an anycast address or some other invention. But we're free to try different approaches and we don't lock ourselves in. If the group is (S,G) then that meets what you're saying. If the group is just G, then there could be a global constant anycast address (and you have to make sure someone in your domain is advertising that address). Or perhaps it could be a configuration parameter on the endnode (what anycast address to use for joining groups in general (even SSM groups), or specifically just for ASM groups. 4. The join should use the router alert option in the IP header. This will allow routers along the path from the receiver to the source to process the unicast join or send it to a server it knows about. Ah yes. That was why I thought it would have to be raw sockets, and not just an unprivileged UDP/TCP application. So is this in fact possible? Radia _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 13:01:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09200 for ; Thu, 10 Jul 2003 12:11:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0e-0005MB-UU; Thu, 10 Jul 2003 12:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aN5X-0002HM-Hu for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 18:06:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25007 for ; Wed, 9 Jul 2003 18:06:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aN5U-0004El-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:06:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aN5T-0004E9-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:06:56 -0400 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h69M6M7F021800; Wed, 9 Jul 2003 15:06:22 -0700 (PDT) Received: (from lorenzo@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA25778; Wed, 9 Jul 2003 15:06:22 -0700 (PDT) From: Lorenzo Vicisano To: Joel Jaeggli Cc: David Meyer , mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709150622.F1057@cisco.com> References: <20030709142820.E1057@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 15:06:22 -0700 On Wed, Jul 09, 2003 at 02:52:46PM -0700, Joel Jaeggli wrote: > On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: > > > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > > > > > It was never clear to me why a host to router signaling mechanism had > > > to be different from the router to router signaling mechanism. > > > > one reason is because a host just needs to signal that is wants to > > receive multicast on a link, while a router cooperates with other > > routers to forward multicast in some optimized way. Hence the > > statement "I want to receive from this link" is typically not > > sufficient. > > so why can't I just send an s,g join towards s using pim instead of nicely > using igmp to get my first hop router to do it for me? because you, the host, would have to have routing information to find out who the 1st hop towards the source is... you would also have to take part to the PIM routing protocol to find out who's responsible to forward in your lan for that source. Lorenzo > > > Lorenzo > > > > > > > > > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > > > > > > > I guess the more things change, the more they stay the > > > > same. > > > > > > > > So another thing occurred to me while reading the > > > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > > > are we defining yet another ad-hoc signaling protocol > > > > (that is one way to looks at these proposals)? The IETF > > > > literature is littered with signaling proposals, some > > > > host-based, some router-based, at varying degrees of > > > > generality. > > > > > > > > Straw person: why not have the host send a PATH message > > > > towards the source (since it knows the source) and have > > > > the first multicast capable router in the path send back > > > > the its tunnel endpoint, have the host set up GRE (or > > > > user space encap) to that router and ... > > > > > > > > What I am suggesting is we really don't have a general > > > > purpose host-to-router signaling protocol (well, > > > > maybe). So if we pick one of the current drafts (or a > > > > hybrid, or even new), will we have to build a new > > > > signaling infrastructure for the next feature not > > > > supported by the directly connected routers? > > > > > > > > Seems like we should be able to answer this question in a > > > > more general way than is done in these drafts. > > > > > > > > Dave > > > > _______________________________________________ > > > > Mtp mailing list > > > > Mtp@shepfarm.com > > > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > > > > > > > -- > > > -------------------------------------------------------------------------- > > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > > resort of the scoundrel. With all due respect to an enlightened but > > > inferior lexicographer I beg to submit that it is the first. > > > -- Ambrose Bierce, "The Devil's Dictionary" > > > > > > > -- > -------------------------------------------------------------------------- > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > In Dr. Johnson's famous dictionary patriotism is defined as the last > resort of the scoundrel. With all due respect to an enlightened but > inferior lexicographer I beg to submit that it is the first. > -- Ambrose Bierce, "The Devil's Dictionary" > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:01:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09230 for ; Thu, 10 Jul 2003 12:11:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005i5-6e for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBKQe021199 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0e-0005MB-UU; Thu, 10 Jul 2003 12:11:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aN5X-0002HM-Hu for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 18:06:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25007 for ; Wed, 9 Jul 2003 18:06:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aN5U-0004El-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:06:56 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19aN5T-0004E9-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 18:06:56 -0400 Received: from cypher.cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h69M6M7F021800; Wed, 9 Jul 2003 15:06:22 -0700 (PDT) Received: (from lorenzo@localhost) by cypher.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA25778; Wed, 9 Jul 2003 15:06:22 -0700 (PDT) From: Lorenzo Vicisano To: Joel Jaeggli Cc: David Meyer , mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org Subject: Re: [Mtp] the more things change, the more they stay the same Message-ID: <20030709150622.F1057@cisco.com> References: <20030709142820.E1057@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 15:06:22 -0700 On Wed, Jul 09, 2003 at 02:52:46PM -0700, Joel Jaeggli wrote: > On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: > > > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > > > > > > It was never clear to me why a host to router signaling mechanism had > > > to be different from the router to router signaling mechanism. > > > > one reason is because a host just needs to signal that is wants to > > receive multicast on a link, while a router cooperates with other > > routers to forward multicast in some optimized way. Hence the > > statement "I want to receive from this link" is typically not > > sufficient. > > so why can't I just send an s,g join towards s using pim instead of nicely > using igmp to get my first hop router to do it for me? because you, the host, would have to have routing information to find out who the 1st hop towards the source is... you would also have to take part to the PIM routing protocol to find out who's responsible to forward in your lan for that source. Lorenzo > > > Lorenzo > > > > > > > > > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > > > > > > > I guess the more things change, the more they stay the > > > > same. > > > > > > > > So another thing occurred to me while reading the > > > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > > > are we defining yet another ad-hoc signaling protocol > > > > (that is one way to looks at these proposals)? The IETF > > > > literature is littered with signaling proposals, some > > > > host-based, some router-based, at varying degrees of > > > > generality. > > > > > > > > Straw person: why not have the host send a PATH message > > > > towards the source (since it knows the source) and have > > > > the first multicast capable router in the path send back > > > > the its tunnel endpoint, have the host set up GRE (or > > > > user space encap) to that router and ... > > > > > > > > What I am suggesting is we really don't have a general > > > > purpose host-to-router signaling protocol (well, > > > > maybe). So if we pick one of the current drafts (or a > > > > hybrid, or even new), will we have to build a new > > > > signaling infrastructure for the next feature not > > > > supported by the directly connected routers? > > > > > > > > Seems like we should be able to answer this question in a > > > > more general way than is done in these drafts. > > > > > > > > Dave > > > > _______________________________________________ > > > > Mtp mailing list > > > > Mtp@shepfarm.com > > > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > > > > > > > -- > > > -------------------------------------------------------------------------- > > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > > resort of the scoundrel. With all due respect to an enlightened but > > > inferior lexicographer I beg to submit that it is the first. > > > -- Ambrose Bierce, "The Devil's Dictionary" > > > > > > > -- > -------------------------------------------------------------------------- > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > In Dr. Johnson's famous dictionary patriotism is defined as the last > resort of the scoundrel. With all due respect to an enlightened but > inferior lexicographer I beg to submit that it is the first. > -- Ambrose Bierce, "The Devil's Dictionary" > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 13:01:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09280 for ; Thu, 10 Jul 2003 12:11:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0g-0005MR-33; Thu, 10 Jul 2003 12:11:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aOjl-0002Vd-9O for routing-discussion@optimus.ietf.org; Wed, 09 Jul 2003 19:52:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29546 for ; Wed, 9 Jul 2003 19:52:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aOjj-0005Pp-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 19:52:35 -0400 Received: from darkwing.uoregon.edu ([128.223.142.13] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19aOji-0005Pm-00 for routing-discussion@ietf.org; Wed, 09 Jul 2003 19:52:34 -0400 Received: from twin.uoregon.edu (twin.uoregon.edu [128.223.214.27]) by darkwing.uoregon.edu (8.12.9/8.12.9) with ESMTP id h69NqSDu022296 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 9 Jul 2003 16:52:28 -0700 (PDT) From: Joel Jaeggli X-X-Sender: joelja@twin.uoregon.edu To: Lorenzo Vicisano cc: David Meyer , , , , Subject: Re: [Mtp] the more things change, the more they stay the same In-Reply-To: <20030709150622.F1057@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 9 Jul 2003 16:52:24 -0700 (PDT) On Wed, 9 Jul 2003, Lorenzo Vicisano wrote: > > because you, the host, would have to have routing information to find > out who the 1st hop towards the source is... Do situations exist where a host that isn't running an igp or egp has multiple first hop routers available on the interface that it's default route is pointing out (excluding the special case of hsrp)? > you would also have to > take part to the PIM routing protocol to find out who's responsible to > forward in your lan for that source. yes > Lorenzo > > > > > > Lorenzo > > > > > > > > > > > > > > > On Wed, 9 Jul 2003, David Meyer wrote: > > > > > > > > > > > > > > I guess the more things change, the more they stay the > > > > > same. > > > > > > > > > > So another thing occurred to me while reading the > > > > > Multicast Last-Mile Solutions drafts on Greg's site: Why > > > > > are we defining yet another ad-hoc signaling protocol > > > > > (that is one way to looks at these proposals)? The IETF > > > > > literature is littered with signaling proposals, some > > > > > host-based, some router-based, at varying degrees of > > > > > generality. > > > > > > > > > > Straw person: why not have the host send a PATH message > > > > > towards the source (since it knows the source) and have > > > > > the first multicast capable router in the path send back > > > > > the its tunnel endpoint, have the host set up GRE (or > > > > > user space encap) to that router and ... > > > > > > > > > > What I am suggesting is we really don't have a general > > > > > purpose host-to-router signaling protocol (well, > > > > > maybe). So if we pick one of the current drafts (or a > > > > > hybrid, or even new), will we have to build a new > > > > > signaling infrastructure for the next feature not > > > > > supported by the directly connected routers? > > > > > > > > > > Seems like we should be able to answer this question in a > > > > > more general way than is done in these drafts. > > > > > > > > > > Dave > > > > > _______________________________________________ > > > > > Mtp mailing list > > > > > Mtp@shepfarm.com > > > > > http://www.shepfarm.com/mailman/listinfo/mtp > > > > > > > > > > > > > -- > > > > -------------------------------------------------------------------------- > > > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > > > resort of the scoundrel. With all due respect to an enlightened but > > > > inferior lexicographer I beg to submit that it is the first. > > > > -- Ambrose Bierce, "The Devil's Dictionary" > > > > > > > > > > > -- > > -------------------------------------------------------------------------- > > Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu > > -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- > > In Dr. Johnson's famous dictionary patriotism is defined as the last > > resort of the scoundrel. With all due respect to an enlightened but > > inferior lexicographer I beg to submit that it is the first. > > -- Ambrose Bierce, "The Devil's Dictionary" > > > -- -------------------------------------------------------------------------- Joel Jaeggli Academic User Services joelja@darkwing.uoregon.edu -- PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E -- In Dr. Johnson's famous dictionary patriotism is defined as the last resort of the scoundrel. With all due respect to an enlightened but inferior lexicographer I beg to submit that it is the first. -- Ambrose Bierce, "The Devil's Dictionary" _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 13:01:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09164 for ; Thu, 10 Jul 2003 12:11:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0h-0005Sn-QJ; Thu, 10 Jul 2003 12:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXGp-0004g6-Nj for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 04:59:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23207 for ; Thu, 10 Jul 2003 04:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aXGm-0000l0-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 04:59:16 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[8YEN6Td5eXArLPmTGxvRkoclNMBUKOvk]) by ietf-mx with esmtp (Exim 4.12) id 19aXGl-0000kx-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 04:59:16 -0400 Received: from nidd.cl.cam.ac.uk ([128.232.8.175] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19aXGd-0003bX-00; Thu, 10 Jul 2003 09:59:07 +0100 To: mboned , wg-multicast , routing-discussion , mtp@shepfarm.com, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: [Mtp] Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message from Bill Nickless of "Mon, 07 Jul 2003 13:42:47 CDT." <5.2.0.9.2.20030707125826.0220d828@pop.mcs.anl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7639.1057827546.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 09:59:06 +0100 so picking up on the _binding_ point, i see the last mile multicast as potentially similar to the NAT traversal problem, especially for cases of last mile access kit that are multicast atheistic....at least for one case (actually, quick aside- its not just last mile, its last kilometer, last foot, last meter etc - by which i mean there is a set of solutions and we need to list all of them with their applicability, pros and cons (e.g. acountabile, secure, performance, limits etc) so continuing on NATTering: given the last mile is not really a general case of a route for the cases where mcast doesnt work, but is just a signaling problem and we are talkign about wilful non use of igmp, then a stateful multicast to unicast NAT solution in the router at the DSLAM or other site is a possible one - of course, it also means the session advertisement (whatever mechansm is used) must also be modified or enhanced as it flows towards edge to include unicast - but that is often the job of newer application aware nats anyhow, esp. if they are part of CDN stuff so while it entails changing a few things, the end app wouldnt have to change at least for inbound/downlink - sending uplink from a non mast capable link might be trickier... and it gets a bit painful for things that use multiple ports (rtp things) although NATs already have to comprehend that for ftp-type apps anyhow In missive <5.2.0.9.2.20030707125826.0220d828@pop.mcs.anl.gov>, Bill Nickless t yped: >>At the risk of repeating myself, here's my take on it. (Focusing on IPv4, >>without loss of generality to IPv6): >> >>RFC 966 answered that question almost 20 years ago: >> >> Multicast has two primary uses, namely distributed binding and >> multi-destination delivery. As a binding mechanism, multicast is a >> robust and often more efficient alternative to the use of name >> servers for finding a particular object or service when a particular >> host address is not known. For example, in a distributed file >> system, all the file servers may be associated with one well-known >> multicast address. To bind a file name to a particular server, a >> client sends a query packet containing the file name to the file >> server multicast address, for delivery to all the file servers. The >> server that recognizes the file name then responds to the client, >> allowing subsequent interaction directly with that server host. Even >> when name servers are employed, multicast can be used as the first >> step in the binding process, that is, finding a name server. >> >> Multi-destination delivery is useful to several applications, >> including: >> >> - distributed, replicated databases [6,9]. >> >> - conferencing [11]. >> >> - distributed parallel computation, including distributed >> gaming [2]. >> >> Ideally, multicast transmission to a set of hosts is not more >> complicated or expensive for the sender than transmission to a single >> host. Similarly, multicast transmission should not be more expensive >> for the networks and gateways than traversing the shortest path tree >> that connects the sending host to the hosts identified by the >> multicast address. >> >>(Bill here again) >> >>Bottom line: >> >>I believe we should start with RFC 966. RFC 1112 targets an Internet that >>no longer exists, and LAN technology that has long since been superceded. >> >>For some time I've wanted to help write an RFC-1112-bis. I'm very much >>looking forward to the results of this BOF. Again--take good notes! >> >>=== >>Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 >>PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov >> >>-----BEGIN PGP SIGNATURE----- >>Version: PGP 8.0.2 >> >>iQCVAwUBPwm/K6wgm7ipJDXBAQHURgP+KHN5kuwgZFPMIRUNIsaPPINZzPd+Q2v2 >>3aPtB9YfIadNW9Ia0ENaH3X06+uwfVA6VK5ZPFLqJQh4K6Bh4yrggpzWYhxclDio >>aNYkJsPHXzGoCUbiEzdLF4eg40mxR2DA0t5WzjwOAwMKqudvVJWyIvHcuRP04LgU >>RXWZsj013Zs= >>=37Vd >>-----END PGP SIGNATURE----- >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:01:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09262 for ; Thu, 10 Jul 2003 12:11:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0x-0005hs-4x for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AGBK1p021187 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 12:11:20 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ae0h-0005Sn-QJ; Thu, 10 Jul 2003 12:11:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aXGp-0004g6-Nj for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 04:59:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23207 for ; Thu, 10 Jul 2003 04:59:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aXGm-0000l0-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 04:59:16 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[8YEN6Td5eXArLPmTGxvRkoclNMBUKOvk]) by ietf-mx with esmtp (Exim 4.12) id 19aXGl-0000kx-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 04:59:16 -0400 Received: from nidd.cl.cam.ac.uk ([128.232.8.175] helo=cl.cam.ac.uk ident=jac22) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19aXGd-0003bX-00; Thu, 10 Jul 2003 09:59:07 +0100 To: mboned , wg-multicast , routing-discussion , mtp@shepfarm.com, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: [Mtp] Re: BOF Agenda - Multicast Last-Mile Solutions In-Reply-To: Message from Bill Nickless of "Mon, 07 Jul 2003 13:42:47 CDT." <5.2.0.9.2.20030707125826.0220d828@pop.mcs.anl.gov> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7639.1057827546.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 09:59:06 +0100 so picking up on the _binding_ point, i see the last mile multicast as potentially similar to the NAT traversal problem, especially for cases of last mile access kit that are multicast atheistic....at least for one case (actually, quick aside- its not just last mile, its last kilometer, last foot, last meter etc - by which i mean there is a set of solutions and we need to list all of them with their applicability, pros and cons (e.g. acountabile, secure, performance, limits etc) so continuing on NATTering: given the last mile is not really a general case of a route for the cases where mcast doesnt work, but is just a signaling problem and we are talkign about wilful non use of igmp, then a stateful multicast to unicast NAT solution in the router at the DSLAM or other site is a possible one - of course, it also means the session advertisement (whatever mechansm is used) must also be modified or enhanced as it flows towards edge to include unicast - but that is often the job of newer application aware nats anyhow, esp. if they are part of CDN stuff so while it entails changing a few things, the end app wouldnt have to change at least for inbound/downlink - sending uplink from a non mast capable link might be trickier... and it gets a bit painful for things that use multiple ports (rtp things) although NATs already have to comprehend that for ftp-type apps anyhow In missive <5.2.0.9.2.20030707125826.0220d828@pop.mcs.anl.gov>, Bill Nickless t yped: >>At the risk of repeating myself, here's my take on it. (Focusing on IPv4, >>without loss of generality to IPv6): >> >>RFC 966 answered that question almost 20 years ago: >> >> Multicast has two primary uses, namely distributed binding and >> multi-destination delivery. As a binding mechanism, multicast is a >> robust and often more efficient alternative to the use of name >> servers for finding a particular object or service when a particular >> host address is not known. For example, in a distributed file >> system, all the file servers may be associated with one well-known >> multicast address. To bind a file name to a particular server, a >> client sends a query packet containing the file name to the file >> server multicast address, for delivery to all the file servers. The >> server that recognizes the file name then responds to the client, >> allowing subsequent interaction directly with that server host. Even >> when name servers are employed, multicast can be used as the first >> step in the binding process, that is, finding a name server. >> >> Multi-destination delivery is useful to several applications, >> including: >> >> - distributed, replicated databases [6,9]. >> >> - conferencing [11]. >> >> - distributed parallel computation, including distributed >> gaming [2]. >> >> Ideally, multicast transmission to a set of hosts is not more >> complicated or expensive for the sender than transmission to a single >> host. Similarly, multicast transmission should not be more expensive >> for the networks and gateways than traversing the shortest path tree >> that connects the sending host to the hosts identified by the >> multicast address. >> >>(Bill here again) >> >>Bottom line: >> >>I believe we should start with RFC 966. RFC 1112 targets an Internet that >>no longer exists, and LAN technology that has long since been superceded. >> >>For some time I've wanted to help write an RFC-1112-bis. I'm very much >>looking forward to the results of this BOF. Again--take good notes! >> >>=== >>Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 >>PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov >> >>-----BEGIN PGP SIGNATURE----- >>Version: PGP 8.0.2 >> >>iQCVAwUBPwm/K6wgm7ipJDXBAQHURgP+KHN5kuwgZFPMIRUNIsaPPINZzPd+Q2v2 >>3aPtB9YfIadNW9Ia0ENaH3X06+uwfVA6VK5ZPFLqJQh4K6Bh4yrggpzWYhxclDio >>aNYkJsPHXzGoCUbiEzdLF4eg40mxR2DA0t5WzjwOAwMKqudvVJWyIvHcuRP04LgU >>RXWZsj013Zs= >>=37Vd >>-----END PGP SIGNATURE----- >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 13:05:40 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12571 for ; Thu, 10 Jul 2003 13:05:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeqr-0002ua-Uk; Thu, 10 Jul 2003 13:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeqN-0002ja-7c for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 13:04:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12537 for ; Thu, 10 Jul 2003 13:04:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aeqL-0005F3-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 13:04:29 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19aeqK-0005Eg-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 13:04:28 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h6AHHRJh029214; Thu, 10 Jul 2003 13:17:27 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h6AH3jXs008085; Thu, 10 Jul 2003 13:03:46 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h6AH3or27652; Thu, 10 Jul 2003 10:03:50 -0700 (PDT) Message-Id: <200307101703.h6AH3or27652@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Radia.Perlman@sun.com Subject: Re: [Mtp] the more things change, the more they stay the same Cc: pusateri@juniper.net, routing-discussion@ietf.org, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 10:03:49 -0700 >Can an application send a UDP or TCP based packet with router alert >in the IP header without special privileges? In the sockets interface, yes - the IP_OPTIONS socket option is not privileged. >Perhaps, though you can't simply remove "G" from the header. It has to >be preserved somewhere. Actually the model that Tom is talking about sounds kind of like REUNITE (Infocom 2000), which just uses unicast address+port pairs to identify multicast groups. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 13:05:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12574 for ; Thu, 10 Jul 2003 13:05:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aer5-0002w0-V6 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 13:05:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AH5FMh011252 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 13:05:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeqr-0002ua-Uk; Thu, 10 Jul 2003 13:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aeqN-0002ja-7c for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 13:04:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12537 for ; Thu, 10 Jul 2003 13:04:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aeqL-0005F3-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 13:04:29 -0400 Received: from h-135-207-24-16.research.att.com ([135.207.24.16] helo=linux.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 19aeqK-0005Eg-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 13:04:28 -0400 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by linux.research.att.com (8.12.8/8.12.8) with ESMTP id h6AHHRJh029214; Thu, 10 Jul 2003 13:17:27 -0400 Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id h6AH3jXs008085; Thu, 10 Jul 2003 13:03:46 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.11.6+Sun/8.8.5) id h6AH3or27652; Thu, 10 Jul 2003 10:03:50 -0700 (PDT) Message-Id: <200307101703.h6AH3or27652@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: Radia.Perlman@sun.com Subject: Re: [Mtp] the more things change, the more they stay the same Cc: pusateri@juniper.net, routing-discussion@ietf.org, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com Versions: dmail (solaris) 2.5a/makemail 2.9d Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 10:03:49 -0700 >Can an application send a UDP or TCP based packet with router alert >in the IP header without special privileges? In the sockets interface, yes - the IP_OPTIONS socket option is not privileged. >Perhaps, though you can't simply remove "G" from the header. It has to >be preserved somewhere. Actually the model that Tom is talking about sounds kind of like REUNITE (Infocom 2000), which just uses unicast address+port pairs to identify multicast groups. Bill _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 14:31:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15689 for ; Thu, 10 Jul 2003 14:31:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agC5-0002D5-Gm; Thu, 10 Jul 2003 14:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agBn-0002CQ-P0 for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 14:30:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15664 for ; Thu, 10 Jul 2003 14:30:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19agBl-00061h-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 14:30:41 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19agBk-00061e-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 14:30:40 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6AIU6314262; Thu, 10 Jul 2003 14:30:06 -0400 (EDT) Message-Id: <200307101830.h6AIU6314262@maildev.avici.com> To: "Naidu, Venkata" cc: "'Bill Fenner'" , joelja@darkwing.uoregon.edu, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Mtp] the more things change, the more they stay the same In-reply-to: Your message of "Thu, 10 Jul 2003 10:34:18 EDT." <39469E08BD83D411A3D900204840EC55FB6F52@vie-msgusr-01.dc.fore.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 14:30:39 -0400 In message <39469E08BD83D411A3D900204840EC55FB6F52@vie-msgusr-01.dc.fore.com>, "Naidu, Venkata" writes: > -> From: Bill Fenner [mailto:fenner@research.att.com] > -> On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > -> > > -> > It was never clear to me why a host to router signaling > -> mechanism had > -> > to be different from the router to router signaling mechanism. > -> > -> Here's one reason: because if we had this conversation in 1993 we > -> would have made the host to router signalling mechanism DVMRP, or > -> maybe we would have been looking toward the future and made it MOSPF. > -> > -> The generalization of that is the goal is to be able to evolve > -> the routing protocol independently of the host<>router interface. > -> Since there are orders of magnitudes more hosts to change than > -> routers when a protocol changes, this theoretically makes the > -> infrastructure more able to change piecemeal. > > Another good reason is based on end-to-end principle of the Internet. > Core of the Internet is best effort (was intended to be, at least). > If we would like to support quality of service, we are supposed > to signal more parameters in the host<>router than router<>router > to do admission control before entering the network. So, the > requirements are different (light weight, not so granular signalling > in the core etc) from user<>router interface to router<>router > interface. > > I am not sure how much (or, how) multicasting fits into such > end-to-end signaling principle. If I have an HDTV and paid for > premium VoD service, will I be getting better picture, sound > quality than my neighbor who is subscribed to a basic service ? > > Venkata. Venkata, You are making assertions that are not necessarily true regarding QoS particularly regarding the role if any of admission control and inferring that they are somehow tied to the end-to-end principle which is even less true. [Sounds like the ramblings of an ATM head. :) ] Since this whole thing is off topic wrt why native multicast deployment is very limited, lets just leave it at that. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 14:31:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15704 for ; Thu, 10 Jul 2003 14:31:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agCD-0002E4-Pi for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 14:31:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AIV90x008556 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 14:31:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agC5-0002D5-Gm; Thu, 10 Jul 2003 14:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agBn-0002CQ-P0 for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 14:30:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15664 for ; Thu, 10 Jul 2003 14:30:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19agBl-00061h-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 14:30:41 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19agBk-00061e-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 14:30:40 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6AIU6314262; Thu, 10 Jul 2003 14:30:06 -0400 (EDT) Message-Id: <200307101830.h6AIU6314262@maildev.avici.com> To: "Naidu, Venkata" cc: "'Bill Fenner'" , joelja@darkwing.uoregon.edu, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: [Mtp] the more things change, the more they stay the same In-reply-to: Your message of "Thu, 10 Jul 2003 10:34:18 EDT." <39469E08BD83D411A3D900204840EC55FB6F52@vie-msgusr-01.dc.fore.com> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 14:30:39 -0400 In message <39469E08BD83D411A3D900204840EC55FB6F52@vie-msgusr-01.dc.fore.com>, "Naidu, Venkata" writes: > -> From: Bill Fenner [mailto:fenner@research.att.com] > -> On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote: > -> > > -> > It was never clear to me why a host to router signaling > -> mechanism had > -> > to be different from the router to router signaling mechanism. > -> > -> Here's one reason: because if we had this conversation in 1993 we > -> would have made the host to router signalling mechanism DVMRP, or > -> maybe we would have been looking toward the future and made it MOSPF. > -> > -> The generalization of that is the goal is to be able to evolve > -> the routing protocol independently of the host<>router interface. > -> Since there are orders of magnitudes more hosts to change than > -> routers when a protocol changes, this theoretically makes the > -> infrastructure more able to change piecemeal. > > Another good reason is based on end-to-end principle of the Internet. > Core of the Internet is best effort (was intended to be, at least). > If we would like to support quality of service, we are supposed > to signal more parameters in the host<>router than router<>router > to do admission control before entering the network. So, the > requirements are different (light weight, not so granular signalling > in the core etc) from user<>router interface to router<>router > interface. > > I am not sure how much (or, how) multicasting fits into such > end-to-end signaling principle. If I have an HDTV and paid for > premium VoD service, will I be getting better picture, sound > quality than my neighbor who is subscribed to a basic service ? > > Venkata. Venkata, You are making assertions that are not necessarily true regarding QoS particularly regarding the role if any of admission control and inferring that they are somehow tied to the end-to-end principle which is even less true. [Sounds like the ramblings of an ATM head. :) ] Since this whole thing is off topic wrt why native multicast deployment is very limited, lets just leave it at that. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 15:20:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18282 for ; Thu, 10 Jul 2003 15:20:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agxV-0006Ex-2T; Thu, 10 Jul 2003 15:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agwo-0006E1-Gm for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 15:19:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18247 for ; Thu, 10 Jul 2003 15:19:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19agwl-0006PH-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 15:19:15 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19agwk-0006PC-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 15:19:15 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6AJIx320250; Thu, 10 Jul 2003 15:18:59 -0400 (EDT) Message-Id: <200307101918.h6AJIx320250@maildev.avici.com> To: David Meyer cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? In-reply-to: Your message of "Thu, 10 Jul 2003 07:56:12 PDT." <20030710075612.A17872@1-4-5.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 15:19:31 -0400 In message <20030710075612.A17872@1-4-5.net>, David Meyer writes: > > Here's something I've been discussing with the ADs > (and hoping to learn the lessons of the MADDOGs > "experience"). > > I put it on the mboned agenda, so we can also discuss this > there. As always, comments greatly appreciated. > > Dave Dave, I think you've got a great list of multicast issues and mboned would be a good place to continue with this. My first reaction was that this may be too complete a list and you should concentrate on the subset of the items that are deemed most important to or considered barriers to further multicast deployment. On the original topic of multicast deployment, there were some assertions that there is financial disincentives for a tier-1 to deploy multicast. I have a few comments on that. First, if multicast is not offerred and it happens anyway through unicast replication, then adding multicast does remove a burden from the core. If replication is distributed anyway and not laid out according to topology (p2p stuff, for example), then the savings is greater. OTOH if some sort of service is essentially broadcast as multiple unicast and is huge in volume, lack of multicast provides a visible revenue source for the provider, the fat pipe to the source. It was this (possibly flawed) logic that has motivated some commercial multicast service where only select participants could be senders and charges for this priviledge were quite high (high enough in the one case I have in mind that service penetration was minimal). Somewhere in the middle is the multiparty conference, with more than two or three but no more than a dozen or so participants. Unicast replication at a single site can be viable for a small number of satelite sites, but for larger conferences can become infeasible. It is these many smaller scale multicast groups that it would be good to provide on the same flat rate basis as today's unicast, while avoiding carrying large scale broadcasts for free. The topic of counting leaf nodes came up. For a tier-1 provider, it is sufficient and perhaps more relevant to know only the number of exit points from that provider that a sender is reaching. How much branching occurs beyond the tier-1 provider is inconsequential to the tier-1 provider. The good news is that collection this information is something that can be confined to the single provider if protocol support existed to do so. From the provider's business standpoint, it may be sufficient to limit bandwidth and this bounds (number of exit points to the provider) for lower service levels including any default (comes without charge or a fixed extra) flat rate service and offer a higher service level in which the sender bandwidth and exit point count limits are set higher. This would allow flat rate low usage multicast such as small conferencing but still provide the means to generate revenues appropriate to higher bandwidth and wider spread multicast, such as VOD. Curtis > --- > > This note proposes the creation the Internet Multicast > Documentation, Oversight, and Coordination (IMDOC) > function. The IMDOC, residing in mboned, will serve as > the locus of documentation, cross-coordination, and > oversight function for the muticast activity in the IETF > at large, and will create two crucial missing pieces of > the multicast puzzle: (i). A comprehensive IETF multicast > framework document, and (ii). the Internet Multicast > Reference Architecture (IMRA). Both are discussed briefly > below. > > IMDOC documents will be published in the mboned working > group and will: > > (i). Provide a comprehensive framework document. This > document will cover all multicast issues under > consideration within IETF, and will provide a > systematic way determining when new working > groups are needed. > > (ii). Provide the Internet Multicast Reference > Architecture document. Importantly, the IMRA will > cover both intra and inter-domain multicast > architectures. > > (iii). Outline domain-specific problem spaces (for > example, as was done in mboned with > draft-ietf-mboned-imrp-some-issues-01.txt). > > (iv). Preserve the archival knowledge of what has > worked and what hasn't, and why. This knowledge > is currently folklore (or very ad hoc at best). > > The IMDOC coordination and oversight functions will be > organized by the mboned working group in conjunction with > the appropriate working group chairs and area directors. > > The following list of areas (which are in scope for the > IMDOC) is not intended to exhaustive, but rather to > illustrate the requirement for oversight and > coordination: > > (i). Addressing > > Including dynamic address assignment (malloc, > etc), IANA issues (IPv4 and IPv6, e.g. RFC > 3171/BCP51), scoping mechanisms and > methodologies, multicast address derivation > (e.g. RFCs 2770 and 3138) and Unicast Based > Addresses (IPv6). > > (ii). Source discovery > > Including in-band source discovery methods such as > BSR (which touches pim) and embedded RP (which > touches ipv6)), and out-of-band mechanisms such > as proposed for SSM (which touches ssm), and > their associated applications and APIs (which > touches mmusic). Examples of documents in this > area include RFC 3569. > > (iii). Security > > Including key exchange (which touches msec), and > data encryption (which touches ipsec), as well as > the general problem of a security architecture > for multicast. > > (iv). L2 aliasing > > For example, 802.x (which touches ipoib and > others), IGMP/MLD Snooping, CGMP, PIM Snooping, > and RGMP (which touches on MAGMA). > > (v). Routing > > For example, BGP4+ and associated extensions > which effect multicast, Multi-Topology IGPs. > > (vi). Forwarding > > Including discussions on all PIM forwarding > modes, DVMPR, CBT, etc. Also includes issues > associated with RP mapping approached for PIM-SM, > and general discussions on ASM vs. SSM models > (covering bidirectional and unidirectional status > as well) > > (vii). Reliable Transport > > Including discussions on RMT generated building > blocks as well as issues associated with > PGM. Covers FEC, CC, etc. > > (viii). Session Control > > Will include issues associated with source and > receiver control, example MSNIP, RTS/CTS issues, > floor-control, etc. > > (ix). Application Layer Issues > > Examples include BCPs for writing multicast > applications (e.g. RFC 3170), discussions on > default address use, traffic patterns (example > implications of bursty traffic, low frequency > traffic), and APIs for SSM. > > (x). Tunneling > > Including any potential new dynamic tunneling > proposals which come from Last Mile Multicast, etc. > > (xi). VPN > > Both L2 (pwe3, l2vpn), and L3 (ppvpn, l3vpn) > > > > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 16:06:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18284 for ; Thu, 10 Jul 2003 15:20:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agxe-0006GR-BT for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 15:20:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AJKALQ024078 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 15:20:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agxV-0006Ex-2T; Thu, 10 Jul 2003 15:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19agwo-0006E1-Gm for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 15:19:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18247 for ; Thu, 10 Jul 2003 15:19:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19agwl-0006PH-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 15:19:15 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19agwk-0006PC-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 15:19:15 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6AJIx320250; Thu, 10 Jul 2003 15:18:59 -0400 (EDT) Message-Id: <200307101918.h6AJIx320250@maildev.avici.com> To: David Meyer cc: mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? In-reply-to: Your message of "Thu, 10 Jul 2003 07:56:12 PDT." <20030710075612.A17872@1-4-5.net> From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 15:19:31 -0400 In message <20030710075612.A17872@1-4-5.net>, David Meyer writes: > > Here's something I've been discussing with the ADs > (and hoping to learn the lessons of the MADDOGs > "experience"). > > I put it on the mboned agenda, so we can also discuss this > there. As always, comments greatly appreciated. > > Dave Dave, I think you've got a great list of multicast issues and mboned would be a good place to continue with this. My first reaction was that this may be too complete a list and you should concentrate on the subset of the items that are deemed most important to or considered barriers to further multicast deployment. On the original topic of multicast deployment, there were some assertions that there is financial disincentives for a tier-1 to deploy multicast. I have a few comments on that. First, if multicast is not offerred and it happens anyway through unicast replication, then adding multicast does remove a burden from the core. If replication is distributed anyway and not laid out according to topology (p2p stuff, for example), then the savings is greater. OTOH if some sort of service is essentially broadcast as multiple unicast and is huge in volume, lack of multicast provides a visible revenue source for the provider, the fat pipe to the source. It was this (possibly flawed) logic that has motivated some commercial multicast service where only select participants could be senders and charges for this priviledge were quite high (high enough in the one case I have in mind that service penetration was minimal). Somewhere in the middle is the multiparty conference, with more than two or three but no more than a dozen or so participants. Unicast replication at a single site can be viable for a small number of satelite sites, but for larger conferences can become infeasible. It is these many smaller scale multicast groups that it would be good to provide on the same flat rate basis as today's unicast, while avoiding carrying large scale broadcasts for free. The topic of counting leaf nodes came up. For a tier-1 provider, it is sufficient and perhaps more relevant to know only the number of exit points from that provider that a sender is reaching. How much branching occurs beyond the tier-1 provider is inconsequential to the tier-1 provider. The good news is that collection this information is something that can be confined to the single provider if protocol support existed to do so. From the provider's business standpoint, it may be sufficient to limit bandwidth and this bounds (number of exit points to the provider) for lower service levels including any default (comes without charge or a fixed extra) flat rate service and offer a higher service level in which the sender bandwidth and exit point count limits are set higher. This would allow flat rate low usage multicast such as small conferencing but still provide the means to generate revenues appropriate to higher bandwidth and wider spread multicast, such as VOD. Curtis > --- > > This note proposes the creation the Internet Multicast > Documentation, Oversight, and Coordination (IMDOC) > function. The IMDOC, residing in mboned, will serve as > the locus of documentation, cross-coordination, and > oversight function for the muticast activity in the IETF > at large, and will create two crucial missing pieces of > the multicast puzzle: (i). A comprehensive IETF multicast > framework document, and (ii). the Internet Multicast > Reference Architecture (IMRA). Both are discussed briefly > below. > > IMDOC documents will be published in the mboned working > group and will: > > (i). Provide a comprehensive framework document. This > document will cover all multicast issues under > consideration within IETF, and will provide a > systematic way determining when new working > groups are needed. > > (ii). Provide the Internet Multicast Reference > Architecture document. Importantly, the IMRA will > cover both intra and inter-domain multicast > architectures. > > (iii). Outline domain-specific problem spaces (for > example, as was done in mboned with > draft-ietf-mboned-imrp-some-issues-01.txt). > > (iv). Preserve the archival knowledge of what has > worked and what hasn't, and why. This knowledge > is currently folklore (or very ad hoc at best). > > The IMDOC coordination and oversight functions will be > organized by the mboned working group in conjunction with > the appropriate working group chairs and area directors. > > The following list of areas (which are in scope for the > IMDOC) is not intended to exhaustive, but rather to > illustrate the requirement for oversight and > coordination: > > (i). Addressing > > Including dynamic address assignment (malloc, > etc), IANA issues (IPv4 and IPv6, e.g. RFC > 3171/BCP51), scoping mechanisms and > methodologies, multicast address derivation > (e.g. RFCs 2770 and 3138) and Unicast Based > Addresses (IPv6). > > (ii). Source discovery > > Including in-band source discovery methods such as > BSR (which touches pim) and embedded RP (which > touches ipv6)), and out-of-band mechanisms such > as proposed for SSM (which touches ssm), and > their associated applications and APIs (which > touches mmusic). Examples of documents in this > area include RFC 3569. > > (iii). Security > > Including key exchange (which touches msec), and > data encryption (which touches ipsec), as well as > the general problem of a security architecture > for multicast. > > (iv). L2 aliasing > > For example, 802.x (which touches ipoib and > others), IGMP/MLD Snooping, CGMP, PIM Snooping, > and RGMP (which touches on MAGMA). > > (v). Routing > > For example, BGP4+ and associated extensions > which effect multicast, Multi-Topology IGPs. > > (vi). Forwarding > > Including discussions on all PIM forwarding > modes, DVMPR, CBT, etc. Also includes issues > associated with RP mapping approached for PIM-SM, > and general discussions on ASM vs. SSM models > (covering bidirectional and unidirectional status > as well) > > (vii). Reliable Transport > > Including discussions on RMT generated building > blocks as well as issues associated with > PGM. Covers FEC, CC, etc. > > (viii). Session Control > > Will include issues associated with source and > receiver control, example MSNIP, RTS/CTS issues, > floor-control, etc. > > (ix). Application Layer Issues > > Examples include BCPs for writing multicast > applications (e.g. RFC 3170), discussions on > default address use, traffic patterns (example > implications of bursty traffic, low frequency > traffic), and APIs for SSM. > > (x). Tunneling > > Including any potential new dynamic tunneling > proposals which come from Last Mile Multicast, etc. > > (xi). VPN > > Both L2 (pwe3, l2vpn), and L3 (ppvpn, l3vpn) > > > > > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 16:07:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19811 for ; Thu, 10 Jul 2003 16:07:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ahh0-0002WD-EY; Thu, 10 Jul 2003 16:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ahgH-0002Sf-3F for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 16:06:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19782 for ; Thu, 10 Jul 2003 16:06:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ahgF-0006ov-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 16:06:15 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19ahgE-0006os-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 16:06:14 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA00008; Thu, 10 Jul 2003 13:05:33 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id NAA24325; Thu, 10 Jul 2003 13:06:08 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h6AK4vP07638; Thu, 10 Jul 2003 13:04:57 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jul 2003 16:04:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? Message-ID: Thread-Topic: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? Thread-Index: AcNHGLrCXb/VJVEqRY+L/AAIkGLDJAAAlpTg From: "Manfredi, Albert E" To: Cc: , , , X-OriginalArrivalTime: 10 Jul 2003 20:04:48.0055 (UTC) FILETIME=[83B19470:01C3471E] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 16:04:47 -0400 Content-Transfer-Encoding: quoted-printable Curtis Villamizar wrote: > The topic of counting leaf nodes came up. For a tier-1 provider, it > is sufficient and perhaps more relevant to know only the number of > exit points from that provider that a sender is reaching. How much > branching occurs beyond the tier-1 provider is inconsequential to the > tier-1 provider. Is this necessarily enough? For example, wouldn't a sender want an = accurate count of his audience, sort of like Nielsen ratings, only a = real count instead of statistical sampling? And couldn't a provider use = that count as the basis for charging the sender? I'm not sure what = business models are in use now, so I might be off base. > The good news is that collection this information is > something that can be confined to the single provider if protocol > support existed to do so. From the provider's business standpoint, it > may be sufficient to limit bandwidth and this bounds (number of exit > points to the provider) for lower service levels including any default > (comes without charge or a fixed extra) flat rate service and offer a > higher service level in which the sender bandwidth and exit point > count limits are set higher. This would allow flat rate low usage > multicast such as small conferencing but still provide the means to > generate revenues appropriate to higher bandwidth and wider spread > multicast, such as VOD. That, and more. I seem to recall, for example, that on 9/11/01, not only = was I unable to get *any* news source via streaming media from my = office, due to network congestion caused in large measure by all those = TCP/IP-based streaming media sessions, but the various streaming media = outlets were proud of supporting in the low hundreds of thousands of = sessions that entire day(!). But that's peanuts, isn't it? I doubt = broadcasters would be proud of such low numbers on that day. Multiple = millions would be more like it. I would expect that use of the right protocol here would give the = network providers the revenues they need (want) while at the same time = providing a level of service that is somewhat more competitive with the = broadcast alternatives. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 16:07:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19822 for ; Thu, 10 Jul 2003 16:07:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ahhE-0002Yc-EN for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 16:07:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AK7Gsg009822 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 16:07:16 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ahh0-0002WD-EY; Thu, 10 Jul 2003 16:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ahgH-0002Sf-3F for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 16:06:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19782 for ; Thu, 10 Jul 2003 16:06:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ahgF-0006ov-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 16:06:15 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19ahgE-0006os-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 16:06:14 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id NAA00008; Thu, 10 Jul 2003 13:05:33 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id NAA24325; Thu, 10 Jul 2003 13:06:08 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h6AK4vP07638; Thu, 10 Jul 2003 13:04:57 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jul 2003 16:04:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? Message-ID: Thread-Topic: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? Thread-Index: AcNHGLrCXb/VJVEqRY+L/AAIkGLDJAAAlpTg From: "Manfredi, Albert E" To: Cc: , , , X-OriginalArrivalTime: 10 Jul 2003 20:04:48.0055 (UTC) FILETIME=[83B19470:01C3471E] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 16:04:47 -0400 Content-Transfer-Encoding: quoted-printable Curtis Villamizar wrote: > The topic of counting leaf nodes came up. For a tier-1 provider, it > is sufficient and perhaps more relevant to know only the number of > exit points from that provider that a sender is reaching. How much > branching occurs beyond the tier-1 provider is inconsequential to the > tier-1 provider. Is this necessarily enough? For example, wouldn't a sender want an = accurate count of his audience, sort of like Nielsen ratings, only a = real count instead of statistical sampling? And couldn't a provider use = that count as the basis for charging the sender? I'm not sure what = business models are in use now, so I might be off base. > The good news is that collection this information is > something that can be confined to the single provider if protocol > support existed to do so. From the provider's business standpoint, it > may be sufficient to limit bandwidth and this bounds (number of exit > points to the provider) for lower service levels including any default > (comes without charge or a fixed extra) flat rate service and offer a > higher service level in which the sender bandwidth and exit point > count limits are set higher. This would allow flat rate low usage > multicast such as small conferencing but still provide the means to > generate revenues appropriate to higher bandwidth and wider spread > multicast, such as VOD. That, and more. I seem to recall, for example, that on 9/11/01, not only = was I unable to get *any* news source via streaming media from my = office, due to network congestion caused in large measure by all those = TCP/IP-based streaming media sessions, but the various streaming media = outlets were proud of supporting in the low hundreds of thousands of = sessions that entire day(!). But that's peanuts, isn't it? I doubt = broadcasters would be proud of such low numbers on that day. Multiple = millions would be more like it. I would expect that use of the right protocol here would give the = network providers the revenues they need (want) while at the same time = providing a level of service that is somewhat more competitive with the = broadcast alternatives. Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 10 17:07:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21825 for ; Thu, 10 Jul 2003 17:07:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aid4-0008IJ-BR; Thu, 10 Jul 2003 17:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aicf-0008HB-Ao for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 17:06:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21799 for ; Thu, 10 Jul 2003 17:06:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aicc-0007KU-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 17:06:34 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19aicb-0007KQ-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 17:06:34 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6AL5U302513; Thu, 10 Jul 2003 17:05:31 -0400 (EDT) Message-Id: <200307102105.h6AL5U302513@maildev.avici.com> To: "Manfredi, Albert E" cc: curtis@fictitious.org, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? In-reply-to: Your message of "Thu, 10 Jul 2003 16:04:47 EDT." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 17:06:03 -0400 In message , "Manfredi, Albert E" writes: > Curtis Villamizar wrote: > > > The topic of counting leaf nodes came up. For a tier-1 provider, it > > is sufficient and perhaps more relevant to know only the number of > > exit points from that provider that a sender is reaching. How much > > branching occurs beyond the tier-1 provider is inconsequential to the > > tier-1 provider. > > Is this necessarily enough? For example, wouldn't a sender want an accurate c > ount of his audience, sort of like Nielsen ratings, only a real count instead > of statistical sampling? And couldn't a provider use that count as the basis > for charging the sender? I'm not sure what business models are in use now, s > o I might be off base. If you are a content provider then yes. If you are a provider of connectivity and want to milk the billing on multicast service for as much as you possibly can even if it doesn't cost you anything for expansion of the groups beyond your borders then yes, but that mentality yields low to zero service penetration. This is sort of like the X.25 per packet billing vs IP flat rate only with multicast. X.25 certainly still has the advantage in terms of ability to bill per packet - its also dead. > > The good news is that collection this information is > > something that can be confined to the single provider if protocol > > support existed to do so. From the provider's business standpoint, it > > may be sufficient to limit bandwidth and this bounds (number of exit > > points to the provider) for lower service levels including any default > > (comes without charge or a fixed extra) flat rate service and offer a > > higher service level in which the sender bandwidth and exit point > > count limits are set higher. This would allow flat rate low usage > > multicast such as small conferencing but still provide the means to > > generate revenues appropriate to higher bandwidth and wider spread > > multicast, such as VOD. > > That, and more. I seem to recall, for example, that on 9/11/01, not only was > I unable to get *any* news source via streaming media from my office, due to > network congestion caused in large measure by all those TCP/IP-based streamin > g media sessions, but the various streaming media outlets were proud of suppo > rting in the low hundreds of thousands of sessions that entire day(!). But th > at's peanuts, isn't it? I doubt broadcasters would be proud of such low numbe > rs on that day. Multiple millions would be more like it. For the tier-1 IP provider a few thousand access routers are reached with multicast and how many CPE routers is reached doesn't matter because the end customer already foots that bill. This is an example where multicast would have done some good. > I would expect that use of the right protocol here would give the network pro > viders the revenues they need (want) while at the same time providing a level > of service that is somewhat more competitive with the broadcast alternatives > . > > Bert For the most part the protocols exist. Attempts to make it a big revenue source and bill too much for it has so far killed it for some providers. For the market penetration that existed at the time, it was cheaper for the source (content provider) to get a big pipe and unicast. Commercial multicast has existed for a long time. The goal should be to provide some means to insure the transport provider doesn't take a loss due to high bandwidth wide distribution multicast, and that limited distribution multicast can be offerred unmetered if not free with the unicast service. Make it cost effective for end users (senders and receivers) and multicast penetration will occur. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 10 17:07:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21836 for ; Thu, 10 Jul 2003 17:07:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aidV-0008Qn-Q8 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 17:07:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6AL7Twr032403 for routing-discussion-archive@odin.ietf.org; Thu, 10 Jul 2003 17:07:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aid4-0008IJ-BR; Thu, 10 Jul 2003 17:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19aicf-0008HB-Ao for routing-discussion@optimus.ietf.org; Thu, 10 Jul 2003 17:06:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21799 for ; Thu, 10 Jul 2003 17:06:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19aicc-0007KU-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 17:06:34 -0400 Received: from [12.38.212.174] (helo=maildev.avici.com) by ietf-mx with esmtp (Exim 4.12) id 19aicb-0007KQ-00 for routing-discussion@ietf.org; Thu, 10 Jul 2003 17:06:34 -0400 Received: from laptoy770.fictitious.org (tedev-tun1.avici.com [10.2.20.201]) by maildev.avici.com (8.11.0/8.11.0) with ESMTP id h6AL5U302513; Thu, 10 Jul 2003 17:05:31 -0400 (EDT) Message-Id: <200307102105.h6AL5U302513@maildev.avici.com> To: "Manfredi, Albert E" cc: curtis@fictitious.org, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, mtp@shepfarm.com, routing-discussion@ietf.org Reply-To: curtis@fictitious.org Subject: Re: Internet Multicast Documentation, Oversight, and Coordination (IMDOC)? In-reply-to: Your message of "Thu, 10 Jul 2003 16:04:47 EDT." From: Curtis Villamizar Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 10 Jul 2003 17:06:03 -0400 In message , "Manfredi, Albert E" writes: > Curtis Villamizar wrote: > > > The topic of counting leaf nodes came up. For a tier-1 provider, it > > is sufficient and perhaps more relevant to know only the number of > > exit points from that provider that a sender is reaching. How much > > branching occurs beyond the tier-1 provider is inconsequential to the > > tier-1 provider. > > Is this necessarily enough? For example, wouldn't a sender want an accurate c > ount of his audience, sort of like Nielsen ratings, only a real count instead > of statistical sampling? And couldn't a provider use that count as the basis > for charging the sender? I'm not sure what business models are in use now, s > o I might be off base. If you are a content provider then yes. If you are a provider of connectivity and want to milk the billing on multicast service for as much as you possibly can even if it doesn't cost you anything for expansion of the groups beyond your borders then yes, but that mentality yields low to zero service penetration. This is sort of like the X.25 per packet billing vs IP flat rate only with multicast. X.25 certainly still has the advantage in terms of ability to bill per packet - its also dead. > > The good news is that collection this information is > > something that can be confined to the single provider if protocol > > support existed to do so. From the provider's business standpoint, it > > may be sufficient to limit bandwidth and this bounds (number of exit > > points to the provider) for lower service levels including any default > > (comes without charge or a fixed extra) flat rate service and offer a > > higher service level in which the sender bandwidth and exit point > > count limits are set higher. This would allow flat rate low usage > > multicast such as small conferencing but still provide the means to > > generate revenues appropriate to higher bandwidth and wider spread > > multicast, such as VOD. > > That, and more. I seem to recall, for example, that on 9/11/01, not only was > I unable to get *any* news source via streaming media from my office, due to > network congestion caused in large measure by all those TCP/IP-based streamin > g media sessions, but the various streaming media outlets were proud of suppo > rting in the low hundreds of thousands of sessions that entire day(!). But th > at's peanuts, isn't it? I doubt broadcasters would be proud of such low numbe > rs on that day. Multiple millions would be more like it. For the tier-1 IP provider a few thousand access routers are reached with multicast and how many CPE routers is reached doesn't matter because the end customer already foots that bill. This is an example where multicast would have done some good. > I would expect that use of the right protocol here would give the network pro > viders the revenues they need (want) while at the same time providing a level > of service that is somewhat more competitive with the broadcast alternatives > . > > Bert For the most part the protocols exist. Attempts to make it a big revenue source and bill too much for it has so far killed it for some providers. For the market penetration that existed at the time, it was cheaper for the source (content provider) to get a big pipe and unicast. Commercial multicast has existed for a long time. The goal should be to provide some means to insure the transport provider doesn't take a loss due to high bandwidth wide distribution multicast, and that limited distribution multicast can be offerred unmetered if not free with the unicast service. Make it cost effective for end users (senders and receivers) and multicast penetration will occur. Curtis _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 11 11:49:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04102 for ; Fri, 11 Jul 2003 11:49:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b08r-0003xs-Gt; Fri, 11 Jul 2003 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b08X-0003xT-6m for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 11:48:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04084 for ; Fri, 11 Jul 2003 11:48:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b08W-0006eQ-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 11:48:40 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19b08V-0006e1-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 11:48:39 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h6BFm0t193926; Fri, 11 Jul 2003 10:48:00 -0500 Message-Id: <5.2.0.9.2.20030711102610.02d1ae60@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: shep@shepfarm.com, Alan Crosswell From: Bill Nickless Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Cc: routing-discussion@ietf.org, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com In-Reply-To: References: <3F0C289A.7030403@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 10:47:52 -0500 -----BEGIN PGP SIGNED MESSAGE----- On Wed, 9 Jul 2003, Alan Crosswell wrote: >There are too many pieces: Namely CDNs like Akamai freeflow streaming. >/a At 10:51 AM 7/9/2003 -0700, shep@shepfarm.com wrote: >Too many non-standard pieces that do not leverage multicast. > >Greg Is this a failure of the Akamai engineers to do the "right thing" and use "standard" Internet multicast? Or is it a failure of "standard" Internet multicast to provide what Akamai engineers need? Has anyone in the MBONED working group talked to the Akamai engineers and asked them why they didn't use standard Internet multicast facilities? Have those lessons learned been incorporated into the process to evolve Internet multicast? Has the solution that Akamai came up with been examined with an eye towards standardization? What about other network-based group communication schemes, such as those popular in the supercomputing community like the Message Passing Initiative (MPI), Parallel Virtual Machine (PVM), and so forth? Recall that the motivation for the original IP multicast work by Cheriton and Deering was to support the V distributed system. Have those communities learned anything in the last 15-20 years that the IP community hasn't yet leveraged, but should? I applaud the Multicast Last-Mile Solutions BOF, and the creation of the Internet Multicast Documentation, Oversight, and Coordination (IMDOC) function within MBONED. I support them as steps towards a process driven by real world requirements, leading to innovative and successful solutions. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPw7cLKwgm7ipJDXBAQHW4AP/WaBjA3eP4iJT0v+rHALPOctF4CLiskQq gJAocdD68/q5ZHVY3+6FA32RiUx+tBjf/GdyVOgU2QYhywx7Vd8zq6v7NiY93WPH FK8VSGDsCu+HqW1QTBZNyZOHXIlUZTTu+6Y8aJcIG5a6pzvWt3uWniRVrQRVIQbV s+6ZBBA/p/M= =sSgn -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 11 11:49:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04117 for ; Fri, 11 Jul 2003 11:49:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b099-0003ym-3i for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 11:49:19 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BFnJKc015292 for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 11:49:19 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b08r-0003xs-Gt; Fri, 11 Jul 2003 11:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b08X-0003xT-6m for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 11:48:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04084 for ; Fri, 11 Jul 2003 11:48:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b08W-0006eQ-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 11:48:40 -0400 Received: from cliff.mcs.anl.gov ([140.221.9.17] helo=mcs.anl.gov) by ietf-mx with esmtp (Exim 4.12) id 19b08V-0006e1-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 11:48:39 -0400 Received: from charge.mcs.anl.gov (charge.mcs.anl.gov [140.221.9.213]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h6BFm0t193926; Fri, 11 Jul 2003 10:48:00 -0500 Message-Id: <5.2.0.9.2.20030711102610.02d1ae60@pop.mcs.anl.gov> X-Sender: nickless@pop.mcs.anl.gov X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: shep@shepfarm.com, Alan Crosswell From: Bill Nickless Subject: Re: BOF Agenda - Multicast Last-Mile Solutions Cc: routing-discussion@ietf.org, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu, mtp@shepfarm.com In-Reply-To: References: <3F0C289A.7030403@columbia.edu> Mime-Version: 1.0 Content-Type: text/plain Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 10:47:52 -0500 -----BEGIN PGP SIGNED MESSAGE----- On Wed, 9 Jul 2003, Alan Crosswell wrote: >There are too many pieces: Namely CDNs like Akamai freeflow streaming. >/a At 10:51 AM 7/9/2003 -0700, shep@shepfarm.com wrote: >Too many non-standard pieces that do not leverage multicast. > >Greg Is this a failure of the Akamai engineers to do the "right thing" and use "standard" Internet multicast? Or is it a failure of "standard" Internet multicast to provide what Akamai engineers need? Has anyone in the MBONED working group talked to the Akamai engineers and asked them why they didn't use standard Internet multicast facilities? Have those lessons learned been incorporated into the process to evolve Internet multicast? Has the solution that Akamai came up with been examined with an eye towards standardization? What about other network-based group communication schemes, such as those popular in the supercomputing community like the Message Passing Initiative (MPI), Parallel Virtual Machine (PVM), and so forth? Recall that the motivation for the original IP multicast work by Cheriton and Deering was to support the V distributed system. Have those communities learned anything in the last 15-20 years that the IP community hasn't yet leveraged, but should? I applaud the Multicast Last-Mile Solutions BOF, and the creation of the Internet Multicast Documentation, Oversight, and Coordination (IMDOC) function within MBONED. I support them as steps towards a process driven by real world requirements, leading to innovative and successful solutions. === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless@mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQCVAwUBPw7cLKwgm7ipJDXBAQHW4AP/WaBjA3eP4iJT0v+rHALPOctF4CLiskQq gJAocdD68/q5ZHVY3+6FA32RiUx+tBjf/GdyVOgU2QYhywx7Vd8zq6v7NiY93WPH FK8VSGDsCu+HqW1QTBZNyZOHXIlUZTTu+6Y8aJcIG5a6pzvWt3uWniRVrQRVIQbV s+6ZBBA/p/M= =sSgn -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 11 15:15:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11940 for ; Fri, 11 Jul 2003 15:15:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3MD-0002DH-Tm; Fri, 11 Jul 2003 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3Ld-0002CV-Vw for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11791 for ; Fri, 11 Jul 2003 15:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3Lc-0000pl-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:14:24 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19b3Lb-0000pi-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:14:23 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA03761; Fri, 11 Jul 2003 12:13:43 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA25990; Fri, 11 Jul 2003 12:14:20 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h6BJCKe00527; Fri, 11 Jul 2003 12:12:20 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Jul 2003 15:12:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Two strawpeople for last mile multicast Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNHxGs7UcGh3t66QA21qIMm9SvMeQAE7a8g From: "Manfredi, Albert E" To: Cc: , X-OriginalArrivalTime: 11 Jul 2003 19:12:23.0679 (UTC) FILETIME=[5BE9A0F0:01C347E0] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 15:12:23 -0400 Content-Transfer-Encoding: quoted-printable From the discussion so far, I gather that a couple of the problems that = have to be solved are (a) how to count group membership and (b) how to = allow multicast routers to unicast multicast packets through edge = routers, to the group members. Taking each one independently at first, how about: 1. Counting membership. All that's required here is to have an optional IGMP mode whereby each = group member is made to respond to IGMP queries by using the (unicast) = source address of the querier. That way, no other member will hear the = join report, and every member will be forced to send these join reports. = The multicast router can keep track. Now that each multicast router has = info on every host's membership, that info can be passed back to = whomever needs it, in an unspecified manner. For example, if PIM-SM is = used, it shouldn't be difficult to send the membership info back to the = RP? In any event, this part of the problem affects only the multicast = routers and whoever needs to keep track of overall membership. 2. Unicast the multicast packet. The problem here is to preserve the IP group address information = somehow, while creating a unicast packet which is originated by the = closest multicast router to each host. Many people expressed a dislike = for some sort of tunnel. I agree. How difficult would it be to create a = new IP header option, which would incorporate (S, G)? This ought to work = for IPv4 or IPv6. When this new option is invoked, the end user knows to = read the incoming packet as a multicast packet. The IP Souce Address of = the packet would be the multicast router's source address, but the = actual multicast source address is preserved, along with the group = address, in the new option overhead words (making this compatible with = SSM).=20 3. IGMP in the unicast-only edge router environment. IGMP relies on multicast addressing entirely. What if IGMP frames were = sent by the multicast router to each member of the group using the = scheme described in #2 above? A well-known UDP Port ID could be used to = differentiate this IGMP "unicast multicast" packet from the normal data = "unicast multicast" packets. The source address incorporated in (S,G) in = the new IP header option words, for this unicast IGMP query, would match = the IP Source Address of the packet, both source addressing being the = address of the closest multicast router. 4. To which hosts are IGMP all hosts queries sent? With normal IGMP, all hosts queries are sent to the "all hosts" = multicast address. Also, with normal IGMP, hosts can send join reports = immediately, without waiting for an IGMP query. Neither of these = mechanisms can work here. Can we postulate a separate "cold start" = mechanism here? Such as a web site, which permits hosts to indicate they = want to join a particular multicast group, which in turn causes the = appropriate multicast router for that host to start sending the unicast = IGMP queries to that host? At which point, of course, the joiner will = know the unicast address of the multicast router? Etc. etc.? Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 11 15:15:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11942 for ; Fri, 11 Jul 2003 15:15:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3MU-0002ER-5A for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:15:18 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BJFIT0008575 for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:15:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3MD-0002DH-Tm; Fri, 11 Jul 2003 15:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3Ld-0002CV-Vw for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:14:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11791 for ; Fri, 11 Jul 2003 15:14:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3Lc-0000pl-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:14:24 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx with esmtp (Exim 4.12) id 19b3Lb-0000pi-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:14:23 -0400 Received: from slb-av-02.boeing.com ([129.172.13.7]) by slb-smtpout-01.boeing.com (8.9.2/8.8.5-M2) with ESMTP id MAA03761; Fri, 11 Jul 2003 12:13:43 -0700 (PDT) Received: from blv-hub-01.boeing.com (localhost [127.0.0.1]) by slb-av-02.boeing.com (8.9.3p2/8.9.2/MBS-AV-02) with ESMTP id MAA25990; Fri, 11 Jul 2003 12:14:20 -0700 (PDT) Received: from xch-nebh-01.ne.nos.boeing.com (xch-nebh-01.ne.nos.boeing.com [128.225.80.200]) by blv-hub-01.boeing.com (8.11.3/8.11.3/MBS-LDAP-01) with ESMTP id h6BJCKe00527; Fri, 11 Jul 2003 12:12:20 -0700 (PDT) Received: from xch-ne-01.ne.nos.boeing.com ([128.225.80.201]) by xch-nebh-01.ne.nos.boeing.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 11 Jul 2003 15:12:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6334.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Two strawpeople for last mile multicast Message-ID: Thread-Topic: BOF Agenda - Multicast Last-Mile Solutions Thread-Index: AcNHxGs7UcGh3t66QA21qIMm9SvMeQAE7a8g From: "Manfredi, Albert E" To: Cc: , X-OriginalArrivalTime: 11 Jul 2003 19:12:23.0679 (UTC) FILETIME=[5BE9A0F0:01C347E0] Content-Transfer-Encoding: quoted-printable Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 15:12:23 -0400 Content-Transfer-Encoding: quoted-printable From the discussion so far, I gather that a couple of the problems that = have to be solved are (a) how to count group membership and (b) how to = allow multicast routers to unicast multicast packets through edge = routers, to the group members. Taking each one independently at first, how about: 1. Counting membership. All that's required here is to have an optional IGMP mode whereby each = group member is made to respond to IGMP queries by using the (unicast) = source address of the querier. That way, no other member will hear the = join report, and every member will be forced to send these join reports. = The multicast router can keep track. Now that each multicast router has = info on every host's membership, that info can be passed back to = whomever needs it, in an unspecified manner. For example, if PIM-SM is = used, it shouldn't be difficult to send the membership info back to the = RP? In any event, this part of the problem affects only the multicast = routers and whoever needs to keep track of overall membership. 2. Unicast the multicast packet. The problem here is to preserve the IP group address information = somehow, while creating a unicast packet which is originated by the = closest multicast router to each host. Many people expressed a dislike = for some sort of tunnel. I agree. How difficult would it be to create a = new IP header option, which would incorporate (S, G)? This ought to work = for IPv4 or IPv6. When this new option is invoked, the end user knows to = read the incoming packet as a multicast packet. The IP Souce Address of = the packet would be the multicast router's source address, but the = actual multicast source address is preserved, along with the group = address, in the new option overhead words (making this compatible with = SSM).=20 3. IGMP in the unicast-only edge router environment. IGMP relies on multicast addressing entirely. What if IGMP frames were = sent by the multicast router to each member of the group using the = scheme described in #2 above? A well-known UDP Port ID could be used to = differentiate this IGMP "unicast multicast" packet from the normal data = "unicast multicast" packets. The source address incorporated in (S,G) in = the new IP header option words, for this unicast IGMP query, would match = the IP Source Address of the packet, both source addressing being the = address of the closest multicast router. 4. To which hosts are IGMP all hosts queries sent? With normal IGMP, all hosts queries are sent to the "all hosts" = multicast address. Also, with normal IGMP, hosts can send join reports = immediately, without waiting for an IGMP query. Neither of these = mechanisms can work here. Can we postulate a separate "cold start" = mechanism here? Such as a web site, which permits hosts to indicate they = want to join a particular multicast group, which in turn causes the = appropriate multicast router for that host to start sending the unicast = IGMP queries to that host? At which point, of course, the joiner will = know the unicast address of the multicast router? Etc. etc.? Bert _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 11 15:31:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13094 for ; Fri, 11 Jul 2003 15:31:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3bk-0003wf-Pp; Fri, 11 Jul 2003 15:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3bK-0003rg-Iu for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:30:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12861 for ; Fri, 11 Jul 2003 15:30:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3bJ-00014l-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:30:37 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19b3bI-00012i-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:30:36 -0400 Received: from maroon.juniper.net (maroon.juniper.net [172.17.28.131]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6BJTtu96984; Fri, 11 Jul 2003 12:29:55 -0700 (PDT) (envelope-from lenny@juniper.net) Received: from localhost (lenny@localhost) by maroon.juniper.net (8.11.6/8.11.3) with ESMTP id h6BJTth99841; Fri, 11 Jul 2003 12:29:55 -0700 (PDT) (envelope-from lenny@juniper.net) X-Authentication-Warning: maroon.juniper.net: lenny owned process doing -bs From: Leonard Giuliano To: "Manfredi, Albert E" cc: routing-discussion@ietf.org, "" , "" Subject: Re: Two strawpeople for last mile multicast In-Reply-To: Message-ID: <20030711122609.B81666@maroon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 12:29:55 -0700 (PDT) On Fri, 11 Jul 2003, Manfredi, Albert E wrote: -) >From the discussion so far, I gather that a couple of the problems -) that have to be solved are (a) how to count group membership and (b) I don't think counting group members is a goal of this effort. Counting viewers is a task that can be easily handled by the applications themselves. Indeed, some apps already do this today. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 11 15:31:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13096 for ; Fri, 11 Jul 2003 15:31:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3bq-000409-Mp for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:31:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BJVAGa015356 for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:31:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3bk-0003wf-Pp; Fri, 11 Jul 2003 15:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3bK-0003rg-Iu for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:30:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12861 for ; Fri, 11 Jul 2003 15:30:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3bJ-00014l-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:30:37 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19b3bI-00012i-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:30:36 -0400 Received: from maroon.juniper.net (maroon.juniper.net [172.17.28.131]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6BJTtu96984; Fri, 11 Jul 2003 12:29:55 -0700 (PDT) (envelope-from lenny@juniper.net) Received: from localhost (lenny@localhost) by maroon.juniper.net (8.11.6/8.11.3) with ESMTP id h6BJTth99841; Fri, 11 Jul 2003 12:29:55 -0700 (PDT) (envelope-from lenny@juniper.net) X-Authentication-Warning: maroon.juniper.net: lenny owned process doing -bs From: Leonard Giuliano To: "Manfredi, Albert E" cc: routing-discussion@ietf.org, "" , "" Subject: Re: Two strawpeople for last mile multicast In-Reply-To: Message-ID: <20030711122609.B81666@maroon.juniper.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 12:29:55 -0700 (PDT) On Fri, 11 Jul 2003, Manfredi, Albert E wrote: -) >From the discussion so far, I gather that a couple of the problems -) that have to be solved are (a) how to count group membership and (b) I don't think counting group members is a goal of this effort. Counting viewers is a task that can be easily handled by the applications themselves. Indeed, some apps already do this today. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 11 15:39:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13784 for ; Fri, 11 Jul 2003 15:39:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3jR-0005Uh-L0; Fri, 11 Jul 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3if-0005P8-Fu for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13718 for ; Fri, 11 Jul 2003 15:38:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3id-0001Lz-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:38:11 -0400 Received: from [204.101.26.58] (helo=hq.lindsayelec.com) by ietf-mx with esmtp (Exim 4.12) id 19b3ic-0001Lw-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:38:11 -0400 Received: from rflooker1 ([191.1.2.48]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Fri, 11 Jul 2003 15:38:08 -0400 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: routing-discussion@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Last mile multicast Message-ID: <20030711193808981.AAA359@hq.lindsayelec.com@rflooker1> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 15:38:08 -0400 >On Fri, 11 Jul 2003, Manfredi, Albert E wrote: >-) >From the discussion so far, I gather that a couple of the problems >-) that have to be solved are (a) how to count group membership and (b) >I don't think counting group members is a goal of this effort. Counting >viewers is a task that can be easily handled by the applications >themselves. Indeed, some apps already do this today. I don't get into these discussions much, though I enjoy reading them a lot. Ahhh. As a cable TV guy, our future involves multicast over IP totally. I guess I don't know the deficientcies now? I thought any router could bust up, break out, etc messages and the major problem was too many dumb routers and various filters that don't like multicast IP's. Since a lot of people like myself might not understand this... What's wrong so far? Regs, Dan _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 11 15:39:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13799 for ; Fri, 11 Jul 2003 15:39:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3jX-0005Vs-SF for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BJd7XF021171 for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:39:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3jR-0005Uh-L0; Fri, 11 Jul 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3if-0005P8-Fu for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:38:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13718 for ; Fri, 11 Jul 2003 15:38:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3id-0001Lz-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:38:11 -0400 Received: from [204.101.26.58] (helo=hq.lindsayelec.com) by ietf-mx with esmtp (Exim 4.12) id 19b3ic-0001Lw-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:38:11 -0400 Received: from rflooker1 ([191.1.2.48]) by hq.lindsayelec.com (Post.Office MTA v3.5.3 release 223 ID# 0-66079U100L100S0V35) with SMTP id com for ; Fri, 11 Jul 2003 15:38:08 -0400 X-Sender: dank@191.1.2.250 X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: routing-discussion@ietf.org From: dank@hq.lindsayelec.com (Dan Kolis) Subject: Last mile multicast Message-ID: <20030711193808981.AAA359@hq.lindsayelec.com@rflooker1> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 15:38:08 -0400 >On Fri, 11 Jul 2003, Manfredi, Albert E wrote: >-) >From the discussion so far, I gather that a couple of the problems >-) that have to be solved are (a) how to count group membership and (b) >I don't think counting group members is a goal of this effort. Counting >viewers is a task that can be easily handled by the applications >themselves. Indeed, some apps already do this today. I don't get into these discussions much, though I enjoy reading them a lot. Ahhh. As a cable TV guy, our future involves multicast over IP totally. I guess I don't know the deficientcies now? I thought any router could bust up, break out, etc messages and the major problem was too many dumb routers and various filters that don't like multicast IP's. Since a lot of people like myself might not understand this... What's wrong so far? Regs, Dan _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 11 15:56:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14359 for ; Fri, 11 Jul 2003 15:56:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3zt-0006jI-GJ; Fri, 11 Jul 2003 15:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3yx-0006i3-AV for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:55:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14330 for ; Fri, 11 Jul 2003 15:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3yt-0001Y8-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:54:59 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19b3ys-0001Y5-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:54:58 -0400 Received: from liming-pc.redback.com (liming-pc.redback.com [155.53.44.79]) by prattle.redback.com (Postfix) with ESMTP id 8F3649B8991; Fri, 11 Jul 2003 12:53:32 -0700 (PDT) Received: (from lwei@localhost) by liming-pc.redback.com (8.11.3nb1/8.8.8/null redback bsdclient) id h6BJrW621897; Fri, 11 Jul 2003 12:53:32 -0700 (PDT) Message-Id: <200307111953.h6BJrW621897@liming-pc.redback.com> From: Liming Wei To: albert.e.manfredi@boeing.com Cc: routing-discussion@ietf.org, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu In-reply-to: (albert.e.manfredi@boeing.com) Subject: Re: Two strawpeople for last mile multicast Reply-To: lwei@redback.com References: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 12:53:32 -0700 (PDT) > From: "Manfredi, Albert E" > > >From the discussion so far, I gather that a couple of the problems > >that have to be solved are (a) how to count group membership and > >(b) how to allow multicast routers to unicast multicast packets > >through edge routers, to the group members. > > Taking each one independently at first, how about: > > 1. Counting membership. > > All that's required here is to have an optional IGMP mode whereby > each group member is made to respond to IGMP queries by using the > (unicast) source address of the querier. That way, no other member > will hear the join report, and every member will be forced to send > these join reports. The multicast router can keep track. Now that > each multicast router has info on every host's membership, that info > can be passed back to whomever needs it, in an unspecified manner. > For example, if PIM-SM is used, it shouldn't be difficult to send > the membership info back to the RP? In any event, this part of the > problem affects only the multicast routers and whoever needs to keep > track of overall membership. This is clever, but the problem is it fails the IGMP snooping switches in between the hosts and the last "router". There are almost always some layer 2 IGMP snooping devices in between them. Also, there are already well established and widely-available solutions to collect accounting data from broadband subscribers. As long as the last hop "router" has the membership information, it will be sufficient for all magics to happen. There is no need to propogate such information via a routing protocol to the PIM RP. > > 2. Unicast the multicast packet. > > The problem here is to preserve the IP group address information > somehow, while creating a unicast packet which is originated by the > closest multicast router to each host. Many people expressed a > dislike for some sort of tunnel. I agree. How difficult would it be > to create a new IP header option, which would incorporate (S, G)? > This ought to work for IPv4 or IPv6. When this new option is > invoked, the end user knows to read the incoming packet as a > multicast packet. The IP Souce Address of the packet would be the > multicast router's source address, but the actual multicast source > address is preserved, along with the group address, in the new > option overhead words (making this compatible with SSM). The cost of turning on multicast on the last hop router can not be avoided or postponed. Period. I know there are some interests in trying this out. But it won't really have the effect folks imagined. Neither the subscriber nor the last mile service provider or even the content provider will see a big difference. They will conclude that multicast does not really matter. > > 3. IGMP in the unicast-only edge router environment. > > IGMP relies on multicast addressing entirely. What if IGMP frames > were sent by the multicast router to each member of the group using > the scheme described in #2 above? A well-known UDP Port ID could be > used to differentiate this IGMP "unicast multicast" packet from the > normal data "unicast multicast" packets. The source address > incorporated in (S,G) in the new IP header option words, for this > unicast IGMP query, would match the IP Source Address of the packet, > both source addressing being the address of the closest multicast > router. See comment above. -Liming > > 4. To which hosts are IGMP all hosts queries sent? > > With normal IGMP, all hosts queries are sent to the "all hosts" > multicast address. Also, with normal IGMP, hosts can send join > reports immediately, without waiting for an IGMP query. Neither of > these mechanisms can work here. Can we postulate a separate "cold > start" mechanism here? Such as a web site, which permits hosts to > indicate they want to join a particular multicast group, which in > turn causes the appropriate multicast router for that host to start > sending the unicast IGMP queries to that host? At which point, of > course, the joiner will know the unicast address of the multicast > router? Etc. etc.? > > Bert > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 11 15:56:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14361 for ; Fri, 11 Jul 2003 15:56:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b402-0006l0-Vy for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:56:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BJuAsD025968 for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 15:56:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3zt-0006jI-GJ; Fri, 11 Jul 2003 15:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b3yx-0006i3-AV for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 15:55:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14330 for ; Fri, 11 Jul 2003 15:54:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b3yt-0001Y8-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:54:59 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx with esmtp (Exim 4.12) id 19b3ys-0001Y5-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 15:54:58 -0400 Received: from liming-pc.redback.com (liming-pc.redback.com [155.53.44.79]) by prattle.redback.com (Postfix) with ESMTP id 8F3649B8991; Fri, 11 Jul 2003 12:53:32 -0700 (PDT) Received: (from lwei@localhost) by liming-pc.redback.com (8.11.3nb1/8.8.8/null redback bsdclient) id h6BJrW621897; Fri, 11 Jul 2003 12:53:32 -0700 (PDT) Message-Id: <200307111953.h6BJrW621897@liming-pc.redback.com> From: Liming Wei To: albert.e.manfredi@boeing.com Cc: routing-discussion@ietf.org, wg-multicast@internet2.edu, mboned@network-services.uoregon.edu In-reply-to: (albert.e.manfredi@boeing.com) Subject: Re: Two strawpeople for last mile multicast Reply-To: lwei@redback.com References: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 12:53:32 -0700 (PDT) > From: "Manfredi, Albert E" > > >From the discussion so far, I gather that a couple of the problems > >that have to be solved are (a) how to count group membership and > >(b) how to allow multicast routers to unicast multicast packets > >through edge routers, to the group members. > > Taking each one independently at first, how about: > > 1. Counting membership. > > All that's required here is to have an optional IGMP mode whereby > each group member is made to respond to IGMP queries by using the > (unicast) source address of the querier. That way, no other member > will hear the join report, and every member will be forced to send > these join reports. The multicast router can keep track. Now that > each multicast router has info on every host's membership, that info > can be passed back to whomever needs it, in an unspecified manner. > For example, if PIM-SM is used, it shouldn't be difficult to send > the membership info back to the RP? In any event, this part of the > problem affects only the multicast routers and whoever needs to keep > track of overall membership. This is clever, but the problem is it fails the IGMP snooping switches in between the hosts and the last "router". There are almost always some layer 2 IGMP snooping devices in between them. Also, there are already well established and widely-available solutions to collect accounting data from broadband subscribers. As long as the last hop "router" has the membership information, it will be sufficient for all magics to happen. There is no need to propogate such information via a routing protocol to the PIM RP. > > 2. Unicast the multicast packet. > > The problem here is to preserve the IP group address information > somehow, while creating a unicast packet which is originated by the > closest multicast router to each host. Many people expressed a > dislike for some sort of tunnel. I agree. How difficult would it be > to create a new IP header option, which would incorporate (S, G)? > This ought to work for IPv4 or IPv6. When this new option is > invoked, the end user knows to read the incoming packet as a > multicast packet. The IP Souce Address of the packet would be the > multicast router's source address, but the actual multicast source > address is preserved, along with the group address, in the new > option overhead words (making this compatible with SSM). The cost of turning on multicast on the last hop router can not be avoided or postponed. Period. I know there are some interests in trying this out. But it won't really have the effect folks imagined. Neither the subscriber nor the last mile service provider or even the content provider will see a big difference. They will conclude that multicast does not really matter. > > 3. IGMP in the unicast-only edge router environment. > > IGMP relies on multicast addressing entirely. What if IGMP frames > were sent by the multicast router to each member of the group using > the scheme described in #2 above? A well-known UDP Port ID could be > used to differentiate this IGMP "unicast multicast" packet from the > normal data "unicast multicast" packets. The source address > incorporated in (S,G) in the new IP header option words, for this > unicast IGMP query, would match the IP Source Address of the packet, > both source addressing being the address of the closest multicast > router. See comment above. -Liming > > 4. To which hosts are IGMP all hosts queries sent? > > With normal IGMP, all hosts queries are sent to the "all hosts" > multicast address. Also, with normal IGMP, hosts can send join > reports immediately, without waiting for an IGMP query. Neither of > these mechanisms can work here. Can we postulate a separate "cold > start" mechanism here? Such as a web site, which permits hosts to > indicate they want to join a particular multicast group, which in > turn causes the appropriate multicast router for that host to start > sending the unicast IGMP queries to that host? At which point, of > course, the joiner will know the unicast address of the multicast > router? Etc. etc.? > > Bert > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 11 19:47:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25318 for ; Fri, 11 Jul 2003 19:47:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7bR-0005sH-Hm; Fri, 11 Jul 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7ab-0005rb-9c for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 19:46:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25208 for ; Fri, 11 Jul 2003 19:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b7aZ-0004yl-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 19:46:07 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19b7aY-0004yD-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 19:46:06 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 7AC5534465; Fri, 11 Jul 2003 17:02:50 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.1.1.43]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6BNjZYB016879; Fri, 11 Jul 2003 16:45:35 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id h6BNjZAC014235; Fri, 11 Jul 2003 16:45:35 -0700 Message-Id: <200307112345.h6BNjZAC014235@dino-pc.procket.com> From: Dino Farinacci To: fenner@research.att.com Cc: Radia.Perlman@sun.com, mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org In-reply-to: <200307101703.h6AH3or27652@windsor.research.att.com> (message from Bill Fenner on Thu, 10 Jul 2003 10:03:49 -0700) Subject: Re: [Mtp] the more things change, the more they stay the same References: <200307101703.h6AH3or27652@windsor.research.att.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 16:45:35 -0700 >> Actually the model that Tom is talking about sounds kind of like >> REUNITE (Infocom 2000), which just uses unicast address+port pairs >> to identify multicast groups. But then a multicast-capable router can't turn this join-request into a PIM Join to send upstream into the native-multicast topology. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 11 19:47:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25333 for ; Fri, 11 Jul 2003 19:47:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7bn-0005uW-3U for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 19:47:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6BNlN8Q022695 for routing-discussion-archive@odin.ietf.org; Fri, 11 Jul 2003 19:47:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7bR-0005sH-Hm; Fri, 11 Jul 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19b7ab-0005rb-9c for routing-discussion@optimus.ietf.org; Fri, 11 Jul 2003 19:46:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25208 for ; Fri, 11 Jul 2003 19:46:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19b7aZ-0004yl-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 19:46:07 -0400 Received: from dmz2.procket.com ([65.174.124.37]) by ietf-mx with esmtp (Exim 4.12) id 19b7aY-0004yD-00 for routing-discussion@ietf.org; Fri, 11 Jul 2003 19:46:06 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz2.procket.com (Postfix) with ESMTP id 7AC5534465; Fri, 11 Jul 2003 17:02:50 -0700 (PDT) Received: from dino-pc.procket.com (dino-pc.procket.com [10.1.1.43]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6BNjZYB016879; Fri, 11 Jul 2003 16:45:35 -0700 (PDT) Received: (from dino@localhost) by dino-pc.procket.com (8.12.1/8.12.1) id h6BNjZAC014235; Fri, 11 Jul 2003 16:45:35 -0700 Message-Id: <200307112345.h6BNjZAC014235@dino-pc.procket.com> From: Dino Farinacci To: fenner@research.att.com Cc: Radia.Perlman@sun.com, mtp@shepfarm.com, mboned@network-services.uoregon.edu, wg-multicast@internet2.edu, routing-discussion@ietf.org In-reply-to: <200307101703.h6AH3or27652@windsor.research.att.com> (message from Bill Fenner on Thu, 10 Jul 2003 10:03:49 -0700) Subject: Re: [Mtp] the more things change, the more they stay the same References: <200307101703.h6AH3or27652@windsor.research.att.com> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 11 Jul 2003 16:45:35 -0700 >> Actually the model that Tom is talking about sounds kind of like >> REUNITE (Infocom 2000), which just uses unicast address+port pairs >> to identify multicast groups. But then a multicast-capable router can't turn this join-request into a PIM Join to send upstream into the native-multicast topology. Dino _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 15 05:23:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09110 for ; Tue, 15 Jul 2003 05:23:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM1V-0001yC-3p; Tue, 15 Jul 2003 05:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bkVm-0006QF-Si for routing-discussion@optimus.ietf.org; Sun, 13 Jul 2003 13:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00584 for ; Sun, 13 Jul 2003 13:19:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bkVk-0006Mt-00 for routing-discussion@ietf.org; Sun, 13 Jul 2003 13:19:44 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19bkVj-0006Mm-00 for routing-discussion@ietf.org; Sun, 13 Jul 2003 13:19:43 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8DEF123C31; Sun, 13 Jul 2003 10:28:38 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6DHJBYB017949; Sun, 13 Jul 2003 10:19:11 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 13 Jul 2003 10:19:11 -0700 From: Greg Shepherd To: Ross Finlayson Cc: mtp@shepfarm.com, , , , Subject: MLM BOF Room Change!! In-Reply-To: <4.3.1.1.20030711214420.00bbfae0@laptop-localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 13 Jul 2003 17:19:11.0314 (UTC) FILETIME=[E02C7B20:01C34962] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:19:10 -0700 (PDT) *, Hey, we got the BOF moved to room IK (same time slot) so the festivities can be mcasted to those unable to attend. See you all tomorrow night. Thanks, Greg On Fri, 11 Jul 2003, Ross Finlayson wrote: > To Greg Shepherd et al, > > Do you know yet whether or not this BOF will be multicast? The IETF > multicast schedule still > shows an open slot for that time (Monday 1930-2200), but the multicast room > for channel 1 - Hall IK - appears to be available. > > Like many people, I'm not able to make it to Vienna, but I'll be watching > the MBone sessions from home (using UMTP - a proven 'last mile' multicast > tunneling protocol that's been in use for several years :-) > > Ross. > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 15 05:23:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09147 for ; Tue, 15 Jul 2003 05:23:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM1q-000201-BM for routing-discussion-archive@odin.ietf.org; Tue, 15 Jul 2003 05:23:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6F9NMLj007640 for routing-discussion-archive@odin.ietf.org; Tue, 15 Jul 2003 05:23:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19cM1V-0001yC-3p; Tue, 15 Jul 2003 05:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19bkVm-0006QF-Si for routing-discussion@optimus.ietf.org; Sun, 13 Jul 2003 13:19:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00584 for ; Sun, 13 Jul 2003 13:19:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19bkVk-0006Mt-00 for routing-discussion@ietf.org; Sun, 13 Jul 2003 13:19:44 -0400 Received: from dmz1.procket.com ([65.174.124.36]) by ietf-mx with esmtp (Exim 4.12) id 19bkVj-0006Mm-00 for routing-discussion@ietf.org; Sun, 13 Jul 2003 13:19:43 -0400 Received: from miata.procket.com (zeus-d-1.procket.com [65.174.124.60]) by dmz1.procket.com (Postfix) with ESMTP id 8DEF123C31; Sun, 13 Jul 2003 10:28:38 -0700 (PDT) Received: from exchangefe2.na.procket.com (email.na.procket.com [10.1.7.252]) by miata.procket.com (8.12.1/8.12.1) with ESMTP id h6DHJBYB017949; Sun, 13 Jul 2003 10:19:11 -0700 (PDT) Received: from miata.procket.com ([10.1.1.1]) by exchangefe2.na.procket.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 13 Jul 2003 10:19:11 -0700 From: Greg Shepherd To: Ross Finlayson Cc: mtp@shepfarm.com, , , , Subject: MLM BOF Room Change!! In-Reply-To: <4.3.1.1.20030711214420.00bbfae0@laptop-localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 13 Jul 2003 17:19:11.0314 (UTC) FILETIME=[E02C7B20:01C34962] Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sun, 13 Jul 2003 10:19:10 -0700 (PDT) *, Hey, we got the BOF moved to room IK (same time slot) so the festivities can be mcasted to those unable to attend. See you all tomorrow night. Thanks, Greg On Fri, 11 Jul 2003, Ross Finlayson wrote: > To Greg Shepherd et al, > > Do you know yet whether or not this BOF will be multicast? The IETF > multicast schedule still > shows an open slot for that time (Monday 1930-2200), but the multicast room > for channel 1 - Hall IK - appears to be available. > > Like many people, I'm not able to make it to Vienna, but I'll be watching > the MBone sessions from home (using UMTP - a proven 'last mile' multicast > tunneling protocol that's been in use for several years :-) > > Ross. > > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 22 12:58:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19582 for ; Tue, 22 Jul 2003 12:58:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0Sf-0006uh-5D; Tue, 22 Jul 2003 12:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0Rj-0006sI-Be for routing-discussion@optimus.ietf.org; Tue, 22 Jul 2003 12:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19509 for ; Tue, 22 Jul 2003 12:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0Rc-0005xp-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 12:56:56 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19f0RS-0005xF-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 12:56:46 -0400 Received: from [192.168.1.33] (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 6A5BC20299 for ; Tue, 22 Jul 2003 10:57:50 -0600 (MDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: Open Routing Area meeting in Vienna From: Danny McPherson To: Message-ID: In-Reply-To: <200307082300.h68N0AC04550@windsor.research.att.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 10:55:19 -0600 Content-Transfer-Encoding: 7bit I missed the latter part of the panel discussion in the Routing Area meeting in Vienna. Although I doubt any conclusions were reached, were there any action items that came about (e.g., produce problem statement, applicability notes or other)? -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 22 13:27:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20223 for ; Tue, 22 Jul 2003 13:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0uj-00082p-8j; Tue, 22 Jul 2003 13:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0uh-00082e-Aq for routing-discussion@optimus.ietf.org; Tue, 22 Jul 2003 13:26:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20163 for ; Tue, 22 Jul 2003 13:26:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0uf-00066M-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 13:26:57 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19f0uU-00065m-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 13:26:46 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6MHNtqq004752; Tue, 22 Jul 2003 10:23:55 -0700 From: David Meyer To: Danny McPherson Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030722102355.A4716@1-4-5.net> References: <200307082300.h68N0AC04550@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from danny@tcb.net on Tue, Jul 22, 2003 at 10:55:19AM -0600 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 10:23:55 -0700 >> I missed the latter part of the panel discussion in the Routing Area meeting >> in Vienna. Although I doubt any conclusions were reached, were there any >> action items that came about (e.g., produce problem statement, applicability >> notes or other)? I had suggested producing a problem statement (http://www.1-4-5.net/~dmm/IETF57/routing_area), which is something I'm working on, though I don't know how much traction there really was for such a thing. In any event, ss soon as I have a strawperson statement I'll post it here. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 22 13:48:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19584 for ; Tue, 22 Jul 2003 12:58:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0T6-0006w2-80 for routing-discussion-archive@odin.ietf.org; Tue, 22 Jul 2003 12:58:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MGwSC8026641 for routing-discussion-archive@odin.ietf.org; Tue, 22 Jul 2003 12:58:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0Sf-0006uh-5D; Tue, 22 Jul 2003 12:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0Rj-0006sI-Be for routing-discussion@optimus.ietf.org; Tue, 22 Jul 2003 12:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19509 for ; Tue, 22 Jul 2003 12:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0Rc-0005xp-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 12:56:56 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19f0RS-0005xF-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 12:56:46 -0400 Received: from [192.168.1.33] (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 6A5BC20299 for ; Tue, 22 Jul 2003 10:57:50 -0600 (MDT) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: Open Routing Area meeting in Vienna From: Danny McPherson To: Message-ID: In-Reply-To: <200307082300.h68N0AC04550@windsor.research.att.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 10:55:19 -0600 Content-Transfer-Encoding: 7bit I missed the latter part of the panel discussion in the Routing Area meeting in Vienna. Although I doubt any conclusions were reached, were there any action items that came about (e.g., produce problem statement, applicability notes or other)? -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 22 14:13:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20224 for ; Tue, 22 Jul 2003 13:27:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0un-00083y-2f for routing-discussion-archive@odin.ietf.org; Tue, 22 Jul 2003 13:27:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6MHR5Kp030977 for routing-discussion-archive@odin.ietf.org; Tue, 22 Jul 2003 13:27:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0uj-00082p-8j; Tue, 22 Jul 2003 13:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f0uh-00082e-Aq for routing-discussion@optimus.ietf.org; Tue, 22 Jul 2003 13:26:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20163 for ; Tue, 22 Jul 2003 13:26:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f0uf-00066M-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 13:26:57 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19f0uU-00065m-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 13:26:46 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6MHNtqq004752; Tue, 22 Jul 2003 10:23:55 -0700 From: David Meyer To: Danny McPherson Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030722102355.A4716@1-4-5.net> References: <200307082300.h68N0AC04550@windsor.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from danny@tcb.net on Tue, Jul 22, 2003 at 10:55:19AM -0600 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 10:23:55 -0700 >> I missed the latter part of the panel discussion in the Routing Area meeting >> in Vienna. Although I doubt any conclusions were reached, were there any >> action items that came about (e.g., produce problem statement, applicability >> notes or other)? I had suggested producing a problem statement (http://www.1-4-5.net/~dmm/IETF57/routing_area), which is something I'm working on, though I don't know how much traction there really was for such a thing. In any event, ss soon as I have a strawperson statement I'll post it here. Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 22 20:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02130 for ; Tue, 22 Jul 2003 20:47:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7mX-0007eQ-Fn; Tue, 22 Jul 2003 20:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7lt-0007eD-DT for routing-discussion@optimus.ietf.org; Tue, 22 Jul 2003 20:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02095 for ; Tue, 22 Jul 2003 20:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f7lr-0000c3-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 20:46:19 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19f7lg-0000bb-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 20:46:08 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6N0jHu06803; Tue, 22 Jul 2003 17:45:17 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id h6N0jHq38340; Tue, 22 Jul 2003 17:45:17 -0700 (PDT) (envelope-from kireeti) From: Kireeti Kompella Message-Id: <200307230045.h6N0jHq38340@kummer.juniper.net> To: danny@tcb.net, dmm@1-4-5.net Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org In-Reply-To: <20030722102355.A4716@1-4-5.net> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 17:45:17 -0700 (PDT) > I had suggested producing a problem statement I second the motion (if this is a motion :-)) > ss soon as I have a strawperson statement I'll > post it here. Wonderful! Kireeti. PS: Good X-philosophy! _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 22 20:47:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02133 for ; Tue, 22 Jul 2003 20:47:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7me-0007fd-E0 for routing-discussion-archive@odin.ietf.org; Tue, 22 Jul 2003 20:47:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6N0l8r9029465 for routing-discussion-archive@odin.ietf.org; Tue, 22 Jul 2003 20:47:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7mX-0007eQ-Fn; Tue, 22 Jul 2003 20:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19f7lt-0007eD-DT for routing-discussion@optimus.ietf.org; Tue, 22 Jul 2003 20:46:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02095 for ; Tue, 22 Jul 2003 20:46:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19f7lr-0000c3-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 20:46:19 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19f7lg-0000bb-00 for routing-discussion@ietf.org; Tue, 22 Jul 2003 20:46:08 -0400 Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6N0jHu06803; Tue, 22 Jul 2003 17:45:17 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: (from kireeti@localhost) by kummer.juniper.net (8.11.6/8.9.3) id h6N0jHq38340; Tue, 22 Jul 2003 17:45:17 -0700 (PDT) (envelope-from kireeti) From: Kireeti Kompella Message-Id: <200307230045.h6N0jHq38340@kummer.juniper.net> To: danny@tcb.net, dmm@1-4-5.net Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org In-Reply-To: <20030722102355.A4716@1-4-5.net> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 22 Jul 2003 17:45:17 -0700 (PDT) > I had suggested producing a problem statement I second the motion (if this is a motion :-)) > ss soon as I have a strawperson statement I'll > post it here. Wonderful! Kireeti. PS: Good X-philosophy! _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 23 08:57:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10192 for ; Wed, 23 Jul 2003 08:57:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJAz-0007jq-7r; Wed, 23 Jul 2003 08:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJAX-0007jb-Bl for routing-discussion@optimus.ietf.org; Wed, 23 Jul 2003 08:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10177 for ; Wed, 23 Jul 2003 08:56:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJAV-0004Ky-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 08:56:31 -0400 Received: from web15207.mail.bjs.yahoo.com ([202.3.77.137]) by ietf-mx with smtp (Exim 4.12) id 19fJAK-0004Kj-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 08:56:21 -0400 Message-ID: <20030723125521.55088.qmail@web15207.mail.bjs.yahoo.com> Received: from [218.72.17.156] by web15207.mail.bjs.yahoo.com via HTTP; Wed, 23 Jul 2003 20:55:21 CST From: =?gb2312?q?Jing=20Shen?= Subject: load distribution and smoothing when route flaps To: end2end-interest@postel.org Cc: routing-discussion@ietf.org, OSPF@PEACH.EASE.LSOFT.COM, te-wg@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA10178 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 23 Jul 2003 20:55:21 +0800 (CST) Content-Transfer-Encoding: quoted-printable Hi, (' spamcontrol ') In past days, we talked with someone from one of the main ISP in China. He present us a question as: how to smooth load migration when the primary outgoing link goes down? The network topo. could be abbreviated as: Secondary outgoing link backup link ----- ------ \ / \ / -------------------- | AS (OSPF) | -------------------- | | primary outgoing link | In normal state, about 90% outgoing traffic flows through primary outgoing link, 10% or less on Secondary link.( the bandwidht of primary is times of secondary link, which is more than backup link) The problem comes when primary outgoing link goes down. At this time, they(ISP engineers) have to redirect traffic to backup link and secondary link manually if the other two links are needed to be used, or only secondary link will carry all traffic. When primary link comes up, the phenomenon is: neary all traffic migrates to primary link and load on primary link may reach 100% or so.=20 the questions: 1. How does those ISPs around make full use of outgoing link capacity as well as guaranteeing service quality? 2. Is there any method proposed to smooth traffic migration in either intra-AS or inter-AS situation? How does those ISPs deal with such situation? 3. Although DiffServ has been discussed for years, they do not deploy it. Why should we talk so much about DS-TE ? =20 4. We've spent a lot time with e2e policy around, but if the traffic delivery method is kept to very simple one, is that skeptible to achive a cost-effective and high performance network without introducing more intellenge into core networks?=20 thanks a lot. regards =3D=3D=3D=3D=3D Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _________________________________________________________ Do You Yahoo!?=20 =CA=EE=C6=DA=B4=F3=C6=AC=C6=EB=BE=DB=D1=C5=BB=A2=CD=A8 =CD=F8=C2=E7=C9=E3= =CF=F1=CD=B7+=D1=C5=BB=A2=CD=A8=B5=F7=C6=B5=CA=D5=D2=F4=BB=FA=B5=C8=C4=E3= =C0=B4=C4=C3 http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.promo.yahoo.com/minisite/me= ssenger1/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 23 08:57:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10196 for ; Wed, 23 Jul 2003 08:57:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJB6-0007ki-R5 for routing-discussion-archive@odin.ietf.org; Wed, 23 Jul 2003 08:57:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NCv8IA029799 for routing-discussion-archive@odin.ietf.org; Wed, 23 Jul 2003 08:57:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJAz-0007jq-7r; Wed, 23 Jul 2003 08:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fJAX-0007jb-Bl for routing-discussion@optimus.ietf.org; Wed, 23 Jul 2003 08:56:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10177 for ; Wed, 23 Jul 2003 08:56:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fJAV-0004Ky-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 08:56:31 -0400 Received: from web15207.mail.bjs.yahoo.com ([202.3.77.137]) by ietf-mx with smtp (Exim 4.12) id 19fJAK-0004Kj-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 08:56:21 -0400 Message-ID: <20030723125521.55088.qmail@web15207.mail.bjs.yahoo.com> Received: from [218.72.17.156] by web15207.mail.bjs.yahoo.com via HTTP; Wed, 23 Jul 2003 20:55:21 CST From: =?gb2312?q?Jing=20Shen?= Subject: load distribution and smoothing when route flaps To: end2end-interest@postel.org Cc: routing-discussion@ietf.org, OSPF@PEACH.EASE.LSOFT.COM, te-wg@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA10178 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 23 Jul 2003 20:55:21 +0800 (CST) Content-Transfer-Encoding: quoted-printable Hi, (' spamcontrol ') In past days, we talked with someone from one of the main ISP in China. He present us a question as: how to smooth load migration when the primary outgoing link goes down? The network topo. could be abbreviated as: Secondary outgoing link backup link ----- ------ \ / \ / -------------------- | AS (OSPF) | -------------------- | | primary outgoing link | In normal state, about 90% outgoing traffic flows through primary outgoing link, 10% or less on Secondary link.( the bandwidht of primary is times of secondary link, which is more than backup link) The problem comes when primary outgoing link goes down. At this time, they(ISP engineers) have to redirect traffic to backup link and secondary link manually if the other two links are needed to be used, or only secondary link will carry all traffic. When primary link comes up, the phenomenon is: neary all traffic migrates to primary link and load on primary link may reach 100% or so.=20 the questions: 1. How does those ISPs around make full use of outgoing link capacity as well as guaranteeing service quality? 2. Is there any method proposed to smooth traffic migration in either intra-AS or inter-AS situation? How does those ISPs deal with such situation? 3. Although DiffServ has been discussed for years, they do not deploy it. Why should we talk so much about DS-TE ? =20 4. We've spent a lot time with e2e policy around, but if the traffic delivery method is kept to very simple one, is that skeptible to achive a cost-effective and high performance network without introducing more intellenge into core networks?=20 thanks a lot. regards =3D=3D=3D=3D=3D Jing Shen State Key Lab of CAD&CG ZheJiang University(YuQuan) HangZhou, ZheJiang Province 310027 P.R.China _________________________________________________________ Do You Yahoo!?=20 =CA=EE=C6=DA=B4=F3=C6=AC=C6=EB=BE=DB=D1=C5=BB=A2=CD=A8 =CD=F8=C2=E7=C9=E3= =CF=F1=CD=B7+=D1=C5=BB=A2=CD=A8=B5=F7=C6=B5=CA=D5=D2=F4=BB=FA=B5=C8=C4=E3= =C0=B4=C4=C3 http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.promo.yahoo.com/minisite/me= ssenger1/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 23 10:41:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15406 for ; Wed, 23 Jul 2003 10:41:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKnc-0004zA-Vk; Wed, 23 Jul 2003 10:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKnG-0004ys-Ld for routing-discussion@optimus.ietf.org; Wed, 23 Jul 2003 10:40:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15384 for ; Wed, 23 Jul 2003 10:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKnE-000574-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 10:40:36 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19fKn3-00056v-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 10:40:25 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6NEdj0e011816; Wed, 23 Jul 2003 07:39:45 -0700 From: David Meyer To: Kireeti Kompella Cc: danny@tcb.net, routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030723073945.C11790@1-4-5.net> References: <20030722102355.A4716@1-4-5.net> <200307230045.h6N0jHq38340@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307230045.h6N0jHq38340@kummer.juniper.net>; from kireeti@juniper.net on Tue, Jul 22, 2003 at 05:45:17PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 23 Jul 2003 07:39:45 -0700 >> PS: Good X-philosophy! Thanks :-) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 23 10:41:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15423 for ; Wed, 23 Jul 2003 10:41:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKnm-00051B-1n for routing-discussion-archive@odin.ietf.org; Wed, 23 Jul 2003 10:41:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NEfA6M019219 for routing-discussion-archive@odin.ietf.org; Wed, 23 Jul 2003 10:41:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKnc-0004zA-Vk; Wed, 23 Jul 2003 10:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fKnG-0004ys-Ld for routing-discussion@optimus.ietf.org; Wed, 23 Jul 2003 10:40:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15384 for ; Wed, 23 Jul 2003 10:40:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fKnE-000574-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 10:40:36 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19fKn3-00056v-00 for routing-discussion@ietf.org; Wed, 23 Jul 2003 10:40:25 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6NEdj0e011816; Wed, 23 Jul 2003 07:39:45 -0700 From: David Meyer To: Kireeti Kompella Cc: danny@tcb.net, routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030723073945.C11790@1-4-5.net> References: <20030722102355.A4716@1-4-5.net> <200307230045.h6N0jHq38340@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200307230045.h6N0jHq38340@kummer.juniper.net>; from kireeti@juniper.net on Tue, Jul 22, 2003 at 05:45:17PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 23 Jul 2003 07:39:45 -0700 >> PS: Good X-philosophy! Thanks :-) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 24 21:13:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07533 for ; Thu, 24 Jul 2003 21:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr8r-0008Mm-2K for routing-discussion-archive@odin.ietf.org; Thu, 24 Jul 2003 21:13:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P1D57K032150 for routing-discussion-archive@odin.ietf.org; Thu, 24 Jul 2003 21:13:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr7p-0008Lf-El; Thu, 24 Jul 2003 21:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr79-0008LO-03 for routing-discussion@optimus.ietf.org; Thu, 24 Jul 2003 21:11:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07516 for ; Thu, 24 Jul 2003 21:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fr76-0003cD-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:11:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19fr6v-0003cA-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:11:05 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19fr6c-000LqJ-4o; Fri, 25 Jul 2003 01:10:46 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10069799636.20030724180341@psg.com> To: Danny McPherson CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 18:03:41 -0700 Content-Transfer-Encoding: 7bit Danny, et al- There are two main things that I took out of the meeting: 1. Though we didn't reach consensus that RP overloading is a problem (as I said in the beginning, the community is quite polarized on this question), the number of concerned people was much more than I expected. In other words, we do not have a consensus that RP overloading is a non-issue. 2. At the end of the meeting I asked the room if we should pursue creation of a separate protocol that would potentially inherit some of the MP-BGP framework and would be used as a generalized info distribution protocol. There was a very strong consensus in the room that we should do so. This is a very important step, I believe, and will be following up on this soon. It would also be useful to document what people concerned with RP overloading consider as potential problems. This should map nicely to Dave's problem statement idea. BTW, I'm planning on sending the minutes within a week--need to sync up notes taken by Ross and Dimitri. -- Alex http://www.psg.com/~zinin/ Tuesday, July 22, 2003, 9:55:19 AM, Danny McPherson wrote: > I missed the latter part of the panel discussion in the Routing Area meeting > in Vienna. Although I doubt any conclusions were reached, were there any > action items that came about (e.g., produce problem statement, applicability > notes or other)? > -danny > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 24 22:03:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07532 for ; Thu, 24 Jul 2003 21:13:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr7p-0008Lf-El; Thu, 24 Jul 2003 21:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fr79-0008LO-03 for routing-discussion@optimus.ietf.org; Thu, 24 Jul 2003 21:11:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07516 for ; Thu, 24 Jul 2003 21:11:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fr76-0003cD-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:11:16 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19fr6v-0003cA-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:11:05 -0400 Received: from [147.28.0.62] (helo=127.0.0.1 ident=zinin) by psg.com with esmtp (Exim 4.14) id 19fr6c-000LqJ-4o; Fri, 25 Jul 2003 01:10:46 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <10069799636.20030724180341@psg.com> To: Danny McPherson CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 18:03:41 -0700 Content-Transfer-Encoding: 7bit Danny, et al- There are two main things that I took out of the meeting: 1. Though we didn't reach consensus that RP overloading is a problem (as I said in the beginning, the community is quite polarized on this question), the number of concerned people was much more than I expected. In other words, we do not have a consensus that RP overloading is a non-issue. 2. At the end of the meeting I asked the room if we should pursue creation of a separate protocol that would potentially inherit some of the MP-BGP framework and would be used as a generalized info distribution protocol. There was a very strong consensus in the room that we should do so. This is a very important step, I believe, and will be following up on this soon. It would also be useful to document what people concerned with RP overloading consider as potential problems. This should map nicely to Dave's problem statement idea. BTW, I'm planning on sending the minutes within a week--need to sync up notes taken by Ross and Dimitri. -- Alex http://www.psg.com/~zinin/ Tuesday, July 22, 2003, 9:55:19 AM, Danny McPherson wrote: > I missed the latter part of the panel discussion in the Routing Area meeting > in Vienna. Although I doubt any conclusions were reached, were there any > action items that came about (e.g., produce problem statement, applicability > notes or other)? > -danny > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 24 23:09:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09674 for ; Thu, 24 Jul 2003 23:09:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fsw5-0004Da-6B; Thu, 24 Jul 2003 23:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fsvH-00040y-CT for routing-discussion@optimus.ietf.org; Thu, 24 Jul 2003 23:07:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09584 for ; Thu, 24 Jul 2003 23:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fsvD-0004B8-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 23:07:07 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19fsv2-0004Ai-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 23:06:56 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6P365u16569; Thu, 24 Jul 2003 20:06:05 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6P365c55485; Thu, 24 Jul 2003 20:06:05 -0700 (PDT) (envelope-from roque) Message-Id: <200307250306.h6P365c55485@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <10069799636.20030724180341@psg.com> References: <10069799636.20030724180341@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 20:06:05 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > 2. At the end of the meeting I asked the room if we should pursue > creation of a separate protocol that would potentially inherit some > of the MP-BGP framework and would be used as a generalized info > distribution protocol. There was a very strong consensus in the room > that we should do so. This is a very important step, I believe, and > will be following up on this soon. The problem w/ the question that you asked is that you made no mention of any drawbacks associated w/ such a choice... It is a bit like asking a room full of people if they want to receive a million dollars. Everybody will raise their hands but in fact the deal may not be much better than the business oportunities from Nigeria that one receives daily. :-) Given that the underlying desire seems to be that SPs that are not interest in a given service would prefer not to have that functionality added to BGP (in fact many people mentioned that they wanted not to have the functionality in the router software, period) and that there several services that are in consideration, it is not clear to me that the community will be able to agree on which subsets are wanted and which unwanted. Either in BGP or in any new protocol. An (incomplete) list of services would be: ipv4-unicast, ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ ipv4 / ipv6 / unicast/multicast variations, labeled-unicast, vpn auto-discovery, bgp-l2vpn, ip-tunneling-discovery, etc... One interesting question is how do you go about defining which subsets of services fit where... given that different providers want different subsets and that the rational is that the service a SP don't care about should not be in the protocol that is used by that SP, it would seem to me that you need one protocol per service/application. Developing a single additional protocol doesn't seem to fit the bill, as far as i can see. Or at least not based in the rational presented. And if the new protocol under discussion is not subject to "overload" considerations then the question needs to be why not ? Is there some new technical ability that will be added to it ? If so why not add it to BGP itself? Or is the intention to add a new protocol per service/application ? I would be very surprised if that where to result in increased software quality. I believe that the drawbacks of a given decision have to be considered. The discussion in Vienna was about the existence of a problem w/ routing protocol overload. I don't think it is fair game to attempt to establish consensus on a question that was not discussed and that you asked in the last second of the meeting immediatly cutting off discussion. regards, Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 24 23:58:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09673 for ; Thu, 24 Jul 2003 23:09:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fsxW-0004JR-J1 for routing-discussion-archive@odin.ietf.org; Thu, 24 Jul 2003 23:09:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P39U6P016577 for routing-discussion-archive@odin.ietf.org; Thu, 24 Jul 2003 23:09:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fsw5-0004Da-6B; Thu, 24 Jul 2003 23:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fsvH-00040y-CT for routing-discussion@optimus.ietf.org; Thu, 24 Jul 2003 23:07:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09584 for ; Thu, 24 Jul 2003 23:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fsvD-0004B8-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 23:07:07 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19fsv2-0004Ai-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 23:06:56 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6P365u16569; Thu, 24 Jul 2003 20:06:05 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6P365c55485; Thu, 24 Jul 2003 20:06:05 -0700 (PDT) (envelope-from roque) Message-Id: <200307250306.h6P365c55485@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <10069799636.20030724180341@psg.com> References: <10069799636.20030724180341@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 20:06:05 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > 2. At the end of the meeting I asked the room if we should pursue > creation of a separate protocol that would potentially inherit some > of the MP-BGP framework and would be used as a generalized info > distribution protocol. There was a very strong consensus in the room > that we should do so. This is a very important step, I believe, and > will be following up on this soon. The problem w/ the question that you asked is that you made no mention of any drawbacks associated w/ such a choice... It is a bit like asking a room full of people if they want to receive a million dollars. Everybody will raise their hands but in fact the deal may not be much better than the business oportunities from Nigeria that one receives daily. :-) Given that the underlying desire seems to be that SPs that are not interest in a given service would prefer not to have that functionality added to BGP (in fact many people mentioned that they wanted not to have the functionality in the router software, period) and that there several services that are in consideration, it is not clear to me that the community will be able to agree on which subsets are wanted and which unwanted. Either in BGP or in any new protocol. An (incomplete) list of services would be: ipv4-unicast, ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ ipv4 / ipv6 / unicast/multicast variations, labeled-unicast, vpn auto-discovery, bgp-l2vpn, ip-tunneling-discovery, etc... One interesting question is how do you go about defining which subsets of services fit where... given that different providers want different subsets and that the rational is that the service a SP don't care about should not be in the protocol that is used by that SP, it would seem to me that you need one protocol per service/application. Developing a single additional protocol doesn't seem to fit the bill, as far as i can see. Or at least not based in the rational presented. And if the new protocol under discussion is not subject to "overload" considerations then the question needs to be why not ? Is there some new technical ability that will be added to it ? If so why not add it to BGP itself? Or is the intention to add a new protocol per service/application ? I would be very surprised if that where to result in increased software quality. I believe that the drawbacks of a given decision have to be considered. The discussion in Vienna was about the existence of a problem w/ routing protocol overload. I don't think it is fair game to attempt to establish consensus on a question that was not discussed and that you asked in the last second of the meeting immediatly cutting off discussion. regards, Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 25 10:56:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08337 for ; Fri, 25 Jul 2003 10:56:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3z5-0007bv-N7 for routing-discussion-archive@odin.ietf.org; Fri, 25 Jul 2003 10:55:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PEtpoZ029234 for routing-discussion-archive@odin.ietf.org; Fri, 25 Jul 2003 10:55:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3yH-0007V0-Kw; Fri, 25 Jul 2003 10:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3xz-0007Tq-I9 for routing-discussion@optimus.ietf.org; Fri, 25 Jul 2003 10:54:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08285 for ; Fri, 25 Jul 2003 10:54:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3xx-0000s1-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 10:54:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19g3xm-0000qm-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 10:54:30 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6PEpOMK012789; Fri, 25 Jul 2003 10:51:24 -0400 (EDT) Message-Id: <200307251451.h6PEpOMK012789@rtp-core-1.cisco.com> To: Pedro Roque Marques cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Thu, 24 Jul 2003 20:06:05 -0700. <200307250306.h6P365c55485@roque-bsd.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 25 Jul 2003 10:51:24 -0400 > Given that the underlying desire seems to be that SPs that are not > interest in a given service would prefer not to have that > functionality added to BGP (in fact many people mentioned that they > wanted not to have the functionality in the router software, period) This is a very natural desire, but it is difficult to draw engineering conclusions from it. Sure, if someone has no intention of deploying, say, IPv6, they will say "please don't mess up BGP by putting IPv6 stuff in it". On the other hand, if they do want to deploy IPv6 they'll say "please don't make me deploy another inter-AS routing protocol just to handle IPv6; can't you just extend BGP a little, I already know how to deal with that." Obviously it is impossible for a vendor to provide a single piece of software that satisfies both groups. And since, for any given feature, both groups will always exist, it is difficult to obtain consensus. The desire cited above will never provide a good basis for deciding whether to extend a particular protocol for a particular purpose or not. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 25 11:20:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08891 for ; Fri, 25 Jul 2003 11:20:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4LU-0000OQ-Nf; Fri, 25 Jul 2003 11:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Kj-0000Nl-SX for routing-discussion@optimus.ietf.org; Fri, 25 Jul 2003 11:18:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08867 for ; Fri, 25 Jul 2003 11:18:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4Kj-00011O-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 11:18:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19g4KY-000116-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 11:18:02 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2003 08:17:12 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6PFH9Ai020526; Fri, 25 Jul 2003 11:17:10 -0400 (EDT) Message-Id: <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> To: Alex Zinin cc: Danny McPherson , routing-discussion@ietf.org Subject: Extending BGP In-reply-to: Your message of Thu, 24 Jul 2003 18:03:41 -0700. <10069799636.20030724180341@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 25 Jul 2003 11:17:09 -0400 I wasn't in Vienna, but let me put in my two cents on why it sometimes makes sense to use BGP for distributing non-routing information. Basically, I think you need to look at the specific requirements for distributing that information. (Yes, I know this isn't as much fun as making broad generalizations ;-)) Consider a set of routers S such that: - Members of S know apriori that they are members of S, but they do not know apriori which other routers are members of S. - S is divided into subsets (not necessarily disjoint) such that all members of a subset share a certain attribute. Thus for attribute A, we can speak of the A-subset of S. - Each member of S is configured with a set of "export attributes", and a set of "import attributes". - If a router in S is configured with export attribute E, it is a member of the E-subset. - If a router in S is configured with import attribute I, it needs to learn the membership of the I-subset. - The set of import and/or export attributes with which a router is configured may change at any time; changes in the membership of the various A-subsets should be learned within minutes. - The changes do not occur with great frequency. - The total number of attributes under consideration may be very large. - Members of S cannot be assumed to be in the same Autonomous System, nor can they necessarily be assumed to be under the control of the same administration. Now we need a protocol which detects changes in the A-subsets and distributes these changes. What requirements can be put on such a protocol: - It has to provide a way for a router to announce that it has acquired a new export attribute. (Call this an "update" operation.) - It has to provide a way for a router to announce that it has lost an export attribute. (Call this a "withdraw" operation.) - For scalability, we prefer that routers which are not in S are not impacted by any of this; in particular, they should not need to maintain any state which is specific to S or any of its subsets. Since the members of S do not know each other apriori, one might expect that there will be a server involved, where the members of S talk to the server, and the server redistributes the information as necessary. Of course, we usually want to have each router talking to two servers, with the servers also updating each other. And to make sure the whole system scales up, we'd like to be able to have servers with different sets of "clients" talking to each other. Since we may be passing large amounts of information over arbitrary network paths, we need to have a reliable, flow controlled transport, and it would be nice if the transport handled congestion control as well. A point-to-point transport between clients and servers seems the best fit, given that we don't want to burden any of S's non-members with S-specific state. To further improve scalability, we'd like to be able to have each client tell its server(s) its set of import attributes, so that a given router only receives the information in which it is interested. (Call this "outbound attribute filtering".) If we have servers talking to servers, it would be nice to have the outbound attribute filtering passed around the servers in some loop-free manner, but we can leave that for further study. If you put all these requirements together, and look for an existing protocol to satisfy them, you are inevitably led to BGP. The salient issue is not whether the attributes that need to be distributed are part of "routing", but whether the requirements for the distribution of these attributes are very similar to the requirements for the distribution of inter-domain routing information. We are led to BGP because of a similarity in the distribution requirements, not necessarily because of a similarity in the information distributed. Many alternatives have been suggested in the past, but most of them just make BGP look even better ;-) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 25 11:20:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08893 for ; Fri, 25 Jul 2003 11:20:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4MB-0000UN-AW for routing-discussion-archive@odin.ietf.org; Fri, 25 Jul 2003 11:19:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PFJhm1001866 for routing-discussion-archive@odin.ietf.org; Fri, 25 Jul 2003 11:19:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4LU-0000OQ-Nf; Fri, 25 Jul 2003 11:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g4Kj-0000Nl-SX for routing-discussion@optimus.ietf.org; Fri, 25 Jul 2003 11:18:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08867 for ; Fri, 25 Jul 2003 11:18:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g4Kj-00011O-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 11:18:13 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19g4KY-000116-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 11:18:02 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 25 Jul 2003 08:17:12 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6PFH9Ai020526; Fri, 25 Jul 2003 11:17:10 -0400 (EDT) Message-Id: <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> To: Alex Zinin cc: Danny McPherson , routing-discussion@ietf.org Subject: Extending BGP In-reply-to: Your message of Thu, 24 Jul 2003 18:03:41 -0700. <10069799636.20030724180341@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 25 Jul 2003 11:17:09 -0400 I wasn't in Vienna, but let me put in my two cents on why it sometimes makes sense to use BGP for distributing non-routing information. Basically, I think you need to look at the specific requirements for distributing that information. (Yes, I know this isn't as much fun as making broad generalizations ;-)) Consider a set of routers S such that: - Members of S know apriori that they are members of S, but they do not know apriori which other routers are members of S. - S is divided into subsets (not necessarily disjoint) such that all members of a subset share a certain attribute. Thus for attribute A, we can speak of the A-subset of S. - Each member of S is configured with a set of "export attributes", and a set of "import attributes". - If a router in S is configured with export attribute E, it is a member of the E-subset. - If a router in S is configured with import attribute I, it needs to learn the membership of the I-subset. - The set of import and/or export attributes with which a router is configured may change at any time; changes in the membership of the various A-subsets should be learned within minutes. - The changes do not occur with great frequency. - The total number of attributes under consideration may be very large. - Members of S cannot be assumed to be in the same Autonomous System, nor can they necessarily be assumed to be under the control of the same administration. Now we need a protocol which detects changes in the A-subsets and distributes these changes. What requirements can be put on such a protocol: - It has to provide a way for a router to announce that it has acquired a new export attribute. (Call this an "update" operation.) - It has to provide a way for a router to announce that it has lost an export attribute. (Call this a "withdraw" operation.) - For scalability, we prefer that routers which are not in S are not impacted by any of this; in particular, they should not need to maintain any state which is specific to S or any of its subsets. Since the members of S do not know each other apriori, one might expect that there will be a server involved, where the members of S talk to the server, and the server redistributes the information as necessary. Of course, we usually want to have each router talking to two servers, with the servers also updating each other. And to make sure the whole system scales up, we'd like to be able to have servers with different sets of "clients" talking to each other. Since we may be passing large amounts of information over arbitrary network paths, we need to have a reliable, flow controlled transport, and it would be nice if the transport handled congestion control as well. A point-to-point transport between clients and servers seems the best fit, given that we don't want to burden any of S's non-members with S-specific state. To further improve scalability, we'd like to be able to have each client tell its server(s) its set of import attributes, so that a given router only receives the information in which it is interested. (Call this "outbound attribute filtering".) If we have servers talking to servers, it would be nice to have the outbound attribute filtering passed around the servers in some loop-free manner, but we can leave that for further study. If you put all these requirements together, and look for an existing protocol to satisfy them, you are inevitably led to BGP. The salient issue is not whether the attributes that need to be distributed are part of "routing", but whether the requirements for the distribution of these attributes are very similar to the requirements for the distribution of inter-domain routing information. We are led to BGP because of a similarity in the distribution requirements, not necessarily because of a similarity in the information distributed. Many alternatives have been suggested in the past, but most of them just make BGP look even better ;-) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 25 11:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08336 for ; Fri, 25 Jul 2003 10:56:15 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3yH-0007V0-Kw; Fri, 25 Jul 2003 10:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g3xz-0007Tq-I9 for routing-discussion@optimus.ietf.org; Fri, 25 Jul 2003 10:54:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08285 for ; Fri, 25 Jul 2003 10:54:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g3xx-0000s1-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 10:54:41 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19g3xm-0000qm-00 for routing-discussion@ietf.org; Fri, 25 Jul 2003 10:54:30 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6PEpOMK012789; Fri, 25 Jul 2003 10:51:24 -0400 (EDT) Message-Id: <200307251451.h6PEpOMK012789@rtp-core-1.cisco.com> To: Pedro Roque Marques cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Thu, 24 Jul 2003 20:06:05 -0700. <200307250306.h6P365c55485@roque-bsd.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 25 Jul 2003 10:51:24 -0400 > Given that the underlying desire seems to be that SPs that are not > interest in a given service would prefer not to have that > functionality added to BGP (in fact many people mentioned that they > wanted not to have the functionality in the router software, period) This is a very natural desire, but it is difficult to draw engineering conclusions from it. Sure, if someone has no intention of deploying, say, IPv6, they will say "please don't mess up BGP by putting IPv6 stuff in it". On the other hand, if they do want to deploy IPv6 they'll say "please don't make me deploy another inter-AS routing protocol just to handle IPv6; can't you just extend BGP a little, I already know how to deal with that." Obviously it is impossible for a vendor to provide a single piece of software that satisfies both groups. And since, for any given feature, both groups will always exist, it is difficult to obtain consensus. The desire cited above will never provide a good basis for deciding whether to extend a particular protocol for a particular purpose or not. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Fri Jul 25 19:57:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02617 for ; Fri, 25 Jul 2003 19:57:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gCQn-0001Dl-P7; Fri, 25 Jul 2003 19:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frPw-0000qc-HW for routing-discussion@optimus.ietf.org; Thu, 24 Jul 2003 21:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07890 for ; Thu, 24 Jul 2003 21:30:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frPt-0003iI-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:30:41 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19frPj-0003h7-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:30:31 -0400 Received: from employees.org (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Jul 2003 18:29:10 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6P1RfuD010697 for ; Thu, 24 Jul 2003 18:27:41 -0700 (PDT) Received: from cisco.com (sjc-vpn3-609.cisco.com [10.21.66.97]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AII49859; Thu, 24 Jul 2003 18:21:01 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 24 Jul 2003 21:27:37 -0400 From: Scott W Brim To: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030724212737.T1920@sbrim-w2k01> Mail-Followup-To: Scott W Brim , routing-discussion@ietf.org References: <10069799636.20030724180341@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <10069799636.20030724180341@psg.com>; from zinin@psg.com on Thu, Jul 24, 2003 at 06:03:41PM -0700 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 21:27:37 -0400 On Thu, Jul 24, 2003 06:03:41PM -0700, Alex Zinin allegedly wrote: > 2. At the end of the meeting I asked the room if we should pursue > creation of a separate protocol that would potentially inherit > some of the MP-BGP framework and would be used as a generalized > info distribution protocol. There was a very strong consensus > in the room that we should do so. This is a very important step, > I believe, and will be following up on this soon. Do you (or anyone) have a summary of the pros and cons? Thanks ... Scott _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Fri Jul 25 19:57:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02624 for ; Fri, 25 Jul 2003 19:57:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gCQw-0001Ew-NU for routing-discussion-archive@odin.ietf.org; Fri, 25 Jul 2003 19:57:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PNvAT5004749 for routing-discussion-archive@odin.ietf.org; Fri, 25 Jul 2003 19:57:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gCQn-0001Dl-P7; Fri, 25 Jul 2003 19:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19frPw-0000qc-HW for routing-discussion@optimus.ietf.org; Thu, 24 Jul 2003 21:30:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07890 for ; Thu, 24 Jul 2003 21:30:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19frPt-0003iI-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:30:41 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19frPj-0003h7-00 for routing-discussion@ietf.org; Thu, 24 Jul 2003 21:30:31 -0400 Received: from employees.org (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Jul 2003 18:29:10 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6P1RfuD010697 for ; Thu, 24 Jul 2003 18:27:41 -0700 (PDT) Received: from cisco.com (sjc-vpn3-609.cisco.com [10.21.66.97]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AII49859; Thu, 24 Jul 2003 18:21:01 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Thu, 24 Jul 2003 21:27:37 -0400 From: Scott W Brim To: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030724212737.T1920@sbrim-w2k01> Mail-Followup-To: Scott W Brim , routing-discussion@ietf.org References: <10069799636.20030724180341@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <10069799636.20030724180341@psg.com>; from zinin@psg.com on Thu, Jul 24, 2003 at 06:03:41PM -0700 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 24 Jul 2003 21:27:37 -0400 On Thu, Jul 24, 2003 06:03:41PM -0700, Alex Zinin allegedly wrote: > 2. At the end of the meeting I asked the room if we should pursue > creation of a separate protocol that would potentially inherit > some of the MP-BGP framework and would be used as a generalized > info distribution protocol. There was a very strong consensus > in the room that we should do so. This is a very important step, > I believe, and will be following up on this soon. Do you (or anyone) have a summary of the pros and cons? Thanks ... Scott _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 28 11:27:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07018 for ; Mon, 28 Jul 2003 11:27:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9sv-0002C6-JK; Mon, 28 Jul 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9sb-0002Bn-D4 for routing-discussion@optimus.ietf.org; Mon, 28 Jul 2003 11:25:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06877 for ; Mon, 28 Jul 2003 11:25:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9sa-0003zG-00 for routing-discussion@ietf.org; Mon, 28 Jul 2003 11:25:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19h9sZ-0003xl-00 for routing-discussion@ietf.org; Mon, 28 Jul 2003 11:25:39 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2003 08:25:03 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6SFP1MK003395; Mon, 28 Jul 2003 11:25:01 -0400 (EDT) Message-Id: <200307281525.h6SFP1MK003395@rtp-core-1.cisco.com> To: Jon Crowcroft cc: Alex Zinin , Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-reply-to: Your message of Sat, 26 Jul 2003 07:50:42 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Jul 2003 11:25:00 -0400 Jon> its always attractive to overload "working" infrastructures (vis DNS, Jon> SIP, etc etc) but personally, i believe in choosing ones that are Jon> aliged with the performance requirements of the application, rather Jon> than ones that are barely able to meet existing demands Using BGP as a distribution protocol does not necessarily imply hooking it into the public inter-domain routing infrastructure. If BGP is a suitable protocol for distributing some information, an infrastructure for that info can be set up without impacting any pre-existing BGP infrastructure. Jon> for a start you create other reasons why BGP speakers might get Jon> overloaded, might get attacked, might get misconfigured, and might Jon> never converge Any time you use a protocol to distribute information, you create these possibilities, it's nothing to do with what protocol you're using. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 28 11:27:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07033 for ; Mon, 28 Jul 2003 11:27:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9u6-0002Dd-Ds for routing-discussion-archive@odin.ietf.org; Mon, 28 Jul 2003 11:27:16 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SFREVh008507 for routing-discussion-archive@odin.ietf.org; Mon, 28 Jul 2003 11:27:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9sv-0002C6-JK; Mon, 28 Jul 2003 11:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19h9sb-0002Bn-D4 for routing-discussion@optimus.ietf.org; Mon, 28 Jul 2003 11:25:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06877 for ; Mon, 28 Jul 2003 11:25:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19h9sa-0003zG-00 for routing-discussion@ietf.org; Mon, 28 Jul 2003 11:25:40 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19h9sZ-0003xl-00 for routing-discussion@ietf.org; Mon, 28 Jul 2003 11:25:39 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 28 Jul 2003 08:25:03 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6SFP1MK003395; Mon, 28 Jul 2003 11:25:01 -0400 (EDT) Message-Id: <200307281525.h6SFP1MK003395@rtp-core-1.cisco.com> To: Jon Crowcroft cc: Alex Zinin , Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-reply-to: Your message of Sat, 26 Jul 2003 07:50:42 +0100. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 28 Jul 2003 11:25:00 -0400 Jon> its always attractive to overload "working" infrastructures (vis DNS, Jon> SIP, etc etc) but personally, i believe in choosing ones that are Jon> aliged with the performance requirements of the application, rather Jon> than ones that are barely able to meet existing demands Using BGP as a distribution protocol does not necessarily imply hooking it into the public inter-domain routing infrastructure. If BGP is a suitable protocol for distributing some information, an infrastructure for that info can be set up without impacting any pre-existing BGP infrastructure. Jon> for a start you create other reasons why BGP speakers might get Jon> overloaded, might get attacked, might get misconfigured, and might Jon> never converge Any time you use a protocol to distribute information, you create these possibilities, it's nothing to do with what protocol you're using. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Mon Jul 28 16:36:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20319 for ; Mon, 28 Jul 2003 16:36:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEhx-0002ks-7s; Mon, 28 Jul 2003 16:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gItZ-00042W-5J for routing-discussion@optimus.ietf.org; Sat, 26 Jul 2003 02:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26840 for ; Sat, 26 Jul 2003 02:51:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gItV-0004Ax-00 for routing-discussion@ietf.org; Sat, 26 Jul 2003 02:51:05 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[13DPLKb93/YB69y0UzPJIQQQQrT+ygnC]) by ietf-mx with esmtp (Exim 4.12) id 19gItU-0004Ao-00 for routing-discussion@ietf.org; Sat, 26 Jul 2003 02:51:04 -0400 Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=[8zatVqMWhY5O6J1YJ5ph7sbcGMUJKhyb]) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19gIt9-0000BC-00; Sat, 26 Jul 2003 07:50:43 +0100 To: erosen@cisco.com cc: Alex Zinin , Danny McPherson , routing-discussion@ietf.org, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: Extending BGP In-Reply-To: Message from Eric Rosen of "Fri, 25 Jul 2003 11:17:09 EDT." <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4319.1059202242.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 26 Jul 2003 07:50:42 +0100 In missive <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com>, Eric Rosen typed: >>I wasn't in Vienna, but let me put in my two cents on why it sometimes makes unfortunately for the dollar, the cent does not go as far in europe as it used to:-) >>sense to use BGP for distributing non-routing information. Basically, I >>think you need to look at the specific requirements for distributing that >>information. (Yes, I know this isn't as much fun as making broad >>generalizations ;-)) despite your abstract argument (which i agree with) the point is that distributing things that matter in an infrastructure that is severely broken is a very bad idea - for a start you create other reasons why BGP speakers might get overloaded, might get attacked, might get misconfigured, and might never converge - its always attractive to overload "working" infrastructures (vis DNS, SIP, etc etc) but personally, i believe in choosing ones that are aliged with the performance requirements of the application, rather than ones that are barely able to meet existing demands >>Consider a set of routers S such that: >> >>- Members of S know apriori that they are members of S, but they do not know >> apriori which other routers are members of S. >> >>- S is divided into subsets (not necessarily disjoint) such that all members >> of a subset share a certain attribute. Thus for attribute A, we can speak >> of the A-subset of S. >> >>- Each member of S is configured with a set of "export attributes", and a >> set of "import attributes". >> >>- If a router in S is configured with export attribute E, it is a member of >> the E-subset. >> >>- If a router in S is configured with import attribute I, it needs to learn >> the membership of the I-subset. >> >>- The set of import and/or export attributes with which a router is >> configured may change at any time; changes in the membership of the >> various A-subsets should be learned within minutes. >> >>- The changes do not occur with great frequency. >> >>- The total number of attributes under consideration may be very large. >> >>- Members of S cannot be assumed to be in the same Autonomous System, nor >> can they necessarily be assumed to be under the control of the same >> administration. >> >>Now we need a protocol which detects changes in the A-subsets and >>distributes these changes. What requirements can be put on such a protocol: >> >>- It has to provide a way for a router to announce that it has acquired a >> new export attribute. (Call this an "update" operation.) >> >>- It has to provide a way for a router to announce that it has lost an >> export attribute. (Call this a "withdraw" operation.) >> >>- For scalability, we prefer that routers which are not in S are not >> impacted by any of this; in particular, they should not need to maintain >> any state which is specific to S or any of its subsets. >> >>Since the members of S do not know each other apriori, one might expect that >>there will be a server involved, where the members of S talk to the server, >>and the server redistributes the information as necessary. Of course, we >>usually want to have each router talking to two servers, with the servers >>also updating each other. And to make sure the whole system scales up, we'd >>like to be able to have servers with different sets of "clients" talking to >>each other. Since we may be passing large amounts of information over >>arbitrary network paths, we need to have a reliable, flow controlled >>transport, and it would be nice if the transport handled congestion control >>as well. A point-to-point transport between clients and servers seems the >>best fit, given that we don't want to burden any of S's non-members with >>S-specific state. >> >>To further improve scalability, we'd like to be able to have each client >>tell its server(s) its set of import attributes, so that a given router only >>receives the information in which it is interested. (Call this "outbound >>attribute filtering".) If we have servers talking to servers, it would be >>nice to have the outbound attribute filtering passed around the servers in >>some loop-free manner, but we can leave that for further study. >> >>If you put all these requirements together, and look for an existing >>protocol to satisfy them, you are inevitably led to BGP. The salient issue >>is not whether the attributes that need to be distributed are part of >>"routing", but whether the requirements for the distribution of these >>attributes are very similar to the requirements for the distribution of >>inter-domain routing information. We are led to BGP because of a similarity >>in the distribution requirements, not necessarily because of a similarity in >>the information distributed. >> >>Many alternatives have been suggested in the past, but most of them just >>make BGP look even better ;-) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Mon Jul 28 16:36:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20334 for ; Mon, 28 Jul 2003 16:36:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEid-0002qi-Q9 for routing-discussion-archive@odin.ietf.org; Mon, 28 Jul 2003 16:35:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SKZhNm010948 for routing-discussion-archive@odin.ietf.org; Mon, 28 Jul 2003 16:35:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hEhx-0002ks-7s; Mon, 28 Jul 2003 16:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19gItZ-00042W-5J for routing-discussion@optimus.ietf.org; Sat, 26 Jul 2003 02:51:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26840 for ; Sat, 26 Jul 2003 02:51:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19gItV-0004Ax-00 for routing-discussion@ietf.org; Sat, 26 Jul 2003 02:51:05 -0400 Received: from mta1.cl.cam.ac.uk ([128.232.0.15] helo=wisbech.cl.cam.ac.uk ident=[13DPLKb93/YB69y0UzPJIQQQQrT+ygnC]) by ietf-mx with esmtp (Exim 4.12) id 19gItU-0004Ao-00 for routing-discussion@ietf.org; Sat, 26 Jul 2003 02:51:04 -0400 Received: from shep.cl.cam.ac.uk ([128.232.8.11] helo=cl.cam.ac.uk ident=[8zatVqMWhY5O6J1YJ5ph7sbcGMUJKhyb]) by wisbech.cl.cam.ac.uk with esmtp (Exim 3.092 #1) id 19gIt9-0000BC-00; Sat, 26 Jul 2003 07:50:43 +0100 To: erosen@cisco.com cc: Alex Zinin , Danny McPherson , routing-discussion@ietf.org, Jon.Crowcroft@cl.cam.ac.uk Subject: Re: Extending BGP In-Reply-To: Message from Eric Rosen of "Fri, 25 Jul 2003 11:17:09 EDT." <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4319.1059202242.1@cl.cam.ac.uk> From: Jon Crowcroft Message-Id: Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 26 Jul 2003 07:50:42 +0100 In missive <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com>, Eric Rosen typed: >>I wasn't in Vienna, but let me put in my two cents on why it sometimes makes unfortunately for the dollar, the cent does not go as far in europe as it used to:-) >>sense to use BGP for distributing non-routing information. Basically, I >>think you need to look at the specific requirements for distributing that >>information. (Yes, I know this isn't as much fun as making broad >>generalizations ;-)) despite your abstract argument (which i agree with) the point is that distributing things that matter in an infrastructure that is severely broken is a very bad idea - for a start you create other reasons why BGP speakers might get overloaded, might get attacked, might get misconfigured, and might never converge - its always attractive to overload "working" infrastructures (vis DNS, SIP, etc etc) but personally, i believe in choosing ones that are aliged with the performance requirements of the application, rather than ones that are barely able to meet existing demands >>Consider a set of routers S such that: >> >>- Members of S know apriori that they are members of S, but they do not know >> apriori which other routers are members of S. >> >>- S is divided into subsets (not necessarily disjoint) such that all members >> of a subset share a certain attribute. Thus for attribute A, we can speak >> of the A-subset of S. >> >>- Each member of S is configured with a set of "export attributes", and a >> set of "import attributes". >> >>- If a router in S is configured with export attribute E, it is a member of >> the E-subset. >> >>- If a router in S is configured with import attribute I, it needs to learn >> the membership of the I-subset. >> >>- The set of import and/or export attributes with which a router is >> configured may change at any time; changes in the membership of the >> various A-subsets should be learned within minutes. >> >>- The changes do not occur with great frequency. >> >>- The total number of attributes under consideration may be very large. >> >>- Members of S cannot be assumed to be in the same Autonomous System, nor >> can they necessarily be assumed to be under the control of the same >> administration. >> >>Now we need a protocol which detects changes in the A-subsets and >>distributes these changes. What requirements can be put on such a protocol: >> >>- It has to provide a way for a router to announce that it has acquired a >> new export attribute. (Call this an "update" operation.) >> >>- It has to provide a way for a router to announce that it has lost an >> export attribute. (Call this a "withdraw" operation.) >> >>- For scalability, we prefer that routers which are not in S are not >> impacted by any of this; in particular, they should not need to maintain >> any state which is specific to S or any of its subsets. >> >>Since the members of S do not know each other apriori, one might expect that >>there will be a server involved, where the members of S talk to the server, >>and the server redistributes the information as necessary. Of course, we >>usually want to have each router talking to two servers, with the servers >>also updating each other. And to make sure the whole system scales up, we'd >>like to be able to have servers with different sets of "clients" talking to >>each other. Since we may be passing large amounts of information over >>arbitrary network paths, we need to have a reliable, flow controlled >>transport, and it would be nice if the transport handled congestion control >>as well. A point-to-point transport between clients and servers seems the >>best fit, given that we don't want to burden any of S's non-members with >>S-specific state. >> >>To further improve scalability, we'd like to be able to have each client >>tell its server(s) its set of import attributes, so that a given router only >>receives the information in which it is interested. (Call this "outbound >>attribute filtering".) If we have servers talking to servers, it would be >>nice to have the outbound attribute filtering passed around the servers in >>some loop-free manner, but we can leave that for further study. >> >>If you put all these requirements together, and look for an existing >>protocol to satisfy them, you are inevitably led to BGP. The salient issue >>is not whether the attributes that need to be distributed are part of >>"routing", but whether the requirements for the distribution of these >>attributes are very similar to the requirements for the distribution of >>inter-domain routing information. We are led to BGP because of a similarity >>in the distribution requirements, not necessarily because of a similarity in >>the information distributed. >> >>Many alternatives have been suggested in the past, but most of them just >>make BGP look even better ;-) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>_______________________________________________ >>routing-discussion mailing list >>routing-discussion@ietf.org >>https://www1.ietf.org/mailman/listinfo/routing-discussion cheers jon _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 15:50:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07027 for ; Tue, 29 Jul 2003 15:50:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haSy-0001vx-Tl; Tue, 29 Jul 2003 15:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haS9-0001sw-Rm for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 15:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06992 for ; Tue, 29 Jul 2003 15:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19haS8-0001KS-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:48:08 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19haS7-0001KP-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:48:07 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19haS5-000MWB-Q2; Tue, 29 Jul 2003 19:48:05 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2482819267.20030729124721@psg.com> To: Pedro Roque Marques CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307250306.h6P365c55485@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 12:47:21 -0700 Content-Transfer-Encoding: 7bit Pedro, > The problem w/ the question that you asked is that you made no mention > of any drawbacks associated w/ such a choice... > It is a bit like asking a room full of people if they want to receive > a million dollars. Everybody will raise their hands but in fact the > deal may not be much better than the business oportunities from > Nigeria that one receives daily. :-) [reordering paras a bit] > I believe that the drawbacks of a given decision have to be > considered. The discussion in Vienna was about the existence of a > problem w/ routing protocol overload. I don't think it is fair game to > attempt to establish consensus on a question that was not discussed > and that you asked in the last second of the meeting immediatly > cutting off discussion. I see no harm at all in taking the sense of the room about the interest in exploring a certain direction based on the discussion about the existence of the problem. My reading of this is that we clearly need an alternative solution to overloaded BGP. We certainly need to discuss further details. > Given that the underlying desire seems to be that SPs that are not > interest in a given service would prefer not to have that > functionality added to BGP (in fact many people mentioned that they > wanted not to have the functionality in the router software, period) > and that there several services that are in consideration, it is not > clear to me that the community will be able to agree on which subsets > are wanted and which unwanted. Either in BGP or in any new protocol. > An (incomplete) list of services would be: > ipv4-unicast, ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ > ipv4 / ipv6 / unicast/multicast variations, labeled-unicast, > vpn auto-discovery, bgp-l2vpn, ip-tunneling-discovery, etc... IMO, attempts to pull out from MP-BGP what's already there would be a no-op. I also believe that we have a certain level of agreement (based on my discussions within the rtg-dir, and in the hall-ways) that there are certain types of information that should be distributed within the RP. The major point of contention seems to be distribution of information that is not really routing-related or tightly coupled with it, such as VPN discovery and signaling, etc. What I am planning to do is ask the RTG directorate to document the discussion we had about this and come up with a document listing those considerations. We would then discuss this document here. > One interesting question is how do you go about defining which subsets > of services fit where... given that different providers want different > subsets and that the rational is that the service a SP don't care > about should not be in the protocol that is used by that SP, it would > seem to me that you need one protocol per service/application. > Developing a single additional protocol doesn't seem to fit the bill, > as far as i can see. Or at least not based in the rational presented. > And if the new protocol under discussion is not subject to "overload" > considerations then the question needs to be why not ? Is there some > new technical ability that will be added to it ? If so why not add it > to BGP itself? > Or is the intention to add a new protocol per service/application ? > I would be very surprised if that where to result in increased > software quality. The way I see it, the major concern is overloading of BGP, which is part of Internet-critical infrastructure, with non-routing functionality. Hence, the first step would be to give another (similar) transport to those application and keep them away from BGP. I could certainly see how people would feel comfortable putting multiple non-critical network-based applications on the same transport system. However, I could also see that at some point some critical functionality needs to be implemented and people don't feel comfortable putting it on the same transport, and decide to have a separate protocol for it. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 15:54:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07122 for ; Tue, 29 Jul 2003 15:54:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haWr-00026D-3Y; Tue, 29 Jul 2003 15:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haWE-00025K-8q for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 15:52:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07067 for ; Tue, 29 Jul 2003 15:52:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19haWC-0001MD-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:52:20 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19haWB-0001MA-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:52:20 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19haWA-000Mp8-E6; Tue, 29 Jul 2003 19:52:18 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <182483071860.20030729125134@psg.com> To: Eric Rosen CC: Pedro Roque Marques , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307251451.h6PEpOMK012789@rtp-core-1.cisco.com> References: <200307251451.h6PEpOMK012789@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 12:51:34 -0700 Content-Transfer-Encoding: 7bit Eric, See my reply to Pedro, please. Arguing that we should stop putting _any_ features in BGP would seem a non-starter to me. I believe the discussion is about non-routing applications of the MP-BGP framework. -- Alex http://www.psg.com/~zinin/ Friday, July 25, 2003, 7:51:24 AM, Eric Rosen wrote: >> Given that the underlying desire seems to be that SPs that are not >> interest in a given service would prefer not to have that >> functionality added to BGP (in fact many people mentioned that they >> wanted not to have the functionality in the router software, period) > This is a very natural desire, but it is difficult to draw engineering > conclusions from it. > Sure, if someone has no intention of deploying, say, IPv6, they will say > "please don't mess up BGP by putting IPv6 stuff in it". On the other hand, > if they do want to deploy IPv6 they'll say "please don't make me deploy > another inter-AS routing protocol just to handle IPv6; can't you just > extend BGP a little, I already know how to deal with that." > Obviously it is impossible for a vendor to provide a single piece of > software that satisfies both groups. And since, for any given feature, both > groups will always exist, it is difficult to obtain consensus. The desire > cited above will never provide a good basis for deciding whether to extend a > particular protocol for a particular purpose or not. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 15:54:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07124 for ; Tue, 29 Jul 2003 15:54:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haXt-0002F9-Ip for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 15:54:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TJs59H008581 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 15:54:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haWr-00026D-3Y; Tue, 29 Jul 2003 15:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haWE-00025K-8q for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 15:52:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07067 for ; Tue, 29 Jul 2003 15:52:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19haWC-0001MD-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:52:20 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19haWB-0001MA-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:52:20 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19haWA-000Mp8-E6; Tue, 29 Jul 2003 19:52:18 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <182483071860.20030729125134@psg.com> To: Eric Rosen CC: Pedro Roque Marques , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307251451.h6PEpOMK012789@rtp-core-1.cisco.com> References: <200307251451.h6PEpOMK012789@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 12:51:34 -0700 Content-Transfer-Encoding: 7bit Eric, See my reply to Pedro, please. Arguing that we should stop putting _any_ features in BGP would seem a non-starter to me. I believe the discussion is about non-routing applications of the MP-BGP framework. -- Alex http://www.psg.com/~zinin/ Friday, July 25, 2003, 7:51:24 AM, Eric Rosen wrote: >> Given that the underlying desire seems to be that SPs that are not >> interest in a given service would prefer not to have that >> functionality added to BGP (in fact many people mentioned that they >> wanted not to have the functionality in the router software, period) > This is a very natural desire, but it is difficult to draw engineering > conclusions from it. > Sure, if someone has no intention of deploying, say, IPv6, they will say > "please don't mess up BGP by putting IPv6 stuff in it". On the other hand, > if they do want to deploy IPv6 they'll say "please don't make me deploy > another inter-AS routing protocol just to handle IPv6; can't you just > extend BGP a little, I already know how to deal with that." > Obviously it is impossible for a vendor to provide a single piece of > software that satisfies both groups. And since, for any given feature, both > groups will always exist, it is difficult to obtain consensus. The desire > cited above will never provide a good basis for deciding whether to extend a > particular protocol for a particular purpose or not. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 16:10:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07607 for ; Tue, 29 Jul 2003 16:10:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hamL-0002mb-46; Tue, 29 Jul 2003 16:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ham4-0002lv-F0 for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 16:08:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07564 for ; Tue, 29 Jul 2003 16:08:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ham1-0001TZ-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:08:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ham0-0001TW-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:08:40 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19haly-000Nyf-NK; Tue, 29 Jul 2003 20:08:38 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <185484051248.20030729130753@psg.com> To: Eric Rosen CC: Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> References: <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 13:07:53 -0700 Content-Transfer-Encoding: 7bit Eric, > I wasn't in Vienna, but let me put in my two cents on why it sometimes makes > sense to use BGP for distributing non-routing information. Basically, I > think you need to look at the specific requirements for distributing that > information. (Yes, I know this isn't as much fun as making broad > generalizations ;-)) > Consider a set of routers S such that: > - Members of S know apriori that they are members of S, but they do not know > apriori which other routers are members of S. > - S is divided into subsets (not necessarily disjoint) such that all members > of a subset share a certain attribute. Thus for attribute A, we can speak > of the A-subset of S. > - Each member of S is configured with a set of "export attributes", and a > set of "import attributes". > - If a router in S is configured with export attribute E, it is a member of > the E-subset. > - If a router in S is configured with import attribute I, it needs to learn > the membership of the I-subset. > - The set of import and/or export attributes with which a router is > configured may change at any time; changes in the membership of the > various A-subsets should be learned within minutes. > - The changes do not occur with great frequency. > - The total number of attributes under consideration may be very large. > - Members of S cannot be assumed to be in the same Autonomous System, nor > can they necessarily be assumed to be under the control of the same > administration. > Now we need a protocol which detects changes in the A-subsets and > distributes these changes. What requirements can be put on such a protocol: > - It has to provide a way for a router to announce that it has acquired a > new export attribute. (Call this an "update" operation.) > - It has to provide a way for a router to announce that it has lost an > export attribute. (Call this a "withdraw" operation.) > - For scalability, we prefer that routers which are not in S are not > impacted by any of this; in particular, they should not need to maintain > any state which is specific to S or any of its subsets. > Since the members of S do not know each other apriori, one might expect that > there will be a server involved, where the members of S talk to the server, > and the server redistributes the information as necessary. Of course, we > usually want to have each router talking to two servers, with the servers > also updating each other. And to make sure the whole system scales up, we'd > like to be able to have servers with different sets of "clients" talking to > each other. Since we may be passing large amounts of information over > arbitrary network paths, we need to have a reliable, flow controlled > transport, and it would be nice if the transport handled congestion control > as well. A point-to-point transport between clients and servers seems the > best fit, given that we don't want to burden any of S's non-members with > S-specific state. > To further improve scalability, we'd like to be able to have each client > tell its server(s) its set of import attributes, so that a given router only > receives the information in which it is interested. (Call this "outbound > attribute filtering".) If we have servers talking to servers, it would be > nice to have the outbound attribute filtering passed around the servers in > some loop-free manner, but we can leave that for further study. Thanks! Really great summary of the required functionality! This is at least what I would have in mind. > If you put all these requirements together, and look for an existing > protocol to satisfy them, you are inevitably led to BGP. The salient issue > is not whether the attributes that need to be distributed are part of > "routing", but whether the requirements for the distribution of these > attributes are very similar to the requirements for the distribution of > inter-domain routing information. We are led to BGP because of a similarity > in the distribution requirements, not necessarily because of a similarity in > the information distributed. > Many alternatives have been suggested in the past, but most of them just > make BGP look even better ;-) And that's why, if we follow the direction of instantiating a separate protocol, it would most probably inherit a lot from MP-BGP. I.e., the idea is that it would have a very similar framework, though work over a different TCP port number, and would live its own life with independent (from BGP) features, extensions, optimizations, etc. [from your thread with Jon:] Jon>> for a start you create other reasons why BGP speakers might get Jon>> overloaded, might get attacked, might get misconfigured, and might Jon>> never converge > > Any time you use a protocol to distribute information, you create these > possibilities, it's nothing to do with what protocol you're using. I think the argument here is about risk assessment and management. Though it is possible to do a fine job of clearly separating different applications of the same protocol within the system, using a separate protocol makes it much more likely to happen. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 16:25:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07973 for ; Tue, 29 Jul 2003 16:25:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hb0q-0003W6-Re; Tue, 29 Jul 2003 16:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hb0d-0003Vk-AX for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 16:23:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07920 for ; Tue, 29 Jul 2003 16:23:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hb0a-0001YG-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:23:44 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19hb0Z-0001YD-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:23:43 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19hb0Z-000P08-DP; Tue, 29 Jul 2003 20:23:43 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <112484955939.20030729132258@psg.com> To: Scott W Brim CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <20030724212737.T1920@sbrim-w2k01> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 13:22:58 -0700 Content-Transfer-Encoding: 7bit Scott, > Do you (or anyone) have a summary of the pros and cons? I have some in my head, but not in writing. Should be an interesting exercise. Would be faster if someone took the first crack at this and we would then discuss it on this list. Otherwise, we'll have to wait for me :) Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 16:25:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07988 for ; Tue, 29 Jul 2003 16:25:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hb1y-0003cr-QL for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 16:25:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TKPAxq013913 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 16:25:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hb0q-0003W6-Re; Tue, 29 Jul 2003 16:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hb0d-0003Vk-AX for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 16:23:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07920 for ; Tue, 29 Jul 2003 16:23:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hb0a-0001YG-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:23:44 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19hb0Z-0001YD-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:23:43 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19hb0Z-000P08-DP; Tue, 29 Jul 2003 20:23:43 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <112484955939.20030729132258@psg.com> To: Scott W Brim CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <20030724212737.T1920@sbrim-w2k01> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 13:22:58 -0700 Content-Transfer-Encoding: 7bit Scott, > Do you (or anyone) have a summary of the pros and cons? I have some in my head, but not in writing. Should be an interesting exercise. Would be faster if someone took the first crack at this and we would then discuss it on this list. Otherwise, we'll have to wait for me :) Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 16:39:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07026 for ; Tue, 29 Jul 2003 15:50:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haUM-0001xH-Ct for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 15:50:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TJoQLa007511 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 15:50:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haSy-0001vx-Tl; Tue, 29 Jul 2003 15:49:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19haS9-0001sw-Rm for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 15:48:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06992 for ; Tue, 29 Jul 2003 15:48:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19haS8-0001KS-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:48:08 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19haS7-0001KP-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 15:48:07 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19haS5-000MWB-Q2; Tue, 29 Jul 2003 19:48:05 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2482819267.20030729124721@psg.com> To: Pedro Roque Marques CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307250306.h6P365c55485@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 12:47:21 -0700 Content-Transfer-Encoding: 7bit Pedro, > The problem w/ the question that you asked is that you made no mention > of any drawbacks associated w/ such a choice... > It is a bit like asking a room full of people if they want to receive > a million dollars. Everybody will raise their hands but in fact the > deal may not be much better than the business oportunities from > Nigeria that one receives daily. :-) [reordering paras a bit] > I believe that the drawbacks of a given decision have to be > considered. The discussion in Vienna was about the existence of a > problem w/ routing protocol overload. I don't think it is fair game to > attempt to establish consensus on a question that was not discussed > and that you asked in the last second of the meeting immediatly > cutting off discussion. I see no harm at all in taking the sense of the room about the interest in exploring a certain direction based on the discussion about the existence of the problem. My reading of this is that we clearly need an alternative solution to overloaded BGP. We certainly need to discuss further details. > Given that the underlying desire seems to be that SPs that are not > interest in a given service would prefer not to have that > functionality added to BGP (in fact many people mentioned that they > wanted not to have the functionality in the router software, period) > and that there several services that are in consideration, it is not > clear to me that the community will be able to agree on which subsets > are wanted and which unwanted. Either in BGP or in any new protocol. > An (incomplete) list of services would be: > ipv4-unicast, ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ > ipv4 / ipv6 / unicast/multicast variations, labeled-unicast, > vpn auto-discovery, bgp-l2vpn, ip-tunneling-discovery, etc... IMO, attempts to pull out from MP-BGP what's already there would be a no-op. I also believe that we have a certain level of agreement (based on my discussions within the rtg-dir, and in the hall-ways) that there are certain types of information that should be distributed within the RP. The major point of contention seems to be distribution of information that is not really routing-related or tightly coupled with it, such as VPN discovery and signaling, etc. What I am planning to do is ask the RTG directorate to document the discussion we had about this and come up with a document listing those considerations. We would then discuss this document here. > One interesting question is how do you go about defining which subsets > of services fit where... given that different providers want different > subsets and that the rational is that the service a SP don't care > about should not be in the protocol that is used by that SP, it would > seem to me that you need one protocol per service/application. > Developing a single additional protocol doesn't seem to fit the bill, > as far as i can see. Or at least not based in the rational presented. > And if the new protocol under discussion is not subject to "overload" > considerations then the question needs to be why not ? Is there some > new technical ability that will be added to it ? If so why not add it > to BGP itself? > Or is the intention to add a new protocol per service/application ? > I would be very surprised if that where to result in increased > software quality. The way I see it, the major concern is overloading of BGP, which is part of Internet-critical infrastructure, with non-routing functionality. Hence, the first step would be to give another (similar) transport to those application and keep them away from BGP. I could certainly see how people would feel comfortable putting multiple non-critical network-based applications on the same transport system. However, I could also see that at some point some critical functionality needs to be implemented and people don't feel comfortable putting it on the same transport, and decide to have a separate protocol for it. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 16:59:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07609 for ; Tue, 29 Jul 2003 16:10:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hanQ-0002sh-Fx for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 16:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TKA8Sc011072 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 16:10:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hamL-0002mb-46; Tue, 29 Jul 2003 16:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ham4-0002lv-F0 for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 16:08:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07564 for ; Tue, 29 Jul 2003 16:08:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ham1-0001TZ-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:08:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19ham0-0001TW-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 16:08:40 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19haly-000Nyf-NK; Tue, 29 Jul 2003 20:08:38 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <185484051248.20030729130753@psg.com> To: Eric Rosen CC: Danny McPherson , routing-discussion@ietf.org Subject: Re: Extending BGP In-Reply-To: <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> References: <200307251517.h6PFH9Ai020526@rtp-core-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 13:07:53 -0700 Content-Transfer-Encoding: 7bit Eric, > I wasn't in Vienna, but let me put in my two cents on why it sometimes makes > sense to use BGP for distributing non-routing information. Basically, I > think you need to look at the specific requirements for distributing that > information. (Yes, I know this isn't as much fun as making broad > generalizations ;-)) > Consider a set of routers S such that: > - Members of S know apriori that they are members of S, but they do not know > apriori which other routers are members of S. > - S is divided into subsets (not necessarily disjoint) such that all members > of a subset share a certain attribute. Thus for attribute A, we can speak > of the A-subset of S. > - Each member of S is configured with a set of "export attributes", and a > set of "import attributes". > - If a router in S is configured with export attribute E, it is a member of > the E-subset. > - If a router in S is configured with import attribute I, it needs to learn > the membership of the I-subset. > - The set of import and/or export attributes with which a router is > configured may change at any time; changes in the membership of the > various A-subsets should be learned within minutes. > - The changes do not occur with great frequency. > - The total number of attributes under consideration may be very large. > - Members of S cannot be assumed to be in the same Autonomous System, nor > can they necessarily be assumed to be under the control of the same > administration. > Now we need a protocol which detects changes in the A-subsets and > distributes these changes. What requirements can be put on such a protocol: > - It has to provide a way for a router to announce that it has acquired a > new export attribute. (Call this an "update" operation.) > - It has to provide a way for a router to announce that it has lost an > export attribute. (Call this a "withdraw" operation.) > - For scalability, we prefer that routers which are not in S are not > impacted by any of this; in particular, they should not need to maintain > any state which is specific to S or any of its subsets. > Since the members of S do not know each other apriori, one might expect that > there will be a server involved, where the members of S talk to the server, > and the server redistributes the information as necessary. Of course, we > usually want to have each router talking to two servers, with the servers > also updating each other. And to make sure the whole system scales up, we'd > like to be able to have servers with different sets of "clients" talking to > each other. Since we may be passing large amounts of information over > arbitrary network paths, we need to have a reliable, flow controlled > transport, and it would be nice if the transport handled congestion control > as well. A point-to-point transport between clients and servers seems the > best fit, given that we don't want to burden any of S's non-members with > S-specific state. > To further improve scalability, we'd like to be able to have each client > tell its server(s) its set of import attributes, so that a given router only > receives the information in which it is interested. (Call this "outbound > attribute filtering".) If we have servers talking to servers, it would be > nice to have the outbound attribute filtering passed around the servers in > some loop-free manner, but we can leave that for further study. Thanks! Really great summary of the required functionality! This is at least what I would have in mind. > If you put all these requirements together, and look for an existing > protocol to satisfy them, you are inevitably led to BGP. The salient issue > is not whether the attributes that need to be distributed are part of > "routing", but whether the requirements for the distribution of these > attributes are very similar to the requirements for the distribution of > inter-domain routing information. We are led to BGP because of a similarity > in the distribution requirements, not necessarily because of a similarity in > the information distributed. > Many alternatives have been suggested in the past, but most of them just > make BGP look even better ;-) And that's why, if we follow the direction of instantiating a separate protocol, it would most probably inherit a lot from MP-BGP. I.e., the idea is that it would have a very similar framework, though work over a different TCP port number, and would live its own life with independent (from BGP) features, extensions, optimizations, etc. [from your thread with Jon:] Jon>> for a start you create other reasons why BGP speakers might get Jon>> overloaded, might get attacked, might get misconfigured, and might Jon>> never converge > > Any time you use a protocol to distribute information, you create these > possibilities, it's nothing to do with what protocol you're using. I think the argument here is about risk assessment and management. Though it is possible to do a fine job of clearly separating different applications of the same protocol within the system, using a separate protocol makes it much more likely to happen. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 17:22:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10046 for ; Tue, 29 Jul 2003 17:22:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbv0-0006eQ-0k; Tue, 29 Jul 2003 17:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbuT-0006dy-Cx for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 17:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09998 for ; Tue, 29 Jul 2003 17:21:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbuR-0001zG-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 17:21:27 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hbuQ-0001yu-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 17:21:26 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 14:23:39 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6TLKsY3026183; Tue, 29 Jul 2003 14:20:54 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA11133; Tue, 29 Jul 2003 17:20:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <10069799636.20030724180341@psg.com> References: <10069799636.20030724180341@psg.com> To: Alex Zinin From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:20:43 -0400 At 6:03 PM -0700 7/24/03, Alex Zinin wrote: > 2. At the end of the meeting I asked the room if we should pursue > creation of a separate protocol that would potentially inherit > some of the MP-BGP framework and would be used as a generalized > info distribution protocol. Does a set of (prefix, next hop) information fall under the heading of "generalized info"? It seems only sensible that it does. Given that, wouldn't it be good engineering to use this GIDP you speak of for distribution of such information, instead of maintaining two protocols one of which is a functional subset of the other? If not, why not, and why is the GIDP suitable for every other type of "generalized" information with only this one limitation? If so, what makes the imaginary GIDP more suited for so-called "overloading" than BGP? A clear answer to this question would likely be usable as requirements for improving BGP... which would be a positive outcome. Let me also say I agree with Pedro and Eric's remarks. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 18:02:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11564 for ; Tue, 29 Jul 2003 18:02:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcYF-0000Pw-JQ for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 18:02:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TM2Z1O001602 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 18:02:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcXg-0000MK-T7; Tue, 29 Jul 2003 18:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcWj-0000Hb-UL for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 18:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11470 for ; Tue, 29 Jul 2003 18:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcWf-0002KX-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:00:57 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19hcWf-0002KB-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:00:57 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6TM0Qu58082; Tue, 29 Jul 2003 15:00:26 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6TM0Qt69017; Tue, 29 Jul 2003 15:00:26 -0700 (PDT) (envelope-from roque) Message-Id: <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <2482819267.20030729124721@psg.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 15:00:26 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: >> An (incomplete) list of services would be: ipv4-unicast, >> ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ ipv4 / ipv6 / >> unicast/multicast variations, labeled-unicast, vpn auto-discovery, >> bgp-l2vpn, ip-tunneling-discovery, etc... > IMO, attempts to pull out from MP-BGP what's already there would be > a no-op. I'm glad we agree on something :-) I'm just going to press you a little bit more and request you to define "already there". What is the criteria: WG document ? service provider deployements ? a vendor implementation ? interoperable implementations ? > I could certainly see how people would feel comfortable putting > multiple non-critical network-based applications on the same > transport system. One of the points that people keep ignoring is that the definition of critical and non-critical is highly subjective and depends a lot on who is making the call. I work with customers to whom IP is non-critical while VPN services are critical given that they make more money out of the latter than the former (VPN services are also often sold as higher reliability than IP service). I also work w/ customers that have a completely opposite point of view. Thus my definition of critical has necessarily to be the entire set of services (ip unicast/multicast, 2547, l2vpns). ipv6 routing is probably the service considered least critical by SPs but even this one is critical to quite a few of them and a vendor is force to treat it has such. Personally i think that the assumption of "non-critical" is one of the highest reasoning flaws in this discussion. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 18:03:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11565 for ; Tue, 29 Jul 2003 18:02:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcXg-0000MK-T7; Tue, 29 Jul 2003 18:02:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hcWj-0000Hb-UL for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 18:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11470 for ; Tue, 29 Jul 2003 18:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hcWf-0002KX-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:00:57 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19hcWf-0002KB-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:00:57 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6TM0Qu58082; Tue, 29 Jul 2003 15:00:26 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6TM0Qt69017; Tue, 29 Jul 2003 15:00:26 -0700 (PDT) (envelope-from roque) Message-Id: <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <2482819267.20030729124721@psg.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 15:00:26 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: >> An (incomplete) list of services would be: ipv4-unicast, >> ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ ipv4 / ipv6 / >> unicast/multicast variations, labeled-unicast, vpn auto-discovery, >> bgp-l2vpn, ip-tunneling-discovery, etc... > IMO, attempts to pull out from MP-BGP what's already there would be > a no-op. I'm glad we agree on something :-) I'm just going to press you a little bit more and request you to define "already there". What is the criteria: WG document ? service provider deployements ? a vendor implementation ? interoperable implementations ? > I could certainly see how people would feel comfortable putting > multiple non-critical network-based applications on the same > transport system. One of the points that people keep ignoring is that the definition of critical and non-critical is highly subjective and depends a lot on who is making the call. I work with customers to whom IP is non-critical while VPN services are critical given that they make more money out of the latter than the former (VPN services are also often sold as higher reliability than IP service). I also work w/ customers that have a completely opposite point of view. Thus my definition of critical has necessarily to be the entire set of services (ip unicast/multicast, 2547, l2vpns). ipv6 routing is probably the service considered least critical by SPs but even this one is critical to quite a few of them and a vendor is force to treat it has such. Personally i think that the assumption of "non-critical" is one of the highest reasoning flaws in this discussion. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 18:09:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10047 for ; Tue, 29 Jul 2003 17:22:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbvR-0006fr-9R for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 17:22:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TLMTjs025644 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 17:22:29 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbv0-0006eQ-0k; Tue, 29 Jul 2003 17:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hbuT-0006dy-Cx for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 17:21:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09998 for ; Tue, 29 Jul 2003 17:21:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hbuR-0001zG-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 17:21:27 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hbuQ-0001yu-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 17:21:26 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 14:23:39 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6TLKsY3026183; Tue, 29 Jul 2003 14:20:54 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id RAA11133; Tue, 29 Jul 2003 17:20:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <10069799636.20030724180341@psg.com> References: <10069799636.20030724180341@psg.com> To: Alex Zinin From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:20:43 -0400 At 6:03 PM -0700 7/24/03, Alex Zinin wrote: > 2. At the end of the meeting I asked the room if we should pursue > creation of a separate protocol that would potentially inherit > some of the MP-BGP framework and would be used as a generalized > info distribution protocol. Does a set of (prefix, next hop) information fall under the heading of "generalized info"? It seems only sensible that it does. Given that, wouldn't it be good engineering to use this GIDP you speak of for distribution of such information, instead of maintaining two protocols one of which is a functional subset of the other? If not, why not, and why is the GIDP suitable for every other type of "generalized" information with only this one limitation? If so, what makes the imaginary GIDP more suited for so-called "overloading" than BGP? A clear answer to this question would likely be usable as requirements for improving BGP... which would be a positive outcome. Let me also say I agree with Pedro and Eric's remarks. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 18:42:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13891 for ; Tue, 29 Jul 2003 18:42:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdAP-0002ge-Ba; Tue, 29 Jul 2003 18:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hd9e-0002gE-OX for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 18:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13860 for ; Tue, 29 Jul 2003 18:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hd8q-0002ck-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:40:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hd8p-0002ch-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:40:23 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 15:42:38 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6TMdquD004914 for ; Tue, 29 Jul 2003 15:39:52 -0700 (PDT) Received: from cisco.com (sjc-vpn4-312.cisco.com [10.21.81.56]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIL85442; Tue, 29 Jul 2003 15:31:57 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 29 Jul 2003 18:39:49 -0400 From: Scott W Brim To: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030729183949.H2408@sbrim-w2k01> Mail-Followup-To: Scott W Brim , routing-discussion@ietf.org References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2482819267.20030729124721@psg.com>; from zinin@psg.com on Tue, Jul 29, 2003 at 12:47:21PM -0700 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 18:39:49 -0400 How about we rename BGP, declare that we're done with the general information distribution protocol, and work on a new routing protocol? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 18:55:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14187 for ; Tue, 29 Jul 2003 18:55:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdMz-00031u-Oh; Tue, 29 Jul 2003 18:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdMs-00031Q-Hp for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 18:54:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14139 for ; Tue, 29 Jul 2003 18:54:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdMp-0002ga-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:54:51 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hdMo-0002gV-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:54:50 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2003 15:54:17 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6TMsE89027740; Tue, 29 Jul 2003 15:54:14 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT34735; Tue, 29 Jul 2003 15:48:33 -0700 (PDT) Message-ID: <3F26FAE6.EA0D6868@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 00:53:26 +0200 Content-Transfer-Encoding: 7bit Alex, While watching this debate I have a feeling that the problem here is as old as civilization ;-). There has always been an issue if one should extend one city with new buildings or start over and build new city. My take on this is that if the architecture of a given city is good, communication is perfect and can scale adding a new buildings or districts nicely divided from one another will not harm anyone to get to large sizes accomodating all newcommers. On the other hand if architecture is bad, communication is a nightmare just asking for building another city will do no good at all. In fact I would say that in most cases it may do more harm then good if another group of architects will take over in another city and some of the intercity communication would still need to happen anyway. So as it was said by others a number of times this discussion is just about software eng - nothing else. A few providers said that they would like to run only a number of features they use ... AFAIK that should be doable already in most of the shipping implementations. Also it seems to be some interesting assumption that if we separate so called "non-routing" info from BGP the entire system would behave much better. I would like to see what facts make anyone feel/think that way ;) Last lightly assume we go down the path and invent, implement & deploy a new protocol instance/port would that mean that we will from such a moment start indefinitely putting all new things on it or will this topic be comming back every now and then and each time a "new protocol" or "new port number" will be recommended ??? As clearly definitions of routing and non routing, critical and non critical information is different depending who get's to reply my suggestion for routing directorate would be to have a BGP port number progressing with the calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 etc ... :):). Just one page draft. Now time for few comments from this thread ... > > To further improve scalability, we'd like to be able to have each > > client tell its server(s) its set of import attributes, so that a > > given router only receives the information in which it is interested. > > (Call this "outbound attribute filtering".) If we have servers > > talking to servers, it would be nice to have the outbound attribute > > filtering passed around the servers in some loop-free manner, > > but we can leave that for further study. > > Thanks! Really great summary of the required functionality! > This is at least what I would have in mind. I am missing the point above. BGP provides this already in two planes. One is per AFI/SAFI information distribution. As far as I see all new BGP (even non-routing) extensions are nicely separated in their own AFI/SAFIs most with additional capabilities. Second one is realized in at least two ways for pushing to your peer inbound filtering so the peer on outbound already filters (ORF drafts - prefix, ext community, as path or rt-constrain draft). So what exactly is missing ? Cheers, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 18:55:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14188 for ; Tue, 29 Jul 2003 18:55:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdNQ-000362-3L for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 18:55:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TMtSrE011896 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 18:55:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdMz-00031u-Oh; Tue, 29 Jul 2003 18:55:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdMs-00031Q-Hp for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 18:54:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14139 for ; Tue, 29 Jul 2003 18:54:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdMp-0002ga-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:54:51 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hdMo-0002gV-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:54:50 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 29 Jul 2003 15:54:17 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6TMsE89027740; Tue, 29 Jul 2003 15:54:14 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT34735; Tue, 29 Jul 2003 15:48:33 -0700 (PDT) Message-ID: <3F26FAE6.EA0D6868@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 00:53:26 +0200 Content-Transfer-Encoding: 7bit Alex, While watching this debate I have a feeling that the problem here is as old as civilization ;-). There has always been an issue if one should extend one city with new buildings or start over and build new city. My take on this is that if the architecture of a given city is good, communication is perfect and can scale adding a new buildings or districts nicely divided from one another will not harm anyone to get to large sizes accomodating all newcommers. On the other hand if architecture is bad, communication is a nightmare just asking for building another city will do no good at all. In fact I would say that in most cases it may do more harm then good if another group of architects will take over in another city and some of the intercity communication would still need to happen anyway. So as it was said by others a number of times this discussion is just about software eng - nothing else. A few providers said that they would like to run only a number of features they use ... AFAIK that should be doable already in most of the shipping implementations. Also it seems to be some interesting assumption that if we separate so called "non-routing" info from BGP the entire system would behave much better. I would like to see what facts make anyone feel/think that way ;) Last lightly assume we go down the path and invent, implement & deploy a new protocol instance/port would that mean that we will from such a moment start indefinitely putting all new things on it or will this topic be comming back every now and then and each time a "new protocol" or "new port number" will be recommended ??? As clearly definitions of routing and non routing, critical and non critical information is different depending who get's to reply my suggestion for routing directorate would be to have a BGP port number progressing with the calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 etc ... :):). Just one page draft. Now time for few comments from this thread ... > > To further improve scalability, we'd like to be able to have each > > client tell its server(s) its set of import attributes, so that a > > given router only receives the information in which it is interested. > > (Call this "outbound attribute filtering".) If we have servers > > talking to servers, it would be nice to have the outbound attribute > > filtering passed around the servers in some loop-free manner, > > but we can leave that for further study. > > Thanks! Really great summary of the required functionality! > This is at least what I would have in mind. I am missing the point above. BGP provides this already in two planes. One is per AFI/SAFI information distribution. As far as I see all new BGP (even non-routing) extensions are nicely separated in their own AFI/SAFIs most with additional capabilities. Second one is realized in at least two ways for pushing to your peer inbound filtering so the peer on outbound already filters (ORF drafts - prefix, ext community, as path or rt-constrain draft). So what exactly is missing ? Cheers, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 19:07:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14556 for ; Tue, 29 Jul 2003 19:07:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdYb-0003fL-Cb; Tue, 29 Jul 2003 19:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdXl-0003ai-6v for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14503 for ; Tue, 29 Jul 2003 19:06:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdXh-0002lk-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:06:05 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19hdXh-0002lh-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:06:05 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hdXg-0003Qr-EN; Tue, 29 Jul 2003 16:06:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:06:03 -0700 Content-Transfer-Encoding: 7bit > There has always been an issue if one should extend one city with new > buildings or start over and build new city. My take on this is that if > the architecture of a given city is good, communication is perfect and > can scale adding a new buildings or districts nicely divided from one > another will not harm anyone to get to large sizes accomodating all > newcommers. well, so much for bgp, as anyone researcher who actually looks at how the protocol performs on the net will tell you. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 19:20:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14908 for ; Tue, 29 Jul 2003 19:20:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdlB-0004Md-EU; Tue, 29 Jul 2003 19:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdkI-0004Lz-9G for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:19:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14858 for ; Tue, 29 Jul 2003 19:19:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdkG-0002q7-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:19:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19hdkG-0002q4-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:19:04 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19hdkG-000BdX-Ef; Tue, 29 Jul 2003 23:19:04 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <71495483527.20030729161825@psg.com> To: "John G. Scudder" CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: References: <10069799636.20030724180341@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:18:25 -0700 Content-Transfer-Encoding: 7bit Hi John, good to hear from you! > Does a set of (prefix, next hop) information fall under the heading > of "generalized info"? It seems only sensible that it does. Given > that, wouldn't it be good engineering to use this GIDP you speak of > for distribution of such information, instead of maintaining two > protocols one of which is a functional subset of the other? > If not, why not, and why is the GIDP suitable for every other type of > "generalized" information with only this one limitation? There are protocol-related and operations-related considerations here. Protocol-wise, prefix distribution may or may not fit in depending on the design decisions that would be made. I.e., if all BGP mechanisms needed for IP prefix distribution (such as policy-based best-path selection, aggregation, NH behavior, etc.) are preserved, than the protocol may be capable of doing so. There would still be the same operational considerations though, see below pls. > If so, what makes the imaginary GIDP more suited for so-called > "overloading" than BGP? A clear answer to this question would likely > be usable as requirements for improving BGP... which would be a > positive outcome. From my message to Eric: > I think the argument here is about risk assessment and management. > > Though it is possible to do a fine job of clearly separating different > applications of the same protocol within the system, using a separate > protocol makes it much more likely to happen. and from my message to Pedro: > The way I see it, the major concern is overloading of BGP, which is > part of Internet-critical infrastructure, with non-routing > functionality. Hence, the first step would be to give another > (similar) transport to those application and keep them away from BGP. > > I could certainly see how people would feel comfortable putting > multiple non-critical network-based applications on the same transport > system. However, I could also see that at some point some critical > functionality needs to be implemented and people don't feel > comfortable putting it on the same transport, and decide to have a > separate protocol for it. Regards. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 19:29:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13892 for ; Tue, 29 Jul 2003 18:42:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdAs-0002iP-KA for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 18:42:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TMgUwK010394 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 18:42:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdAP-0002ge-Ba; Tue, 29 Jul 2003 18:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hd9e-0002gE-OX for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 18:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13860 for ; Tue, 29 Jul 2003 18:40:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hd8q-0002ck-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:40:24 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hd8p-0002ch-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 18:40:23 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 15:42:38 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6TMdquD004914 for ; Tue, 29 Jul 2003 15:39:52 -0700 (PDT) Received: from cisco.com (sjc-vpn4-312.cisco.com [10.21.81.56]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AIL85442; Tue, 29 Jul 2003 15:31:57 -0700 (PDT) Received: by cisco.com (sSMTP sendmail emulation); Tue, 29 Jul 2003 18:39:49 -0400 From: Scott W Brim To: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030729183949.H2408@sbrim-w2k01> Mail-Followup-To: Scott W Brim , routing-discussion@ietf.org References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2482819267.20030729124721@psg.com>; from zinin@psg.com on Tue, Jul 29, 2003 at 12:47:21PM -0700 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 18:39:49 -0400 How about we rename BGP, declare that we're done with the general information distribution protocol, and work on a new routing protocol? _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 19:28:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15235 for ; Tue, 29 Jul 2003 19:28:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdtH-000549-G9 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:28:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNSNDw019421 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:28:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdsv-0004zp-G0; Tue, 29 Jul 2003 19:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdsJ-0004zS-LK for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15211 for ; Tue, 29 Jul 2003 19:27:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdsI-0002v6-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:27:22 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19hdsC-0002uZ-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:27:16 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6TNQipp018221; Tue, 29 Jul 2003 16:26:45 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT39409; Tue, 29 Jul 2003 16:21:46 -0700 (PDT) Message-ID: <3F2702AF.252E568F@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 01:26:39 +0200 Content-Transfer-Encoding: 7bit I am sure those opinions must be documented - could you compile a URL reference list so we can all see how bad it "performs" today ? Also if those folks are real researchers we will most likely be able to also see studies on how much time do we have left. R. > Randy Bush wrote: > > > There has always been an issue if one should extend one city with new > > buildings or start over and build new city. My take on this is that if > > the architecture of a given city is good, communication is perfect and > > can scale adding a new buildings or districts nicely divided from one > > another will not harm anyone to get to large sizes accomodating all > > newcommers. > > well, so much for bgp, as anyone researcher who actually looks at > how the protocol performs on the net will tell you. > > randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 19:39:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15650 for ; Tue, 29 Jul 2003 19:39:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he3Y-0005br-IJ; Tue, 29 Jul 2003 19:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he35-0005bX-9a for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:38:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15601 for ; Tue, 29 Jul 2003 19:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19he32-00031d-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:38:28 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19he31-00031L-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:38:27 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6TNc34s026802; Tue, 29 Jul 2003 16:38:03 -0700 From: David Meyer To: Robert Raszuk Cc: Randy Bush , Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030729163803.A26790@1-4-5.net> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <3F2702AF.252E568F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F2702AF.252E568F@cisco.com>; from raszuk@cisco.com on Wed, Jul 30, 2003 at 01:26:39AM +0200 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:38:03 -0700 Robert, >> I am sure those opinions must be documented - could you compile a URL >> reference list so we can all see how bad it "performs" today ? Also if >> those folks are real researchers we will most likely be able to also see >> studies on how much time do we have left. While nowhere near exhaustive, you might have a look at http://www.routeviews.org/papers for a few (notably, the craig/abha paper isn't on that list). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 19:39:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15652 for ; Tue, 29 Jul 2003 19:39:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he3w-0005g9-Mu for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:39:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNdOf3021805 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:39:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he3Y-0005br-IJ; Tue, 29 Jul 2003 19:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he35-0005bX-9a for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:38:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15601 for ; Tue, 29 Jul 2003 19:38:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19he32-00031d-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:38:28 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19he31-00031L-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:38:27 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6TNc34s026802; Tue, 29 Jul 2003 16:38:03 -0700 From: David Meyer To: Robert Raszuk Cc: Randy Bush , Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030729163803.A26790@1-4-5.net> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <3F2702AF.252E568F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3F2702AF.252E568F@cisco.com>; from raszuk@cisco.com on Wed, Jul 30, 2003 at 01:26:39AM +0200 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:38:03 -0700 Robert, >> I am sure those opinions must be documented - could you compile a URL >> reference list so we can all see how bad it "performs" today ? Also if >> those folks are real researchers we will most likely be able to also see >> studies on how much time do we have left. While nowhere near exhaustive, you might have a look at http://www.routeviews.org/papers for a few (notably, the craig/abha paper isn't on that list). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 19:46:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15779 for ; Tue, 29 Jul 2003 19:46:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heAk-0005wy-An for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:46:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNkQrc022855 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:46:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heAL-0005vo-VL; Tue, 29 Jul 2003 19:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he9z-0005vX-U7 for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:45:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15757 for ; Tue, 29 Jul 2003 19:45:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19he9y-000340-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:45:38 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19he9x-00033x-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:45:37 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19he9x-0004Qf-Kc; Tue, 29 Jul 2003 16:45:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <3F2702AF.252E568F@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:45:36 -0700 Content-Transfer-Encoding: 7bit > I am sure those opinions must be documented - could you compile a URL > reference list so we can all see how bad it "performs" today ? other than the large literature on the issue, we working on one particularly ugly piece of it now. showing it to dr. bug on thursday, and hope to have the first ppt at apnic next month. > Also if those folks are real researchers we will most likely be > able to also see studies on how much time do we have left. it's a long way from that. research is still trying to differentiate between problems caused by configuration, by implementaion, and by the protocol itself. but today, i am looking at one single announce creating over 40 events just a few hops away (in a real network). but the point is that, while we have such outrageous behavior, no matter that we are still trying to work out all the causes, it is scarily not appropriate to characterize bgp as > the architecture of a given city is good, communication is > perfect and can scale randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 19:54:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14557 for ; Tue, 29 Jul 2003 19:07:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdZ2-0003oj-5y for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:07:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TN7Sm1014650 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:07:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdYb-0003fL-Cb; Tue, 29 Jul 2003 19:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdXl-0003ai-6v for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:06:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14503 for ; Tue, 29 Jul 2003 19:06:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdXh-0002lk-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:06:05 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19hdXh-0002lh-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:06:05 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hdXg-0003Qr-EN; Tue, 29 Jul 2003 16:06:04 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:06:03 -0700 Content-Transfer-Encoding: 7bit > There has always been an issue if one should extend one city with new > buildings or start over and build new city. My take on this is that if > the architecture of a given city is good, communication is perfect and > can scale adding a new buildings or districts nicely divided from one > another will not harm anyone to get to large sizes accomodating all > newcommers. well, so much for bgp, as anyone researcher who actually looks at how the protocol performs on the net will tell you. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 19:59:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16164 for ; Tue, 29 Jul 2003 19:59:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heMv-0006my-Dv; Tue, 29 Jul 2003 19:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heMT-0006ma-4C for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16133 for ; Tue, 29 Jul 2003 19:58:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heMR-0003Ae-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:58:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19heMQ-0003Ab-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:58:30 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19heMR-000EUY-2b; Tue, 29 Jul 2003 23:58:31 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <154497849009.20030729165751@psg.com> To: Pedro Roque Marques CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:57:51 -0700 Content-Transfer-Encoding: 7bit Pedro, >> IMO, attempts to pull out from MP-BGP what's already there would be >> a no-op. > I'm glad we agree on something :-) I'm just going to press you a > little bit more and request you to define "already there". > What is the criteria: WG document ? service provider deployements ? > a vendor implementation ? interoperable implementations ? Let's think about this. On the one hand we want to be reasonable and avoid recoding/redebugging things that are already widely agreed on and/or deployed. On the other hand we don't want to fall for the "oh, but I just coded it yesterday, and here's the draft" trick. How about something along these lines: "an IETF RFC, or a de-facto multi-vendor interoperable standard"? Other suggestions? >> I could certainly see how people would feel comfortable putting >> multiple non-critical network-based applications on the same >> transport system. > One of the points that people keep ignoring is that the definition of > critical and non-critical is highly subjective and depends a lot on > who is making the call. Indeed. Note the "Internet-critical" part. > I work with customers to whom IP is non-critical while VPN services > are critical given that they make more money out of the latter > than the former (VPN services are also often sold as higher > reliability than IP service). I also work w/ customers that have a > completely opposite point of view. > Thus my definition of critical has necessarily to be the entire set of > services (ip unicast/multicast, 2547, l2vpns). > ipv6 routing is probably the service considered least critical by SPs > but even this one is critical to quite a few of them and a vendor is > force to treat it has such. > Personally i think that the assumption of "non-critical" is one of the > highest reasoning flaws in this discussion. We have a couple of considerations here: a) level of criticality, and b) fate sharing. While from the perspective of a stand-alone SP, Internet routing and L2VPNs might be of equal significance, and hence criticality, if we look at it from the perspective of the Internet as a whole (which is what we are supposed to at least keep in mind in the IETF), or at least a set of cooperating service providers, then VPN functionality may very well depend on routing (in case of a PE-to-PE tunnel, for example); in other words, VPN mechanisms use services provided by routing, and hence routing becomes more critical. The fate sharing argument is bidirectional--we probably don't want routing to pay the tax for non-routing related features, and the guys for whom VPNs are much more important may not want to pay the tax for whatever we do with Internet routing. If that's the case, separating the two is a good idea. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 20:09:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14909 for ; Tue, 29 Jul 2003 19:20:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdlb-0004RN-Sc for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:20:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNKRWw017062 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:20:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdlB-0004Md-EU; Tue, 29 Jul 2003 19:20:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdkI-0004Lz-9G for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:19:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14858 for ; Tue, 29 Jul 2003 19:19:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdkG-0002q7-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:19:04 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19hdkG-0002q4-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:19:04 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19hdkG-000BdX-Ef; Tue, 29 Jul 2003 23:19:04 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <71495483527.20030729161825@psg.com> To: "John G. Scudder" CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: References: <10069799636.20030724180341@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:18:25 -0700 Content-Transfer-Encoding: 7bit Hi John, good to hear from you! > Does a set of (prefix, next hop) information fall under the heading > of "generalized info"? It seems only sensible that it does. Given > that, wouldn't it be good engineering to use this GIDP you speak of > for distribution of such information, instead of maintaining two > protocols one of which is a functional subset of the other? > If not, why not, and why is the GIDP suitable for every other type of > "generalized" information with only this one limitation? There are protocol-related and operations-related considerations here. Protocol-wise, prefix distribution may or may not fit in depending on the design decisions that would be made. I.e., if all BGP mechanisms needed for IP prefix distribution (such as policy-based best-path selection, aggregation, NH behavior, etc.) are preserved, than the protocol may be capable of doing so. There would still be the same operational considerations though, see below pls. > If so, what makes the imaginary GIDP more suited for so-called > "overloading" than BGP? A clear answer to this question would likely > be usable as requirements for improving BGP... which would be a > positive outcome. From my message to Eric: > I think the argument here is about risk assessment and management. > > Though it is possible to do a fine job of clearly separating different > applications of the same protocol within the system, using a separate > protocol makes it much more likely to happen. and from my message to Pedro: > The way I see it, the major concern is overloading of BGP, which is > part of Internet-critical infrastructure, with non-routing > functionality. Hence, the first step would be to give another > (similar) transport to those application and keep them away from BGP. > > I could certainly see how people would feel comfortable putting > multiple non-critical network-based applications on the same transport > system. However, I could also see that at some point some critical > functionality needs to be implemented and people don't feel > comfortable putting it on the same transport, and decide to have a > separate protocol for it. Regards. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 20:15:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17152 for ; Tue, 29 Jul 2003 20:15:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hecv-0007ng-6U for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 20:15:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U0FXcr029978 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 20:15:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hecQ-0007mg-4o; Tue, 29 Jul 2003 20:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hebT-0007ks-E5 for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 20:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17029 for ; Tue, 29 Jul 2003 20:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hebR-0003Rn-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:14:01 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19hebQ-0003RI-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:14:00 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6U0DTu66424; Tue, 29 Jul 2003 17:13:29 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6U0DTk69365; Tue, 29 Jul 2003 17:13:29 -0700 (PDT) (envelope-from roque) Message-Id: <200307300013.h6U0DTk69365@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <154497849009.20030729165751@psg.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:13:29 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > Pedro, >>> IMO, attempts to pull out from MP-BGP what's already there would >>> be a no-op. >> I'm glad we agree on something :-) I'm just going to press you a >> little bit more and request you to define "already there". >> What is the criteria: WG document ? service provider deployements ? >> a vendor implementation ? interoperable implementations ? > Let's think about this. On the one hand we want to be reasonable and > avoid recoding/redebugging things that are already widely agreed on > and/or deployed. On the other hand we don't want to fall for the > "oh, but I just coded it yesterday, and here's the draft" trick. How > about something along these lines: "an IETF RFC, or a de-facto > multi-vendor interoperable standard"? Other suggestions? Alex, What is published as RFCs doesn't reflect my definition of what is "already there". In several areas, the best one can get to is WG document despite years spent in the process, running code and customer deployments. Without wanting to reopen unproductive discussions, this doesn't usually reflect lack of quality of the proposals but "process blocks". There is an a very high level of entropy which is created when something stops being an 'idea' and becomes used in production networks. Can we expect the IESG to acknowledge that these documents should be published as RFCs in order to facilitate interoperability ? Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 20:19:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15234 for ; Tue, 29 Jul 2003 19:28:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdsv-0004zp-G0; Tue, 29 Jul 2003 19:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hdsJ-0004zS-LK for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:27:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15211 for ; Tue, 29 Jul 2003 19:27:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hdsI-0002v6-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:27:22 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19hdsC-0002uZ-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:27:16 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6TNQipp018221; Tue, 29 Jul 2003 16:26:45 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT39409; Tue, 29 Jul 2003 16:21:46 -0700 (PDT) Message-ID: <3F2702AF.252E568F@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 01:26:39 +0200 Content-Transfer-Encoding: 7bit I am sure those opinions must be documented - could you compile a URL reference list so we can all see how bad it "performs" today ? Also if those folks are real researchers we will most likely be able to also see studies on how much time do we have left. R. > Randy Bush wrote: > > > There has always been an issue if one should extend one city with new > > buildings or start over and build new city. My take on this is that if > > the architecture of a given city is good, communication is perfect and > > can scale adding a new buildings or districts nicely divided from one > > another will not harm anyone to get to large sizes accomodating all > > newcommers. > > well, so much for bgp, as anyone researcher who actually looks at > how the protocol performs on the net will tell you. > > randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 20:34:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15778 for ; Tue, 29 Jul 2003 19:46:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heAL-0005vo-VL; Tue, 29 Jul 2003 19:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19he9z-0005vX-U7 for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:45:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15757 for ; Tue, 29 Jul 2003 19:45:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19he9y-000340-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:45:38 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19he9x-00033x-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:45:37 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19he9x-0004Qf-Kc; Tue, 29 Jul 2003 16:45:37 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Robert Raszuk Cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <3F2702AF.252E568F@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:45:36 -0700 Content-Transfer-Encoding: 7bit > I am sure those opinions must be documented - could you compile a URL > reference list so we can all see how bad it "performs" today ? other than the large literature on the issue, we working on one particularly ugly piece of it now. showing it to dr. bug on thursday, and hope to have the first ppt at apnic next month. > Also if those folks are real researchers we will most likely be > able to also see studies on how much time do we have left. it's a long way from that. research is still trying to differentiate between problems caused by configuration, by implementaion, and by the protocol itself. but today, i am looking at one single announce creating over 40 events just a few hops away (in a real network). but the point is that, while we have such outrageous behavior, no matter that we are still trying to work out all the causes, it is scarily not appropriate to characterize bgp as > the architecture of a given city is good, communication is > perfect and can scale randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 20:37:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17709 for ; Tue, 29 Jul 2003 20:37:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hexh-0008ML-SQ; Tue, 29 Jul 2003 20:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hexB-0008LW-Ei for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 20:36:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17684 for ; Tue, 29 Jul 2003 20:36:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hex9-0003dE-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:36:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19hex8-0003d9-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:36:26 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19hex8-000HKv-Th; Wed, 30 Jul 2003 00:36:26 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <27500124180.20030729173546@psg.com> To: Robert Raszuk CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3F26FAE6.EA0D6868@cisco.com> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:35:46 -0700 Content-Transfer-Encoding: 7bit Robert, > While watching this debate I have a feeling that the problem here is as > old as civilization ;-). [leaving out the city development part, it seems being discussed already ;)] > So as it was said by others a number of times this discussion is just > about software eng - nothing else. Yes and no. Yes, SW engineering is what we constantly keep in mind in this discussion. However, this is not what we are trying to define here. As one of the IETF participants told after the area meeting, we need to admit that the decisions we make at the protocol level within the IETF _do_ affect the SW architectures and running code. I'd like to take this further and say that it is perfectly appropriate for us to keep the engineering aspects in mind and make the right choices at the protocol level. This is the i_E_tf. Saying "ouch! this is engineering, we can't be thinking about this" would be wrong. What we are also talking about here is splitting the protocol evolution. I.e., making it clear that this is not BGP any more, checking if any refinements are needed in the base functionality, and then letting it live its own life with its own extensions and features, without looking back at backwards compatibility with BGP... > A few providers said that they would like to run only a number of > features they use ... AFAIK that should be doable already in most of the > shipping implementations. from my message to Eric: Arguing that we should stop putting _any_ features in BGP would seem a non-starter to me. I believe the discussion is about non-routing applications of the MP-BGP framework. > Also it seems to be some interesting assumption that if we separate so > called "non-routing" info from BGP the entire system would behave much > better. I would like to see what facts make anyone feel/think that way > ;) again, it's about risk management. even with a separate protocol, there is some risk that a vendor will do a poor job, but it's much less likely that the same running environment, internal system infrastructure will be used. Same way as I _practically_ don't have to worry about OSPF bugs if I'm running ISIS in my network, I won't be as much concerned about bugs in mechanism X if I'm running BGP and X is put on top of a separate protocol. > Last lightly assume we go down the path and invent, implement & deploy a > new protocol instance/port would that mean that we will from such a > moment start indefinitely putting all new things on it or will this > topic be comming back every now and then and each time a "new protocol" > or "new port number" will be recommended ??? As clearly definitions of > routing and non routing, critical and non critical information is > different depending who get's to reply my suggestion for routing > directorate would be to have a BGP port number progressing with the > calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 etc > ... :):). Just one page draft. The topic of where certain functionality should be put is a valid one and will come back over and over again. This is a normal process. From my message to Pedro: The way I see it, the major concern is overloading of BGP, which is part of Internet-critical infrastructure, with non-routing functionality. Hence, the first step would be to give another (similar) transport to those application and keep them away from BGP. I could certainly see how people would feel comfortable putting multiple non-critical network-based applications on the same transport system. However, I could also see that at some point some critical functionality needs to be implemented and people don't feel comfortable putting it on the same transport, and decide to have a separate protocol for it. > Now time for few comments from this thread ... >> Thanks! Really great summary of the required functionality! >> This is at least what I would have in mind. > I am missing the point above. BGP provides this already in two planes. > One is per AFI/SAFI information distribution. As far as I see all new > BGP (even non-routing) extensions are nicely separated in their own > AFI/SAFIs most with additional capabilities. Second one is realized in > at least two ways for pushing to your peer inbound filtering so the peer > on outbound already filters (ORF drafts - prefix, ext community, as path > or rt-constrain draft). So what exactly is missing ? The point is that I agree that the MP-BGP framework is a good match for the required functionality, however the number of concerns we have heard suggest that it may not be THE right choice in the long run. Cheers Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 20:49:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16163 for ; Tue, 29 Jul 2003 19:59:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heNR-0006qw-B5 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:59:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6TNxXxS026336 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 19:59:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heMv-0006my-Dv; Tue, 29 Jul 2003 19:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heMT-0006ma-4C for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 19:58:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16133 for ; Tue, 29 Jul 2003 19:58:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19heMR-0003Ae-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:58:31 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19heMQ-0003Ab-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 19:58:30 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19heMR-000EUY-2b; Tue, 29 Jul 2003 23:58:31 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <154497849009.20030729165751@psg.com> To: Pedro Roque Marques CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:57:51 -0700 Content-Transfer-Encoding: 7bit Pedro, >> IMO, attempts to pull out from MP-BGP what's already there would be >> a no-op. > I'm glad we agree on something :-) I'm just going to press you a > little bit more and request you to define "already there". > What is the criteria: WG document ? service provider deployements ? > a vendor implementation ? interoperable implementations ? Let's think about this. On the one hand we want to be reasonable and avoid recoding/redebugging things that are already widely agreed on and/or deployed. On the other hand we don't want to fall for the "oh, but I just coded it yesterday, and here's the draft" trick. How about something along these lines: "an IETF RFC, or a de-facto multi-vendor interoperable standard"? Other suggestions? >> I could certainly see how people would feel comfortable putting >> multiple non-critical network-based applications on the same >> transport system. > One of the points that people keep ignoring is that the definition of > critical and non-critical is highly subjective and depends a lot on > who is making the call. Indeed. Note the "Internet-critical" part. > I work with customers to whom IP is non-critical while VPN services > are critical given that they make more money out of the latter > than the former (VPN services are also often sold as higher > reliability than IP service). I also work w/ customers that have a > completely opposite point of view. > Thus my definition of critical has necessarily to be the entire set of > services (ip unicast/multicast, 2547, l2vpns). > ipv6 routing is probably the service considered least critical by SPs > but even this one is critical to quite a few of them and a vendor is > force to treat it has such. > Personally i think that the assumption of "non-critical" is one of the > highest reasoning flaws in this discussion. We have a couple of considerations here: a) level of criticality, and b) fate sharing. While from the perspective of a stand-alone SP, Internet routing and L2VPNs might be of equal significance, and hence criticality, if we look at it from the perspective of the Internet as a whole (which is what we are supposed to at least keep in mind in the IETF), or at least a set of cooperating service providers, then VPN functionality may very well depend on routing (in case of a PE-to-PE tunnel, for example); in other words, VPN mechanisms use services provided by routing, and hence routing becomes more critical. The fate sharing argument is bidirectional--we probably don't want routing to pay the tax for non-routing related features, and the guys for whom VPNs are much more important may not want to pay the tax for whatever we do with Internet routing. If that's the case, separating the two is a good idea. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 20:53:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17997 for ; Tue, 29 Jul 2003 20:53:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfDe-0000h0-B3 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 20:53:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U0rUeN002659 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 20:53:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfDA-0000dR-SU; Tue, 29 Jul 2003 20:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfCs-0000aL-GP for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 20:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17992 for ; Tue, 29 Jul 2003 20:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hfCq-0003jB-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:52:40 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19hfCp-0003j3-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:52:39 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6U0q8pp000828; Tue, 29 Jul 2003 17:52:08 -0700 (PDT) Received: (from achandra@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA22230; Tue, 29 Jul 2003 17:52:08 -0700 (PDT) From: Chandrashekhar Appanna To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030730005207.GA18303@cypher.cisco.com> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <27500124180.20030729173546@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27500124180.20030729173546@psg.com> User-Agent: Mutt/1.4i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:52:07 -0700 On Tue, Jul 29, 2003 at 05:35:46PM -0700, Alex Zinin wrote: > > I'd like to take this further and say that it is perfectly appropriate > for us to keep the engineering aspects in mind and make the right > choices at the protocol level. This is the i_E_tf. Saying "ouch! this > is engineering, we can't be thinking about this" would be wrong. > .. > again, it's about risk management. > > even with a separate protocol, there is some risk that a vendor will > do a poor job, but it's much less likely that the same running > environment, internal system infrastructure will be used. Same way as > I _practically_ don't have to worry about OSPF bugs if I'm running > ISIS in my network, I won't be as much concerned about bugs in > mechanism X if I'm running BGP and X is put on top of a separate > protocol. > So how do we reach consensus on a measure for 'risk' that is not tainted by preferences based on what is profitable/convenient for some given set of participants in any proposal/discussion for a new 'item' that needs BGP. A new protocol would raise the same set of concerns. If there is a reasonably clear requirement for a new protocol for a given set of applications, I think it may be a good idea to just define what those are and why there is a feeling that they do not belong in BGP. Would that be easier than to debate about a future proof 'new' protocol for 'all the other stuff'? rgds, Chandra. > > Last lightly assume we go down the path and invent, implement & deploy a > > new protocol instance/port would that mean that we will from such a > > moment start indefinitely putting all new things on it or will this > > topic be comming back every now and then and each time a "new protocol" > > or "new port number" will be recommended ??? As clearly definitions of > > routing and non routing, critical and non critical information is > > different depending who get's to reply my suggestion for routing > > directorate would be to have a BGP port number progressing with the > > calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 etc > > ... :):). Just one page draft. > > The topic of where certain functionality should be put is a valid one > and will come back over and over again. This is a normal process. > From my message to Pedro: > > The way I see it, the major concern is overloading of BGP, which is > part of Internet-critical infrastructure, with non-routing > functionality. Hence, the first step would be to give another > (similar) transport to those application and keep them away from BGP. > > I could certainly see how people would feel comfortable putting > multiple non-critical network-based applications on the same transport > system. However, I could also see that at some point some critical > functionality needs to be implemented and people don't feel > comfortable putting it on the same transport, and decide to have a > separate protocol for it. > > > Now time for few comments from this thread ... > > >> Thanks! Really great summary of the required functionality! > >> This is at least what I would have in mind. > > > I am missing the point above. BGP provides this already in two planes. > > One is per AFI/SAFI information distribution. As far as I see all new > > BGP (even non-routing) extensions are nicely separated in their own > > AFI/SAFIs most with additional capabilities. Second one is realized in > > at least two ways for pushing to your peer inbound filtering so the peer > > on outbound already filters (ORF drafts - prefix, ext community, as path > > or rt-constrain draft). So what exactly is missing ? > > The point is that I agree that the MP-BGP framework is a good match > for the required functionality, however the number of concerns we have > heard suggest that it may not be THE right choice in the long run. > > Cheers > > Alex > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 21:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17153 for ; Tue, 29 Jul 2003 20:15:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hecQ-0007mg-4o; Tue, 29 Jul 2003 20:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hebT-0007ks-E5 for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 20:14:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17029 for ; Tue, 29 Jul 2003 20:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hebR-0003Rn-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:14:01 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19hebQ-0003RI-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:14:00 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6U0DTu66424; Tue, 29 Jul 2003 17:13:29 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6U0DTk69365; Tue, 29 Jul 2003 17:13:29 -0700 (PDT) (envelope-from roque) Message-Id: <200307300013.h6U0DTk69365@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <154497849009.20030729165751@psg.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:13:29 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > Pedro, >>> IMO, attempts to pull out from MP-BGP what's already there would >>> be a no-op. >> I'm glad we agree on something :-) I'm just going to press you a >> little bit more and request you to define "already there". >> What is the criteria: WG document ? service provider deployements ? >> a vendor implementation ? interoperable implementations ? > Let's think about this. On the one hand we want to be reasonable and > avoid recoding/redebugging things that are already widely agreed on > and/or deployed. On the other hand we don't want to fall for the > "oh, but I just coded it yesterday, and here's the draft" trick. How > about something along these lines: "an IETF RFC, or a de-facto > multi-vendor interoperable standard"? Other suggestions? Alex, What is published as RFCs doesn't reflect my definition of what is "already there". In several areas, the best one can get to is WG document despite years spent in the process, running code and customer deployments. Without wanting to reopen unproductive discussions, this doesn't usually reflect lack of quality of the proposals but "process blocks". There is an a very high level of entropy which is created when something stops being an 'idea' and becomes used in production networks. Can we expect the IESG to acknowledge that these documents should be published as RFCs in order to facilitate interoperability ? Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 21:21:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18542 for ; Tue, 29 Jul 2003 21:21:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfeH-0001dP-C7; Tue, 29 Jul 2003 21:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfdQ-0001ZI-DC for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 21:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18514 for ; Tue, 29 Jul 2003 21:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hfdN-0003ow-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 21:20:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hfdN-0003oj-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 21:20:05 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6U1JXpZ008319; Tue, 29 Jul 2003 18:19:33 -0700 (PDT) Received: from [64.101.214.208] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA20315; Tue, 29 Jul 2003 21:19:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <71495483527.20030729161825@psg.com> References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> To: Alex Zinin From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 21:19:25 -0400 At 4:18 PM -0700 7/29/03, Alex Zinin wrote: >Hi John, good to hear from you! Glad to bring a little ray of sunshine to your day. :-) >and from my message to Pedro: > >> The way I see it, the major concern is overloading of BGP, which is > > part of Internet-critical infrastructure, with non-routing > > functionality. I would be interested to know if you can elaborate on this without resort to the ambiguous term "non-routing". --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 21:24:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17708 for ; Tue, 29 Jul 2003 20:37:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19heyD-000082-KY for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 20:37:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U0bXC2000492 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 20:37:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hexh-0008ML-SQ; Tue, 29 Jul 2003 20:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hexB-0008LW-Ei for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 20:36:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17684 for ; Tue, 29 Jul 2003 20:36:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hex9-0003dE-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:36:27 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19hex8-0003d9-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:36:26 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19hex8-000HKv-Th; Wed, 30 Jul 2003 00:36:26 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <27500124180.20030729173546@psg.com> To: Robert Raszuk CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3F26FAE6.EA0D6868@cisco.com> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:35:46 -0700 Content-Transfer-Encoding: 7bit Robert, > While watching this debate I have a feeling that the problem here is as > old as civilization ;-). [leaving out the city development part, it seems being discussed already ;)] > So as it was said by others a number of times this discussion is just > about software eng - nothing else. Yes and no. Yes, SW engineering is what we constantly keep in mind in this discussion. However, this is not what we are trying to define here. As one of the IETF participants told after the area meeting, we need to admit that the decisions we make at the protocol level within the IETF _do_ affect the SW architectures and running code. I'd like to take this further and say that it is perfectly appropriate for us to keep the engineering aspects in mind and make the right choices at the protocol level. This is the i_E_tf. Saying "ouch! this is engineering, we can't be thinking about this" would be wrong. What we are also talking about here is splitting the protocol evolution. I.e., making it clear that this is not BGP any more, checking if any refinements are needed in the base functionality, and then letting it live its own life with its own extensions and features, without looking back at backwards compatibility with BGP... > A few providers said that they would like to run only a number of > features they use ... AFAIK that should be doable already in most of the > shipping implementations. from my message to Eric: Arguing that we should stop putting _any_ features in BGP would seem a non-starter to me. I believe the discussion is about non-routing applications of the MP-BGP framework. > Also it seems to be some interesting assumption that if we separate so > called "non-routing" info from BGP the entire system would behave much > better. I would like to see what facts make anyone feel/think that way > ;) again, it's about risk management. even with a separate protocol, there is some risk that a vendor will do a poor job, but it's much less likely that the same running environment, internal system infrastructure will be used. Same way as I _practically_ don't have to worry about OSPF bugs if I'm running ISIS in my network, I won't be as much concerned about bugs in mechanism X if I'm running BGP and X is put on top of a separate protocol. > Last lightly assume we go down the path and invent, implement & deploy a > new protocol instance/port would that mean that we will from such a > moment start indefinitely putting all new things on it or will this > topic be comming back every now and then and each time a "new protocol" > or "new port number" will be recommended ??? As clearly definitions of > routing and non routing, critical and non critical information is > different depending who get's to reply my suggestion for routing > directorate would be to have a BGP port number progressing with the > calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 etc > ... :):). Just one page draft. The topic of where certain functionality should be put is a valid one and will come back over and over again. This is a normal process. From my message to Pedro: The way I see it, the major concern is overloading of BGP, which is part of Internet-critical infrastructure, with non-routing functionality. Hence, the first step would be to give another (similar) transport to those application and keep them away from BGP. I could certainly see how people would feel comfortable putting multiple non-critical network-based applications on the same transport system. However, I could also see that at some point some critical functionality needs to be implemented and people don't feel comfortable putting it on the same transport, and decide to have a separate protocol for it. > Now time for few comments from this thread ... >> Thanks! Really great summary of the required functionality! >> This is at least what I would have in mind. > I am missing the point above. BGP provides this already in two planes. > One is per AFI/SAFI information distribution. As far as I see all new > BGP (even non-routing) extensions are nicely separated in their own > AFI/SAFIs most with additional capabilities. Second one is realized in > at least two ways for pushing to your peer inbound filtering so the peer > on outbound already filters (ORF drafts - prefix, ext community, as path > or rt-constrain draft). So what exactly is missing ? The point is that I agree that the MP-BGP framework is a good match for the required functionality, however the number of concerns we have heard suggest that it may not be THE right choice in the long run. Cheers Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Tue Jul 29 21:39:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17998 for ; Tue, 29 Jul 2003 20:53:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfDA-0000dR-SU; Tue, 29 Jul 2003 20:53:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfCs-0000aL-GP for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 20:52:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17992 for ; Tue, 29 Jul 2003 20:52:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hfCq-0003jB-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:52:40 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19hfCp-0003j3-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 20:52:39 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6U0q8pp000828; Tue, 29 Jul 2003 17:52:08 -0700 (PDT) Received: (from achandra@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA22230; Tue, 29 Jul 2003 17:52:08 -0700 (PDT) From: Chandrashekhar Appanna To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030730005207.GA18303@cypher.cisco.com> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <27500124180.20030729173546@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <27500124180.20030729173546@psg.com> User-Agent: Mutt/1.4i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 17:52:07 -0700 On Tue, Jul 29, 2003 at 05:35:46PM -0700, Alex Zinin wrote: > > I'd like to take this further and say that it is perfectly appropriate > for us to keep the engineering aspects in mind and make the right > choices at the protocol level. This is the i_E_tf. Saying "ouch! this > is engineering, we can't be thinking about this" would be wrong. > .. > again, it's about risk management. > > even with a separate protocol, there is some risk that a vendor will > do a poor job, but it's much less likely that the same running > environment, internal system infrastructure will be used. Same way as > I _practically_ don't have to worry about OSPF bugs if I'm running > ISIS in my network, I won't be as much concerned about bugs in > mechanism X if I'm running BGP and X is put on top of a separate > protocol. > So how do we reach consensus on a measure for 'risk' that is not tainted by preferences based on what is profitable/convenient for some given set of participants in any proposal/discussion for a new 'item' that needs BGP. A new protocol would raise the same set of concerns. If there is a reasonably clear requirement for a new protocol for a given set of applications, I think it may be a good idea to just define what those are and why there is a feeling that they do not belong in BGP. Would that be easier than to debate about a future proof 'new' protocol for 'all the other stuff'? rgds, Chandra. > > Last lightly assume we go down the path and invent, implement & deploy a > > new protocol instance/port would that mean that we will from such a > > moment start indefinitely putting all new things on it or will this > > topic be comming back every now and then and each time a "new protocol" > > or "new port number" will be recommended ??? As clearly definitions of > > routing and non routing, critical and non critical information is > > different depending who get's to reply my suggestion for routing > > directorate would be to have a BGP port number progressing with the > > calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 etc > > ... :):). Just one page draft. > > The topic of where certain functionality should be put is a valid one > and will come back over and over again. This is a normal process. > From my message to Pedro: > > The way I see it, the major concern is overloading of BGP, which is > part of Internet-critical infrastructure, with non-routing > functionality. Hence, the first step would be to give another > (similar) transport to those application and keep them away from BGP. > > I could certainly see how people would feel comfortable putting > multiple non-critical network-based applications on the same transport > system. However, I could also see that at some point some critical > functionality needs to be implemented and people don't feel > comfortable putting it on the same transport, and decide to have a > separate protocol for it. > > > Now time for few comments from this thread ... > > >> Thanks! Really great summary of the required functionality! > >> This is at least what I would have in mind. > > > I am missing the point above. BGP provides this already in two planes. > > One is per AFI/SAFI information distribution. As far as I see all new > > BGP (even non-routing) extensions are nicely separated in their own > > AFI/SAFIs most with additional capabilities. Second one is realized in > > at least two ways for pushing to your peer inbound filtering so the peer > > on outbound already filters (ORF drafts - prefix, ext community, as path > > or rt-constrain draft). So what exactly is missing ? > > The point is that I agree that the MP-BGP framework is a good match > for the required functionality, however the number of concerns we have > heard suggest that it may not be THE right choice in the long run. > > Cheers > > Alex > > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Tue Jul 29 22:08:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18543 for ; Tue, 29 Jul 2003 21:21:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfei-0001hh-15 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 21:21:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U1LSsL006532 for routing-discussion-archive@odin.ietf.org; Tue, 29 Jul 2003 21:21:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfeH-0001dP-C7; Tue, 29 Jul 2003 21:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hfdQ-0001ZI-DC for routing-discussion@optimus.ietf.org; Tue, 29 Jul 2003 21:20:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18514 for ; Tue, 29 Jul 2003 21:20:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hfdN-0003ow-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 21:20:05 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hfdN-0003oj-00 for routing-discussion@ietf.org; Tue, 29 Jul 2003 21:20:05 -0400 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6U1JXpZ008319; Tue, 29 Jul 2003 18:19:33 -0700 (PDT) Received: from [64.101.214.208] (ssh-rtp-1.cisco.com [161.44.11.166]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id VAA20315; Tue, 29 Jul 2003 21:19:31 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: <71495483527.20030729161825@psg.com> References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> To: Alex Zinin From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 21:19:25 -0400 At 4:18 PM -0700 7/29/03, Alex Zinin wrote: >Hi John, good to hear from you! Glad to bring a little ray of sunshine to your day. :-) >and from my message to Pedro: > >> The way I see it, the major concern is overloading of BGP, which is > > part of Internet-critical infrastructure, with non-routing > > functionality. I would be interested to know if you can elaborate on this without resort to the ambiguous term "non-routing". --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 02:01:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25676 for ; Wed, 30 Jul 2003 02:01:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hk0H-00014Y-V0; Wed, 30 Jul 2003 02:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hk03-00013y-SY for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 01:59:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24190 for ; Wed, 30 Jul 2003 01:59:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hk00-00057w-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 01:59:44 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19hjzz-00057s-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 01:59:43 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6U5xEu81751; Tue, 29 Jul 2003 22:59:14 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6U5xE470168; Tue, 29 Jul 2003 22:59:14 -0700 (PDT) (envelope-from roque) Message-Id: <200307300559.h6U5xE470168@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <154497849009.20030729165751@psg.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 22:59:14 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: >>> I could certainly see how people would feel comfortable putting >>> multiple non-critical network-based applications on the same >>> transport system. >> One of the points that people keep ignoring is that the definition >> of critical and non-critical is highly subjective and depends a lot >> on who is making the call. > Indeed. Note the "Internet-critical" part. This is perhaps a fundamental difference in perception that we have. I don't see the existence of an "Internet" infrastructure as separate from the telecomunications industry. Although the later provides several services to its customers including access to a public network it does so on an infrastruture which is shared in variable degrees. For instance, the transmission infrastruture (wdm, sonet, tdm) tends to be the same for all services the carrier provides. In an increasing number of cases, network nodes such as routers are also shared resources, either by providing transport to several applications or by terminating them. I confess that i'm not quite sure what your goal is... my assumption is that you are concerned w/ the availiability of internet service, which depends on several factors including the stability of router software. While the latter is certainly a cause for concern, i would suggest that you think of this equipment not as "Internet" infrastructure but as equipment which is bought and operated by a telecomunications company. Thus equipment caracteristics and failures are going to play an important role in "Internet" availability, regardless of the root cause of the problem. As such, "critical" needs to be defined from the point of view of a service provider. Personally, i believe that this issue is being completly blown out of proportion. I've not seen any evidence to suggest that adding VPN services, as we are discussing, has higher impact in routing software stability than to add any other type of functionality. I'd like to see people that believe otherwise put forward data that corroborates that view. While people love to state that the "I in IETF stands for Internet" in tend to be very sceptic of how realistic is this view. The Internet doesn't exist in a vacum. The IETF itself doesn't have a vertical approach in terms of considering all levels and elements used to provide internet services. It has mostly an horizontal approach to standardize the IP protocol suite regardless of the application. Typically when the word "Internet" enters a discussion it doesn't do much in terms of achieving progress. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 02:01:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25675 for ; Wed, 30 Jul 2003 02:01:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hk1D-0001BY-Rz for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 02:00:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U60xc5004557 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 02:00:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hk0H-00014Y-V0; Wed, 30 Jul 2003 02:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hk03-00013y-SY for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 01:59:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24190 for ; Wed, 30 Jul 2003 01:59:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hk00-00057w-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 01:59:44 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19hjzz-00057s-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 01:59:43 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6U5xEu81751; Tue, 29 Jul 2003 22:59:14 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6U5xE470168; Tue, 29 Jul 2003 22:59:14 -0700 (PDT) (envelope-from roque) Message-Id: <200307300559.h6U5xE470168@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <154497849009.20030729165751@psg.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 29 Jul 2003 22:59:14 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: >>> I could certainly see how people would feel comfortable putting >>> multiple non-critical network-based applications on the same >>> transport system. >> One of the points that people keep ignoring is that the definition >> of critical and non-critical is highly subjective and depends a lot >> on who is making the call. > Indeed. Note the "Internet-critical" part. This is perhaps a fundamental difference in perception that we have. I don't see the existence of an "Internet" infrastructure as separate from the telecomunications industry. Although the later provides several services to its customers including access to a public network it does so on an infrastruture which is shared in variable degrees. For instance, the transmission infrastruture (wdm, sonet, tdm) tends to be the same for all services the carrier provides. In an increasing number of cases, network nodes such as routers are also shared resources, either by providing transport to several applications or by terminating them. I confess that i'm not quite sure what your goal is... my assumption is that you are concerned w/ the availiability of internet service, which depends on several factors including the stability of router software. While the latter is certainly a cause for concern, i would suggest that you think of this equipment not as "Internet" infrastructure but as equipment which is bought and operated by a telecomunications company. Thus equipment caracteristics and failures are going to play an important role in "Internet" availability, regardless of the root cause of the problem. As such, "critical" needs to be defined from the point of view of a service provider. Personally, i believe that this issue is being completly blown out of proportion. I've not seen any evidence to suggest that adding VPN services, as we are discussing, has higher impact in routing software stability than to add any other type of functionality. I'd like to see people that believe otherwise put forward data that corroborates that view. While people love to state that the "I in IETF stands for Internet" in tend to be very sceptic of how realistic is this view. The Internet doesn't exist in a vacum. The IETF itself doesn't have a vertical approach in terms of considering all levels and elements used to provide internet services. It has mostly an horizontal approach to standardize the IP protocol suite regardless of the application. Typically when the word "Internet" enters a discussion it doesn't do much in terms of achieving progress. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 02:53:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21611 for ; Wed, 30 Jul 2003 02:53:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hkpJ-0004QR-EC for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 02:52:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U6qjvB017011 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 02:52:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hkob-0004KR-7l; Wed, 30 Jul 2003 02:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hkoS-0004KA-Kp for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 02:51:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21599 for ; Wed, 30 Jul 2003 02:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hkoO-0005Ry-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:51:48 -0400 Received: from web42002.mail.yahoo.com ([66.218.93.170]) by ietf-mx with smtp (Exim 4.12) id 19hkoO-0005Rv-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:51:48 -0400 Message-ID: <20030730065118.13175.qmail@web42002.mail.yahoo.com> Received: from [203.200.20.226] by web42002.mail.yahoo.com via HTTP; Wed, 30 Jul 2003 02:51:18 EDT From: Tulip Rasputin Subject: Re: Open Routing Area meeting in Vienna To: raszuk@cisco.com Cc: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 02:51:18 -0400 (EDT) Robert, > There has always been an issue if one should extend one city with new > buildings or start over and build new city. My take on this is that if > the architecture of a given city is good, communication is perfect and > can scale adding a new buildings or districts nicely divided from one > another will not harm anyone to get to large sizes accomodating all > newcommers. I *dont* like this analogy at all but since you've started this, let me make an attempt to explain you using the same. Say you have this really great city and the taxes are really low here. The infrastructure is great, the climate is fantastic and you have lovely beaches. Everybody is happy, the administration is satisfied with the population and the related issues. Because of the above mentioned factors, people from nearby (and far off) states/cities start immigrating to this city. They believe that the infrastructure is great (and all the other things which i mentioned) and that it would really take them no time to commute to their work (which happens to be in other cities!). Over a period of time, you have equal number of people living in this city who work here and who work in places nowhere connected/associated with this city. They by all means share the same resources as the people living/working in this city. Dont you now see a problem with this (traffic jams/increased property rates/rents/pollution/etc)? The local authorities would somehow need to put a check on this. They can as a deterrent increase the taxes or do something to prevent more people from coming in. The infrastructure is now enough to just keep this much population. Now what if more people want to come in who need to work here? What about the offsprings? As i had said earlier, i dont approve of this analogy at all and infact find it quite dumb - but used the same to explain my point and what probably has been plaguing the ADs and the other IETFers for long! BGP is critical for the Internet (Pedro might feel uncomfortable for my using this term so loosely :) !) and we must proceed with caution. By adding more and more features we will only be bloating the code size and the probability of introducing more and more bugs. Yes, this is an implementation specific issue and the vendors will have their own ways to deal with it - but the fact remains that by doing this we make BGP more and more vulnerable than what it already is. Regards, Rasputin P.S. And why is it that we only see some of the vendors in favor of bundling BGP with everything. Is there any ISP out there which feels the same? What is it that they feel is right? Would they want to muck around with BGP? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 02:57:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21720 for ; Wed, 30 Jul 2003 02:57:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hksU-0004Ya-6E; Wed, 30 Jul 2003 02:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hks8-0004Xs-P5 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 02:55:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21678 for ; Wed, 30 Jul 2003 02:55:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hks4-0005TB-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:55:36 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hks4-0005T6-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:55:36 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U6thFJ006610 for ; Wed, 30 Jul 2003 08:55:44 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) From: Kurt Erik Lindqvist To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <2482819267.20030729124721@psg.com> Message-Id: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 08:55:36 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> Given that the underlying desire seems to be that SPs that are not >> interest in a given service would prefer not to have that >> functionality added to BGP (in fact many people mentioned that they >> wanted not to have the functionality in the router software, period) A number of people said they at least did want this code enabled if they where not using the service. >> and that there several services that are in consideration, it is not >> clear to me that the community will be able to agree on which subsets >> are wanted and which unwanted. Either in BGP or in any new protocol. It's not about what services the community want's. It's how data for each of the protocols/services are distributed. The SPs that went to the mike said they didn't see the benefit of overloading BGP with all this. Or any other routing protocol. >> An (incomplete) list of services would be: >> ipv4-unicast, ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ >> ipv4 / ipv6 / unicast/multicast variations, labeled-unicast, >> vpn auto-discovery, bgp-l2vpn, ip-tunneling-discovery, etc... These come in two types. Topology reachability information, and others. It's the second group that I personally think we need to move away. But I agree with Alex comment below that taking something out that is already in is a no-op. > IMO, attempts to pull out from MP-BGP what's already there would be a > no-op. I also believe that we have a certain level of agreement (based > on my discussions within the rtg-dir, and in the hall-ways) that there > are certain types of information that should be distributed within the > RP. The major point of contention seems to be distribution of > information that is not really routing-related or tightly coupled with > it, such as VPN discovery and signaling, etc. Agreed. >> One interesting question is how do you go about defining which subsets >> of services fit where... given that different providers want different >> subsets and that the rational is that the service a SP don't care >> about should not be in the protocol that is used by that SP, it would >> seem to me that you need one protocol per service/application. Why not? Why do we need a "super-protocol" that distributes it all? Will this then speak XML? Can I upload my configurations in it? Where is the limit? Let's at least break out signaling from the reachability information. > The way I see it, the major concern is overloading of BGP, which is > part of Internet-critical infrastructure, with non-routing > functionality. Hence, the first step would be to give another > (similar) transport to those application and keep them away from BGP. Agreed. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPydr66arNKXTPFCVEQImwgCfQYxvE7N/7/a3CbJknWDgsnq86rwAoJMQ NQqAWIAadaE/fGHq0GroEyGV =H/IQ -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 02:57:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21723 for ; Wed, 30 Jul 2003 02:57:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hktA-0004eY-CO for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 02:56:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U6uiWn017878 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 02:56:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hksU-0004Ya-6E; Wed, 30 Jul 2003 02:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hks8-0004Xs-P5 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 02:55:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21678 for ; Wed, 30 Jul 2003 02:55:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hks4-0005TB-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:55:36 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hks4-0005T6-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:55:36 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U6thFJ006610 for ; Wed, 30 Jul 2003 08:55:44 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) From: Kurt Erik Lindqvist To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <2482819267.20030729124721@psg.com> Message-Id: X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 08:55:36 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > >> Given that the underlying desire seems to be that SPs that are not >> interest in a given service would prefer not to have that >> functionality added to BGP (in fact many people mentioned that they >> wanted not to have the functionality in the router software, period) A number of people said they at least did want this code enabled if they where not using the service. >> and that there several services that are in consideration, it is not >> clear to me that the community will be able to agree on which subsets >> are wanted and which unwanted. Either in BGP or in any new protocol. It's not about what services the community want's. It's how data for each of the protocols/services are distributed. The SPs that went to the mike said they didn't see the benefit of overloading BGP with all this. Or any other routing protocol. >> An (incomplete) list of services would be: >> ipv4-unicast, ipv4-multicast, ipv6-unicast, ipv6-multicast, 2547 w/ >> ipv4 / ipv6 / unicast/multicast variations, labeled-unicast, >> vpn auto-discovery, bgp-l2vpn, ip-tunneling-discovery, etc... These come in two types. Topology reachability information, and others. It's the second group that I personally think we need to move away. But I agree with Alex comment below that taking something out that is already in is a no-op. > IMO, attempts to pull out from MP-BGP what's already there would be a > no-op. I also believe that we have a certain level of agreement (based > on my discussions within the rtg-dir, and in the hall-ways) that there > are certain types of information that should be distributed within the > RP. The major point of contention seems to be distribution of > information that is not really routing-related or tightly coupled with > it, such as VPN discovery and signaling, etc. Agreed. >> One interesting question is how do you go about defining which subsets >> of services fit where... given that different providers want different >> subsets and that the rational is that the service a SP don't care >> about should not be in the protocol that is used by that SP, it would >> seem to me that you need one protocol per service/application. Why not? Why do we need a "super-protocol" that distributes it all? Will this then speak XML? Can I upload my configurations in it? Where is the limit? Let's at least break out signaling from the reachability information. > The way I see it, the major concern is overloading of BGP, which is > part of Internet-critical infrastructure, with non-routing > functionality. Hence, the first step would be to give another > (similar) transport to those application and keep them away from BGP. Agreed. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPydr66arNKXTPFCVEQImwgCfQYxvE7N/7/a3CbJknWDgsnq86rwAoJMQ NQqAWIAadaE/fGHq0GroEyGV =H/IQ -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 03:14:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22149 for ; Wed, 30 Jul 2003 03:14:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hl9h-0005Wk-Oi for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:13:49 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U7DnlN021242 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:13:49 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hl8u-0005Qg-Kv; Wed, 30 Jul 2003 03:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hl8k-0005Pp-N4 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:12:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22124 for ; Wed, 30 Jul 2003 03:12:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hl8i-0005bM-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:12:48 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hl8h-0005bJ-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:12:47 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U7CpFJ006627; Wed, 30 Jul 2003 09:12:51 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alex Zinin , routing-discussion@ietf.org To: raszuk@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <3F26FAE6.EA0D6868@cisco.com> Message-Id: <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:12:46 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > While watching this debate I have a feeling that the problem here is as > old as civilization ;-). While watching this debate I realize that most people posting are router vendors...:-) > So as it was said by others a number of times this discussion is just > about software eng - nothing else. From the SP POV this is about operational stability. Not about software engineering. > A few providers said that they would like to run only a number of > features they use ... AFAIK that should be doable already in most of > the > shipping implementations. I disagree. In the products from the two vendors, I can't today decide what features to use or not AFAIK. I can decide what information to process or not. But that is not the same thing. > Also it seems to be some interesting assumption that if we separate so > called "non-routing" info from BGP the entire system would behave much > better. I would like to see what facts make anyone feel/think that way > ;) What are the facts that we need to put everything into BGP? And where do we stop? Why not make the NLRI field XML code? Javascript? Operational experience tells me that the easier, simpler and less information there is - the less the chance of a problem. It's as simple as that. > Last lightly assume we go down the path and invent, implement & deploy > a > new protocol instance/port would that mean that we will from such a > moment start indefinitely putting all new things on it or will this > topic be comming back every now and then and each time a "new protocol" > or "new port number" will be recommended ??? As clearly definitions of > routing and non routing, critical and non critical information is > different depending who get's to reply my suggestion for routing > directorate would be to have a BGP port number progressing with the > calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 > etc > ... :):). Just one page draft. I don't see a problem (actually on the contrary) with separating reachability information, signaling, etc. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPydv8aarNKXTPFCVEQLcrwCgmbC2SRtlmSQc9MAXcy5BrwDJzgwAn2Uu yu/AckoFuGA/+XWWQe7pt5O9 =9OAs -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 03:30:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22426 for ; Wed, 30 Jul 2003 03:30:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlPC-000610-3H for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:29:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U7TnKl023122 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:29:50 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlOP-0005vB-GL; Wed, 30 Jul 2003 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlNc-0005sO-7l for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:28:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22398 for ; Wed, 30 Jul 2003 03:28:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlNY-0005fq-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:28:09 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hlNY-0005fb-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:28:08 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6U7RbLH027012; Wed, 30 Jul 2003 00:27:38 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT76034; Wed, 30 Jul 2003 00:22:37 -0700 (PDT) Message-ID: <3F277365.B42998C5@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tulip Rasputin , Kurt Erik Lindqvist CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <20030730065118.13175.qmail@web42002.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:27:33 +0200 Content-Transfer-Encoding: 7bit Tulip, > And why is it that we only see some of the vendors in favor of bundling BGP with everything. Is > there any ISP out there which feels the same? What is it that they feel is right? Would they want > to muck around with BGP? Each operator I have talked to clearly indicated huge resistance to undertake operational pain of rolling new intra/inter domain "non-routing" information distribution protocol. Kurt, > >> Given that the underlying desire seems to be that SPs that are not > >> interest in a given service would prefer not to have that > >> functionality added to BGP (in fact many people mentioned that they > >> wanted not to have the functionality in the router software, period) > > A number of people said they at least did want this code enabled if > they where not using the service. This stament is comming back a lot. What does it mean "code enabled" ? Maybe someone would provide an example how let's say adding multicast distribution to BGP impacts IPv4 unicast address family ? If one does not need to use it - just don't configure it. Almost all protocol extensions are knobed - thay are NOT enabled by default carrying vacum. Most vendors I am aware about either already or soon have the option of per AFI/SAFI specific BGP sub-process clearly separating running or not new functionality. If I have BGP free core, and I don't type by accident "router bgp ..." I don't really see a good reason to buy routers which do not support BGP just so I don't have it in the core. If I have IPv4 ASBRs and i am not keen on running on them 2547 just don't configure vpnv4 AF there. I am yet to see a one single case where new opaque to existing functionality code presence if not configured or enabled by user caused any trouble to anyone. Thx, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 03:30:16 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22428 for ; Wed, 30 Jul 2003 03:30:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlOP-0005vB-GL; Wed, 30 Jul 2003 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlNc-0005sO-7l for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:28:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22398 for ; Wed, 30 Jul 2003 03:28:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlNY-0005fq-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:28:09 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hlNY-0005fb-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:28:08 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6U7RbLH027012; Wed, 30 Jul 2003 00:27:38 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT76034; Wed, 30 Jul 2003 00:22:37 -0700 (PDT) Message-ID: <3F277365.B42998C5@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Tulip Rasputin , Kurt Erik Lindqvist CC: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <20030730065118.13175.qmail@web42002.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:27:33 +0200 Content-Transfer-Encoding: 7bit Tulip, > And why is it that we only see some of the vendors in favor of bundling BGP with everything. Is > there any ISP out there which feels the same? What is it that they feel is right? Would they want > to muck around with BGP? Each operator I have talked to clearly indicated huge resistance to undertake operational pain of rolling new intra/inter domain "non-routing" information distribution protocol. Kurt, > >> Given that the underlying desire seems to be that SPs that are not > >> interest in a given service would prefer not to have that > >> functionality added to BGP (in fact many people mentioned that they > >> wanted not to have the functionality in the router software, period) > > A number of people said they at least did want this code enabled if > they where not using the service. This stament is comming back a lot. What does it mean "code enabled" ? Maybe someone would provide an example how let's say adding multicast distribution to BGP impacts IPv4 unicast address family ? If one does not need to use it - just don't configure it. Almost all protocol extensions are knobed - thay are NOT enabled by default carrying vacum. Most vendors I am aware about either already or soon have the option of per AFI/SAFI specific BGP sub-process clearly separating running or not new functionality. If I have BGP free core, and I don't type by accident "router bgp ..." I don't really see a good reason to buy routers which do not support BGP just so I don't have it in the core. If I have IPv4 ASBRs and i am not keen on running on them 2547 just don't configure vpnv4 AF there. I am yet to see a one single case where new opaque to existing functionality code presence if not configured or enabled by user caused any trouble to anyone. Thx, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 03:39:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21613 for ; Wed, 30 Jul 2003 02:53:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hkob-0004KR-7l; Wed, 30 Jul 2003 02:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hkoS-0004KA-Kp for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 02:51:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21599 for ; Wed, 30 Jul 2003 02:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hkoO-0005Ry-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:51:48 -0400 Received: from web42002.mail.yahoo.com ([66.218.93.170]) by ietf-mx with smtp (Exim 4.12) id 19hkoO-0005Rv-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 02:51:48 -0400 Message-ID: <20030730065118.13175.qmail@web42002.mail.yahoo.com> Received: from [203.200.20.226] by web42002.mail.yahoo.com via HTTP; Wed, 30 Jul 2003 02:51:18 EDT From: Tulip Rasputin Subject: Re: Open Routing Area meeting in Vienna To: raszuk@cisco.com Cc: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 02:51:18 -0400 (EDT) Robert, > There has always been an issue if one should extend one city with new > buildings or start over and build new city. My take on this is that if > the architecture of a given city is good, communication is perfect and > can scale adding a new buildings or districts nicely divided from one > another will not harm anyone to get to large sizes accomodating all > newcommers. I *dont* like this analogy at all but since you've started this, let me make an attempt to explain you using the same. Say you have this really great city and the taxes are really low here. The infrastructure is great, the climate is fantastic and you have lovely beaches. Everybody is happy, the administration is satisfied with the population and the related issues. Because of the above mentioned factors, people from nearby (and far off) states/cities start immigrating to this city. They believe that the infrastructure is great (and all the other things which i mentioned) and that it would really take them no time to commute to their work (which happens to be in other cities!). Over a period of time, you have equal number of people living in this city who work here and who work in places nowhere connected/associated with this city. They by all means share the same resources as the people living/working in this city. Dont you now see a problem with this (traffic jams/increased property rates/rents/pollution/etc)? The local authorities would somehow need to put a check on this. They can as a deterrent increase the taxes or do something to prevent more people from coming in. The infrastructure is now enough to just keep this much population. Now what if more people want to come in who need to work here? What about the offsprings? As i had said earlier, i dont approve of this analogy at all and infact find it quite dumb - but used the same to explain my point and what probably has been plaguing the ADs and the other IETFers for long! BGP is critical for the Internet (Pedro might feel uncomfortable for my using this term so loosely :) !) and we must proceed with caution. By adding more and more features we will only be bloating the code size and the probability of introducing more and more bugs. Yes, this is an implementation specific issue and the vendors will have their own ways to deal with it - but the fact remains that by doing this we make BGP more and more vulnerable than what it already is. Regards, Rasputin P.S. And why is it that we only see some of the vendors in favor of bundling BGP with everything. Is there any ISP out there which feels the same? What is it that they feel is right? Would they want to muck around with BGP? ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 03:44:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22758 for ; Wed, 30 Jul 2003 03:44:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlbx-0006Yx-1L; Wed, 30 Jul 2003 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlbO-0006YP-Pj for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:42:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22712 for ; Wed, 30 Jul 2003 03:42:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlbL-0005jw-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:42:23 -0400 Received: from web42002.mail.yahoo.com ([66.218.93.170]) by ietf-mx with smtp (Exim 4.12) id 19hlbK-0005jV-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:42:22 -0400 Message-ID: <20030730074154.26246.qmail@web42002.mail.yahoo.com> Received: from [203.200.20.226] by web42002.mail.yahoo.com via HTTP; Wed, 30 Jul 2003 03:41:54 EDT From: Tulip Rasputin Subject: Re: Open Routing Area meeting in Vienna To: raszuk@cisco.com, Kurt Erik Lindqvist Cc: routing-discussion@ietf.org In-Reply-To: <3F277365.B42998C5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 03:41:54 -0400 (EDT) Robert, > Each operator I have talked to clearly indicated huge resistance to > undertake operational pain of rolling new intra/inter domain > "non-routing" information distribution protocol. If this is the only *motivation* then i am sure we need to think more before proceeding further. It is really an operational pain to configure geographically separated routers. Why not, have BGP automatically send configurations to all such routers by some sort of "automatic flooding"! > Maybe someone would provide an example how let's say adding multicast > distribution to BGP impacts IPv4 unicast address family ? If one does > not need to use it - just don't configure it. Almost all protocol > extensions are knobed - thay are NOT enabled by default carrying vacum. > Most vendors I am aware about either already or soon have the option of > per AFI/SAFI specific BGP sub-process clearly separating running or not > new functionality. I am sure you must have looked into the BGP implementation for the vendor you work for. Dont you parse for the multicast routes in the same file as you do for the IPv4 unicast address family. Are you sure you didnt tough the functions which parse the IPv4 routes when you introduced multicast support? What i mean to say is that even if you do turn off one particular feature you do put in all the additional code in your main working code - which in turn definitely complicates the stuff and makes it more prone to bugs/mishaps/surprises (depending upon which side of the fence you are on!) By turning off an option you dont remove the code dynamically from the binary image .. Its still there tightly coupled with remaining code! Dynamically removing the code has atleast not been done till the time of my writing this email!! :-) Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 03:47:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22849 for ; Wed, 30 Jul 2003 03:47:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlet-0006kJ-7R; Wed, 30 Jul 2003 03:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hle1-0006jJ-5k for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:45:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22793 for ; Wed, 30 Jul 2003 03:45:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hldx-0005lE-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:45:05 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hldx-0005lB-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:45:05 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U7jDFJ006637; Wed, 30 Jul 2003 09:45:13 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alex Zinin , routing-discussion@ietf.org To: Pedro Roque Marques From: Kurt Erik Lindqvist In-Reply-To: <200307300559.h6U5xE470168@roque-bsd.juniper.net> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:45:08 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > This is perhaps a fundamental difference in perception that we have. > > I don't see the existence of an "Internet" infrastructure as separate > from the telecomunications industry. Although the later provides > several services to its customers including access to a public network > it does so on an infrastruture which is shared in variable degrees. > > For instance, the transmission infrastruture (wdm, sonet, tdm) tends > to be the same for all services the carrier provides. But you do not use SS7 to signal the paths in SONET/SDH, or the OSI information from the ADMs to route the WDM channels. > In an increasing > number of cases, network nodes such as routers are also shared > resources, either by providing transport to several applications or by > terminating them. Yes. But the routers in this case are the same as the ADMs. And those do not signal anything else than the reachability. > I confess that i'm not quite sure what your goal is... my assumption > is that you are concerned w/ the availiability of internet service, > which depends on several factors including the stability of router > software. Among other things. As Randy said, there i a lot of research that also points to the protocol itself. > While the latter is certainly a cause for concern, i would suggest > that you think of this equipment not as "Internet" infrastructure but > as equipment which is bought and operated by a telecomunications > company. I fail to understand this comment? > cause of the problem. As such, "critical" needs to be defined from the > point of view of a service provider. From my experience, when a fault happens, the time it takes to recover is many times mostly due to the protocol. > Personally, i believe that this issue is being completly blown out of > proportion. I've not seen any evidence to suggest that adding VPN > services, as we are discussing, has higher impact in routing software > stability than to add any other type of functionality. I don't think anyone will disagree with you. I am waiting for someone to provide the evidence that we gain stability and faster convergence by putting all this into BGP.... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyd3hqarNKXTPFCVEQLQFwCg1iXXmaxfT5Sry3zCFT9FwtuaVRQAoOmG GLgCxNBlxYx+CWMiK+uzEDX/ =M14R -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 03:49:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22932 for ; Wed, 30 Jul 2003 03:49:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlhS-00070p-9P for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:48:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U7mgCS026938 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:48:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlgn-0006ul-HC; Wed, 30 Jul 2003 03:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlfv-0006s4-RS for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22826 for ; Wed, 30 Jul 2003 03:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlfs-0005m2-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:47:04 -0400 Received: from web42003.mail.yahoo.com ([66.218.93.171]) by ietf-mx with smtp (Exim 4.12) id 19hlfs-0005lR-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:47:04 -0400 Message-ID: <20030730074635.19021.qmail@web42003.mail.yahoo.com> Received: from [203.200.20.226] by web42003.mail.yahoo.com via HTTP; Wed, 30 Jul 2003 03:46:35 EDT From: Tulip Rasputin Subject: Errata To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 03:46:35 -0400 (EDT) All, > I am sure you must have looked into the BGP implementat > ion for the vendor you work for. Dont you > parse for the multicast routes in the same file as you do for the > IPv4 unicast address family. Are > you sure you didnt tough the functions which parse the its "touch" and not "tough" :-) Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 03:55:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23063 for ; Wed, 30 Jul 2003 03:55:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlnH-0007GV-4N for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:54:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U7shjw027922 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:54:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlmb-00079t-19; Wed, 30 Jul 2003 03:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlm5-00078d-TP for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:53:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23005 for ; Wed, 30 Jul 2003 03:53:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlm2-0005o3-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:53:26 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hlm1-0005o0-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:53:25 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U7rTFJ006641; Wed, 30 Jul 2003 09:53:30 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Tulip Rasputin , routing-discussion@ietf.org To: raszuk@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <3F277365.B42998C5@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:53:22 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> And why is it that we only see some of the vendors in favor of >> bundling BGP with everything. Is >> there any ISP out there which feels the same? What is it that they >> feel is right? Would they want >> to muck around with BGP? > > Each operator I have talked to clearly indicated huge resistance to > undertake operational pain of rolling new intra/inter domain > "non-routing" information distribution protocol. There certainly was a large number of very large providers at the meeting that express differing opinions. >>>> Given that the underlying desire seems to be that SPs that are not >>>> interest in a given service would prefer not to have that >>>> functionality added to BGP (in fact many people mentioned that they >>>> wanted not to have the functionality in the router software, period) >> >> A number of people said they at least did want this code enabled if >> they where not using the service. > > This stament is comming back a lot. What does it mean "code enabled" ? A problem with data for one "feature" distributed will effect the session/processing of data for another feature. > Maybe someone would provide an example how let's say adding multicast > distribution to BGP impacts IPv4 unicast address family ? If one does > not need to use it - just don't configure it. I don't like to take examples from a single vendor, as over time they tend to be equally bad, but I have had enough experience of multicast problems effecting BGP routes on my Ciscos. If you go and dig in the bug tracker there should be some 12-18 months back. Unfortunately I no longer have access to CCO. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyd5dqarNKXTPFCVEQLFewCeJH6h0YuUREkLeGZL29iz4cmtc18AoPZ7 yyQef9+4mDm5hwLcHdgTINSP =zPQI -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 03:59:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22151 for ; Wed, 30 Jul 2003 03:14:16 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hl8u-0005Qg-Kv; Wed, 30 Jul 2003 03:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hl8k-0005Pp-N4 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:12:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22124 for ; Wed, 30 Jul 2003 03:12:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hl8i-0005bM-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:12:48 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hl8h-0005bJ-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:12:47 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U7CpFJ006627; Wed, 30 Jul 2003 09:12:51 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alex Zinin , routing-discussion@ietf.org To: raszuk@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <3F26FAE6.EA0D6868@cisco.com> Message-Id: <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:12:46 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > While watching this debate I have a feeling that the problem here is as > old as civilization ;-). While watching this debate I realize that most people posting are router vendors...:-) > So as it was said by others a number of times this discussion is just > about software eng - nothing else. From the SP POV this is about operational stability. Not about software engineering. > A few providers said that they would like to run only a number of > features they use ... AFAIK that should be doable already in most of > the > shipping implementations. I disagree. In the products from the two vendors, I can't today decide what features to use or not AFAIK. I can decide what information to process or not. But that is not the same thing. > Also it seems to be some interesting assumption that if we separate so > called "non-routing" info from BGP the entire system would behave much > better. I would like to see what facts make anyone feel/think that way > ;) What are the facts that we need to put everything into BGP? And where do we stop? Why not make the NLRI field XML code? Javascript? Operational experience tells me that the easier, simpler and less information there is - the less the chance of a problem. It's as simple as that. > Last lightly assume we go down the path and invent, implement & deploy > a > new protocol instance/port would that mean that we will from such a > moment start indefinitely putting all new things on it or will this > topic be comming back every now and then and each time a "new protocol" > or "new port number" will be recommended ??? As clearly definitions of > routing and non routing, critical and non critical information is > different depending who get's to reply my suggestion for routing > directorate would be to have a BGP port number progressing with the > calendar years :) Now we have 179, in 2004 let's add 180, 2006 - 181 > etc > ... :):). Just one page draft. I don't see a problem (actually on the contrary) with separating reachability information, signaling, etc. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPydv8aarNKXTPFCVEQLcrwCgmbC2SRtlmSQc9MAXcy5BrwDJzgwAn2Uu yu/AckoFuGA/+XWWQe7pt5O9 =9OAs -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 04:29:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22759 for ; Wed, 30 Jul 2003 03:44:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlcd-0006ew-F0 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:43:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U7hhwb025592 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:43:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlbx-0006Yx-1L; Wed, 30 Jul 2003 03:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlbO-0006YP-Pj for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:42:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22712 for ; Wed, 30 Jul 2003 03:42:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlbL-0005jw-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:42:23 -0400 Received: from web42002.mail.yahoo.com ([66.218.93.170]) by ietf-mx with smtp (Exim 4.12) id 19hlbK-0005jV-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:42:22 -0400 Message-ID: <20030730074154.26246.qmail@web42002.mail.yahoo.com> Received: from [203.200.20.226] by web42002.mail.yahoo.com via HTTP; Wed, 30 Jul 2003 03:41:54 EDT From: Tulip Rasputin Subject: Re: Open Routing Area meeting in Vienna To: raszuk@cisco.com, Kurt Erik Lindqvist Cc: routing-discussion@ietf.org In-Reply-To: <3F277365.B42998C5@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 03:41:54 -0400 (EDT) Robert, > Each operator I have talked to clearly indicated huge resistance to > undertake operational pain of rolling new intra/inter domain > "non-routing" information distribution protocol. If this is the only *motivation* then i am sure we need to think more before proceeding further. It is really an operational pain to configure geographically separated routers. Why not, have BGP automatically send configurations to all such routers by some sort of "automatic flooding"! > Maybe someone would provide an example how let's say adding multicast > distribution to BGP impacts IPv4 unicast address family ? If one does > not need to use it - just don't configure it. Almost all protocol > extensions are knobed - thay are NOT enabled by default carrying vacum. > Most vendors I am aware about either already or soon have the option of > per AFI/SAFI specific BGP sub-process clearly separating running or not > new functionality. I am sure you must have looked into the BGP implementation for the vendor you work for. Dont you parse for the multicast routes in the same file as you do for the IPv4 unicast address family. Are you sure you didnt tough the functions which parse the IPv4 routes when you introduced multicast support? What i mean to say is that even if you do turn off one particular feature you do put in all the additional code in your main working code - which in turn definitely complicates the stuff and makes it more prone to bugs/mishaps/surprises (depending upon which side of the fence you are on!) By turning off an option you dont remove the code dynamically from the binary image .. Its still there tightly coupled with remaining code! Dynamically removing the code has atleast not been done till the time of my writing this email!! :-) Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 04:34:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22931 for ; Wed, 30 Jul 2003 03:49:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlgn-0006ul-HC; Wed, 30 Jul 2003 03:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlfv-0006s4-RS for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:47:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22826 for ; Wed, 30 Jul 2003 03:47:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlfs-0005m2-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:47:04 -0400 Received: from web42003.mail.yahoo.com ([66.218.93.171]) by ietf-mx with smtp (Exim 4.12) id 19hlfs-0005lR-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:47:04 -0400 Message-ID: <20030730074635.19021.qmail@web42003.mail.yahoo.com> Received: from [203.200.20.226] by web42003.mail.yahoo.com via HTTP; Wed, 30 Jul 2003 03:46:35 EDT From: Tulip Rasputin Subject: Errata To: routing-discussion@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 03:46:35 -0400 (EDT) All, > I am sure you must have looked into the BGP implementat > ion for the vendor you work for. Dont you > parse for the multicast routes in the same file as you do for the > IPv4 unicast address family. Are > you sure you didnt tough the functions which parse the its "touch" and not "tough" :-) Rasputin ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 04:34:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22848 for ; Wed, 30 Jul 2003 03:47:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlfa-0006q3-2d for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:46:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6U7kjt0026283 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 03:46:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlet-0006kJ-7R; Wed, 30 Jul 2003 03:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hle1-0006jJ-5k for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:45:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22793 for ; Wed, 30 Jul 2003 03:45:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hldx-0005lE-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:45:05 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hldx-0005lB-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:45:05 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U7jDFJ006637; Wed, 30 Jul 2003 09:45:13 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Alex Zinin , routing-discussion@ietf.org To: Pedro Roque Marques From: Kurt Erik Lindqvist In-Reply-To: <200307300559.h6U5xE470168@roque-bsd.juniper.net> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:45:08 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > This is perhaps a fundamental difference in perception that we have. > > I don't see the existence of an "Internet" infrastructure as separate > from the telecomunications industry. Although the later provides > several services to its customers including access to a public network > it does so on an infrastruture which is shared in variable degrees. > > For instance, the transmission infrastruture (wdm, sonet, tdm) tends > to be the same for all services the carrier provides. But you do not use SS7 to signal the paths in SONET/SDH, or the OSI information from the ADMs to route the WDM channels. > In an increasing > number of cases, network nodes such as routers are also shared > resources, either by providing transport to several applications or by > terminating them. Yes. But the routers in this case are the same as the ADMs. And those do not signal anything else than the reachability. > I confess that i'm not quite sure what your goal is... my assumption > is that you are concerned w/ the availiability of internet service, > which depends on several factors including the stability of router > software. Among other things. As Randy said, there i a lot of research that also points to the protocol itself. > While the latter is certainly a cause for concern, i would suggest > that you think of this equipment not as "Internet" infrastructure but > as equipment which is bought and operated by a telecomunications > company. I fail to understand this comment? > cause of the problem. As such, "critical" needs to be defined from the > point of view of a service provider. From my experience, when a fault happens, the time it takes to recover is many times mostly due to the protocol. > Personally, i believe that this issue is being completly blown out of > proportion. I've not seen any evidence to suggest that adding VPN > services, as we are discussing, has higher impact in routing software > stability than to add any other type of functionality. I don't think anyone will disagree with you. I am waiting for someone to provide the evidence that we gain stability and faster convergence by putting all this into BGP.... - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyd3hqarNKXTPFCVEQLQFwCg1iXXmaxfT5Sry3zCFT9FwtuaVRQAoOmG GLgCxNBlxYx+CWMiK+uzEDX/ =M14R -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 04:44:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23062 for ; Wed, 30 Jul 2003 03:55:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlmb-00079t-19; Wed, 30 Jul 2003 03:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hlm5-00078d-TP for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 03:53:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23005 for ; Wed, 30 Jul 2003 03:53:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hlm2-0005o3-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:53:26 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hlm1-0005o0-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 03:53:25 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6U7rTFJ006641; Wed, 30 Jul 2003 09:53:30 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Tulip Rasputin , routing-discussion@ietf.org To: raszuk@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <3F277365.B42998C5@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:53:22 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> And why is it that we only see some of the vendors in favor of >> bundling BGP with everything. Is >> there any ISP out there which feels the same? What is it that they >> feel is right? Would they want >> to muck around with BGP? > > Each operator I have talked to clearly indicated huge resistance to > undertake operational pain of rolling new intra/inter domain > "non-routing" information distribution protocol. There certainly was a large number of very large providers at the meeting that express differing opinions. >>>> Given that the underlying desire seems to be that SPs that are not >>>> interest in a given service would prefer not to have that >>>> functionality added to BGP (in fact many people mentioned that they >>>> wanted not to have the functionality in the router software, period) >> >> A number of people said they at least did want this code enabled if >> they where not using the service. > > This stament is comming back a lot. What does it mean "code enabled" ? A problem with data for one "feature" distributed will effect the session/processing of data for another feature. > Maybe someone would provide an example how let's say adding multicast > distribution to BGP impacts IPv4 unicast address family ? If one does > not need to use it - just don't configure it. I don't like to take examples from a single vendor, as over time they tend to be equally bad, but I have had enough experience of multicast problems effecting BGP routes on my Ciscos. If you go and dig in the bug tracker there should be some 12-18 months back. Unfortunately I no longer have access to CCO. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyd5dqarNKXTPFCVEQLFewCeJH6h0YuUREkLeGZL29iz4cmtc18AoPZ7 yyQef9+4mDm5hwLcHdgTINSP =zPQI -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 10:25:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03129 for ; Wed, 30 Jul 2003 10:25:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrs1-0002GZ-Fb; Wed, 30 Jul 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrrg-0002Fu-8n for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 10:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03049 for ; Wed, 30 Jul 2003 10:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrre-0000Us-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 10:23:38 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19hrrd-0000Up-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 10:23:37 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hrrb-0004QF-K4; Wed, 30 Jul 2003 07:23:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kurt Erik Lindqvist Cc: raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F26FAE6.EA0D6868@cisco.com> <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 07:23:34 -0700 Content-Transfer-Encoding: 7bit > While watching this debate I realize that most people posting are > router vendors...:-) bingo! and they seem to be all for putting it all in the "it's running perfectly now" bgp. except people are getting phd theses by showing how strangely it is actually running, and this should scare the hell out of us (not because it's a clear disaster, but because we don't know). and the operators seem to be a bit more hesitant with what hits the soft underbelly of their critical infrastructure. and thanks, i get to say what is critical to me. it's pretty strange to keep watching the customer (yes, try saying that 'customer' word a few times, and then maybe try 'user' a few times) being told that their concerns are invalid. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 10:25:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03141 for ; Wed, 30 Jul 2003 10:25:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrt4-0002PI-F0 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 10:25:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UEP6Dp009181 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 10:25:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrs1-0002GZ-Fb; Wed, 30 Jul 2003 10:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hrrg-0002Fu-8n for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 10:23:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03049 for ; Wed, 30 Jul 2003 10:23:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hrre-0000Us-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 10:23:38 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19hrrd-0000Up-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 10:23:37 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hrrb-0004QF-K4; Wed, 30 Jul 2003 07:23:35 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Kurt Erik Lindqvist Cc: raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F26FAE6.EA0D6868@cisco.com> <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 07:23:34 -0700 Content-Transfer-Encoding: 7bit > While watching this debate I realize that most people posting are > router vendors...:-) bingo! and they seem to be all for putting it all in the "it's running perfectly now" bgp. except people are getting phd theses by showing how strangely it is actually running, and this should scare the hell out of us (not because it's a clear disaster, but because we don't know). and the operators seem to be a bit more hesitant with what hits the soft underbelly of their critical infrastructure. and thanks, i get to say what is critical to me. it's pretty strange to keep watching the customer (yes, try saying that 'customer' word a few times, and then maybe try 'user' a few times) being told that their concerns are invalid. randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 12:33:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07275 for ; Wed, 30 Jul 2003 12:33:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htrt-0007xN-8R; Wed, 30 Jul 2003 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htr7-0007w7-5Q for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 12:31:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07219 for ; Wed, 30 Jul 2003 12:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htr5-0001be-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:31:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19htr5-0001ba-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:31:11 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2003 09:33:33 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6UGUc7F011662; Wed, 30 Jul 2003 09:30:38 -0700 (PDT) Message-Id: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> To: Randy Bush cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 07:23:34 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 12:30:37 -0400 Randy> it's pretty strange to keep watching the customer (yes, try saying Randy> that 'customer' word a few times, and then maybe try 'user' a few Randy> times) being told that their concerns are invalid. One advantage of working for a vendor is that you get to talk to lots of customers, not just the ones that are politically well connected in the IETF. And I can tell you that the idea of extending BGP ad infinitum is enormously popular with the customers, MUCH more popular than it deserves to be; I'm often in the position of trying to convince a customer that BGP should not be extended for some particular function. Randy> well, so much for bgp, as any one researcher who actually looks at Randy> how the protocol performs on the net will tell you. Sure, BGP is the worst possible protocol, except for all the others. If we can come up with a protocol that is clearly better, let's definitely use it instead. In the meantime, however, ... Alex> I'd like to take this further and say that it is perfectly appropriate Alex> for us to keep the engineering aspects in mind and make the right Alex> choices at the protocol level. This is the i_E_tf. Saying "ouch! this Alex> is engineering, we can't be thinking about this" would be wrong. Sure the IETF has to be concerned with engineering. But the software engineering of a particular box is the responsibility of the box builders, and not a matter for IETF consensus. Alex> even with a separate protocol, there is some risk that a vendor will Alex> do a poor job, but it's much less likely that the same running Alex> environment, internal system infrastructure will be used. If we had a second protocol which is "like BGP", probably there would be a lot of reuse of modules for table maintenance and stuff. Of course, some of these modules might need to be generalized, which would then impact BGP. I think this is the kind of stuff that Pedro has been talking about. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 12:35:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07406 for ; Wed, 30 Jul 2003 12:35:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19http-00088i-Ub; Wed, 30 Jul 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htti-00087x-U2 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 12:33:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07318 for ; Wed, 30 Jul 2003 12:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htth-0001dH-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:33:53 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19httg-0001dE-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:33:52 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19htte-0007l6-TF; Wed, 30 Jul 2003 09:33:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:33:50 -0700 Content-Transfer-Encoding: 7bit > One advantage of working for a vendor is that you get to talk to > lots of customers, not just the ones that are politically well > connected in the IETF. And I can tell you that the idea of > extending BGP ad infinitum is enormously popular with the > customers one of the advantages of working for an operator is that you get to talk to lots of vendors, not just the ones that are politically well connected in the ietf. and i can tell you that the idea of extending bgp ad infinitum horrifies most of them. can we now finish representing hidden others than ourselves, expecially given that the ietf is supposedly a forum of individual experts? randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 12:35:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07407 for ; Wed, 30 Jul 2003 12:35:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htuQ-0008Ji-CN for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 12:34:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGYcdj031922 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 12:34:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19http-00088i-Ub; Wed, 30 Jul 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htti-00087x-U2 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 12:33:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07318 for ; Wed, 30 Jul 2003 12:33:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htth-0001dH-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:33:53 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19httg-0001dE-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:33:52 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19htte-0007l6-TF; Wed, 30 Jul 2003 09:33:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:33:50 -0700 Content-Transfer-Encoding: 7bit > One advantage of working for a vendor is that you get to talk to > lots of customers, not just the ones that are politically well > connected in the IETF. And I can tell you that the idea of > extending BGP ad infinitum is enormously popular with the > customers one of the advantages of working for an operator is that you get to talk to lots of vendors, not just the ones that are politically well connected in the ietf. and i can tell you that the idea of extending bgp ad infinitum horrifies most of them. can we now finish representing hidden others than ourselves, expecially given that the ietf is supposedly a forum of individual experts? randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 13:07:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08404 for ; Wed, 30 Jul 2003 13:07:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huOn-0001IH-Bq; Wed, 30 Jul 2003 13:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huOf-0001HI-W0 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:05:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08314 for ; Wed, 30 Jul 2003 13:05:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huOe-0001pG-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:05:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19huOc-0001p7-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:05:51 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6UH5HXw007727; Wed, 30 Jul 2003 13:05:17 -0400 (EDT) Message-Id: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> To: Randy Bush cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 09:33:50 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:05:16 -0400 Randy> can we now finish representing hidden others than ourselves, Randy> especially given that the ietf is supposedly a forum of individual Randy> experts? Seems like a fair enough deal: you stop pretending to speak for all service providers, and I won't pretend to speak for all vendors ;-) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 13:09:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08542 for ; Wed, 30 Jul 2003 13:09:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huQj-0001eq-En; Wed, 30 Jul 2003 13:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huQ9-0001YK-Kg for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:07:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08448 for ; Wed, 30 Jul 2003 13:07:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huQ7-0001pq-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:07:23 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19huQ7-0001pn-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:07:23 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19huQ5-0008eR-Rj; Wed, 30 Jul 2003 10:07:21 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 10:07:21 -0700 Content-Transfer-Encoding: 7bit > you stop pretending to speak for all service providers, and I won't > pretend to speak for all vendors ;-) no problem, when you actually listen to all the operators actually in the room _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 13:17:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08788 for ; Wed, 30 Jul 2003 13:17:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huZC-00023y-6I for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:16:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHGkBS007925 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:16:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huYU-0001y3-JN; Wed, 30 Jul 2003 13:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huYB-0001xG-RF for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:15:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08732 for ; Wed, 30 Jul 2003 13:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huY9-0001uB-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:15:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19huY8-0001u0-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:15:41 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 10:15:07 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6UHF3LH002137; Wed, 30 Jul 2003 10:15:04 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA06617; Wed, 30 Jul 2003 13:15:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: <3F26FAE6.EA0D6868@cisco.com> <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> To: Randy Bush From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:14:58 -0400 At 7:23 AM -0700 7/30/03, Randy Bush wrote: >and they seem to be all for putting it all in the "it's running >perfectly now" bgp. except people are getting phd theses by >showing how strangely it is actually running, and this should scare >the hell out of us (not because it's a clear disaster, but because >we don't know). Well, rather than be scared and run around in terror, I would prefer it if we'd remain calm and look at said research, learn something from it and maybe even (gasp) work to fix the problems identified. We don't seem to be doing any of that in this conversation. If anything, we're distracting ourselves. Is there in fact research that "people are getting phd theses" for that indicates that "overloading" BGP is making the routing infrastructure "run strangely"? I'm not aware of it, and I think I'm reasonably conversant with the literature. The research I'm aware of tends to have identified what I'd call day-one bugs (or, ahem, limitations) in the protocol. In particular I'm aware of a fair body of research broadly related to policy (and why it's hairy), BGP's path-exploration behavior (ditto) and flap dampening (ditto ditto). None of these relate to "overloading". I'd be happy to be corrected with relevant references (really). But lacking such correction, it seems to me that the research you allude to isn't germane to the present conversation. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 13:17:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08789 for ; Wed, 30 Jul 2003 13:17:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huYU-0001y3-JN; Wed, 30 Jul 2003 13:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huYB-0001xG-RF for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:15:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08732 for ; Wed, 30 Jul 2003 13:15:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huY9-0001uB-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:15:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19huY8-0001u0-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:15:41 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 10:15:07 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6UHF3LH002137; Wed, 30 Jul 2003 10:15:04 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-214-208.cisco.com [64.101.214.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id NAA06617; Wed, 30 Jul 2003 13:15:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: <3F26FAE6.EA0D6868@cisco.com> <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> To: Randy Bush From: "John G. Scudder" Subject: Re: Open Routing Area meeting in Vienna Cc: routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:14:58 -0400 At 7:23 AM -0700 7/30/03, Randy Bush wrote: >and they seem to be all for putting it all in the "it's running >perfectly now" bgp. except people are getting phd theses by >showing how strangely it is actually running, and this should scare >the hell out of us (not because it's a clear disaster, but because >we don't know). Well, rather than be scared and run around in terror, I would prefer it if we'd remain calm and look at said research, learn something from it and maybe even (gasp) work to fix the problems identified. We don't seem to be doing any of that in this conversation. If anything, we're distracting ourselves. Is there in fact research that "people are getting phd theses" for that indicates that "overloading" BGP is making the routing infrastructure "run strangely"? I'm not aware of it, and I think I'm reasonably conversant with the literature. The research I'm aware of tends to have identified what I'd call day-one bugs (or, ahem, limitations) in the protocol. In particular I'm aware of a fair body of research broadly related to policy (and why it's hairy), BGP's path-exploration behavior (ditto) and flap dampening (ditto ditto). None of these relate to "overloading". I'd be happy to be corrected with relevant references (really). But lacking such correction, it seems to me that the research you allude to isn't germane to the present conversation. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 13:19:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07274 for ; Wed, 30 Jul 2003 12:33:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htsc-00082a-9k for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 12:32:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGWkAF030908 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 12:32:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htrt-0007xN-8R; Wed, 30 Jul 2003 12:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htr7-0007w7-5Q for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 12:31:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07219 for ; Wed, 30 Jul 2003 12:31:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htr5-0001be-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:31:11 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19htr5-0001ba-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:31:11 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 30 Jul 2003 09:33:33 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6UGUc7F011662; Wed, 30 Jul 2003 09:30:38 -0700 (PDT) Message-Id: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> To: Randy Bush cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 07:23:34 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 12:30:37 -0400 Randy> it's pretty strange to keep watching the customer (yes, try saying Randy> that 'customer' word a few times, and then maybe try 'user' a few Randy> times) being told that their concerns are invalid. One advantage of working for a vendor is that you get to talk to lots of customers, not just the ones that are politically well connected in the IETF. And I can tell you that the idea of extending BGP ad infinitum is enormously popular with the customers, MUCH more popular than it deserves to be; I'm often in the position of trying to convince a customer that BGP should not be extended for some particular function. Randy> well, so much for bgp, as any one researcher who actually looks at Randy> how the protocol performs on the net will tell you. Sure, BGP is the worst possible protocol, except for all the others. If we can come up with a protocol that is clearly better, let's definitely use it instead. In the meantime, however, ... Alex> I'd like to take this further and say that it is perfectly appropriate Alex> for us to keep the engineering aspects in mind and make the right Alex> choices at the protocol level. This is the i_E_tf. Saying "ouch! this Alex> is engineering, we can't be thinking about this" would be wrong. Sure the IETF has to be concerned with engineering. But the software engineering of a particular box is the responsibility of the box builders, and not a matter for IETF consensus. Alex> even with a separate protocol, there is some risk that a vendor will Alex> do a poor job, but it's much less likely that the same running Alex> environment, internal system infrastructure will be used. If we had a second protocol which is "like BGP", probably there would be a lot of reuse of modules for table maintenance and stuff. Of course, some of these modules might need to be generalized, which would then impact BGP. I think this is the kind of stuff that Pedro has been talking about. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 13:24:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09300 for ; Wed, 30 Jul 2003 13:24:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hufF-0002dy-Gw; Wed, 30 Jul 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huey-0002dK-Oz for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:22:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09239 for ; Wed, 30 Jul 2003 13:22:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huew-0001zC-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:22:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19huev-0001ym-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:22:41 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 10:22:10 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6UHHIuG021538; Wed, 30 Jul 2003 10:17:29 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU18279; Wed, 30 Jul 2003 10:12:13 -0700 (PDT) Message-ID: <3F27FD98.6B82D152@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Eric Rosen , Kurt Erik Lindqvist , Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 19:17:12 +0200 Content-Transfer-Encoding: 7bit The only problem with this is that most of those operators who were in the room are running and using those ugly non pure ipv4 related bgp extensions in their production networks to sell more services and to make extra money. Furthen most of them just wants their features in the code tomorrow and not anybody's elses. Cheers, R. > Randy Bush wrote: > > > you stop pretending to speak for all service providers, and I won't > > pretend to speak for all vendors ;-) > > no problem, when you actually listen to all the operators actually > in the room > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 13:42:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09988 for ; Wed, 30 Jul 2003 13:42:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huwg-0003bW-54; Wed, 30 Jul 2003 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huvz-0003a8-CV for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:40:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09884 for ; Wed, 30 Jul 2003 13:40:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huvx-00028W-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:40:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19huvw-00028T-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:40:16 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19huvu-0009M1-B6; Wed, 30 Jul 2003 17:40:14 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <102561546891.20030730103929@psg.com> To: Robert Raszuk CC: Randy Bush , Eric Rosen , Kurt Erik Lindqvist , Subject: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: <3F27FD98.6B82D152@cisco.com> References: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> <3F27FD98.6B82D152@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 10:39:29 -0700 Content-Transfer-Encoding: 7bit Folks- I suggest we once and for all agree that each of us speaks as an individual. The chest beating matches like "I've talked to so many guys and they think..., how many have you talked to?" are NOT going to be productive. The topic is _extremely_ important and we want to encourage an open discussion here. If you believe someone thinks one way or the other--please ask that person to speak up on the list and explain, don't "represent" their opinion. Please, let's also NOT second-guess why people think one way or the other, let's NOT try to put reasons behind THEIR words, let THEM do that. Let's please get back to the very important topic at hand. Thanks. -- Alex http://www.psg.com/~zinin/ Wednesday, July 30, 2003, 10:17:12 AM, Robert Raszuk wrote: > The only problem with this is that most of those operators who were in > the room are running and using those ugly non pure ipv4 related bgp > extensions in their production networks to sell more services and to > make extra money. > Furthen most of them just wants their features in the code tomorrow and > not anybody's elses. > Cheers, > R. >> Randy Bush wrote: >> >> > you stop pretending to speak for all service providers, and I won't >> > pretend to speak for all vendors ;-) >> >> no problem, when you actually listen to all the operators actually >> in the room >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 13:42:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09991 for ; Wed, 30 Jul 2003 13:42:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huxT-0003gL-KZ for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:41:51 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHfprs014148 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:41:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huwg-0003bW-54; Wed, 30 Jul 2003 13:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huvz-0003a8-CV for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:40:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09884 for ; Wed, 30 Jul 2003 13:40:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huvx-00028W-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:40:17 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19huvw-00028T-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:40:16 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19huvu-0009M1-B6; Wed, 30 Jul 2003 17:40:14 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <102561546891.20030730103929@psg.com> To: Robert Raszuk CC: Randy Bush , Eric Rosen , Kurt Erik Lindqvist , Subject: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] In-Reply-To: <3F27FD98.6B82D152@cisco.com> References: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> <3F27FD98.6B82D152@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 10:39:29 -0700 Content-Transfer-Encoding: 7bit Folks- I suggest we once and for all agree that each of us speaks as an individual. The chest beating matches like "I've talked to so many guys and they think..., how many have you talked to?" are NOT going to be productive. The topic is _extremely_ important and we want to encourage an open discussion here. If you believe someone thinks one way or the other--please ask that person to speak up on the list and explain, don't "represent" their opinion. Please, let's also NOT second-guess why people think one way or the other, let's NOT try to put reasons behind THEIR words, let THEM do that. Let's please get back to the very important topic at hand. Thanks. -- Alex http://www.psg.com/~zinin/ Wednesday, July 30, 2003, 10:17:12 AM, Robert Raszuk wrote: > The only problem with this is that most of those operators who were in > the room are running and using those ugly non pure ipv4 related bgp > extensions in their production networks to sell more services and to > make extra money. > Furthen most of them just wants their features in the code tomorrow and > not anybody's elses. > Cheers, > R. >> Randy Bush wrote: >> >> > you stop pretending to speak for all service providers, and I won't >> > pretend to speak for all vendors ;-) >> >> no problem, when you actually listen to all the operators actually >> in the room >> >> _______________________________________________ >> routing-discussion mailing list >> routing-discussion@ietf.org >> https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 13:47:07 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10182 for ; Wed, 30 Jul 2003 13:47:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv1V-0003uW-N8; Wed, 30 Jul 2003 13:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv0m-0003td-A3 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:45:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10144 for ; Wed, 30 Jul 2003 13:45:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hv0k-0002Br-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:45:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hv0j-0002Bo-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:45:13 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 10:44:43 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6UHieXw013614; Wed, 30 Jul 2003 13:44:40 -0400 (EDT) Message-Id: <200307301744.h6UHieXw013614@rtp-core-1.cisco.com> To: Randy Bush cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 10:07:21 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:44:40 -0400 Randy> no problem, when you actually listen to all the operators actually in Randy> the room As individual technical experts, we all need to evaluate and critique the technical arguments using our complete range of knowledge and experience. The correctness of a technical position has nothing to do with who happens to be in some room at some particular time. In the case at hand, no one would deny that providers desire to have operational stability. Providers also desire other things, such as delivery of new services in a timely manner. What is at issue is the best technical approach for achieving these goals. This is a legitimate subject for discussion, and the "operators actually in the room" are not the only people who may have something useful to say. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 13:52:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10546 for ; Wed, 30 Jul 2003 13:52:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv6M-0004Ny-6J; Wed, 30 Jul 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv6J-0004Ng-9z for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:50:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10522 for ; Wed, 30 Jul 2003 13:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hv6F-0002HC-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:50:55 -0400 Received: from dhcp4.se.kurtis.pp.se ([195.43.225.73] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hv6E-0002H9-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:50:54 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6UHoYFJ007091; Wed, 30 Jul 2003 19:50:37 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org To: erosen@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> Message-Id: <4A9296C2-C2B6-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 19:50:22 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Randy> well, so much for bgp, as any one researcher who actually > looks at > Randy> how the protocol performs on the net will tell you. > > Sure, BGP is the worst possible protocol, except for all the others. > If we > can come up with a protocol that is clearly better, let's definitely > use it > instead. In the meantime, however, ... I think one of the problems with BGP is that it has lured into this "as there is nothing better, let's put it all in there". To be honest I think that the reason that you are seeing customers being perfectly happy to put various features into BGP is not that they don't see a problem with it. They don't think there is an alternative. If we go to the next Nanog/RIPE/APNIC/SANOG/NORDNOG etc and try and get a feeling if people would be happy to add a new protocol, I think you would have an interesting discussion. As I said in Vienna, I think a large part of the problem is that we are getting complacent (I hope that is the right word; read lazy). > Alex> I'd like to take this further and say that it is perfectly > appropriate > Alex> for us to keep the engineering aspects in mind and make the > right > Alex> choices at the protocol level. This is the i_E_tf. Saying > "ouch! this > Alex> is engineering, we can't be thinking about this" would be wrong. > > Sure the IETF has to be concerned with engineering. But the > software > engineering of a particular box is the responsibility of the box > builders, > and not a matter for IETF consensus. I would say that the problem we are having now is the opposite. In order to solve a software problem, people are trying to add things to a protocol. > Alex> even with a separate protocol, there is some risk that a > vendor will > Alex> do a poor job, but it's much less likely that the same > running > Alex> environment, internal system infrastructure will be used. > > If we had a second protocol which is "like BGP", probably there > would be a > lot of reuse of modules for table maintenance and stuff. Of course, > some of > these modules might need to be generalized, which would then impact > BGP. I > think this is the kind of stuff that Pedro has been talking about. This is a theoretical statement until we know what that protocol or the requirement for it would be. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPygFZqarNKXTPFCVEQLl3wCg/rXq3ulJFCUSeV71fwyHdmkxHBQAoJQh JSUoCJt8dmJonuyj0ZveIe2r =LosQ -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 13:54:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08543 for ; Wed, 30 Jul 2003 13:09:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huRJ-0001kE-6A for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:08:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UH8bCf006676 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:08:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huQj-0001eq-En; Wed, 30 Jul 2003 13:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huQ9-0001YK-Kg for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:07:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08448 for ; Wed, 30 Jul 2003 13:07:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huQ7-0001pq-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:07:23 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19huQ7-0001pn-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:07:23 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19huQ5-0008eR-Rj; Wed, 30 Jul 2003 10:07:21 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Eric Rosen Cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 10:07:21 -0700 Content-Transfer-Encoding: 7bit > you stop pretending to speak for all service providers, and I won't > pretend to speak for all vendors ;-) no problem, when you actually listen to all the operators actually in the room _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 13:54:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08405 for ; Wed, 30 Jul 2003 13:07:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huPP-0001MI-Mh for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:06:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UH6d2B005194 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:06:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huOn-0001IH-Bq; Wed, 30 Jul 2003 13:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huOf-0001HI-W0 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:05:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08314 for ; Wed, 30 Jul 2003 13:05:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huOe-0001pG-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:05:52 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19huOc-0001p7-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:05:51 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6UH5HXw007727; Wed, 30 Jul 2003 13:05:17 -0400 (EDT) Message-Id: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> To: Randy Bush cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 09:33:50 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:05:16 -0400 Randy> can we now finish representing hidden others than ourselves, Randy> especially given that the ietf is supposedly a forum of individual Randy> experts? Seems like a fair enough deal: you stop pretending to speak for all service providers, and I won't pretend to speak for all vendors ;-) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 14:09:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09301 for ; Wed, 30 Jul 2003 13:24:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hufw-0002iQ-4J for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:23:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHNiGx010417 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:23:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hufF-0002dy-Gw; Wed, 30 Jul 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huey-0002dK-Oz for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:22:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09239 for ; Wed, 30 Jul 2003 13:22:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huew-0001zC-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:22:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19huev-0001ym-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:22:41 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 10:22:10 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6UHHIuG021538; Wed, 30 Jul 2003 10:17:29 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU18279; Wed, 30 Jul 2003 10:12:13 -0700 (PDT) Message-ID: <3F27FD98.6B82D152@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Randy Bush CC: Eric Rosen , Kurt Erik Lindqvist , Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 19:17:12 +0200 Content-Transfer-Encoding: 7bit The only problem with this is that most of those operators who were in the room are running and using those ugly non pure ipv4 related bgp extensions in their production networks to sell more services and to make extra money. Furthen most of them just wants their features in the code tomorrow and not anybody's elses. Cheers, R. > Randy Bush wrote: > > > you stop pretending to speak for all service providers, and I won't > > pretend to speak for all vendors ;-) > > no problem, when you actually listen to all the operators actually > in the room > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 14:19:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11575 for ; Wed, 30 Jul 2003 14:19:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvX9-0005fp-OB for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 14:18:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIIhQ4021808 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 14:18:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvWT-0005bj-M3; Wed, 30 Jul 2003 14:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvW1-0005bA-Sz for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 14:17:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11519 for ; Wed, 30 Jul 2003 14:17:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvVz-0002S7-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:17:31 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19hvVy-0002Rp-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:17:30 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 944C220298 for ; Wed, 30 Jul 2003 12:19:30 -0600 (MDT) Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: Content-Transfer-Encoding: 7bit In-Reply-To: <102561546891.20030730103929@psg.com> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 12:16:15 -0600 Content-Transfer-Encoding: 7bit I.e., hearsay is inadmissible.. It's always amused me how folks within the IETF tout it's existence as a body of individuals when it's convenient, yet those same folks explicitly ask for "operator input" on a consistent basis. It's always amusing as well to see folks attempt to solidify their own stance by suggesting that they're speaking on behalf of "lots of customers" or "all the big operators" on some important IETF topic. If it's that important [and the folks they're speaking on behalf of have email and half a clue!], you'd think they might be capable of speaking for themselves (I am aware of some legitimate exceptions). Then again, the extreme (and probably most entertaining) is when all of one vendor's "customers" come out of the woodwork and post the "we like this idea" to the WG mailing list, which is typically equally useless. The reality is that being an operator doesn't make you any more clueful then the next guy, nor does being a vendor or "developer" at said vendor. Heck, I know lots of vendor folks that used to be good operators, some of which actually maintained their operator mindset! I know vendors that have never been an operator that think more about operational issues than most operators... Of course, I see *service provider* requirements documents authored entirely by vendors with only more vendors in the acknowledgments section (i.e., no service providers or operators) and I've seen service provider folks listed as co-authors on documents they've neither read nor understand. My point: each person's arguments should carry weight based on the content, not on the author's employer... On the topic of RP overloading... There are [some] very real problems folks are attempting to address and given MP-BGP & BGP-CAP, BGP has been the easy answer. Heck, with IGP Capabilities being defined we'll be able to do more things even faster (although I'm kidding, be wary :-) Seriously though, maybe piggybacking on routing protocols is the right answer -- or is it? Most of the problems folks are trying to solve certainly seem very real. I was mesmerized by the sight of a "panel" at the Routing Area meeting, and as I suspected, only the same set of arguments were repeated to no avail. As several people have suggested, I think if folks have something more to say and are genuinely concerned with this topic, you should probably attempt to organize and document your thoughts in an Internet-Draft and post it accordingly, else it'll likely be lost in the obvious rumble of political and commercial agendas and egotistic chest thumping. I know of several folks that are engaged in this process now, hopefully, some good will come of it. -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 14:34:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10183 for ; Wed, 30 Jul 2003 13:47:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv29-0003zw-MC for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:46:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHkfDQ015336 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:46:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv1V-0003uW-N8; Wed, 30 Jul 2003 13:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv0m-0003td-A3 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:45:16 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10144 for ; Wed, 30 Jul 2003 13:45:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hv0k-0002Br-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:45:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hv0j-0002Bo-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:45:13 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 10:44:43 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6UHieXw013614; Wed, 30 Jul 2003 13:44:40 -0400 (EDT) Message-Id: <200307301744.h6UHieXw013614@rtp-core-1.cisco.com> To: Randy Bush cc: Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 10:07:21 -0700. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:44:40 -0400 Randy> no problem, when you actually listen to all the operators actually in Randy> the room As individual technical experts, we all need to evaluate and critique the technical arguments using our complete range of knowledge and experience. The correctness of a technical position has nothing to do with who happens to be in some room at some particular time. In the case at hand, no one would deny that providers desire to have operational stability. Providers also desire other things, such as delivery of new services in a timely manner. What is at issue is the best technical approach for achieving these goals. This is a legitimate subject for discussion, and the "operators actually in the room" are not the only people who may have something useful to say. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 14:39:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12354 for ; Wed, 30 Jul 2003 14:39:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvpq-0006rs-8A; Wed, 30 Jul 2003 14:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvpQ-0006lm-9V for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 14:37:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12307 for ; Wed, 30 Jul 2003 14:37:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvpN-0002dv-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:37:33 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19hvpM-0002ds-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:37:33 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hvpM-000B4x-PH; Wed, 30 Jul 2003 11:37:32 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "John G. Scudder" Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F26FAE6.EA0D6868@cisco.com> <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 11:37:32 -0700 Content-Transfer-Encoding: 7bit interesting question, john. how would one measure whether and how adding complexity to the protocol decreases reliability of the network (of course there is a large body of literature on software compexity, but that aside)? an academic research approach might be to measure the change in the software complexity over a long period of time and, in parallel, measure the reliability of the network. but we have not done so, and getting those measures would be difficult as would controlling for other variables. but, as operators, we do have some measures, e.g., how long it takes to get an image reliable enough to deploy after a new feature has been added. but it will be difficult to discuss this without getting into bashing. so, how would you suggest we measure this? randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 14:39:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12355 for ; Wed, 30 Jul 2003 14:39:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvqX-00071I-UT for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 14:38:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UIcjBi026969 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 14:38:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvpq-0006rs-8A; Wed, 30 Jul 2003 14:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvpQ-0006lm-9V for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 14:37:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12307 for ; Wed, 30 Jul 2003 14:37:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvpN-0002dv-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:37:33 -0400 Received: from ip166.usw12.rb1.bel.nwlink.com ([209.20.253.166] helo=ran.psg.com) by ietf-mx with esmtp (Exim 4.12) id 19hvpM-0002ds-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:37:33 -0400 Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.20) id 19hvpM-000B4x-PH; Wed, 30 Jul 2003 11:37:32 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "John G. Scudder" Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F26FAE6.EA0D6868@cisco.com> <387C08A4-C25D-11D7-958B-000393A638B2@kurtis.pp.se> Message-Id: Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 11:37:32 -0700 Content-Transfer-Encoding: 7bit interesting question, john. how would one measure whether and how adding complexity to the protocol decreases reliability of the network (of course there is a large body of literature on software compexity, but that aside)? an academic research approach might be to measure the change in the software complexity over a long period of time and, in parallel, measure the reliability of the network. but we have not done so, and getting those measures would be difficult as would controlling for other variables. but, as operators, we do have some measures, e.g., how long it takes to get an image reliable enough to deploy after a new feature has been added. but it will be difficult to discuss this without getting into bashing. so, how would you suggest we measure this? randy _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 14:39:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10547 for ; Wed, 30 Jul 2003 13:52:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv6w-0004SC-CH for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:51:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UHpcd8017111 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 13:51:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv6M-0004Ny-6J; Wed, 30 Jul 2003 13:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hv6J-0004Ng-9z for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:50:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10522 for ; Wed, 30 Jul 2003 13:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hv6F-0002HC-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:50:55 -0400 Received: from dhcp4.se.kurtis.pp.se ([195.43.225.73] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hv6E-0002H9-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:50:54 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6UHoYFJ007091; Wed, 30 Jul 2003 19:50:37 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org To: erosen@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> Message-Id: <4A9296C2-C2B6-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 19:50:22 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Randy> well, so much for bgp, as any one researcher who actually > looks at > Randy> how the protocol performs on the net will tell you. > > Sure, BGP is the worst possible protocol, except for all the others. > If we > can come up with a protocol that is clearly better, let's definitely > use it > instead. In the meantime, however, ... I think one of the problems with BGP is that it has lured into this "as there is nothing better, let's put it all in there". To be honest I think that the reason that you are seeing customers being perfectly happy to put various features into BGP is not that they don't see a problem with it. They don't think there is an alternative. If we go to the next Nanog/RIPE/APNIC/SANOG/NORDNOG etc and try and get a feeling if people would be happy to add a new protocol, I think you would have an interesting discussion. As I said in Vienna, I think a large part of the problem is that we are getting complacent (I hope that is the right word; read lazy). > Alex> I'd like to take this further and say that it is perfectly > appropriate > Alex> for us to keep the engineering aspects in mind and make the > right > Alex> choices at the protocol level. This is the i_E_tf. Saying > "ouch! this > Alex> is engineering, we can't be thinking about this" would be wrong. > > Sure the IETF has to be concerned with engineering. But the > software > engineering of a particular box is the responsibility of the box > builders, > and not a matter for IETF consensus. I would say that the problem we are having now is the opposite. In order to solve a software problem, people are trying to add things to a protocol. > Alex> even with a separate protocol, there is some risk that a > vendor will > Alex> do a poor job, but it's much less likely that the same > running > Alex> environment, internal system infrastructure will be used. > > If we had a second protocol which is "like BGP", probably there > would be a > lot of reuse of modules for table maintenance and stuff. Of course, > some of > these modules might need to be generalized, which would then impact > BGP. I > think this is the kind of stuff that Pedro has been talking about. This is a theoretical statement until we know what that protocol or the requirement for it would be. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPygFZqarNKXTPFCVEQLl3wCg/rXq3ulJFCUSeV71fwyHdmkxHBQAoJQh JSUoCJt8dmJonuyj0ZveIe2r =LosQ -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 15:01:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12894 for ; Wed, 30 Jul 2003 15:01:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwB7-0007gF-Po; Wed, 30 Jul 2003 15:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwAK-0007e6-6c for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 14:59:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12800 for ; Wed, 30 Jul 2003 14:59:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hwAH-0002kO-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:59:09 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19hwAG-0002k7-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:59:08 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6UIwapp000312; Wed, 30 Jul 2003 11:58:37 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AJU34234; Wed, 30 Jul 2003 11:53:33 -0700 (PDT) Message-Id: <5.2.0.9.2.20030730114414.05544cf8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Danny McPherson From: Fred Baker Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Cc: In-Reply-To: References: <102561546891.20030730103929@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 11:57:25 -0700 At 12:16 PM 7/30/2003 -0600, Danny McPherson wrote: >If it's that important [and the folks they're speaking >on behalf of have email and half a clue!], you'd think they might be capable >of speaking for themselves I agree with the sentiment, and at the same time I can tell you of a number of cases where they have chosen not to but rather to pull me (and presumably others) off in the hallways and say "please do in the IETF and we will use it". I get very frustrated with them for not speaking for themselves, but I also know that they often feel that there is some competitive information that they don't want to leak. They would rather use some sort of surrogate. So, for them, I would hope that this is a call to speak for themselves. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 15:04:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11574 for ; Wed, 30 Jul 2003 14:19:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvWT-0005bj-M3; Wed, 30 Jul 2003 14:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hvW1-0005bA-Sz for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 14:17:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11519 for ; Wed, 30 Jul 2003 14:17:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hvVz-0002S7-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:17:31 -0400 Received: from dog.tcb.net ([64.78.150.133]) by ietf-mx with esmtp (Exim 4.12) id 19hvVy-0002Rp-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:17:30 -0400 Received: from tcb.net (vdsl-151-118-3-177.dnvr.uswest.net [151.118.3.177]) by dog.tcb.net (Postfix) with ESMTP id 944C220298 for ; Wed, 30 Jul 2003 12:19:30 -0600 (MDT) Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Danny McPherson To: Content-Transfer-Encoding: 7bit In-Reply-To: <102561546891.20030730103929@psg.com> Message-Id: X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 12:16:15 -0600 Content-Transfer-Encoding: 7bit I.e., hearsay is inadmissible.. It's always amused me how folks within the IETF tout it's existence as a body of individuals when it's convenient, yet those same folks explicitly ask for "operator input" on a consistent basis. It's always amusing as well to see folks attempt to solidify their own stance by suggesting that they're speaking on behalf of "lots of customers" or "all the big operators" on some important IETF topic. If it's that important [and the folks they're speaking on behalf of have email and half a clue!], you'd think they might be capable of speaking for themselves (I am aware of some legitimate exceptions). Then again, the extreme (and probably most entertaining) is when all of one vendor's "customers" come out of the woodwork and post the "we like this idea" to the WG mailing list, which is typically equally useless. The reality is that being an operator doesn't make you any more clueful then the next guy, nor does being a vendor or "developer" at said vendor. Heck, I know lots of vendor folks that used to be good operators, some of which actually maintained their operator mindset! I know vendors that have never been an operator that think more about operational issues than most operators... Of course, I see *service provider* requirements documents authored entirely by vendors with only more vendors in the acknowledgments section (i.e., no service providers or operators) and I've seen service provider folks listed as co-authors on documents they've neither read nor understand. My point: each person's arguments should carry weight based on the content, not on the author's employer... On the topic of RP overloading... There are [some] very real problems folks are attempting to address and given MP-BGP & BGP-CAP, BGP has been the easy answer. Heck, with IGP Capabilities being defined we'll be able to do more things even faster (although I'm kidding, be wary :-) Seriously though, maybe piggybacking on routing protocols is the right answer -- or is it? Most of the problems folks are trying to solve certainly seem very real. I was mesmerized by the sight of a "panel" at the Routing Area meeting, and as I suspected, only the same set of arguments were repeated to no avail. As several people have suggested, I think if folks have something more to say and are genuinely concerned with this topic, you should probably attempt to organize and document your thoughts in an Internet-Draft and post it accordingly, else it'll likely be lost in the obvious rumble of political and commercial agendas and egotistic chest thumping. I know of several folks that are engaged in this process now, hopefully, some good will come of it. -danny _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 15:09:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13645 for ; Wed, 30 Jul 2003 15:09:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwIr-0008MJ-Iy; Wed, 30 Jul 2003 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwIY-0008IW-Ao for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 15:07:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13483 for ; Wed, 30 Jul 2003 15:07:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hwIV-0002ot-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 15:07:39 -0400 Received: from dhcp4.se.kurtis.pp.se ([195.43.225.73] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hwIU-0002oq-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 15:07:38 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6UJ7cFJ007139; Wed, 30 Jul 2003 21:07:40 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: routing-discussion@ietf.org To: Randy Bush From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <1198849C-C2C1-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 21:07:31 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > so, how would you suggest we measure this? What I can't figure out.... We all know that BGP doesn't scale, convergence is a serious problem, etc, etc. What on earth makes us think that adding data to be distributed and processed will not have impact? Or make it worse? Could someone enlighten me? Router vendors have a hard time as it is to get packets from interface A to interface B. The people designing these systems and providing feedback (so I include myself, and most people on this list) have been at this for more than 10 years. What we have today is the best we have done so far. If this would be any other business, we would have the government intervene (for example, look at the food scandals in Europe. To a large extend that is failure of the standards bodies). We have continuously complained of the performance of BGP (I am not as much long-timer as some people here, but I have probably been around longer than many), and yet we continue to add features. The first thing that amazes me is that developers of various features _even want_ them to use BGP, the second thing that amazes me is that we haven't started to see a pattern. I am sorry I can't work this out - and I have had way to much coffee for someone who shouldn't drink coffee at all ;-) Last, but I think Randy have a point, we need to agree on what we are trying to measure first. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPygXdqarNKXTPFCVEQLWBgCfUej55kjHJMu/sMmu4dF0QQ5amiMAn3N4 BBBjMUsS4E4a6nTTZHkV74Hk =FFbc -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 15:09:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13644 for ; Wed, 30 Jul 2003 15:09:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwJZ-0008UW-Hl for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 15:08:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UJ8jlj032634 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 15:08:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwIr-0008MJ-Iy; Wed, 30 Jul 2003 15:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwIY-0008IW-Ao for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 15:07:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13483 for ; Wed, 30 Jul 2003 15:07:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hwIV-0002ot-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 15:07:39 -0400 Received: from dhcp4.se.kurtis.pp.se ([195.43.225.73] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19hwIU-0002oq-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 15:07:38 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6UJ7cFJ007139; Wed, 30 Jul 2003 21:07:40 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: routing-discussion@ietf.org To: Randy Bush From: Kurt Erik Lindqvist In-Reply-To: Message-Id: <1198849C-C2C1-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 21:07:31 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > so, how would you suggest we measure this? What I can't figure out.... We all know that BGP doesn't scale, convergence is a serious problem, etc, etc. What on earth makes us think that adding data to be distributed and processed will not have impact? Or make it worse? Could someone enlighten me? Router vendors have a hard time as it is to get packets from interface A to interface B. The people designing these systems and providing feedback (so I include myself, and most people on this list) have been at this for more than 10 years. What we have today is the best we have done so far. If this would be any other business, we would have the government intervene (for example, look at the food scandals in Europe. To a large extend that is failure of the standards bodies). We have continuously complained of the performance of BGP (I am not as much long-timer as some people here, but I have probably been around longer than many), and yet we continue to add features. The first thing that amazes me is that developers of various features _even want_ them to use BGP, the second thing that amazes me is that we haven't started to see a pattern. I am sorry I can't work this out - and I have had way to much coffee for someone who shouldn't drink coffee at all ;-) Last, but I think Randy have a point, we need to agree on what we are trying to measure first. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPygXdqarNKXTPFCVEQLWBgCfUej55kjHJMu/sMmu4dF0QQ5amiMAn3N4 BBBjMUsS4E4a6nTTZHkV74Hk =FFbc -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 15:49:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12895 for ; Wed, 30 Jul 2003 15:01:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwBr-0007o6-RJ for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 15:00:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UJ0l03029988 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 15:00:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwB7-0007gF-Po; Wed, 30 Jul 2003 15:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hwAK-0007e6-6c for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 14:59:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12800 for ; Wed, 30 Jul 2003 14:59:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hwAH-0002kO-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:59:09 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19hwAG-0002k7-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 14:59:08 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6UIwapp000312; Wed, 30 Jul 2003 11:58:37 -0700 (PDT) Received: from CSCOAMERA19540.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AJU34234; Wed, 30 Jul 2003 11:53:33 -0700 (PDT) Message-Id: <5.2.0.9.2.20030730114414.05544cf8@mira-sjc5-b.cisco.com> X-Sender: fred@mira-sjc5-b.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: Danny McPherson From: Fred Baker Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna] Cc: In-Reply-To: References: <102561546891.20030730103929@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 11:57:25 -0700 At 12:16 PM 7/30/2003 -0600, Danny McPherson wrote: >If it's that important [and the folks they're speaking >on behalf of have email and half a clue!], you'd think they might be capable >of speaking for themselves I agree with the sentiment, and at the same time I can tell you of a number of cases where they have chosen not to but rather to pull me (and presumably others) off in the hallways and say "please do in the IETF and we will use it". I get very frustrated with them for not speaking for themselves, but I also know that they often feel that there is some competitive information that they don't want to leak. They would rather use some sort of surrogate. So, for them, I would hope that this is a call to speak for themselves. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 16:45:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17071 for ; Wed, 30 Jul 2003 16:45:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxnk-0003I7-Th; Wed, 30 Jul 2003 16:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxmp-0003Hh-8r for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 16:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17049 for ; Wed, 30 Jul 2003 16:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxmn-0003QM-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 16:43:01 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hxmm-0003Q8-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 16:43:00 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 13:42:30 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6UKgRxc006696; Wed, 30 Jul 2003 16:42:28 -0400 (EDT) Message-Id: <200307302042.h6UKgRxc006696@rtp-core-2.cisco.com> To: Kurt Erik Lindqvist cc: Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 21:07:31 +0200. <1198849C-C2C1-11D7-958B-000393A638B2@kurtis.pp.se> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 16:40:43 -0400 Kurt> We all know that BGP doesn't scale Yes, that must be what prevented the Internet from ever getting very large. ;-) Kurt> What on earth makes us think that adding data to be distributed and Kurt> processed will not have impact? Or make it worse? Could someone Kurt> enlighten me? Let's look at two cases: 1. The new data is going to be distributed to the same set of nodes which currently speak BGP for the purpose of maintaining their Internet routing tables. Assuming that there is some necessity of distributing that new data, then however one distributes it, those nodes are going to have to handle it. Either they have enough capacity for it or they don't. Using a second protocol does not reduce the distribution or the capacity load. 2. The new data is distributed to a different set of nodes than the ones which currently speak BGP for the purpose of maintaining their Internet routing tables. In this case, the use of BGP by the nodes which need the new data has no impact on the nodes which use BGP to maintain their Internet routing tables. So in neither case do I see what this terrifying impact is. Now for a particular kind of data, you may want to argue that BGP is not the appropriate mechanism for distributing that kind of data. But to decide that you need to look at the details of the particular proposal. Kurt> The first thing that amazes me is that developers of various features Kurt> _even want_ them to use BGP, the second thing that amazes me is that Kurt> we haven't started to see a pattern. I guess not everyone agrees with you that _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 16:45:19 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17075 for ; Wed, 30 Jul 2003 16:45:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxoc-0003OJ-E5 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 16:44:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UKisnd013029 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 16:44:54 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxnk-0003I7-Th; Wed, 30 Jul 2003 16:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxmp-0003Hh-8r for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 16:43:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17049 for ; Wed, 30 Jul 2003 16:42:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxmn-0003QM-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 16:43:01 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hxmm-0003Q8-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 16:43:00 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 30 Jul 2003 13:42:30 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6UKgRxc006696; Wed, 30 Jul 2003 16:42:28 -0400 (EDT) Message-Id: <200307302042.h6UKgRxc006696@rtp-core-2.cisco.com> To: Kurt Erik Lindqvist cc: Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Wed, 30 Jul 2003 21:07:31 +0200. <1198849C-C2C1-11D7-958B-000393A638B2@kurtis.pp.se> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 16:40:43 -0400 Kurt> We all know that BGP doesn't scale Yes, that must be what prevented the Internet from ever getting very large. ;-) Kurt> What on earth makes us think that adding data to be distributed and Kurt> processed will not have impact? Or make it worse? Could someone Kurt> enlighten me? Let's look at two cases: 1. The new data is going to be distributed to the same set of nodes which currently speak BGP for the purpose of maintaining their Internet routing tables. Assuming that there is some necessity of distributing that new data, then however one distributes it, those nodes are going to have to handle it. Either they have enough capacity for it or they don't. Using a second protocol does not reduce the distribution or the capacity load. 2. The new data is distributed to a different set of nodes than the ones which currently speak BGP for the purpose of maintaining their Internet routing tables. In this case, the use of BGP by the nodes which need the new data has no impact on the nodes which use BGP to maintain their Internet routing tables. So in neither case do I see what this terrifying impact is. Now for a particular kind of data, you may want to argue that BGP is not the appropriate mechanism for distributing that kind of data. But to decide that you need to look at the details of the particular proposal. Kurt> The first thing that amazes me is that developers of various features Kurt> _even want_ them to use BGP, the second thing that amazes me is that Kurt> we haven't started to see a pattern. I guess not everyone agrees with you that _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 17:05:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17911 for ; Wed, 30 Jul 2003 17:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hy77-00046Q-Gq; Wed, 30 Jul 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hy6M-00043k-GU for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17799 for ; Wed, 30 Jul 2003 17:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hy6K-0003cX-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:03:12 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 19hy6J-0003cP-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:03:11 -0400 Received: from gih505.telstra.net (dhcp50.potaroo.net [203.10.60.50]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h6UL2TD7069651; Thu, 31 Jul 2003 07:02:31 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: erosen@cisco.com, routing-discussion@ietf.org From: Geoff Huston Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307302042.h6UKgRxc006696@rtp-core-2.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 07:02:14 +1000 At 04:40 PM 30/07/2003 -0400, Eric Rosen wrote: >Kurt> We all know that BGP doesn't scale > >Yes, that must be what prevented the Internet from ever getting very >large. ;-) I suspect in this comment that Eric is skipping across some amazing efforts by a small pool of folk to reign in some of the more extreme forms of deployed routing abuse (no, I do not count my own small efforts in this pool of individuals). Keeping the network vaguely stable at it's current size is taking increasingly large amounts of manual effort, and no, this cannot scale indefinitely. There _are_ problems in BGP deployments, and overloading the running instance of the protocol to carry more information related to various overlay signalling applications does not in itself assist in improving the situation. For me its a counter-intuitive action that increases the level of operational reliance on a single element of the network. But as Randy and Kurt have said this already there's no point in my repeating it. Geoff _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 17:05:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17913 for ; Wed, 30 Jul 2003 17:05:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hy7r-0004Eg-HZ for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:04:47 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UL4lhX016256 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:04:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hy77-00046Q-Gq; Wed, 30 Jul 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hy6M-00043k-GU for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:03:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17799 for ; Wed, 30 Jul 2003 17:03:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hy6K-0003cX-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:03:12 -0400 Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx with esmtp (Exim 4.12) id 19hy6J-0003cP-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:03:11 -0400 Received: from gih505.telstra.net (dhcp50.potaroo.net [203.10.60.50]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h6UL2TD7069651; Thu, 31 Jul 2003 07:02:31 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net> X-Sender: gih@kahuna.telstra.net X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: erosen@cisco.com, routing-discussion@ietf.org From: Geoff Huston Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <200307302042.h6UKgRxc006696@rtp-core-2.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 07:02:14 +1000 At 04:40 PM 30/07/2003 -0400, Eric Rosen wrote: >Kurt> We all know that BGP doesn't scale > >Yes, that must be what prevented the Internet from ever getting very >large. ;-) I suspect in this comment that Eric is skipping across some amazing efforts by a small pool of folk to reign in some of the more extreme forms of deployed routing abuse (no, I do not count my own small efforts in this pool of individuals). Keeping the network vaguely stable at it's current size is taking increasingly large amounts of manual effort, and no, this cannot scale indefinitely. There _are_ problems in BGP deployments, and overloading the running instance of the protocol to carry more information related to various overlay signalling applications does not in itself assist in improving the situation. For me its a counter-intuitive action that increases the level of operational reliance on a single element of the network. But as Randy and Kurt have said this already there's no point in my repeating it. Geoff _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 17:23:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18275 for ; Wed, 30 Jul 2003 17:23:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyOX-0004mB-4X; Wed, 30 Jul 2003 17:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyNw-0004lw-Nz for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:21:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18251 for ; Wed, 30 Jul 2003 17:21:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyNu-0003kk-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:21:22 -0400 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx with esmtp (Exim 4.12) id 19hyNt-0003kh-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:21:21 -0400 Received: from petal.blackrose.org (localhost [127.0.0.1]) by petal.blackrose.org (8.12.9/8.12.4) with ESMTP id h6ULVGfM012246; Wed, 30 Jul 2003 17:31:16 -0400 Received: (from dorian@localhost) by petal.blackrose.org (8.12.9/8.12.4/Submit) id h6ULVGNL012245; Wed, 30 Jul 2003 17:31:16 -0400 From: Dorian Kim To: Kurt Erik Lindqvist Cc: erosen@cisco.com, Randy Bush , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030730213116.GB12046@blackrose.org> References: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> <4A9296C2-C2B6-11D7-958B-000393A638B2@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9296C2-C2B6-11D7-958B-000393A638B2@kurtis.pp.se> User-Agent: Mutt/1.4i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 17:31:16 -0400 On Wed, Jul 30, 2003 at 07:50:22PM +0200, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Randy> well, so much for bgp, as any one researcher who actually > > looks at > > Randy> how the protocol performs on the net will tell you. > > > > Sure, BGP is the worst possible protocol, except for all the others. > > If we > > can come up with a protocol that is clearly better, let's definitely > > use it > > instead. In the meantime, however, ... > > I think one of the problems with BGP is that it has lured into this "as > there is nothing better, let's put it all in there". To be honest I > think that the reason that you are seeing customers being perfectly > happy to put various features into BGP is not that they don't see a > problem with it. They don't think there is an alternative. Along the same vein, I wonder how many other operators started out with a strong stance against overloading of BGP, and after years of tilting at that windmill and observing that vendors continues to pile on new "feature" after "feature" into BGP, just gave up? I certainly have. As an operator stability and optimal performance of BGP implementations are of upmost concern for me, and there was a time that many others appeared to feel the same. Afterall, MSDP didn't end up in BGP and became a separate protocol because of that concern. However, since then I've seen vendors continually ignore our concern and input and overload other features into BGP. There are those who say that it's operators' need to deploy new services that's been causing this, but from my perspective, when/where we do use new gadgets in BGP to rollout new service deployments it's because vendors have already put those gadgets into their BGP implementation despite my feedback, and there's only so much time and energy we can spend bashing our heads against the brick wall. Afterall, we have a network to run and services to deploy. So, is it really that operators all want to pile everything on BGP, or is it that they don't see any alternatives? -dorian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 17:25:01 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18487 for ; Wed, 30 Jul 2003 17:25:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyR3-00053b-7Q for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:24:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULObSW019410 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:24:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyQS-0004uV-Up; Wed, 30 Jul 2003 17:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyPd-0004t9-Rr for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18268 for ; Wed, 30 Jul 2003 17:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyPY-0003lK-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:23:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hyPX-0003l6-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:23:03 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6ULMUxc011134; Wed, 30 Jul 2003 17:22:31 -0400 (EDT) Message-Id: <200307302122.h6ULMUxc011134@rtp-core-2.cisco.com> To: Geoff Huston cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Thu, 31 Jul 2003 07:02:14 +1000. <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 17:22:30 -0400 Geoff> There _are_ problems in BGP deployments, and overloading the running Geoff> instance of the protocol to carry more information related to various Geoff> overlay signalling applications does not in itself assist in Geoff> improving the situation. For me its a counter-intuitive action that Geoff> increases the level of operational reliance on a single element of Geoff> the network. This is all true, but it seems like a deployment issue rather than a protocol issue. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 17:25:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18486 for ; Wed, 30 Jul 2003 17:25:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyQS-0004uV-Up; Wed, 30 Jul 2003 17:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyPd-0004t9-Rr for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:23:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18268 for ; Wed, 30 Jul 2003 17:23:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyPY-0003lK-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:23:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19hyPX-0003l6-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:23:03 -0400 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6ULMUxc011134; Wed, 30 Jul 2003 17:22:31 -0400 (EDT) Message-Id: <200307302122.h6ULMUxc011134@rtp-core-2.cisco.com> To: Geoff Huston cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Thu, 31 Jul 2003 07:02:14 +1000. <5.1.0.14.2.20030731064951.01ebd3c0@kahuna.telstra.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 17:22:30 -0400 Geoff> There _are_ problems in BGP deployments, and overloading the running Geoff> instance of the protocol to carry more information related to various Geoff> overlay signalling applications does not in itself assist in Geoff> improving the situation. For me its a counter-intuitive action that Geoff> increases the level of operational reliance on a single element of Geoff> the network. This is all true, but it seems like a deployment issue rather than a protocol issue. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 17:28:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18825 for ; Wed, 30 Jul 2003 17:28:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyTO-0005HE-1i; Wed, 30 Jul 2003 17:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyT5-0005GX-D6 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:26:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18759 for ; Wed, 30 Jul 2003 17:26:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyT3-0003q5-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:26:41 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19hyT2-0003pO-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:26:40 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6ULQHNa000536; Wed, 30 Jul 2003 14:26:17 -0700 From: David Meyer To: routing-discussion@ietf.org Subject: What is this all about? [was Re: Open Routing Area meeting in Vienna] Message-ID: <20030730142617.A32621@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 14:26:17 -0700 I was reading all of the traffic on this list this AM and decided to go off to the gym, experience a little of the relationship between mass and gravity, and think about all of this a bit. So, it seems to me that there are (at least) five general areas that we've been discussing: (i). The control theoretic properties of the BGP control plane. As Randy points out, this is a topic of great interest to most everyone, and has been (and continues to be) the object of a great deal of study. (ii). Possibly not unrelated to (i). above is the potential impact on the behavior of the BGP control plane (i.e., operational stability). More specifically, we seem to be discussing the impact of various transporting features and their associated signaling using the BGP control plane (no one seems to have voiced an explicit problem with the BGP data plane, as far as I can tell). (iii). Another point that has been discussed in this thread (as well as in Vienna) relates to the software engineering aspects of transporting features and signaling using the BGP infrastructure that is deployed on the Internet today. In particular, some have concern about the effect of this practice on the stability of the Internet (i.e., (i)-(ii) above). Others see it (explicitly) differently. (iv). Again, possibly related to (i)-(iii) are a set of loosely defined/described concerns relating to the possible increase in system complexity deriving from extensions to BGP (the term extensions here is itself loosely defined; one might argue that the extension was to MP-BGP, and the rest fits within that framework, and hence are not extensions). One thing that I think we as a community have learned over the past few years is that a quantitative understanding of the complexity of a system like the Internet is currently beyond our grasp. See http://www.maoz.com/~dmm/complexity_and_the_internet for an overview of some of the early work in this area (the point here is that the field is in a very early stage in its development). (v). Market forces and their associated economics. It is interesting to note that, in addition to the discussion of AFs we're having here, current BGP deployment practices are clearly not independent of these same forces. (vi). Others that I missed. These are complex issues in that they involve a system (the Internet) who's behavior we can not precisely characterize (in many cases, we just don't have the tools). These include, but not limited to, the quantative behavior of the current BGP control plane, market forces involved in fielding features (and signaling) in BGP, and in general, the stability and scaling properties of the BGP as deployed in the Internet. All of that considered, one approach which might be constructive here is to understand which of (i)-(v) above, if any, are in scope for this discussion (and in scope for the IETF in general), and to fill out (vi), as there must be other issues not captured by (i)-(iv). Then, to Danny's point, we can finish up the straw-person document, post it here (or wherever is appropriate), and discuss that. That would seem to be consistent with the IETF process, as I understand it. >> My point: each person's arguments should carry weight based on the >> content, not on the author's employer... Agree, and to put a (slightly) finer point on it (quoting the great Sly Stone now): Sometimes I'm right, but I can be wrong My own beliefs are in my song The butcher, the banker, the drummer and then Makes no difference what group I'm in Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 17:28:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18827 for ; Wed, 30 Jul 2003 17:28:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyTy-0005N3-5W for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:27:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULRc4S020638 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:27:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyTO-0005HE-1i; Wed, 30 Jul 2003 17:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyT5-0005GX-D6 for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:26:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18759 for ; Wed, 30 Jul 2003 17:26:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyT3-0003q5-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:26:41 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19hyT2-0003pO-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:26:40 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6ULQHNa000536; Wed, 30 Jul 2003 14:26:17 -0700 From: David Meyer To: routing-discussion@ietf.org Subject: What is this all about? [was Re: Open Routing Area meeting in Vienna] Message-ID: <20030730142617.A32621@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 14:26:17 -0700 I was reading all of the traffic on this list this AM and decided to go off to the gym, experience a little of the relationship between mass and gravity, and think about all of this a bit. So, it seems to me that there are (at least) five general areas that we've been discussing: (i). The control theoretic properties of the BGP control plane. As Randy points out, this is a topic of great interest to most everyone, and has been (and continues to be) the object of a great deal of study. (ii). Possibly not unrelated to (i). above is the potential impact on the behavior of the BGP control plane (i.e., operational stability). More specifically, we seem to be discussing the impact of various transporting features and their associated signaling using the BGP control plane (no one seems to have voiced an explicit problem with the BGP data plane, as far as I can tell). (iii). Another point that has been discussed in this thread (as well as in Vienna) relates to the software engineering aspects of transporting features and signaling using the BGP infrastructure that is deployed on the Internet today. In particular, some have concern about the effect of this practice on the stability of the Internet (i.e., (i)-(ii) above). Others see it (explicitly) differently. (iv). Again, possibly related to (i)-(iii) are a set of loosely defined/described concerns relating to the possible increase in system complexity deriving from extensions to BGP (the term extensions here is itself loosely defined; one might argue that the extension was to MP-BGP, and the rest fits within that framework, and hence are not extensions). One thing that I think we as a community have learned over the past few years is that a quantitative understanding of the complexity of a system like the Internet is currently beyond our grasp. See http://www.maoz.com/~dmm/complexity_and_the_internet for an overview of some of the early work in this area (the point here is that the field is in a very early stage in its development). (v). Market forces and their associated economics. It is interesting to note that, in addition to the discussion of AFs we're having here, current BGP deployment practices are clearly not independent of these same forces. (vi). Others that I missed. These are complex issues in that they involve a system (the Internet) who's behavior we can not precisely characterize (in many cases, we just don't have the tools). These include, but not limited to, the quantative behavior of the current BGP control plane, market forces involved in fielding features (and signaling) in BGP, and in general, the stability and scaling properties of the BGP as deployed in the Internet. All of that considered, one approach which might be constructive here is to understand which of (i)-(v) above, if any, are in scope for this discussion (and in scope for the IETF in general), and to fill out (vi), as there must be other issues not captured by (i)-(iv). Then, to Danny's point, we can finish up the straw-person document, post it here (or wherever is appropriate), and discuss that. That would seem to be consistent with the IETF process, as I understand it. >> My point: each person's arguments should carry weight based on the >> content, not on the author's employer... Agree, and to put a (slightly) finer point on it (quoting the great Sly Stone now): Sometimes I'm right, but I can be wrong My own beliefs are in my song The butcher, the banker, the drummer and then Makes no difference what group I'm in Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 18:09:44 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18276 for ; Wed, 30 Jul 2003 17:23:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyPB-0004rm-Mg for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:22:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULMfrD018700 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 17:22:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyOX-0004mB-4X; Wed, 30 Jul 2003 17:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hyNw-0004lw-Nz for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 17:21:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18251 for ; Wed, 30 Jul 2003 17:21:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyNu-0003kk-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:21:22 -0400 Received: from petal.blackrose.org ([204.212.44.11]) by ietf-mx with esmtp (Exim 4.12) id 19hyNt-0003kh-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 17:21:21 -0400 Received: from petal.blackrose.org (localhost [127.0.0.1]) by petal.blackrose.org (8.12.9/8.12.4) with ESMTP id h6ULVGfM012246; Wed, 30 Jul 2003 17:31:16 -0400 Received: (from dorian@localhost) by petal.blackrose.org (8.12.9/8.12.4/Submit) id h6ULVGNL012245; Wed, 30 Jul 2003 17:31:16 -0400 From: Dorian Kim To: Kurt Erik Lindqvist Cc: erosen@cisco.com, Randy Bush , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030730213116.GB12046@blackrose.org> References: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> <4A9296C2-C2B6-11D7-958B-000393A638B2@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A9296C2-C2B6-11D7-958B-000393A638B2@kurtis.pp.se> User-Agent: Mutt/1.4i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 17:31:16 -0400 On Wed, Jul 30, 2003 at 07:50:22PM +0200, Kurt Erik Lindqvist wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Randy> well, so much for bgp, as any one researcher who actually > > looks at > > Randy> how the protocol performs on the net will tell you. > > > > Sure, BGP is the worst possible protocol, except for all the others. > > If we > > can come up with a protocol that is clearly better, let's definitely > > use it > > instead. In the meantime, however, ... > > I think one of the problems with BGP is that it has lured into this "as > there is nothing better, let's put it all in there". To be honest I > think that the reason that you are seeing customers being perfectly > happy to put various features into BGP is not that they don't see a > problem with it. They don't think there is an alternative. Along the same vein, I wonder how many other operators started out with a strong stance against overloading of BGP, and after years of tilting at that windmill and observing that vendors continues to pile on new "feature" after "feature" into BGP, just gave up? I certainly have. As an operator stability and optimal performance of BGP implementations are of upmost concern for me, and there was a time that many others appeared to feel the same. Afterall, MSDP didn't end up in BGP and became a separate protocol because of that concern. However, since then I've seen vendors continually ignore our concern and input and overload other features into BGP. There are those who say that it's operators' need to deploy new services that's been causing this, but from my perspective, when/where we do use new gadgets in BGP to rollout new service deployments it's because vendors have already put those gadgets into their BGP implementation despite my feedback, and there's only so much time and energy we can spend bashing our heads against the brick wall. Afterall, we have a network to run and services to deploy. So, is it really that operators all want to pile everything on BGP, or is it that they don't see any alternatives? -dorian _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 19:47:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23849 for ; Wed, 30 Jul 2003 19:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0es-0002if-AO; Wed, 30 Jul 2003 19:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0e3-0002ge-5f for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 19:46:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23784 for ; Wed, 30 Jul 2003 19:46:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i0e1-0005MX-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 19:46:09 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19i0e0-0005MM-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 19:46:08 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6UNjiF4002271; Wed, 30 Jul 2003 16:45:44 -0700 From: David Meyer To: routing-discussion@ietf.org Subject: Re: What is this all about? [was Re: Open Routing Area meeting in Vienna] Message-ID: <20030730164544.A2248@1-4-5.net> References: <20030730142617.A32621@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030730142617.A32621@1-4-5.net>; from dmm@1-4-5.net on Wed, Jul 30, 2003 at 02:26:17PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 16:45:44 -0700 One clarification: >> (ii). Possibly not unrelated to (i). above is the >> potential impact on the behavior of the BGP >> control plane (i.e., operational stability). More >> specifically, we seem to be discussing the impact >> of various transporting features and their >> associated signaling using the BGP control plane >> (no one seems to have voiced an explicit problem >> with the BGP data plane, as far as I can tell). I kinda mangled what I was trying to say here (sorry about that). Basically, this item was supposed to capture the discussion about the impact of carrying new AF/SAFIs and their associated signaling data in BGP. The parenthetical comment about the data plane was meant to reflect that I hadn't seen any discussion about the encoding or format of the data being carried (someone correct me if I'm wrong there). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 19:47:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23847 for ; Wed, 30 Jul 2003 19:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0er-0002hv-PB; Wed, 30 Jul 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huQz-0001jQ-Gb for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:08:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08463 for ; Wed, 30 Jul 2003 13:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huQx-0001qH-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:08:15 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19huQx-0001qE-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:08:15 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 6C52B4F3D2; Wed, 30 Jul 2003 13:08:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16167.64368.170120.892909@durmstrang.padfoot.com> From: Henry Kilmer To: Randy Bush Cc: Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: References: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:08:00 -0400 Content-Transfer-Encoding: 7bit Randy Bush writes: >one of the advantages of working for an operator is that you get to >talk to lots of vendors, not just the ones that are politically >well connected in the ietf. and i can tell you that the idea of >extending bgp ad infinitum horrifies most of them. > >can we now finish representing hidden others than ourselves, >expecially given that the ietf is supposedly a forum of individual >experts? Amen. Although I don't think the operator to vendor ratio within the IETF forums are what they should be to produce the best results. -Hank _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 20:34:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23854 for ; Wed, 30 Jul 2003 19:47:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0fK-0002ms-D5 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 19:47:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UNlU5p010620 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 19:47:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0er-0002hv-PB; Wed, 30 Jul 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huQz-0001jQ-Gb for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 13:08:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08463 for ; Wed, 30 Jul 2003 13:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huQx-0001qH-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:08:15 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19huQx-0001qE-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 13:08:15 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 6C52B4F3D2; Wed, 30 Jul 2003 13:08:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16167.64368.170120.892909@durmstrang.padfoot.com> From: Henry Kilmer To: Randy Bush Cc: Eric Rosen , Kurt Erik Lindqvist , raszuk@cisco.com, Alex Zinin , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: References: <200307301630.h6UGUc7F011662@sj-core-2.cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 13:08:00 -0400 Content-Transfer-Encoding: 7bit Randy Bush writes: >one of the advantages of working for an operator is that you get to >talk to lots of vendors, not just the ones that are politically >well connected in the ietf. and i can tell you that the idea of >extending bgp ad infinitum horrifies most of them. > >can we now finish representing hidden others than ourselves, >expecially given that the ietf is supposedly a forum of individual >experts? Amen. Although I don't think the operator to vendor ratio within the IETF forums are what they should be to produce the best results. -Hank _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 20:34:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23848 for ; Wed, 30 Jul 2003 19:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0fK-0002mV-CP for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 19:47:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UNlU8J010619 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 19:47:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0es-0002if-AO; Wed, 30 Jul 2003 19:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0e3-0002ge-5f for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 19:46:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23784 for ; Wed, 30 Jul 2003 19:46:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i0e1-0005MX-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 19:46:09 -0400 Received: from sith.maoz.com ([205.167.76.10]) by ietf-mx with esmtp (Exim 4.12) id 19i0e0-0005MM-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 19:46:08 -0400 Received: (from dmm@localhost) by sith.maoz.com (8.12.9/8.12.9) id h6UNjiF4002271; Wed, 30 Jul 2003 16:45:44 -0700 From: David Meyer To: routing-discussion@ietf.org Subject: Re: What is this all about? [was Re: Open Routing Area meeting in Vienna] Message-ID: <20030730164544.A2248@1-4-5.net> References: <20030730142617.A32621@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030730142617.A32621@1-4-5.net>; from dmm@1-4-5.net on Wed, Jul 30, 2003 at 02:26:17PM -0700 X-public-key: http://www.maoz.com/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 16:45:44 -0700 One clarification: >> (ii). Possibly not unrelated to (i). above is the >> potential impact on the behavior of the BGP >> control plane (i.e., operational stability). More >> specifically, we seem to be discussing the impact >> of various transporting features and their >> associated signaling using the BGP control plane >> (no one seems to have voiced an explicit problem >> with the BGP data plane, as far as I can tell). I kinda mangled what I was trying to say here (sorry about that). Basically, this item was supposed to capture the discussion about the impact of carrying new AF/SAFIs and their associated signaling data in BGP. The parenthetical comment about the data plane was meant to reflect that I hadn't seen any discussion about the encoding or format of the data being carried (someone correct me if I'm wrong there). Dave _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Wed Jul 30 20:34:47 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23850 for ; Wed, 30 Jul 2003 19:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0er-0002hB-8T; Wed, 30 Jul 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huIx-00011c-AA for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 12:59:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08127 for ; Wed, 30 Jul 2003 12:59:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huIv-0001mh-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:59:57 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19huIv-0001me-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:59:57 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 06EB84F3D5; Wed, 30 Jul 2003 12:59:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16167.63869.703754.88668@durmstrang.padfoot.com> From: Henry Kilmer To: raszuk@cisco.com Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3F2702AF.252E568F@cisco.com> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <3F2702AF.252E568F@cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 12:59:41 -0400 Content-Transfer-Encoding: 7bit You're asking for the URL for all of the NOCs of the major ISPs. Robert Raszuk writes: > >I am sure those opinions must be documented - could you compile a URL >reference list so we can all see how bad it "performs" today ? Also if >those folks are real researchers we will most likely be able to also see >studies on how much time do we have left. > >R. > >> Randy Bush wrote: >> >> > There has always been an issue if one should extend one city with new >> > buildings or start over and build new city. My take on this is that if >> > the architecture of a given city is good, communication is perfect and >> > can scale adding a new buildings or districts nicely divided from one >> > another will not harm anyone to get to large sizes accomodating all >> > newcommers. >> >> well, so much for bgp, as anyone researcher who actually looks at >> how the protocol performs on the net will tell you. >> >> randy > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Wed Jul 30 20:34:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23851 for ; Wed, 30 Jul 2003 19:47:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0fK-0002n6-DZ for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 19:47:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UNlUpr010621 for routing-discussion-archive@odin.ietf.org; Wed, 30 Jul 2003 19:47:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i0er-0002hB-8T; Wed, 30 Jul 2003 19:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19huIx-00011c-AA for routing-discussion@optimus.ietf.org; Wed, 30 Jul 2003 12:59:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08127 for ; Wed, 30 Jul 2003 12:59:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19huIv-0001mh-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:59:57 -0400 Received: from mail.padfoot.com ([198.137.194.43]) by ietf-mx with esmtp (Exim 4.12) id 19huIv-0001me-00 for routing-discussion@ietf.org; Wed, 30 Jul 2003 12:59:57 -0400 Received: by mail.padfoot.com (Postfix, from userid 102) id 06EB84F3D5; Wed, 30 Jul 2003 12:59:41 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16167.63869.703754.88668@durmstrang.padfoot.com> From: Henry Kilmer To: raszuk@cisco.com Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3F2702AF.252E568F@cisco.com> References: <10069799636.20030724180341@psg.com> <20030724212737.T1920@sbrim-w2k01> <112484955939.20030729132258@psg.com> <3F26FAE6.EA0D6868@cisco.com> <3F2702AF.252E568F@cisco.com> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 30 Jul 2003 12:59:41 -0400 Content-Transfer-Encoding: 7bit You're asking for the URL for all of the NOCs of the major ISPs. Robert Raszuk writes: > >I am sure those opinions must be documented - could you compile a URL >reference list so we can all see how bad it "performs" today ? Also if >those folks are real researchers we will most likely be able to also see >studies on how much time do we have left. > >R. > >> Randy Bush wrote: >> >> > There has always been an issue if one should extend one city with new >> > buildings or start over and build new city. My take on this is that if >> > the architecture of a given city is good, communication is perfect and >> > can scale adding a new buildings or districts nicely divided from one >> > another will not harm anyone to get to large sizes accomodating all >> > newcommers. >> >> well, so much for bgp, as anyone researcher who actually looks at >> how the protocol performs on the net will tell you. >> >> randy > >_______________________________________________ >routing-discussion mailing list >routing-discussion@ietf.org >https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:28:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14446 for ; Thu, 31 Jul 2003 03:28:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7qz-0001Rk-IW; Thu, 31 Jul 2003 03:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7qU-0001Qs-9a for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:27:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14415 for ; Thu, 31 Jul 2003 03:27:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7qS-0000LU-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:27:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7qR-0000LR-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:27:27 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7qR-000IyU-R8 for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:27:27 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <132611177176.20030731002639@psg.com> To: routing-discussion@ietf.org Subject: Threads and subject lines MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:26:39 -0700 Content-Transfer-Encoding: 7bit [Re: Open Routing Area meeting in Vienna] For a more focused discussion, I'll be taking several important topics to separate threads. Please use appropriate subject lines. If you believe that an important issue has been accidently dropped, please take it to the appropriate thread or spawn a new one. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:28:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14449 for ; Thu, 31 Jul 2003 03:28:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7rQ-0001Yd-WE for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:28:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7SSxU005916 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:28:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7qz-0001Rk-IW; Thu, 31 Jul 2003 03:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7qU-0001Qs-9a for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:27:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14415 for ; Thu, 31 Jul 2003 03:27:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7qS-0000LU-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:27:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7qR-0000LR-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:27:27 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7qR-000IyU-R8 for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:27:27 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <132611177176.20030731002639@psg.com> To: routing-discussion@ietf.org Subject: Threads and subject lines MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:26:39 -0700 Content-Transfer-Encoding: 7bit [Re: Open Routing Area meeting in Vienna] For a more focused discussion, I'll be taking several important topics to separate threads. Please use appropriate subject lines. If you believe that an important issue has been accidently dropped, please take it to the appropriate thread or spawn a new one. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:29:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14498 for ; Thu, 31 Jul 2003 03:29:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7rx-0001bU-Sv; Thu, 31 Jul 2003 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7rc-0001ZV-AA for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:28:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14443 for ; Thu, 31 Jul 2003 03:28:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7ra-0000Lt-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:38 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7rZ-0000Lq-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:37 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7ra-000J2k-Fy for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:28:38 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <28611247908.20030731002750@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: the goal of the discussion In-Reply-To: <200307300559.h6U5xE470168@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300559.h6U5xE470168@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:27:50 -0700 Content-Transfer-Encoding: 7bit I guess I should start with this one: Tuesday, July 29, 2003, 10:59:14 PM, Pedro Roque Marques wrote: [...] > I confess that i'm not quite sure what your goal is... For a long time I have been hearing concerns about mmmm... ever increasing popularity of BGP and routing protocols in general as one and the only answer to any problem involving distribution of information among routers (whether routing-related or not), a the potential impact of this on stability of BGP holding the Internet together. I've also seen folks refusing to accept the possibility that the above may cause concerns. I've also been observing vendors hard-pressed by dead-lines and competition to put more applications on top of BGP. As you said, there is "a fundamental difference in perception that we have". The question, however, is very important, and needs to be discussed in the open. My goal for this discussion is that we come out with a clear sense of direction. If we are fine with what's happening to RPs (and BGP in particular)--we'll keep walking down the same path. However, if this is not the case, we better have a very good idea where we want to be long term and what our next steps should be. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:29:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14499 for ; Thu, 31 Jul 2003 03:29:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7sI-0001h8-Qy for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:29:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7TMST006461 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:29:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7rx-0001bU-Sv; Thu, 31 Jul 2003 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7rc-0001ZV-AA for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:28:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14443 for ; Thu, 31 Jul 2003 03:28:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7ra-0000Lt-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:38 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7rZ-0000Lq-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:37 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7ra-000J2k-Fy for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:28:38 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <28611247908.20030731002750@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: the goal of the discussion In-Reply-To: <200307300559.h6U5xE470168@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300559.h6U5xE470168@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:27:50 -0700 Content-Transfer-Encoding: 7bit I guess I should start with this one: Tuesday, July 29, 2003, 10:59:14 PM, Pedro Roque Marques wrote: [...] > I confess that i'm not quite sure what your goal is... For a long time I have been hearing concerns about mmmm... ever increasing popularity of BGP and routing protocols in general as one and the only answer to any problem involving distribution of information among routers (whether routing-related or not), a the potential impact of this on stability of BGP holding the Internet together. I've also seen folks refusing to accept the possibility that the above may cause concerns. I've also been observing vendors hard-pressed by dead-lines and competition to put more applications on top of BGP. As you said, there is "a fundamental difference in perception that we have". The question, however, is very important, and needs to be discussed in the open. My goal for this discussion is that we come out with a clear sense of direction. If we are fine with what's happening to RPs (and BGP in particular)--we'll keep walking down the same path. However, if this is not the case, we better have a very good idea where we want to be long term and what our next steps should be. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:30:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14556 for ; Thu, 31 Jul 2003 03:30:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7sw-0001ig-6z; Thu, 31 Jul 2003 03:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7rw-0001a7-KW for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:29:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14477 for ; Thu, 31 Jul 2003 03:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7ru-0000Lz-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:58 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7rt-0000Lw-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:57 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7ru-000J4e-OG for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:28:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <116611268077.20030731002810@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: what is "overloading" In-Reply-To: References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:28:10 -0700 Content-Transfer-Encoding: 7bit John, Tuesday, July 29, 2003, 6:19:25 PM, John G. Scudder wrote: [...] >>> The way I see it, the major concern is overloading of BGP, which is >> > part of Internet-critical infrastructure, with non-routing >> > functionality. > I would be interested to know if you can elaborate on this without > resort to the ambiguous term "non-routing". Sure. The discussion started with two VPN-related drafts (they had different names then): draft-ietf-l3vpn-bgpvpn-auto-00.txt and draft-ietf-l2vpn-vpls-bgp-00.txt At the IETF meeting in Vienna, we had some more BGP-based proposals, that are not related to distribution of {prefix, next-hop,...} tuples. If wanted to formalize when I see concerns being raised, I would probably use the results of the discussion we had on the RTG directorate: There are types of information that are fair to distribute in routing protocols: a) information required to calculate the routing tables b) route tagging, administrative, and policy-related information c) routing security-related information d) information closely related to routing, especially when synchronization with routing information is needed Others would be considered non-routing. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:31:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14636 for ; Thu, 31 Jul 2003 03:31:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7uF-0002C6-2l for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7VNHg008435 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tt-0001qd-HX; Thu, 31 Jul 2003 03:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7t9-0001oC-PW for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14539 for ; Thu, 31 Jul 2003 03:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7t7-0000Mu-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7t6-0000Mq-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:13 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7t7-000JCF-LL for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:13 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <178611342894.20030731002925@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: criticality of Internet routing In-Reply-To: <200307300559.h6U5xE470168@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300559.h6U5xE470168@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:25 -0700 Content-Transfer-Encoding: 7bit Tuesday, July 29, 2003, 10:59:14 PM, Pedro Roque Marques wrote: [...] > I confess that i'm not quite sure what your goal is... my assumption > is that you are concerned w/ the availiability of internet service, > which depends on several factors including the stability of router > software. Yes. See my message on "the goal". > While the latter is certainly a cause for concern, i would suggest > that you think of this equipment not as "Internet" infrastructure but > as equipment which is bought and operated by a telecomunications > company. Both views are valid, and both need to be kept in mind. We can't look at the routers in a SP network only within the contents of that given SP. They are also part of the Internet infrastructure, and we need to keep this picture in mind too. > Thus equipment caracteristics and failures are going to play an > important role in "Internet" availability, regardless of the root > cause of the problem. As such, "critical" needs to be defined from the > point of view of a service provider. If by "from the POV of a service provide" you mean within the context of its network only, then I would disagree. This would merely ignore the bigger picture. [part on impact on SW taken to a separate thread] > While people love to state that the "I in IETF stands for Internet" in > tend to be very sceptic of how realistic is this view. The Internet > doesn't exist in a vacum. The IETF itself doesn't have a vertical > approach in terms of considering all levels and elements used to > provide internet services. It has mostly an horizontal approach to > standardize the IP protocol suite regardless of the application. However, issues of the scale of the Internet should be kept in mind, and, frankly, I'm a bit surprised I find myself having to convince _routing_ folks on this... Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:31:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14638 for ; Thu, 31 Jul 2003 03:31:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tt-0001qd-HX; Thu, 31 Jul 2003 03:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7t9-0001oC-PW for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14539 for ; Thu, 31 Jul 2003 03:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7t7-0000Mu-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:13 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7t6-0000Mq-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:13 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7t7-000JCF-LL for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:13 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <178611342894.20030731002925@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: criticality of Internet routing In-Reply-To: <200307300559.h6U5xE470168@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300559.h6U5xE470168@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:25 -0700 Content-Transfer-Encoding: 7bit Tuesday, July 29, 2003, 10:59:14 PM, Pedro Roque Marques wrote: [...] > I confess that i'm not quite sure what your goal is... my assumption > is that you are concerned w/ the availiability of internet service, > which depends on several factors including the stability of router > software. Yes. See my message on "the goal". > While the latter is certainly a cause for concern, i would suggest > that you think of this equipment not as "Internet" infrastructure but > as equipment which is bought and operated by a telecomunications > company. Both views are valid, and both need to be kept in mind. We can't look at the routers in a SP network only within the contents of that given SP. They are also part of the Internet infrastructure, and we need to keep this picture in mind too. > Thus equipment caracteristics and failures are going to play an > important role in "Internet" availability, regardless of the root > cause of the problem. As such, "critical" needs to be defined from the > point of view of a service provider. If by "from the POV of a service provide" you mean within the context of its network only, then I would disagree. This would merely ignore the bigger picture. [part on impact on SW taken to a separate thread] > While people love to state that the "I in IETF stands for Internet" in > tend to be very sceptic of how realistic is this view. The Internet > doesn't exist in a vacum. The IETF itself doesn't have a vertical > approach in terms of considering all levels and elements used to > provide internet services. It has mostly an horizontal approach to > standardize the IP protocol suite regardless of the application. However, issues of the scale of the Internet should be kept in mind, and, frankly, I'm a bit surprised I find myself having to convince _routing_ folks on this... Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:31:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14666 for ; Thu, 31 Jul 2003 03:31:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tu-0001w0-Q5; Thu, 31 Jul 2003 03:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tO-0001pe-Gj for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14545 for ; Thu, 31 Jul 2003 03:30:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7tM-0000N1-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7tL-0000My-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:27 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7tL-000JCv-QP for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:27 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <66611356253.20030731002938@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: what would stay in BGP and what wouldn't In-Reply-To: <200307300013.h6U0DTk69365@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300013.h6U0DTk69365@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:38 -0700 Content-Transfer-Encoding: 7bit Pedro, Tuesday, July 29, 2003, 5:13:29 PM, Pedro Roque Marques wrote: > Alex Zinin writes: >> Pedro, >>>> IMO, attempts to pull out from MP-BGP what's already there would >>>> be a no-op. >>> I'm glad we agree on something :-) I'm just going to press you a >>> little bit more and request you to define "already there". >>> What is the criteria: WG document ? service provider deployements ? >>> a vendor implementation ? interoperable implementations ? >> Let's think about this. On the one hand we want to be reasonable and >> avoid recoding/redebugging things that are already widely agreed on >> and/or deployed. On the other hand we don't want to fall for the >> "oh, but I just coded it yesterday, and here's the draft" trick. How >> about something along these lines: "an IETF RFC, or a de-facto >> multi-vendor interoperable standard"? Other suggestions? > Alex, > What is published as RFCs doesn't reflect my definition of what is > "already there". what about the second part of the suggested definition? > In several areas, the best one can get to is WG document despite years > spent in the process, running code and customer deployments. Without > wanting to reopen unproductive discussions, this doesn't usually > reflect lack of quality of the proposals but "process blocks". > There is an a very high level of entropy which is created when > something stops being an 'idea' and becomes used in production > networks. > Can we expect the IESG to acknowledge that these documents should be > published as RFCs in order to facilitate interoperability ? I don't think the IESG could do that, because until the document is past the WG progress and the IETF Last Call, we can't state that there's a consensus on it. Chandra wrote: > So how do we reach consensus on a measure for 'risk' that is not > tainted by preferences based on what is profitable/convenient for > some given set of participants in any proposal/discussion for > a new 'item' that needs BGP. One of the suggestions that was being discussed in rtg-dir and ops-dir is to have the proponents of the protocol extension explain why it belongs in a particular routing protocol, and require consensus that putting it there is the right approach. > A new protocol would raise the same set of concerns. If there > is a reasonably clear requirement for a new protocol for a given > set of applications, I think it may be a good idea to just define > what those are and why there is a feeling that they do not belong > in BGP. Two points here: 1. If there is a feeling that a given set of applications needs a separate protocol, we should do so. 2. Note how your logic wrt "belong in BGP" is completely reversed compared to the suggestion I mentioned above. I.e., you suggest to explain why something does NOT belong in BGP, while the suggestion is to have people explain why it should go there in the first place. I personally believe (and it seems to be the consensus in the rtg-dir and ops-dir) that the latter makes much more sense. > Would that be easier than to debate about a future proof > 'new' protocol for 'all the other stuff'? It does not seem to me that one excludes the other. One of the attractive properties of the MP-BGP framework is that you can quickly distribute new types of information among the routers without having to specify and implement new protocol machinery. A generalized transport protocol would provide the same possibility. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:31:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14683 for ; Thu, 31 Jul 2003 03:31:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7uG-0002Dk-Ah for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:24 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7VOZc008517 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tu-0001w0-Q5; Thu, 31 Jul 2003 03:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tO-0001pe-Gj for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14545 for ; Thu, 31 Jul 2003 03:30:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7tM-0000N1-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:28 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7tL-0000My-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:27 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7tL-000JCv-QP for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:27 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <66611356253.20030731002938@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: what would stay in BGP and what wouldn't In-Reply-To: <200307300013.h6U0DTk69365@roque-bsd.juniper.net> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300013.h6U0DTk69365@roque-bsd.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:38 -0700 Content-Transfer-Encoding: 7bit Pedro, Tuesday, July 29, 2003, 5:13:29 PM, Pedro Roque Marques wrote: > Alex Zinin writes: >> Pedro, >>>> IMO, attempts to pull out from MP-BGP what's already there would >>>> be a no-op. >>> I'm glad we agree on something :-) I'm just going to press you a >>> little bit more and request you to define "already there". >>> What is the criteria: WG document ? service provider deployements ? >>> a vendor implementation ? interoperable implementations ? >> Let's think about this. On the one hand we want to be reasonable and >> avoid recoding/redebugging things that are already widely agreed on >> and/or deployed. On the other hand we don't want to fall for the >> "oh, but I just coded it yesterday, and here's the draft" trick. How >> about something along these lines: "an IETF RFC, or a de-facto >> multi-vendor interoperable standard"? Other suggestions? > Alex, > What is published as RFCs doesn't reflect my definition of what is > "already there". what about the second part of the suggested definition? > In several areas, the best one can get to is WG document despite years > spent in the process, running code and customer deployments. Without > wanting to reopen unproductive discussions, this doesn't usually > reflect lack of quality of the proposals but "process blocks". > There is an a very high level of entropy which is created when > something stops being an 'idea' and becomes used in production > networks. > Can we expect the IESG to acknowledge that these documents should be > published as RFCs in order to facilitate interoperability ? I don't think the IESG could do that, because until the document is past the WG progress and the IETF Last Call, we can't state that there's a consensus on it. Chandra wrote: > So how do we reach consensus on a measure for 'risk' that is not > tainted by preferences based on what is profitable/convenient for > some given set of participants in any proposal/discussion for > a new 'item' that needs BGP. One of the suggestions that was being discussed in rtg-dir and ops-dir is to have the proponents of the protocol extension explain why it belongs in a particular routing protocol, and require consensus that putting it there is the right approach. > A new protocol would raise the same set of concerns. If there > is a reasonably clear requirement for a new protocol for a given > set of applications, I think it may be a good idea to just define > what those are and why there is a feeling that they do not belong > in BGP. Two points here: 1. If there is a feeling that a given set of applications needs a separate protocol, we should do so. 2. Note how your logic wrt "belong in BGP" is completely reversed compared to the suggestion I mentioned above. I.e., you suggest to explain why something does NOT belong in BGP, while the suggestion is to have people explain why it should go there in the first place. I personally believe (and it seems to be the consensus in the rtg-dir and ops-dir) that the latter makes much more sense. > Would that be easier than to debate about a future proof > 'new' protocol for 'all the other stuff'? It does not seem to me that one excludes the other. One of the attractive properties of the MP-BGP framework is that you can quickly distribute new types of information among the routers without having to specify and implement new protocol machinery. A generalized transport protocol would provide the same possibility. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:31:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14698 for ; Thu, 31 Jul 2003 03:31:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tw-00020J-1y; Thu, 31 Jul 2003 03:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tV-0001pm-62 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14548 for ; Thu, 31 Jul 2003 03:30:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7tS-0000N7-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:34 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7tS-0000N4-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:34 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7tT-000JD5-6D for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:35 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <69611363293.20030731002945@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: impact on routing SW MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:45 -0700 Content-Transfer-Encoding: 7bit Pedro wrote: > Personally, i believe that this issue is being completly blown out of > proportion. It's ok to think so. The thing is however--sufficient number of people indicated their concerns, and this has been happening for years. Both sides need to talk and find common ground. > I've not seen any evidence to suggest that adding VPN > services, as we are discussing, has higher impact in routing software > stability than to add any other type of functionality. > I'd like to see people that believe otherwise put forward data that > corroborates that view. As far as routing SW stability is concerned, I think the concern is not that this very VPN service will blow BGP up, but about the increasing number of extensions we see in routing protocols, and while we can't stop routing code from changing at all (I don't think anyone disagrees that there are legitimate reasons to extend RPs), we should seriously look at what is coming in, whether this belongs in routing, and what we should do about this long term. Robert wrote: ... > If I have BGP free core, and I don't type by accident "router bgp ..." I > don't really see a good reason to buy routers which do not support BGP > just so I don't have it in the core. If I have IPv4 ASBRs and i am not > keen on running on them 2547 just don't configure vpnv4 AF there. I am > yet to see a one single case where new opaque to existing functionality > code presence if not configured or enabled by user caused any trouble to > anyone. I have to say it's not that simple. There are reasons (beyond required flash mem and DRAM size) for existence of feature sets in SW of at least one major vendor. There were also reasons why one major vendor had to maintain two code trains--one with 2547, and another where SPs asked to please "don't even think about touching BGP!" Eric wrote: Kurt>> What on earth makes us think that adding data to be distributed and Kurt>> processed will not have impact? Or make it worse? Could someone Kurt>> enlighten me? > > Let's look at two cases: > > 1. The new data is going to be distributed to the same set of nodes which > currently speak BGP for the purpose of maintaining their Internet routing > tables. > > Assuming that there is some necessity of distributing that new data, then > however one distributes it, those nodes are going to have to handle it. > Either they have enough capacity for it or they don't. Using a second > protocol does not reduce the distribution or the capacity load. > > 2. The new data is distributed to a different set of nodes than the ones > which currently speak BGP for the purpose of maintaining their Internet > routing tables. > > In this case, the use of BGP by the nodes which need the new data has no > impact on the nodes which use BGP to maintain their Internet routing > tables. > > So in neither case do I see what this terrifying impact is. Eric, I think the concern is (the SP folks will correct me if I'm wrong) that in both cases we have increased protocol and code complexity which doesn't help their stability regardless of whether a given SP uses the new features or not, and in case 1 there might be potential interference between the distributed systems because of resource contention at several levels: transport connections, queues, mem bufs, etc. Kurt wrote: > The first thing that > amazes me is that developers of various features _even want_ them to > use BGP I'd say there's difference in opinions in those circles too. However, as you correctly pointed out before--there's currently no alternative now, so the choice is kind of obvious. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:31:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14713 for ; Thu, 31 Jul 2003 03:31:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7uJ-0002Fb-O7 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7VRRY008597 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tw-00020J-1y; Thu, 31 Jul 2003 03:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tV-0001pm-62 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:37 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14548 for ; Thu, 31 Jul 2003 03:30:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7tS-0000N7-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:34 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7tS-0000N4-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:34 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7tT-000JD5-6D for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:35 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <69611363293.20030731002945@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: impact on routing SW MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:45 -0700 Content-Transfer-Encoding: 7bit Pedro wrote: > Personally, i believe that this issue is being completly blown out of > proportion. It's ok to think so. The thing is however--sufficient number of people indicated their concerns, and this has been happening for years. Both sides need to talk and find common ground. > I've not seen any evidence to suggest that adding VPN > services, as we are discussing, has higher impact in routing software > stability than to add any other type of functionality. > I'd like to see people that believe otherwise put forward data that > corroborates that view. As far as routing SW stability is concerned, I think the concern is not that this very VPN service will blow BGP up, but about the increasing number of extensions we see in routing protocols, and while we can't stop routing code from changing at all (I don't think anyone disagrees that there are legitimate reasons to extend RPs), we should seriously look at what is coming in, whether this belongs in routing, and what we should do about this long term. Robert wrote: ... > If I have BGP free core, and I don't type by accident "router bgp ..." I > don't really see a good reason to buy routers which do not support BGP > just so I don't have it in the core. If I have IPv4 ASBRs and i am not > keen on running on them 2547 just don't configure vpnv4 AF there. I am > yet to see a one single case where new opaque to existing functionality > code presence if not configured or enabled by user caused any trouble to > anyone. I have to say it's not that simple. There are reasons (beyond required flash mem and DRAM size) for existence of feature sets in SW of at least one major vendor. There were also reasons why one major vendor had to maintain two code trains--one with 2547, and another where SPs asked to please "don't even think about touching BGP!" Eric wrote: Kurt>> What on earth makes us think that adding data to be distributed and Kurt>> processed will not have impact? Or make it worse? Could someone Kurt>> enlighten me? > > Let's look at two cases: > > 1. The new data is going to be distributed to the same set of nodes which > currently speak BGP for the purpose of maintaining their Internet routing > tables. > > Assuming that there is some necessity of distributing that new data, then > however one distributes it, those nodes are going to have to handle it. > Either they have enough capacity for it or they don't. Using a second > protocol does not reduce the distribution or the capacity load. > > 2. The new data is distributed to a different set of nodes than the ones > which currently speak BGP for the purpose of maintaining their Internet > routing tables. > > In this case, the use of BGP by the nodes which need the new data has no > impact on the nodes which use BGP to maintain their Internet routing > tables. > > So in neither case do I see what this terrifying impact is. Eric, I think the concern is (the SP folks will correct me if I'm wrong) that in both cases we have increased protocol and code complexity which doesn't help their stability regardless of whether a given SP uses the new features or not, and in case 1 there might be potential interference between the distributed systems because of resource contention at several levels: transport connections, queues, mem bufs, etc. Kurt wrote: > The first thing that > amazes me is that developers of various features _even want_ them to > use BGP I'd say there's difference in opinions in those circles too. However, as you correctly pointed out before--there's currently no alternative now, so the choice is kind of obvious. -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:31:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14715 for ; Thu, 31 Jul 2003 03:31:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tw-00022N-Uz; Thu, 31 Jul 2003 03:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7td-0001py-6p for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14554 for ; Thu, 31 Jul 2003 03:30:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7ta-0000NJ-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7ta-0000NG-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:42 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7tb-000JDQ-9b for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:43 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <110611371345.20030731002953@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: operational feedback MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:53 -0700 Content-Transfer-Encoding: 7bit OK, in this thread, I'm going to drop proxy statements a la "I am being told...", and bring the main points of the operational feedback I've seen on the list. Regarding the role of the operational feedback in this discussion... Each problem we address here will have several dimensions. Examples are scalability, stability, backwards compatibility, security. Operational considerations represent another dimension. We have to recognize and clearly realize that. Just like SEC people give us clue on what does and does not make sense security-wise, OPS people give us their view of the world, and we ought to take it into consideration. At the end, they are the consumers of whatever we produce here. In order of appearance, grouped by the author, compacted: Randy said: > ...it is scarily not appropriate to characterize bgp as >> the architecture of a given city is good, communication is >> perfect and can scale Tulip Rasputin wrote: > BGP is critical for the Internet...and we must proceed with caution. > By adding more and more features we will only be bloating the code > size and the probability of introducing more and more bugs... the > fact remains that by doing this we make BGP more and more vulnerable > than what it already is. Kurt said: > The SPs that went to > the mike said they didn't see the benefit of overloading BGP with all > this. Or any other routing protocol. > From the SP POV this is about operational stability. Not about software > engineering. > What are the facts that we need to put everything into BGP? And where > do we stop? > I think one of the problems with BGP is that it has lured into this "as > there is nothing better, let's put it all in there". To be honest I > think that the reason that you are seeing customers being perfectly > happy to put various features into BGP is not that they don't see a > problem with it. They don't think there is an alternative. > I would say that the problem we are having now is the opposite. In > order to solve a software problem, people are trying to add things to a > protocol. Geoff said: > Keeping the network vaguely stable at it's current size > is taking increasingly large amounts of manual effort, and no, this > cannot scale indefinitely. > > There _are_ problems in BGP deployments, and overloading the running > instance of the protocol to carry more information related to various overlay > signalling applications does not in itself assist in improving the situation. > For me its a counter-intuitive action that increases the level of operational > reliance on a single element of the network. Dorian said: > I wonder how many other operators started out with > a strong stance against overloading of BGP, and after years ...just gave up > I certainly have. As an operator stability and optimal performance of > BGP implementations are of upmost concern for me, and there was a time > that many others appeared to feel the same. Afterall, MSDP didn't end > up in BGP and became a separate protocol because of that concern. > However, since then I've seen vendors continually ignore our concern > and input and overload other features into BGP. > So, is it really that operators all want to pile everything on BGP, or > is it that they don't see any alternatives? -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:31:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14743 for ; Thu, 31 Jul 2003 03:31:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7uM-0002HF-7i for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7VS3D008680 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:31:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tw-00022N-Uz; Thu, 31 Jul 2003 03:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7td-0001py-6p for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:30:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14554 for ; Thu, 31 Jul 2003 03:30:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7ta-0000NJ-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7ta-0000NG-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:30:42 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7tb-000JDQ-9b for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:30:43 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <110611371345.20030731002953@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: operational feedback MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:29:53 -0700 Content-Transfer-Encoding: 7bit OK, in this thread, I'm going to drop proxy statements a la "I am being told...", and bring the main points of the operational feedback I've seen on the list. Regarding the role of the operational feedback in this discussion... Each problem we address here will have several dimensions. Examples are scalability, stability, backwards compatibility, security. Operational considerations represent another dimension. We have to recognize and clearly realize that. Just like SEC people give us clue on what does and does not make sense security-wise, OPS people give us their view of the world, and we ought to take it into consideration. At the end, they are the consumers of whatever we produce here. In order of appearance, grouped by the author, compacted: Randy said: > ...it is scarily not appropriate to characterize bgp as >> the architecture of a given city is good, communication is >> perfect and can scale Tulip Rasputin wrote: > BGP is critical for the Internet...and we must proceed with caution. > By adding more and more features we will only be bloating the code > size and the probability of introducing more and more bugs... the > fact remains that by doing this we make BGP more and more vulnerable > than what it already is. Kurt said: > The SPs that went to > the mike said they didn't see the benefit of overloading BGP with all > this. Or any other routing protocol. > From the SP POV this is about operational stability. Not about software > engineering. > What are the facts that we need to put everything into BGP? And where > do we stop? > I think one of the problems with BGP is that it has lured into this "as > there is nothing better, let's put it all in there". To be honest I > think that the reason that you are seeing customers being perfectly > happy to put various features into BGP is not that they don't see a > problem with it. They don't think there is an alternative. > I would say that the problem we are having now is the opposite. In > order to solve a software problem, people are trying to add things to a > protocol. Geoff said: > Keeping the network vaguely stable at it's current size > is taking increasingly large amounts of manual effort, and no, this > cannot scale indefinitely. > > There _are_ problems in BGP deployments, and overloading the running > instance of the protocol to carry more information related to various overlay > signalling applications does not in itself assist in improving the situation. > For me its a counter-intuitive action that increases the level of operational > reliance on a single element of the network. Dorian said: > I wonder how many other operators started out with > a strong stance against overloading of BGP, and after years ...just gave up > I certainly have. As an operator stability and optimal performance of > BGP implementations are of upmost concern for me, and there was a time > that many others appeared to feel the same. Afterall, MSDP didn't end > up in BGP and became a separate protocol because of that concern. > However, since then I've seen vendors continually ignore our concern > and input and overload other features into BGP. > So, is it really that operators all want to pile everything on BGP, or > is it that they don't see any alternatives? -- Alex http://www.psg.com/~zinin/ _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:34:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14857 for ; Thu, 31 Jul 2003 03:34:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7wn-0002PX-BE; Thu, 31 Jul 2003 03:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7wH-0002P3-9Q for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:33:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14802 for ; Thu, 31 Jul 2003 03:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7wE-0000PO-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:33:26 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19i7wE-0000PL-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:33:26 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6V7XKFJ007670; Thu, 31 Jul 2003 09:33:21 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , routing-discussion@ietf.org To: erosen@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <200307302042.h6UKgRxc006696@rtp-core-2.cisco.com> Message-Id: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:33:10 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Kurt> We all know that BGP doesn't scale > > Yes, that must be what prevented the Internet from ever getting > very > large. ;-) BGP convergence is slow, due to a number of reasons, the size of the routing table being one of them. Attributes is another. Have you ever tried to deploy a VoIP network over several AS boundaries? A VoIP network that carries live, real paid for, regulated voice traffic? These are real operational problem faced by operators today. > Kurt> What on earth makes us think that adding data to be > distributed and > Kurt> processed will not have impact? Or make it worse? Could > someone > Kurt> enlighten me? > > Let's look at two cases: > > 1. The new data is going to be distributed to the same set of nodes > which > currently speak BGP for the purpose of maintaining their Internet > routing > tables. > > Assuming that there is some necessity of distributing that new > data, then > however one distributes it, those nodes are going to have to > handle it. > Either they have enough capacity for it or they don't. Using a > second > protocol does not reduce the distribution or the capacity load. No. But it will have impact on the other services carried in that protocol. What you are saying is that bGP is merely a data distribution protocol and that the receiving node will have to hand the data off to each process for handling and processing. If this really is what you want, why not make it even more generic than what BGP is today? I most certainly disagrees with the first approach. > > 2. The new data is distributed to a different set of nodes than > the ones > which currently speak BGP for the purpose of maintaining their > Internet > routing tables. > > In this case, the use of BGP by the nodes which need the new data > has no > impact on the nodes which use BGP to maintain their Internet > routing > tables. I am not arguing that we should not distribute this information. I am arguing that we should not mix it all up in one protocol. > Now for a particular kind of data, you may want to argue that BGP is > not the > appropriate mechanism for distributing that kind of data. But to > decide > that you need to look at the details of the particular proposal. So what are the limits in your opinion on what should not go into BGP? > > Kurt> The first thing that amazes me is that developers of various > features > Kurt> _even want_ them to use BGP, the second thing that amazes me > is that > Kurt> we haven't started to see a pattern. > > I guess not everyone agrees with you that > If we all agreed we would not have this debate :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyjGO6arNKXTPFCVEQLfFQCgyYcEWzB8QQKgun3nzDKCZroOBAEAoKpY GUB1OXv35Gdp63slxnPut7Fo =dobb -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:34:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14860 for ; Thu, 31 Jul 2003 03:34:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7x9-0002Te-DE for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:34:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7YN1p009515 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:34:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7wn-0002PX-BE; Thu, 31 Jul 2003 03:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7wH-0002P3-9Q for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:33:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14802 for ; Thu, 31 Jul 2003 03:33:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7wE-0000PO-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:33:26 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19i7wE-0000PL-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:33:26 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6V7XKFJ007670; Thu, 31 Jul 2003 09:33:21 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Randy Bush , routing-discussion@ietf.org To: erosen@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <200307302042.h6UKgRxc006696@rtp-core-2.cisco.com> Message-Id: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:33:10 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > Kurt> We all know that BGP doesn't scale > > Yes, that must be what prevented the Internet from ever getting > very > large. ;-) BGP convergence is slow, due to a number of reasons, the size of the routing table being one of them. Attributes is another. Have you ever tried to deploy a VoIP network over several AS boundaries? A VoIP network that carries live, real paid for, regulated voice traffic? These are real operational problem faced by operators today. > Kurt> What on earth makes us think that adding data to be > distributed and > Kurt> processed will not have impact? Or make it worse? Could > someone > Kurt> enlighten me? > > Let's look at two cases: > > 1. The new data is going to be distributed to the same set of nodes > which > currently speak BGP for the purpose of maintaining their Internet > routing > tables. > > Assuming that there is some necessity of distributing that new > data, then > however one distributes it, those nodes are going to have to > handle it. > Either they have enough capacity for it or they don't. Using a > second > protocol does not reduce the distribution or the capacity load. No. But it will have impact on the other services carried in that protocol. What you are saying is that bGP is merely a data distribution protocol and that the receiving node will have to hand the data off to each process for handling and processing. If this really is what you want, why not make it even more generic than what BGP is today? I most certainly disagrees with the first approach. > > 2. The new data is distributed to a different set of nodes than > the ones > which currently speak BGP for the purpose of maintaining their > Internet > routing tables. > > In this case, the use of BGP by the nodes which need the new data > has no > impact on the nodes which use BGP to maintain their Internet > routing > tables. I am not arguing that we should not distribute this information. I am arguing that we should not mix it all up in one protocol. > Now for a particular kind of data, you may want to argue that BGP is > not the > appropriate mechanism for distributing that kind of data. But to > decide > that you need to look at the details of the particular proposal. So what are the limits in your opinion on what should not go into BGP? > > Kurt> The first thing that amazes me is that developers of various > features > Kurt> _even want_ them to use BGP, the second thing that amazes me > is that > Kurt> we haven't started to see a pattern. > > I guess not everyone agrees with you that > If we all agreed we would not have this debate :-) - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyjGO6arNKXTPFCVEQLfFQCgyYcEWzB8QQKgun3nzDKCZroOBAEAoKpY GUB1OXv35Gdp63slxnPut7Fo =dobb -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 03:35:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14927 for ; Thu, 31 Jul 2003 03:35:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7xl-0002ZK-Lb; Thu, 31 Jul 2003 03:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7xk-0002XJ-5c for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14889 for ; Thu, 31 Jul 2003 03:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7xh-0000QI-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:34:57 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19i7xh-0000QF-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:34:57 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6V7YxFJ007673; Thu, 31 Jul 2003 09:35:01 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Geoff Huston , routing-discussion@ietf.org To: erosen@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <200307302122.h6ULMUxc011134@rtp-core-2.cisco.com> Message-Id: <781B40E5-C329-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:34:50 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Geoff> There _are_ problems in BGP deployments, and overloading the > running > Geoff> instance of the protocol to carry more information related to > various > Geoff> overlay signalling applications does not in itself > assist in > Geoff> improving the situation. For me its a counter-intuitive > action that > Geoff> increases the level of operational reliance on a single > element of > Geoff> the network. > > This is all true, but it seems like a deployment issue rather > than a > protocol issue. The deployment problems are symptoms of the protocol problems. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyjGnqarNKXTPFCVEQLZxgCgnukRsgf9RNfYBPlBSbjhTHIJvW0AoNtx Fd15n6leZBAf34MMR1Zq99KQ =Mrqu -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 03:35:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14930 for ; Thu, 31 Jul 2003 03:35:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7y7-0002du-8t for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:35:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7ZNYP010126 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:35:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7xl-0002ZK-Lb; Thu, 31 Jul 2003 03:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7xk-0002XJ-5c for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14889 for ; Thu, 31 Jul 2003 03:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7xh-0000QI-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:34:57 -0400 Received: from laptop2.kurtis.autonomica.se ([192.71.80.74] helo=adsl-2-173.aland.net) by ietf-mx with esmtp (Exim 4.12) id 19i7xh-0000QF-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:34:57 -0400 Received: from kurtis.pp.se (localhost [127.0.0.1]) by adsl-2-173.aland.net (8.12.9/8.10.2) with ESMTP id h6V7YxFJ007673; Thu, 31 Jul 2003 09:35:01 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna Content-Type: text/plain; charset=US-ASCII; format=fixed Mime-Version: 1.0 (Apple Message framework v552) Cc: Geoff Huston , routing-discussion@ietf.org To: erosen@cisco.com From: Kurt Erik Lindqvist In-Reply-To: <200307302122.h6ULMUxc011134@rtp-core-2.cisco.com> Message-Id: <781B40E5-C329-11D7-958B-000393A638B2@kurtis.pp.se> Content-Transfer-Encoding: 7bit X-Pgp-Rfc2646-Fix: 1 X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:34:50 +0200 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Geoff> There _are_ problems in BGP deployments, and overloading the > running > Geoff> instance of the protocol to carry more information related to > various > Geoff> overlay signalling applications does not in itself > assist in > Geoff> improving the situation. For me its a counter-intuitive > action that > Geoff> increases the level of operational reliance on a single > element of > Geoff> the network. > > This is all true, but it seems like a deployment issue rather > than a > protocol issue. The deployment problems are symptoms of the protocol problems. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.2 iQA/AwUBPyjGnqarNKXTPFCVEQLZxgCgnukRsgf9RNfYBPlBSbjhTHIJvW0AoNtx Fd15n6leZBAf34MMR1Zq99KQ =Mrqu -----END PGP SIGNATURE----- _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 04:18:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14557 for ; Thu, 31 Jul 2003 03:30:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7tH-0001pJ-C3 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:30:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V7UNi7006966 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 03:30:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7sw-0001ig-6z; Thu, 31 Jul 2003 03:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i7rw-0001a7-KW for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 03:29:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14477 for ; Thu, 31 Jul 2003 03:28:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i7ru-0000Lz-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:58 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19i7rt-0000Lw-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 03:28:57 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19i7ru-000J4e-OG for routing-discussion@ietf.org; Thu, 31 Jul 2003 07:28:58 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <116611268077.20030731002810@psg.com> To: routing-discussion@ietf.org Subject: RP overloading: what is "overloading" In-Reply-To: References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 00:28:10 -0700 Content-Transfer-Encoding: 7bit John, Tuesday, July 29, 2003, 6:19:25 PM, John G. Scudder wrote: [...] >>> The way I see it, the major concern is overloading of BGP, which is >> > part of Internet-critical infrastructure, with non-routing >> > functionality. > I would be interested to know if you can elaborate on this without > resort to the ambiguous term "non-routing". Sure. The discussion started with two VPN-related drafts (they had different names then): draft-ietf-l3vpn-bgpvpn-auto-00.txt and draft-ietf-l2vpn-vpls-bgp-00.txt At the IETF meeting in Vienna, we had some more BGP-based proposals, that are not related to distribution of {prefix, next-hop,...} tuples. If wanted to formalize when I see concerns being raised, I would probably use the results of the discussion we had on the RTG directorate: There are types of information that are fair to distribute in routing protocols: a) information required to calculate the routing tables b) route tagging, administrative, and policy-related information c) routing security-related information d) information closely related to routing, especially when synchronization with routing information is needed Others would be considered non-routing. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 04:38:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16366 for ; Thu, 31 Jul 2003 04:38:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8xC-0005Nh-Lw for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 04:38:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V8cUZB020679 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 04:38:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8wk-0005KJ-3P; Thu, 31 Jul 2003 04:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8wI-0005EW-4q for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 04:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16325 for ; Thu, 31 Jul 2003 04:37:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i8wF-0000ob-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:37:31 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19i8wE-0000oL-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:37:30 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6V8axpp023043; Thu, 31 Jul 2003 01:36:59 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV08341; Thu, 31 Jul 2003 01:31:50 -0700 (PDT) Message-ID: <3F28D527.CFC4C9D9@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: routing-discussion@ietf.org Subject: Re: RP overloading: what is "overloading" References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> <116611268077.20030731002810@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:36:55 +0200 Content-Transfer-Encoding: 7bit Alex, Last attempt to switch this tread to the right tracks ... > If wanted to formalize when I see concerns being raised, I would > probably use the results of the discussion we had on the RTG > directorate: > > There are types of information that are fair to distribute in > routing protocols: > > a) information required to calculate the routing tables > > b) route tagging, administrative, and policy-related information > > c) routing security-related information > > d) information closely related to routing, especially when > synchronization with routing information is needed > > Others would be considered non-routing. IMHO the best thing that can be done today by RTG directorate/ADs/IETF is to mandate the clear separation of so called "non-routing" information being distributed into their own AFI/SAFIs. That for one will long term provide easy migration into a new transport (when such is available & deployed) as well kind of "force" better software engineering and code architecture. It could be said that it is recommended by each implementation to have such a new AFI/SAFIs separated into their own RIBs, their own maintenance & operation routines given AFI/SAFI specific and be demultiplexed by general BGP inbound process based on the AFI/SAFI values very early. Looking realistically otherwise what we will see soon would an explosion of extended/flexible communities or new attribiutes use under current AFI/SAFIs which may in fact have very negative impact on current Internet stability. Cheers, R. PS. > > If I have BGP free core, and I don't type by accident "router bgp ..." I > > don't really see a good reason to buy routers which do not support BGP > > just so I don't have it in the core. If I have IPv4 ASBRs and i am not > > keen on running on them 2547 just don't configure vpnv4 AF there. I am > > yet to see a one single case where new opaque to existing functionality > > code presence if not configured or enabled by user caused any trouble to > > anyone. > > I have to say it's not that simple. > > There are reasons (beyond required flash mem and DRAM size) for > existence of feature sets in SW of at least one major vendor. There > were also reasons why one major vendor had to maintain two code > trains--one with 2547, and another where SPs asked to please "don't > even think about touching BGP!" Adding support for MP-BGP required code modifications. And that has nothing to do with introduction of 2547. For vendors starting later they just provided MP-BGP support since day one. Unfortunately one major vendor did not have a crstal ball few years back to see the future and desing the entire code already fitting 2010 requirements. In other words as I think Yakov alreay mentioned in Vienna what is happening to BGP is just a regular protocol evolution and improvemnt. I don't see anything wrong with this. In fact I would highly encourage constructive discussion (piece started above reg AFI/SAFI separation) what can be done to make the protocol evolution smooth and least painful for operators. That is what I would call "Engineering" meaning of "E". What on the other hand I see to be the real goal of this discussion is to do revolution. While revolution leaders get much more glory and reputation if revolution suceeds history shows that when revolutions fail they quickly also become part of the dark sides of the history. Also the idea of centrally deciding what is good and what is bad should to at least two of us remind something :). _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 04:45:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16588 for ; Thu, 31 Jul 2003 04:45:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i93V-0005YC-ND; Thu, 31 Jul 2003 04:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i92f-0005XN-Sw for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 04:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16498 for ; Thu, 31 Jul 2003 04:44:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i92c-0000r7-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:44:06 -0400 Received: from ims21.stu.nus.edu.sg ([137.132.14.228]) by ietf-mx with esmtp (Exim 4.12) id 19i92c-0000qr-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:44:06 -0400 Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 16:43:58 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: Fuzzy Routing Message-ID: <94B4D36209DCF44587E799AC1CBC5B4145EDDA@MBXSRV26.stu.nus.edu.sg> Thread-Topic: RP overloading: what is "overloading" Thread-Index: AcNXPyZiRWfPrkAqQ3i8OkbB2UMpEQAAFqWJ From: "Marwaha Shivanajay" To: X-OriginalArrivalTime: 31 Jul 2003 08:43:59.0027 (UTC) FILETIME=[E2735030:01C3573F] Content-Transfer-Encoding: base64 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 16:43:58 +0800 Content-Transfer-Encoding: base64 SGkgYWxsLA0KIA0KSSBhbSBhbiBNLkVuZy4gc3R1ZGVudCBhbmQgbXkgcHJvamVjdCBpcyBvbiBG dXp6eSBSb3V0aW5nLiBJIHdhbnQgdG8ga25vdyBpZiBhbnlvbmUgZWxzZSBpcyB3b3JraW5nIGlu IHRoaXMgYXJlYS4gQ2FuIHlvdSBhbHNvIGtpbmRseSByZWZlciBtZSB0byBzb21lIHBhcGVycyBv biB0aGlzLg0KIA0KVGhhbmtzLA0KU2hpdmFuYWpheQ0K _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 04:45:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16603 for ; Thu, 31 Jul 2003 04:45:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i93w-0005f4-IG for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 04:45:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6V8jSEN021691 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 04:45:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i93V-0005YC-ND; Thu, 31 Jul 2003 04:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i92f-0005XN-Sw for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 04:44:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16498 for ; Thu, 31 Jul 2003 04:44:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i92c-0000r7-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:44:06 -0400 Received: from ims21.stu.nus.edu.sg ([137.132.14.228]) by ietf-mx with esmtp (Exim 4.12) id 19i92c-0000qr-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:44:06 -0400 Received: from mbxsrv26.stu.nus.edu.sg ([137.132.14.236]) by ims21.stu.nus.edu.sg with Microsoft SMTPSVC(5.0.2195.5329); Thu, 31 Jul 2003 16:43:58 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: Fuzzy Routing Message-ID: <94B4D36209DCF44587E799AC1CBC5B4145EDDA@MBXSRV26.stu.nus.edu.sg> Thread-Topic: RP overloading: what is "overloading" Thread-Index: AcNXPyZiRWfPrkAqQ3i8OkbB2UMpEQAAFqWJ From: "Marwaha Shivanajay" To: X-OriginalArrivalTime: 31 Jul 2003 08:43:59.0027 (UTC) FILETIME=[E2735030:01C3573F] Content-Transfer-Encoding: base64 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 16:43:58 +0800 Content-Transfer-Encoding: base64 SGkgYWxsLA0KIA0KSSBhbSBhbiBNLkVuZy4gc3R1ZGVudCBhbmQgbXkgcHJvamVjdCBpcyBvbiBG dXp6eSBSb3V0aW5nLiBJIHdhbnQgdG8ga25vdyBpZiBhbnlvbmUgZWxzZSBpcyB3b3JraW5nIGlu IHRoaXMgYXJlYS4gQ2FuIHlvdSBhbHNvIGtpbmRseSByZWZlciBtZSB0byBzb21lIHBhcGVycyBv biB0aGlzLg0KIA0KVGhhbmtzLA0KU2hpdmFuYWpheQ0K _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 05:24:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16367 for ; Thu, 31 Jul 2003 04:38:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8wk-0005KJ-3P; Thu, 31 Jul 2003 04:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19i8wI-0005EW-4q for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 04:37:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16325 for ; Thu, 31 Jul 2003 04:37:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19i8wF-0000ob-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:37:31 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19i8wE-0000oL-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 04:37:30 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6V8axpp023043; Thu, 31 Jul 2003 01:36:59 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV08341; Thu, 31 Jul 2003 01:31:50 -0700 (PDT) Message-ID: <3F28D527.CFC4C9D9@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alex Zinin CC: routing-discussion@ietf.org Subject: Re: RP overloading: what is "overloading" References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> <116611268077.20030731002810@psg.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:36:55 +0200 Content-Transfer-Encoding: 7bit Alex, Last attempt to switch this tread to the right tracks ... > If wanted to formalize when I see concerns being raised, I would > probably use the results of the discussion we had on the RTG > directorate: > > There are types of information that are fair to distribute in > routing protocols: > > a) information required to calculate the routing tables > > b) route tagging, administrative, and policy-related information > > c) routing security-related information > > d) information closely related to routing, especially when > synchronization with routing information is needed > > Others would be considered non-routing. IMHO the best thing that can be done today by RTG directorate/ADs/IETF is to mandate the clear separation of so called "non-routing" information being distributed into their own AFI/SAFIs. That for one will long term provide easy migration into a new transport (when such is available & deployed) as well kind of "force" better software engineering and code architecture. It could be said that it is recommended by each implementation to have such a new AFI/SAFIs separated into their own RIBs, their own maintenance & operation routines given AFI/SAFI specific and be demultiplexed by general BGP inbound process based on the AFI/SAFI values very early. Looking realistically otherwise what we will see soon would an explosion of extended/flexible communities or new attribiutes use under current AFI/SAFIs which may in fact have very negative impact on current Internet stability. Cheers, R. PS. > > If I have BGP free core, and I don't type by accident "router bgp ..." I > > don't really see a good reason to buy routers which do not support BGP > > just so I don't have it in the core. If I have IPv4 ASBRs and i am not > > keen on running on them 2547 just don't configure vpnv4 AF there. I am > > yet to see a one single case where new opaque to existing functionality > > code presence if not configured or enabled by user caused any trouble to > > anyone. > > I have to say it's not that simple. > > There are reasons (beyond required flash mem and DRAM size) for > existence of feature sets in SW of at least one major vendor. There > were also reasons why one major vendor had to maintain two code > trains--one with 2547, and another where SPs asked to please "don't > even think about touching BGP!" Adding support for MP-BGP required code modifications. And that has nothing to do with introduction of 2547. For vendors starting later they just provided MP-BGP support since day one. Unfortunately one major vendor did not have a crstal ball few years back to see the future and desing the entire code already fitting 2010 requirements. In other words as I think Yakov alreay mentioned in Vienna what is happening to BGP is just a regular protocol evolution and improvemnt. I don't see anything wrong with this. In fact I would highly encourage constructive discussion (piece started above reg AFI/SAFI separation) what can be done to make the protocol evolution smooth and least painful for operators. That is what I would call "Engineering" meaning of "E". What on the other hand I see to be the real goal of this discussion is to do revolution. While revolution leaders get much more glory and reputation if revolution suceeds history shows that when revolutions fail they quickly also become part of the dark sides of the history. Also the idea of centrally deciding what is good and what is bad should to at least two of us remind something :). _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 06:18:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19093 for ; Thu, 31 Jul 2003 06:18:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAVV-0000Zs-HN; Thu, 31 Jul 2003 06:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAV8-0000ZP-TK for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 06:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19064 for ; Thu, 31 Jul 2003 06:17:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iAV5-0001ib-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 06:17:35 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19iAV4-0001i6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 06:17:34 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6VAH5u86586; Thu, 31 Jul 2003 03:17:05 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6VAH5F73550; Thu, 31 Jul 2003 03:17:05 -0700 (PDT) (envelope-from roque) Message-Id: <200307311017.h6VAH5F73550@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: RP overloading: what is "overloading" In-Reply-To: <116611268077.20030731002810@psg.com> References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> <116611268077.20030731002810@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 03:17:05 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > Sure. The discussion started with two VPN-related drafts (they had > different names then): > draft-ietf-l3vpn-bgpvpn-auto-00.txt and > draft-ietf-l2vpn-vpls-bgp-00.txt > At the IETF meeting in Vienna, we had some more BGP-based proposals, > that are not related to distribution of {prefix, next-hop,...} > tuples. draft-ietf-l2vpn-vpls-bgp-00.txt is about distribution of {prefix, next-hop} tuples at least as far as BGP is concerned. It uses the same path selection rules than ipv4-unicast and the same next-hop resolution rules. The forwarding engines get to interpret the information differently although. In fact, the forwarding engine control code changes to support such application are much more extensive than routing ones, and that is not going to change regardless of what control protocol is used. Well, i guess you can make it worse by requiring a new control protocol to be developed for this application... and requiring network ops people to learn a new protocol, which btw is a much higher cost than control protocol developement. Doesn't implementing vpls raise the possibility of introducing regressions in the code ? It certainly does. That doesn't make "don't implement vpls" a productive discussion and doesn't mean that implementing it via a different control protocol is going to be any less harmful to system stability. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 06:18:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19095 for ; Thu, 31 Jul 2003 06:18:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAVy-0000dn-6c for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 06:18:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VAIUSP002461 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 06:18:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAVV-0000Zs-HN; Thu, 31 Jul 2003 06:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iAV8-0000ZP-TK for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 06:17:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19064 for ; Thu, 31 Jul 2003 06:17:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iAV5-0001ib-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 06:17:35 -0400 Received: from natint.juniper.net ([207.17.136.129] helo=merlot.juniper.net) by ietf-mx with esmtp (Exim 4.12) id 19iAV4-0001i6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 06:17:34 -0400 Received: from roque-bsd.juniper.net (roque-bsd.juniper.net [172.17.12.183]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id h6VAH5u86586; Thu, 31 Jul 2003 03:17:05 -0700 (PDT) (envelope-from roque@juniper.net) Received: (from roque@localhost) by roque-bsd.juniper.net (8.11.6/8.9.3) id h6VAH5F73550; Thu, 31 Jul 2003 03:17:05 -0700 (PDT) (envelope-from roque) Message-Id: <200307311017.h6VAH5F73550@roque-bsd.juniper.net> From: Pedro Roque Marques MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Alex Zinin Cc: routing-discussion@ietf.org Subject: RP overloading: what is "overloading" In-Reply-To: <116611268077.20030731002810@psg.com> References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> <116611268077.20030731002810@psg.com> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 03:17:05 -0700 (PDT) Content-Transfer-Encoding: 7bit Alex Zinin writes: > Sure. The discussion started with two VPN-related drafts (they had > different names then): > draft-ietf-l3vpn-bgpvpn-auto-00.txt and > draft-ietf-l2vpn-vpls-bgp-00.txt > At the IETF meeting in Vienna, we had some more BGP-based proposals, > that are not related to distribution of {prefix, next-hop,...} > tuples. draft-ietf-l2vpn-vpls-bgp-00.txt is about distribution of {prefix, next-hop} tuples at least as far as BGP is concerned. It uses the same path selection rules than ipv4-unicast and the same next-hop resolution rules. The forwarding engines get to interpret the information differently although. In fact, the forwarding engine control code changes to support such application are much more extensive than routing ones, and that is not going to change regardless of what control protocol is used. Well, i guess you can make it worse by requiring a new control protocol to be developed for this application... and requiring network ops people to learn a new protocol, which btw is a much higher cost than control protocol developement. Doesn't implementing vpls raise the possibility of introducing regressions in the code ? It certainly does. That doesn't make "don't implement vpls" a productive discussion and doesn't mean that implementing it via a different control protocol is going to be any less harmful to system stability. Pedro. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 08:36:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22715 for ; Thu, 31 Jul 2003 08:36:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCe5-0005wG-Rn; Thu, 31 Jul 2003 08:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCdb-0005va-Iu for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 08:34:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22675 for ; Thu, 31 Jul 2003 08:34:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iCda-00035h-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:34:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iCdZ-00035F-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:34:29 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 05:33:59 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VCXuXw010156; Thu, 31 Jul 2003 08:33:56 -0400 (EDT) Received: from dhcp-64-102-60-208.cisco.com (dhcp-64-102-60-208.cisco.com [64.102.60.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA04022; Thu, 31 Jul 2003 08:33:56 -0400 (EDT) From: Russ White Reply-To: Russ White To: Kurt Erik Lindqvist cc: erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> Message-ID: References: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 08:34:51 -0400 (EDT) > > Kurt> What on earth makes us think that adding data to be distributed > > and processed will not have impact? Or make it worse? Could someone > > enlighten me? > > Eric> Let's look at two cases: > > > > 1. The new data is going to be distributed to the same set of nodes > > which currently speak BGP for the purpose of maintaining their Internet > > routing tables. > > > > Assuming that there is some necessity of distributing that new data, > > then however one distributes it, those nodes are going to have to > > handle it. Either they have enough capacity for it or they don't. > > Using a second protocol does not reduce the distribution or the > > capacity load. > > No. But it will have impact on the other services carried in that > protocol. What you are saying is that bGP is merely a data distribution > protocol and that the receiving node will have to hand the data off to > each process for handling and processing. If this really is what you > want, why not make it even more generic than what BGP is today? I most > certainly disagrees with the first approach. How is carrying it in another protocol going to keep the new data being carried and processed from impacting the old data being carried and processed? It's not. Unless you're going to argue that adding an OSPF process to a router running BGP doesn't impact BGP processing in any way. Given infinite bandwidth, memory, and processing, you can have two protocols running on the same machine that do not impact each other. When you're willing to buy links with infinite bandwidth, and machines with infinite processing and memory, let us know. In the mean time, it's a not a matter of "will this impact that," because it will. It's a matter of best deciding how to share the resources which actually exist. We need to examine each case of what to carry inside BGP independantly. The basic problem is that in each case, the ones who want the new information to be carried without waiting on a new working group to form up, and a new protocol to be deployed, will always claim it is critical, while those who are don't want it, will consider it bloat. Weeds are always just flowers in the wrong part of the yard, after all. My general take: It might be nice to have a new protocol to carry stuff around between routers in. Especially if that stuff doesn't relate to routing. My questions, though, are: -- How long will it wait to develop, deploy, and debug, the stuff protocol? -- Will the providers stop asking for new features that require carrying non routing information between routers until the stuff protocol is fully deployed? I think the answers to these two questions make it apparent that it's useful to create such a stuff protocol, but we need to think realisitically about: -- What do we mean by "non routing stuff?" -- What are we going to do with "non routing stuff" in the meantime? -- What do we do when some mission critical app rolls out on the stuff protocol, and people start calling for us not to change it any more, since it will introduce stuff instability, and thus we need a "stuff 2" protocol to break out the "new stuff" from the "old stuff?" -- Should, if we do a stuff protocol, go back and rip the "nonrouting stuff" out of BGP, if we can actually determine what that is, and put it in the stuff protocol? So, I'm undecided on the issue. I think there are advantages and disadvantages to both ways of doing things--I hate the mess that HTTP has become, but I also don't want to see us with stuff 2, and stuff 3, and stuff 4--and any argument leveled against putting x in BGP can also, probably, be used as an argument against putting something new in the stuff protocol, once it's developed and deployed. Further, I also see Eric's point that all processes on a device interact, no matter whether we like it or not, and deploying a new protocol is probably just about as risky as touching old, well known code (which is going to be touched to fix things, and add things, anyway). Maybe it's worth splitting off a bof for some time just to talk about this, and come back with some sort of an answer on these sorts of questions? So we'd have some concept of the practicality of designing and depoying a "stuff protocol," and some concept of the risks involved? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 08:36:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22717 for ; Thu, 31 Jul 2003 08:36:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCed-00062A-Jy for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 08:35:35 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VCZZUl023188 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 08:35:35 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCe5-0005wG-Rn; Thu, 31 Jul 2003 08:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCdb-0005va-Iu for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 08:34:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22675 for ; Thu, 31 Jul 2003 08:34:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iCda-00035h-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:34:30 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iCdZ-00035F-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:34:29 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 05:33:59 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VCXuXw010156; Thu, 31 Jul 2003 08:33:56 -0400 (EDT) Received: from dhcp-64-102-60-208.cisco.com (dhcp-64-102-60-208.cisco.com [64.102.60.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA04022; Thu, 31 Jul 2003 08:33:56 -0400 (EDT) From: Russ White Reply-To: Russ White To: Kurt Erik Lindqvist cc: erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> Message-ID: References: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 08:34:51 -0400 (EDT) > > Kurt> What on earth makes us think that adding data to be distributed > > and processed will not have impact? Or make it worse? Could someone > > enlighten me? > > Eric> Let's look at two cases: > > > > 1. The new data is going to be distributed to the same set of nodes > > which currently speak BGP for the purpose of maintaining their Internet > > routing tables. > > > > Assuming that there is some necessity of distributing that new data, > > then however one distributes it, those nodes are going to have to > > handle it. Either they have enough capacity for it or they don't. > > Using a second protocol does not reduce the distribution or the > > capacity load. > > No. But it will have impact on the other services carried in that > protocol. What you are saying is that bGP is merely a data distribution > protocol and that the receiving node will have to hand the data off to > each process for handling and processing. If this really is what you > want, why not make it even more generic than what BGP is today? I most > certainly disagrees with the first approach. How is carrying it in another protocol going to keep the new data being carried and processed from impacting the old data being carried and processed? It's not. Unless you're going to argue that adding an OSPF process to a router running BGP doesn't impact BGP processing in any way. Given infinite bandwidth, memory, and processing, you can have two protocols running on the same machine that do not impact each other. When you're willing to buy links with infinite bandwidth, and machines with infinite processing and memory, let us know. In the mean time, it's a not a matter of "will this impact that," because it will. It's a matter of best deciding how to share the resources which actually exist. We need to examine each case of what to carry inside BGP independantly. The basic problem is that in each case, the ones who want the new information to be carried without waiting on a new working group to form up, and a new protocol to be deployed, will always claim it is critical, while those who are don't want it, will consider it bloat. Weeds are always just flowers in the wrong part of the yard, after all. My general take: It might be nice to have a new protocol to carry stuff around between routers in. Especially if that stuff doesn't relate to routing. My questions, though, are: -- How long will it wait to develop, deploy, and debug, the stuff protocol? -- Will the providers stop asking for new features that require carrying non routing information between routers until the stuff protocol is fully deployed? I think the answers to these two questions make it apparent that it's useful to create such a stuff protocol, but we need to think realisitically about: -- What do we mean by "non routing stuff?" -- What are we going to do with "non routing stuff" in the meantime? -- What do we do when some mission critical app rolls out on the stuff protocol, and people start calling for us not to change it any more, since it will introduce stuff instability, and thus we need a "stuff 2" protocol to break out the "new stuff" from the "old stuff?" -- Should, if we do a stuff protocol, go back and rip the "nonrouting stuff" out of BGP, if we can actually determine what that is, and put it in the stuff protocol? So, I'm undecided on the issue. I think there are advantages and disadvantages to both ways of doing things--I hate the mess that HTTP has become, but I also don't want to see us with stuff 2, and stuff 3, and stuff 4--and any argument leveled against putting x in BGP can also, probably, be used as an argument against putting something new in the stuff protocol, once it's developed and deployed. Further, I also see Eric's point that all processes on a device interact, no matter whether we like it or not, and deploying a new protocol is probably just about as risky as touching old, well known code (which is going to be touched to fix things, and add things, anyway). Maybe it's worth splitting off a bof for some time just to talk about this, and come back with some sort of an answer on these sorts of questions? So we'd have some concept of the practicality of designing and depoying a "stuff protocol," and some concept of the risks involved? :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 08:43:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23055 for ; Thu, 31 Jul 2003 08:43:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iCmA-0006kR-QY for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 08:43:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VChMGL025894 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 08:43:22 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iClq-0006aI-6l; Thu, 31 Jul 2003 08:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iClT-0006Z1-Sb for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 08:42:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22992 for ; Thu, 31 Jul 2003 08:42:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iClS-0003BT-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:42:38 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iClS-0003BE-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:42:38 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VCg4xc022110; Thu, 31 Jul 2003 08:42:05 -0400 (EDT) Received: from dhcp-64-102-60-208.cisco.com (dhcp-64-102-60-208.cisco.com [64.102.60.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA04474; Thu, 31 Jul 2003 08:42:04 -0400 (EDT) From: Russ White Reply-To: Russ White To: Kurt Erik Lindqvist cc: erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Message-ID: References: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 08:42:59 -0400 (EDT) > How is carrying it in another protocol going to keep the new data being > carried and processed from impacting the old data being carried and > processed? It's not. Unless you're going to argue that adding an OSPF > process to a router running BGP doesn't impact BGP processing in any way. > > Given infinite bandwidth, memory, and processing, you can have two > protocols running on the same machine that do not impact each other. When > you're willing to buy links with infinite bandwidth, and machines with > infinite processing and memory, let us know. In the mean time, it's a not > a matter of "will this impact that," because it will. It's a matter of > best deciding how to share the resources which actually exist. BTW--this isn't meant to be mean, just a realistic assessment of the 'way things are.' > I think the answers to these two questions make it apparent that it's > useful to create such a stuff protocol, but we need to think > realisitically about: It _might_ be useful. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 09:29:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23054 for ; Thu, 31 Jul 2003 08:43:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iClq-0006aI-6l; Thu, 31 Jul 2003 08:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iClT-0006Z1-Sb for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 08:42:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22992 for ; Thu, 31 Jul 2003 08:42:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iClS-0003BT-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:42:38 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iClS-0003BE-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 08:42:38 -0400 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VCg4xc022110; Thu, 31 Jul 2003 08:42:05 -0400 (EDT) Received: from dhcp-64-102-60-208.cisco.com (dhcp-64-102-60-208.cisco.com [64.102.60.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA04474; Thu, 31 Jul 2003 08:42:04 -0400 (EDT) From: Russ White Reply-To: Russ White To: Kurt Erik Lindqvist cc: erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-Reply-To: Message-ID: References: <3C315532-C329-11D7-958B-000393A638B2@kurtis.pp.se> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 08:42:59 -0400 (EDT) > How is carrying it in another protocol going to keep the new data being > carried and processed from impacting the old data being carried and > processed? It's not. Unless you're going to argue that adding an OSPF > process to a router running BGP doesn't impact BGP processing in any way. > > Given infinite bandwidth, memory, and processing, you can have two > protocols running on the same machine that do not impact each other. When > you're willing to buy links with infinite bandwidth, and machines with > infinite processing and memory, let us know. In the mean time, it's a not > a matter of "will this impact that," because it will. It's a matter of > best deciding how to share the resources which actually exist. BTW--this isn't meant to be mean, just a realistic assessment of the 'way things are.' > I think the answers to these two questions make it apparent that it's > useful to create such a stuff protocol, but we need to think > realisitically about: It _might_ be useful. :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 09:57:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25923 for ; Thu, 31 Jul 2003 09:57:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDvs-00012K-3W for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 09:57:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VDvSFN003973 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 09:57:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDvR-0000wR-UO; Thu, 31 Jul 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDuf-0000tf-BX for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 09:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25831 for ; Thu, 31 Jul 2003 09:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDud-0003wq-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 09:56:11 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iDuc-0003wX-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 09:56:10 -0400 Message-ID: From: Jeff Parker To: "'Russ White'" , Kurt Erik Lindqvist Cc: erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:55:26 -0400 > How is carrying it in another protocol going to keep the new > data being carried and processed from impacting the old data > being carried and processed? Russ - I haven't heard concern about the amount of raw data a box is carrying. I have heard concerns about Implementation Complexity and Protocol Convergence. I agree that producing a new protocol with the maturity and utility of BGP or IS-IS is difficult. But at some point we hit the salami principle: it isn't adding this slice or that slice that gets you, but soon you have a sandwich that only Dagwood Bumstead can handle.* At some point, it is time to start a new sandwich. - jeff parker * Kurt - Appologies for this grossly US reference. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 09:57:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25922 for ; Thu, 31 Jul 2003 09:57:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDvR-0000wR-UO; Thu, 31 Jul 2003 09:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iDuf-0000tf-BX for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 09:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25831 for ; Thu, 31 Jul 2003 09:56:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iDud-0003wq-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 09:56:11 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iDuc-0003wX-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 09:56:10 -0400 Message-ID: From: Jeff Parker To: "'Russ White'" , Kurt Erik Lindqvist Cc: erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:55:26 -0400 > How is carrying it in another protocol going to keep the new > data being carried and processed from impacting the old data > being carried and processed? Russ - I haven't heard concern about the amount of raw data a box is carrying. I have heard concerns about Implementation Complexity and Protocol Convergence. I agree that producing a new protocol with the maturity and utility of BGP or IS-IS is difficult. But at some point we hit the salami principle: it isn't adding this slice or that slice that gets you, but soon you have a sandwich that only Dagwood Bumstead can handle.* At some point, it is time to start a new sandwich. - jeff parker * Kurt - Appologies for this grossly US reference. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 10:17:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27899 for ; Thu, 31 Jul 2003 10:17:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEEn-0002Cq-Pw; Thu, 31 Jul 2003 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEEQ-0002CG-Fz for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:16:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27800 for ; Thu, 31 Jul 2003 10:16:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEEO-000485-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:16:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEEN-00047N-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:16:35 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 07:15:48 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEFixc001566; Thu, 31 Jul 2003 10:15:44 -0400 (EDT) Received: from dhcp-64-102-60-208.cisco.com (dhcp-64-102-60-208.cisco.com [64.102.60.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA10246; Thu, 31 Jul 2003 10:15:44 -0400 (EDT) From: Russ White Reply-To: Russ White To: Jeff Parker cc: Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:16:38 -0400 (EDT) > > > How is carrying it in another protocol going to keep the new > > data being carried and processed from impacting the old data > > being carried and processed? > > Russ - > I haven't heard concern about the amount of raw > data a box is carrying. I have heard concerns about > Implementation Complexity and Protocol Convergence. Well.. I'm hearing (on this thread) that the reason BGP converges so slowly is the amount of data it is carrying, and then on the other side, that this isn't the problem it's a deployment issue, but then back that the deployment issues are caused by the protocol, etc.... In fact, the only thing that seperating a specific set of data out is going to give you is the ability to prioritize what you converge first. If we are going to develop a new protocol, should we develop it over something other than TCP, just so we don't overload the TCP stack on the box, and impact BGP's performance? Or perhaps we should go down to the IP layer, and say that too much is being carried there? It's hard to say when you should stop, and say that it's okay to multiplex here, and not there. It's easy to do what http has done, and pile everything on one channel. It's also easy to do what ospf has done, and make a seperate channel for everything (unecessarily, in my opinion). > I agree that producing a new protocol with the maturity and utility > of BGP or IS-IS is difficult. But at some point we hit the salami > principle: it isn't adding this slice or that slice that gets you, but > soon you have a sandwich that only Dagwood Bumstead can handle.* At some > point, it is time to start a new sandwich. But, if you're eating the same amount of food either way, then is it better to get a "bigger mouth," or a "smaller sandwich?" And if you have to eat 1000 smaller sandwiches, are you going to be any less full? Maybe we're just facing a case of having too much information to cart around, rather than a case of "time to build a second sandwich." I don't know.... (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 10:38:02 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29684 for ; Thu, 31 Jul 2003 10:38:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEYj-000374-DJ for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:37:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEbb9k011962 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:37:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEY9-0002qQ-Kq; Thu, 31 Jul 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEXT-0002nd-FY for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29641 for ; Thu, 31 Jul 2003 10:36:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEXR-0004dc-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:36:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEXQ-0004dP-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:36:16 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 07:38:52 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEZhXw001378; Thu, 31 Jul 2003 10:35:43 -0400 (EDT) Message-Id: <200307311435.h6VEZhXw001378@rtp-core-1.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: RP overloading: impact on routing SW In-reply-to: Your message of Thu, 31 Jul 2003 00:29:45 -0700. <69611363293.20030731002945@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:35:43 -0400 Alex> Eric, I think the concern is (the SP folks will correct me if I'm Alex> wrong) that in both cases we have increased protocol and code Alex> complexity which doesn't help their stability regardless of whether a Alex> given SP uses the new features or not, This concern has been expressed, but it is not the concern that Kurt was articulating in the message to which I was replying. It's indisputable that adding new features to a piece of software reduces the stability of that piece of software. Certainly this is an argument against extending BGP, and it's an argument that carries some weight. However, it just doesn't settle the issue, because there are many other things to consider: - If an alternative protocol shares code with BGP, using the alternative will not provide the hoped-for stability advantage. - Lack of an evident alternative which is sufficiently different to avoid this sort of code-sharing. - Time-to-market for the new features which are being demanded by the many of the same customers who then complain about the lack of stability. To the extent that this is just a software engineering issue, the IETF will not be able to have any impact on it. Alex> in case 1 [the new data is going to be distributed to the same set of Alex> nodes which currently speak BGP for the purpose of maintaining their Alex> Internet routing tables] there might be potential interference between Alex> the distributed systems because of resource contention at several Alex> levels: transport connections, queues, mem bufs, etc. The question is whether using a different protocol for distributing the new data will avoid this potential interference. If not, this is "simply" a deployment issue not a protocol or architecture issue. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 10:39:50 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29774 for ; Thu, 31 Jul 2003 10:39:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEa4-0003D5-VU; Thu, 31 Jul 2003 10:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEZD-0003Ch-4U for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:38:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29681 for ; Thu, 31 Jul 2003 10:38:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEZA-0004eU-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:38:04 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iEZ9-0004dx-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:38:03 -0400 Message-ID: From: Jeff Parker To: "'Russ White'" , Jeff Parker Cc: Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:37:19 -0400 > But, if you're eating the same amount of food either way, > then is it better to get a "bigger mouth," or a > "smaller sandwich?" Russ - To repeat myself, I don't think the issue is the raw amount of data. It is the complexity of the protocol and rate of convergence protocol convergence. (And I don't think that BGP is linear in convergence, so two smaller sandwichs would be better than one bigger one with the same wieght.) > If we are going to develop a new protocol, should we > develop it over something other than TCP, The issue isn't reuse, it is augmenting the protocol. TCP is a general purpose transport, and both BGP and HTTP use it. When someone suggests augmenting TCP to add, say, transactions, doesn't the IETF suggest that they get a new protocol? So I don't find your analogy convincing, unless you want to argue that BGP is just a general purpose distribution mechanism. The idea of splitting different functions into different tasks on the same processor is that new or allarming. This avoids fate-sharing, release-sharing, and allows users to monitor status and manage risk. It allows the SP to deploy versions of each protocol that he is comfortable with. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 10:45:51 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00117 for ; Thu, 31 Jul 2003 10:45:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEgI-0003zw-Rb for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:45:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEjQS2015343 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:45:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEft-0003rQ-9Z; Thu, 31 Jul 2003 10:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEfB-0003pH-6I for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:44:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00034 for ; Thu, 31 Jul 2003 10:44:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEf8-0004kM-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:44:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEf8-0004jF-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:44:14 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 07:43:43 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEheXw002982; Thu, 31 Jul 2003 10:43:41 -0400 (EDT) Message-Id: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: RP overloading: operational feedback In-reply-to: Your message of Thu, 31 Jul 2003 00:29:53 -0700. <110611371345.20030731002953@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:43:40 -0400 Of course, a survey of the PPVPN archives will show many messages from operators supporting the extension of BGP. In fact, there are messages from operators supporting the use of BGP for totally inappropriate purposes that (IMHO) should be rejected by the IETF. Fortunately this is the IETF not the ITU-T, and we make our decisions by dint of technical deliberations rather than by having a popularity contest. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 10:45:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00116 for ; Thu, 31 Jul 2003 10:45:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEft-0003rQ-9Z; Thu, 31 Jul 2003 10:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEfB-0003pH-6I for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:44:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00034 for ; Thu, 31 Jul 2003 10:44:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEf8-0004kM-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:44:14 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEf8-0004jF-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:44:14 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 07:43:43 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEheXw002982; Thu, 31 Jul 2003 10:43:41 -0400 (EDT) Message-Id: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: RP overloading: operational feedback In-reply-to: Your message of Thu, 31 Jul 2003 00:29:53 -0700. <110611371345.20030731002953@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:43:40 -0400 Of course, a survey of the PPVPN archives will show many messages from operators supporting the extension of BGP. In fact, there are messages from operators supporting the use of BGP for totally inappropriate purposes that (IMHO) should be rejected by the IETF. Fortunately this is the IETF not the ITU-T, and we make our decisions by dint of technical deliberations rather than by having a popularity contest. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 10:58:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00535 for ; Thu, 31 Jul 2003 10:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEsU-0004fE-Jk for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:58:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEw2tn017917 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:58:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iErW-0004Wi-0J; Thu, 31 Jul 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEr6-0004WH-UN for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:56:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00449 for ; Thu, 31 Jul 2003 10:56:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEr4-0004q4-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:56:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEr3-0004pr-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:56:33 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 07:56:03 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEu0xc007093; Thu, 31 Jul 2003 10:56:00 -0400 (EDT) Message-Id: <200307311456.h6VEu0xc007093@rtp-core-2.cisco.com> To: Pedro Roque Marques cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: RP overloading: what is "overloading" In-reply-to: Your message of Thu, 31 Jul 2003 03:17:05 -0700. <200307311017.h6VAH5F73550@roque-bsd.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:56:00 -0400 Pedro> draft-ietf-l2vpn-vpls-bgp-00.txt is about distribution of {prefix, Pedro> next-hop} tuples at least as far as BGP is concerned. No it isn't. The data which is proposed there to be carried in the NLRI field is nothing at all like an address prefix. L2VPN discovery and L2VPN signaling (including VPLS) are pretty clear cases where the data proposed to be carried by BGP is "non-routing". It may or may not be appropriate to carry such data in BGP (personally I think "yes" in the discovery case and "no" in the signaling case), but I don't think a defense of draft-ietf-l2vpn-vpls-bgp can be mounted on the basis that it is just using BGP to distribute routing info. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 11:04:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27898 for ; Thu, 31 Jul 2003 10:17:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEFC-0002IE-0M for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:17:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEHPQN008813 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:17:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEEn-0002Cq-Pw; Thu, 31 Jul 2003 10:17:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEEQ-0002CG-Fz for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:16:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27800 for ; Thu, 31 Jul 2003 10:16:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEEO-000485-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:16:36 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEEN-00047N-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:16:35 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 07:15:48 -0700 Received: from cisco.com (uzura.cisco.com [64.102.17.77]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEFixc001566; Thu, 31 Jul 2003 10:15:44 -0400 (EDT) Received: from dhcp-64-102-60-208.cisco.com (dhcp-64-102-60-208.cisco.com [64.102.60.208]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id KAA10246; Thu, 31 Jul 2003 10:15:44 -0400 (EDT) From: Russ White Reply-To: Russ White To: Jeff Parker cc: Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:16:38 -0400 (EDT) > > > How is carrying it in another protocol going to keep the new > > data being carried and processed from impacting the old data > > being carried and processed? > > Russ - > I haven't heard concern about the amount of raw > data a box is carrying. I have heard concerns about > Implementation Complexity and Protocol Convergence. Well.. I'm hearing (on this thread) that the reason BGP converges so slowly is the amount of data it is carrying, and then on the other side, that this isn't the problem it's a deployment issue, but then back that the deployment issues are caused by the protocol, etc.... In fact, the only thing that seperating a specific set of data out is going to give you is the ability to prioritize what you converge first. If we are going to develop a new protocol, should we develop it over something other than TCP, just so we don't overload the TCP stack on the box, and impact BGP's performance? Or perhaps we should go down to the IP layer, and say that too much is being carried there? It's hard to say when you should stop, and say that it's okay to multiplex here, and not there. It's easy to do what http has done, and pile everything on one channel. It's also easy to do what ospf has done, and make a seperate channel for everything (unecessarily, in my opinion). > I agree that producing a new protocol with the maturity and utility > of BGP or IS-IS is difficult. But at some point we hit the salami > principle: it isn't adding this slice or that slice that gets you, but > soon you have a sandwich that only Dagwood Bumstead can handle.* At some > point, it is time to start a new sandwich. But, if you're eating the same amount of food either way, then is it better to get a "bigger mouth," or a "smaller sandwich?" And if you have to eat 1000 smaller sandwiches, are you going to be any less full? Maybe we're just facing a case of having too much information to cart around, rather than a case of "time to build a second sandwich." I don't know.... (?). :-) Russ __________________________________ riw@cisco.com CCIE <>< Grace Alone _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 11:05:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00820 for ; Thu, 31 Jul 2003 11:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEyH-0004oY-3Q; Thu, 31 Jul 2003 11:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEyB-0004oH-Ld for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:03:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00746 for ; Thu, 31 Jul 2003 11:03:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEy8-0004td-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:03:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEy6-0004tO-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:03:52 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 08:06:27 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VF3Cxc011347; Thu, 31 Jul 2003 11:03:13 -0400 (EDT) Message-Id: <200307311503.h6VF3Cxc011347@rtp-core-2.cisco.com> To: Jeff Parker cc: "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Thu, 31 Jul 2003 10:37:19 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:03:12 -0400 Jeff> TCP is a general purpose transport, and both BGP and Jeff> HTTP use it. When someone suggests augmenting TCP to Jeff> add, say, transactions, doesn't the IETF suggest that Jeff> they get a new protocol? But this is an issue of whether TCP provides functionality which is appropriate for transactions. I don't think anyone would say "you can't use TCP because we already have too much TCP going on". Jeff> unless you want to argue that BGP is just a general purpose Jeff> distribution mechanism. It is possible to think of BGP as a general purpose distribution mechanism with applications layered on top of it, where the "address family" is used to multiplex the applications. The multi-protocol extensions to BGP are a pretty clear attempt to move in this direction. Jeff> The idea of splitting different functions into different tasks on the Jeff> same processor is that new or alarming. No question. The issue is whether using a different protocol is either a necessary or a sufficient condition of "splitting different functions into different tasks". _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 11:05:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00821 for ; Thu, 31 Jul 2003 11:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEzC-0004vo-H3 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:04:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VF4wuu018927 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:04:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEyH-0004oY-3Q; Thu, 31 Jul 2003 11:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEyB-0004oH-Ld for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:03:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00746 for ; Thu, 31 Jul 2003 11:03:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEy8-0004td-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:03:52 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEy6-0004tO-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:03:52 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 08:06:27 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VF3Cxc011347; Thu, 31 Jul 2003 11:03:13 -0400 (EDT) Message-Id: <200307311503.h6VF3Cxc011347@rtp-core-2.cisco.com> To: Jeff Parker cc: "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of Thu, 31 Jul 2003 10:37:19 -0400. Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:03:12 -0400 Jeff> TCP is a general purpose transport, and both BGP and Jeff> HTTP use it. When someone suggests augmenting TCP to Jeff> add, say, transactions, doesn't the IETF suggest that Jeff> they get a new protocol? But this is an issue of whether TCP provides functionality which is appropriate for transactions. I don't think anyone would say "you can't use TCP because we already have too much TCP going on". Jeff> unless you want to argue that BGP is just a general purpose Jeff> distribution mechanism. It is possible to think of BGP as a general purpose distribution mechanism with applications layered on top of it, where the "address family" is used to multiplex the applications. The multi-protocol extensions to BGP are a pretty clear attempt to move in this direction. Jeff> The idea of splitting different functions into different tasks on the Jeff> same processor is that new or alarming. No question. The issue is whether using a different protocol is either a necessary or a sufficient condition of "splitting different functions into different tasks". _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 11:24:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29775 for ; Thu, 31 Jul 2003 10:39:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEaT-0003JI-Hp for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:39:25 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VEdP2v012678 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 10:39:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEa4-0003D5-VU; Thu, 31 Jul 2003 10:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEZD-0003Ch-4U for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:38:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29681 for ; Thu, 31 Jul 2003 10:38:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEZA-0004eU-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:38:04 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iEZ9-0004dx-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:38:03 -0400 Message-ID: From: Jeff Parker To: "'Russ White'" , Jeff Parker Cc: Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:37:19 -0400 > But, if you're eating the same amount of food either way, > then is it better to get a "bigger mouth," or a > "smaller sandwich?" Russ - To repeat myself, I don't think the issue is the raw amount of data. It is the complexity of the protocol and rate of convergence protocol convergence. (And I don't think that BGP is linear in convergence, so two smaller sandwichs would be better than one bigger one with the same wieght.) > If we are going to develop a new protocol, should we > develop it over something other than TCP, The issue isn't reuse, it is augmenting the protocol. TCP is a general purpose transport, and both BGP and HTTP use it. When someone suggests augmenting TCP to add, say, transactions, doesn't the IETF suggest that they get a new protocol? So I don't find your analogy convincing, unless you want to argue that BGP is just a general purpose distribution mechanism. The idea of splitting different functions into different tasks on the same processor is that new or allarming. This avoids fate-sharing, release-sharing, and allows users to monitor status and manage risk. It allows the SP to deploy versions of each protocol that he is comfortable with. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 11:24:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29685 for ; Thu, 31 Jul 2003 10:38:02 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEY9-0002qQ-Kq; Thu, 31 Jul 2003 10:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEXT-0002nd-FY for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:36:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29641 for ; Thu, 31 Jul 2003 10:36:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEXR-0004dc-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:36:17 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEXQ-0004dP-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:36:16 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 07:38:52 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEZhXw001378; Thu, 31 Jul 2003 10:35:43 -0400 (EDT) Message-Id: <200307311435.h6VEZhXw001378@rtp-core-1.cisco.com> To: Alex Zinin cc: routing-discussion@ietf.org Subject: Re: RP overloading: impact on routing SW In-reply-to: Your message of Thu, 31 Jul 2003 00:29:45 -0700. <69611363293.20030731002945@psg.com> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:35:43 -0400 Alex> Eric, I think the concern is (the SP folks will correct me if I'm Alex> wrong) that in both cases we have increased protocol and code Alex> complexity which doesn't help their stability regardless of whether a Alex> given SP uses the new features or not, This concern has been expressed, but it is not the concern that Kurt was articulating in the message to which I was replying. It's indisputable that adding new features to a piece of software reduces the stability of that piece of software. Certainly this is an argument against extending BGP, and it's an argument that carries some weight. However, it just doesn't settle the issue, because there are many other things to consider: - If an alternative protocol shares code with BGP, using the alternative will not provide the hoped-for stability advantage. - Lack of an evident alternative which is sufficiently different to avoid this sort of code-sharing. - Time-to-market for the new features which are being demanded by the many of the same customers who then complain about the lack of stability. To the extent that this is just a software engineering issue, the IETF will not be able to have any impact on it. Alex> in case 1 [the new data is going to be distributed to the same set of Alex> nodes which currently speak BGP for the purpose of maintaining their Alex> Internet routing tables] there might be potential interference between Alex> the distributed systems because of resource contention at several Alex> levels: transport connections, queues, mem bufs, etc. The question is whether using a different protocol for distributing the new data will avoid this potential interference. If not, this is "simply" a deployment issue not a protocol or architecture issue. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 11:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01858 for ; Thu, 31 Jul 2003 11:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFQL-0006fr-NH; Thu, 31 Jul 2003 11:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFPg-0006em-SG for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:32:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01811 for ; Thu, 31 Jul 2003 11:32:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFPf-00058R-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:32:19 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iFPf-00058A-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:32:19 -0400 Message-ID: From: Jeff Parker To: "'erosen@cisco.com'" , Jeff Parker Cc: "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:31:37 -0400 > No question. The issue is whether using a different > protocol is either a necessary or a sufficient > condition of "splitting different functions into > different tasks". There are really two questions a) Should data for my application be carried in BGP? b) Should data for his application be carried in BGP? It is tempting to say that the answer to a) is yes and the answer to b) is no. I don;t know what the right answer is, but see the attempt to write down some rules as a useful effort. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 11:34:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01859 for ; Thu, 31 Jul 2003 11:34:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFRO-0006nD-44 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFY6j4026061 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:34:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFQL-0006fr-NH; Thu, 31 Jul 2003 11:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFPg-0006em-SG for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:32:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01811 for ; Thu, 31 Jul 2003 11:32:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFPf-00058R-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:32:19 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iFPf-00058A-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:32:19 -0400 Message-ID: From: Jeff Parker To: "'erosen@cisco.com'" , Jeff Parker Cc: "'Russ White'" , Kurt Erik Lindqvist , Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:31:37 -0400 > No question. The issue is whether using a different > protocol is either a necessary or a sufficient > condition of "splitting different functions into > different tasks". There are really two questions a) Should data for my application be carried in BGP? b) Should data for his application be carried in BGP? It is tempting to say that the answer to a) is yes and the answer to b) is no. I don;t know what the right answer is, but see the attempt to write down some rules as a useful effort. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 11:36:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01929 for ; Thu, 31 Jul 2003 11:36:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFTC-0006xR-1Q for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:35:58 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFZwul026724 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:35:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFSI-0006oQ-6A; Thu, 31 Jul 2003 11:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFRo-0006nf-Ak for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01856 for ; Thu, 31 Jul 2003 11:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFRn-00059i-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:34:31 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iFRm-00059Z-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:34:30 -0400 Message-ID: From: Jeff Parker To: "'Craig Labovitz'" , Jeff Parker Cc: routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:33:56 -0400 > So, inter-domain BGP convergence is linear with respect to the length > of the longest possible ASPath. It is the complexity of the realized > topology, and not intrinsic properties of the protocol implementation, > that plays the largest role in convergence times. > > - Craig I suspect, but cannot prove, that more applications will mean higher connectivity, as more boxes need to get 'their' information. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 11:41:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02037 for ; Thu, 31 Jul 2003 11:41:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFX7-0007LL-R7; Thu, 31 Jul 2003 11:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFWx-0007Kc-Ro for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:39:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01974 for ; Thu, 31 Jul 2003 11:39:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFWw-0005Az-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:39:50 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iFWw-0005Ap-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:39:50 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VFd9pp006572; Thu, 31 Jul 2003 08:39:10 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV32814; Thu, 31 Jul 2003 08:28:51 -0700 (PDT) Message-ID: <3F2936E6.E8F46012@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 17:33:58 +0200 Content-Transfer-Encoding: 7bit Jeff, > > But, if you're eating the same amount of food either way, > > then is it better to get a "bigger mouth," or a > > "smaller sandwich?" > > Russ - > To repeat myself, I don't think the issue is the raw > amount of data. It is the complexity of the protocol > and rate of convergence protocol convergence. (And I don't > think that BGP is linear in convergence, so two smaller > sandwichs would be better than one bigger one with the > same wieght.) Reg the sandwitch analogy ... Two (or N) smaller sandwitches could be easily done by cutting the 1 meter (sorry 3 feet) long one into pieces (read modules) before consumption. That is exactly what making each new AFI/SAFI fully modular is all about. Notice also that once cutted it is packed in individual bags for distribution (each AFI/SAFI uses a separate update msg). Some folks on this list don't like to use knives and want to make small sandwitches when there is only one piece of bread already in action. So first let's make sure we have a bread ready on the table for a second sandwitch then start putting salami on it :). R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 11:41:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02052 for ; Thu, 31 Jul 2003 11:41:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFY3-0007Uh-8T for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:40:59 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VFexK0028733 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 11:40:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFX7-0007LL-R7; Thu, 31 Jul 2003 11:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFWx-0007Kc-Ro for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:39:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01974 for ; Thu, 31 Jul 2003 11:39:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFWw-0005Az-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:39:50 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iFWw-0005Ap-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:39:50 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VFd9pp006572; Thu, 31 Jul 2003 08:39:10 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV32814; Thu, 31 Jul 2003 08:28:51 -0700 (PDT) Message-ID: <3F2936E6.E8F46012@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Parker CC: "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 17:33:58 +0200 Content-Transfer-Encoding: 7bit Jeff, > > But, if you're eating the same amount of food either way, > > then is it better to get a "bigger mouth," or a > > "smaller sandwich?" > > Russ - > To repeat myself, I don't think the issue is the raw > amount of data. It is the complexity of the protocol > and rate of convergence protocol convergence. (And I don't > think that BGP is linear in convergence, so two smaller > sandwichs would be better than one bigger one with the > same wieght.) Reg the sandwitch analogy ... Two (or N) smaller sandwitches could be easily done by cutting the 1 meter (sorry 3 feet) long one into pieces (read modules) before consumption. That is exactly what making each new AFI/SAFI fully modular is all about. Notice also that once cutted it is packed in individual bags for distribution (each AFI/SAFI uses a separate update msg). Some folks on this list don't like to use knives and want to make small sandwitches when there is only one piece of bread already in action. So first let's make sure we have a bread ready on the table for a second sandwitch then start putting salami on it :). R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 11:44:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00534 for ; Thu, 31 Jul 2003 10:58:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iErW-0004Wi-0J; Thu, 31 Jul 2003 10:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEr6-0004WH-UN for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:56:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00449 for ; Thu, 31 Jul 2003 10:56:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEr4-0004q4-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:56:34 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iEr3-0004pr-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:56:33 -0400 Received: from cisco.com (64.102.124.13) by sj-iport-3.cisco.com with ESMTP; 31 Jul 2003 07:56:03 -0700 Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VEu0xc007093; Thu, 31 Jul 2003 10:56:00 -0400 (EDT) Message-Id: <200307311456.h6VEu0xc007093@rtp-core-2.cisco.com> To: Pedro Roque Marques cc: Alex Zinin , routing-discussion@ietf.org Subject: Re: RP overloading: what is "overloading" In-reply-to: Your message of Thu, 31 Jul 2003 03:17:05 -0700. <200307311017.h6VAH5F73550@roque-bsd.juniper.net> Reply-To: erosen@cisco.com User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII From: Eric Rosen Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:56:00 -0400 Pedro> draft-ietf-l2vpn-vpls-bgp-00.txt is about distribution of {prefix, Pedro> next-hop} tuples at least as far as BGP is concerned. No it isn't. The data which is proposed there to be carried in the NLRI field is nothing at all like an address prefix. L2VPN discovery and L2VPN signaling (including VPLS) are pretty clear cases where the data proposed to be carried by BGP is "non-routing". It may or may not be appropriate to carry such data in BGP (personally I think "yes" in the discovery case and "no" in the signaling case), but I don't think a defense of draft-ietf-l2vpn-vpls-bgp can be mounted on the basis that it is just using BGP to distribute routing info. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 12:11:11 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02932 for ; Thu, 31 Jul 2003 12:11:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG09-0000bD-HG; Thu, 31 Jul 2003 12:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFzr-0000ap-Dh for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:09:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02887 for ; Thu, 31 Jul 2003 12:09:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFzq-0005PL-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:09:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iFzp-0005PC-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:09:41 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iFzH-0007FX-6I; Thu, 31 Jul 2003 16:09:07 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <129642483252.20030731090825@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org Subject: Re: RP overloading: operational feedback In-Reply-To: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> References: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:08:25 -0700 Content-Transfer-Encoding: 7bit Eric, Thursday, July 31, 2003, 7:43:40 AM, Eric Rosen wrote: > Of course, a survey of the PPVPN archives will show many messages from > operators supporting the extension of BGP. Indeed. In fact, what I will do is go back to the archives and invite those operators to join this discussion. > In fact, there are messages from > operators supporting the use of BGP for totally inappropriate purposes that > (IMHO) should be rejected by the IETF. > Fortunately this is the IETF not the ITU-T, and we make our decisions by > dint of technical deliberations rather than by having a popularity contest. Of course. Technical discussion is what we need, not just me-too's. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 12:11:12 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02941 for ; Thu, 31 Jul 2003 12:11:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG0s-0000g3-AY for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:10:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VGAkjO002529 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:10:46 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG09-0000bD-HG; Thu, 31 Jul 2003 12:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFzr-0000ap-Dh for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:09:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02887 for ; Thu, 31 Jul 2003 12:09:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFzq-0005PL-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:09:42 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iFzp-0005PC-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:09:41 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iFzH-0007FX-6I; Thu, 31 Jul 2003 16:09:07 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <129642483252.20030731090825@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org Subject: Re: RP overloading: operational feedback In-Reply-To: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> References: <200307311443.h6VEheXw002982@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:08:25 -0700 Content-Transfer-Encoding: 7bit Eric, Thursday, July 31, 2003, 7:43:40 AM, Eric Rosen wrote: > Of course, a survey of the PPVPN archives will show many messages from > operators supporting the extension of BGP. Indeed. In fact, what I will do is go back to the archives and invite those operators to join this discussion. > In fact, there are messages from > operators supporting the use of BGP for totally inappropriate purposes that > (IMHO) should be rejected by the IETF. > Fortunately this is the IETF not the ITU-T, and we make our decisions by > dint of technical deliberations rather than by having a popularity contest. Of course. Technical discussion is what we need, not just me-too's. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 12:19:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03089 for ; Thu, 31 Jul 2003 12:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG7s-0000na-Ug; Thu, 31 Jul 2003 12:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG7E-0000mB-H4 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:17:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03070 for ; Thu, 31 Jul 2003 12:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iG7D-0005Rp-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:17:19 -0400 Received: from nova.noc.catch.no ([193.69.2.2]) by ietf-mx with esmtp (Exim 4.12) id 19iG7C-0005Rm-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:17:18 -0400 Received: from [193.69.2.66] (callisto.noc.catch.no [193.69.2.66]) by nova.noc.catch.no (Postfix) with ESMTP id CE8C0FF6A; Thu, 31 Jul 2003 18:16:46 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna From: Lars Erik Gullerud To: raszuk@cisco.com Cc: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org In-Reply-To: <3F2936E6.E8F46012@cisco.com> References: <3F2936E6.E8F46012@cisco.com> Content-Type: text/plain Message-Id: <1059668206.39692.547.camel@callisto.noc.catch.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 31 Jul 2003 18:16:46 +0200 Content-Transfer-Encoding: 7bit On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > Reg the sandwitch analogy ... > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > meter (sorry 3 feet) long one into pieces (read modules) before > consumption. That is exactly what making each new AFI/SAFI fully modular > is all about. Notice also that once cutted it is packed in individual > bags for distribution (each AFI/SAFI uses a separate update msg). One problem as I see it right now though, is that if the contents of one of those bags isn't satisfactory (i.e. an update message is invalid), you throw the whole loaf of bread away (i.e. peer sends notification message and tears down the BGP session). And as more and more different sandwiches have to be made, the chances increase that a sloppy chef mistakenly puts ham on one of them instead of salami, so this is a real concern. But since we are starting to stretch this sandwich analogy, let's go back to cleartext - I have had the "pleasure" of observing the effects on a network where buggy router code from vendor X generated bad update messages for one AFI (in this case, vpnv4) and BGP sessions started dropping all over the place. Which then ended up affecting a substantially bigger portion of the customer mass than if only the VPN service had gone down. Without going into details, let's just say the guys in suits were not too happy, and the guys in jeans were sweating heavily that day. I'm not saying a separate protocol for every service is the preferred way to go, but from an operators POV, a "soft" failure of one service should ideally not affect all the other services being provided on the same infrastructure, but rather contain the failure to that particular service. Exactly how that is achieved however, is something we Ops guys usually prefer to leave as an exercise to the people we pay obscene amounts of money for those giant paperweights we stuff into our 19" racks. /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 12:19:05 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03101 for ; Thu, 31 Jul 2003 12:19:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG8U-0000tQ-RY for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:18:39 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VGIcJm003421 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:18:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG7s-0000na-Ug; Thu, 31 Jul 2003 12:18:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iG7E-0000mB-H4 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:17:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03070 for ; Thu, 31 Jul 2003 12:17:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iG7D-0005Rp-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:17:19 -0400 Received: from nova.noc.catch.no ([193.69.2.2]) by ietf-mx with esmtp (Exim 4.12) id 19iG7C-0005Rm-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:17:18 -0400 Received: from [193.69.2.66] (callisto.noc.catch.no [193.69.2.66]) by nova.noc.catch.no (Postfix) with ESMTP id CE8C0FF6A; Thu, 31 Jul 2003 18:16:46 +0200 (CEST) Subject: Re: Open Routing Area meeting in Vienna From: Lars Erik Gullerud To: raszuk@cisco.com Cc: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org In-Reply-To: <3F2936E6.E8F46012@cisco.com> References: <3F2936E6.E8F46012@cisco.com> Content-Type: text/plain Message-Id: <1059668206.39692.547.camel@callisto.noc.catch.no> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: 31 Jul 2003 18:16:46 +0200 Content-Transfer-Encoding: 7bit On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > Reg the sandwitch analogy ... > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > meter (sorry 3 feet) long one into pieces (read modules) before > consumption. That is exactly what making each new AFI/SAFI fully modular > is all about. Notice also that once cutted it is packed in individual > bags for distribution (each AFI/SAFI uses a separate update msg). One problem as I see it right now though, is that if the contents of one of those bags isn't satisfactory (i.e. an update message is invalid), you throw the whole loaf of bread away (i.e. peer sends notification message and tears down the BGP session). And as more and more different sandwiches have to be made, the chances increase that a sloppy chef mistakenly puts ham on one of them instead of salami, so this is a real concern. But since we are starting to stretch this sandwich analogy, let's go back to cleartext - I have had the "pleasure" of observing the effects on a network where buggy router code from vendor X generated bad update messages for one AFI (in this case, vpnv4) and BGP sessions started dropping all over the place. Which then ended up affecting a substantially bigger portion of the customer mass than if only the VPN service had gone down. Without going into details, let's just say the guys in suits were not too happy, and the guys in jeans were sweating heavily that day. I'm not saying a separate protocol for every service is the preferred way to go, but from an operators POV, a "soft" failure of one service should ideally not affect all the other services being provided on the same infrastructure, but rather contain the failure to that particular service. Exactly how that is achieved however, is something we Ops guys usually prefer to leave as an exercise to the people we pay obscene amounts of money for those giant paperweights we stuff into our 19" racks. /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 12:24:03 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03200 for ; Thu, 31 Jul 2003 12:24:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGDJ-000167-Sf for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:23:37 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VGNb6m004209 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:23:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGCi-00010L-TD; Thu, 31 Jul 2003 12:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGCB-000100-CQ for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:22:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03169 for ; Thu, 31 Jul 2003 12:22:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGC9-0005Ts-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:22:26 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iGC9-0005Ti-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:22:25 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VGLnpp014074; Thu, 31 Jul 2003 09:21:50 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV38125; Thu, 31 Jul 2003 09:16:34 -0700 (PDT) Message-ID: <3F294216.65FD655B@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Erik Gullerud CC: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F2936E6.E8F46012@cisco.com> <1059668206.39692.547.camel@callisto.noc.catch.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:21:42 +0200 Content-Transfer-Encoding: 7bit Lars, There is nothing which would prohibit anyone today from using a dedicated BGP session for each AF mesh. So all probles you are describing are very valid, but can be already addressed today by few extra config lines. Further from TCP point of view adding another protocol or using multiple sessions for existing one is the same thing. R. > Lars Erik Gullerud wrote: > > On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > > > Reg the sandwitch analogy ... > > > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > > meter (sorry 3 feet) long one into pieces (read modules) before > > consumption. That is exactly what making each new AFI/SAFI fully modular > > is all about. Notice also that once cutted it is packed in individual > > bags for distribution (each AFI/SAFI uses a separate update msg). > > One problem as I see it right now though, is that if the contents of one > of those bags isn't satisfactory (i.e. an update message is invalid), > you throw the whole loaf of bread away (i.e. peer sends notification > message and tears down the BGP session). And as more and more different > sandwiches have to be made, the chances increase that a sloppy chef > mistakenly puts ham on one of them instead of salami, so this is a real > concern. > > But since we are starting to stretch this sandwich analogy, let's go > back to cleartext - I have had the "pleasure" of observing the effects > on a network where buggy router code from vendor X generated bad update > messages for one AFI (in this case, vpnv4) and BGP sessions started > dropping all over the place. Which then ended up affecting a > substantially bigger portion of the customer mass than if only the VPN > service had gone down. Without going into details, let's just say the > guys in suits were not too happy, and the guys in jeans were sweating > heavily that day. > > I'm not saying a separate protocol for every service is the preferred > way to go, but from an operators POV, a "soft" failure of one service > should ideally not affect all the other services being provided on the > same infrastructure, but rather contain the failure to that particular > service. Exactly how that is achieved however, is something we Ops guys > usually prefer to leave as an exercise to the people we pay obscene > amounts of money for those giant paperweights we stuff into our 19" > racks. > > /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 12:24:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01928 for ; Thu, 31 Jul 2003 11:36:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFSI-0006oQ-6A; Thu, 31 Jul 2003 11:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFRo-0006nf-Ak for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:34:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01856 for ; Thu, 31 Jul 2003 11:34:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFRn-00059i-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:34:31 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iFRm-00059Z-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:34:30 -0400 Message-ID: From: Jeff Parker To: "'Craig Labovitz'" , Jeff Parker Cc: routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:33:56 -0400 > So, inter-domain BGP convergence is linear with respect to the length > of the longest possible ASPath. It is the complexity of the realized > topology, and not intrinsic properties of the protocol implementation, > that plays the largest role in convergence times. > > - Craig I suspect, but cannot prove, that more applications will mean higher connectivity, as more boxes need to get 'their' information. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 12:44:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03790 for ; Thu, 31 Jul 2003 12:44:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGWn-000242-DQ for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:43:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VGhjkx007931 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 12:43:45 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGW5-00020V-RP; Thu, 31 Jul 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGVq-00020J-A6 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:42:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03746 for ; Thu, 31 Jul 2003 12:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGVo-0005c6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:42:44 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iGVn-0005c3-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:42:44 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VGgB7F021871; Thu, 31 Jul 2003 09:42:12 -0700 (PDT) Received: (from achandra@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA11809; Thu, 31 Jul 2003 09:42:11 -0700 (PDT) From: Chandrashekhar Appanna To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: RP overloading: what would stay in BGP and what wouldn't Message-ID: <20030731164211.GA29245@cypher.cisco.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300013.h6U0DTk69365@roque-bsd.juniper.net> <66611356253.20030731002938@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66611356253.20030731002938@psg.com> User-Agent: Mutt/1.4i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:42:11 -0700 On Thu, Jul 31, 2003 at 12:29:38AM -0700, Alex Zinin wrote: > > Chandra wrote: > > > So how do we reach consensus on a measure for 'risk' that is not > > tainted by preferences based on what is profitable/convenient for > > some given set of participants in any proposal/discussion for > > a new 'item' that needs BGP. > > One of the suggestions that was being discussed in rtg-dir and ops-dir > is to have the proponents of the protocol extension explain why it > belongs in a particular routing protocol, and require consensus that > putting it there is the right approach. > > > A new protocol would raise the same set of concerns. If there > > is a reasonably clear requirement for a new protocol for a given > > set of applications, I think it may be a good idea to just define > > what those are and why there is a feeling that they do not belong > > in BGP. > > Two points here: > > 1. If there is a feeling that a given set of applications needs > a separate protocol, we should do so. > > 2. Note how your logic wrt "belong in BGP" is completely reversed > compared to the suggestion I mentioned above. I.e., you suggest > to explain why something does NOT belong in BGP, while the I suggest that because this entire topic/discussion seems to be primarily driven from the point of view that BGP is being used to carry information that it should not be carrying. > suggestion is to have people explain why it should go there in I agree with the above statement too. To me they are the same thing. A draft being put out => the authors think it should belong in BGP. IDR does discuss the merits/demerits of every draft anyway. - Chandra. > the first place. I personally believe (and it seems to be the > consensus in the rtg-dir and ops-dir) that the latter makes much > more sense. > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 13:09:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03201 for ; Thu, 31 Jul 2003 12:24:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGCi-00010L-TD; Thu, 31 Jul 2003 12:23:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGCB-000100-CQ for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:22:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03169 for ; Thu, 31 Jul 2003 12:22:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGC9-0005Ts-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:22:26 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iGC9-0005Ti-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:22:25 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VGLnpp014074; Thu, 31 Jul 2003 09:21:50 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV38125; Thu, 31 Jul 2003 09:16:34 -0700 (PDT) Message-ID: <3F294216.65FD655B@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Erik Gullerud CC: Jeff Parker , "'Russ White'" , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <3F2936E6.E8F46012@cisco.com> <1059668206.39692.547.camel@callisto.noc.catch.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:21:42 +0200 Content-Transfer-Encoding: 7bit Lars, There is nothing which would prohibit anyone today from using a dedicated BGP session for each AF mesh. So all probles you are describing are very valid, but can be already addressed today by few extra config lines. Further from TCP point of view adding another protocol or using multiple sessions for existing one is the same thing. R. > Lars Erik Gullerud wrote: > > On Thu, 2003-07-31 at 17:33, Robert Raszuk wrote: > > > Reg the sandwitch analogy ... > > > > Two (or N) smaller sandwitches could be easily done by cutting the 1 > > meter (sorry 3 feet) long one into pieces (read modules) before > > consumption. That is exactly what making each new AFI/SAFI fully modular > > is all about. Notice also that once cutted it is packed in individual > > bags for distribution (each AFI/SAFI uses a separate update msg). > > One problem as I see it right now though, is that if the contents of one > of those bags isn't satisfactory (i.e. an update message is invalid), > you throw the whole loaf of bread away (i.e. peer sends notification > message and tears down the BGP session). And as more and more different > sandwiches have to be made, the chances increase that a sloppy chef > mistakenly puts ham on one of them instead of salami, so this is a real > concern. > > But since we are starting to stretch this sandwich analogy, let's go > back to cleartext - I have had the "pleasure" of observing the effects > on a network where buggy router code from vendor X generated bad update > messages for one AFI (in this case, vpnv4) and BGP sessions started > dropping all over the place. Which then ended up affecting a > substantially bigger portion of the customer mass than if only the VPN > service had gone down. Without going into details, let's just say the > guys in suits were not too happy, and the guys in jeans were sweating > heavily that day. > > I'm not saying a separate protocol for every service is the preferred > way to go, but from an operators POV, a "soft" failure of one service > should ideally not affect all the other services being provided on the > same infrastructure, but rather contain the failure to that particular > service. Exactly how that is achieved however, is something we Ops guys > usually prefer to leave as an exercise to the people we pay obscene > amounts of money for those giant paperweights we stuff into our 19" > racks. > > /leg _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 13:13:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04675 for ; Thu, 31 Jul 2003 13:13:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGy9-0003Or-QZ; Thu, 31 Jul 2003 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGxr-0003Ny-IK for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 13:11:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04635; Thu, 31 Jul 2003 13:11:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGxp-0005lT-00; Thu, 31 Jul 2003 13:11:41 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iGxo-0005lI-00; Thu, 31 Jul 2003 13:11:40 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VHB8pp028012; Thu, 31 Jul 2003 10:11:08 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV44248; Thu, 31 Jul 2003 10:05:56 -0700 (PDT) Message-ID: <3F294DA7.C44114F9@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Routing Discussion , L3VPN Subject: Sequence control of distributed information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 19:11:03 +0200 Content-Transfer-Encoding: 7bit Let me try to probe operators about one element which may become much harder to achive when moving some data out of BGP umbrella. Under a numerous conversations I have heard requests asking for allowing operator to tightly control the order of information being distributed by BGP for example: vpnv4 routes first then ipv4 routes or ipv4 routes first followed by mutlicast routes etc ... When all AFs are under the same BGP umbrella that request can be very easy to deliver with a simple knob. When we separate future - non routing data - I could easily see the case that +100K ipv4 routes is competing with +100K telefon numbers to be send between routers. There would be no easy way to allow priority control other then low level CPU resources allocations to each process. Even that it would be usually difficult to achive full task serialization on a more granular level that fully blocking given's process resources. That will in turn result in explosion of separate processes almost per task and managment of those will for sure provide very stable platforms :). Bottom line - the question is - do we all agree that the only required mode of operation is fairness in distribution of all kinds of information between routers ? Cheers, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 13:39:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03791 for ; Thu, 31 Jul 2003 12:44:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGW5-00020V-RP; Thu, 31 Jul 2003 12:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGVq-00020J-A6 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 12:42:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03746 for ; Thu, 31 Jul 2003 12:42:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGVo-0005c6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:42:44 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iGVn-0005c3-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 12:42:44 -0400 Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6VGgB7F021871; Thu, 31 Jul 2003 09:42:12 -0700 (PDT) Received: (from achandra@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA11809; Thu, 31 Jul 2003 09:42:11 -0700 (PDT) From: Chandrashekhar Appanna To: Alex Zinin Cc: routing-discussion@ietf.org Subject: Re: RP overloading: what would stay in BGP and what wouldn't Message-ID: <20030731164211.GA29245@cypher.cisco.com> References: <10069799636.20030724180341@psg.com> <200307250306.h6P365c55485@roque-bsd.juniper.net> <2482819267.20030729124721@psg.com> <200307292200.h6TM0Qt69017@roque-bsd.juniper.net> <154497849009.20030729165751@psg.com> <200307300013.h6U0DTk69365@roque-bsd.juniper.net> <66611356253.20030731002938@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66611356253.20030731002938@psg.com> User-Agent: Mutt/1.4i Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:42:11 -0700 On Thu, Jul 31, 2003 at 12:29:38AM -0700, Alex Zinin wrote: > > Chandra wrote: > > > So how do we reach consensus on a measure for 'risk' that is not > > tainted by preferences based on what is profitable/convenient for > > some given set of participants in any proposal/discussion for > > a new 'item' that needs BGP. > > One of the suggestions that was being discussed in rtg-dir and ops-dir > is to have the proponents of the protocol extension explain why it > belongs in a particular routing protocol, and require consensus that > putting it there is the right approach. > > > A new protocol would raise the same set of concerns. If there > > is a reasonably clear requirement for a new protocol for a given > > set of applications, I think it may be a good idea to just define > > what those are and why there is a feeling that they do not belong > > in BGP. > > Two points here: > > 1. If there is a feeling that a given set of applications needs > a separate protocol, we should do so. > > 2. Note how your logic wrt "belong in BGP" is completely reversed > compared to the suggestion I mentioned above. I.e., you suggest > to explain why something does NOT belong in BGP, while the I suggest that because this entire topic/discussion seems to be primarily driven from the point of view that BGP is being used to carry information that it should not be carrying. > suggestion is to have people explain why it should go there in I agree with the above statement too. To me they are the same thing. A draft being put out => the authors think it should belong in BGP. IDR does discuss the merits/demerits of every draft anyway. - Chandra. > the first place. I personally believe (and it seems to be the > consensus in the rtg-dir and ops-dir) that the latter makes much > more sense. > _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 13:59:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04676 for ; Thu, 31 Jul 2003 13:13:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGyn-0003ZF-Gt for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 13:12:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VHCfaX013689 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 13:12:41 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGy9-0003Or-QZ; Thu, 31 Jul 2003 13:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iGxr-0003Ny-IK for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 13:11:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04635; Thu, 31 Jul 2003 13:11:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iGxp-0005lT-00; Thu, 31 Jul 2003 13:11:41 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19iGxo-0005lI-00; Thu, 31 Jul 2003 13:11:40 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VHB8pp028012; Thu, 31 Jul 2003 10:11:08 -0700 (PDT) Received: from cisco.com (ams-rraszuk-vpn5.cisco.com [10.61.160.6]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV44248; Thu, 31 Jul 2003 10:05:56 -0700 (PDT) Message-ID: <3F294DA7.C44114F9@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Routing Discussion , L3VPN Subject: Sequence control of distributed information Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 19:11:03 +0200 Content-Transfer-Encoding: 7bit Let me try to probe operators about one element which may become much harder to achive when moving some data out of BGP umbrella. Under a numerous conversations I have heard requests asking for allowing operator to tightly control the order of information being distributed by BGP for example: vpnv4 routes first then ipv4 routes or ipv4 routes first followed by mutlicast routes etc ... When all AFs are under the same BGP umbrella that request can be very easy to deliver with a simple knob. When we separate future - non routing data - I could easily see the case that +100K ipv4 routes is competing with +100K telefon numbers to be send between routers. There would be no easy way to allow priority control other then low level CPU resources allocations to each process. Even that it would be usually difficult to achive full task serialization on a more granular level that fully blocking given's process resources. That will in turn result in explosion of separate processes almost per task and managment of those will for sure provide very stable platforms :). Bottom line - the question is - do we all agree that the only required mode of operation is fairness in distribution of all kinds of information between routers ? Cheers, R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 14:27:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07225 for ; Thu, 31 Jul 2003 14:27:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iI7m-0006n2-7R; Thu, 31 Jul 2003 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEPP-0002WU-Cz for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:27:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29186 for ; Thu, 31 Jul 2003 10:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEPN-0004XV-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:27:57 -0400 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 19iEPL-0004XO-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:27:56 -0400 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.8p1/8.12.8) with ESMTP id h6VERMLl020686; Thu, 31 Jul 2003 15:27:22 +0100 (BST) (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: Russ White cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 10:16:38 EDT." Message-ID: <20685.1059661642@aardvark.cs.ucl.ac.uk> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 15:27:22 +0100 >Well.. I'm hearing (on this thread) that the reason BGP converges so slowly >is the amount of data it is carrying, and then on the other side, that this >isn't the problem it's a deployment issue, but then back that the >deployment issues are caused by the protocol, etc.... In fact, the only >thing that seperating a specific set of data out is going to give you is >the ability to prioritize what you converge first. No, using different connections also means two datasets don't share fate to the same extent. If one dataset's sender generates an illegal message, the receiver won't tear down the TCP connection for all datasets. If the reader for one dataset fails to read quickly enough (because it's buggy, or it's doing something time consuming, or it's waiting on someone else, or whatever), then it will block a shared TCP connection for everyone. If one dataset generates an excessively large amount of data, using separate connections means it won't cause the other datasets to be directly delayed by TCP congestion control and being queued behind the large amount of data - they'll be indirectly delayed by competing with the other TCP connection, but this is a much less severe situation. In particular, using different connections gives most of the control over which thing gets scheduled first to the receiving router. If two datasets share a connection, this gives the sending router much more control over the relative scheduling at the receiver. Cheers, Mark _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 14:27:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07224 for ; Thu, 31 Jul 2003 14:27:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iI7n-0006nA-4Q; Thu, 31 Jul 2003 14:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFIW-0006Jm-7z for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01471 for ; Thu, 31 Jul 2003 11:24:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFIV-00053z-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:24:55 -0400 Received: from state.arbornetworks.com ([204.181.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19iFIU-00053w-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:24:54 -0400 Received: by state.arbornetworks.com (Arbor Networks mail relay, from userid 1005) id 1F8C5634F1; Thu, 31 Jul 2003 11:24:46 -0400 (EDT) From: Craig Labovitz To: Jeff Parker Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030731112445.A23490@state.arbor.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jparker@axiowave.com on Thu, Jul 31, 2003 at 10:37:19AM -0400 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:24:45 -0400 So, inter-domain BGP convergence is linear with respect to the length of the longest possible ASPath. It is the complexity of the realized topology, and not intrinsic properties of the protocol implementation, that plays the largest role in convergence times. - Craig > To repeat myself, I don't think the issue is the raw > amount of data. It is the complexity of the protocol > and rate of convergence protocol convergence. (And I don't > think that BGP is linear in convergence, so two smaller > sandwichs would be better than one bigger one with the > same wieght.) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 14:27:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07237 for ; Thu, 31 Jul 2003 14:27:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iI8Q-0006vl-RC for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 14:26:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VIQg4v026544 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 14:26:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iI7n-0006nA-4Q; Thu, 31 Jul 2003 14:26:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iFIW-0006Jm-7z for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 11:24:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01471 for ; Thu, 31 Jul 2003 11:24:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iFIV-00053z-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:24:55 -0400 Received: from state.arbornetworks.com ([204.181.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19iFIU-00053w-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 11:24:54 -0400 Received: by state.arbornetworks.com (Arbor Networks mail relay, from userid 1005) id 1F8C5634F1; Thu, 31 Jul 2003 11:24:46 -0400 (EDT) From: Craig Labovitz To: Jeff Parker Cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna Message-ID: <20030731112445.A23490@state.arbor.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jparker@axiowave.com on Thu, Jul 31, 2003 at 10:37:19AM -0400 Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 11:24:45 -0400 So, inter-domain BGP convergence is linear with respect to the length of the longest possible ASPath. It is the complexity of the realized topology, and not intrinsic properties of the protocol implementation, that plays the largest role in convergence times. - Craig > To repeat myself, I don't think the issue is the raw > amount of data. It is the complexity of the protocol > and rate of convergence protocol convergence. (And I don't > think that BGP is linear in convergence, so two smaller > sandwichs would be better than one bigger one with the > same wieght.) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 14:32:04 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07407 for ; Thu, 31 Jul 2003 14:32:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iICc-00076T-6G; Thu, 31 Jul 2003 14:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIBj-00074X-VI for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 14:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07345 for ; Thu, 31 Jul 2003 14:30:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIBh-0006Ow-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 14:30:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iIBg-0006Op-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 14:30:04 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 11:32:44 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VITVPY000967; Thu, 31 Jul 2003 11:29:31 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA10472; Thu, 31 Jul 2003 14:29:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Jeff Parker From: "John G. Scudder" Subject: RE: Open Routing Area meeting in Vienna Cc: "'Russ White'" , Jeff Parker , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 14:29:24 -0400 At 10:37 AM -0400 7/31/03, Jeff Parker wrote: > >> But, if you're eating the same amount of food either way, >> then is it better to get a "bigger mouth," or a >> "smaller sandwich?" > >Russ - > To repeat myself, I don't think the issue is the raw >amount of data. It is the complexity of the protocol >and rate of convergence protocol convergence. (And I don't >think that BGP is linear in convergence, so two smaller >sandwichs would be better than one bigger one with the >same wieght.) I don't think you can support this on a big-O analysis of convergence. Let me try to break it down. BGP's convergence time is said to be O(N!) in the number of autonomous systems in the Internet. Eek! However, leaving aside the fact that that's a theoretic upper bound and not the expected case, that is a bound for Internet-wide convergence for a particular destination; there is no term for number of data objects ("routes") in the system. So that can't be relevant to your comment. The data transport term for BGP or any BGP-like protocol must be linear, per peer, in the number of routes -- clearly you have to transport every route at least once, so it's at least linear, and you don't have to transport them more than once -- at least at this level of abstract discussion -- so it's not more than linear. Since this analysis is independent of _how_ you transport the routes, that can't be what you're getting at with your "sandwich" comment either. That leaves the on-box component. A decent BGP implementation should have a per AF cost of approximately O(RPlogP) where R is the number of routes ("paths") per prefix, and P is the number of prefixes (destinations) stored in the local db for that AF. So, right, that's not linear. But it's per AF. The cost of any BGP-like protocol supporting a set of related data will equally be O(RPlogP). So either you sum these terms into BGP, or you divide them into different protocols... and still have to sum them. So once again, I don't see the basis for your "two smaller sandwiches" comment. This might be about software engineering, or protocol aesthetics, but I don't think it's about theoretical convergence properties. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 15:10:10 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09232 for ; Thu, 31 Jul 2003 15:10:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iInM-0000fD-SD; Thu, 31 Jul 2003 15:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iImZ-0000bz-Bk for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 15:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09021 for ; Thu, 31 Jul 2003 15:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iImW-0006ez-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:08:08 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iImV-0006ev-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:08:07 -0400 Message-ID: From: Jeff Parker To: "'John G. Scudder'" , Jeff Parker Cc: "'Russ White'" , Jeff Parker , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 15:07:23 -0400 > >Russ - > > To repeat myself, I don't think the issue is the raw > >amount of data. It is the complexity of the protocol > >and rate of convergence protocol convergence. (And I don't > >think that BGP is linear in convergence, so two smaller > >sandwichs would be better than one bigger one with the > >same wieght.) > > I don't think you can support this on a big-O analysis of > convergence. Let me try to break it down. ... > This might be about software engineering, or protocol aesthetics, but > I don't think it's about theoretical convergence properties. > > --John John - Thanks for the analysis: I spoke rashly. We now return to the discussion of protocol aesthetics, already in progress. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 15:14:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07227 for ; Thu, 31 Jul 2003 14:27:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iI8Q-0006vn-RF for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 14:26:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VIQgBg026543 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 14:26:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iI7m-0006n2-7R; Thu, 31 Jul 2003 14:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iEPP-0002WU-Cz for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 10:27:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29186 for ; Thu, 31 Jul 2003 10:27:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iEPN-0004XV-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:27:57 -0400 Received: from aardvark.cs.ucl.ac.uk ([128.16.11.150]) by ietf-mx with esmtp (Exim 4.12) id 19iEPL-0004XO-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 10:27:56 -0400 Received: from aardvark.cs.ucl.ac.uk (localhost [127.0.0.1]) by aardvark.cs.ucl.ac.uk (8.12.8p1/8.12.8) with ESMTP id h6VERMLl020686; Thu, 31 Jul 2003 15:27:22 +0100 (BST) (envelope-from mjh@aardvark.cs.ucl.ac.uk) From: Mark Handley X-Organisation: UCL To: Russ White cc: routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna In-reply-to: Your message of "Thu, 31 Jul 2003 10:16:38 EDT." Message-ID: <20685.1059661642@aardvark.cs.ucl.ac.uk> Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 15:27:22 +0100 >Well.. I'm hearing (on this thread) that the reason BGP converges so slowly >is the amount of data it is carrying, and then on the other side, that this >isn't the problem it's a deployment issue, but then back that the >deployment issues are caused by the protocol, etc.... In fact, the only >thing that seperating a specific set of data out is going to give you is >the ability to prioritize what you converge first. No, using different connections also means two datasets don't share fate to the same extent. If one dataset's sender generates an illegal message, the receiver won't tear down the TCP connection for all datasets. If the reader for one dataset fails to read quickly enough (because it's buggy, or it's doing something time consuming, or it's waiting on someone else, or whatever), then it will block a shared TCP connection for everyone. If one dataset generates an excessively large amount of data, using separate connections means it won't cause the other datasets to be directly delayed by TCP congestion control and being queued behind the large amount of data - they'll be indirectly delayed by competing with the other TCP connection, but this is a much less severe situation. In particular, using different connections gives most of the control over which thing gets scheduled first to the receiving router. If two datasets share a connection, this gives the sending router much more control over the relative scheduling at the receiver. Cheers, Mark _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 15:19:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07406 for ; Thu, 31 Jul 2003 14:32:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIDC-0007Dm-RP for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 14:31:38 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VIVcEI027752 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 14:31:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iICc-00076T-6G; Thu, 31 Jul 2003 14:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIBj-00074X-VI for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 14:30:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07345 for ; Thu, 31 Jul 2003 14:30:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iIBh-0006Ow-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 14:30:05 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iIBg-0006Op-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 14:30:04 -0400 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 11:32:44 -0700 Received: from cisco.com (router.cisco.com [64.101.214.30]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6VITVPY000967; Thu, 31 Jul 2003 11:29:31 -0700 (PDT) Received: from [64.101.214.208] (dhcp-64-101-215-142.cisco.com [64.101.215.142]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA10472; Thu, 31 Jul 2003 14:29:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: jgs@router Message-Id: In-Reply-To: References: To: Jeff Parker From: "John G. Scudder" Subject: RE: Open Routing Area meeting in Vienna Cc: "'Russ White'" , Jeff Parker , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 14:29:24 -0400 At 10:37 AM -0400 7/31/03, Jeff Parker wrote: > >> But, if you're eating the same amount of food either way, >> then is it better to get a "bigger mouth," or a >> "smaller sandwich?" > >Russ - > To repeat myself, I don't think the issue is the raw >amount of data. It is the complexity of the protocol >and rate of convergence protocol convergence. (And I don't >think that BGP is linear in convergence, so two smaller >sandwichs would be better than one bigger one with the >same wieght.) I don't think you can support this on a big-O analysis of convergence. Let me try to break it down. BGP's convergence time is said to be O(N!) in the number of autonomous systems in the Internet. Eek! However, leaving aside the fact that that's a theoretic upper bound and not the expected case, that is a bound for Internet-wide convergence for a particular destination; there is no term for number of data objects ("routes") in the system. So that can't be relevant to your comment. The data transport term for BGP or any BGP-like protocol must be linear, per peer, in the number of routes -- clearly you have to transport every route at least once, so it's at least linear, and you don't have to transport them more than once -- at least at this level of abstract discussion -- so it's not more than linear. Since this analysis is independent of _how_ you transport the routes, that can't be what you're getting at with your "sandwich" comment either. That leaves the on-box component. A decent BGP implementation should have a per AF cost of approximately O(RPlogP) where R is the number of routes ("paths") per prefix, and P is the number of prefixes (destinations) stored in the local db for that AF. So, right, that's not linear. But it's per AF. The cost of any BGP-like protocol supporting a set of related data will equally be O(RPlogP). So either you sum these terms into BGP, or you divide them into different protocols... and still have to sum them. So once again, I don't see the basis for your "two smaller sandwiches" comment. This might be about software engineering, or protocol aesthetics, but I don't think it's about theoretical convergence properties. --John _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 15:30:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10447 for ; Thu, 31 Jul 2003 15:30:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ7i-0001LW-1J; Thu, 31 Jul 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ7g-0001Kv-62 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 15:30:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10393 for ; Thu, 31 Jul 2003 15:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJ7d-0006o6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:29:57 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iJ7c-0006o3-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:29:56 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iJ7b-000OJI-MI; Thu, 31 Jul 2003 19:29:55 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <58654467634.20030731122809@psg.com> To: Robert Raszuk CC: Routing Discussion Subject: Re: Sequence control of distributed information In-Reply-To: <3F294DA7.C44114F9@cisco.com> References: <3F294DA7.C44114F9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 12:28:09 -0700 Content-Transfer-Encoding: 7bit Robert, [I suggest we don't cross-post to l3vpn] Though fairness and prioritization among application is not the only consideration, I think you got a very important question that can hopefully lead us to one of the main questions in this discussion. (I will put my thoughts together about the generic version of this question in a separate message.) Regarding this particular topic, one thing it seems we should consider in addition to scheduling at the BGP level vs scheduling at the process/TCP socket level is scheduling and resource sharing below. I.e., are there resources that would be shared by all TCP sessions with port 179? I know certain vendors, for example, detect such TCP segments and put them in a separate rate-limited queue towards the RP in the line card. If we have more apps running over what-looks-like-BGP, are we concerned about possible resource contention at this level? -- Alex http://www.psg.com/~zinin/ Thursday, July 31, 2003, 10:11:03 AM, Robert Raszuk wrote: > Let me try to probe operators about one element which may become much > harder to achive when moving some data out of BGP umbrella. Under a > numerous conversations I have heard requests asking for allowing > operator to tightly control the order of information being distributed > by BGP for example: vpnv4 routes first then ipv4 routes or ipv4 routes > first followed by mutlicast routes etc ... > When all AFs are under the same BGP umbrella that request can be very > easy to deliver with a simple knob. When we separate future - non > routing data - I could easily see the case that +100K ipv4 routes is > competing with +100K telefon numbers to be send between routers. There > would be no easy way to allow priority control other then low level CPU > resources allocations to each process. Even that it would be usually > difficult to achive full task serialization on a more granular level > that fully blocking given's process resources. That will in turn result > in explosion of separate processes almost per task and managment of > those will for sure provide very stable platforms :). > Bottom line - the question is - do we all agree that the only required > mode of operation is fairness in distribution of all kinds of > information between routers ? > Cheers, > R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 15:31:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10607 for ; Thu, 31 Jul 2003 15:31:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ8f-0001T4-4M; Thu, 31 Jul 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ7v-0001MK-Ly for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 15:30:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10410 for ; Thu, 31 Jul 2003 15:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJ7u-0006oR-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:30:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iJ7t-0006o1-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:30:13 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 12:32:54 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VJTfLH019960; Thu, 31 Jul 2003 12:29:42 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV64617; Thu, 31 Jul 2003 12:24:27 -0700 (PDT) Message-ID: <3F296E21.D2B6DA5C@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Handley CC: Russ White , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <20685.1059661642@aardvark.cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 21:29:37 +0200 Content-Transfer-Encoding: 7bit Mark, As said before to Lars you can easily carry each AFI/SAFI with a separate BGP session today. So what is the problem which mandates new protcol to achive any of the points you made below ? R. > Mark Handley wrote: > > >Well.. I'm hearing (on this thread) that the reason BGP converges so slowly > >is the amount of data it is carrying, and then on the other side, that this > >isn't the problem it's a deployment issue, but then back that the > >deployment issues are caused by the protocol, etc.... In fact, the only > >thing that seperating a specific set of data out is going to give you is > >the ability to prioritize what you converge first. > > No, using different connections also means two datasets don't share > fate to the same extent. > > If one dataset's sender generates an illegal message, the receiver > won't tear down the TCP connection for all datasets. > > If the reader for one dataset fails to read quickly enough (because > it's buggy, or it's doing something time consuming, or it's waiting on > someone else, or whatever), then it will block a shared TCP connection > for everyone. > > If one dataset generates an excessively large amount of data, using > separate connections means it won't cause the other datasets to be > directly delayed by TCP congestion control and being queued behind the > large amount of data - they'll be indirectly delayed by competing with > the other TCP connection, but this is a much less severe situation. > > In particular, using different connections gives most of the control > over which thing gets scheduled first to the receiving router. If two > datasets share a connection, this gives the sending router much more > control over the relative scheduling at the receiver. > > Cheers, > Mark > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 15:59:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09234 for ; Thu, 31 Jul 2003 15:10:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIo4-0000ke-KT for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 15:09:44 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VJ9i7W002863 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 15:09:44 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iInM-0000fD-SD; Thu, 31 Jul 2003 15:09:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iImZ-0000bz-Bk for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 15:08:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09021 for ; Thu, 31 Jul 2003 15:08:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iImW-0006ez-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:08:08 -0400 Received: from [64.115.125.242] (helo=bridge.axiowave.com) by ietf-mx with esmtp (Exim 4.12) id 19iImV-0006ev-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:08:07 -0400 Message-ID: From: Jeff Parker To: "'John G. Scudder'" , Jeff Parker Cc: "'Russ White'" , Jeff Parker , Kurt Erik Lindqvist , erosen@cisco.com, Randy Bush , routing-discussion@ietf.org Subject: RE: Open Routing Area meeting in Vienna MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 15:07:23 -0400 > >Russ - > > To repeat myself, I don't think the issue is the raw > >amount of data. It is the complexity of the protocol > >and rate of convergence protocol convergence. (And I don't > >think that BGP is linear in convergence, so two smaller > >sandwichs would be better than one bigger one with the > >same wieght.) > > I don't think you can support this on a big-O analysis of > convergence. Let me try to break it down. ... > This might be about software engineering, or protocol aesthetics, but > I don't think it's about theoretical convergence properties. > > --John John - Thanks for the analysis: I spoke rashly. We now return to the discussion of protocol aesthetics, already in progress. - jeff parker _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 16:19:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10606 for ; Thu, 31 Jul 2003 15:31:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ8z-0001Yl-VL for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 15:31:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VJVLrW005991 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 15:31:21 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ8f-0001T4-4M; Thu, 31 Jul 2003 15:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ7v-0001MK-Ly for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 15:30:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10410 for ; Thu, 31 Jul 2003 15:30:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJ7u-0006oR-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:30:14 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19iJ7t-0006o1-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:30:13 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 31 Jul 2003 12:32:54 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6VJTfLH019960; Thu, 31 Jul 2003 12:29:42 -0700 (PDT) Received: from cisco.com (komorow.cisco.com [10.61.160.50]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJV64617; Thu, 31 Jul 2003 12:24:27 -0700 (PDT) Message-ID: <3F296E21.D2B6DA5C@cisco.com> From: Robert Raszuk Reply-To: raszuk@cisco.com Organization: Signature: http://www.employees.org/~raszuk/sig/ X-Mailer: Mozilla 4.79 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Handley CC: Russ White , routing-discussion@ietf.org Subject: Re: Open Routing Area meeting in Vienna References: <20685.1059661642@aardvark.cs.ucl.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 21:29:37 +0200 Content-Transfer-Encoding: 7bit Mark, As said before to Lars you can easily carry each AFI/SAFI with a separate BGP session today. So what is the problem which mandates new protcol to achive any of the points you made below ? R. > Mark Handley wrote: > > >Well.. I'm hearing (on this thread) that the reason BGP converges so slowly > >is the amount of data it is carrying, and then on the other side, that this > >isn't the problem it's a deployment issue, but then back that the > >deployment issues are caused by the protocol, etc.... In fact, the only > >thing that seperating a specific set of data out is going to give you is > >the ability to prioritize what you converge first. > > No, using different connections also means two datasets don't share > fate to the same extent. > > If one dataset's sender generates an illegal message, the receiver > won't tear down the TCP connection for all datasets. > > If the reader for one dataset fails to read quickly enough (because > it's buggy, or it's doing something time consuming, or it's waiting on > someone else, or whatever), then it will block a shared TCP connection > for everyone. > > If one dataset generates an excessively large amount of data, using > separate connections means it won't cause the other datasets to be > directly delayed by TCP congestion control and being queued behind the > large amount of data - they'll be indirectly delayed by competing with > the other TCP connection, but this is a much less severe situation. > > In particular, using different connections gives most of the control > over which thing gets scheduled first to the receiving router. If two > datasets share a connection, this gives the sending router much more > control over the relative scheduling at the receiver. > > Cheers, > Mark > > _______________________________________________ > routing-discussion mailing list > routing-discussion@ietf.org > https://www1.ietf.org/mailman/listinfo/routing-discussion _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 16:19:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10448 for ; Thu, 31 Jul 2003 15:30:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ88-0001Mg-RU for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 15:30:28 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VJUSpN005242 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 15:30:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ7i-0001LW-1J; Thu, 31 Jul 2003 15:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJ7g-0001Kv-62 for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 15:30:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10393 for ; Thu, 31 Jul 2003 15:29:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJ7d-0006o6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:29:57 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iJ7c-0006o3-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 15:29:56 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iJ7b-000OJI-MI; Thu, 31 Jul 2003 19:29:55 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <58654467634.20030731122809@psg.com> To: Robert Raszuk CC: Routing Discussion Subject: Re: Sequence control of distributed information In-Reply-To: <3F294DA7.C44114F9@cisco.com> References: <3F294DA7.C44114F9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 12:28:09 -0700 Content-Transfer-Encoding: 7bit Robert, [I suggest we don't cross-post to l3vpn] Though fairness and prioritization among application is not the only consideration, I think you got a very important question that can hopefully lead us to one of the main questions in this discussion. (I will put my thoughts together about the generic version of this question in a separate message.) Regarding this particular topic, one thing it seems we should consider in addition to scheduling at the BGP level vs scheduling at the process/TCP socket level is scheduling and resource sharing below. I.e., are there resources that would be shared by all TCP sessions with port 179? I know certain vendors, for example, detect such TCP segments and put them in a separate rate-limited queue towards the RP in the line card. If we have more apps running over what-looks-like-BGP, are we concerned about possible resource contention at this level? -- Alex http://www.psg.com/~zinin/ Thursday, July 31, 2003, 10:11:03 AM, Robert Raszuk wrote: > Let me try to probe operators about one element which may become much > harder to achive when moving some data out of BGP umbrella. Under a > numerous conversations I have heard requests asking for allowing > operator to tightly control the order of information being distributed > by BGP for example: vpnv4 routes first then ipv4 routes or ipv4 routes > first followed by mutlicast routes etc ... > When all AFs are under the same BGP umbrella that request can be very > easy to deliver with a simple knob. When we separate future - non > routing data - I could easily see the case that +100K ipv4 routes is > competing with +100K telefon numbers to be send between routers. There > would be no easy way to allow priority control other then low level CPU > resources allocations to each process. Even that it would be usually > difficult to achive full task serialization on a more granular level > that fully blocking given's process resources. That will in turn result > in explosion of separate processes almost per task and managment of > those will for sure provide very stable platforms :). > Bottom line - the question is - do we all agree that the only required > mode of operation is fairness in distribution of all kinds of > information between routers ? > Cheers, > R. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 19:21:59 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18755 for ; Thu, 31 Jul 2003 19:21:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMjF-00026G-P7; Thu, 31 Jul 2003 19:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMj9-00025i-2z for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 19:20:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18713 for ; Thu, 31 Jul 2003 19:20:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iMj7-0000k9-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 19:20:53 -0400 Received: from dhcp108.yarralumla.aarnet.edu.au ([192.94.63.108] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19iMj6-0000k4-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 19:20:52 -0400 Received: from [192.94.63.108] (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h6VNKUGV001004; Fri, 1 Aug 2003 08:50:32 +0930 (CST) (envelope-from mrp@mrp.net) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: Open Routing Area meeting in Vienna From: Mark Prior To: , Randy Bush CC: Kurt Erik Lindqvist , , Alex Zinin , Message-ID: In-Reply-To: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 08:50:29 +0930 Content-Transfer-Encoding: 7bit On 31/7/03 2:35 AM, "Eric Rosen" wrote: > > Randy> can we now finish representing hidden others than ourselves, > Randy> especially given that the ietf is supposedly a forum of individual > Randy> experts? > > Seems like a fair enough deal: you stop pretending to speak for all service > providers, and I won't pretend to speak for all vendors ;-) > Having Randy speak for me seems to be a terrifying thought :-) so I will speak for myself and say on this issue I agree with Randy. Mark. (also an operator) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 19:22:00 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18771 for ; Thu, 31 Jul 2003 19:22:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMjl-00029N-Fp for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 19:21:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VNLXuT008242 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 19:21:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMjF-00026G-P7; Thu, 31 Jul 2003 19:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iMj9-00025i-2z for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 19:20:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18713 for ; Thu, 31 Jul 2003 19:20:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iMj7-0000k9-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 19:20:53 -0400 Received: from dhcp108.yarralumla.aarnet.edu.au ([192.94.63.108] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19iMj6-0000k4-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 19:20:52 -0400 Received: from [192.94.63.108] (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h6VNKUGV001004; Fri, 1 Aug 2003 08:50:32 +0930 (CST) (envelope-from mrp@mrp.net) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: Re: Open Routing Area meeting in Vienna From: Mark Prior To: , Randy Bush CC: Kurt Erik Lindqvist , , Alex Zinin , Message-ID: In-Reply-To: <200307301705.h6UH5HXw007727@rtp-core-1.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 08:50:29 +0930 Content-Transfer-Encoding: 7bit On 31/7/03 2:35 AM, "Eric Rosen" wrote: > > Randy> can we now finish representing hidden others than ourselves, > Randy> especially given that the ietf is supposedly a forum of individual > Randy> experts? > > Seems like a fair enough deal: you stop pretending to speak for all service > providers, and I won't pretend to speak for all vendors ;-) > Having Randy speak for me seems to be a terrifying thought :-) so I will speak for myself and say on this issue I agree with Randy. Mark. (also an operator) _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 20:27:58 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19885 for ; Thu, 31 Jul 2003 20:27:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iNl7-0003yQ-Tn; Thu, 31 Jul 2003 20:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iNkF-0003xm-5B for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 20:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19808 for ; Thu, 31 Jul 2003 20:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iNkD-00011M-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 20:26:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iNkC-00011J-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 20:26:04 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iNkC-000Orc-Hg for routing-discussion@ietf.org; Fri, 01 Aug 2003 00:26:04 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <64672146084.20030731172248@psg.com> To: Routing Discussion Subject: RP overloading: main question wrt code impact and resource sharing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 17:22:48 -0700 Content-Transfer-Encoding: 7bit Inspired by Robert's posting, I think we can formalize the concerns about impact on the running code and resources sharing as follows. (Note that there are other issues under consideration too.) What essentially we are talking about is the most comfortable location of the demux point among the apps. We have two major scenarios: The BGP-based model: in this case, there's a single demux point for routing and non-routing apps, and it is at the AFI/SAFI parsing/encoding stage. All apps are explicitly exposed to BGP. The non-BGP model: in this case, BGP is not exposed to non-routing apps and the demux point for them, as well as for BGP as a whole, is at the TCP level. It seems that a more comfortable feeling about the non-BGP model (again, only from the code impact and resource sharing POV) is based on the following assumptions: Code impact: 1. The code below the demux point (i.e. TCP, IP, kernel) that affects all apps is not changed when a new app is added. 2. The code in existing apps does not have to be changed when a new app is introduced, i.e., the apps are sufficiently decoupled 3. The code in separate apps may be developed, tested, released, debugged and packaged independently from other apps. Resource sharing: 1. Separate apps do not share a single transport connection, which implies that: a) they don't compete for socket buffers, and hence don't block or starve each other at the TCP level b) they don't compete for possible protocol-level transport- related buffers and queues, and hence don't starve or block each other at the protocol send/receive level c) they don't compete for a possible per-connection processing time budget, hence don't starve each other at the intra-process scheduling level d) they don't compete for resources within the network (e.g., BW), when the protocol session spans multiple hops e) they likely do not compete for resources in other parts of the local system that may be protocol-aware (such as line cards putting all BGP segments in a separate rate-limited queue) 2. Separate apps are likely to not share a single scheduling context, which implies that they will not compete for the same per-process time budget. 3. Separate apps are likely to have their memory segments protected from each other in the OS'es supporting this. Hence, the risk of non-routing apps corrupting routing data is decreased. 4. Separate apps are likely to have their own pools of resources, such as memory heaps, so the risk of memory starvation is decreased. 5. In OS'es supporting protected memory, the above results in fate separation. Shout if I forgot something... If we take the BGP model and set the goal to achieving the same fuzzy feeling, here's the type of SW engineering discussion we would have (please feel free to comment and correct): > Code impact: > > 1. The code below the demux point (i.e. TCP, IP, kernel) that > affects all apps is not changed when a new app is added. possible with proper abstraction and AFI/SAFI API registries. > 2. The code in existing apps does not have to be changed when a > new app is introduced, i.e., the apps are sufficiently decoupled should be the case for AFI/SAFI's already > 3. The code in separate apps may be developed, tested, released, > debugged and packaged independently from other apps. theoretically possible, hardly expected in reality... > Resource sharing: > > 1. Separate apps do not share a single transport connection, which > implies that: we can have a separate session per AFI/SAFI > a) they don't compete for socket buffers, and hence > don't block or starve each other at the TCP level true with the above > b) they don't compete for possible protocol-level transport- > related buffers and queues, and hence don't starve or > block each other at the protocol send/receive level ditto > c) they don't compete for a possible per-connection > processing time budget, hence don't starve each other > at the intra-process scheduling level ditto > d) they don't compete for resources within the network > (e.g., BW), when the protocol session spans multiple hops ditto > e) they likely do not compete for resources in other > parts of the local system that may be protocol-aware > (such as line cards putting all BGP segments in a separate > rate-limited queue) this one may not be true, since rate limiter still thinks it's BGP > 2. Separate apps are likely to not share a single scheduling context, > which implies that they will not compete for the same per-process > time budget. achievable with proper decoupling, and APIs. according to Robert folks are working on this. > 3. Separate apps are likely to have their memory segments protected > from each other in the OS'es supporting this. Hence, the risk of > non-routing apps corrupting routing data is decreased. possible, though IPC is likely to be a performance hit don't know if anyone is looking at this. given the well-known SW architectures of some vendors, we're far from there... > 4. Separate apps are likely to have their own pools of resources, > such as memory heaps, so the risk of memory starvation is > decreased. doable with per AFI/SAFI resource pools. > 5. In OS'es supporting protected memory, the above results in fate > separation. hard without protected memory So, from the code impact and resource sharing perspective _exclusively_ (other aspects aside), it is the question of whether we feel more comfortable with explicit, "manual" code and resource separation that the BGP model requires, or with implicit, natural one that the non-BGP model encourages, though does not guarantee. Notice that we're now deep into SW engineering details. When commenting, please be careful to make sure we don't degrade into vendor bashing. Regards Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 21:19:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19886 for ; Thu, 31 Jul 2003 20:27:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iNlb-00042P-IL for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 20:27:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h710RVQ7015505 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 20:27:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iNl7-0003yQ-Tn; Thu, 31 Jul 2003 20:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iNkF-0003xm-5B for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 20:26:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19808 for ; Thu, 31 Jul 2003 20:26:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iNkD-00011M-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 20:26:05 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iNkC-00011J-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 20:26:04 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iNkC-000Orc-Hg for routing-discussion@ietf.org; Fri, 01 Aug 2003 00:26:04 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <64672146084.20030731172248@psg.com> To: Routing Discussion Subject: RP overloading: main question wrt code impact and resource sharing MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 17:22:48 -0700 Content-Transfer-Encoding: 7bit Inspired by Robert's posting, I think we can formalize the concerns about impact on the running code and resources sharing as follows. (Note that there are other issues under consideration too.) What essentially we are talking about is the most comfortable location of the demux point among the apps. We have two major scenarios: The BGP-based model: in this case, there's a single demux point for routing and non-routing apps, and it is at the AFI/SAFI parsing/encoding stage. All apps are explicitly exposed to BGP. The non-BGP model: in this case, BGP is not exposed to non-routing apps and the demux point for them, as well as for BGP as a whole, is at the TCP level. It seems that a more comfortable feeling about the non-BGP model (again, only from the code impact and resource sharing POV) is based on the following assumptions: Code impact: 1. The code below the demux point (i.e. TCP, IP, kernel) that affects all apps is not changed when a new app is added. 2. The code in existing apps does not have to be changed when a new app is introduced, i.e., the apps are sufficiently decoupled 3. The code in separate apps may be developed, tested, released, debugged and packaged independently from other apps. Resource sharing: 1. Separate apps do not share a single transport connection, which implies that: a) they don't compete for socket buffers, and hence don't block or starve each other at the TCP level b) they don't compete for possible protocol-level transport- related buffers and queues, and hence don't starve or block each other at the protocol send/receive level c) they don't compete for a possible per-connection processing time budget, hence don't starve each other at the intra-process scheduling level d) they don't compete for resources within the network (e.g., BW), when the protocol session spans multiple hops e) they likely do not compete for resources in other parts of the local system that may be protocol-aware (such as line cards putting all BGP segments in a separate rate-limited queue) 2. Separate apps are likely to not share a single scheduling context, which implies that they will not compete for the same per-process time budget. 3. Separate apps are likely to have their memory segments protected from each other in the OS'es supporting this. Hence, the risk of non-routing apps corrupting routing data is decreased. 4. Separate apps are likely to have their own pools of resources, such as memory heaps, so the risk of memory starvation is decreased. 5. In OS'es supporting protected memory, the above results in fate separation. Shout if I forgot something... If we take the BGP model and set the goal to achieving the same fuzzy feeling, here's the type of SW engineering discussion we would have (please feel free to comment and correct): > Code impact: > > 1. The code below the demux point (i.e. TCP, IP, kernel) that > affects all apps is not changed when a new app is added. possible with proper abstraction and AFI/SAFI API registries. > 2. The code in existing apps does not have to be changed when a > new app is introduced, i.e., the apps are sufficiently decoupled should be the case for AFI/SAFI's already > 3. The code in separate apps may be developed, tested, released, > debugged and packaged independently from other apps. theoretically possible, hardly expected in reality... > Resource sharing: > > 1. Separate apps do not share a single transport connection, which > implies that: we can have a separate session per AFI/SAFI > a) they don't compete for socket buffers, and hence > don't block or starve each other at the TCP level true with the above > b) they don't compete for possible protocol-level transport- > related buffers and queues, and hence don't starve or > block each other at the protocol send/receive level ditto > c) they don't compete for a possible per-connection > processing time budget, hence don't starve each other > at the intra-process scheduling level ditto > d) they don't compete for resources within the network > (e.g., BW), when the protocol session spans multiple hops ditto > e) they likely do not compete for resources in other > parts of the local system that may be protocol-aware > (such as line cards putting all BGP segments in a separate > rate-limited queue) this one may not be true, since rate limiter still thinks it's BGP > 2. Separate apps are likely to not share a single scheduling context, > which implies that they will not compete for the same per-process > time budget. achievable with proper decoupling, and APIs. according to Robert folks are working on this. > 3. Separate apps are likely to have their memory segments protected > from each other in the OS'es supporting this. Hence, the risk of > non-routing apps corrupting routing data is decreased. possible, though IPC is likely to be a performance hit don't know if anyone is looking at this. given the well-known SW architectures of some vendors, we're far from there... > 4. Separate apps are likely to have their own pools of resources, > such as memory heaps, so the risk of memory starvation is > decreased. doable with per AFI/SAFI resource pools. > 5. In OS'es supporting protected memory, the above results in fate > separation. hard without protected memory So, from the code impact and resource sharing perspective _exclusively_ (other aspects aside), it is the question of whether we feel more comfortable with explicit, "manual" code and resource separation that the BGP model requires, or with implicit, natural one that the non-BGP model encourages, though does not guarantee. Notice that we're now deep into SW engineering details. When commenting, please be careful to make sure we don't degrade into vendor bashing. Regards Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 21:29:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20961 for ; Thu, 31 Jul 2003 21:29:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOio-00060V-Cw for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 21:28:42 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h711SgSM023088 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 21:28:42 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOi9-0005yr-0t; Thu, 31 Jul 2003 21:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOhs-0005yf-Kc for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 21:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20940 for ; Thu, 31 Jul 2003 21:27:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iOhp-0001Fj-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:27:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iOhp-0001Fg-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:27:41 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iOhp-0004Iv-0m; Fri, 01 Aug 2003 01:27:41 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <67675836401.20030731182418@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org Subject: Re: RP overloading: impact on routing SW In-Reply-To: <200307311435.h6VEZhXw001378@rtp-core-1.cisco.com> References: <200307311435.h6VEZhXw001378@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:24:18 -0700 Content-Transfer-Encoding: 7bit Eric, > It's indisputable that adding new features to a piece of software reduces > the stability of that piece of software. Certainly this is an argument > against extending BGP, and it's an argument that carries some weight. > However, it just doesn't settle the issue, because there are many other > things to consider: > - If an alternative protocol shares code with BGP, using the alternative > will not provide the hoped-for stability advantage. This is not necessarily true. If the shared piece of code is stable and unstable pieces are protocol-specific, then additional functionality put on one protocol should not affect the other. > - Lack of an evident alternative which is sufficiently different to avoid > this sort of code-sharing. > - Time-to-market for the new features which are being demanded by the many > of the same customers who then complain about the lack of stability. This is a valid question. Russ brought it up too. I will follow up on it in my reply to Russ. > To the extent that this is just a software engineering issue, the IETF will > not be able to have any impact on it. Alex>> in case 1 [the new data is going to be distributed to the same set of Alex>> nodes which currently speak BGP for the purpose of maintaining their Alex>> Internet routing tables] there might be potential interference between Alex>> the distributed systems because of resource contention at several Alex>> levels: transport connections, queues, mem bufs, etc. > The question is whether using a different protocol for distributing the new > data will avoid this potential interference. If not, this is "simply" a > deployment issue not a protocol or architecture issue. Please see my previous message with an attempt to formalize the code-related concerns. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 21:29:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20960 for ; Thu, 31 Jul 2003 21:29:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOi9-0005yr-0t; Thu, 31 Jul 2003 21:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOhs-0005yf-Kc for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 21:27:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20940 for ; Thu, 31 Jul 2003 21:27:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iOhp-0001Fj-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:27:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iOhp-0001Fg-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:27:41 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iOhp-0004Iv-0m; Fri, 01 Aug 2003 01:27:41 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <67675836401.20030731182418@psg.com> To: Eric Rosen CC: routing-discussion@ietf.org Subject: Re: RP overloading: impact on routing SW In-Reply-To: <200307311435.h6VEZhXw001378@rtp-core-1.cisco.com> References: <200307311435.h6VEZhXw001378@rtp-core-1.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:24:18 -0700 Content-Transfer-Encoding: 7bit Eric, > It's indisputable that adding new features to a piece of software reduces > the stability of that piece of software. Certainly this is an argument > against extending BGP, and it's an argument that carries some weight. > However, it just doesn't settle the issue, because there are many other > things to consider: > - If an alternative protocol shares code with BGP, using the alternative > will not provide the hoped-for stability advantage. This is not necessarily true. If the shared piece of code is stable and unstable pieces are protocol-specific, then additional functionality put on one protocol should not affect the other. > - Lack of an evident alternative which is sufficiently different to avoid > this sort of code-sharing. > - Time-to-market for the new features which are being demanded by the many > of the same customers who then complain about the lack of stability. This is a valid question. Russ brought it up too. I will follow up on it in my reply to Russ. > To the extent that this is just a software engineering issue, the IETF will > not be able to have any impact on it. Alex>> in case 1 [the new data is going to be distributed to the same set of Alex>> nodes which currently speak BGP for the purpose of maintaining their Alex>> Internet routing tables] there might be potential interference between Alex>> the distributed systems because of resource contention at several Alex>> levels: transport connections, queues, mem bufs, etc. > The question is whether using a different protocol for distributing the new > data will avoid this potential interference. If not, this is "simply" a > deployment issue not a protocol or architecture issue. Please see my previous message with an attempt to formalize the code-related concerns. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 21:36:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21128 for ; Thu, 31 Jul 2003 21:36:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOpt-0006GS-B9; Thu, 31 Jul 2003 21:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOpc-0006FD-Ko for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 21:35:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21092 for ; Thu, 31 Jul 2003 21:35:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iOpZ-0001Hu-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:35:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iOpZ-0001Hr-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:35:41 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iOpZ-00051d-3p; Fri, 01 Aug 2003 01:35:41 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <133676315860.20030731183218@psg.com> To: Robert Raszuk CC: routing-discussion@ietf.org Subject: Re: RP overloading: what is "overloading" In-Reply-To: <3F28D527.CFC4C9D9@cisco.com> References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> <116611268077.20030731002810@psg.com> <3F28D527.CFC4C9D9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:32:18 -0700 Content-Transfer-Encoding: 7bit Robert, > Last attempt to switch this tread to the right tracks ... [I'll take this part to a separate thread together with Russ'es suggestion, since I see some good suggestions that we should discuss in them] A small comment on this: > What on the other hand I see to be the real goal of this discussion is > to do revolution. While revolution leaders get much more glory and > reputation if revolution suceeds history shows that when revolutions > fail they quickly also become part of the dark sides of the history. > Also the idea of centrally deciding what is good and what is bad should > to at least two of us remind something :). and notice that we are not deciding what's good and what's bad centrally (pushing down the directives from the IESG/ADs/RTG-DIR, etc.), but instead are heaving an open discussion first at the routing area meeting and then here on the list. No desire for a revolution, but a huge desire to get a closure on this topic and move on. Thanks. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 21:36:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21132 for ; Thu, 31 Jul 2003 21:36:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOqF-0006LT-PR for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 21:36:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h711aNU9024314 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 21:36:23 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOpt-0006GS-B9; Thu, 31 Jul 2003 21:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iOpc-0006FD-Ko for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 21:35:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21092 for ; Thu, 31 Jul 2003 21:35:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iOpZ-0001Hu-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:35:41 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iOpZ-0001Hr-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:35:41 -0400 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.20) id 19iOpZ-00051d-3p; Fri, 01 Aug 2003 01:35:41 +0000 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <133676315860.20030731183218@psg.com> To: Robert Raszuk CC: routing-discussion@ietf.org Subject: Re: RP overloading: what is "overloading" In-Reply-To: <3F28D527.CFC4C9D9@cisco.com> References: <10069799636.20030724180341@psg.com> <71495483527.20030729161825@psg.com> <116611268077.20030731002810@psg.com> <3F28D527.CFC4C9D9@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 31 Jul 2003 18:32:18 -0700 Content-Transfer-Encoding: 7bit Robert, > Last attempt to switch this tread to the right tracks ... [I'll take this part to a separate thread together with Russ'es suggestion, since I see some good suggestions that we should discuss in them] A small comment on this: > What on the other hand I see to be the real goal of this discussion is > to do revolution. While revolution leaders get much more glory and > reputation if revolution suceeds history shows that when revolutions > fail they quickly also become part of the dark sides of the history. > Also the idea of centrally deciding what is good and what is bad should > to at least two of us remind something :). and notice that we are not deciding what's good and what's bad centrally (pushing down the directives from the IESG/ADs/RTG-DIR, etc.), but instead are heaving an open discussion first at the routing area meeting and then here on the list. No desire for a revolution, but a huge desire to get a closure on this topic and move on. Thanks. Alex _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 21:58:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21627 for ; Thu, 31 Jul 2003 21:58:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iPBB-00075d-B1; Thu, 31 Jul 2003 21:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iPAq-00074y-0g for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 21:57:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21573 for ; Thu, 31 Jul 2003 21:57:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iPAn-0001Q6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:57:37 -0400 Received: from dhcp108.yarralumla.aarnet.edu.au ([192.94.63.108] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19iPAl-0001Q3-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:57:36 -0400 Received: from [192.94.63.108] (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h711vTGV001072 for ; Fri, 1 Aug 2003 11:27:32 +0930 (CST) (envelope-from mrp@mrp.net) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: FW: Open Routing Area meeting in Vienna From: Mark Prior To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 11:27:28 +0930 Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Mark Prior Date: Fri, 01 Aug 2003 11:11:09 +0930 To: Alex Zinin Subject: Re: Open Routing Area meeting in Vienna On 1/8/03 8:58 AM, "Alex Zinin" wrote: > Could you please be kind and elaborate on your reasoning on the > list? It would help a lot if folks knew what makes you feel certain > way. > As an operator, stability is priority #1. If the customer can't get work done then they will soon be an ex-customer. This means that the network needs to be there when they need it. They will put up with some poor performance as long as they can get work done and they think the problem will go away sooner rather than later. The extension to this is that complexity is bad, as complexity and stability don't play well together. As I work at a R&E network there is some level of requirement for bleeding edge stuff and an acceptance that new stuff isn't always as robust as you would like but it would be jetisoned pretty damn quick if it impacted the business processes (note in our case we provide commodity and R&E access). Having this new stuff separate from the production stuff is good and the more separate the better. Mark. ------ End of Forwarded Message _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 22:44:57 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21628 for ; Thu, 31 Jul 2003 21:58:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iPBb-000787-8z for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 21:58:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h711wRoO027331 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 21:58:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iPBB-00075d-B1; Thu, 31 Jul 2003 21:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iPAq-00074y-0g for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 21:57:40 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21573 for ; Thu, 31 Jul 2003 21:57:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iPAn-0001Q6-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:57:37 -0400 Received: from dhcp108.yarralumla.aarnet.edu.au ([192.94.63.108] helo=spa.mrp.net) by ietf-mx with esmtp (Exim 4.12) id 19iPAl-0001Q3-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 21:57:36 -0400 Received: from [192.94.63.108] (localhost [127.0.0.1]) by spa.mrp.net (8.12.9/8.12.9) with ESMTP id h711vTGV001072 for ; Fri, 1 Aug 2003 11:27:32 +0930 (CST) (envelope-from mrp@mrp.net) User-Agent: Microsoft-Entourage/10.1.1.2418 Subject: FW: Open Routing Area meeting in Vienna From: Mark Prior To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 01 Aug 2003 11:27:28 +0930 Content-Transfer-Encoding: 7bit ------ Forwarded Message From: Mark Prior Date: Fri, 01 Aug 2003 11:11:09 +0930 To: Alex Zinin Subject: Re: Open Routing Area meeting in Vienna On 1/8/03 8:58 AM, "Alex Zinin" wrote: > Could you please be kind and elaborate on your reasoning on the > list? It would help a lot if folks knew what makes you feel certain > way. > As an operator, stability is priority #1. If the customer can't get work done then they will soon be an ex-customer. This means that the network needs to be there when they need it. They will put up with some poor performance as long as they can get work done and they think the problem will go away sooner rather than later. The extension to this is that complexity is bad, as complexity and stability don't play well together. As I work at a R&E network there is some level of requirement for bleeding edge stuff and an acceptance that new stuff isn't always as robust as you would like but it would be jetisoned pretty damn quick if it impacted the business processes (note in our case we provide commodity and R&E access). Having this new stuff separate from the production stuff is good and the more separate the better. Mark. ------ End of Forwarded Message _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From routing-discussion-admin@ietf.org Thu Jul 31 22:59:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22561 for ; Thu, 31 Jul 2003 22:59:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQ7F-0000gw-56; Thu, 31 Jul 2003 22:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQ6S-0000gY-7m for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 22:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22516 for ; Thu, 31 Jul 2003 22:57:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iQ6O-0001h7-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 22:57:08 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iQ5j-0001gA-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 22:56:27 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.20) id 19iQ3m-000C6d-Pg for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:54:27 +0000 Subject: Re: RP overloading: what would stay in BGP and what wouldn't Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <66611356253.20030731002938@psg.com> Message-Id: <73557B67-C3CB-11D7-93AF-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 11:54:21 +0900 Content-Transfer-Encoding: 7bit On torsdag, jul 31, 2003, at 16:29 Asia/Seoul, Alex Zinin wrote: > Chandra wrote: > >> So how do we reach consensus on a measure for 'risk' that is not >> tainted by preferences based on what is profitable/convenient for >> some given set of participants in any proposal/discussion for >> a new 'item' that needs BGP. > > One of the suggestions that was being discussed in rtg-dir and ops-dir > is to have the proponents of the protocol extension explain why it > belongs in a particular routing protocol, and require consensus that > putting it there is the right approach. This, at a minimum seems a very good start. Anyone who think that a new feature belongs in the protocol should be able to present a cogent and convincing argument for that new feature. This may do nothing to relieve the bloat, but it will hopefully prevent it from getting worse. > > > One of the attractive properties of the MP-BGP framework is that you > can quickly distribute new types of information among the routers > without having to specify and implement new protocol machinery. A > generalized transport protocol would provide the same possibility. And this can be expected to be part of someone's presentation on why add new functionality. > a. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion From exim@www1.ietf.org Thu Jul 31 22:59:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22562 for ; Thu, 31 Jul 2003 22:59:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQ8K-0000on-AD for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 22:59:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h712x8hU003121 for routing-discussion-archive@odin.ietf.org; Thu, 31 Jul 2003 22:59:08 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQ7F-0000gw-56; Thu, 31 Jul 2003 22:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iQ6S-0000gY-7m for routing-discussion@optimus.ietf.org; Thu, 31 Jul 2003 22:57:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22516 for ; Thu, 31 Jul 2003 22:57:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iQ6O-0001h7-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 22:57:08 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19iQ5j-0001gA-00 for routing-discussion@ietf.org; Thu, 31 Jul 2003 22:56:27 -0400 Received: from [147.28.0.62] (helo=acm.org) by psg.com with esmtp (Exim 4.20) id 19iQ3m-000C6d-Pg for routing-discussion@ietf.org; Fri, 01 Aug 2003 02:54:27 +0000 Subject: Re: RP overloading: what would stay in BGP and what wouldn't Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Avri Doria To: routing-discussion@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <66611356253.20030731002938@psg.com> Message-Id: <73557B67-C3CB-11D7-93AF-000393CC2112@acm.org> X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: routing-discussion-admin@ietf.org Errors-To: routing-discussion-admin@ietf.org X-BeenThere: routing-discussion@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Routing Area General mailing list List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 1 Aug 2003 11:54:21 +0900 Content-Transfer-Encoding: 7bit On torsdag, jul 31, 2003, at 16:29 Asia/Seoul, Alex Zinin wrote: > Chandra wrote: > >> So how do we reach consensus on a measure for 'risk' that is not >> tainted by preferences based on what is profitable/convenient for >> some given set of participants in any proposal/discussion for >> a new 'item' that needs BGP. > > One of the suggestions that was being discussed in rtg-dir and ops-dir > is to have the proponents of the protocol extension explain why it > belongs in a particular routing protocol, and require consensus that > putting it there is the right approach. This, at a minimum seems a very good start. Anyone who think that a new feature belongs in the protocol should be able to present a cogent and convincing argument for that new feature. This may do nothing to relieve the bloat, but it will hopefully prevent it from getting worse. > > > One of the attractive properties of the MP-BGP framework is that you > can quickly distribute new types of information among the routers > without having to specify and implement new protocol machinery. A > generalized transport protocol would provide the same possibility. And this can be expected to be part of someone's presentation on why add new functionality. > a. _______________________________________________ routing-discussion mailing list routing-discussion@ietf.org https://www1.ietf.org/mailman/listinfo/routing-discussion