From 7935b9d21228dcd1eb95ebcb056b2a815e3e854b Mon Sep 17 00:00:00 2001 From: Pavel Tvrdik Date: Thu, 29 Sep 2016 18:08:40 +0200 Subject: Doc: Add tag for links to RFCs --- doc/bird.sgml | 238 ++++++++++++++++++++++++++-------------------------------- 1 file changed, 106 insertions(+), 132 deletions(-) (limited to 'doc/bird.sgml') diff --git a/doc/bird.sgml b/doc/bird.sgml index 159cac46..24be3de0 100644 --- a/doc/bird.sgml +++ b/doc/bird.sgml @@ -73,8 +73,8 @@ running on background which does the dynamic part of Internet routing, that is it communicates with the other routers, calculates routing tables and sends them to the OS kernel which does the actual packet forwarding. There already exist other such routing daemons: routed (RIP only), GateD (non-free), -Zebra and -MRTD , + and +, but their capabilities are limited and they are relatively hard to configure and maintain. @@ -485,9 +485,9 @@ protocol rip { used to validate route origination of BGP routes. A ROA table contains ROA entries, each consist of a network prefix, a max prefix length and an AS number. A ROA entry specifies prefixes which could be originated - by that AS number. ROA tables could be filled with data from RPKI (RFC - 6480) or from public databases like Whois. ROA tables are examined by - ) or from public databases like Whois. ROA tables are + examined by roa , which can be used to populate the ROA table with static @@ -1270,9 +1270,9 @@ clist) or on clist and pair/quad set (returning true if there is an element of the clist that is also a member of the pair/quad set).

There is one operator related to ROA infrastructure - roa_check(, which checks -current route (which should be from BGP to have AS_PATH argument) in the +examines a ROA table and does route origin validation for a +given network prefix. The basic usage is roa_check(, which +checks current route (which should be from BGP to have AS_PATH argument) in the specified ROA table and returns ROA_UNKNOWN if there is no relevant ROA, ROA_VALID if there is a matching ROA, or ROA_INVALID if there are some relevant ROAs but none of them match. There is also an extended variant @@ -1434,11 +1434,12 @@ corresponding protocol sections. Introduction

The Babel protocol (RFC6126) is a loop-avoiding distance-vector routing -protocol that is robust and efficient both in ordinary wired networks and in -wireless mesh networks. Babel is conceptually very simple in its operation and -"just works" in its default configuration, though some configuration is possible -and in some cases desirable. +

The Babel protocol +() is a loop-avoiding distance-vector routing protocol that is +robust and efficient both in ordinary wired networks and in wireless mesh +networks. Babel is conceptually very simple in its operation and "just works" +in its default configuration, though some configuration is possible and in some +cases desirable.

While the Babel protocol is dual stack (i.e., can carry both IPv4 and IPv6 routes over the same IPv6 transport), BIRD presently implements only the IPv6 @@ -1580,14 +1581,10 @@ addresses and associated interfaces. When a session changes its state, these protocols are notified and act accordingly (e.g. break an OSPF adjacency when the BFD session went down). -

BIRD implements basic BFD behavior as defined in -RFC 5880 -(some advanced features like the echo mode or authentication are not implemented), -IP transport for BFD as defined in -RFC 5881 and -RFC 5883 -and interaction with client protocols as defined in -RFC 5882. +

BIRD implements basic BFD behavior as defined in (some +advanced features like the echo mode or authentication are not implemented), IP +transport for BFD as defined in and and +interaction with client protocols as defined in .

Note that BFD implementation in BIRD is currently a new feature in development, expect some rough edges and possible UI and configuration changes @@ -1764,31 +1761,16 @@ the packet will travel through if it uses the particular route) in order to avoid routing loops.

BIRD supports all requirements of the BGP4 standard as defined in -RFC 4271 -It also supports the community attributes -(RFC 1997), -capability negotiation -(RFC 5492), -MD5 password authentication -(RFC 2385), -extended communities -(RFC 4360), -route reflectors -(RFC 4456), -graceful restart -(RFC 4724), -multiprotocol extensions -(RFC 4760), -4B AS numbers -(RFC 4893), -and 4B AS numbers in extended communities -(RFC 5668). + It also supports the community attributes (), +capability negotiation (), MD5 password authentication (), extended communities (), route reflectors (), graceful restart (), multiprotocol extensions +(), 4B AS numbers (), and 4B AS numbers in +extended communities (). For IPv6, it uses the standard multiprotocol extensions defined in -RFC 4760 -and applied to IPv6 according to -RFC 2545. + and applied to IPv6 according to . Route selection rules

Open Shortest Path First (OSPF) is a quite complex interior gateway -protocol. The current IPv4 version (OSPFv2) is defined in RFC 2328 - -and the current IPv6 version (OSPFv3) is defined in RFC 5340 - -It's a link state (a.k.a. shortest path first) protocol -- each router maintains -a database describing the autonomous system's topology. Each participating -router has an identical copy of the database and all routers run the same -algorithm calculating a shortest path tree with themselves as a root. OSPF -chooses the least cost path as the best path. +protocol. The current IPv4 version (OSPFv2) is defined in and +the current IPv6 version (OSPFv3) is defined in It's a link +state (a.k.a. shortest path first) protocol -- each router maintains a database +describing the autonomous system's topology. Each participating router has an +identical copy of the database and all routers run the same algorithm +calculating a shortest path tree with themselves as a root. OSPF chooses the +least cost path as the best path.

In OSPF, the autonomous system can be split to several areas in order to reduce the amount of resources consumed for exchanging the routing information @@ -2708,8 +2689,7 @@ protocol ospf <name> { This option controls compatibility of routing table calculation with - RFC 1583 . - Default value is no. + . Default value is no.

BIRD supports RIPv1 -(RFC 1058), -RIPv2 (RFC 2453), -RIPng (RFC 2080), -and RIP cryptographic authentication (SHA-1 not implemented) -(RFC 4822). +

BIRD supports RIPv1 (), RIPv2 (), RIPng (), and RIP cryptographic authentication (SHA-1 not implemented) +().

RIP is a very simple protocol, and it has a lot of shortcomings. Slow convergence, big network load and inability to handle larger networks makes it @@ -3707,8 +3680,9 @@ protocol rip [<name>] { compatibility with neighbors regardless of whether they use ttl security. - For RIPng, TTL security is a standard behavior (required by RFC 2080) - and therefore default value is yes. For IPv4 RIP, default value is no. + For RIPng, TTL security is a standard behavior (required by ) and therefore default value is yes. For IPv4 RIP, default + value is no.