[Please post counter proposals also to https://forge.ogf.org/sf/go/artf6495] I have recently distributed some NML example topologies to people outside of the NML developers. This included label definitions like: <nml:label> <nml:parameter name="type">http://schemas.ogf.org/nml/2013/10/ethernet/vlan</nml:parameter> <nml:parameter name="values">1780-1783</nml:parameter> </nml:label> Some of the feedback was that the label syntax was too verbose, and the alternative was akin to the original proposal: <nml:label labelType="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780-1783</nml:label> This in combination with a recent majority on the NML mailing list who favoured a relative flat syntax for label ranges ("1780-1783" instead of <start>1780</start><end>1783</end>) has prompted me to see if a more simple alternative is possible. To that end, I posed two complex label definitions, to see how those can be described: 1. IP does not describe resource labels, but a source + destination label pair. How to describe a label pair with "source IP 145.100.124.38 and destination IP 193.10.252.66"? 2. WDM channel not only have a (central) frequency (or central wavelength) but also a given frequency bandwidth, the spacing. How to specify the these (ITU-gridless) wavelengths: "The wavelengths with 193.0, 193.1 and 193.2 central frequency with 100 GHz spacing, and another wavelength at 193.275 central frequency with 50 GHz spacing". After some thinking, here is a proposal: (sorry for the quoting, this prevents wrapping in my mail client)
1. <nml:label labeltype="http://schemas.ogf.org/nml/2013/10/ip/ipv4"><source>145.100.124.38</source><destination>193.10.252.66</destination></nml:label>
2. <nml:labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/dwdm/frequency">193.0-193.2±0.05,193.275±0.025</nml:label> (or the alternative if we don't want a non-ASCII "±" sign, and like to see the spacing rather than half the spacing): <nml:labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/dwdm/frequency">193.0-193.2~0.1,193.275~0.05</nml:label>
In conclusion, I think that the shorter variant can be done, as long as we specify per labeltype what the syntax is. I recommend to distinguish between nml:label and nml:labelgroup, now that the type="value"/type="values" is no longer there to distinguish between a label and a label group. Regards, Freek
This syntax seems reasonable. My only minor niggle is i'd prefer it be 'type' instead of 'labelType' since it's an attribute of a label construct, and adding 'label' to it seems redundant. Cheers, Aaron On Jul 10, 2012, at 8:34 AM, Freek Dijkstra wrote:
[Please post counter proposals also to https://forge.ogf.org/sf/go/artf6495]
I have recently distributed some NML example topologies to people outside of the NML developers. This included label definitions like:
<nml:label> <nml:parameter name="type">http://schemas.ogf.org/nml/2013/10/ethernet/vlan</nml:parameter> <nml:parameter name="values">1780-1783</nml:parameter> </nml:label>
Some of the feedback was that the label syntax was too verbose, and the alternative was akin to the original proposal:
<nml:label labelType="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780-1783</nml:label>
This in combination with a recent majority on the NML mailing list who favoured a relative flat syntax for label ranges ("1780-1783" instead of <start>1780</start><end>1783</end>) has prompted me to see if a more simple alternative is possible. To that end, I posed two complex label definitions, to see how those can be described:
1. IP does not describe resource labels, but a source + destination label pair. How to describe a label pair with "source IP 145.100.124.38 and destination IP 193.10.252.66"?
2. WDM channel not only have a (central) frequency (or central wavelength) but also a given frequency bandwidth, the spacing. How to specify the these (ITU-gridless) wavelengths: "The wavelengths with 193.0, 193.1 and 193.2 central frequency with 100 GHz spacing, and another wavelength at 193.275 central frequency with 50 GHz spacing".
After some thinking, here is a proposal: (sorry for the quoting, this prevents wrapping in my mail client)
1. <nml:label labeltype="http://schemas.ogf.org/nml/2013/10/ip/ipv4"><source>145.100.124.38</source><destination>193.10.252.66</destination></nml:label>
2. <nml:labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/dwdm/frequency">193.0-193.2±0.05,193.275±0.025</nml:label> (or the alternative if we don't want a non-ASCII "±" sign, and like to see the spacing rather than half the spacing): <nml:labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/dwdm/frequency">193.0-193.2~0.1,193.275~0.05</nml:label>
In conclusion, I think that the shorter variant can be done, as long as we specify per labeltype what the syntax is. I recommend to distinguish between nml:label and nml:labelgroup, now that the type="value"/type="values" is no longer there to distinguish between a label and a label group.
Regards, Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
Regarding the syntax:
<nml:label labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780</nml:label>
On 12-07-2012 13:25, Aaron Brown wrote:
This syntax seems reasonable. My only minor niggle is i'd prefer it be 'type' instead of 'labelType' since it's an attribute of a label construct, and adding 'label' to it seems redundant.
Henrik suggested labelType, because "type" was an overloaded word. I also don't like "type", because I may later propose to introduce the distinction between resource label, source label and destination label. That's also a "type". I actually went over the GMPLS tables at www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml to find a better name, but got confused by all the parameters there (heck, I wasn't even sure that parameter I should use for a simple VLAN). So I used Henrik's suggestion. Thinking about it, what is meant here is the "technology" or "encoding" of the label. A quick search yieled that "label encoding" is an accepted term, so I propose: <nml:label encoding="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780</nml:label> A minor drawback: we just started using "encoding" to specify the technology of a Port of Link. E.g. Ethernet frames. That may be confusing. Should be change that to "layer" or can we keep "encoding" there? Freek
Hey Freek, On Jul 12, 2012, at 7:38 AM, Freek Dijkstra wrote:
Regarding the syntax:
<nml:label labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780</nml:label>
On 12-07-2012 13:25, Aaron Brown wrote:
This syntax seems reasonable. My only minor niggle is i'd prefer it be 'type' instead of 'labelType' since it's an attribute of a label construct, and adding 'label' to it seems redundant.
Henrik suggested labelType, because "type" was an overloaded word.
I also don't like "type", because I may later propose to introduce the distinction between resource label, source label and destination label. That's also a "type".
I actually went over the GMPLS tables at www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml to find a better name, but got confused by all the parameters there (heck, I wasn't even sure that parameter I should use for a simple VLAN). So I used Henrik's suggestion.
Thinking about it, what is meant here is the "technology" or "encoding" of the label. A quick search yieled that "label encoding" is an accepted term, so I propose:
<nml:label encoding="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780</nml:label>
A minor drawback: we just started using "encoding" to specify the technology of a Port of Link. E.g. Ethernet frames. That may be confusing. Should be change that to "layer" or can we keep "encoding" there?
I'd prefer 'layer' to 'encoding', but I'm fine with either. Cheers, Aaron
Freek
ESCC/Internet2 Joint Techs July 15-19, 2012 - Palo Alto, California Hosted by Stanford University http://events.internet2.edu/2012/jt-stanford/
The more interesting problem is that the term VLAN needs to be qualified depending on the Ethernet service being offered. For example, CE-VLAN (Customer Edge VLAN) or P-VLAN (Provider VLAN) or S-VLAN (Service VLAN), On 2012-07-12, at 7:38 AM, Freek Dijkstra wrote:
Regarding the syntax:
<nml:label labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780</nml:label>
On 12-07-2012 13:25, Aaron Brown wrote:
This syntax seems reasonable. My only minor niggle is i'd prefer it be 'type' instead of 'labelType' since it's an attribute of a label construct, and adding 'label' to it seems redundant.
Henrik suggested labelType, because "type" was an overloaded word.
I also don't like "type", because I may later propose to introduce the distinction between resource label, source label and destination label. That's also a "type".
I actually went over the GMPLS tables at www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml to find a better name, but got confused by all the parameters there (heck, I wasn't even sure that parameter I should use for a simple VLAN). So I used Henrik's suggestion.
Thinking about it, what is meant here is the "technology" or "encoding" of the label. A quick search yieled that "label encoding" is an accepted term, so I propose:
<nml:label encoding="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1780</nml:label>
A minor drawback: we just started using "encoding" to specify the technology of a Port of Link. E.g. Ethernet frames. That may be confusing. Should be change that to "layer" or can we keep "encoding" there?
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On 13-07-2012 03:24, John MacAuley wrote:
The more interesting problem is that the term VLAN needs to be qualified depending on the Ethernet service being offered. For example, CE-VLAN (Customer Edge VLAN) or P-VLAN (Provider VLAN) or S-VLAN (Service VLAN),
NML will create a base schema with generic concepts. It would be very useful to push out some technology specific schemas at roughly the same time, and I think Ethernet is a prime candidate for that. I've created some technology-specific schemes in NDL, but certainly don't consider myself an expert. Would you be willing to work with me on a Ethernet schema? That would be extremely useful and helpful to us. As a first step, I like to call you to go over the above variants, and decide together how many sublayers there are in Ethernet. (where a sublayer is an encoding of a datastream, thus with a given frame header). I can make time for this in about a week from now. Thanks, Freek
participants (3)
-
Aaron Brown -
Freek Dijkstra -
John MacAuley