Subject: [RRG] FW: I-D ACTION:draft-schuetz-nid-arch-00.txt

From: "Simon Schuetz" <[email-masked]>
Date: Thu, 20 Sep 2007 12:13:56 +0200

FYI,

We submitted a proposal for a future Internetworking Architecture that we would like to bring to your attention.

Comments welcome,

Simon

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

 > -----Original Message-----
 > From: [email-masked] [mailto:[email-masked]] 
 > Sent: Tuesday, September 18, 2007 9:15 PM
 > To: [email-masked]
 > Subject: I-D ACTION:draft-schuetz-nid-arch-00.txt 
 > 
 > A New Internet-Draft is available from the on-line Internet-Drafts 
 > directories.
 > 
 > 
 > 	Title		: Node Identity Internetworking Architecture
 > 	Author(s)	: S. Schuetz, et al.
 > 	Filename	: draft-schuetz-nid-arch-00.txt
 > 	Pages		: 21
 > 	Date		: 2007-9-18
 > 	
 >    This document describes a new proposal for a future Internet
 >    architecture.  Similar to many other proposals it employs 
 > a locator/
 >    identifier split to overcome the short-comings arising 
 > from the dual
 >    role of IP addresses.  Similar to the Host Identity Protocol, each
 >    node carries a unique, randomly self-generated identifier - the
 >    public part of a public/private key pair.  It can 
 > therefore directly
 >    be used for authentication and authorisation purposes.  Different
 >    from some other proposals, the Node Identity Internetworking
 >    architecture does not try to converge on a single 
 > (globally managed)
 >    address space, but instead accepts the co-existence of different
 >    networking domains - here called locator domains.  
 > Routing within the
 >    architecture is based on a two-level approach.  First, 
 > routing within
 >    a locator domain is managed by the internal addressing and routing
 >    scheme of the locator domain.  Second, routing between locator
 >    domains involves specialized nodes at locator domain borders.  By
 >    grouping the nodes into locator domains, the effects of certain
 >    events such as mobility can often be localised, thus reducing the
 >    impact on the global network.
 > 
 > A URL for this Internet-Draft is:
 > http://www.ietf.org/internet-drafts/draft-schuetz-nid-arch-00.txt
 > 
 > To remove yourself from the I-D Announcement list, send a message to 
 > [email-masked] with the word unsubscribe in 
 > the body of 
 > the message. 
 > You can also visit 
 > https://www1.ietf.org/mailman/listinfo/I-D-announce 
 > to change your subscription settings.
 > 
 > Internet-Drafts are also available by anonymous FTP. Login with the 
 > username "anonymous" and a password of your e-mail address. After 
 > logging in, type "cd internet-drafts" and then 
 > "get draft-schuetz-nid-arch-00.txt".
 > 
 > A list of Internet-Drafts directories can be found in
 > http://www.ietf.org/shadow.html 
 > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 > 
 > Internet-Drafts can also be obtained by e-mail.
 > 
 > Send a message to:
 > 	[email-masked].
 > In the body type:
 > 	"FILE /internet-drafts/draft-schuetz-nid-arch-00.txt".
 > 	
 > NOTE:	The mail server at ietf.org can return the document in
 > 	MIME-encoded form by using the "mpack" utility.  To use this
 > 	feature, insert the command "ENCODING mime" before the "FILE"
 > 	command.  To decode the response(s), you will need "munpack" or
 > 	a MIME-compliant mail reader.  Different MIME-compliant 
 > mail readers
 > 	exhibit different behavior, especially when dealing with
 > 	"multipart" MIME messages (i.e. documents which have been split
 > 	up into multiple messages), so check your local documentation on
 > 	how to manipulate these messages.
 > 
 > Below is the data which will enable a MIME compliant mail reader
 > implementation to automatically retrieve the ASCII version of the
 > Internet-Draft.
 >

---

From: Pekka Nikander <[email-masked]>
Date: Thu, 20 Sep 2007 14:09:37 +0300

Hi Simon,

A simple question to start with:  Why do you wanted to introduce new  
terminology for what basically appears to be identical of what the  
HIP architecture [RFC4423] proposes, and to which you seem to rely?   
That is, why do you want to call a HIP "HI" as a "NID" in your  
proposal, or a HIP "HIT" as "NIFT" in your proposal?  Also, what you  
call NRs in your document seem to be basically a combination of a HIP  
SPINAT box and a HIP rendezvous servers (RVS), with the additional  
twist of the RVS being located in multiple locator domains at the  
same time.

To me, that makes it much harder to read and understand your document  
as I must make constant mapping in my mind while reading your  
document.  (Based on my casual reading, you seem to be going further  
along the lines that Ylitalo et al introduced in their paper -- a  
very welcome direction to me.)  It also makes it hard for me to  
understand what are the additional benefits to existing work, and how  
exactly they are achieved.

--Pekka

On 20 Sep 2007, at 13:13, Simon Schuetz wrote:

>
> FYI,
>
> We submitted a proposal for a future Internetworking Architecture  
> that we would like to bring to your attention.
>
> Comments welcome,
>
> Simon
>
>
>
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,  
> London W3 6BL | Registered in England 2832014
>
>> <ATT1546449.TXT>
>> <draft-schuetz-nid-arch-00.URL>
>> <ATT1546450.txt>

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

---

From: "Simon Schuetz" <[email-masked]>
Date: Fri, 21 Sep 2007 11:31:58 +0200

> HIP architecture [RFC4423] proposes, and to which you seem 

Hi Pekka,

One reason is that we basically want people to think "fresh". The Node Identity Internetworking Architecture is in some parts (loc/id split, crypto ID) pretty similar to HIP, but it is not HIP.

As stated in the draft, using HIP as a basis gives you one instantiation of the architecture, but not the only one.

 > twist of the RVS being located in multiple locator domains at the  

This is not completely true. First, implementing the NR as a modified SPINAT is just one option. If you e.g. implement the data protocol in a stateless variant as mentioned in the draft, then you don't need SPINAT at all, but you forward based on the NIFTs included in the packets, and not based on the SPI of ESP packets.

Also,  even if you base the implementation on HIP, you cannot use the mentioned elements (SPINAT,RVS) as they are.  E.g. within the NID architecture, you explicitly address the IP packets to the next-hop NR or the destination node (on the last hop). A NR then rewrites the IP header to address it to the next NR (or the final destination node for the last hop). I.e., the NRs are explicitly in the communication path while SPINAT is as transparent as any other NAT.

Simon