[BGPCEP-271] Investigate possibility of component registry in BGP FS Created: 24/Aug/15  Updated: 03/Mar/19  Due: 13/Jan/16  Resolved: 10/Feb/16

Status: Resolved
Project: bgpcep
Component/s: BGP
Affects Version/s: Bugzilla Migration
Fix Version/s: Bugzilla Migration

Type: Improvement
Reporter: Dana Kutenicsova Assignee: Jeff Liu
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All



 Description   

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.



 Comments   
Comment by Jeff Liu [ 23/Oct/15 ]

Hi Dana,

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.?

I'll appreciate it if you can elaborate on that with details so I can be more clear about your design ideas. Thanks!

Thanks,
Jeff

Comment by Dana Kutenicsova [ 23/Oct/15 ]

Hi Jeff,
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 https://tools.ietf.org/html/rfc5575#section-4
Dana

Comment by Jeff Liu [ 29/Oct/15 ]

Sorry for the delay. That sounds good to me. I''ll sync up with Milos and get it started.

Comment by Milos Fabian [ 11/Nov/15 ]

Since "parser-spi" cannot depend on "flowspec" module, we are not able to add component type registry there.
The best we can do until the code freeze is to define an "inner registry" (maps) for BGP-FS IPv4/Ipv6 components encoders/decoders.

Comment by Jeff Liu [ 14/Nov/15 ]

Milos,
can you elaborate on the "inner registry"? any example to help me understand how to correctly implement that?

Thanks,
Jeff

Comment by Milos Fabian [ 16/Nov/15 ]

Hi Jeff,
"inner registry" - maps holding flowspec components encoders/decoders.
A parser might be identified by component type# and serializer by "case" class of component type (per yang module).
When FS NLRI is being encoded/decoded, proper parser/serializer will be picked from registry.

Comment by Dana Kutenicsova [ 19/Nov/15 ]

Inner registry can do just fine (didn't realize the reversed dependency). It will clear the AbstractFSNlriParser and will make the parsers extendable.

Comment by Jeff Liu [ 24/Nov/15 ]

https://git.opendaylight.org/gerrit/#/c/30102, get the first draft for Milos and the team to review and provide feedback.
The wiring to BGPActivator and the additional handlers for other components, as well as unittests are underway.

Comment by Jeff Liu [ 14/Dec/15 ]

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.

Comment by Milos Fabian [ 14/Dec/15 ]

(In reply to Jeff Liu from comment #9)
> 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.

Hi Jeff,
path was rebased, verify job failed due to compilation errors related to your changes.

Comment by Jeff Liu [ 14/Dec/15 ]

Thanks for the rebase, Milos. I see a build error specifically to flowspec. I'll look into it. Thanks.

Comment by Jeff Liu [ 14/Dec/15 ]

hi Milos,
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.

Am I missing another rebase?

Thanks,
Jeff

Comment by Milos Fabian [ 10/Feb/16 ]

https://git.opendaylight.org/gerrit/#/c/30102/

Generated at Wed Feb 07 19:12:32 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.