-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Telco Meeting Minutes
This page is dedicated for Telco meeting minutes using a more recent call first order to avoid scrolling on the page. Old meeting minutes will be archived if necessary to keep this page with a reasonable size.
Three main subjects were discuss during this call:
- Regarding Zebra SRv6, Olivier will ask the author of the PR #5865 to present his work during one of the next Telco meeting (15/04 or 29/04)
- Olivier made a status about on-going Segment Routing development:
- ECMP support for OSPF-SR is finished. It will be publish as PR in coming days
- Label Manager for OSPF-SR will be added in the same PR as for ECMP support as a separate commit
- IS-IS-SR enhancement is progressing (50% work done). PR will be release before next Telco meeting
- Discussion about Traffic Engineering Database as base support for BGP-LS continue from last meeting. During the call, a
new proposal for Zebra threading model was drawn and the resulting slide is available here Zebra Threading model for TE. The
main idea is add to Zebra a dedicated thread to convey Link State family routing information between producer daemons
(IS-IS, OSPF) and consumer daemons (BGP, RSVP-TE, PCE). The slide is available for modification and peoples are requested
to give their opinion and modify it if necessary. Remaining question concerns the re-synchronization (e.g. BGP restart):
- Do we keep a "cache" of the Link State RIB in this new thread and work in a "State-full" mode to simplify exchange but at the price of storage,
- or do we work in a "Stateless" mode which need to add a dedicated mechanism for re-synchro at the price of complexity Note that the solution must keep consumer daemons independent i.e. if a daemon restart e.g. BGP, the chosen mechanism must not have an impact on the another daemons (e.g. RSVP-TE)
Four subject were discuss during this call:
- Author of Zebra SRv6 finally answer telling that he is busy right now and back to the PR next month. So, the FRR community will wait until there is more information provided
- A new Pull Request (https://github.com/danos/vyatta-protocols-frr/pull/3) to integrate IS-IS in DANOS project, which embed FRR for the routing protocol stack, was discussed. Indeed, DANOS (formely vyatta) uses yang model to structure its CLI and ease translation to vtshy commands to FRR. Unfortunately, the PR ignore the FRR yang models and produce a new one which is different from the FRR IS-IS yang model, but described the same data model. It seems hard to converge between both project, first because DANOS used an old FRR release (version 6.0), and because they already have yang models (in particular for the interface) that are augment by the IS-IS yang model. Convergence will take time and FRR community decided to follow from distance DANOS while suggesting that they use the latest version of FRR. Alistaire offer to contact DANOS peoples.
- Olivier present its ideas about conveying Traffic Engineering information from routing daemon (OSPF / IS-IS) to BGP for BGP-LS and ask if ZEBRA should just play a broker role or could store a cache of these TE information. The objectives is to ease the initial transmission of the TE info from the routing daemon to BGP. In the first case, this impose a new synchronization exchange while the second is closer to the actual ZAPI interface (i.e. the same behavior used to redistribute route). Donald raise the point that ZEBRA must not be overloaded and suggest to go to the new pthread architecture for ZEBRA communication. Olivier will have a look to this new mechanism and will refine the TE code in order to have a better idea of volume and number of exchange between routing protocol and BGP this will represent.
- Finally, Segment Routing stuff was discuss. Olivier is working from home due to containment in France. So, he has not yet finish SR patch and a new request to support ECMP for OSPF take also its attention. First PR for IS-IS and OSPF will be proposed for next week
The call was mostly devoted to discuss the Pull Request #5865 about providing support to SRv6. The proposed modification has huge impact to zebra layer. Indeed, Segment Routing with IPv6 data plane is complex as it introduces a new mechanism to forward packet. In addition, if RFC 8754 which defined IPv6 SR Header has been published, there is many discussion at IETF about the SRv6 Network Programming draft https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/ (see SPRING mail archive) which the PR aims to implement. It was decided to ask the author of the PR about the roadmap and objectives of this PR to have a better understanding.
Brief status about on-going development for IS-IS Segment Routing was provided by Olivier. Due to its contribution to OpenDaylight, Olivier will provide PR next week.
BGP-LS interest was requested. For the moment, some peoples are interested by the feature, but have no plan to develop part of BGP-LS code. Olivier will re-contact people that are interested by developing such function and will share the old code that has been developed 3 years ago (on Quagga base prior to FRR project). Unfortunately, it is not possible to merge this code as is in the current FRR master. So, only new files (parser and serializer) will be publish.
A point was done about the Traffic Engineering Database. This feature is mandatory for BGP-LS but will be of interest for other part e.g. RSVP-TE, PCE. Olivier clarified how he saw the use of Traffic Engineering Database. In one side, there are daemons (IS-IS or OSPF) which are in charge to fulfil it from the TE information they receive from neighbours and what is configured on the interfaces. And in other side, daemon consumers which will have access to the TED either via ZEBRA and new ZAPI messages (e.g. BGP for BGP-LS) or directly (e.g. IS-IS for Segment Routing flexible algorithm) since the TED will be stored in the same address space as the process that will produce it e.g. IS-IS.
Olivier suggested establishing a roadmap for future developments. It may still be too early. However, it was decided to review the list of requested features listed in the FRR Wiki. Renato suggested seeing this during the weekly FRR meetings. Olivier will ask Donald to add this to the agenda of the next FRR meetings.
- Pad from 2020-02-05 call https://pads.ccc.de/SirC0aOh6x
- Pad from 2020-01-22 call: https://pads.ccc.de/frr-20200122