Allow creation of EVCs for untagged UNI - support matching packets without a VLAN tag

[italovalcy]

Hi,

We should enhance mef_eline to allow the creation of EVCs for untagged UNIs, i.e., matching packets without a VLAN tag.

According to OpenFlow spec 1.3:

Omitting the OFPXMT_OFB_VLAN_VID field specifies that a flow entry should match packets regardless of whether they contain the corresponding tag. Special values are defined below for the VLAN tag to allow matching of packets with any tag, independent of the tag’s value, and to supports matching packets without a VLAN tag. The special values defined for OFPXMT_OFB_VLAN_VID are:
/* The VLAN id is 12-bits, so we can use the entire 16 bits to indicate

• special conditions.
  /
  enum ofp_vlan_id {
  OFPVID_PRESENT = 0x1000, / Bit that indicate that a VLAN id is set /
  OFPVID_NONE = 0x0000, / No VLAN id was set. */
  };

in our case, creating an EPL will work for untagged traffic, but it will end up matching much more than just untagged traffic: it will match everything in the interface.

If we try to create the EVC, I couldn't find an option to use untagged:

root@5cf51067a6e2:/# curl -H 'Content-type: application/json' -X POST http://127.0.0.1:8181/api/kytos/mef_eline/v2/evc -d '{"name": "vlan100", "dynamic_backup_path": true, "uni_a": {"tag": {"value": 0, "tag_type": 1}, "interface_id": "00:00:00:00:00:00:00:01:1"}, "uni_z": {"tag": {"value": 0, "tag_type": 1}, "interface_id": "00:00:00:00:00:00:00:03:1"}}'
{"code":400,"description":"VLAN tag 0 is not available in uni_a","name":"Bad Request"}
root@5cf51067a6e2:/# curl -H 'Content-type: application/json' -X POST http://127.0.0.1:8181/api/kytos/mef_eline/v2/evc -d '{"name": "vlan100", "dynamic_backup_path": true, "uni_a": {"tag": null, "interface_id": "00:00:00:00:00:00:00:01:1"}, "uni_z": {"tag": null, "interface_id": "00:00:00:00:00:00:00:03:1"}}'
{"code":400,"description":"The request body contains invalid API data. None for not nullable for field uni_a/tag.","name":"Bad Request"}
root@5cf51067a6e2:/# curl -H 'Content-type: application/json' -X POST http://127.0.0.1:8181/api/kytos/mef_eline/v2/evc -d '{"name": "vlan100", "dynamic_backup_path": true, "uni_a": {"tag": {}, "interface_id": "00:00:00:00:00:00:00:01:1"}, "uni_z": {"tag": {}, "interface_id": "00:00:00:00:00:00:00:03:1"}}'
{"code":400,"description":"The request body contains invalid API data. 'tag_type' is a required property for field uni_a/tag.","name":"Bad Request"}

[viniarck]

This is also related to in-band management use case.

[italovalcy]

From the OpenFlow specification, there are 4 possible scenarios for VLAN tag matching (i.e., the combinations of wildcard bits and field values for particular VLAN tag matches) in Table 12 of OF 1.3.0 [1]:

Scenario 1: Matching packets with and without a VLAN tag

Scenario 2: Matching only packets without a VLAN tag

Scenario 3: Matching only packets with a VLAN tag regardless of its value

Scenario 4: Matching only packets with VLAN tag and VID equal value

Scenario 1 is the easiest: we just need don't provide the VLAN ID. For Mef_eline this is already implemented when we create an EPL.

Scenario 4: is also already covered: we just need to create an EVPL EVC with a valid Tag value (1-4095).

Scenario 3: could be done if we accept vlan_vid as being 0 (internally, this should setup the mask). This will require some changes on the core, so that Tag value can be zero

Scenario 2: this will require more changes. From the user perspective, it could be done if we accept vlan_vid as being -1. We have to work on of_core, because it assumes the flag OFPVID_PRESENT. Probably, we would also require some changes on flow_manager and, of course, Kytos core (to accept -1) and mef_eline (range of possible values for tag value).

[1] https://opennetworking.org/wp-content/uploads/2014/10/openflow-spec-v1.3.0.pdf

[Alopalao]

As discused

• Scenario 3: Matching only packets with a VLAN tag regardless of its value
  An EVC with "tag": {"value": "any", "tag_type": 1} is posted on the API. This will result in a flow similar to:

cookie=0x0, duration=1.469s, table=0, n_packets=0, n_bytes=0, priority=1000,arp,in_port="s1-eth1",vlan_tci=0x1000/0x1000 actions=output:"s1-eth2"

Internally mef_eline will detect the value any and send a flow with dl_vlan: "4096/4096".
Matching (code) will have to be updated. Since in as_of_tlv() is expected the addition of 4095 to self.value, from_of_tlv needs to ignore 4096 otherwise will change it to 0.

• Scenario 2:Matching only packets without a VLAN tag
  An EVC with "tag": {"value": "untagged", "tag_type": 1} is posted on the API. This will result in a flow similar to:

cookie=0xaaa16d05a1189a4f, duration=2.930s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=20000,in_port="s1-eth1",vlan_tci=0x0000/0x1fff actions=push_vlan:0x88a8,output:"s1-eth3"

mef_eline will send a flow with dl_vlan: 0
Matching also needs to be adapted to serialize value to OFPVID_NONE

• Related PRs:
  of_core will be able to manage "4096/4096" and 0, PR
  flow_manager will allow masks with this PR

[viniarck]

As discused

• Scenario 3: Matching only packets with a VLAN tag regardless of its value
  An EVC with "tag": {"value": "any", "tag_type": 1} is posted on the API. This will result in a flow similar to:

cookie=0x0, duration=1.469s, table=0, n_packets=0, n_bytes=0, priority=1000,arp,in_port="s1-eth1",vlan_tci=0x1000/0x1000 actions=output:"s1-eth2"

Internally mef_eline will detect the value any and send a flow with dl_vlan: "4096/4096". Matching (code) will have to be updated. Since in as_of_tlv() is expected the addition of 4095 to self.value, from_of_tlv needs to ignore 4096 otherwise will change it to 0.

• Scenario 2:Matching only packets without a VLAN tag
  An EVC with "tag": {"value": "untagged", "tag_type": 1} is posted on the API. This will result in a flow similar to:

cookie=0xaaa16d05a1189a4f, duration=2.930s, table=0, n_packets=0, n_bytes=0, send_flow_rem priority=20000,in_port="s1-eth1",vlan_tci=0x0000/0x1fff actions=push_vlan:0x88a8,output:"s1-eth3"

mef_eline will send a flow with dl_vlan: 0 Matching also needs to be adapted to serialize value to OFPVID_NONE

• Related PRs:
  of_core will be able to manage "4096/4096" and 0, PR
  flow_manager will allow masks with this PR

Nicely done consolidating and proposing the implementation details.

Looks really great to me, it's nice how dl_vlan evolved on flow_manager too.

Regarding UNI.is_valid() are we going to accept the strings "untagged" and "any" not allocating any VLANs considering them as valid? and then when mef_eline sets tag.value as value/mask then the range is validated and consumed from available_vlans?

[Alopalao]

cc'ing:

• @gretelliz working on sdn_trace. The changes on flow_manager (branch feat/support-vlan-range) alone to support str produces an for an empty trace. I have tested the changes for sdn_trace and mef_eline and it seems that the error is solved. To reproduce such error: Run kytos, install an EVC (both uni with tags), close kytos, open kytos again and wait ~40 seconds.

• @ajoaoff working on a similar feature, vlan_range. I am using flow_manger support for str in dl_vlan

[Alopalao]

Now that we have more combinations for EVCs (range(1,4095), 0, "4096/4096", None), the flows coming out of mef_eline are more complicated. This spreadsheet presents all the possible combinations and the created flows, EVC combinations. Please feel free to change something that is incorrect. First sheet is for direct_flows from intra-switch cases and the second sheet is for push/pop flows from switch-switch cases.

[viniarck]

@Alopalao

Regarding UNI.is_valid() are we going to accept the strings "untagged" and "any" not allocating any VLANs considering them as valid? and then when mef_eline sets tag.value as value/mask then the range is validated and consumed from available_vlans?

this point here is being addressed on kytos-ng/kytos#331 for the record, so looks good.

Great spreadsheet. Overall, this feature looks very well defined. I'd like to confirm though regarding FlowMods priority as we briefly chatted. Currently, we have on mef_eline settings:

EVPL_SB_PRIORITY = 20000
EPL_SB_PRIORITY = 10000

Should we support any of these 4 configurations in the same UNI? It's probably worth confirming with @italovalcy and @jab1982, but in the same way EPL and EVPL are supported, maybe we should

I wonder if the levels of priority should be in descending order (I noticed in your spreadsheet some priorities there, but I figured it'd be easier to raise the questions here):

1. EVPL -> 20000
2. EVPL any 4096/4096 -> ? slightly lower than 20000?
3. untagged -> ? slightly greater than 10000?
4. EPL -> 10000

[italovalcy]

@Alopalao

Regarding UNI.is_valid() are we going to accept the strings "untagged" and "any" not allocating any VLANs considering them as valid? and then when mef_eline sets tag.value as value/mask then the range is validated and consumed from available_vlans?

this point here is being addressed on kytos-ng/kytos#331 for the record, so looks good.

Great spreadsheet. Overall, this feature looks very well defined. I'd like to confirm though regarding FlowMods priority as we briefly chatted. Currently, we have on mef_eline settings:

EVPL_SB_PRIORITY = 20000
EPL_SB_PRIORITY = 10000

Should we support any of these 4 configurations in the same UNI? It's probably worth confirming with @italovalcy and @jab1982, but in the same way EPL and EVPL are supported, maybe we should

I wonder if the levels of priority should be in descending order (I noticed in your spreadsheet some priorities there, but I figured it'd be easier to raise the questions here):

1. EVPL -> 20000
2. EVPL any 4096/4096 -> ? slightly lower than 20000?
3. untagged -> ? slightly greater than 10000?
4. EPL -> 10000

Hi @viniarck, good catch! IMO, we can deal with untagged with the same priority of EVPL, because it is not an overlapping matching. On the other hand, the any UNI would overlap with EVPL/untagged, and having a slightly lower priority would be interesting. My suggestion would be the following:

1. EVPL -> 20000
2. EVPL any 4096/4096 -> 15000
3. untagged -> 20000
4. EPL -> 10000

[Alopalao]

This discussion is finished and the PRs related to it are close to be merged.