Subject: [pilc] IESG Review of LINK

From: Allison Mankin <[email-masked]>
Date: Mon, 09 Jun 2003 15:57:59 -0700

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/

---

From: Dr G Fairhurst <[email-masked]>
Date: Tue, 10 Jun 2003 11:49:22 +0100

See in-line comments...

> Section 6: Should there be mention of switches that snoop on IGMP? I

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!

<<snip>>

> move to the meta question...

<<snip>>

>  agree with the statement that Ethernet bridging is more effective

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.

---

From: Dr G Fairhurst <[email-masked]>
Date: Tue, 10 Jun 2003 11:49:22 +0100

See in-line comments...

<<snip>>

<<snip>>

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Jun 2003 23:04:56 -0700

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

> 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

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Jun 2003 23:04:56 -0700

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Jun 2003 23:35:13 -0700

Some comments on Allison's original context:

>  used for single-hop packet framing among IP nodes, subnetwork-level

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

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

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

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

...
>       certain subnetwork technologies have the routing function.

(see contributed paragraph above)

>       reason, routing should be left to IP.

(see contributed paragraph above)

>                broadcast, any-to-any connectivity needs to be ensured)

Perhaps a paragraph warning about how transit subnetworks end up looking 
like AS's ;-)??

>                (e.g. dynamic connection establishment)

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

>          (adjacencies going up/down, applicability of e.g. demand circuit

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.

>            functionality as in ATM, for example...

Shifting sands again. ;-)

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 12 Jun 2003 23:35:13 -0700

Possible text: (?)

...

Joe

---

From: Alex Zinin <[email-masked]>
Date: Tue, 17 Jun 2003 13:20:38 -0700

Joe,

> 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: (?)

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

> single shared link and be done.

I don't believe this is correct.

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

> advertisements in a BGP-like fashion.

Frankly, didn't have a clear feeling whether you agree or disagree
with me.

> (see contributed paragraph above)

didn't see text trying to address this

> Perhaps a paragraph warning about how transit subnetworks end up looking 

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.

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

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

> Shifting sands again. ;-)

:) Quite concrete, actually. The question is "how do I manage
available BW of the subnetwork?"

Alex

---

From: Alex Zinin <[email-masked]>
Date: Tue, 17 Jun 2003 13:20:38 -0700

Joe,

Alex