Subject: Re: first cut at the Routing Protocol Overload (RPO) draft

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Nov 2003 15:49:03 +0200 (EET)

On Thu, 30 Oct 2003, David Meyer wrote:
> 	A first cut at the RPO draft can be found on 
> 
> 	http://www.1-4-5.net/~dmm/draft-meyer-rpo-00.txt

In general, I think the document is very good and pretty useful.  A few
bigger comments, and more below...:

1) Does te docs need to also consider the issues loosely related to the
interference that those who want the application features aksi 
"pay the price" (either in the terms of money, or having to 
install/enable the system)  -- and not requiring the others to bear
the "fruits" of the features (refer to Rob Austein's comment about "pain
transfer protocol") ?

2) "Application fit" mainly discusses the applicability of BGP as a
transport mechanism.  This looks like a terribly limited vision.  Are there
really no other aspects of application fit than distribution??

3) I think you'll need to expand a bit on L3 Routing Information and
Reachability Information in 4.1 and 4.2, because it is not really clear what
the precise differences are.  How is reachability information not L3 routing
information ? (I can see a few ways of how not, but it'd clarify a lot if
these were spelled out..)

semi-editorial
--------------

    Examples
   include IPv6 [RFC2460], flow specification rules [FLOW], virtual
   private LAN services [VPLS], and virtual private Wire Service [VPWS].

and:

 example applications include the IPv4 routing system,
   flow specification rules [FLOW], auto-discovery mechanisms for Layer
   3 VPNs [BGPVPN], and virtual private LAN services [VPLS].

==> sync the introduction and the problem statement application lists

  Application fit refers to the matching of the requirements of the
   data to be distributed with the underlying capabilities of a
   distribution mechanism.  Broadcast, multicast and unicast
   distribution mechanisms in use today.

==> isn't tehe last sentence redundant?  or at least requires reword..

   The fate sharing principle for end to end network protocols was first
   enunciated by Dave Clark [CLARK]. As applied to software systems,
   fate sharing refers to the sharing of common resources among a group
   of applications. In our case, the particular "fate" of most interest
   is the ability of one application, call it application A, to cause an
   application with which it is fate sharing, call it application B, to
   experience one or more faults due to faults in application A. In the
   case of BGP, one way to reduce fate sharing is to run applications A
   and B in seprate BGP sessions.

==> or the most obvious ones, such as running application A (or B) outside
of the BGP in the first place, not just in separate sessions
==> s/seprate/separate/

   Finally, note that these models can have very risk profiles with
   respect to code impact and resource sharing. Some of the questions
   relating to risk assessment are considered below.

==> something missing around the first line, can't parse?

    o Do applications have to compete for resources within the  
      network (e.g., bandwidth), when the protocol session spans
      multiple hops ?

==> I don't see how protocol spanning multicast hops here?  In theory, it
should be irrelevant.  In practice, I guess the network resource reqs could
be more severe if they're very high.

    o Do applications have to compete for socket buffers, and hence
      have to potential to block or starve each other (at the TCP
      level)?

      The TCP model does not require applications to compete for
      socket level resources. It should also be possible to achieve
      this type of application independence in the BGP model with
      multi-session extensions to BGP (i.e., grouping of one or more
      AFI/SAFI per TCP session).

==> I don't really understand why you use the word "require" in these
sections.  Therefore, it's difficult to understand all of these answers. 
Consider rewording..

   [CLARK]         Clark, D., "Design Philosophy of the DARPA Internet
                   Protocols", Computer Communication Review, volume
                   25, number 1, January 1995. ISSN # 0146-4833.

==> wasn't the original statement of the fate-sharing principle a much,
much older one?

editorial
---------
   However, while the theoretical properties of BGP remains a topic of
==> s/remains/remain/ ? (not sure..)

While these concepts were
   originally described for protocols such as DVMRP [RFC1075], the bulk
   of the generalization of the NLRI described in this document derive
   from the introduction to BGP of the MP_REACH_NLRI and MP_UNREACH_NLRI
   attributes [RFC2858].

==> put "to BGP" at the end of the sentence.

   "BGP model", based on the current BGP model, provides a single point
   model is and instantiation of the GPT model.

==> s/and/an/

   assessing the difference in risk between TCP model and the BGP model
   with respect to the requirements and properties of the system
   resource sharing it they require.

==> s/it// or something else?

   Interference in the Internet routing system has it is roots in the

==> s/it is/its/

   That is, interference, if and where it occurs, has its roots protocol
   complexity and is frequently the result of application coupling.

==> can't parse, s/roots/roots in/ or something ?

   As mentioned above, risk models the robustness tradeoffs around
   generic software architecture and engineering associated with
   protocol implementations, including the impact on impact on existing 
   protocol implementations, and on the fate sharing properties of those

==> remove the second "impact on".  even with that, it still looks funny but
at least parses somehow..

      Neither the TCP model nor the BGP model (again, with    
      multi-session extensions) should be require competition for
      network resources in this case.

==> s/should be/should/ ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Nov 2003 15:49:03 +0200 (EET)

semi-editorial
--------------

    Examples

and:

editorial
---------

==> s/and/an/

==> s/it is/its/