[Nsi-wg] Fwd: Re: comments to WSDL files

Wed Apr 6 22:26:12 CDT 2011

Jerry,

I don't think anyone us claiming that the NSI protocol is VLAN sensitive.  I believe the issue is the concept of "connecting" pre-defined topology at the same layer you are attempting to instantiate the new service.  I will not reference VLAN in my example as I am going old school SONET to give us a second service example to discuss.

Thinking in Layer 1 SONET terms, the action of creating an STS-3c connection across the network (sometime called a trail) required me to specify at each network element a cross connect between two line/multiplex sections on an OC-192 carrier.  So to do this I would specify in the cross connect command the two MS ports (which I view as the STP), the bandwidth (or frame rate/format in SONET with STS-3c == 150,336 Kbit/s), and the time slot within the OC-192 carrier to begin multiplex this bandwidth into.  So from a TMN perspective, the line/multiplex section on the OC-192 carrier is the existing topology that is discoverable and available for service creation when I want to create a layer 1 STS rate connection.  The STS connection does not exist in the network, and cannot be referenced until it is created.  But once created is becomes topology and can be used to create addition new services such as VTG/VT1.5 services.

If I understand the current proposal, then in order for me to connect two network domains together via the NSI protocol, I would have already needed to model the time slots on the inter-domain ports in topology database and create a representative STP for each time slot.  The NSI then only references the STP in a reserve request, allowing me to know which time slot the STS-3c (bandwidth) would start on for the inter-domain port.  So if I have this correct I would need 192 STP for a single OC-192 inter-domain link to model all the potential starting time slots.  However, once a connection is reserved I would need to provide a topology update to remove all the STP referencing time slots that were no longer available due to a reservation taking up multiple time slots.

I must say that this is very different from standard connection management and perhaps why it was so hard for me to get my head around it.  I am also seriously questioning the value given it seems to introduce more complexity to the solution (much more so to topology), than me just providing a pair of STP represents the Line/MS segment and a time slot in the reservation request.

Please let me know if my example is wrong with respect to SONET STP.

John

