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@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@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg