I Have some comments I will just list:

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...? 

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...

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/... 

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 varous n-tuple permutations, has merit.   So I think it is useful to work on this notion (!)

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.  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 ineffiecient:  first, managing large groups of [virtual] endpoints is a data base issue, and nothing we are thinking of exceeds present database capabalities to do this.  Second, there are effieicent ways to optimize the management o 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.  :-)
  
Thanks!
Jerry

On 5/10/12 8:58 AM, Aaron Brown wrote:

On May 9, 2012, at 5:37 PM, Freek Dijkstra wrote:

On Labels:

What we have defined are "resource labels", eg.:
* Ethernet VLAN
* Ethernet I-SID
* Frequency on DWDM / Wavelength on CWDM
* ATM VPC
* ATM VPI
* SONET/SDH STS3c/STM/AUG-1 timeslot
* MPLS shim label
perhaps even:
* SSID on a wifi
* strand in a fiber bundle
* ...

This label is used for both:
* distinguishing between flows on a link (aka channels)
* routing and switching (eg. "switch X will forward data from port 1,
label 28 to port 4, label 42")


So far so good.
Now two issues.

1. On PortGroups:

I assume that each Port is associated with a particular label. This is
useful for monitoring, so we can distinguish between e.g. VLAN 120 and
VLAN 42.

For path finding, it seem useful to describe a all possible ports (e.g.
"all VLANs that can dynamically created". For this, I propose to
introduce a "PortGroup": which logically can be expanded to many
individual Ports.

The idea is still sketchy, but I like some input if this is a good
approach. If so, I'll make a proposal.

In the OSCARS world, we've done this, using the label terminology, as "the available labels on a port". Thus, a single port might have a variety of available labels that could be used on that port. That approach makes more sense to me than introducing a new grouping concept for ports that don't currently exist.

Cheers,
Aaron




2. On Destination Labels

The "destination labels", such as destination IP address or destination
MAC address are also used for routing and switching, just like the
resource labels above.

Hence I presumed that destination labels could be described the same way
as resource labels.
I'm longer sure that this is a good idea.

Recall that each Port is associated with exactly one label.

For a host with one IP address 2001:0DB8:B4C6:6AAE::1 this means that is
has one ingress Port (for this IP address). On the other hand, it would
have 2^128-1 egress Ports (for all possible IP addresses that is can
send to).

This discrepancy between ingress Port and egress Ports seems odd to me,
and makes me doubt that destination labels are the same things as
resource labels.

As stated in my previous email, G.800 thinks it's a different beast: it
associates resource labels with the adaptation, while is associates
source- and destination labels with the termination.

That's all nice, but I'm still at loss how to describe source- and
destination labels in NML and how to deal with them. If you have any
idea (good or bad), please share it.

Freek
_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg

Internet2 Spring Member Meeting
April 22-25, 2012 - Arlington, Virginia
http://events.internet2.edu/2012/spring-mm/



_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg