Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: what is virtual and what...)

From: Pekka Nikander <[email-masked]>
Date: Fri, 1 Dec 2006 10:36:52 +0200

Geoff, Noel, and all,

When I was saying that SHIM6 is a watered down version of HIP, I was  
mostly speaking from an architectural and long-term point of view.   
I'm trying to clarify that below, replying to your messages.

Geoff Huston spoke wisely:
> My personal view is that there is a significant difference between   
> a host-level approach and a transport session level approach that  
> you seem to have missed in your note.  I find myself in  strong  
> disagreement with your perspective of SHIM6 as some kind of diluted  
> or  compromised version of HIP.

I can easily understand your point of view and appreciate that you  
disagree with me, though I don't quite understand what you mean with  
a "host-level" vs. "transport session level" approach.  Would you  
care to clarify?

However, overall, I think that perhaps we could agree to disagree  
here, hopefully understanding that we looking at these two artefacts  
(HIP and SHIM6) from very different points of view.

There *are* differences between HIP and SHIM6.  Some of the  
differences appear very significant from a short-term operational  
point of view.  If I understand you correctly (please correct if I'm  
reading you wrong), that's what you consider most important.  Indeed,  
from that point of view SHIM6 can really be considered as a better- 
engineered protocol (and not a watered down version), since it  
addresses some operational aspects that HIPpers are just slowly  
copying from SHIM6, and, perhaps most importantly, SHIM6 does not  
mandate any changes into the DNS data or require any new  
infrastructure while HIP does.

However, my point of view was and still is architectural and long- 
term.  From that point of view, I stand behind my words.  I can try  
to explain my point even more rigourously if needed, but I said  
already most of what I wanted to say in http://www1.ietf.org/mail- 
archive/web/architecture-discuss/current/msg00837.html

> Frankly, [...], there is much involved here. To expect any  
> particular approach to get it all right first time is asking too  
> much. HIP and SHIM6 are examples of trying to understand what these  
> concepts look like in code and in protocol stacks. They bed down  
> these otherwise abstract discussions with some experience with  
> implementation and the harsh realities of deployment in the network.

I couldn't agree more.

> For you that may well be band aid.

I'm calling it band aid since it is all relatively short-term to me.   
I once thought that HIP would be a long-term solution, but no longer  
do.  I think that proves your point above: you cannot get all right  
the first time.  :-)

> For me its part of the scientific investigatory process of devising  
> an hypothesis, and then testing this hypothesis, and then looking  
> very hard to make sure that the hypothesis remains intact.

Yes, indeed!  Any ideas need to be tested.  With HIP we are getting  
there now, hopefully, and I've understood that the first SHIM6  
implementations are getting ready as well.

> As far as I can see, we [...] still have much to learn here.

That's the whole point of having this discussion, at least to me.  To  
learn what I'm missing and understanding badly, and also slowly  
learning to see the things with other people's eyes.

Yes, I know I appear sometimes quite arrogant and perhaps even  
elitist.  My apologies for that.  One reason behind is my still- 
persisting frustration...

---

Andrew McGregor <[email-masked]> once wrote:
>> .. what HIP and SHIM6 both give you is the ability to assert that  
>> something accessible at location A is also accessible at locations B
>> through ...
>> .. but the core of what the protocols provide is very similar.

On 1 Dec 2006, at 06:39, Noel Chiappa wrote:
> Yes and no, I think - but I kind of phased out on the finer details  
> of HIP and SHIM6, so the following comments may not be accurate,  
> and I'd appreciate any corrections to possibly mistaken impressions.
>
> My impression is that although to an initial glance (if you  
> consider a few "how do I do thing X" cases) they do look like they  
> provide similar capabilities (as you point out), I think that  
> perhaps at a deeper level HIP is more powerful, architecturally.  
> The reason is simple: HIP brings an extra namespace to bear, and at  
> an architectural level that's very powerful.

 From the 10000 feet point of view, I think that is exactly right.   
HIP was designed with a new name space very much in mind, from the  
beginning.  SHIM6 started from functional requirements, and the a new  
name space was not there, rather the reverse.

However, with the introduction of CGA-based SHIM6 ULIDs, you can kind- 
of retrofit a new name space into SHIM6.  I have to admit not having  
read the latest versions of the specs, but my impression is that the  
value of such possibility is still not appreciated and there's been  
relatively little thought about that.  But I may be wrong.

Hence, while in theory HIP is architecturally more powerful due to  
the new name space, in reality you apparently can do the same things  
with SHIM6.  Perhaps not that elegantly than with HIP (that is, if  
HIP can be considered elegant :-), but still.

> Also, SHIM6 overloads one more meaning onto an existing namespace  
> (IPv6 addresses), and, architecturally speaking, that's always  
> bad.  Yes, yes, I know, the idea is that there will be two separate  
> namespaces that just happen
> to share a syntax.

But so does HIP with its backwards compatibility mode.  That's the  
whole point with the ORCHID draft: to allow existing applications to  
work unmodified, by overloading the IPv6 syntax.

> However... we all know that anytime there is the possibility of  
> kludging something (in this case, by treating a name from sub-space  
> A as if it were a name from sub-space B), someone somewhere will do  
> it, as a "quick hack" to solve some problem they have, and then  
> you're in the soup. Only with a complete separate namespace is  
> there no possibility of hacks that entangle (and strangle) a design.

Indeed.  However, in this particular case I think that the value of  
backwards compatibility may exceed the drawbacks.  In any case, there  
is also an attempt to define a new API that could be used with any  
shim-like approach, including SHIM6 and HIP.

So, to summarise, at the grass roots level HIP and SHIM6 are closer  
to each other today than many people may think or would like to  
admit.  I think that is quite natural: implementation wise, the  
differences are relatively small, at least if you implement also CGAs  
for SHIM6.  For example, it looks like that the first SHIM6  
implementations will be based on existing HIP ones.

--Pekka Nikander

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Dec 2006 11:37:47 +0100

> Also, SHIM6 overloads one more meaning onto an existing namespace (IPv6
> addresses), 

I think of it a little differently. SHIM6 recognizes the fact that IP addresses
are already viewed from "above" as stack identifiers and from "below" as stack
locators. It makes use of that existing overloading to decouple the two views.

> and, architecturally speaking, that's always bad. Yes, yes, I
> know, the idea is that there will be two separate namespaces that just happen
> to share a syntax. 

Well, SHIM6 really preserves a single namespace but treats it as
having two surfaces.

> However... we all know that anytime there is the
> possibility of kludging something (in this case, by treating a name from
> sub-space A as if it were a name from sub-space B), someone somewhere will do
> it, as a "quick hack" to solve some problem they have, and then you're in the
> soup. Only with a complete separate namespace is there no possibility of
> hacks that entangle (and strangle) a design.

Correct. But the problem we have is the existing upper layer legacy, which
I believe is much harder to change than we Layer 3 geeks tend to believe.
So we come up with things like SHIM6 or ORCHID (draft-laganier-ipv6-khi).

     Brian

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 1 Dec 2006 12:45:00 -0500

I believe Noel has the two correct and HIPs strength.  I would suggest
the finer grain details of the transport communications in SHIM6 and
from implementation view are easier to identify and ship faster.

/jim 

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Thursday, November 30, 2006 11:40 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: 
> On identifiers:what is virtual and what...)
> 
>     > From: Andrew McGregor <[email-masked]>
> 
> Yes and no, I think - but I kind of phased out on the finer 
> details of HIP and SHIM6, so the following comments may not 
> be accurate, and I'd appreciate any corrections to possibly 
> mistaken impressions.
> 
> consider a few "how do I do thing X" cases) they do look like 
> they provide similar capabilities (as you point out), I think 
> that perhaps at a deeper level HIP is more powerful, 
> architecturally. The reason is simple: HIP brings an extra 
> namespace to bear, and at an architectural level that's very powerful.
> 
> Also, SHIM6 overloads one more meaning onto an existing 
> namespace (IPv6 addresses), and, architecturally speaking, 
> that's always bad. Yes, yes, I know, the idea is that there 
> will be two separate namespaces that just happen to share a 
> syntax. However... we all know that anytime there is the 
> possibility of kludging something (in this case, by treating 
> a name from sub-space A as if it were a name from sub-space 
> B), someone somewhere will do it, as a "quick hack" to solve 
> some problem they have, and then you're in the soup. Only 
> with a complete separate namespace is there no possibility of 
> 	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 1 Dec 2006 12:49:58 -0500

Well stated and I agree with most below.  My view and support of SHIM6
is that it can adapt to new architecture models and further to HIP and
the name space and actually could be an additional SHIM6 set of specs.
I feel SHIM6 is the IETF energy vehicle to address this part of a change
to the architecture model for transport.

