[Nsi-wg] Service Termination Points
Inder Monga
imonga at es.net
Mon Mar 14 11:38:47 CDT 2011
or maybe I am confused, either way -
The PA's state and request parameters as-built - the request parameters as built may have the abstract representation of the various "segments" of the call with any information that may be shared. Is that what I am assuming for "hop by hop" information.
but this may not be what Chin/John had been meaning in their responses.
Inder
On Mar 14, 2011, at 9:28 AM, Jerry Sobieski wrote:
> Hmm...maybe I am confused... (not often:-)
>
> What hop by hop aspects are we speaking to?
>
> J
>
> On 3/14/11 12:21 PM, Inder Monga wrote:
>> Returning the hop-by-hop capabilities does not necessarily imply walking the tree.
>>
>>
>> Inder
>>
>> On Mar 14, 2011, at 7:50 AM, Jerry Sobieski wrote:
>>
>>> 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.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>> ---
>> Inder Monga
>> imonga at es.net
>>
>>
>>
---
Inder Monga
imonga at es.net
More information about the nsi-wg
mailing list