[Nsi-wg] NSI endpoint references

Sat Mar 12 20:27:10 CST 2011

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
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1791 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110312/26ee3f60/attachment.bin 