[Nsi-wg] Service Termination Points

[Jerry Sobieski]

On 3/13/11 1:06 PM, Chin Guok wrote:
> 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.
>
I think pushing it to post-v1 discussion will be best.   I do think it 
merits serious discussion.

> 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.
Exactly my point.   We have a LOT more work before NSI is a full set of 
functionality.   Lets not boil the ocean in the next two weeks.

THe verification was part of it.   But fundamentally if A>B>C is 
equivalent to A>B + B>C,  why do we need both?   Its needless complexity.

J
>
> - 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.
>>
>>
>>
>>
>>
>>
>
>
>
>