Re: IESG Review of LINK

Joe Touch <[email protected]> Thu, 12 Jun 2003 23:04:56 -0700
Newsgroups gmane.ietf.pilc
Message-ID <[email protected]>
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
>> >
> 
> 
> <<snip>>
> 
>> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/