On 2011-04-06, at 1:39 PM, Jerry Sobieski wrote:
> NSI is not VLAN sensitive...this is soo hard for people to grip.   In 
> NSI, we specify "connections" across "network", between two 
> "endpoints".  Period.  Its *that* simple.
> If that requires that we have 4000 entries in our topology DB 
> representing VLAN endpoints across the ENNI, so be it...its a topology 
> problem -not an NSI CS problem.   Its a pathfinder problem, not a 
> ReserveRequest problem.
> 
> An NSA for network "netA" gets a request netA:F>netQ:M,  the NSA looks 
> at the orig netA:F and knows its in his own network.   NSA looks at dest 
> netQ:M and realizes its in a remote network.   NSA calls the pathfinder 
> to select an exit point from netA:F towards netQ:M.  Pathfinder says go 
> to netB:io1 next via netA:x10.    NSA creates a segment netA:F>netA:X10, 
> it looks up netA:F in local topoDB and build a hdw request from 
> "sw=F10-e300 port=3/2 vlan=27" he found from the topoDB, he looks up 
> netA:X10 in topodb and come up with hdw info"sw=dell3236 port=1/1 
> vlan=2998" he puts both hardware endpoints in the NRM reserve request 
> and  and passes the nrm request to local NRM.  Local segment done.     
> NSA then goes to pathfinder again to ask:  next hop for netB:io1 > 
> netQ:M  (this is tree)   Pathfinder says netC:i1 next via netB:io9.  NSA 
> build SR for netB:io1>netB:io9 and sends to netB NSA.   NSA then goes to 
> PF from netC:i1>netQ:M.  PF return NetD:in via netC:o9...  This 
> continues until a segment is built for the last network.   In this 
> process, each NSA gets a request with only local endpoint STPs, the NSA 
> will see both are local, and will build a local nrm request with 
> hardware specs just as the first hop NSA did.
> 
> Alternately, after the first hop NSA does his local ReservationRequest, 
> it can build a SR for netB:io1>netQ:M and submit it to netB NSA.  If a 
> confirm comes back, we have a circuit. (this is chain)
> 
> does this help?
> 
> j
> 
> On 4/6/11 9:35 AM, John MacAuley wrote:
> > Taking time off from the NSI the last couple weeks has muddled my head.
> >
> > Taking the current Automated GOLE demo service as an example, we specify a VLAN to provision across the network and the E-NNI Ethernet edge ports along the path.  Are you saying that we no longer do this and that an STP would reference pre-defined VLANs?  I am having problems visualizing.
> >
> > Thanks,
> > John.
> >
> > On 2011-04-06, at 12:27 AM, Jerry Sobieski wrote:
> >
> >> Not quite, John.  The STP (<net>:<ep>  tuple) should be considered to be a link into the local topology db.   The physical specifics of the termination point are found there- not in the service request.
> >>
> >> When processing the SR, the NSA will look up the network in the topodb and find a path to that network.   At some point, a segment will be generated from the far network edge to the end point and set to the NSA.  That NSA will realize the endpoints are local, and will know then to convert the NSI tuples to NRM nomenclature and any other munging about of the SR.   The NSAs will need a local internal mechanism to map NSI names to local physical specifications for the NRM.  That might be a look up name table, or it may be a name list in the topology DB that has the NSI name associated with a topology object.  In any case, the topology object should have information relating to the termination point details - vlan tag, port, switch, availbale cap, etc.
> >>
> >> The VLAN tag is NRM specific information and is not recognized by NSI.   Unless we elect to define VLANs in the Service Definition, they won't either show up in the ReserveRequest.    All the specific hardware information is found in the topology DB.  The local NRM topology DB will say if the termination point is a tag on a port on a switch... or is just a port on a switch (or tag0 on a port on a switch).
> >>
> >> The user doesn't know and should have to know the technical specs associated with an far STP in some remote land.   The request simply specifies an STP - the networkname:endpointname tuple.  The request will specify the bandwdith, orig and dest STP, and other parameters defined in the Service definition.     The primitive does not have guaranteed attributes...(I saw these in the xsd...  What are those?)
> >>
> >> j
> >>
> >> On 4/5/11 10:45 PM, John MacAuley wrote:
> >>> So based on the discussion here, have we answered Radek's original request with respect to VLAN against the ServiceTerminationPointType?
> >>>
> >>> In my mind the answer is that the  ServiceTerminationPointType identifies the abstract interconnects, while specifics of the service are held in the ServiceParametersType.  The tagged/untagged and specific VLAN id would be populated in the "guaranteed" attribute sequence as per the service definitions.
> >>>
> >>> John.
> >>>
> >>> On 2011-03-29, at 3:13 PM, Jerry Sobieski wrote:
> >>>
> >>>> Oops - one thing I should make clear below...
> >>>>
> >>>> O
> >>>>>> - In ServiceTerminationPointType, it would be useful to have information whether port is tagged or not (VLANs information is not stored also). I know that we would like to keep the messages as technology agnostic as possible, but we need to have a balance between functionality and simplicity/universality here. In case of AutoBAHN we can probably do some workarounds to evade the issue, however this is not plug-and-play ;)
> >>>>> Hej Radak-
> >>>>>
> >>>>> The STP is just an NSI name.<network>:<localname>       NSI does not
> >>>>> encode any physical topology information into the name.  It is just a
> >>>>> name.  I expect the NSA would use the name to index into a table of
> >>>>> local names to link to the local topologyDB. (Alternatively, the NSA may
> >>>>> simply search the local TopoDB for a topology object with this NSI name.
> >>>>> ...but this is all an implementaion detail)   The topoDB would indicate
> >>>>> whether that STP maps to a port or VLAN or something else.  Since NSI
> >>>>> does not define any technology specific topology information, things
> >>>>> like VLANs and ports etc are only of significance to the local NRM
> >>>>> (AutoBahn in this case).   And it becomes the responsibility of the NRM
> >>>>> (AutoBahn in this case) to provide a translation from the NSI local
> >>>>> endpoint name to any NRM specific denotion.  (Also, since each NRM is
> >>>>> different, it would be impractical for the NSA to know each dialect of
> >>>>> every NRM it might encounter...)
> >>>> The *service* specifics - things like bandwidth or MTU or other service
> >>>> related specifics of a particular connection service are defined in the
> >>>> Service Definition.  The ReservationRequest contains such service
> >>>> attributes, and they are qualified against the Service Definitions of
> >>>> the transit networks, but they are not specifically part of the NSI-CS
> >>>> protocol.
> >>>>
> >>>> We have tried to separate the service specifics from the protocol(s)
> >>>> that communicate them.   The NSI-CS protocol recognizes an abstract
> >>>> model of a "connection", but hardware specifics of a particular
> >>>> connection service offering or a particular service instance are not
> >>>> hard wired into the NSI-CS protocol.  This will allow a great deal of
> >>>> flexibility to map multi-layer and heterogenous connection services and
> >>>> their dialects to the same generic and global protocol framework.
> >>>>
> >>>> Hope this helps a bit more..
> >>>> J
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> nsi-wg mailing list
> >>>> nsi-wg at ogf.org
> >>>> http://www.ogf.org/mailman/listinfo/nsi-wg
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/970d89d0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/970d89d0/attachment-0001.bin 