[Nsi-wg] NSI endpoint references

John MacAuley john.macauley at surfnet.nl
Sat Mar 12 19:49:51 CST 2011


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

-------------- 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/49a27dfc/attachment.bin 


More information about the nsi-wg mailing list