[icnrg] Comments on draft-azgin-icnrg-ni-01

["David Oran" <[e-mail]>]

I spent some time going over “Enabling Network Identifier (NI) in 
Information Centric Networks to Support Optimized Forwarding” ( 
draft-azgin-icnrg-ni-01).

Here are my comments, with <Chair Hat Off>

### General Comments

This is a potentially useful position paper. It takes the position that 
ICN would benefit from having a separate routing-friendly identifier in 
order to scale global routing, and that the application-assigned names 
cannot be directly used in many cases to achieve feasible global routing 
capability. This is an attractive idea in many ways, but is not 
universally subscribed to in the ICN community. In order to have the 
separate “Network Identifier” (NI) from the “Application 
Identifier” (AI), some way to carry the NI in packets, derive it from 
the AI, and forward based on it are needed. The main material in the 
document addresses these questions.

This reviewer is not among the set of people convinced by the arguments 
in this paper; nonetheless it has a lot of good material, and  a good 
set of references. I would advocate that after more work to address 
these (and hopefully other ICNRG participant) comments, it would be a 
useful addition to the literature and hence publishable as an individual 
contribution RFC. I am less enthusiastic about adopting this as an ICNRG 
draft, unless one or more people with differing/opposing views add 
material to the document to make it a more balanced discussion of the 
the ways naming interact with ICN routing/forwarding scalability and 
security. In particular, security gets very little attention in this 
position paper. Security considerations around AI/NI mapping, trust in 
routing directives, and tradeoffs in control by consumers/publishers 
versus network operators needs to get significantly more attention.

## Detailed comments
####Abstract
The abstract already argues that a network-based name resolution service 
is mandatory. This is not entirely obvious and it is certainly not 
obvious that the NRS needs to be “network based”. It could be 
designed as an ICN application, and not even be “global” in the 
sense that  single NRS serves all of the global namespace.

####1 Introduction
- As I’ve commented elsewhere, the term “location” is introduced 
informally, and this makes for confusion right off the bat. In this 
paragraph, you don’t need to wade into the “location swamp” as in 
this context you could just as easily say “contents, services, and 
services become disentangled from particular hosts…”

####2 Application Identifier (AI) vs. Network Identifier (NI)
in the first paragraph you say “a flat identifier offers a fixed 
predictable overhead and variable security properties within a given 
context” I get the first property, but I have no idea what “variable 
security properties within a given context” means.

Some real difficulties start in the second paragraph. Among my 
doubts/questions/complaints are:

- you say the NI provides a binding for the AI to the network *at a 
location*. Why only one? Why not a set?
- you say the NI is “managed by the network provider to  name the 
routers, point of attachments, servers and end devices” This is 
orthogonal to the point of the paper, since all of those things are 
owned by the network operator and he can name them any way he wants. In 
fact, he can assign AI’s to these things since he knows how to route 
to them on his own infrastructure and not need an NI at all.
- you say “NI could assume names of the underlay network as well, such 
as IP or Ethernet addresses” I don’t see how this helps/works since 
in those cases you need an underlay running those protocols anyway, so 
you already have a map/encap happening without inserting an NI at the 
ICN layer.
- while you say the growth of NI can be much smaller than the growth of 
AI, your argument for why doesn’t hold water. If AI grows via more 
objects under routable prefixes that grow no faster than the growth rate 
of infrastructure, the scaling for routing will be similar. There’s a 
true point here about high-level name authorities growing faster than 
infrastructure providers, but you don’t make it.
- you say “it is desirable to route requests on NIs, with the mapping 
between AI and NI is achieved in a scalable manner using a   network 
based name resolution system.” That is one possibility; however there 
are others, such as the CCN approach of alternative equivalent names 
with Manifests.

Further on, starting on page 4,

