[Nml-wg] PortGroups and Labels for IP/MAC

[Freek Dijkstra]

Jerry Sobieski wrote:

> a.) How would you describe a flow space?   If you are identifying VLANs
> and other virtual flow identifiers, we should consider how combinations
> of frame characteristics could identify a specific topological link (or
> "flow") Can we bind these to define a single flow identifier.  This is
> obviously a question of how NML applies in OpenFLOW architectures...?

For the theoretical background, please refer to section 7 of ITU-T
G.800. [www.itu.int/rec/T-REC-G.800].

I have a preference to use existing terminology, even if that
terminology is awkward at times. The question that this group should
answer which of the existing concepts should be included in the NML
schema, and how the elements of this schema relate to each other. A
definition discussion might be better for a research group (such as
GHPN-RG) than a work group such as NML.

NML only defines "resource labels" so far, and does not define e.g. a
"connectivity label", or "source label" or "destination label".

The question at hand is if a "resource label" is sufficient for MAC and
IP layer. I fear it is not. See the use case at
https://forge.ogf.org/sf/go/artf6557.

Your "flow identifier" seems the same as a G800 "connectivity label". If
you think you have a distinct use case, please create a practical use
case at https://forge.ogf.org/sf/go/projects.nml-wg/tracker.use_cases

If you have a proposal how to add this to NML, please create a proposal
at
https://forge.ogf.org/sf/tracker/do/listArtifacts/projects.nml-wg/tracker.tracker_title

Please note that a well documented use case still does not guarantee
that NML will support it. For the best change of acceptance by the WG,
it pays of to give an actual proposal, including UML schema
changes/additions, XML example and RDF example.

(I consider OpenFlow equal to MAC/IP in that it may look at source and
destination labels beside resource labels. I consider it different from
MAC/IP in that has a specific setup phase where the forwarding rules for
a specific flow are added to the forwarding table. I leave it up to you
what this means for a use case ;) )


> b) A similar question for optical wave bands.  Bands are variable width
> optical spectrum  rather than fixed single wave ITU channels.  They can
> be optically tuned and routed - effectively routing whole groups of
> waves.  I don't know specifically how the bands are officially defined
> (continuous frequency ranges or discrete granularity).  But there is
> hardware that support such wave bands today...

I know them as group muxes.
That's one of 3 difficulaties in describing WDM labels.
The other problems are:
* CWDM describes a label as a wavelength (with 10nm) spacing, DWDM
describes a label as a frequency. Should we allow translation between
wavelenght and frequency? Should we describe CWDM and DWDM as
incompatible technologies?
* WDWM wavelengths can have multiple spacings (100GHz, 50 GHz, 25 GHz),
and wavelengths of different spacing on the same fiber are somewhat
common. How to describe this?

For NML we opted to simply describe the properties, without adding the
logic behind it (as e.g. NDL did in the past). See the recent proposal
of Roman Łapacz. http://www.ogf.org/pipermail/nml-wg/2012-April/000941.html


> c) Has there been any discussion about the use of the TPID field
> (ethertype) in the ethernet frame for topological link characterization
> purposes?  A physical link may be hard wired to be 802.3 framed by merit
> of the interface.  But the behaviour of the frames - and sometimes the
> format of those frames - is dependent upon the Ethertype field
> (TPID).    For instance, many protocols have TPIDs reserved - IPv4,
> IPv6, ARP, tagged frames, doubly tagged frames, etc.  The implication is
> that the physical 802.3 transport framing may carry *many* different
> types of streams which are differentiated by the TPID field. Our notions
> of single VLANs as connections really means TPID=8100 && VLAN=x. 802.1Q
> VLANs and PBB are simply particular subsets of possible wire framing. 
> What is the abstract definition that NML uses to define a topologically
> significant link layer connection?     As Freek alludes, [virtual]
> labels are part of the  information that identify the topological
> link/connection/... 

Adaptation with resource labels is the abstract model we use.

You are correct that there is a shitload of potential labels which all
can influence how a data flow is handled in a network. Not to mention
all sort of stateful behaviour of network devices such as firewalls.

The fine line is:
- NML doesn't want to enforce a user to describe all labels.
- NML wants to allow a user to describe the labels he/she cares about

