From mailman-admin@ietf.org Sun Jun 1 10:46:36 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14000 for ; Sun, 1 Jun 2003 10:46:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h51EkCB15063 for ; Sun, 1 Jun 2003 10:46:12 -0400 Date: Sun, 01 Jun 2003 10:46:12 -0400 Message-ID: <20030601144612.11734.43285.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: pilc-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, pilc-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for pilc-archive@lists.ietf.org: List Password // URL ---- -------- pilc@ietf.org HsCZ https://www1.ietf.org/mailman/options/pilc/pilc-archive%40lists.ietf.org From pilc-admin@ietf.org Mon Jun 9 19:12:55 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24889 for ; Mon, 9 Jun 2003 19:12:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59NCNB13057; Mon, 9 Jun 2003 19:12:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MwAB11806 for ; Mon, 9 Jun 2003 18:58: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 SAA24721 for ; Mon, 9 Jun 2003 18:58:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PVYZ-0007dp-00 for pilc@ietf.org; Mon, 09 Jun 2003 18:56:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19PVYY-0007dm-00 for pilc@ietf.org; Mon, 09 Jun 2003 18:56:03 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19PVaR-000OKo-00; Mon, 09 Jun 2003 22:57:59 +0000 To: pilc@ietf.org Cc: zinin@psg.com, mankin@psg.com Reply-To: mankin@psg.com Date: Mon, 09 Jun 2003 15:57:59 -0700 From: Allison Mankin Message-Id: Subject: [pilc] IESG Review of LINK Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Phil, Mark, PILC WG, The IESG reviewed LINK and had comments that should be addressed with changes. These are in the id-tracker, but they are among a lot of material, not all of which does need addressing. Below are the comments that do. Those from the Security ADs are simple textual fixes, but the comment from Alex Zinin, one of the Routing ADs, wants the WG to re-look significantly at Section 17 - I support Alex's points, though cellphone handoffs do complement IP level routing and one would not want them to take place at IP level. There should be some way to write about both this sort of routing tradeoff and Alex's issues in the section. Allison -------- From Steve Bellovin: Section 6: Should there be mention of switches that snoop on IGMP? I suspect so. Section 18: The list at the end should included replay attacks. -------- From Russ Housley: I do have two comments on the Security Considerations section. 1. PGP is mentioned in the 3rd paragraph. S/MIME should also be listed. S/MIME is included in every major mail agent (except the one from Qualcomm). While S/MIME suffers from the lack of ubiquitous certificate enrollment, PGP suffers from the lack of integration into mail stream mail agents. In my opinion, either mention both or neither. 2. At least two more items should be added to the number list of "mistakes." The first is replay detection. The second is the use of confidentiality mechanisms without integrity mechanisms. -------- From Alex Zinin: I didn't know how to formulate my concerns at first, because it appeared that in addition to being not quite correct in some places, the discussion in text actually goes in a wrong direction, and touches on some seemingly irrelevant points without discussing those that should have been. So, I decided to start with comments on the actual text and then move to the meta question... > 17 Routing > > Many subnetworks provide their own internal routing mechanisms. The text should probably say why some do and some don't. E.g., if a subnetwork technology can be used to construct a multi-node network, where internal nodes do not run IP, and where the network is self-contained and can be used for service independent from IP routing, then subnetwork-level routing function is usually provided (FR, ATM, Ethernet bridging and STP). If the technology is primarily used for single-hop packet framing among IP nodes, subnetwork-level routing is not needed. > Since routing is the major function of the Internet layer, the > question naturally arises as to the proper division of function > between routing at the Internet layer and routing in the subnet. and the text does not address this question, nor does it talk about the interactions among the routing function within the subnetwork and at the IP level. > In general, routing in a subnetwork and at IP is more > complementary than competitive. Routing algorithms often have > difficulty scaling to very large networks, and a division of labor > between IP and a large subnetwork can often make the routing > problem more tractable for both. In fact, experience shows that this is exactly the opposite. When a large number of IP routers is connected via a subnetwork that hides internal routing details from IP, this usually results in O(N^2) adjacencies, flooding storms, and unforeseen convergence interactions. In most cases, the physical topology of a subnetwork is orders of magnitude simpler than the logical IP topology on top of it. This is because the topology graph within the subnetwork is determined by physical links and nodes, while the topology graph at the IP level is essentially driven by the connectivity matrix. With the same number of nodes, routing scales better if it operates over the physical topology rather than when it's layered up. > Some subnetworks have special features that allow the use of more > effective or responsive routing mechanisms that cannot be > implemented in IP because of its need for generality. One example > is the self-learning bridge algorithm widely used in Ethernet > networks. Another is the "handoff" mechanism in cellular telephone > networks, particularly the "soft handoff" scheme in IS-95 CDMA. Those who ran a large-enough bridged network with STP would hardly agree with the statement that Ethernet bridging is more effective and responsive. Actually, this para adds no information, so I'd just remove it. > On the other hand, routing optimality can suffer when a > subnetwork's routing architecture hides internal structure that an > IP router could have used to make more efficient decisions. Such > situations occur most often when the subnetwork covers a large > geographic area and includes links of widely varying capacities, but > presents itself to IP as a single, fully-connected network with > uniform metrics between border nodes. True > The subnetwork designer who decides to implement internal routing > should also consider whether a custom routing algorithm is warranted, > or if an existing Internet routing algorithm or protocol may suffice. Not clear if this means something like GMPLS where IP control plane is used to route non-IP stuff, or that routing is left to IP and the subnetwork provides primarily link-level functionality. > Protocols and routing algorithms can be notoriously subtle, complex > and difficult to implement correctly. Much work can be avoided if an > existing protocol or off-the-shelf product can be readily used. I'd change wording to refer to "existing implementations" as opposed to "off-the-shelf product" here... OK, meta issues now. What I would expect this section to talk about is: 1. Difference between the _function_ of IP routing and the routing function found in some subnetworks and analysis of why certain subnetwork technologies have the routing function. 2. Give a recommendation that unless there is a very compelling reason, routing should be left to IP. 3. If the routing function is still implemented in the subnetwork technology, explain what considerations should be kept in mind: a) Connectivity graph and its affects on IP routing, such as: - number of adjacencies/sessions per router to maintain - broadcast & connectivity (if routing treats the subnet as broadcast, any-to-any connectivity needs to be ensured) - flooding implications - ... b) Rerouting, convergence and timing with multiple layers: - effects of topology change and rerouting within subnetwork on IP routing (e.g., if the subnetwork has slow rerouting, IP will start reconverging) - effects of reconvergence at the IP level on the subnet (e.g. dynamic connection establishment) - combination of the two c) Connection model for connection-oriented subnetworks If the model assumes temporary connectivity between nodes (e.g., PSTN or ISDN) how will this affect IP routing (adjacencies going up/down, applicability of e.g. demand circuit extension in OSPF) d) Optimality and traffic engineering it's addressed in the text to some extent, but more thought should be given to such aspects as how traffic engineering within the network (pure IP and MPLS) would be done, i.e., is it just "enough BW", or the subnetwork provides TE functionality as in ATM, for example... Something along these lines should set the mind of the reader in the right direction. _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From mailnull@www1.ietf.org Mon Jun 9 19:23:35 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25011 for ; Mon, 9 Jun 2003 19:23:35 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59NN8Y13353 for pilc-archive@odin.ietf.org; Mon, 9 Jun 2003 19:23:08 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59NN8B13350 for ; Mon, 9 Jun 2003 19:23: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 TAA25001 for ; Mon, 9 Jun 2003 19:23:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PVwn-0007je-00 for pilc-web-archive@ietf.org; Mon, 09 Jun 2003 19:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PVwn-0007ja-00 for pilc-web-archive@ietf.org; Mon, 09 Jun 2003 19:21:05 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59NCNB13057; Mon, 9 Jun 2003 19:12:23 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h59MwAB11806 for ; Mon, 9 Jun 2003 18:58: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 SAA24721 for ; Mon, 9 Jun 2003 18:58:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PVYZ-0007dp-00 for pilc@ietf.org; Mon, 09 Jun 2003 18:56:03 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19PVYY-0007dm-00 for pilc@ietf.org; Mon, 09 Jun 2003 18:56:03 -0400 Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 3.36 #1) id 19PVaR-000OKo-00; Mon, 09 Jun 2003 22:57:59 +0000 To: pilc@ietf.org Cc: zinin@psg.com, mankin@psg.com Reply-To: mankin@psg.com Date: Mon, 09 Jun 2003 15:57:59 -0700 From: Allison Mankin Message-Id: Subject: [pilc] IESG Review of LINK Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Phil, Mark, PILC WG, The IESG reviewed LINK and had comments that should be addressed with changes. These are in the id-tracker, but they are among a lot of material, not all of which does need addressing. Below are the comments that do. Those from the Security ADs are simple textual fixes, but the comment from Alex Zinin, one of the Routing ADs, wants the WG to re-look significantly at Section 17 - I support Alex's points, though cellphone handoffs do complement IP level routing and one would not want them to take place at IP level. There should be some way to write about both this sort of routing tradeoff and Alex's issues in the section. Allison -------- From Steve Bellovin: Section 6: Should there be mention of switches that snoop on IGMP? I suspect so. Section 18: The list at the end should included replay attacks. -------- From Russ Housley: I do have two comments on the Security Considerations section. 1. PGP is mentioned in the 3rd paragraph. S/MIME should also be listed. S/MIME is included in every major mail agent (except the one from Qualcomm). While S/MIME suffers from the lack of ubiquitous certificate enrollment, PGP suffers from the lack of integration into mail stream mail agents. In my opinion, either mention both or neither. 2. At least two more items should be added to the number list of "mistakes." The first is replay detection. The second is the use of confidentiality mechanisms without integrity mechanisms. -------- From Alex Zinin: I didn't know how to formulate my concerns at first, because it appeared that in addition to being not quite correct in some places, the discussion in text actually goes in a wrong direction, and touches on some seemingly irrelevant points without discussing those that should have been. So, I decided to start with comments on the actual text and then move to the meta question... > 17 Routing > > Many subnetworks provide their own internal routing mechanisms. The text should probably say why some do and some don't. E.g., if a subnetwork technology can be used to construct a multi-node network, where internal nodes do not run IP, and where the network is self-contained and can be used for service independent from IP routing, then subnetwork-level routing function is usually provided (FR, ATM, Ethernet bridging and STP). If the technology is primarily used for single-hop packet framing among IP nodes, subnetwork-level routing is not needed. > Since routing is the major function of the Internet layer, the > question naturally arises as to the proper division of function > between routing at the Internet layer and routing in the subnet. and the text does not address this question, nor does it talk about the interactions among the routing function within the subnetwork and at the IP level. > In general, routing in a subnetwork and at IP is more > complementary than competitive. Routing algorithms often have > difficulty scaling to very large networks, and a division of labor > between IP and a large subnetwork can often make the routing > problem more tractable for both. In fact, experience shows that this is exactly the opposite. When a large number of IP routers is connected via a subnetwork that hides internal routing details from IP, this usually results in O(N^2) adjacencies, flooding storms, and unforeseen convergence interactions. In most cases, the physical topology of a subnetwork is orders of magnitude simpler than the logical IP topology on top of it. This is because the topology graph within the subnetwork is determined by physical links and nodes, while the topology graph at the IP level is essentially driven by the connectivity matrix. With the same number of nodes, routing scales better if it operates over the physical topology rather than when it's layered up. > Some subnetworks have special features that allow the use of more > effective or responsive routing mechanisms that cannot be > implemented in IP because of its need for generality. One example > is the self-learning bridge algorithm widely used in Ethernet > networks. Another is the "handoff" mechanism in cellular telephone > networks, particularly the "soft handoff" scheme in IS-95 CDMA. Those who ran a large-enough bridged network with STP would hardly agree with the statement that Ethernet bridging is more effective and responsive. Actually, this para adds no information, so I'd just remove it. > On the other hand, routing optimality can suffer when a > subnetwork's routing architecture hides internal structure that an > IP router could have used to make more efficient decisions. Such > situations occur most often when the subnetwork covers a large > geographic area and includes links of widely varying capacities, but > presents itself to IP as a single, fully-connected network with > uniform metrics between border nodes. True > The subnetwork designer who decides to implement internal routing > should also consider whether a custom routing algorithm is warranted, > or if an existing Internet routing algorithm or protocol may suffice. Not clear if this means something like GMPLS where IP control plane is used to route non-IP stuff, or that routing is left to IP and the subnetwork provides primarily link-level functionality. > Protocols and routing algorithms can be notoriously subtle, complex > and difficult to implement correctly. Much work can be avoided if an > existing protocol or off-the-shelf product can be readily used. I'd change wording to refer to "existing implementations" as opposed to "off-the-shelf product" here... OK, meta issues now. What I would expect this section to talk about is: 1. Difference between the _function_ of IP routing and the routing function found in some subnetworks and analysis of why certain subnetwork technologies have the routing function. 2. Give a recommendation that unless there is a very compelling reason, routing should be left to IP. 3. If the routing function is still implemented in the subnetwork technology, explain what considerations should be kept in mind: a) Connectivity graph and its affects on IP routing, such as: - number of adjacencies/sessions per router to maintain - broadcast & connectivity (if routing treats the subnet as broadcast, any-to-any connectivity needs to be ensured) - flooding implications - ... b) Rerouting, convergence and timing with multiple layers: - effects of topology change and rerouting within subnetwork on IP routing (e.g., if the subnetwork has slow rerouting, IP will start reconverging) - effects of reconvergence at the IP level on the subnet (e.g. dynamic connection establishment) - combination of the two c) Connection model for connection-oriented subnetworks If the model assumes temporary connectivity between nodes (e.g., PSTN or ISDN) how will this affect IP routing (adjacencies going up/down, applicability of e.g. demand circuit extension in OSPF) d) Optimality and traffic engineering it's addressed in the text to some extent, but more thought should be given to such aspects as how traffic engineering within the network (pure IP and MPLS) would be done, i.e., is it just "enough BW", or the subnetwork provides TE functionality as in ATM, for example... Something along these lines should set the mind of the reader in the right direction. _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From pilc-admin@ietf.org Tue Jun 10 06:56:30 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19891 for ; Tue, 10 Jun 2003 06:56:29 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAu0B08299; Tue, 10 Jun 2003 06:56:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAoEB08126 for ; Tue, 10 Jun 2003 06:50: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 GAA19814 for ; Tue, 10 Jun 2003 06:50:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pgfe-0003bq-00 for pilc@ietf.org; Tue, 10 Jun 2003 06:48:06 -0400 Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19Pgfd-0003be-00 for pilc@ietf.org; Tue, 10 Jun 2003 06:48:05 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5AAnKvb000399; Tue, 10 Jun 2003 11:49:21 +0100 (BST) Message-ID: <3EE5B7B1.1D82A6CD@erg.abdn.ac.uk> Date: Tue, 10 Jun 2003 11:49:22 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: pilc@ietf.org CC: mankin@psg.com Subject: Re: [pilc] IESG Review of LINK References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See in-line comments... Allison Mankin wrote: > > Phil, Mark, PILC WG, > > The IESG reviewed LINK and had comments that should be addressed with changes. > These are in the id-tracker, but they are among a lot of material, > not all of which does need addressing. Below are the comments that do. > Those from the Security ADs are simple textual fixes, but the comment from > Alex Zinin, one of the Routing ADs, wants the WG to re-look significantly > at Section 17 - I support Alex's points, though cellphone handoffs do complement > IP level routing and one would not want them to take place at IP level. > There should be some way to write about both this sort of routing tradeoff > and Alex's issues in the section. > > Allison > > -------- > >From Steve Bellovin: > Section 6: Should there be mention of switches that snoop on IGMP? I > suspect so. > I'd be happy to work on some text for this, is anyone able to work with me to check sanity and wording? Please let me know! <> > -------- > >From Alex Zinin: > > I didn't know how to formulate my concerns at first, because it > appeared that in addition to being not quite correct in some places, > the discussion in text actually goes in a wrong direction, and > touches on some seemingly irrelevant points without discussing those > that should have been. > > So, I decided to start with comments on the actual text and then > move to the meta question... > > > 17 Routing > > <> > > With the same number of nodes, routing scales better if it operates > over the physical topology rather than when it's layered up. > > > Some subnetworks have special features that allow the use of more > > effective or responsive routing mechanisms that cannot be > > implemented in IP because of its need for generality. One example > > is the self-learning bridge algorithm widely used in Ethernet > > networks. Another is the "handoff" mechanism in cellular telephone > > networks, particularly the "soft handoff" scheme in IS-95 CDMA. > > Those who ran a large-enough bridged network with STP would hardly > agree with the statement that Ethernet bridging is more effective > and responsive. > OK, Spanning Tree has a reputation of being a pain when trying to converge. But, IMHO simple "Learning Bridges" provide a very efficient way to send Ethernet frames to the place were they are needed. This uses the L2 (MAC) source address in the frame header without the need to configure or maintain routing information. Handovers in 802.11 and cellular radio utilise information not visible at the IP level - such as base station capability and signal strength. Are there more things we should add to the list? I wonder if the words "special features" are simply too vague to be useful, if we give some concrete examples, then we have a better basis for the paragraph. > > _______________________________________________ > pilc mailing list > pilc@ietf.org > https://www1.ietf.org/mailman/listinfo/pilc > http://www.ietf.org/html.charters/pilc-charter.html > http://pilc.grc.nasa.gov/ _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From mailnull@www1.ietf.org Tue Jun 10 07:07:05 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20149 for ; Tue, 10 Jun 2003 07:07:05 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AB6g308743 for pilc-archive@odin.ietf.org; Tue, 10 Jun 2003 07:06:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AB6fB08740 for ; Tue, 10 Jun 2003 07:06: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 HAA20133 for ; Tue, 10 Jun 2003 07:06:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PgvZ-0003hd-00 for pilc-web-archive@ietf.org; Tue, 10 Jun 2003 07:04:33 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PgvZ-0003hX-00 for pilc-web-archive@ietf.org; Tue, 10 Jun 2003 07:04:33 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAu0B08299; Tue, 10 Jun 2003 06:56:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AAoEB08126 for ; Tue, 10 Jun 2003 06:50: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 GAA19814 for ; Tue, 10 Jun 2003 06:50:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pgfe-0003bq-00 for pilc@ietf.org; Tue, 10 Jun 2003 06:48:06 -0400 Received: from mavis.erg.abdn.ac.uk ([139.133.204.77] helo=erg.abdn.ac.uk) by ietf-mx with esmtp (Exim 4.12) id 19Pgfd-0003be-00 for pilc@ietf.org; Tue, 10 Jun 2003 06:48:05 -0400 Received: from erg.abdn.ac.uk (gresley.erg.abdn.ac.uk [139.133.207.106]) by erg.abdn.ac.uk (8.12.9/8.12.9) with ESMTP id h5AAnKvb000399; Tue, 10 Jun 2003 11:49:21 +0100 (BST) Message-ID: <3EE5B7B1.1D82A6CD@erg.abdn.ac.uk> Date: Tue, 10 Jun 2003 11:49:22 +0100 From: Dr G Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: ERG, Aberdeen, UK X-Mailer: Mozilla 4.77C-CCK-MCD {C-UDP; EBM-APPLE} (Macintosh; U; PPC) X-Accept-Language: en MIME-Version: 1.0 To: pilc@ietf.org CC: mankin@psg.com Subject: Re: [pilc] IESG Review of LINK References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit See in-line comments... Allison Mankin wrote: > > Phil, Mark, PILC WG, > > The IESG reviewed LINK and had comments that should be addressed with changes. > These are in the id-tracker, but they are among a lot of material, > not all of which does need addressing. Below are the comments that do. > Those from the Security ADs are simple textual fixes, but the comment from > Alex Zinin, one of the Routing ADs, wants the WG to re-look significantly > at Section 17 - I support Alex's points, though cellphone handoffs do complement > IP level routing and one would not want them to take place at IP level. > There should be some way to write about both this sort of routing tradeoff > and Alex's issues in the section. > > Allison > > -------- > >From Steve Bellovin: > Section 6: Should there be mention of switches that snoop on IGMP? I > suspect so. > I'd be happy to work on some text for this, is anyone able to work with me to check sanity and wording? Please let me know! <> > -------- > >From Alex Zinin: > > I didn't know how to formulate my concerns at first, because it > appeared that in addition to being not quite correct in some places, > the discussion in text actually goes in a wrong direction, and > touches on some seemingly irrelevant points without discussing those > that should have been. > > So, I decided to start with comments on the actual text and then > move to the meta question... > > > 17 Routing > > <> > > With the same number of nodes, routing scales better if it operates > over the physical topology rather than when it's layered up. > > > Some subnetworks have special features that allow the use of more > > effective or responsive routing mechanisms that cannot be > > implemented in IP because of its need for generality. One example > > is the self-learning bridge algorithm widely used in Ethernet > > networks. Another is the "handoff" mechanism in cellular telephone > > networks, particularly the "soft handoff" scheme in IS-95 CDMA. > > Those who ran a large-enough bridged network with STP would hardly > agree with the statement that Ethernet bridging is more effective > and responsive. > OK, Spanning Tree has a reputation of being a pain when trying to converge. But, IMHO simple "Learning Bridges" provide a very efficient way to send Ethernet frames to the place were they are needed. This uses the L2 (MAC) source address in the frame header without the need to configure or maintain routing information. Handovers in 802.11 and cellular radio utilise information not visible at the IP level - such as base station capability and signal strength. Are there more things we should add to the list? I wonder if the words "special features" are simply too vague to be useful, if we give some concrete examples, then we have a better basis for the paragraph. > > _______________________________________________ > pilc mailing list > pilc@ietf.org > https://www1.ietf.org/mailman/listinfo/pilc > http://www.ietf.org/html.charters/pilc-charter.html > http://pilc.grc.nasa.gov/ _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From pilc-admin@ietf.org Tue Jun 10 12:25:22 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07654 for ; Tue, 10 Jun 2003 12:25:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGOhB05228; Tue, 10 Jun 2003 12:24:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGJxB04915 for ; Tue, 10 Jun 2003 12:19: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 MAA07481 for ; Tue, 10 Jun 2003 12:19:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Plon-00006X-00 for pilc@ietf.org; Tue, 10 Jun 2003 12:17:53 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx with esmtp (Exim 4.12) id 19Plon-00006U-00 for pilc@ietf.org; Tue, 10 Jun 2003 12:17:53 -0400 Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h5AGJtG20415 for pilc@ietf.org; Tue, 10 Jun 2003 09:19:55 -0700 Date: Tue, 10 Jun 2003 09:19:55 -0700 From: Aaron Falk To: pilc@ietf.org Message-ID: <20030610161955.GI6577@isi.edu> Mail-Followup-To: pilc@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [pilc] test message -- please ignore Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , mail list test... _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From mailnull@www1.ietf.org Tue Jun 10 12:29:26 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07861 for ; Tue, 10 Jun 2003 12:29:26 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5AGT0I05541 for pilc-archive@odin.ietf.org; Tue, 10 Jun 2003 12:29:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGSxB05538 for ; Tue, 10 Jun 2003 12:28: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 MAA07789 for ; Tue, 10 Jun 2003 12:28:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PlxW-0000C3-00 for pilc-web-archive@ietf.org; Tue, 10 Jun 2003 12:26:54 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PlxV-0000C0-00 for pilc-web-archive@ietf.org; Tue, 10 Jun 2003 12:26:53 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGOhB05228; Tue, 10 Jun 2003 12:24:43 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AGJxB04915 for ; Tue, 10 Jun 2003 12:19: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 MAA07481 for ; Tue, 10 Jun 2003 12:19:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Plon-00006X-00 for pilc@ietf.org; Tue, 10 Jun 2003 12:17:53 -0400 Received: from nit.isi.edu ([128.9.160.116]) by ietf-mx with esmtp (Exim 4.12) id 19Plon-00006U-00 for pilc@ietf.org; Tue, 10 Jun 2003 12:17:53 -0400 Received: (from falk@localhost) by nit.isi.edu (8.11.6/8.11.6) id h5AGJtG20415 for pilc@ietf.org; Tue, 10 Jun 2003 09:19:55 -0700 Date: Tue, 10 Jun 2003 09:19:55 -0700 From: Aaron Falk To: pilc@ietf.org Message-ID: <20030610161955.GI6577@isi.edu> Mail-Followup-To: pilc@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Subject: [pilc] test message -- please ignore Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , mail list test... _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From pilc-admin@ietf.org Fri Jun 13 12:45:19 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11543 for ; Fri, 13 Jun 2003 12:45:19 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D663a30806; Fri, 13 Jun 2003 02:06:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D65cm29155 for ; Fri, 13 Jun 2003 02:05: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 CAA15825 for ; Fri, 13 Jun 2003 02:05:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qhem-0001W4-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:03:24 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19Qhel-0001Vw-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:03:24 -0400 Received: from isi.edu ([206.117.105.46]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5D65O109449; Thu, 12 Jun 2003 23:05:24 -0700 (PDT) Message-ID: <3EE96988.2010100@isi.edu> Date: Thu, 12 Jun 2003 23:04:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk CC: pilc@ietf.org, mankin@psg.com Subject: Re: [pilc] IESG Review of LINK References: <3EE5B7B1.1D82A6CD@erg.abdn.ac.uk> In-Reply-To: <3EE5B7B1.1D82A6CD@erg.abdn.ac.uk> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dr G Fairhurst wrote: > See in-line comments... > > Allison Mankin wrote: > >>Phil, Mark, PILC WG, >> >>The IESG reviewed LINK and had comments that should be addressed with changes. >>These are in the id-tracker, but they are among a lot of material, >>not all of which does need addressing. Below are the comments that do. >>Those from the Security ADs are simple textual fixes, but the comment from >>Alex Zinin, one of the Routing ADs, wants the WG to re-look significantly >>at Section 17 - I support Alex's points, though cellphone handoffs do complement >>IP level routing and one would not want them to take place at IP level. >>There should be some way to write about both this sort of routing tradeoff >>and Alex's issues in the section. >> >>Allison >> >>-------- >>>From Steve Bellovin: >>Section 6: Should there be mention of switches that snoop on IGMP? I >>suspect so. >> > > > I'd be happy to work on some text for this, is anyone able to work with > me to check sanity and wording? Please let me know! I'll pitch in on that (Gorry - I recall we worked on some of that section before). >>-------- >>>From Alex Zinin: >> >>I didn't know how to formulate my concerns at first, because it >>appeared that in addition to being not quite correct in some places, >>the discussion in text actually goes in a wrong direction, and >>touches on some seemingly irrelevant points without discussing those >>that should have been. >> >>So, I decided to start with comments on the actual text and then >>move to the meta question... >> >> > 17 Routing >> > > > > <> > >> With the same number of nodes, routing scales better if it operates >> over the physical topology rather than when it's layered up. >> >> > Some subnetworks have special features that allow the use of more >> > effective or responsive routing mechanisms that cannot be >> > implemented in IP because of its need for generality. One example >> > is the self-learning bridge algorithm widely used in Ethernet >> > networks. Another is the "handoff" mechanism in cellular telephone >> > networks, particularly the "soft handoff" scheme in IS-95 CDMA. >> >> Those who ran a large-enough bridged network with STP would hardly >> agree with the statement that Ethernet bridging is more effective >> and responsive. > > OK, Spanning Tree has a reputation of being a pain when trying > to converge. > > But, IMHO simple "Learning Bridges" provide a very efficient way > to send Ethernet frames to the place were they are needed. > This uses the L2 (MAC) source address in the frame header > without the need to configure or maintain routing information. > > Handovers in 802.11 and cellular radio utilise information not > visible at the IP level - such as base station capability and > signal strength. Are there more things we should add to the list? > > I wonder if the words "special features" are simply too vague > to be useful, if we give some concrete examples, then we have > a better basis for the paragraph. IMO, IP expects shared links to act shared. Sure - the link layer _can_ be more efficient and do switching, even routing (or optimize multicast as above). But that presumes that the group within which switching occurs is considered as a single shared link to IP. Further, many L2 protocols don't scale either with the number of nodes or as propagation delays increase (L2 emulation tries to patch over these, but it's clearly a patch). Perhaps we need to say that: 1) L2 routing should occur on timescales faster than IP routing to be useful together (?) 2) L2 routing should happen within what IP considers a shared link In particular, addresses moving around at the link layer that end up changing what IP thinks of as a "link" Joe _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From mailnull@www1.ietf.org Fri Jun 13 12:55:49 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12033 for ; Fri, 13 Jun 2003 12:55:49 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DGtMC30963 for pilc-archive@odin.ietf.org; Fri, 13 Jun 2003 12:55:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DGtMm30960 for ; Fri, 13 Jun 2003 12:55: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 MAA11967 for ; Fri, 13 Jun 2003 12:55:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qrnb-0006hX-00 for pilc-web-archive@ietf.org; Fri, 13 Jun 2003 12:53:11 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Qrnb-0006hT-00 for pilc-web-archive@ietf.org; Fri, 13 Jun 2003 12:53:11 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D663a30806; Fri, 13 Jun 2003 02:06:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D65cm29155 for ; Fri, 13 Jun 2003 02:05: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 CAA15825 for ; Fri, 13 Jun 2003 02:05:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qhem-0001W4-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:03:24 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19Qhel-0001Vw-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:03:24 -0400 Received: from isi.edu ([206.117.105.46]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5D65O109449; Thu, 12 Jun 2003 23:05:24 -0700 (PDT) Message-ID: <3EE96988.2010100@isi.edu> Date: Thu, 12 Jun 2003 23:04:56 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gorry@erg.abdn.ac.uk CC: pilc@ietf.org, mankin@psg.com Subject: Re: [pilc] IESG Review of LINK References: <3EE5B7B1.1D82A6CD@erg.abdn.ac.uk> In-Reply-To: <3EE5B7B1.1D82A6CD@erg.abdn.ac.uk> X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dr G Fairhurst wrote: > See in-line comments... > > Allison Mankin wrote: > >>Phil, Mark, PILC WG, >> >>The IESG reviewed LINK and had comments that should be addressed with changes. >>These are in the id-tracker, but they are among a lot of material, >>not all of which does need addressing. Below are the comments that do. >>Those from the Security ADs are simple textual fixes, but the comment from >>Alex Zinin, one of the Routing ADs, wants the WG to re-look significantly >>at Section 17 - I support Alex's points, though cellphone handoffs do complement >>IP level routing and one would not want them to take place at IP level. >>There should be some way to write about both this sort of routing tradeoff >>and Alex's issues in the section. >> >>Allison >> >>-------- >>>From Steve Bellovin: >>Section 6: Should there be mention of switches that snoop on IGMP? I >>suspect so. >> > > > I'd be happy to work on some text for this, is anyone able to work with > me to check sanity and wording? Please let me know! I'll pitch in on that (Gorry - I recall we worked on some of that section before). >>-------- >>>From Alex Zinin: >> >>I didn't know how to formulate my concerns at first, because it >>appeared that in addition to being not quite correct in some places, >>the discussion in text actually goes in a wrong direction, and >>touches on some seemingly irrelevant points without discussing those >>that should have been. >> >>So, I decided to start with comments on the actual text and then >>move to the meta question... >> >> > 17 Routing >> > > > > <> > >> With the same number of nodes, routing scales better if it operates >> over the physical topology rather than when it's layered up. >> >> > Some subnetworks have special features that allow the use of more >> > effective or responsive routing mechanisms that cannot be >> > implemented in IP because of its need for generality. One example >> > is the self-learning bridge algorithm widely used in Ethernet >> > networks. Another is the "handoff" mechanism in cellular telephone >> > networks, particularly the "soft handoff" scheme in IS-95 CDMA. >> >> Those who ran a large-enough bridged network with STP would hardly >> agree with the statement that Ethernet bridging is more effective >> and responsive. > > OK, Spanning Tree has a reputation of being a pain when trying > to converge. > > But, IMHO simple "Learning Bridges" provide a very efficient way > to send Ethernet frames to the place were they are needed. > This uses the L2 (MAC) source address in the frame header > without the need to configure or maintain routing information. > > Handovers in 802.11 and cellular radio utilise information not > visible at the IP level - such as base station capability and > signal strength. Are there more things we should add to the list? > > I wonder if the words "special features" are simply too vague > to be useful, if we give some concrete examples, then we have > a better basis for the paragraph. IMO, IP expects shared links to act shared. Sure - the link layer _can_ be more efficient and do switching, even routing (or optimize multicast as above). But that presumes that the group within which switching occurs is considered as a single shared link to IP. Further, many L2 protocols don't scale either with the number of nodes or as propagation delays increase (L2 emulation tries to patch over these, but it's clearly a patch). Perhaps we need to say that: 1) L2 routing should occur on timescales faster than IP routing to be useful together (?) 2) L2 routing should happen within what IP considers a shared link In particular, addresses moving around at the link layer that end up changing what IP thinks of as a "link" Joe _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From pilc-admin@ietf.org Fri Jun 13 13:18:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13863 for ; Fri, 13 Jun 2003 13:18:48 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D6a1a09572; Fri, 13 Jun 2003 02:36:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D6Zsm09561 for ; Fri, 13 Jun 2003 02:35: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 CAA22654 for ; Fri, 13 Jun 2003 02:35:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qi88-0001zU-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:33:44 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19Qi87-0001zR-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:33:43 -0400 Received: from isi.edu ([206.117.105.46]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5D6Zn123806; Thu, 12 Jun 2003 23:35:50 -0700 (PDT) Message-ID: <3EE970A1.4080606@isi.edu> Date: Thu, 12 Jun 2003 23:35:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mankin@psg.com CC: pilc@ietf.org, zinin@psg.com Subject: Re: [pilc] IESG Review of LINK References: In-Reply-To: X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Some comments on Allison's original context: Allison Mankin wrote: >>From Alex Zinin: > > I didn't know how to formulate my concerns at first, because it > appeared that in addition to being not quite correct in some places, > the discussion in text actually goes in a wrong direction, and > touches on some seemingly irrelevant points without discussing those > that should have been. > > So, I decided to start with comments on the actual text and then > move to the meta question... > > > 17 Routing > > > > Many subnetworks provide their own internal routing mechanisms. > > The text should probably say why some do and some don't. E.g., if a > subnetwork technology can be used to construct a multi-node network, > where internal nodes do not run IP, and where the network is > self-contained and can be used for service independent from IP > routing, then subnetwork-level routing function is usually provided > (FR, ATM, Ethernet bridging and STP). If the technology is primarily > used for single-hop packet framing among IP nodes, subnetwork-level > routing is not needed. The issue isn't whether it's a multi-node network; the issue is whether the media is switched or not. Possible text: (?) -------------------------------- Multipoint subnetworks may be single-hop or multi-hop. In either case, IP considers the subnetwork as a single shared link, i.e., IP assumes there is one or more subnetwork addresses that can broadcast to all nodes on the subnetwork with one subnetwork packet. IP also assumes that multi-hop multipoint subnetworks provide their own routing, such that IP can inject the subnetwork packet with the appropriate destination subnetwork address, with no further path information. -------------------------------- > > Since routing is the major function of the Internet layer, the > > question naturally arises as to the proper division of function > > between routing at the Internet layer and routing in the subnet. > > and the text does not address this question, nor does it talk > about the interactions among the routing function within the > subnetwork and at the IP level. I believe the above addresses the interaction - i.e., that in general IP assumes there is NO interaction, that the subnetwork can be considered a single shared link and be done. > > In general, routing in a subnetwork and at IP is more > > complementary than competitive. Routing algorithms often have > > difficulty scaling to very large networks, and a division of labor > > between IP and a large subnetwork can often make the routing > > problem more tractable for both. > > In fact, experience shows that this is exactly the opposite. > > When a large number of IP routers is connected via a subnetwork that > hides internal routing details from IP, this usually results in O(N^2) > adjacencies, flooding storms, and unforeseen convergence interactions. > In most cases, the physical topology of a subnetwork is orders of > magnitude simpler than the logical IP topology on top of it. This is > because the topology graph within the subnetwork is determined by > physical links and nodes, while the topology graph at the IP level is > essentially driven by the connectivity matrix. But the link connectivity matrix is insufficient to express the reachability of IP addresses, which is what IP needs to compute. > With the same number of nodes, routing scales better if it operates > over the physical topology rather than when it's layered up. Link routing doesn't scale when viewed as a transit; in that case, the link subnet looks more like an AS, and IP routing convergence faulters when interior routing protocols (e.g., ones that assume broadcast or multicast) are used over a multihop subnetwork. These are good reasons not to use large-scale subnetworks as transits in dynamically routed IP networks, or to better manage the route advertisements in a BGP-like fashion. ... > OK, meta issues now. > > What I would expect this section to talk about is: > > 1. Difference between the _function_ of IP routing and the routing > function found in some subnetworks and analysis of why > certain subnetwork technologies have the routing function. (see contributed paragraph above) > 2. Give a recommendation that unless there is a very compelling > reason, routing should be left to IP. (see contributed paragraph above) > 3. If the routing function is still implemented in the subnetwork > technology, explain what considerations should be kept in mind: > > a) Connectivity graph and its affects on IP routing, such as: > - number of adjacencies/sessions per router to maintain > - broadcast & connectivity (if routing treats the subnet as > broadcast, any-to-any connectivity needs to be ensured) > - flooding implications > - ... Perhaps a paragraph warning about how transit subnetworks end up looking like AS's ;-)?? > b) Rerouting, convergence and timing with multiple layers: > - effects of topology change and rerouting within subnetwork > on IP routing (e.g., if the subnetwork has slow rerouting, > IP will start reconverging) > > - effects of reconvergence at the IP level on the subnet > (e.g. dynamic connection establishment) > > - combination of the two This hits a different concept. IP doesn't really like having links appear and disappear; it expects the subnetwork to be largely static. That point might be useful to raise (?). > c) Connection model for connection-oriented subnetworks > > If the model assumes temporary connectivity between > nodes (e.g., PSTN or ISDN) how will this affect IP routing > (adjacencies going up/down, applicability of e.g. demand circuit > extension in OSPF) Such systems can be 'faked' by having routing proxies on both sides of the idle links that lie about reachability, and connect only when there is traffic in place. I.e., when the links are made on-demand, it can be useful to let IP consider the links as always there, and kill the proxies only when connection establishment fails. > d) Optimality and traffic engineering > > it's addressed in the text to some extent, but more thought > should be given to such aspects as how traffic engineering > within the network (pure IP and MPLS) would be done, i.e., > is it just "enough BW", or the subnetwork provides TE > functionality as in ATM, for example... Shifting sands again. ;-) Joe _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From mailnull@www1.ietf.org Fri Jun 13 13:33:04 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14931 for ; Fri, 13 Jun 2003 13:33:03 -0400 (EDT) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5DHWaH26914 for pilc-archive@odin.ietf.org; Fri, 13 Jun 2003 13:32:36 -0400 Received: from ietf.org (lists.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5DHWam26911 for ; Fri, 13 Jun 2003 13:32: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 NAA14908 for ; Fri, 13 Jun 2003 13:32:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19QsNd-0007Rw-00 for pilc-web-archive@ietf.org; Fri, 13 Jun 2003 13:30:25 -0400 Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19QsNc-0007Rt-00 for pilc-web-archive@ietf.org; Fri, 13 Jun 2003 13:30:24 -0400 Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D6a1a09572; Fri, 13 Jun 2003 02:36:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5D6Zsm09561 for ; Fri, 13 Jun 2003 02:35: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 CAA22654 for ; Fri, 13 Jun 2003 02:35:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Qi88-0001zU-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:33:44 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx with esmtp (Exim 4.12) id 19Qi87-0001zR-00 for pilc@ietf.org; Fri, 13 Jun 2003 02:33:43 -0400 Received: from isi.edu ([206.117.105.46]) by boreas.isi.edu (8.11.6p2/8.11.2) with ESMTP id h5D6Zn123806; Thu, 12 Jun 2003 23:35:50 -0700 (PDT) Message-ID: <3EE970A1.4080606@isi.edu> Date: Thu, 12 Jun 2003 23:35:13 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mankin@psg.com CC: pilc@ietf.org, zinin@psg.com Subject: Re: [pilc] IESG Review of LINK References: In-Reply-To: X-Enigmail-Version: 0.74.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some comments on Allison's original context: Allison Mankin wrote: >>From Alex Zinin: > > I didn't know how to formulate my concerns at first, because it > appeared that in addition to being not quite correct in some places, > the discussion in text actually goes in a wrong direction, and > touches on some seemingly irrelevant points without discussing those > that should have been. > > So, I decided to start with comments on the actual text and then > move to the meta question... > > > 17 Routing > > > > Many subnetworks provide their own internal routing mechanisms. > > The text should probably say why some do and some don't. E.g., if a > subnetwork technology can be used to construct a multi-node network, > where internal nodes do not run IP, and where the network is > self-contained and can be used for service independent from IP > routing, then subnetwork-level routing function is usually provided > (FR, ATM, Ethernet bridging and STP). If the technology is primarily > used for single-hop packet framing among IP nodes, subnetwork-level > routing is not needed. The issue isn't whether it's a multi-node network; the issue is whether the media is switched or not. Possible text: (?) -------------------------------- Multipoint subnetworks may be single-hop or multi-hop. In either case, IP considers the subnetwork as a single shared link, i.e., IP assumes there is one or more subnetwork addresses that can broadcast to all nodes on the subnetwork with one subnetwork packet. IP also assumes that multi-hop multipoint subnetworks provide their own routing, such that IP can inject the subnetwork packet with the appropriate destination subnetwork address, with no further path information. -------------------------------- > > Since routing is the major function of the Internet layer, the > > question naturally arises as to the proper division of function > > between routing at the Internet layer and routing in the subnet. > > and the text does not address this question, nor does it talk > about the interactions among the routing function within the > subnetwork and at the IP level. I believe the above addresses the interaction - i.e., that in general IP assumes there is NO interaction, that the subnetwork can be considered a single shared link and be done. > > In general, routing in a subnetwork and at IP is more > > complementary than competitive. Routing algorithms often have > > difficulty scaling to very large networks, and a division of labor > > between IP and a large subnetwork can often make the routing > > problem more tractable for both. > > In fact, experience shows that this is exactly the opposite. > > When a large number of IP routers is connected via a subnetwork that > hides internal routing details from IP, this usually results in O(N^2) > adjacencies, flooding storms, and unforeseen convergence interactions. > In most cases, the physical topology of a subnetwork is orders of > magnitude simpler than the logical IP topology on top of it. This is > because the topology graph within the subnetwork is determined by > physical links and nodes, while the topology graph at the IP level is > essentially driven by the connectivity matrix. But the link connectivity matrix is insufficient to express the reachability of IP addresses, which is what IP needs to compute. > With the same number of nodes, routing scales better if it operates > over the physical topology rather than when it's layered up. Link routing doesn't scale when viewed as a transit; in that case, the link subnet looks more like an AS, and IP routing convergence faulters when interior routing protocols (e.g., ones that assume broadcast or multicast) are used over a multihop subnetwork. These are good reasons not to use large-scale subnetworks as transits in dynamically routed IP networks, or to better manage the route advertisements in a BGP-like fashion. ... > OK, meta issues now. > > What I would expect this section to talk about is: > > 1. Difference between the _function_ of IP routing and the routing > function found in some subnetworks and analysis of why > certain subnetwork technologies have the routing function. (see contributed paragraph above) > 2. Give a recommendation that unless there is a very compelling > reason, routing should be left to IP. (see contributed paragraph above) > 3. If the routing function is still implemented in the subnetwork > technology, explain what considerations should be kept in mind: > > a) Connectivity graph and its affects on IP routing, such as: > - number of adjacencies/sessions per router to maintain > - broadcast & connectivity (if routing treats the subnet as > broadcast, any-to-any connectivity needs to be ensured) > - flooding implications > - ... Perhaps a paragraph warning about how transit subnetworks end up looking like AS's ;-)?? > b) Rerouting, convergence and timing with multiple layers: > - effects of topology change and rerouting within subnetwork > on IP routing (e.g., if the subnetwork has slow rerouting, > IP will start reconverging) > > - effects of reconvergence at the IP level on the subnet > (e.g. dynamic connection establishment) > > - combination of the two This hits a different concept. IP doesn't really like having links appear and disappear; it expects the subnetwork to be largely static. That point might be useful to raise (?). > c) Connection model for connection-oriented subnetworks > > If the model assumes temporary connectivity between > nodes (e.g., PSTN or ISDN) how will this affect IP routing > (adjacencies going up/down, applicability of e.g. demand circuit > extension in OSPF) Such systems can be 'faked' by having routing proxies on both sides of the idle links that lie about reachability, and connect only when there is traffic in place. I.e., when the links are made on-demand, it can be useful to let IP consider the links as always there, and kill the proxies only when connection establishment fails. > d) Optimality and traffic engineering > > it's addressed in the text to some extent, but more thought > should be given to such aspects as how traffic engineering > within the network (pure IP and MPLS) would be done, i.e., > is it just "enough BW", or the subnetwork provides TE > functionality as in ATM, for example... Shifting sands again. ;-) Joe _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From pilc-admin@ietf.org Wed Jun 18 14:40: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 OAA20425 for ; Wed, 18 Jun 2003 14:40:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ShHs-0005s7-UU; Wed, 18 Jun 2003 14:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMx0-0007Nk-9z for pilc@optimus.ietf.org; Tue, 17 Jun 2003 16:21: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 QAA09118 for ; Tue, 17 Jun 2003 16:21:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMul-0004Uk-00 for pilc@ietf.org; Tue, 17 Jun 2003 16:18:47 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19SMuk-0004Uh-00 for pilc@ietf.org; Tue, 17 Jun 2003 16:18:46 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19SMwt-000Ni3-00; Tue, 17 Jun 2003 20:20:59 +0000 Date: Tue, 17 Jun 2003 13:20:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <158181639233.20030617132038@psg.com> To: Joe Touch CC: mankin@psg.com, pilc@ietf.org Subject: Re: [pilc] IESG Review of LINK In-Reply-To: <3EE970A1.4080606@isi.edu> References: <3EE970A1.4080606@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Joe, >> > 17 Routing >> > >> > Many subnetworks provide their own internal routing mechanisms. >> >> The text should probably say why some do and some don't. E.g., if a >> subnetwork technology can be used to construct a multi-node network, >> where internal nodes do not run IP, and where the network is >> self-contained and can be used for service independent from IP >> routing, then subnetwork-level routing function is usually provided >> (FR, ATM, Ethernet bridging and STP). If the technology is primarily >> used for single-hop packet framing among IP nodes, subnetwork-level >> routing is not needed. > The issue isn't whether it's a multi-node network; the issue is whether > the media is switched or not. Switching is a consequence of the decision to provide the routing function within a network, and one doesn't need routing for a single-link technology... Anyways, this is not a terribly important argument here. > Possible text: (?) > -------------------------------- > Multipoint subnetworks may be single-hop or multi-hop. In either case, > IP considers the subnetwork as a single shared link, i.e., IP assumes > there is one or more subnetwork addresses that can broadcast to all > nodes on the subnetwork with one subnetwork packet. IP also assumes that > multi-hop multipoint subnetworks provide their own routing, such that IP > can inject the subnetwork packet with the appropriate destination > subnetwork address, with no further path information. > -------------------------------- The "single link" and "broadcast" assumption above are not always correct. One could model connectivity through a cloud as a set of p2p, p2mp, and broadcast-emulation logical segments. Also, in many subnetwork technologies there no broadcast capabilities (so-called NBMA.) >> > Since routing is the major function of the Internet layer, the >> > question naturally arises as to the proper division of function >> > between routing at the Internet layer and routing in the subnet. >> >> and the text does not address this question, nor does it talk >> about the interactions among the routing function within the >> subnetwork and at the IP level. > I believe the above addresses the interaction - i.e., that in general IP > assumes there is NO interaction, that the subnetwork can be considered a > single shared link and be done. I don't believe this is correct. >> > In general, routing in a subnetwork and at IP is more >> > complementary than competitive. Routing algorithms often have >> > difficulty scaling to very large networks, and a division of labor >> > between IP and a large subnetwork can often make the routing >> > problem more tractable for both. >> >> In fact, experience shows that this is exactly the opposite. >> >> When a large number of IP routers is connected via a subnetwork that >> hides internal routing details from IP, this usually results in O(N^2) >> adjacencies, flooding storms, and unforeseen convergence interactions. >> In most cases, the physical topology of a subnetwork is orders of >> magnitude simpler than the logical IP topology on top of it. This is >> because the topology graph within the subnetwork is determined by >> physical links and nodes, while the topology graph at the IP level is >> essentially driven by the connectivity matrix. > But the link connectivity matrix is insufficient to express the > reachability of IP addresses, which is what IP needs to compute. I meant connectivity matrix of the subnetwork. My point was that "division of labor" mentioned in the text, does NOT make the routing problem "more tractable". In fact, it makes it worse. >> With the same number of nodes, routing scales better if it operates >> over the physical topology rather than when it's layered up. > Link routing doesn't scale when viewed as a transit; in that case, the > link subnet looks more like an AS, and IP routing convergence faulters > when interior routing protocols (e.g., ones that assume broadcast or > multicast) are used over a multihop subnetwork. > These are good reasons not to use large-scale subnetworks as transits in > dynamically routed IP networks, or to better manage the route > advertisements in a BGP-like fashion. Frankly, didn't have a clear feeling whether you agree or disagree with me. >> OK, meta issues now. >> >> What I would expect this section to talk about is: >> >> 1. Difference between the _function_ of IP routing and the routing >> function found in some subnetworks and analysis of why >> certain subnetwork technologies have the routing function. > (see contributed paragraph above) >> 2. Give a recommendation that unless there is a very compelling >> reason, routing should be left to IP. > (see contributed paragraph above) didn't see text trying to address this >> 3. If the routing function is still implemented in the subnetwork >> technology, explain what considerations should be kept in mind: >> >> a) Connectivity graph and its affects on IP routing, such as: >> - number of adjacencies/sessions per router to maintain >> - broadcast & connectivity (if routing treats the subnet as >> broadcast, any-to-any connectivity needs to be ensured) >> - flooding implications >> - ... > Perhaps a paragraph warning about how transit subnetworks end up looking > like AS's ;-)?? hmmmm... I think not... It would be better for the doc to discuss IGPs, as we normally have IGPs running on top of a subnetwork. >> b) Rerouting, convergence and timing with multiple layers: >> - effects of topology change and rerouting within subnetwork >> on IP routing (e.g., if the subnetwork has slow rerouting, >> IP will start reconverging) >> >> - effects of reconvergence at the IP level on the subnet >> (e.g. dynamic connection establishment) >> >> - combination of the two > This hits a different concept. IP doesn't really like having links > appear and disappear; it expects the subnetwork to be largely static. > That point might be useful to raise (?). Right, from the IGP perspective, a change in topology is a transient event and stable topology is the normal condition. Note however, that the issues above are related to the interaction of the routing functions. >> c) Connection model for connection-oriented subnetworks >> >> If the model assumes temporary connectivity between >> nodes (e.g., PSTN or ISDN) how will this affect IP routing >> (adjacencies going up/down, applicability of e.g. demand circuit >> extension in OSPF) > Such systems can be 'faked' by having routing proxies on both sides of > the idle links that lie about reachability, and connect only when there > is traffic in place. I.e., when the links are made on-demand, it can be > useful to let IP consider the links as always there, and kill the > proxies only when connection establishment fails. Basically, yes. I would recommend studying the approaches that RIP and OSPF took for Demand Circuit extensions. The fundamental concept is presumption of reachability and fake adjacencies. >> d) Optimality and traffic engineering >> >> it's addressed in the text to some extent, but more thought >> should be given to such aspects as how traffic engineering >> within the network (pure IP and MPLS) would be done, i.e., >> is it just "enough BW", or the subnetwork provides TE >> functionality as in ATM, for example... > Shifting sands again. ;-) :) Quite concrete, actually. The question is "how do I manage available BW of the subnetwork?" Alex _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/ From exim@www1.ietf.org Wed Jun 18 14:48:43 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20854 for ; Wed, 18 Jun 2003 14:48:43 -0400 (EDT) Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5IImGi31668 for pilc-archive@odin.ietf.org; Wed, 18 Jun 2003 14:48:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Shqi-0007cc-HL for pilc-web-archive@optimus.ietf.org; Wed, 18 Jun 2003 14:40: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 OAA20380 for ; Wed, 18 Jun 2003 14:39:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ShoQ-0007nT-00 for pilc-web-archive@ietf.org; Wed, 18 Jun 2003 14:37:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ShoQ-0007nP-00 for pilc-web-archive@ietf.org; Wed, 18 Jun 2003 14:37:38 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ShHs-0005s7-UU; Wed, 18 Jun 2003 14:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19SMx0-0007Nk-9z for pilc@optimus.ietf.org; Tue, 17 Jun 2003 16:21: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 QAA09118 for ; Tue, 17 Jun 2003 16:21:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19SMul-0004Uk-00 for pilc@ietf.org; Tue, 17 Jun 2003 16:18:47 -0400 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 19SMuk-0004Uh-00 for pilc@ietf.org; Tue, 17 Jun 2003 16:18:46 -0400 Received: from psg.com ([147.28.0.62] helo=127.0.0.1) by psg.com with esmtp (Exim 3.36 #1) id 19SMwt-000Ni3-00; Tue, 17 Jun 2003 20:20:59 +0000 Date: Tue, 17 Jun 2003 13:20:38 -0700 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <158181639233.20030617132038@psg.com> To: Joe Touch CC: mankin@psg.com, pilc@ietf.org Subject: Re: [pilc] IESG Review of LINK In-Reply-To: <3EE970A1.4080606@isi.edu> References: <3EE970A1.4080606@isi.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: pilc-admin@ietf.org Errors-To: pilc-admin@ietf.org X-BeenThere: pilc@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Performance Implications of Link Characteristics IETF Working Group List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Joe, >> > 17 Routing >> > >> > Many subnetworks provide their own internal routing mechanisms. >> >> The text should probably say why some do and some don't. E.g., if a >> subnetwork technology can be used to construct a multi-node network, >> where internal nodes do not run IP, and where the network is >> self-contained and can be used for service independent from IP >> routing, then subnetwork-level routing function is usually provided >> (FR, ATM, Ethernet bridging and STP). If the technology is primarily >> used for single-hop packet framing among IP nodes, subnetwork-level >> routing is not needed. > The issue isn't whether it's a multi-node network; the issue is whether > the media is switched or not. Switching is a consequence of the decision to provide the routing function within a network, and one doesn't need routing for a single-link technology... Anyways, this is not a terribly important argument here. > Possible text: (?) > -------------------------------- > Multipoint subnetworks may be single-hop or multi-hop. In either case, > IP considers the subnetwork as a single shared link, i.e., IP assumes > there is one or more subnetwork addresses that can broadcast to all > nodes on the subnetwork with one subnetwork packet. IP also assumes that > multi-hop multipoint subnetworks provide their own routing, such that IP > can inject the subnetwork packet with the appropriate destination > subnetwork address, with no further path information. > -------------------------------- The "single link" and "broadcast" assumption above are not always correct. One could model connectivity through a cloud as a set of p2p, p2mp, and broadcast-emulation logical segments. Also, in many subnetwork technologies there no broadcast capabilities (so-called NBMA.) >> > Since routing is the major function of the Internet layer, the >> > question naturally arises as to the proper division of function >> > between routing at the Internet layer and routing in the subnet. >> >> and the text does not address this question, nor does it talk >> about the interactions among the routing function within the >> subnetwork and at the IP level. > I believe the above addresses the interaction - i.e., that in general IP > assumes there is NO interaction, that the subnetwork can be considered a > single shared link and be done. I don't believe this is correct. >> > In general, routing in a subnetwork and at IP is more >> > complementary than competitive. Routing algorithms often have >> > difficulty scaling to very large networks, and a division of labor >> > between IP and a large subnetwork can often make the routing >> > problem more tractable for both. >> >> In fact, experience shows that this is exactly the opposite. >> >> When a large number of IP routers is connected via a subnetwork that >> hides internal routing details from IP, this usually results in O(N^2) >> adjacencies, flooding storms, and unforeseen convergence interactions. >> In most cases, the physical topology of a subnetwork is orders of >> magnitude simpler than the logical IP topology on top of it. This is >> because the topology graph within the subnetwork is determined by >> physical links and nodes, while the topology graph at the IP level is >> essentially driven by the connectivity matrix. > But the link connectivity matrix is insufficient to express the > reachability of IP addresses, which is what IP needs to compute. I meant connectivity matrix of the subnetwork. My point was that "division of labor" mentioned in the text, does NOT make the routing problem "more tractable". In fact, it makes it worse. >> With the same number of nodes, routing scales better if it operates >> over the physical topology rather than when it's layered up. > Link routing doesn't scale when viewed as a transit; in that case, the > link subnet looks more like an AS, and IP routing convergence faulters > when interior routing protocols (e.g., ones that assume broadcast or > multicast) are used over a multihop subnetwork. > These are good reasons not to use large-scale subnetworks as transits in > dynamically routed IP networks, or to better manage the route > advertisements in a BGP-like fashion. Frankly, didn't have a clear feeling whether you agree or disagree with me. >> OK, meta issues now. >> >> What I would expect this section to talk about is: >> >> 1. Difference between the _function_ of IP routing and the routing >> function found in some subnetworks and analysis of why >> certain subnetwork technologies have the routing function. > (see contributed paragraph above) >> 2. Give a recommendation that unless there is a very compelling >> reason, routing should be left to IP. > (see contributed paragraph above) didn't see text trying to address this >> 3. If the routing function is still implemented in the subnetwork >> technology, explain what considerations should be kept in mind: >> >> a) Connectivity graph and its affects on IP routing, such as: >> - number of adjacencies/sessions per router to maintain >> - broadcast & connectivity (if routing treats the subnet as >> broadcast, any-to-any connectivity needs to be ensured) >> - flooding implications >> - ... > Perhaps a paragraph warning about how transit subnetworks end up looking > like AS's ;-)?? hmmmm... I think not... It would be better for the doc to discuss IGPs, as we normally have IGPs running on top of a subnetwork. >> b) Rerouting, convergence and timing with multiple layers: >> - effects of topology change and rerouting within subnetwork >> on IP routing (e.g., if the subnetwork has slow rerouting, >> IP will start reconverging) >> >> - effects of reconvergence at the IP level on the subnet >> (e.g. dynamic connection establishment) >> >> - combination of the two > This hits a different concept. IP doesn't really like having links > appear and disappear; it expects the subnetwork to be largely static. > That point might be useful to raise (?). Right, from the IGP perspective, a change in topology is a transient event and stable topology is the normal condition. Note however, that the issues above are related to the interaction of the routing functions. >> c) Connection model for connection-oriented subnetworks >> >> If the model assumes temporary connectivity between >> nodes (e.g., PSTN or ISDN) how will this affect IP routing >> (adjacencies going up/down, applicability of e.g. demand circuit >> extension in OSPF) > Such systems can be 'faked' by having routing proxies on both sides of > the idle links that lie about reachability, and connect only when there > is traffic in place. I.e., when the links are made on-demand, it can be > useful to let IP consider the links as always there, and kill the > proxies only when connection establishment fails. Basically, yes. I would recommend studying the approaches that RIP and OSPF took for Demand Circuit extensions. The fundamental concept is presumption of reachability and fake adjacencies. >> d) Optimality and traffic engineering >> >> it's addressed in the text to some extent, but more thought >> should be given to such aspects as how traffic engineering >> within the network (pure IP and MPLS) would be done, i.e., >> is it just "enough BW", or the subnetwork provides TE >> functionality as in ATM, for example... > Shifting sands again. ;-) :) Quite concrete, actually. The question is "how do I manage available BW of the subnetwork?" Alex _______________________________________________ pilc mailing list pilc@ietf.org https://www1.ietf.org/mailman/listinfo/pilc http://www.ietf.org/html.charters/pilc-charter.html http://pilc.grc.nasa.gov/