I had not submitted the final update because I wanted to go through it on the last call but we ran out of time. Here is the new STP type that lines up with the NML definitions: <xsd:complexType name="StpType"> <xsd:sequence> <xsd:element name="networkId" type="xsd:string" /> <xsd:element name="localId" type="xsd:string" /> <xsd:choice minOccurs="0"> <xsd:element name="label" type="tns:TypeValueType" /> <xsd:element name="labelGroup" type="tns:TypeValueType" maxOccurs="unbounded" /> </xsd:choice> </xsd:sequence> </xsd:complexType> <xsd:complexType name="TypeValueType"> <xsd:simpleContent> <xsd:extension base="xsd:string"> <xsd:attribute name="type" type="xsd:string" use="required"/> </xsd:extension> </xsd:simpleContent> </xsd:complexType> After considerable discussion, I decided to propose a single collapsed P2PS service element like we originally defined. <xsd:element name="p2ps" type="tns:P2PServiceBaseType"/> <xsd:complexType name="P2PServiceBaseType"> <xsd:sequence> <xsd:element name="capacity" type="xsd:long" /> <xsd:element name="directionality" type="types:DirectionalityType" default="Bidirectional" /> <xsd:element name="symmetricPath" type="xsd:boolean" minOccurs="0" /> <xsd:element name="sourceSTP" type="types:StpType" /> <xsd:element name="destSTP" type="types:StpType" /> <xsd:element name="ero" type="types:StpListType" minOccurs="0" /> <xsd:element name="parameter" type="types:TypeValueType" minOccurs="0" maxOccurs="unbounded" /> <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded" /> </xsd:sequence> </xsd:complexType> Having the separate ETS service element just for MTU seemed over kill. We can now put these types of additional parameters into the "parameter" element similar to vlan in the label: <parameter type="http://schemas.ogf.org/nml/2013/03/ethernet#mtu">9500</parameter> As for the under qualified and fully qualified STP, I recommended we write a section covering it in the service specific section of the CS specification. That is, if we plan on supporting it. I would suggest we support the same rules as NML for specification (must use LabelGroup, can have multiple LabelGroup elements, with each element containing a series of comma separated ranges (e.g. 1775-1777, 1780-1790). If the under qualified STP is provided in a reservation request, then the reservation confirmed contains the fully qualified STP in the "label" element as selected by the Provider NSA. I have a slide pack documenting these and a few other changes that have been done. I will send it out today or tomorrow depending on a few actions I still need to close. Comments? John On 2013-11-19, at 5:51 AM, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
In revision 101 label got re-added under StpType, which fits with what we agreed with on the call as far as I can remember. However sourceVLAN and destVLAN still exists in the EthernetVlanType. Is there a reason for this, or did we just forgot to take them out.
Further is there a reason to keep EthernetVlanType around? If one wants a VLAN, one just specifies a label and if one wants plain ethernet, no label should be specified (right?).
We also have some discrepency between NML and STPs. A Port/PortGroup in NML can only have a single label, which has a single value. Our StpType can have multiple labels. Furthermore a label can have multiple values, which confuses me a bit, but it might be related to the next issue.
Overqualifying labels is something that isn't really documented anywhere AFAICT. In NML we specify ranges with "start-end" and AFAIK, can also be comma-seperated. In NSI I reckon we should do the same when overqualifying, and only have a single value in the label. Furthermore we should have it written down... somewhere... how to overqualify a label with the "start-end" semantics.
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