[prev in list] [next in list] [prev in thread] [next in thread]
List: quagga-dev
Subject: [quagga-dev 8008] Re: rib and vrf roadmap?
From: Balaji G <balajig81 () gmail ! com>
Date: 2010-05-24 13:10:55
Message-ID: AANLkTinHWVJW5S-U1yog-oe6G2kqx0SW-3cv4hXuR4S4 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Paul
>I think we first need to cleanup the RIB, to make it maintainable. To that
end, it'd be good if people working on the RIB chose to >base it on existing
cleanup branches, such as the above. Then perhaps they could help with
proving the cleanup was good. But I >can't force that.
We now have separate RIBs per Sub address family so which means our V4
Unicast and V4 Multicast and so on stores only specific routes. For the VR
from the BGP and RIB perspective we need to create that many RIBs based on
the VR-ID as its going to be unique but i believe more than the control
plane, we would need the kernel to support it, i would be really interested
to test out if there are some patches that you know in the kernel
unofficially as part of some git repo so that i could change stuff in the
control plane code for the BGP,RIB and give it a shot
Thanks,
Cheers,
- Balaji
On Mon, May 24, 2010 at 5:18 PM, <paul@jakma.org> wrote:
> Hi,
>
>
> On Thu, 1 Apr 2010, Henderson, Thomas R wrote:
>
> from a post last September:
>>
>
> Can you please update the status of the above branch? I am adding RFC
>> 4915 support (MTR) for OSPFv2 and would like to know what is the roadmap for
>> vrf and rib work in quagga, so that I can base it against the right repo.
>>
>
> I think we first need to cleanup the RIB, to make it maintainable. To that
> end, it'd be good if people working on the RIB chose to base it on existing
> cleanup branches, such as the above. Then perhaps they could help with
> proving the cleanup was good. But I can't force that.
>
> The roadmap ought to be:
>
> 1. Cleanup the existing RIB
> - get rid of the duplicated code
> - document its design
> - more tests (functional rigs and, ideally, unit tests)
> 2. Move to shared next-hops
> 3. Get the dependency updates worked out (the simplest way is a
> scanner, but if there are neater ways..)
>
> I don't have priorities after that.
>
> I have a month or two this summer where I might try work on that, perhaps.
>
>
> If anyone else has an update on the plan for VRFs and multiple instances, I
>> am curious about that too.
>>
>
> I don't think there's a plan for VRFs at the moment. It'd be nice to have I
> guess, and we could design it into the RIB after the above.
>
> Multi-instances - you mean for OSPF? I don't think there's anyone planning
> on it at the moment. The easiest way might be to add some kind of "claim an
> interface:subnet" command to Zserv. Perhaps.
>
> regards,
> --
> Paul Jakma paul@jakma.org Key ID: 64A2FF6A
> Fortune:
> Youth is such a wonderful thing. What a crime to waste it on children.
> -- George Bernard Shaw
>
> _______________________________________________
> Quagga-dev mailing list
> Quagga-dev@lists.quagga.net
> http://lists.quagga.net/mailman/listinfo/quagga-dev
>
[Attachment #5 (text/html)]
<div>Hi Paul</div>
<div> </div>
<div>>I think we first need to cleanup the RIB, to make it maintainable. To that \
end, it'd be good if people working on the RIB chose to >base it on existing \
cleanup branches, such as the above. Then perhaps they could help with proving the \
cleanup was good. But I >can't force that.</div>
<div> </div>
<div>We now have separate RIBs per Sub address family so which means our V4 Unicast \
and V4 Multicast and so on stores only specific routes. For the VR from the BGP and \
RIB perspective we need to create that many RIBs based on the VR-ID as its going to \
be unique but i believe more than the control plane, we would need the kernel to \
support it, i would be really interested to test out if there are some patches that \
you know in the kernel unofficially as part of some git repo so that i could change \
stuff in the control plane code for the BGP,RIB and give it a shot </div>
<div> </div>
<div>Thanks,</div>
<div>Cheers,</div>
<div> - Balaji<br></div>
<div class="gmail_quote">On Mon, May 24, 2010 at 5:18 PM, <span dir="ltr"><<a \
href="mailto:paul@jakma.org">paul@jakma.org</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: \
#ccc 1px solid">Hi, <div class="im"><br><br>On Thu, 1 Apr 2010, Henderson, Thomas R \
wrote:<br><br> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px \
0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">from a post last \
September:<br></blockquote><br></div> <div class="im">
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; \
BORDER-LEFT: #ccc 1px solid">Can you please update the status of the above branch? \
I am adding RFC 4915 support (MTR) for OSPFv2 and would like to know what is the \
roadmap for vrf and rib work in quagga, so that I can base it against the right \
repo.<br> </blockquote><br></div>I think we first need to cleanup the RIB, to make it \
maintainable. To that end, it'd be good if people working on the RIB chose to \
base it on existing cleanup branches, such as the above. Then perhaps they could help \
with proving the cleanup was good. But I can't force that.<br> <br>The roadmap \
ought to be:<br><br>1. Cleanup the existing RIB<br> - get rid of the duplicated \
code<br> - document its design<br> - more tests (functional rigs and, ideally, \
unit tests)<br>2. Move to shared next-hops<br> 3. Get the dependency updates worked \
out (the simplest way is a<br> scanner, but if there are neater ways..)<br><br>I \
don't have priorities after that.<br><br>I have a month or two this summer where \
I might try work on that, perhaps. <div class="im"><br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; \
BORDER-LEFT: #ccc 1px solid">If anyone else has an update on the plan for VRFs and \
multiple instances, I am curious about that too.<br> </blockquote><br></div>I \
don't think there's a plan for VRFs at the moment. It'd be nice to have I \
guess, and we could design it into the RIB after the above.<br><br>Multi-instances - \
you mean for OSPF? I don't think there's anyone planning on it at the moment. \
The easiest way might be to add some kind of "claim an interface:subnet" \
command to Zserv. Perhaps.<br> <br>regards,<br><font color="#888888">-- <br>Paul \
Jakma <a href="mailto:paul@jakma.org" target="_blank">paul@jakma.org</a> \
Key ID: 64A2FF6A<br>Fortune:<br>Youth is such a wonderful thing. What a crime to \
waste it on children.<br>
-- George Bernard Shaw</font>
<div>
<div></div>
<div class="h5"><br>_______________________________________________<br>Quagga-dev \
mailing list<br><a href="mailto:Quagga-dev@lists.quagga.net" \
target="_blank">Quagga-dev@lists.quagga.net</a><br><a \
href="http://lists.quagga.net/mailman/listinfo/quagga-dev" \
target="_blank">http://lists.quagga.net/mailman/listinfo/quagga-dev</a><br> \
</div></div></blockquote></div><br>
_______________________________________________
Quagga-dev mailing list
Quagga-dev@lists.quagga.net
http://lists.quagga.net/mailman/listinfo/quagga-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic