Allow 2 hops with same interface on a single path

[ahelsing]

Stitcher gets confused by a request with 2 hops with the same URN in a path.

This happens when doing a hairpin circuit, like to connect 2 slices. In general, this is inefficient and weird. And maybe bad. But it is useful.

Would the hops always be one after the other? (Is it safer if this is true?) Or could someone want a circuit that goes out to some other switch so that switch can do routing decisions, and then comes back where it started?

Imported from trac ticket #784, created by ahelsing on 02-19-2015 at 12:40, last modified: 02-19-2015 at 14:31

[ahelsing]

• Include the hop ID when printing hops
• path.find_hop must compare more than hop urn - see where it is called from workflow.py _parse_deps and _parse_hop_deps: may not have anything else!
• see around line 585 where we hash hops by URN in allocate()
• getEGVLANRangeSuggested assumes that a given hop link URN is only once in a path
• handleDCN finds the failed hop by URN (and assumes there's only one)
• check handleVlanUnavail where it handles the OESS case and looks at hop URN
• see around line 3242 and 3287 in handleVlanUnavail where it handles a hop that is diff but same URN. Is this accurate? Does it implicitly assume this is a different path?
• logic in block around line 3327 for whether can redo here may be wrong?
• around line 3605: any hop with same urn, whether on this path or not, presumably has to exclude the failed tag?
• check the error checking around line 3751
• updateWithAvail assumes it can find the right hop to update by looking at URN only (and in check loop at end)
• workflow.py _set_hop_import_vlans_from complains if a hop says it imports from something with the same URN
• Man Combiner finds the EG hop by link URN in replaceHopLinkElement

Trac comment by ahelsing on 02-19-2015 at 14:31