[Nsi-wg] Reservation request message

Wed Apr 6 00:20:32 CDT 2011

Ok...I have been thinking on this NSA addressing issue a lot recently...

There are times when we do not want to forward a request to the NSA 
associated with an endpoint.  One is a federating NSA that announces an 
internal network we need.  Another is just a transit network we need to 
use because we don't know how to reach the real nsa.  For these reasons 
we should not expect the network name associated with an endpoint to map 
us directly to the appropriate NSA for forwarding the request.   But 
this is a simple problem, a local name table (in topology DB?) maps a 
network we know about to an NSA delivery address.  Nordu.net.ETS={ KTH, 
DTU,Stocholm.edu}  says Nordu.net.ETS speaks for these other network NSI 
networks.  All this will be clearer when we work on topology 
distribution, but for now, all we can say is that there are only a few 
ways we could find out where to send a message to an NSA:

1. The NSA IP /port addr is configured by hand and read into the 
topology DB at NSA initiatization.
2. We learn about a remote NSA from an automated Toplogy distribution 
process.
3. There is some "well known" place to start ala DNS resolver.
4. Global file someplace.

Number 4 does not scale and is unreliable.   Might work in an 
experiment, but not in a standard.
Number 3 requires other services and is similar to number 4. Certainly 
too complex for now...and not necessary IMO.
Number 1 is the obvious place to start - we configure the Network name 
and associated contact address manually.  These form the initial direct 
peerings that we have arranged with other networks (ala BGP peers)
These initial NSA peers will presumably offer us topology - which 
contains network announcements(2).  IMO, associating the NSA contact 
info with the network topology object is the perfect location. We can 
use the topology to build an incrementally more comprehensive set of 
Networks and associated NSA contact info.

I think I like your suggestion to specify it as 
<nsaAddress>tcp://NSA.NORDU.net:2764</nsaAddress> in the topodb, but in 
the NSI message, I think I prefer a context free spec:  maybe just the 
network name.   So if you are a PA and send amessage to the RA at 
Nordunet, the RAnsaAddress in the ReserveConfirm would just be 
"Nordu.net" or "Nordu.net.ETS" (for the Ethernet service).   These would 
be found in the topodb and the associated ipaddr or the URi would be 
used to actually send the messgae.

AS for the tuple syntax, I agree.  The colon has implications for 
URNs...but the GLIF guys knew that too...why did they choose it none the 
less?   I am not wed to using that specific syntax, but I do like the 
form <network><divider><localname>.   Indeed, I would have suggested a 
more hierarchichal aproach ala //Nordu.net/endpoint1, or 
Internet2.edu/MAX/UMD/perfSonar which would allow easier federation....

But for now, we have the two part tuple.  Lets stick with that.   We can 
review the separator character, and the string syntax, but lets keep the 
two part tuple. It works well in some key ways.   What do you suggest?
(Note- I will blow a fuse if you try to encode physical information into 
these names for direct use by DRAC or any other NRM - it won't work in 
real world. :-)    Whatever we do, we need to keep the NSI names and 
objects abstracted from any particular hardware, technology, or NRM.   
These have to work across all of them.

Peace brother:-)
Gotta sleep now.
J

On 4/5/11 11:55 PM, John MacAuley wrote:
> So are you implying that the <nsaAddress> is element is not just an 
> opaque reference, but an actual protocol address?  Would this not 
> conflict with the requirement not to put any transport implementation 
> specific fields on the protocol?
>
> I have defined the <nsaAddress> element as an anyURI because I 
> anticipated you would be asking for this as soon as you saw my 
> example.  If you want to model the NSA address as a UDP port it can be 
> done with the URI format 
> <nsaAddress>udp://NSA.NORDU.net:2764</nsaAddress> or for TCP 
> <nsaAddress>tcp://NSA.NORDU.net:2764</nsaAddress> all accomplished 
> through the magic of the URI.
>
> These are still protocol specific so you might want to revert back to 
> my nice abstract name :-)
>
> As for not using STP in the <localId> of the STP... I am not sure 
> specifying a colon as an internal string separator is a good idea when 
> URI/URL are now becoming a de facto standard for naming resources. 
>  Some of the organizations that will participate in the NSI testbed 
> use this naming format already, and we should not force them to 
> change.  I also do not think we should be specifying a restricted 
> character set for naming in the NSI with so many standardized naming 
> schemes available in RFCs.
>
> Jerry... Come over to the dark side..
>
> Which raises another question.  Should naming support multi-byte 
> characters (UTF-8)?
>
> John.
>
> On 2011-03-25, at 11:15 PM, Jerry Sobieski wrote:
>
>> Oh...a couple other comments I forgot:
>>
>> First, the <nsaAddresses> examples do not seem right...
>> The message should reference a RA NSA and a PA NSA...  Those should 
>> not need a domain reference...just the NSA identifier.    First, NSI 
>> context has no notion of a "domain"...   but more importantly, we 
>> need to specify where to find an NSA...it should ultimately resolve 
>> to an IP address (v4 or v6) and a TCP port that NSA is listening 
>> to.   The NSA location can be specified in a symbolic name manner, 
>> but it needs to be specific to the transport layer it is using, and 
>> should not be handled differently in the protocol for different 
>> transport layers.
>>
>> So an NSA locator string could be:  "NSA.NORDU.net:2764" meaning the 
>> NSA is listening to port 2764 on the server nsa.nordu.net 
>> <http://nsa.nordu.net>.    Or we could do "urn:ogf:network: 
>> netherlight.edu <http://netherlight.edu>"  and assume it is using a 
>> default port that is documented somewhere.
>>
>> We need to come to closure on NSA resolution.   I.e. How do we 
>> specify an NSA location?   Is it an IP address and TCP port?  Is it a 
>> standard DNS name?  a URN of some sort?
>>
>> Also, the string you referenced as a local part of the 
>> netherlight.edu <http://netherlight.edu> STP is probably not valid if 
>> we use the colon seperated tuple for NSI endpoints.   Endpoints will 
>> be referenced outside of XML contexts.  And endpoint strings will be 
>> used in many other manners than simply the local NRM.   Therefore, I 
>> think it is imperative that we make sure the name strings are as 
>> simple as possible.  For instance is a network name case sensitive?  
>> Can it have colons ":" embedded in it?  Or will that hose the tuple 
>> mechanism for naming?  Are spaces allowed?  are linefeeds?  Are 
>> contiguous spaces significant?     I was hoping we could let the 
>> local strings be whatever the local NSA wants them to be, but I think 
>> we need to be a bit more specific about how we expect to be able to 
>> use endpoint names.
>>
>> We need to specify some constraints on the string values that make up 
>> NSI names.   I suggest case-insensitive, no spaces, alphanumeric, and 
>> maybe a small set of special characters.
>>
>> Jerry
>>
>> On 3/23/11 10:37 PM, John MacAuley wrote:
>>> Peoples,
>>>
>>> I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
>>>
>>> John.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> nsi-wg mailing list
>>> nsi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/nsi-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nsi-wg/attachments/20110406/55bce6c9/attachment-0001.html 