- you say “names or identifiers …typically managed by  applications, 
thereby of persistent nature” - what does persistence have to do with 
this? some names, particularly in the context of real time multimedia, 
may have little persistence - a few RTTs or so.
- You say “Overloading an identifier as a locator can lead to unstable 
routing control”. First I don’t think using an identifier for 
routing and matching against named content constitutes 
“overloading”. Second, what do you mean by “unstable routing 
control”? Just because something has a high update rate (you mention 
mobility), or multiple feasible destinations (you mention replication) 
does not necessarily mean there’s any instability. Further, the 
problem of high state mutation rates is inherent to mobility (in the 
absence of cheap broadcast), and whether it is routing state changing 
fast, or AI/NI binding state changing fast at first order makes no 
difference. In fact it’s quite likely that routing state update could 
be considerably *more* efficient than binding state update.
- Why do you say that “name aggregation does not help with scaling the 
routing and forwarding as originally imagined” I doubt anybody with 
even minimal technical clue imagined that name aggregation would lead to 
routing scaling in ICN.

The next paragraph starts by presuming that NIs and routing are 
inherently needed together, which you have argued but hardly proved. 
Might be better to s/Routing scalability is typically achieved by 
designing NIs with aggregate-able property/Routing scalability is 
typically  achieved by designing routing state with aggregate-able 
property/. The fact that provider-independent addressing in IP is not 
common has many causes, one of which is non-aggregatability, but there 
are others, such as the economics of BGP route advertisements (the 
creator of state is not the one who pays the cost of distributing the 
state), and the ownership properties of IP address blocks.

- I also don’t follow the argument that avoiding NIs somehow leads to 
“relinquishing the persistency of names”.
- Nor the argument that it relinquishes the security bindings such as 
trust - trust is established by how you bind keys to names, not how 
persistent the names are.

####3 NI based ICN forwarding

In addition to the cases you cite at the beginning of this section, an 
important additional use case is infrastructure-less configurations that 
do not need to scale globally.

In the next paragraph, I was trying to follow your argument of where NI 
becomes important. Why is there necessarily a correspondence between 
domain boundaries and whether routing state exists in both domains 
sufficient to route on AIs? I also don’t follow why necessarily domain 
entry triggers the usage of an NI. I could argue just the opposite- when 
you enter a domain with relatively complete routing state, the domain 
can route directly rather than having to do any kind of NI mapping.

A bit further along, you make a pretty strong claim: “However, as 
significant amount of user traffic fetches resources outside the   
requesting host's local domain, it becomes crucial to provide  
architectural support for NI in an ICN protocol.” What is crucial is 
to be able to route globally, however you do it. Architecturally 
mandated NIs are one way. Tunneling is another, Source routing is 
another. Multiple published names with Manifests is another. There are 
many ways to skin this cat. You do say up front that NI is optional, not 
mandatory, but is this optional to implement? Optional to use? Is there 
one mandated format? Globally agreed semantics for the trust assertions 
in the bindings between AIs and NIs?

####3.1 Label based ICN forwarding

- why are security bindings considered optional? forwarding labels would 
seem to be a devil’s playground, especially if they survive domain 
crossing. If they don’t we wind up with a feature that is much less 
useful than it might be as we’ve seen with DSCPs.
- you say forwarding labels can guide interests toward a cache (in 
addition to producers or repositories). This is an interesting 
capability, similar to what can be done with cache steering for cache 
clusters. This probably deserves a separate discussion, rather than 
being buried here.
- I think the question of whether label-based forwarding treats labels 
as always having precedence is kind of an independent property from the 
other properties of forwarding labels. What is the thinking behind the 
static precedence requirement? I don’t see how this helps compared to 
leaving it as a local forwarder decision, other than perhaps removing 
some cases where there could otherwise be loops. Similarly, I don’t 
get why it can’t be treated as a hint to be used when there’s no 
route in the FIB for the AI, as you talk about for link objects.
- Why only one forwarding label per interest packet? I can envision a 
system where there are multiple, at different granularities, and the 
forwarder picks the “best” one (e.g. the one for which it has the 
best LPM FIB entry).
- You talk a bit about forwarding labels allowing non-ICN names and 
instead using transport addresses. This seems quite problematic 
especially when combined with tunneling. You could put in a forwarding 
label that could result in an upstream forwarder blindly tunneling an 
ICN packet to anywhere.

The next paragraph, starting “Forwarding label consists”, needs a 
bunch of language fix up. Also:

