[dev] Dataplane API
Lou Berger
lberger at labn.net
Wed May 30 13:11:02 EDT 2018
Olivier, Julien,
Great! Let's setup a time to talk. Drop me a line off list to
coordinate time - please suggest some times next week.
All,
drop me a line if interested in participating (I'll start a doodle
if enough are interested).
Lou
On 5/30/2018 12:57 PM, Olivier Dugeon wrote:
>
> Lou,
>
> Add Julien Meuric in the loop (PCE WG co-chair) who work with me on
> this subject.
>
> We are ready to collaborate with you to facilitate open source of your
> code.
> How can we help ?
>
> Regards
>
> Olivier
>
> Le 30/05/2018 à 17:48, Lou Berger a écrit :
>> Olivier,
>>
>> On 5/30/2018 10:24 AM, Olivier Dugeon wrote:
>>> Hi Lou, Donald,
>>>
>>> I have also in mind another use case: ROADM.
>>>
>>> Indeed, optical devices may take the opportunity of FRR to support
>>> GMPLS
>>> (OSPF-TE + RSVP-TE). In this scenario, interface i.e. optical ports are
>>> also decoupled from the control plane. Optical ports that are not
>>> yet fire
>>> up (from an optical point of view) are not forward any packets, so no
>>> routing protocol, but they must be announce at the Traffic Engineering
>>> level at least for their availability. When a light path is activated
>>> tough RSVP-TE, the signalling is received by the control plane
>>> through the
>>> management interface, but to activate a different optical interface.
>> I think this is certainly workable.
>>
>> as I think I mentioned before, LabN actually has some GMPLS-TE code
>> (including path computation and RSVP-TE) we'd love to open source,
>> but haven't found the time/support to strip out the non-source
>> compatible code and integrate with FRR.
>>
>> Lou
>>
>>
>>>
>>> Regards
>>>
>>> Olivier
>>>
>>> Le 30/05/2018 à 15:29, Lou Berger a écrit :
>>>> Thanks Donald,
>>>>
>>>> VNC/RFAPI can also be used today (with some environment specific
>>>> integration) to support controller based models such as defined in
>>>> NVO3
>>>> where forwarders (NVEs) are completely disjoint from anything else on
>>>> the controller. As has been discussed in the past, VNC/RFAPI was
>>>> designed about 10 years ago with a BGP-centric optimization approach -
>>>> and included 2 distinct parts: L3VPN VRF management and NVA style
>>>> remote
>>>> forwarder (NVE) control. We've agreed that the long term right answer
>>>> for FRR is to separate these two, where the first stays in BGP and the
>>>> second moves under zebra using FPM or it's successor (e.g., the PR
>>>> mentioned below). The first part was recently completed and is in
>>>> 5.0.
>>>> The second part remains on our todo (wish) list - and I expect will be
>>>> facilitated by Donald's work.
>>>>
>>>> Lou
>>>>
>>>> On 05/30/2018 09:19 AM, Donald Sharp wrote:
>>>>> I actually agree with both Vincent and Lou :)
>>>>>
>>>>> The current paradigm is a kernel based infrastructure and will be so
>>>>> for the foreseeable future. So if you are doing development *now* I
>>>>> would highly recommend working towards this paradigm. So Vincent is
>>>>> correct.
>>>>>
>>>>> Having said that, we are looking towards more formally defining the
>>>>> DataPlane API so that it becomes possible to allow a fully
>>>>> implemented
>>>>> dataplane api that if someone wanted to implement non-kernel based
>>>>> interfaces they could. So Lou is correct too!
>>>>>
>>>>> There is a lot of work here though, mainly of a infrastructure
>>>>> updates. I've currently (slowly) started trying to define this api(
>>>>> See https://github.com/FRRouting/frr/pull/2292 ). The current api
>>>>> line for the dataplane is fuzzy at best and lots of assumptions are
>>>>> made about behavior and how data structures are created. This line
>>>>> must be wedged apart as a first step. If you are unsure where to
>>>>> start here, please ask and we'll have suggestions. We also have
>>>>> additional goals for zebra such as true pthreads and nexthop-group
>>>>> route entry indirection to name a few.
>>>>>
>>>>> Please note we are not doing this work specifically to allow a full
>>>>> dataplane outside of a kernel, it should fall out if I do the work
>>>>> correctly for what I am interested in. I am doing this work
>>>>> because I
>>>>> think this work will allow me to do some work with route-aggregation
>>>>> as well as more efficiently pass data to the kernel for route
>>>>> installs. I'm sure other people have their own reasons, just as long
>>>>> as we keep those in mind and work together.
>>>>>
>>>>> thanks!
>>>>>
>>>>> donald
>>>>>
>>>>> On Tue, May 29, 2018 at 3:04 PM, Jay Chen
>>>>> <jchen1 at paloaltonetworks.com> wrote:
>>>>>> A quick question about FRR interfaces. The Zebra get interface
>>>>>> information/status from Kernel.
>>>>>>
>>>>>> In our platform, it is almost impossible to put interface into
>>>>>> kernel (due to history reasons people object to do so). Is there
>>>>>> anyone else facing the same situation and any suggestions for a
>>>>>> work around? Or anything similarly to FPM existing for interface
>>>>>> to bypass kernel (from interface manager to Zebra instead)?
>>>>>>
>>>>>> Thanks,
>>>>>> Jay
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> dev mailing list
>>>>> dev at lists.frrouting.org
>>>>> https://lists.frrouting.org/listinfo/dev
>>>>>
>>>> _______________________________________________
>>>> dev mailing list
>>>> dev at lists.frrouting.org
>>>> https://lists.frrouting.org/listinfo/dev
>>>
>>>
>>
>>
>
More information about the dev
mailing list