[pilc] updated routing text for draft-ietf-pilc-link-design

[Aaron Falk <[e-mail]>]

Hi PILC folks!

You may be wondering (in the deep recesses of your mind) what happened
to our document "Advice for Internet Subnet Designers".  You may
recall that we received some substantial comments from the IESG in
June.

The most significant comment was from Alex Zinin, Routing AD, on the
routing text.  Joe Touch, Gorry Fairhurst, and I have been working
with Alex since around the last IETF to get revised language worked
out.  While I am waiting for Alex to respond to (what we believe is)
an greatly improved section, it is probably (past) time for the
working group to get a chance to see the text and comment on it.  

  Keep in mind that we want to get this document out the door and so
  I'd like to encourage you to read the text below and voice either
  support for it or major concerns (e.g., inaccuracies).

Mark Allman, current holder of the editor token, will be updating
draft-...-13.txt with the responses to the IESG comments and a list of
nits (mostly found by Gorry -- Thanks!).  Once we can get the DISCUSS
votes lifted by the IESG, the doc will go to the RFC Editor.

--aaron


>> Wednesday, August 6, 2003, 2:02:50 PM, Aaron Falk wrote:
>> > Alex-
>> 
>> > I think you'll find the new text below by Joe Touch and Gorry
>> > Fairhurst responds to your comments.  I hope you find it
>> > satisifies your concerns.  I'd enclose a diff from the draft but
>> > in addressing your meta-concerns, the new text is significantly
>> > different from the original.
>> 
>> > I'm anxious to get closure on this issue so we can get this doc
>> > published.  To that end, I'd like very much to focus subsequent
>> > discussion on specific text deletions or insertions (preferably
>> > deletions) on this section.
>> 
>> > As the text has changed so substantially, once you're comfortable
>> > with it I'll be circulating it by the wg mailing list (who are
>> > currently unaware of the text changes).  With your permission, I
>> > plan to keep you cc'ed on that exchange in case further changes
>> > result.
>> 
>> > --aaron
>> 
>> 
>> > ----------------------------------------------------------------
>> 
>> > (insert new paragraph after the first paragraph of sec 1:)
>> 
>> 
>> > This document defines a subnetwork as a layer 2 network, that is
>> > a network that does not rely upon the services of IP routers to
>> > forward packets between parts of the subnetwork. Sometimes, it is
>> > convenient to aggregate a group of such subnetworks into a single
>> > logical subnetwork. IP routing protocols (e.g., OSPF, IS-IS, and
>> > PIM) can be configured to support this aggregation, but typically
>> > present a layer 3 subnetwork rather than a layer 2
>> > subnetwork. This may also result in a specific packet passing
>> > several times over the same layer 2 subnetwork via an
>> > intermediate layer 3 gateway (router). Because that aggregation
>> > requires layer 3 components, issues thereof are beyond the scope
>> > of this document.
>> 
>> > ------------------------------------------------------------------------
>> 
>> > (new text for Routing sec 17:)
>> 
>> > Subnetworks connecting more than two systems must provide their
>> > own internal layer 2 forwarding mechanisms, either implicitly
>> > (e.g., broadcast) or explicitly (e.g., switched).  Since routing
>> > is the major function of the Internet layer, the question
>> > naturally arises as to the interaction between routing at the
>> > Internet layer and routing in the subnet, and proper division of
>> > function between the two.
>> 
>> > Layer 2 subnetworks can be point-to-point, connecting two
>> > systems, or multipoint.  Multipoint subnetworks can be broadcast
>> > (e.g., shared media or emulated) or non-broadcast.  Generally, IP
>> > considers multipoint subnetworks as broadcast, with shared-media
>> > Ethernet as the canonical (and historical) example, and
>> > point-to-point subnetworks as a degenerate case.  Non-broadcast
>> > subnetworks may require additional mechanisms, e.g., above IP at
>> > the routing layer [1].
>> 
>> > IP is ignorant of the topology of the subnetwork layer. In
>> > particular, reconfiguration of subnetwork paths is not tracked by
>> > the IP layer.  IP is only affected by whether it can send/receive
>> > packets sent to the remotely connected systems via the subnetwork
>> > interface (i.e. the reachability from one router to another). IP
>> > further considers that subnetworks are largely static - that both
>> > their membership and existance are stable at routing timescales
>> > (tens of seconds); both events are considered re-provisioning,
>> > rather than routing.
>> 
>> > Routing in a subnetwork interfaces to address resolution (e.g.,
>> > ARP) at the IP layer, rather than directly interacting with
>> > network layer routing.  Where broadcast is provided or explicitly
>> > emulated, address resolution can be used directly; where not
>> > provided, the link layer routing may interface to a protocol for
>> > resolution, e.g., to the Next-Hop Resolution Protocol [RFC2322]
>> > to provide context-dependent address resolution capabilities.
>> 
>> > Subnetwork routing can either complement or compete with IP
>> > routing.  It complements IP when a subnetwork encapsulates its
>> > internal routing, and where the effects of that routing are not
>> > noticible at the IP layer.  However, if different paths in the
>> > subnetwork have characteristics that affect IP routing, it can
>> > affect or even inhibit the convergence of IP routing.
>> 
>> > Routing protocols generally consider layer 2 subnetworks, i.e.,
>> > with subnet masks and no intermediate IP hops, to have uniform
>> > routing metrics to all members.  Routing can break when a link's
>> > characteristics do not match the routing metric, in this case,
>> > e.g., when some member pairs have different path
>> > characteristics. Consider a virtual Ethernet subnetwork that
>> > includes both nearby (sub-millisecond latency) and remote (100's
>> > of milliseconds away) systems. Presenting that group as a single
>> > subnetwork means that some routing protocols will assume that all
>> > pairs have the same delay, and that it is small. Because this is
>> > not the case, the routing tables constructed may be suboptimal or
>> > may even fail to converge.
>> 
>> > When subnetworks are used as a transit among a set of routers,
>> > they conventionally provide the equivalent of a full mesh of
>> > point-to-point links. Simplicity of the internal subnet structure
>> > can be used (e.g., via NHRP [RFC2332]) to reduce the size of
>> > address resolution tables, but routing exchanges will continue to
>> > reflect the full-mesh they emulate. In general, subnetworks
>> > should not be used as a transit among a set of routers where
>> > routing protocols would break if a full mesh of equivalent
>> > point-to-point links were used.
>> 
>> > 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. Learning bridges encapsulate Ethernet routing, avoiding
>> > the need for dynamic routing at each subnetwork hop.  Another is
>> > the "handoff" mechanism in cellular telephone networks,
>> > particularly the "soft handoff" scheme in IS-95 CDMA.
>> 
>> > Subnetworks that cover large geographic areas or include links of
>> > widely varying capabilities should be avoided. IP routing
>> > generally considers all multipoint subnets equivalent to a local,
>> > shared-media link with uniform metrics between any pair of
>> > systems, and ignores internal subnetwork topology. Where a
>> > subnetwork diverges from that assumption, it is the subnetwork
>> > designers obligation to provide compensating mechanisms. Not
>> > doing so can affect the scalability and convergence of IP
>> > routing, as noted above.
>> 
>> > The subnetwork designer who decides to implement internal routing
>> > should consider whether a custom routing algorithm is warranted,
>> > or if an existing Internet routing algorithm or protocol may
>> > suffice.  They should consider whether they are intending to
>> > reduce the address resolution table size (possible, but with
>> > additional protocol support required), or trying to reduce
>> > routing table complexity.  The latter may be better achieved by
>> > partitioning the subnetwork, either physically or logically, and
>> > using network layer protocols to support partitioning (e.g., AS's
>> > in BGP). Protocols and routing algorithms can be notoriously
>> > subtle, complex and difficult to implement correctly.  Much work
>> > can be avoided if an existing protocol or existing
>> > implementations can be readily used.
>> 
>> > -----------------------------------------------------------------
>> 
>> > [1]*** Refs to resolve .... 
>> 
>> >   (we could refer to RFCs and/or a book? - e.g. Khalid Raza &
>> >   Mark Turner, "Large-Scale IP Network Solution", CISCO Press,
>> >   2000.)

----- End forwarded message -----

_______________________________________________
pilc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/