How to walk this fine line, we do not know yet (at least I don't).
Perhaps NML will be flexible, allow aliases or shortcuts, while a
specific application of NML, or a specific technology description may be
rigid, and demand that a certain technology is described in
this-and-that way. For example, the TPID is left out as a label, while
the version number in the IP header is described as a label. Or neither
is explicitly described (perhaps neither is relevant to either path
finding or monitoring, so why describe them).

This discussion may be more timely if we describe specific Ethernet
examples. I welcome you to make a proposal. As always:
https://forge.ogf.org/sf/go/projects.nml-wg/tracker.tracker_title


> d) The proposed notion of PortGroups sounds like it addresses an issue
> that NSI was sparring with - If an ingress/egress endpoint of a link or
> connection is identified by the topological n-tuple that uniquely
> identifies the characteristics of datagrams belonging to that "flow",
> then you have this issue of potentially thousands, or hundreds of
> thousands, of endpoints associated with each link - and different
> subsets of the n-tuple defining different groups or flows.  IMO, looking
> at the n-tuple in the abstract, and defining Ports, or port groups, as
> formal terminal groupings of various n-tuple permutations, has merit.  
> So I think it is useful to work on this notion (!)

I think both Aaron and I agree on that. The only discussion we still
have if we need a separate PortGroup concept, or can simply re-use the
existing Port concept.

My thinking is that a separate PortGroup (and perhaps also LinkGroup?)
concept is required. Perhaps it's good to talk about this in a conf call.


> e) Finally, With respect to Aaron's comments about Ports that don't
> exist (:-) (...I hope I understand the context properly...) - but they
> *do* actually exist.

I think Aaron "do not exist" remark was with respect to the introduction
of the indeed-newly-introduced "PortGroup" NML object.
Not referring to non-existing logical Ports in the real world.

> Just because they are virtual ports or virtual
> endpoints, or not yet assigned to a crossconnect does not make them
> immaterial or non-existent.  I think this goes to a widespread gut sense
> that virtual ports makes topology DBs too big...   I agree that this
> "feels" inelegant, but IMO this is not a scaling issue.  I think we
> confuse a couple issues that makes us think it all becomes intractable
> or inefficient:  first, managing large groups of [virtual] endpoints is
> a data base issue, and nothing we are thinking of exceeds present
> database capabilities to do this.  Second, there are efficient ways to
> optimize the management of these resources for sparse utilization or for
> high utilization.   Third, is pathfinding - as we increase the degree of
> fan-out of our topological nodes, we get an exponential increase in the
> theoretical time to perform a PF search - if we use the same
> O(n^3)algorithms.  So the theoretical complexity of the problem has not
> changed with increase endpoints, just our expected runtime increases. 
> Fourth, if you define a zillion endpoints in your network, it is
> presumably because you think you may need them...right?  And if you
> think there is a likelyhood that you will actually use them, then you
> still have the problem of managing them as they are allocated.  So if
> they are potential for allocation, we have to manage them, so we still
> have the problem.    Fifth, with the increase in degree of the virtual
> topological fanout, we have a problem of coherency - how do we
> communicate state changes of these endpoints to PFs in a global network
> who may want to consider using these endpoints?  It begs the question of
> - does every PF need to know about every state change or every
> endpoint?  If not, how would this work?   These are hard issues, and
> frankly these are the issues that have caused previous attempts at
> connections oriented topology management and path finding to be deemed
> impractical.  So making sure we understand how we intend to use the
> topology information is critical - and defining processes that properly
> implement those uses is far more important than worrying about the size
> of the topology DB.  IMO.  :-)

I think the rationale for looking into this problem is clear.

I have a few comments on your above text (I do think it is a scaling
issue), but for now will only say that you seem to make some assumptions
about how a Port or PortGroups maps to a node in a path finding
algorithm, and what type of algorithm is used for path finding. I think
those assumptions are not necessarily true, and may obfuscate any
discussion about path finding.

If it is OK with you, I'll answer any subsequent mail discussing path
finding off-list, as this was not the original thread of this topic.

(I'm happy to continue the discussion, but suggest to do that off-list,
and mail a summary to the NML list -- those who are interested in this
discussion, please let us know, so we can cc you)

Freek