[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] 2 RRG drafts

On Mon, 31 Oct 2005, Elwyn Davies wrote:
Trying to reconstruct history is an interesting pursuit and the historian sometimes gets it wrong! Maybe it is time I took a history degree!!

I would be interested to gather any more recollections of these early events, not necessarily for the draft, but maybe for a more detailed history in the future. Of current regular IETF attendees, I know that Sue Hares and Christian Huitema at the very least were closely involved.

I don't know the history, but here are some comments in any case..

minor issues
------------  "Route to Destination"
   Current practice:  Multihoming is not efficient and the proposed
                      inter-domain multicast protocol BGMP [RFC3913] is
                      an add-on to BGP following many of the same
                      strategies but not integrated into the BGP
                      framework .

==> BGMP is, for all intents and purposes, dead.  mcast for v4 is done with
MP-BGP, MSDP, and PIM-(S)SM.  "Provide A Credible Environment"
   Current practice:  BGP provides a mechanism for authentication and

==> 'auth and security' is an awfully large and generic concept.  More
detail is needed here.  I guess you're just referring to the _peer_ auth/sec
(through GTSM and TCP MD5), because BGP doesn't provide much else...

                      there is no support for policies other than route-
                      properties (such as AS-origin, AS-path,
                      destination prefix, MED-values etc).

==> well, the 'NOPEER' attribute deals with a particular case of business
relationships, but that doesn't mean it's implemented by the operators,
nothing automatic in any case..  "Load splitting"

   Relevance:         This should neither be a non-goal, nor an explicit
                      goal.  It might be desirable in some cases and
                      should be considered as an optional architectural

   Current practice:  Can be implemented by exporting different prefixes
                      on different links, but this requires manual
                      configuration and does not consider actual load.

==> well, this has actually caused a LOT of routing table bloat today, so if
you buy that this is a real operational requirement of the multihomed or
otherwise richly connected sites, it's pretty high on the goals list..

                    \       /
                   AS1     AS2
                      \   /

   AS3 has received its addresses from AS1, which means AS1 can
   aggregate.  But if AS3 want its traffic to be seen equally both ways,
   AS1 is forced to announce both the aggregate and the more specific
   route to AS3.

==> did you mean "AS3 is forced to announce both the aggregate and the
more specific route to AS2.", otherwise I didn't understand.

[4B as'es]
   needs to be complete and implementations available at least one
   equipment replacement cycle in advance of expected exhaustion so that
   deployement should be starting around 2008.

==> I'm not sure I understand -- 4B as's aren't a forklift upgrade, they
don't deal with hardware so a s/w update should be enough.

   o  If the NEXT HOP destination for a set of BGP routes becomes
      inaccessible because of IGP problems, the routes using the
      vanished next hop have to be invalidated at the next available
      UPDATE.  Subsequently, if the next hop route reappears, this would
      normally lead to the BGP speaker requesting a full table from its
      neighbour(s).  Current implementations may attempt to circumvent
      the effects of IGP route flap by caching the invalid routes for a
      period in case the next hop is restored.

==> actually, even RFC1771 includes the notion that if the route to the
next-hop of a BGP route disappears from the routinig table, the BGP
route immediately becomes unfeasible (the BGP session times out 90 to 180
seconds later).  That works in practise, you'll just have to be careful not
to have aggregates or default routes matching the BGP nexthops in your
routing table -- or you must exclude them from the next-hop eligibility

   o  Synchronizing in BGP means waiting for the IGP to know about the
      same networks as the EGP, which can take a significant period of
      time and slows down the convergence of BGP by adding the IGP
      convergence time into each cycle.

==> no sane operator synchronizes BGP with an IGP anymore (redistribute the
full BGP feed to IGP?  ugh...), so the text may need tweaking.

   Though DDOS attacks can be fought in a variety of ways, most
   filtering methods, it is takes constant vigilance.  There is nothing
   in the current architecture or in the protocols that serves to
   protect the forwarders from these attacks.

==> if you want cover security and/or DDoS, this needs to be much more
extensive -- this isn't helpful.


   companion document to "Requirements for Inter-Domain Routing"
   [I-D.irtf-routing-reqs], which is a discussion of requirements for

==> no refs in the abstract

   an evolutionary strategy.  The Babylon group was later folded into
   the IRTF RRG as Sub-Group B.

==>   didn't render it seems

  The kind of radical changes that have to accommodated are epitomized

==> s/to/to be/ ?

                      the resulting information.  IPv6 implementations
                      may be able to make better use of the information
                      as they may have alternative addresses that might

==> missing something at the end

                      a number of BGP speakers engaging in a cyclic
                      pattern of advertisements and withdrawals which
                      never converges to a stable result [I-D.mcpherson-
                      bgp-route-oscillation].  Perhaps this is one

==> is there a newer ref on this?

                      events of great celerity there should exist

==> extra `  "Ubiquity"

   In a sense this 'non-goal' has effectively been achieved by the
   Internet and IP protocols.  This requirement reflects a different
   worldview where there was serious competition for network protocols,
   which is really no longer the case. ....

==> I'd reorganize the text so that you start by explaining what you mean by
Ubiquity... :)

   suite Open Systems Intercnnection (OSI).  For a considerable part of

==> s/cnn/conn/

   Protocol (BGP-1) [RFC1105]was developed as a replacement, but was

==> s/was/ was/

   1.  _End-system to Intermediate system routing _(host to router), in
       which the principal functions are discovery and redirection.

==> odd endings for underlining, in the next paragraph as well.

      antithetical to routing.  Accomplishing either wilI involve a

===> s/wilI/will/

   Level 3 routing protcocol for the OSI architecture.  IDRP was

==> s/protc/prot/

   Over the next three or four years successive versions of BGP (BGP-2
   [RFC1163], BGP-3 [RFC1267] and BGP-4 [RFC1771], [I-D.ietf-idr-bgp4])

==> I'd maybe refer to bgp4 draft in some other place so that the text can't
be read that it was done in the next 3-4 years :)

   unlike it's IGP counterpart IS-IS which has stood the test of time,

==> s/it's/its/

   the net as described in [RFC3221] and Section 2.5.1 may limit the
   usefulness of auto-aggregation

==> period missing at the end

   followed by re-advertisements of many prefices.  To control the load

==> s/ces/xes/

   o  The policies that can be implemented using BGP are designed for
      control of traffic exchange between operators, not for controlling
      paths within a domain.  Policies for BGP are most conveniently
      expressed in RPSL and this could be extended if thought desirable
      to include additional policy information.

==> spelling out and forward ref to RPSL might be good here

   There are several classes of issue with current BGP policy:

==> s/issue/issues/

   While many of the issues with BPG security have been traced either to

==> s/BPG/BGP/

   Routing Policy Specification Language RPSL enables a network operator

==> s/RPSL/(RPSL)/ (though it has been used before many times..)

   Tools exist (RIPE 81, 181, 103) that can be applied on the database
   to answer requests of the form, e.g.

==> those RIPE refs are so old I wonder if they even exist anymore :)

              Chiappa, N., "A New IP Routing and Addressing
              Architecture",  , 1991.

              Griffin, T. and G. Wilfong, "An Analysis of BGP
              Convergence Properties",  , 1999.

==> the critical publication details seem to be missing for both

              Alaettinoglu, C., Jacobson, V., and H. Yu, "",
              draft-alaettinoglu-isis-convergence-00 (work in progress),
              Nov 2000.

==> title missing

              Berkowitz, H. and D. Krioukov, "To Be Multihomed:
              Requirements and Definitions",
              draft-berkowitz-multirqmt-02 (work in progress), 2002.

==> is there more recent work on this?  (maybe the multi6 WG's v4
multihoming doc?)

              Lang, "Link Management Protocol", draft-lang-mpls-lmp-02
              (work in progress), 2002.

==> I think this was just published as an RFC

              McPherson, D. and T. Przygienda, "OSPF Transient Blackhole
              Avoidance", draft-mcpherson-ospf-transient-00 (work in
              progress), Jul 2000.

==> more recent work on this?

              Sandick, H., Squire, M., Cain, B., Duncan, I., and B.
              Haberman, "Fast LIveness Protocol (FLIP)",
              draft-sandiick-flip-00 (work in progress), Feb 2000.

==> abandoned, replace with reference to BFD? (draft-ietf-bfd-base)

to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg