[Nml-wg] PortGroups and Labels for IP/MAC
Jerry Sobieski
jerry at nordu.net
Mon May 14 08:05:36 EDT 2012
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>
More information about the nml-wg
mailing list