/jim 

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Friday, December 01, 2006 3:37 AM
> To: Noel Chiappa; Geoff Huston
> Cc: [email-masked]
> > a host-level approach and a transport session level 
> approach that you 
> > seem to have missed in your note.  I find myself in  strong 
> > disagreement with your perspective of SHIM6 as some kind of 
> diluted or  
> > compromised version of HIP.
> 
> I can easily understand your point of view and appreciate 
> that you disagree with me, though I don't quite understand 
> what you mean with a "host-level" vs. "transport session 
> level" approach.  Would you care to clarify?
> 
> However, overall, I think that perhaps we could agree to 
> disagree here, hopefully understanding that we looking at 
> these two artefacts (HIP and SHIM6) from very different 
> points of view.
> 
> differences appear very significant from a short-term 
> operational point of view.  If I understand you correctly 
> (please correct if I'm reading you wrong), that's what you 
> consider most important.  Indeed, from that point of view 
> SHIM6 can really be considered as a better- engineered 
> protocol (and not a watered down version), since it addresses 
> some operational aspects that HIPpers are just slowly copying 
> from SHIM6, and, perhaps most importantly, SHIM6 does not 
> However, my point of view was and still is architectural and 
> long- term.  From that point of view, I stand behind my 
> words.  I can try to explain my point even more rigourously 
> if needed, but I said already most of what I wanted to say in 
> http://www1.ietf.org/mail- 
> particular 
> > approach to get it all right first time is asking too much. HIP and 
> > SHIM6 are examples of trying to understand what these concepts look 
> > like in code and in protocol stacks. They bed down these otherwise 
> > abstract discussions with some experience with 
> implementation and the 
> > harsh realities of deployment in the network.
> 
> I couldn't agree more.
> 
> I once thought that HIP would be a long-term solution, but no 
> longer do.  I think that proves your point above: you cannot 
> get all right the first time.  :-)
> 
> > For me its part of the scientific investigatory process of 
> devising an 
> > hypothesis, and then testing this hypothesis, and then looking very 
> > hard to make sure that the hypothesis remains intact.
> 
> Yes, indeed!  Any ideas need to be tested.  With HIP we are 
> getting there now, hopefully, and I've understood that the 
> first SHIM6 implementations are getting ready as well.
> 
> That's the whole point of having this discussion, at least to 
> me.  To learn what I'm missing and understanding badly, and 
> also slowly learning to see the things with other people's eyes.
> 
> Yes, I know I appear sometimes quite arrogant and perhaps 
> even elitist.  My apologies for that.  One reason behind is 
> my still- persisting frustration...
> 
> ---
> 
> details of 
> > HIP and SHIM6, so the following comments may not be 
> accurate, and I'd 
> > appreciate any corrections to possibly mistaken impressions.
> >
> consider a 
> > few "how do I do thing X" cases) they do look like they provide 
> > similar capabilities (as you point out), I think that perhaps at a 
> > deeper level HIP is more powerful, architecturally.
> > The reason is simple: HIP brings an extra namespace to 
> bear, and at an 
> > architectural level that's very powerful.
> 
> HIP was designed with a new name space very much in mind, 
> from the beginning.  SHIM6 started from functional 
> requirements, and the a new name space was not there, rather 
> the reverse.
> 
> However, with the introduction of CGA-based SHIM6 ULIDs, you 
> can kind- of retrofit a new name space into SHIM6.  I have to 
> admit not having read the latest versions of the specs, but 
> my impression is that the value of such possibility is still 
> not appreciated and there's been relatively little thought 
> about that.  But I may be wrong.
> 
> Hence, while in theory HIP is architecturally more powerful 
> due to the new name space, in reality you apparently can do 
> the same things with SHIM6.  Perhaps not that elegantly than 
> with HIP (that is, if HIP can be considered elegant :-), but still.
> 
> > (IPv6 addresses), and, architecturally speaking, that's 
> always bad.  
> > Yes, yes, I know, the idea is that there will be two separate 
> > namespaces that just happen to share a syntax.
> 
> But so does HIP with its backwards compatibility mode.  
> That's the whole point with the ORCHID draft: to allow 
> existing applications to work unmodified, by overloading the 
> IPv6 syntax.
> 
> > kludging something (in this case, by treating a name from 
> sub-space A 
> > as if it were a name from sub-space B), someone somewhere 
> will do it, 
> > as a "quick hack" to solve some problem they have, and then 
> you're in 
> > the soup. Only with a complete separate namespace is there no 
> > possibility of hacks that entangle (and strangle) a design.
> 
> Indeed.  However, in this particular case I think that the 
> value of backwards compatibility may exceed the drawbacks.  
> In any case, there is also an attempt to define a new API 
> that could be used with any shim-like approach, including 
> SHIM6 and HIP.
> 
> So, to summarise, at the grass roots level HIP and SHIM6 are 
> closer to each other today than many people may think or 
> would like to admit.  I think that is quite natural: 
> implementation wise, the differences are relatively small, at 
> least if you implement also CGAs for SHIM6.  For example, it 
> looks like that the first SHIM6 implementations will be based 
> on existing HIP ones.
> 
> --Pekka Nikander
> 
>