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

["Simon Schuetz" <Simon.Schuetz@nw.neclab.eu>]

 > 
 > 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?   

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.

 > 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.

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

 > 
 > 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
 > 


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

--
to unsubscribe send a message to rrg-request@psg.com 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