[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
------------
3.1.1.1. "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.
3.1.1.6. "Provide A Credible Environment"
Current practice: BGP provides a mechanism for authentication and
security.
==> '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...
....
Lastly,
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..
3.1.3.3. "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
feature.
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
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
checking.
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.
editorial
---------
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
provide
==> 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 `
3.1.3.1. "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 :)
[Chiappa91]
Chiappa, N., "A New IP Routing and Addressing
Architecture", , 1991.
[Griffin99]
Griffin, T. and G. Wilfong, "An Analysis of BGP
Convergence Properties", , 1999.
==> the critical publication details seem to be missing for both
[I-D.alaettinoglu-isis-convergence]
Alaettinoglu, C., Jacobson, V., and H. Yu, "",
draft-alaettinoglu-isis-convergence-00 (work in progress),
Nov 2000.
==> title missing
[I-D.berkowitz-multirqmt]
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?)
[I-D.lang-mpls-lmp]
Lang, "Link Management Protocol", draft-lang-mpls-lmp-02
(work in progress), 2002.
==> I think this was just published as an RFC
[I-D.mcpherson-ospf-transient]
McPherson, D. and T. Przygienda, "OSPF Transient Blackhole
Avoidance", draft-mcpherson-ospf-transient-00 (work in
progress), Jul 2000.
==> more recent work on this?
[I-D.sandiick-flip]
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