[Nsi-wg] NSI endpoint references
Inder Monga
imonga at es.net
Sat Mar 12 20:03:38 CST 2011
Yes I think there might be some "crosstalk" here.
I think Jerry is talking about STPs and Vangelis may be talking about NSA EPR?
Regarding STPs, since there is amapping of STP to a data plane topological space, whether multiple NSA's advertise same end-point is upto the implementation of the domain and its policy. We had agreed a while ago that ONE NRM "owns" the provisioning and resource allocation of that end-point.
btw, someone keeping track of how many things are out of scope of NSI? :)
Inder
On Mar 12, 2011, at 5:49 PM, John MacAuley wrote:
> 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
---
Inder Monga
imonga at es.net
More information about the nsi-wg
mailing list