Service definitions (draft) for Point-to-Point Ethernet
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
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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Thu, 11 Jul 2013, John MacAuley wrote:
Just a quick question before I write this up - we are doing unidirectional and bidirectional as a single service type and not two separate?
Good question. It is certainly a possiblity. One thing to be careful about is to avoid the blowup of if make it for vlan, directionality, with/without ERO, and so forth. We don't want to many of these. So I don't really know. Hmm :-| Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
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@ogf.org [mailto:nsi-wg-bounces@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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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@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@ogf.org [mailto:nsi-wg-bounces@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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
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@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@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@ogf.org [mailto:nsi-wg-bounces@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@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
You left out ERO. Was this on purpose? On 2013-07-11, at 6:30 AM, Henrik Thostrup Jensen <htj@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@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Thu, 11 Jul 2013, John MacAuley wrote:
You left out ERO.
Whoops.
Was this on purpose?
Certainly not. However, ERO it not really something that is defines a network service. It is more like special instructions to an aggregator. If you specify an ERO or not, does not really change the service you get from a network perspective. This is actually a good example of something that a network cannot provide, but a capability of an NSA(s). Should we consider putting this outside the service definition? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
On Thu, 11 Jul 2013, Henrik Thostrup Jensen wrote:
However, ERO it not really something that is defines a network service. It is more like special instructions to an aggregator. If you specify an ERO or not, does not really change the service you get from a network perspective.
This is actually a good example of something that a network cannot provide, but a capability of an NSA(s). Should we consider putting this outside the service definition?
Thought a bit more about this on the way home. The source and destination STP are really not service requirements as well, but something the service requirements should hold for. Should we consider something like seperating Path and ServiceRequirement. I.e., and object for the path (which can include an ERO), and a requirement which should hold for the path. However this is starting to get a bit hairy. I am overthinking this? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Based on the discussion so far I have created the following. I will need to factor in modify, but at the moment this should do for the discussion. I have named the service elements: p2ps - This Point-to-Point Service element is used to specify a generic point-to-point service request in the NSI CS protocol. It can be the base for layer 1 services as well. ets - This Ethernet Transport Service element is used to specify a point-to-point Ethernet service request in the NSI CS protocol. evts - This Ethernet VLAN Transport Service element is used to specify a point-to-point Ethernet VLAN service request in the NSI CS protocol. In the schema vets extends from ets which extends from p2ps. I removed the "_v1" from the element names since the XML namespace identifies the version. John On 2013-07-11, at 11:29 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
On Thu, 11 Jul 2013, Henrik Thostrup Jensen wrote:
However, ERO it not really something that is defines a network service. It is more like special instructions to an aggregator. If you specify an ERO or not, does not really change the service you get from a network perspective.
This is actually a good example of something that a network cannot provide, but a capability of an NSA(s). Should we consider putting this outside the service definition?
Thought a bit more about this on the way home. The source and destination STP are really not service requirements as well, but something the service requirements should hold for.
Should we consider something like seperating Path and ServiceRequirement. I.e., and object for the path (which can include an ERO), and a requirement which should hold for the path. However this is starting to get a bit hairy. I am overthinking this?
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Guy Roberts -
Henrik Thostrup Jensen -
John MacAuley