[Nsi-wg] NSI endpoint references

[Evangelos Chaniotakis]

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