frr/doc/developer/index.rst

FRRouting Developer's Guide
===========================

.. toctree::
   :maxdepth: 2

   workflow
   building
   packaging
   process-architecture
   library
   fuzzing
   tracing
   testing
   bgpd
   fpm
   grpc
   ospf
   zebra
   vtysh
   pathd
doc: update doc titles Should be a bit easier to Google this way. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2018-05-09 16:44:08 +02:00			`FRRouting Developer's Guide`
			`===========================`
doc: sample code-doc in .rst+sphinx Signed-off-by: David Lamparter <equinox@opensourcerouting.org> 2017-08-08 10:30:37 +02:00
			`.. toctree::`
			`:maxdepth: 2`

doc: begin developer's manual * Move doc/code/ -> doc/developer/ * Move disparate code documentation to doc/developer/ * Convert Markdown docs to reStructuredText * Organize docs into Sphinx tree * Move build docs -> doc/developer/ * Change build doc titles to fit under Building subsection of manual Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2017-12-08 17:47:49 +01:00			`workflow`
doc: make ospf section With OSPF API and OSPF-SR docs as subsections. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2018-03-14 20:44:28 +01:00			`building`
doc: move Debian packaging docs to dev docs Updated the doc to cross-reference build documentation as well and reformatted to RST. Removed stub section on how to configure daemons and whatnot, as that's the domain of the user docs. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2018-05-09 21:12:07 +02:00			`packaging`
doc: add documentation on threading & process arch Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2018-05-01 01:54:40 +02:00			`process-architecture`
doc: sample code-doc in .rst+sphinx Signed-off-by: David Lamparter <equinox@opensourcerouting.org> 2017-08-08 10:30:37 +02:00			`library`
doc: add docs on fuzzing stuff Signed-off-by: Quentin Young <qlyoung@nvidia.com> 2020-11-09 21:08:02 +01:00			`fuzzing`
doc: add developer docs for tracing Signed-off-by: Quentin Young <qlyoung@nvidia.com> 2020-09-29 02:12:41 +02:00			`tracing`
doc: move topotests docs to developers guide Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2019-02-05 20:22:38 +01:00			`testing`
doc: more organizing & updating * Add chapter on BGPD * Add diagram for git workflow * Convert next-hop tracking documents to ReST * Update & organize workflow document * Move ldpd docs back up to the parent directory Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2017-12-09 00:22:26 +01:00			`bgpd`
doc: update FPM documentation Tell users about new FPM implementation and add more documentation about it. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org> 2020-04-16 21:26:51 +02:00			`fpm`
doc: initial documentation for gRPC Give the FRR users some examples of gRPC usage in scripts to let them start experimenting with the new configuration interface provided by YANG/northbound. Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org> 2020-08-09 23:04:30 +02:00			`grpc`
doc: make ospf section With OSPF API and OSPF-SR docs as subsections. Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2018-03-14 20:44:28 +01:00			`ospf`
			`zebra`
doc: add dev doc for vtysh Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com> 2018-10-29 04:00:24 +01:00			`vtysh`
pathd: New SR-TE policy management daemon This new daemon manages Segment-Routing Traffic-Engineering (SR-TE) Policies and installs them into zebra. It provides the usual yang support and vtysh commands to define or change SR-TE Policies. In a nutshell SR-TE Policies provide the possibility to steer traffic through a (possibly dynamic) list of Segment Routing segments to the endpoint of the policy. This list of segments is part of a Candidate Path which again belongs to the SR-TE Policy. SR-TE Policies are uniquely identified by their color and endpoint. The color can be used to e.g. match BGP communities on incoming traffic. There can be multiple Candidate Paths for a single policy, the active Candidate Path is chosen according to certain conditions of which the most important is its preference. Candidate Paths can be explicit (fixed list of segments) or dynamic (list of segment comes from e.g. PCEP, see below). Configuration example: segment-routing traffic-eng segment-list SL index 10 mpls label 1111 index 20 mpls label 2222 ! policy color 4 endpoint 10.10.10.4 name POL4 binding-sid 104 candidate-path preference 100 name exp explicit segment-list SL candidate-path preference 200 name dyn dynamic ! ! ! There is an important connection between dynamic Candidate Paths and the overall topic of Path Computation. Later on for pathd a dynamic module will be introduced that is capable of communicating via the PCEP protocol with a PCE (Path Computation Element) which again is capable of calculating paths according to its local TED (Traffic Engineering Database). This dynamic module will be able to inject the mentioned dynamic Candidate Paths into pathd based on calculated paths from a PCE. https://tools.ietf.org/html/draft-ietf-spring-segment-routing-policy-06 Co-authored-by: Sebastien Merle <sebastien@netdef.org> Co-authored-by: Renato Westphal <renato@opensourcerouting.org> Co-authored-by: GalaxyGorilla <sascha@netdef.org> Co-authored-by: Emanuele Di Pascale <emanuele@voltanet.io> Signed-off-by: Sebastien Merle <sebastien@netdef.org> 2020-07-31 18:04:20 +02:00			`pathd`