[pilc] IESG Review of LINK

From: Allison Mankin (mankin@psg.com)
Date: Mon Jun 09 2003 - 18:57:59 EDT

  • Next message: 13749-06101838428670-061001111248036-06050121346487-0603212504send@aijsoft.com: "(±¤°í)Á¦ÀÏÆíÇÑ´ëÃâÁ¦ÀϽÑÀÌÀÚ·Î ¹Þ¾Æµå¸³´Ï´Ù >>13749-06101838428670-061001111248036-06050121346487-0603212504send"

    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/



    This archive was generated by hypermail 2b29 : Mon Jun 09 2003 - 19:09:10 EDT