[Nsi-wg] Service Termination Points

[Chin Guok]

I'm fine just specifying the source and destination in the initial 
implementation.  However I think that as we evolve the protocol, being able 
to specify "mid-point" STPs will be useful.

If I recall correctly, the issue was that the end user may not be able to 
see the "mid-point" STPs and thus is unable to verify the path.  However as 
we start adding other services (i.e. monitoring, etc), lack of visibility 
may not be an issue.

- Chin

--On March 12, 2011 11:51:20 PM -0500 John MacAuley 
<john.macauley at surfnet.nl> wrote:

> I am okay not to specify anything other than the source and destination,
> but was this not the whole discussion around not routing traffic through
> certain locations by specifying the route?  It resulted in the trust
> discussion.
>
>
> Does anyone else have strong opinions on the topic?
>
>
> John.
>
>
>
>
> On 2011-03-12, at 11:42 PM, Jerry Sobieski wrote:
>
>
>  Hi John-
>  I know we've had long discussions about path objects.   But I am not so
> sure they are necessary...
>
> If we can make two concatenated connections and treat them as one, then
> why do we need to specify loose hops?
> We can instead just issue two reservation requests, right?   If so, this
> would substantially simplify the request structure.  And so far, I've not
> heard of any use case that multiple reservations would not work for
> transit routing.
>
> ??
>
> Jerry
>
>
> On 3/12/11 10:35 PM, John MacAuley wrote:
>
>
> Taking Jerry's definition and Tomohiro's note not to use domain or
> endpoint I have defined the following three XML schema components:
>
>
>
>   • A "Path Object Type" consists of at a minimum an "aSTP" and a
> "zSTP", with an optional ordered list of "STP" defining the path through
> the network.
>   • An "STP Type" consisting of a mandatory "Network Id" string and a
> mandatory "Local Id" string that uniquely identify the STP.  There is an
> optional "Order" attribute that will only be populated when the STP is
> part of the ordered list.
>   • An "STP List Type" that will support both an ordered and unordered
> list of STPs.
>
>
>
> So is does my definition of a Path Object cover what was intended in the
> CS architecture document?
>
>
>    <xsd:complexType name="PathObjectType">
>        <xsd:sequence>
>           <xsd:element name="aSTP" type="tns:StpType" minOccurs="1"
> maxOccurs="1" />
>           <xsd:element name="orderedStpList" type="tns:StpListType" />
>           <xsd:element name="zSTP" type="tns:StpType" minOccurs="1"
> maxOccurs="1" />
>        </xsd:sequence>
>     </xsd:complexType>
>
>    <xsd:complexType name="StpType">
>        <xsd:sequence>
>           <xsd:element name="networkId" type="xsd:string" minOccurs="1"
> maxOccurs="1" />
>           <xsd:element name="localId" type="xsd:string" minOccurs="1"
> maxOccurs="1" />
>        </xsd:sequence>
>        <xsd:attribute name="order" type="xsd:integer" />
>     </xsd:complexType>
>
>    <xsd:complexType name="StpListType">
>        <xsd:sequence>
>           <xsd:element name="stp" type="tns:StpType" minOccurs="0"
> maxOccurs="unbounded" />
>        </xsd:sequence>
>     </xsd:complexType>
>
>
>
> On 2011-03-12, at 10:11 PM, Jerry Sobieski wrote:
>
>
> Hi John-
>
> Yes.   For NSI I think we can say an STP==endpoint.
>
> I think STPs in the abstract sense may be topological locations other
> than just a port or a VLAN, but for the purposes of NSI v1.0, I think a
> "real STP" is indeed a location in the topology where a connection may
> originate or terminate.
>
> (I note that I used a circular reference in the endpoint definition.
> Apologies.  An Endpoint is the physical topological terminus of a
> connection.)     I do reserve some flexibility in the abstraction
> however.  I think there are ways we can use Service Termination Points to
> indicate larger complexes of topological elements.   If folks are
> intersted I will elaborate, but for now, and to be expedient with respect
> to defining ReserveRequest() parameters, I suggest we accept an adequate
> definition and leave additional refinement to later.
>
> Is this helpful?
>  Jerry
>
> On 3/12/11 9:57 PM, John MacAuley wrote:
>
> Jerry,
>
>
> So based on your definition below is STP == Endpoint Reference from an
> NSI protocol perspective?
>
> Definitions:
>
> Service Termination Point := 1. An abstract object that represents the
> ingress or egress point of a connection, or the abstract notion of a
> location in a topology where a connection could potentially originate or
> terminate.  2. A real point in a topology where a connection can
> originate or terminate.
>
> Endpoint := In NSI, this is a location within a network that can be used
> as an endpoint for a connection.
>
> Endpoint Reference := a two-tuple consisting of a {<network name>,
> <endpoint name>} .  An “endpoint reference” is this tuple, the
> “endpoint” itself is the topological location it identifies.
>
>  John.
>
>
>
>
>
>