[Nsi-wg] NSI endpoint references

[John MacAuley]

I just want to make sure you do not think I believe we need globally unique endpoint names based on a common URN scheme.  This is not the case.

When part of Nortel I developed two separate adjacency discovery mechanisms to drive topology discovery.  These used mechanisms similar to what Jerry is proposing.  The first transmitted adjacency strings in the IS-IS Hello message of the form "AD_2_00:21:e1:d6:d6:70_001_000_012_000_001_ME_1", where the component was the AD version string format (AD_2), the IEEE system id of the network element transmitting the tag (00:21:e1:d6:d6:70), and the encoded port identifier within the shelf (001_000_012_000_001_ME_1).  The transmit and receive strings from each network element were then correlated by and external system to match port pairs together.

For ASON, where there was a requirement for peer controller discovery, I modified the mechanism to utilize PPP or LAPD unacknowledged unnumbered information frames over SDCC/LDCC and sent an XML formatted string containing the IP address of the managing ASON controller, MAC address of the containing network elements, and the port identifier.  This was standardized in ITU-T G.7714.1/Y.1705.1.

In both cases, the information passed is similar in concept to what Jerry is proposing, just a different scope of uniqueness.

On 2011-03-13, at 1:43 AM, Inder Monga wrote:

>> I think my concern is that the endpoints we are trying to reference are not values passed to application services - they are endpoints of conenctions.   Is it apropriate to force all users of NSI to adopt OGF naming conventions for their network endpoints?  It is one thing to say NSI uses these namepsaces internal to the protocol, its is another to say all users of NSI services must also use OGF name spaces to name their endpoints. If we specify any namesapce, it seems to me we are also excluding all others.   Is this necessary to identify endpoints suitably?- or just a habit we've gotten into?

The reason I have been assuming this would be true is due to perfSONAR and Fenius, where participants named their endpoints using the OGF URN scheme for consistency and uniqueness globally.  Obviously, global uniqueness of each field is not required when put in the context of another field.  It is the 20 years experience of knowing how nice it would be for a unified naming scheme that is getting in the way :-)

>> Speaking of clarity, how much "clarity" does it really need?  What is not clear?   We are talking about a two part tuple...  That carries no NSI relevant information in the names.   Why would more namespaces provide more "clarity"?   Namespaces just qualify the ...uh..namespace.   duh.  I think what you want is not just namespaces but XML schemas.   

Hmmm... I guess what is not clear to me is the operationalization of this NSI protocol in the current state.  We are leaving a considerable amount as "out-of-scope" and many of the types are defined as strings and nondescript attribute lists.  I think we will end up doing most of the functional usefulness and interoperability work pairwise between two peering NSA, similar to the exercise I went through with Vangelis when building the Fenius agent on top of OpenDRAC.  I am fine with this approach, and perhaps I will get a more certain feeling as we proceed with the reference implementation.

John.
-------------- 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/20110313/44cff51d/attachment.bin