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