[Nsi-wg] [Nml-wg] Wednesday's NSI standards conf call

Wed Feb 12 06:39:54 EST 2014

Hi Jerry,

I hope it's OK if I quote you on-list. Perhaps others share the same
questions. (your full mail is quoted verbatim at the end). I'll try to
answer some of them here.

> STPs - An STP is service termination point.  A concept.    The STP
> "Identifier" is the name for the STP.  It is a 2-tuple
> <networkid>:<localid>.   These carry no routing information other than
> the name of the network in which the STP resides.

I'm not making any assumption about the syntax of the name/identifier in
this presentation. So also not that the name starts with a networkid.
(In general, an identifier MAY be hierarchical, and may start with the
ID of the assigning organisation. This is how most identifiers,
including ISBNs and URNs, work. NSI indeed makes the assumption that the
ID of the assigning organisation is the name of the network. NML
actually does not make this assumption.)

> An STP is the object,  An STP Identifier names the object. 

Indeed!

You are right that I took a bit of a shortcut on slide 3, when it comes
to "NSA" and "Intermediate STP/SDP".

I perhaps should not have mentioned these two, but only mentioned
"Endpoint STP" and "Topology".

[...]
> We do not need "intermediate" STPs ... this is meaningless in NSI
[...]

While we now have a clear vision what we need for "Endpoint STP" and
"Topology" (identifier and address respectively), at least I am still
uncertain about "NSA" and "Intermediate STP/SDP".

Thanks for explaining your vision. You are going in the details about
routing and path finding. We have not discussed that yet, so we don't
have a solution there (yet).

> b) Slide 5; Your assertion that addressing are used for routing, and the
> notion that addresses are hierarchical.  
> I think this goes to the definition of an "address" as a string that can
> be parsed to locate an endpoint in the infrastructure.

It is interesting to see that in the late seventies, people apparently
mixed the concepts of address and route. Not surprising, since a
telephone number is both a number as well as a description of the route
how to reach it.

> b)  NML..."NSI has a problem".   
> I don't understand this comment.  

This is self-critcism that at least I never clearly communicated the
difference to the NSI group, and that we're now having this discussion.

Freek

-- 
Freek Dijkstra
| Group Leader & Network Expert | Infrastructure Services | SURFsara |
| Science Park 140 | 1098 XG Amsterdam | +31 6 4484 7459 |
| Freek.Dijkstra at surfsara.nl | www.surfsara.nl |

Available on Mon | Tue | Wed | Thu |

-------- Original Message --------
Subject: 	Re: [Nml-wg] [Nsi-wg] Wednesday's NSI standards conf call
Date: 	Wed, 12 Feb 2014 00:25:35 -0500
From: 	Jerry Sobieski <jerry at nordu.net>
Organisation: 	NORDUnet
To: 	Freek Dijkstra <Freek.Dijkstra at surfsara.nl>

Hi Freek-

Interesting slides.  Slide 2 says it all...  But I have some issues that
I think you mis-understand about NSI.
So let me make some points:

a) Slide 3: What do we need for NSI?
*STPs* - An STP is service termination point.  A concept.    The STP
"_/Identifier/_" is the name for the STP.   It is a 2-tuple
<networkid>:<localid>.   These carry no routing information other than
the name of the network in which the STP resides.  So subtle
difference:  An STP is the object,  An STP Identifier names the object.
An STP n-tuple is the topological address of the object.
*NSI Network* - Is a service domain bounded by STPs.  An NSI Network Id
names the domain.   THe boundaries of that domain are defined by the
STPs (since all STPs are at the edge of a NSI Netwokr service domain.)
The Network identifier only needs to be unique within the use context of
NSI Networks (i.e. we don't care if the same string is used in a
different application for a different concept.)
*SDP*s - These are data plane adjacencies, i.e. they  describe a
*relationships* between two STPs.   SDPs are specified as a pair of /STP
Identifiers/.   They describe the adjacencies among networks.

These three objects are necessary and sufficient for NSI path finding to
functioning.  These three objects represent the Ports, Nodes, and Links
found in graph theory.   This resource graph model that NSI originally
supported (and still does) scales well and can actually be used
recursively.   THis topology model is specifically designed to address
the needs of a connection service - ie a _/Service/_.  It is not
intended to describe plumbing.

