[Nsi-wg] Service Termination Points
Chin Guok
chin at es.net
Mon Mar 14 13:14:09 CDT 2011
Yes, the hop-by-hop info I was referring to was what John mentions below,
which at a minimum, is the inter-domain STP entities interconnecting the
domains. I foresee that this information can be recursively passed up the
tree/chain as the reservation request is returned successfully. I think
John's comment about it being optional is fine with me. We cannot enforce
a mid-level NSA in a workflow that decides not to return intermediate STP
info.
- Chin
--On March 14, 2011 5:55:34 PM +0100 John MacAuley
<john.macauley at surfnet.nl> wrote:
> The strategy I took in defining the WSDL operations it to return the
> reserved connection parameters in the reserveConfirmed, and queryResult
> (Inder I need your slides so I can get the names correct). These are
> similar to the original reservation parameters, except with the addition
> of connection state, the chosen guaranteed parameters, the chosen
> preferred parameters, and optionally the PathObject describing the chosen
> path (may be removed based on discussions). I believe, with the
> exception of PathObject, that this would line up with discussions in Hong
> Kong.
>
> As for the hop-by-hop parameters - I have left it up to the NSA
> implementation to decide what is returned up the tree. I think
> specifying this is out-of-scope ;-)
>
> Seriously now, I visualized that the first Provider NSA would take the
> sourceSTP and destSTP, perform path computation using some type of
> topology, then reserve this STP topology down the tree. The resulting
> reserveConfirmed would contain this STP topology which, at a minimum,
> would be the inter-domain STP entities interconnecting the domains.
>
> John.
>
> ----- Original Message -----
>> From: "Inder Monga" <imonga at es.net>
>> To: "Jerry Sobieski" <jerry at nordu.net>
>> Cc: "John MacAuley" <john.macauley at surfnet.nl>, nsi-wg at ogf.org
>> Sent: Monday, March 14, 2011 12:38:47 PM
>> Subject: Re: [Nsi-wg] Service Termination Points
>> 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
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
More information about the nsi-wg
mailing list