https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/BGPCEP-271 bgpcep <p>Currently all parsing and serializing is grouped within AbstractFSNlriParser. Investigate a possibility for extending BGP parser-spi registries to add ne ComponentRegistry and create parser/serializers for each component type to decouple concepts.</p> <p>Operating System: All<br/> Platform: All</p> BGPCEP-271

Investigate possibility of component registry in BGP FS

Improvement Resolved Done Jeff Liu Dana Kutenicsova Mon, 24 Aug 2015 14:26:04 +0000 Sun, 3 Mar 2019 11:50:30 +0000 Wed, 10 Feb 2016 09:50:34 +0000 Bugzilla Migration Bugzilla Migration BGP Wed, 13 Jan 2016 00:00:00 +0000 0 3 <p>Hi Dana,</p> <p>I have a quick question about the "component" here, do you mean "flow-spec" module? or something else like address family, parameters, capabilities and etc.?</p> <p>I'll appreciate it if you can elaborate on that with details so I can be more clear about your design ideas. Thanks!</p> <p>Thanks,<br/> Jeff</p> <p>Hi Jeff,<br/> yes I mean something like adress family etc. In FS it is called directly component-type. We already have implemented extensions to FS and having a component registry would facilitate adding new component-type. Check <a href="https://tools.ietf.org/html/rfc5575#section-4" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc5575#section-4</a> <br/> Dana</p> <p>Sorry for the delay. That sounds good to me. I''ll sync up with Milos and get it started.</p> <p>Since "parser-spi" cannot depend on "flowspec" module, we are not able to add component type registry there.<br/> The best we can do until the code freeze is to define an "inner registry" (maps) for BGP-FS IPv4/Ipv6 components encoders/decoders.</p> <p>Milos,<br/> can you elaborate on the "inner registry"? any example to help me understand how to correctly implement that?</p> <p>Thanks,<br/> Jeff</p> <p>Hi Jeff,<br/> "inner registry" - maps holding flowspec components encoders/decoders.<br/> A parser might be identified by component type# and serializer by "case" class of component type (per yang module).<br/> When FS NLRI is being encoded/decoded, proper parser/serializer will be picked from registry.</p> <p>Inner registry can do just fine (didn't realize the reversed dependency). It will clear the AbstractFSNlriParser and will make the parsers extendable.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/30102" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/30102</a>, get the first draft for Milos and the team to review and provide feedback.<br/> The wiring to BGPActivator and the additional handlers for other components, as well as unittests are underway.</p> <p>The changes for flowspec ipv4handler and ipv6handler are submitted to jenknins. There is a build failure but it doesn't seem to be related to this change.</p> <p>(In reply to Jeff Liu from comment #9)<br/> &gt; The changes for flowspec ipv4handler and ipv6handler are submitted to<br/> &gt; jenknins. There is a build failure but it doesn't seem to be related to this<br/> &gt; change.</p> <p>Hi Jeff,<br/> path was rebased, verify job failed due to compilation errors related to your changes.</p> <p>Thanks for the rebase, Milos. I see a build error specifically to flowspec. I'll look into it. Thanks.</p> <p>hi Milos,<br/> I have made the fix and submitted again but only to find it failed again due to the same integration/pom.xml issue happened early. I did rebase from latest master but it didn't allow me to send "git review" because it detects no change.</p> <p>Am I missing another rebase?</p> <p>Thanks,<br/> Jeff</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/30102/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/30102/</a></p> Development External issue ID 4175 External issue URL Issue Type ODL SR Target Milestone Priority Rank 0|i02b9b: