[Nsi-wg] Service Termination Points

Sat Mar 12 20:44:27 CST 2011

I sent this to Inder last night. It is my summary of what an "STP" 
represents.

Please read and offer comments.

Jerry

On 3/12/11 9:27 PM, John MacAuley wrote:
> Okay, i am glad it is not just me :-)
>
> On 2011-03-12, at 9:05 PM, Tomohiro Kudoh wrote:
>
>> Yes, this is an important point.
>>
>> STP
>> endpoint
>> network
>> NSA
>> domain
>>
>> terminology should be defined before proceeding.
>>
>> "endpoint" and "domain" are the words we agreed to not to use.
>>
>> Tomohiro
>>
>> 2011/3/13 John MacAuley<john.macauley at surfnet.nl>:
>>> Oops, forgot to make both components mandatory as Vangelis has.  I guess I should have moved back in time :-)
>>>
>>> Are we defining an STP or an endpoint?  Are they the same and we are just changing terminology?  I am a bit confused.
>>>
>>>> - Does a domain-id represent ownership/responsibility of the EPR by an
>>>> NSA?
>>>> - Can an EPR "belong to" multiple NSAs?
>>> I think we are saying an endpoint belongs to a single domain, but I believe multiple NSA could manage the same domain, and therefore, the same endpoint.
>>>
>>>> - Does this affect which NSAs receive a connection request? If so, how?
>>> Domain to NSA resolution is out of scope based on the last NSI call.
>>>
>>> John.
>>>
>>>
>>> On 2011-03-10, at 4:19 PM, Evangelos Chaniotakis wrote:
>>>
>>>> Jerry,
>>>>
>>>> I disagree with part of what you're saying here: i.e. that the entire
>>>> endpoint reference is a string. In my opinion the standard should
>>>> define it is an abstract tuple: (domain-id, local-id).
>>>>
>>>> The implementation of the standard should decide how to encode that
>>>> tuple. It could be a pair of two XML elements for SOAP, or a colon-
>>>> delimited concatenation, or whatever. It's absolutely trivial to go
>>>> the extra mile and support multiple representations, converting
>>>> between them on the fly.
>>>>
>>>> Let me propose this schema snippet for the SOAP implementation:
>>>>
>>>> <xsd:complexType name="nsiEndpointReference">
>>>>    <xsd:sequence>
>>>>      <xsd:element name="domainId" type="xsd:string" maxOccurs="1"
>>>> minOccurs="1"/>
>>>>      <xsd:element name="localId" type="xsd:string" maxOccurs="1"
>>>> minOccurs="1"/>
>>>>    </xsd:sequence>
>>>> </xsd:complexType>
>>>>
>>>>
>>>> I do agree with the points you're making about the local part, and I'm
>>>> fine with the clarification you want to explicitly set in the standard.
>>>>
>>>>
>>>>
>>>> In my opinion a much more important clarification needs to be made
>>>> about the domain-id part. Here are some questions that should probably
>>>> be answered.
>>>>
>>>> - Does a domain-id represent ownership/responsibility of the EPR by an
>>>> NSA?
>>>> - Can an EPR "belong to" multiple NSAs?
>>>> - Does this affect which NSAs receive a connection request? If so, how?
>>>>
>>>>
>>>>
>>>> On Mar 10, 2011, at 12:03 PM, Jerry Sobieski wrote:
>>>>
>>>>> Hi Vangelis-
>>>>>
>>>>> You are right except for one part:...  As I see this, it is really
>>>>> only the NRM that cares about the endpoint name.  NSI has no
>>>>> interest in what the endpoint string looks like other than maybe
>>>>> some purely aesthetic lexical conventions (e.g. no backspace
>>>>> characters, etc.)    Therefore, the *NSI* protocol implementers must
>>>>> explicitly treat the string as just a string.    If one domain wants
>>>>> to name its endpoints with topology info encoded, they can do that,
>>>>> but no other domain or NSA will look for that info in their
>>>>> string...as far as the other NSAs are concerned, the string is just
>>>>> a string.
>>>>>
>>>>> I will say though that for the mapping of the NSI endpoint reference
>>>>> to the NRM resource *is* the responsibility of the implementors who
>>>>> are coding the PA frontend onto an NRM.  They do need to know if
>>>>> local convention expects or requires local endpoints to be named a
>>>>> certain way.  But again it is only relevant for the local endpoints,
>>>>> and so is only of local significance and only for that particular
>>>>> NRM.   So this is not an NSI issue.
>>>>>
>>>>> I recommend that we are explicit in the NSI standard and say the
>>>>> following:
>>>>> The<local part>  of the endpoint reference is a string that uniquely
>>>>> identifies a particular endpoint within the<domain>  specified.
>>>>> The NSI framework and protocol explicitly leave the value of the
>>>>> endpoint reference string to be assigned by the network domain
>>>>> within which the endpoint resides.   The NSI Framework and protocol
>>>>> do not encode any information directly into the endpoint reference
>>>>> string.
>>>>>
>>>>> How is that?   This insures that local domains have full sway to
>>>>> name their own endpoints as they see fit.
>>>>>
>>>>> Best regards
>>>>> Jerry
>>>>>
>>>>>
>>>>> On 3/10/11 11:48 AM, Evangelos Chaniotakis wrote:
>>>>>> Jerry,
>>>>>>
>>>>>> If I may distill your email to:
>>>>>>
>>>>>> "Let's define an NSI-CS endpoint reference as this tuple: (globally
>>>>>> unique domain identifier, locally scoped opaque identifier)."
>>>>>>
>>>>>> I'm fine with that definition.
>>>>>>
>>>>>> The actual implementation/representation/format of such a tuple
>>>>>> should be left to the implementors of the protocol. It's just an
>>>>>> ordered pair of strings, it does not deserve a big discussion about
>>>>>> formats.
>>>>>>
>>>> --
>>>> Evangelos Chaniotakis
>>>> Network Engineer, ESnet
>>>> Visit our blog: http://bit.ly/9mNapV
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>
>
> _______________________________________________
> 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/20110312/b8841617/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Service Termination Points.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 144495 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110312/b8841617/attachment-0001.bin 