We do not need "intermediate" STPs ... this is meaningless in NSI
(though I don't think everyone understands this.).   STPs should
properly only exist at the edge of a network - since by definition they
define the edge of a switching domain.  IMO, an STP should be
unidirectional only(!)   We can support STPs in an ERO in the Reserve()
command but this should be indistinguishable from submitting each ero
segment individually.

b) Slide 5; Your assertion that addressing are used for routing, and the
notion that addresses are hierarchical.
I think this goes to the definition of an "address" as a string that can
be parsed to locate an endpoint in the infrastructure.   In this
interpretation, our STP Identifier 2-tuple is partly address and partly
name.   The Network ID is the address part and it is public.  The
localid is a name for the local address n-tuple.   If we looked at the
local address it would be something like <switch id><blade Id> <port
#><VLAN#> etc.

So I have always asserted that the STP Identifier is a 2-tuple name.
And that when the NRM provisions the path inside a domain, it must
translate the name (the localid) to the n-tuple address.   THis is in
fact what OpenNSA does - it has a topology table that maps the localid
to the n-tuple topological address.   The n-tuple is then broken up and
each component is used to perform path finding or provisioning.

b)  NML..."NSI has a problem".
I don't understand this comment.
NSI has always said the _/STP Identifier/_ (i.e. the 2-tuple
<network>:<localid> ) was just a name for an end point.   The STP
identifiers did not contain any topological specification besides the
Network Id in which the LocalID was to be found.  And the NSI Network ID
itself contains no routing or other topo information - it is simply a
tag.   Pathfinders essentially ignore the LocalID, and only look for the
src and dest Network IDs in the topology.   The PF only needs to
determine the inter-domain path it wishes to use - and this only
requires knowledge of the SDPs (i.e. the Network adjacencies).   The PF
needs no internal domain topological information, nor does it need any
physical topological addressing to do this.   So tell me do say NSI has
a problem?

It has always been the responsibility of the NRM (internal to a domain)
to resolve the local Id into the topological addressing info that
corresponds to the end point in the local physical infrastructure and
then do the necessary internal path selection and configuration.  This
internal work is a local internal responsibility and NSI need not deal
with it.   (Indeed, NSI expects a domain to perform this internal
pathfinding and configuration - it is that domain's responsibility...

This internal topological address is the "n-tuple" representation of an
STP containing:  <switch element id> + <blade #> + <port #> + <vlan tag>
+ etc.   Each network can use whatever addressing n-tuple they deem
necessary depending on their hardware and internal provisioning model.
Since this is an internal issue for the NRM, NSI does not care.

NSI originally only recognized the 2-tuple.  And the 2-tuple was the
only aspect of STPs that needed to be carried in the NSI Reservation
Request.  And it was the NRM's job to translate the 2-tuple to an
internal n-tuple address. THe 2-tuple hides all internal topological
address structure and is easier to use, so it will be the most commonly
used form in NSI.      Some folks suggested that NSI should also
recognize the "N-tuple" physical address.   I did not think this was
necessary, practical, or smart, but I was convinced by Tomohiro that if
a requester somehow magically knew the physical n-tuple address of the
desired end point, then why not allow the protocol to carry it along?
It does not change the service model.    So a Reservation could have
either a) a 2-tuple STP Identifier, or b) and n-tuple STP physical
topological address.    How to tell the difference?

Enough for now...  Suffice it to say I think we should review the STP
naming and reference aspects.   I think there are ways we can retain key
important features, and introduce the proper (simplifying) concepts.   I
do not think we should parse URNs.   Indeed, I do not think we need or
should use URNs in NSI.  I think we need to rethink our specification
syntx for end points .

Late here...gotta sleep.  Thanks for reading this.
Jerry

On 2/10/14 6:57 PM, Freek Dijkstra wrote:
> On 10-02-2014 13:04, Guy Roberts wrote:
>
>> -          Freek Dijkstra to present on the distinction between
>> identifiers and addresses in NML.  (20 minutes)
> Attached you will find the slides I like to present.
>
> With kind regards,
> Freek Dijkstra
>
>
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg