Inter-OXP links

[italovalcy]

Hi,

As we discussed on slack, there are many ways of exporting the Inter-OXP links. For example, 1) each OXP could send the Port objects with a NNI attribute pointing to the other OXP's side and then the SDX-Controller "combine" the two Port objects and create a link; or even 2) each OXP could send the full Link object with incomplete information, and then the SDX-Controller "merges" the two objects. For sure, other ways also are possible.

The data model spec leaves room for the possibilities for the OXP exporting Inter-OXP links:

From page 9 of the spec:

The nni attribute is used to describe if the port is a Network to Network Interface (NNI). NNI will be used to qualify the port as an endpoint of an intra-domain (internal) or an inter-domain (external) link. If nni is not set (an empty string), the port is considered an UNI (User to Network Interface), meaning a user port. From the SDX perspective, a R&E network that is not operated by the AtlanticWave-SDX Controller is considered a user port. If the port is a NNI, there are two ways to use this field: if it is a intra-domain link, then the nni attribute must be set with the Link ID (URN to represent the Link). If the port is an inter-domain link, the nni attribute must be set with the remote OXPs Port ID. For example, if the port is a NNI part of the link "Novi03/p2_Novi02/p3" at the AmLight OXP, then the nni attribute is set to "urn:sdx:link:amlight.net:Novi03/p2_Novi02/p3". If the port is an AmLight port connected to ZAOXI OXP, via link named "sacs_sub_link" then the nni attribute on the AmLight topology side is set to "urn:sdx:link:zaoxi.ac.za:sacs_sub_link".

And then from pages 13 we have:

The type attribute describes if a Link object represents an intra-OXP link (internal) or an inter-OXP link (external). Type is an enum with acceptable values either "intra" for intra-OXP or "inter" for inter-OXP.

and from page 15 we have:

Example:

{ "id": "urn:sdx:link:amlight.net:saopaulo_miami", "name": "100G Sao Paulo to Miami", "ports":["urn:sdx:port:amlight.net:s3:s3-eth2",
"urn:sdx:port:sax.net:rt1:rt1-et-1/0/0"], "type": "inter", "bandwidth": 100, "residual_bandwidth": 50, "latency": 108, "packet_loss": 0, "availability": 100, "state": "enabled", "status": "maintenance" "private": ["packet_loss"] }

Another interpretation would be that an OXP has to provide both the Port object with nni saying it is an Inter-OXP and the Link object with the correspondent Inter-OXP link.

Either way, I'm opening this issue to discuss the specific implementation details on this and, eventually, improvement opportunities on the spec.

[YufengXin]

@italovalcy Thanks for opening this important issue. (1) My initial thought were that because inter-domain ports and the links were procured between two OXPs over a long time and would exist for long time, they should be added to the topology json files permanently, probably manually because OXP software like Kytos probably doesn't control the NNI ports. (Correct me if I am wrong.). So "nni' attributes on both sides would be sufficient. (2) Then the question of "is this too much burden" on OXPs came up over the time. My interpretation was that if these exist a way to "control/manage these inter-domain links" without bothering Kytos and OESS....? One thought I had was to create an "inter-domain" virtual OXP that manages all the inter-domain links. As needed, when inter-OXP contracts come and go, the inter-domain links can be updated via APIs by the operator (you--:) That's why I asked Jeronimo the other day who is supposed to run SDX-Controller.) Well, another benefit of having the distributed per-OXP LC.

[YufengXin]

@italovalcy The middleware can process the inter-oxp link and provision cross-oxp connection connection. As we discussed above, (1) is it still a problem for the OXPs to provide the inter-OXP link information in the topology json? (2) if so, do you think we need to create an inter-oxp sdx-LC to manage these links in a centralized fashion? (3) if not, please feed us with two examples OXP topology jsons with inter-oxp links to test and close this issue.

@sajith