[Nsi-wg] Service Termination Points
Jerry Sobieski
jerry at nordu.net
Wed Mar 16 14:53:59 CDT 2011
On 3/14/11 2:14 PM, Chin Guok wrote:
> 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.
Hey John - This sounds elegant and the way it ought to work. However,
as I state in another post though, the network transport as-built info
should IMO have a different security context than user as-built info.
Plus we have not agreed on the need that path information must be
returned, so this will not work reliably regardless of the elegance.
I think our NSI model of a Connection := "STP A ingress framing" +
"Network transport provisioning" + "STP Z egress framing" is an
important model to keep in mind... I think that the network
transport provisioning represents information that is not part of the
service commitment to the user. Ergo, the user is not entitled to it
just because its his data transport instance. This information can be
had, just not as part of the connection service request... maybe a query
is better/more apropriate mechanism with potentially different
authorization credentials. But I think in the NSI context, the network
must be able to protect all the network stuff for security, privacy,
competitive, or other reasons. The user is not entitled to network stuff.
In our model, we expect the ReserveConfirm to be the network accepting
responsibility for providing a service instance with a certain
guarranteed performance. I think we are really missing an important
game changing opportunity if we do not hold the network responsible for
that commitment. If we delegate responsibility for performance
guarantees to the network, then we don't need all this network stuff to
debug the service instance...we just need a way to Ding the network when
the circuit is underperforming to say "FIX IT!" (:-)
Its still not clear to me *why* a user would care about the path their
service request takes ... It seems to me most of the compelling reasons
we hear (e.g. path diversity, security, or debugging) miss the point:
/We have no mechanism for asking for path diversity or policy based
routes/, so what are we looking for?? We have no NSI plan or
architectural model for fault resolution or performance verification -
so asking for NSI path info on that basis is at best premature. There
is no guaranty that path information you return will be at all useful.
Regardless, I thought we agreed to just return [user] as-built info for
a particular CID as the result of a Query in v1.0 This will be simple
and nominally useful. I do not recall concensus on returning path
information.
(FYI all: I am not resisting these features...just resisting trying to
get them all into v1.0 n the next week - we need to get this draft out
asap. I am more than willing to discuss all of these features as part
of v1.1 or v2.... It will be fun. But lets not add anything we haven't
thought out completely in the group and have concensus on.)
Thanks!!
Jerry
>> 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
>
>
>
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110316/8e5c2fe2/attachment-0001.html
More information about the nsi-wg
mailing list