[Nsi-wg] Service Termination Points

[Chin Guok]

My vote is to keep the hop-by-hop info in the reservation request, and 
return it in queries.

>From a practical standpoint, as we start using the protocol not only as an 
academic exercise but as a production tool, having that level of detail is 
critical in helping network operators troubleshoot (i.e. determining which 
downstream network to contact).

My 2 cents.

- Chin

--On March 13, 2011 12:30:16 PM -0400 John MacAuley 
<john.macauley at surfnet.nl> wrote:

> Sorry, I should have stated the reservation and query responses.
>
> On 2011-03-13, at 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.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>