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

[Jerry Sobieski]

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 at ogf.org <mailto:nml-wg at 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 at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120514/7bbff042/attachment.html>