Re: [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?


Prem sankar G <prem.sankar.g@...>
 

Hi Yi Yang,

  Agree with you, very good points and we were also thinking on similar lines about creating small framework that can detect conflicts/provide conflict resolution.

 Also, I had brought this issue during our last ODL hackfest.  The suggestion from community was - as an interim, to create a wiki for documenting the pipeline information being used by various applications/NSFs (as a reference so that developers are cautioned about conflicts) and later address it programmatically.   I have created a draft wiki page based on your list and added VPNService table information  –

https://wiki.opendaylight.org/view/OF_pipeline

 Based on the community acceptance/TSC approval, we can formalize and request others to update this page.

Regards,

Prem

 

From: groupbasedpolicy-dev-bounces@... [mailto:groupbasedpolicy-dev-bounces@...] On Behalf Of Yang, Yi Y
Sent: Tuesday, July 14, 2015 8:24 PM
To: groupbasedpolicy-dev@...
Cc: ovsdb-dev@...; sfc-dev@...; openflowplugin-dev@...
Subject: [groupbasedpolicy-dev] How can we fix multiple masters issue better for openflowplugin?
Importance: High

 

Hi, All

 

Maybe some of you know several projects in ODL have implemented their own openflow writers for programming openflow rules, the end part of the mail are some info I collected. My question is how they work together if we install all of them? Every writer will create table 0, can it work normally? How can we fix it if not? The most important issue is they are duplicating efforts, what if we can provide a good middle layer in openflowplugin or in a separate project in order that all the operations are synchronized and coordinated? I kick off this discussion here is to let all the developers discuss it in open mind.

 

I think we can consolidate these unnecessary duplicate efforts into a separate project or part of openflowplugin, it is very necessary to provide only one entry to program openflow tables and rules, these operations must be efficiently synchronized and managed and coordinated, the direct benefits are as below:

 

1.       Fix table conflict

2.       Reduce number of tables: all the user scenarios have ingress and egress tables although they have different names or purposes

3.       Fix multiple master/writer synchronization

4.       Provide high level APIs for simplifying use for consumers

5.       Optimization will be visible for all the users (APIs consumers)

6.       Openflowplugin evolution or update will be invisible for all the users (API consumers)

7.       You can list more items here if you can imagine J

 

Welcome your great ideas and look forward to seeing we can bear fruit.

 

GBP

====

Table 0: Port Security, Ingress

Table 1: Ingress NAT Mapper

Table 2: Source Mapper

Table 3: Destination Mapper

Table 4: Policy Enforcer

Table 5: Egress NAT Mapper

Table 6: External Mapper

 

 

SFC

===

Table 0, Transport Ingress

Table 1, Path Mapper

Table 2, Next Hop

Table 10, Transport Egress

 

OVSDB Netvirt

==============

Table 0: Classifier

Table 10: Director

Table 20: Distributed ARP Responder

Table 30: DNAT for inbound floating-ip traffic

Table 40: Egress Acces-control

Table 50: Distributed LBaaS

Table 60: Distributed Virtual Routing (DVR)

Table 70: Layer 3 forwarding/lookup service

Table 80: Layer2 rewrite service

Table 90: Ingress Acces-control

Table 100: SNAT for traffic accessing external network

Table 110: Layer2 mac,vlan based forwarding

Join z.archive.ovsdb-dev@lists.opendaylight.org to automatically receive all group messages.