[Nsi-wg] Service definitions (draft) for Point-to-Point Ethernet
John MacAuley
john.macauley at surfnet.nl
Thu Jul 11 11:16:20 EDT 2013
Here is another good question - now that we have some additional flexibility on specifying elements in the reserve request, do we want to specify the attributes directly that we want to modify? For example…
<nsi:reserve xmlns:nsi="http://schemas.ogf.org/nsi/2013/04/connection/types"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p2p="http://schemas.ogf.org/nsi/2013/04/services/point2point"
xmlns:surf="http://schemas.surfnet.nl/nsi/2013/04/services">
<connectionId>urn:uuid:4b4a71d0-3c71-47cf-a646-beacb14a4c72</connectionId>
<criteria version="2">
<p2p:capacity>1000</bandwidth>
</criteria>
</nsi:reserve>
On 2013-07-11, at 11:03 AM, John MacAuley <john.macauley at surfnet.nl> wrote:
> Henrik,
>
> Your comments on topology and capability discovery is a good one. My primary concerns at the moment is what we have is very oriented around point-topoint ethernet and many unwritten assumptions. I was discussing the service offering issue with Chin yesterday, and it is obvious we will have to address this quickly as new services are added if we want the solution to scale beyond hand managing it.
>
> John
>
> On 2013-07-11, at 10:57 AM, Guy Roberts <Guy.Roberts at dante.net> wrote:
>
>> John,
>>
>> On the basis that unidirectional and bidirectional service requests have essentially the same attributes I think we should keep these together as one service type.
>>
>> Guy
>>
>> -----Original Message-----
>> From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of John MacAuley
>> Sent: 11 July 2013 15:20
>> To: Henrik Thostrup Jensen
>> Cc: NSI Working Group
>> Subject: Re: [Nsi-wg] Service definitions (draft) for Point-to-Point Ethernet
>>
>> Just a quick question before I write this up - we are doing unidirectional and bidirectional as a single service type and not two separate?
>>
>> On 2013-07-11, at 6:30 AM, Henrik Thostrup Jensen <htj at nordu.net> wrote:
>>
>>> Hi everyone
>>>
>>> Here are high-level descriptions of suggested ethernet service definitions.
>>>
>>> These are the result of a conversation that Jerry and I had some weeks ago, along with the latest discussions on the calls. The definitions are fairly close to what we already had, but are more precise and involve some more ethernet specific attributes.
>>
>>>
>>> There are two suggestions here. One for plain ethernet, and one for vlan over ethernet. Organizing the the request types / service definitions like this makes it very clear what is going, but is also slightly less flexible than what we previously had, e.g., there is no clear way for how to provide a connection where one end is plain ethernet and the other is on a VLAN. However, as the point here is interdomain, I think simplicity is a virtue, and I don't see it as a major loss.
>>>
>>> The order of in which the attributes are listed is largely random.
>>>
>>>
>>> Point-to-Point Ethernet (suggested short name ets_v1)
>>>
>>> * Directionality := choice(Bidirectional, Unidirectional).
>>> Optional, default: Bidirecitonal Specifies if
>>> the circuit should only carry data in one direction or in both
>>> direction. If Unidirectional, data can only be carried from source to
>>> destination.
>>>
>>> * Symmetric := Boolean. Optional. Default: False
>>> Can only be specified for bidirectional circuits.
>>> If true, the circuit creates must follow the same path in both
>>> directions.
>>>
>>> * Source STP : PortType (network + port). Mandatory.
>>> Specifies the source of the data flow.
>>> Network+Port values are similar to current STP constructio.
>>>
>>> * Destination STP : PortType (network + port). Mandatory.
>>> Specifies the destination of the data flow.
>>> Network+Port values are similar to current STP constructio.
>>>
>>> * Capacity : Integer. Mandatory.
>>> Specifies the required capacity of the circuit. In Mbps.
>>> The capacity includes ethernet framing headers (because thats what
>>> Ethernet does)
>>>
>>> * MTU : Integer. Optional.
>>> Specifies the maximum transmission unit size. In bits.
>>>
>>> * Burstsize : Integer. Optional.
>>> Specifies the maximum number of bits that can be send to the
>>> interface before the sender must wait before sending again.
>>>
>>> Point-to-Point Ethernet VLAN (suggested short name evts_v1)
>>>
>>> # Includes the same attributes as the Ethernet service.
>>>
>>> * Source VLAN : Integer (1-4095). Mandatory.
>>> Specifies the VLAN for the source port.
>>>
>>> * Destination VLAN : Integer (1-4095). Mandatory.
>>> Specified the VLAN for destination port.
>>>
>>>
>>> I suggest not having any ANY elements or similar in these, as they are strict thingies.
>>>
>>>
>>>
>>> * Service types and Topology
>>>
>>> Where this gets interesting, is how the service definitions mix up with the topology. At the very least we need a way to announce which service types a NSA or Network (Topology in NML lingo). I'm a bit unsure how to structure this. Just because an NSA supports a request type, doesn't mean that the network can provide it and vice versa. However IMHO it only makes sense to announce service types, which the NSA AND Network can provide. However an NSA may adminstrate multiple networks, which shakes things up a bit. I am unsure if it should be attached to the network, but leaning toward the network.
>>>
>>> Another thing to consider is if how match the service types and ports in the topology. One option is to have a mapping between labels and service types, or simply just list the service types on the ports. This would make it clear which ports could support features like jumbo frames (by having a large mtu capability). This could even be necessary for path finding.
>>>
>>> The idea of listing capabilities in the topology like this is somewhat different than the core principles in NML, which is more geared towards describing network a link and labels (plumming so to say), where using service definitions it becomes more oriented towards capability.
>>>
>>> The capability oriented approach could have some advantages in topology aggregation / scaling, where a network could announce reachability to other networks in terms of capability, i.e., nordunet can provide transit to surfnet on ethernet with the following parameters, etc. This is a lot more useful than just reachability, and compresses quite well.
>>>
>>> Thoughts?
>>>
>>>
>>> Best regards, Henrik
>>>
>>> Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>
>> _______________________________________________
>> nsi-wg mailing list
>> nsi-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nsi-wg
>>
>>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20130711/53e2046b/attachment-0001.html>
More information about the nsi-wg
mailing list