[Nsi-wg] Service Termination Points

[Jerry Sobieski]

I think we had agreed at GLIF that queries would be (for now) just 
returning the PA's state and the request parameters as-built.   That 
there was no walking the tree implied at this time...?

J

On 3/13/11 12:29 PM, John MacAuley wrote:
> If we remove the hop-by-hop capabilities from the reservation request, do I also remove it from any queries?
>
> On 2011-03-13, at 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.
>>
>> 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.
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>