- you say “if the namespace supports the use of an NI to reach a 
specific destination” This is the first mention of NI usage being 
bound to a namespace. If you actually meant to say this, it could be an 
interesting idea, but raises a ton of questions, like how that binding 
is made and checked. Why would you do this? Are there certain namespaces 
that are known a priori to need NI in order to have its objects be 
reachable? (The next paragraph further mentions this possibility by 
starting “Forwarding label support for a namespace can be offered at a 
global…”)
- a bit later you say NIs can be mutated “depending on the feedback 
from the name resolution system” ignoring for the moment whether an 
NRS provides feedback or only answers questions, there might easily be 
other reasons to swap NIs like having local IGP information - segment 
routing in IP can do this.

Parts of the paragraph starting “Forwarding label support” are 
pretty hard to follow and tend to wander into separate issues, like QoS. 
  I also wonder whether you want to characterize mobility as a 
“service”, since it’s so baked into ICN as a native feature.

####3.2 Link-object based ICN forwarding

- Why do you think using link objects constitutes “Map-and-encap”?

####3.3 Link Object vs. Forwarding Label

This section reads more like an argument in favor of forwarding labels 
that a list of differences. It needs a more balanced presentation. For 
example, the first paragraph attributes certain “network based 
management” advantages to forwarding labels, which, by implication, 
you think link objects do not have. However, they might, especially if 
counter-signed by the network operator and ignored or generating a NAK 
otherwise.

- As an example of things that might argue for link objects, here’s 
some possible text: “Conversely, the link object constrains a network 
operator from overriding a consumer’s intent, for example where the 
consumer knows that a certain triangle routing path will outperform 
native service provider paths”.

- Another example is where you say that the optionality of the the 
security binding for the forwarding label is a feature since it 
contextualizes the trust relationship. A counter view is perhaps “The 
former puts all trust assessment in the producers and consumers; the 
latter relieves users of this burden but opens the system to route 
hijacking similar to what we see with BGP”.

- For the paragraph about forwarding efficiency, you make the claim that 
NI-based forwarding labels are more flexible operation in routing. This 
is arguable, as the router could always put the equivalent FIB entry in 
based on the same mapping data that created the NI binding. Putting 
forwarding state in the packet sometimes wins; putting it in the FIB 
sometimes wins. If putting it in the packet wins sufficiently 
frequently, the forwarding-labels may be desirable, however there are 
other ways to skin the cat using path switching or tunneling.

- The next paragraph says “Forwarding label, on the other hand, can be 
enabled as part of a service, which limits the use of forwarding label 
to the supported namespaces, while at the same time requiring its use 
whenever/wherever supported.” I think this needs a lot more 
explanation, with example “services” and how forwarding label 
enables these when a link object or other techniques do not. (Aside: In 
doing so take care to not declare as “services” obnoxious 
middleboxes than screw up consumers’ intents as has occurred too much 
in the IP world. This is a particularly sensitive topic, as I’ve heard 
occasional arguments in favor of ICN from service providers that it 
restores their ability to re-insert themselves in application 
interactions as IP becomes more transparent through e2e encryption ).

- You say “Even though this selection is shared between consecutive 
hosts, it is not enforced, thereby potentially leading to non-optimal 
forwarding paths.” What does “shared between consecutive hosts” 
mean? Do you mean hosts or routers? A bit further you say “Hence, 
forwarding label presents the network with the ability to consistently 
forward packets over optimal paths towards a content source.” I’m 
not sure this is true, and perhaps only true if the IGP is itself 
optimal.

####4 Name Resolution System Considerations

I didn’t spend much time on this section, as it might be more easily 
cut down or eliminated once there is a mature NRS document to point to.  
The material is very general, and doesn’t really get into what kind of 
NRS is a good match for which style of forwarding. Most limiting, 
however, is the lack of any discussion of security. Not so much of the 
NRS itself (which belongs in an NRS specification) but of the tricky 
issues of who attests to what in the creation, maintenance, and usage of 
the AI/NI bindings (I think link objects already cover this aspect quite 
extensively). That is needed in this document, independent of the nature 
of any NRS that stores and regurgitates them.


David R. Oran
Network Systems Research & Design
4 Shady Hill Square
Cambridge, MA 02138 USA