<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:826747057;
mso-list-type:hybrid;
mso-list-template-ids:2109924078 67698703 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-start-at:0;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Mark, <o:p></o:p></p>
<p class="MsoNormal">Sorry for late reply. I definitely agree with you with 2 below that interface to use management API. (refer to inline green color)<o:p></o:p></p>
<p class="MsoNormal">Thank you, <o:p></o:p></p>
<p class="MsoNormal">Jay<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Mark Stapp <mjs@voltanet.io><br>
<b>Date: </b>Monday, July 23, 2018 at 6:32 AM<br>
<b>To: </b>Jia Chen <jchen1@paloaltonetworks.com><br>
<b>Cc: </b>Lou Berger <lberger@labn.net>, Donald Sharp <sharpd@cumulusnetworks.com>, Renato Westphal <renato@opensourcerouting.org>, JP Senior <jp@apstra.com>, FRRouting-Dev <dev@lists.frrouting.org><br>
<b>Subject: </b>Re: [dev] Dataplane API<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">This is an interesting case - and I have to say that I have been focussed on the zebra-to-dataplane path, and haven't given much thought to the inbound path yet (and there are several kinds of info that flow _into_ zebra). a couple of things:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<ol style="margin-top:0in" start="0" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1">if the interfaces aren't in the kernel ... does that mean the daemons don't use them?<o:p></o:p></li></ol>
<p class="MsoListParagraph"><span style="color:#70AD47">The protocols still use them. Only the interface differs from “kernel ==</span><span style="font-family:Wingdings;color:#70AD47">è</span><span style="color:#70AD47"> Zebra ==</span><span style="font-family:Wingdings;color:#70AD47">è</span><span style="color:#70AD47">
OSPF” rather it looks like “ x-user-daemon ==</span><span style="font-family:Wingdings;color:#70AD47">è</span><span style="color:#70AD47"> Zebra ==</span><span style="font-family:Wingdings;color:#70AD47">è</span><span style="color:#70AD47"> OSPF”<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">1. the general software model that I've been trying to work with is that there will be some fairly neutral data structure that represents the information that's being exchanged between the vendor-specific and frr sides of the system. for
incoming notifications, those structures will be queued towards the main zebra processing context/pthread - the vendor plugin will be running in a different pthread/context. the transport and marshalling between your own system and frr is your own business
- a plugin will need to deal with that, and it sounds like you're already on that path. at some point, we'll add the 'interface notification' type, migrate the existing code to use it, and make it available to plugins.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">2. you used the phrase "interface configurations", and I just want to clarify that a bit. incoming configuration is going to be using the management api, imo - not some special zebra-specific path. there's work going on to provide a comprehensive
"northbound" management interface. the existence of a device is sort of a special case, and that's the case that will need some specific handling.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Mark<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Jul 20, 2018 at 5:04 PM, Jia Chen <<a href="mailto:jchen1@paloaltonetworks.com" target="_blank">jchen1@paloaltonetworks.com</a>> wrote:<o:p></o:p></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal" style="margin-bottom:12.0pt">In order to port FRR to our firewall/router platform, two things need to be differ from the current FRR paradigm. One is that we have a data plane and hardware forwarding. The other one is that we have an interface
manager for interface configurations and their up/down status update. <br>
<br>
For the first one, we are able to use FPM mechanism and successfully redirect FIB from Zebra to our data plane.<br>
Zebra(FIB via. FPM) --- routed --- data plane<br>
<br>
For interfaces, we are developing the API from “routed(IFM) to Zebra”. I would like to start the discussion here, such that our development can be aligned with FRR and can be contributed back to FRR.<br>
<br>
A. A TCP connection between Routed and Zebra, that handle bidirectional communications about request (from Zebra) and reply (from routed)<br>
B. At Zebra start/restart, requests to Routed about interfaces (interfaces, IP addresses, interface up/down status)<br>
C. Routed IFM (interface manager) reply to the requests with all interface information requested (formatted same as if it comes from kernel)<br>
D. If Routed restart (IFM), once the TCP connection re-established, routed will resend all configured interfaces to Zebra<br>
<br>
This is what we are planning to handle the interface are not in the kernel case. <br>
<br>
Please share your thought, any comments, questions, caveat, or suggestions? I remember Donald have investigated some a while back, anything we should watch for?
<br>
<br>
Thanks, <br>
Jay<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>