Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec

From: "Jasani Rohan" <[email-masked]>
Date: Mon, 2 Oct 2006 16:24:39 -0400

Lars:
My comments are inline.  Thanks

Rohan Jasani
Booz | Allen | Hamilton
703.984.0337 (office)
832.452.3241 (mobile)

> -----Original Message-----
> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]] 
> Sent: Friday, September 29, 2006 9:26 AM
> To: Jasani Rohan; [email-masked]
> Subject: RE: [rohc] FW: IPsec Processing & HCoIPsec
> 
> Ok, let me then summarize my main point here. I did think the 
> idea of registering a PROTOCOL NUMBER was ok as long as we 
> talked about registering an unambiguous identifier for the 
> ROHC header compression platform. However, I do not like the 
> idea with a "generic", as I see it ambiguous, identifier. 

I'm still not convinced as to why an ambiguous identifier would be a
problem, as negotiation of state will resolve any of the concerns voiced
thus far.

We originally proposed the Unification approach, which stipulated that a
single unambiguous IANA value would be allocated specific to ROHC.
However, there was push back from the ROHC WG members on "unififying"
the two HC schemes, by plugging ECRTP into ROHC.  This is still another
viable option ?

> Based on that, I think it is a good idea to investigate the 
> approach Jan is proposing, avoiding registrations.

We are currently investigating this approach.  Initially, it seems like
this approach will require thorough discussion within the community,
prior to acceptance.  We will keep you posted as we flesh out the
details.

> I'm of course also open to new ideas...=)

Indeed, so am I :)  We are looking into this as well.

> /L-E
> 
> 
> >> Yes, each header compression scheme needs a channel state to be 
> >> negotiated, specific to that scheme. However, to use this generic 
> >> identifier, you need to add another level of negotiation 
> to negotiate 
> >> the meaning of "compressed header", so that these can be 
> delivered to 
> >> the correct decompression module. The packets with 
> compressed headers 
> >> will thus not be self-describing.
> > 
> > I don't see it as another level of negotiation, since you 
> can use the 
> > same mechanism that is negotiating the HC scheme specific 
> parameters.
> > You would just have to negotiate the HC scheme first, then based on 
> > that you can negotiate the appropriate HC scheme parameters.  I'm 
> > unclear
> on
> > why "another level of negotiation" would complicate things ?
> 
> Conceptually there is another level of negotiation, but it 
> might not be in implementation. As often is the case...
> 
> 
> >>> If ROHC is better than ECRTP from a technical point of 
> view, than by 
> >>> putting them on a level playing (as we are suggesting), I think 
> >>> vendors will easily be able to see that as well.
> >>> Are folks concerned that by supporting both ECRTP and 
> ROHC, vendors 
> >>> may only implement ECRTP? If not, then what are the concerns with 
> >>> supporting both HC schemes ?
> >> 
> >> Alternatives are bad for interoperability. Alternatives 
> are bad for 
> >> complexity. Multiple solutions means increased burden for 
> >> implementers. Let me cite Randy Bush:
> >> "The vendor/market approach has engendered a 'let the 
> market decide' 
> >> culture. Instead of hard-thought, rigorous designs, every possible 
> >> feature gets added and many competing proposals are approved. This 
> >> last is like throwing spaghetti at the wall to see what sticks, an 
> >> amusing tactic to everyone but the wall."
> > 
> > I see where you are coming for certain cases where there are many 
> > competing protocols.  However, in the HC case, we are only 
> trying to 
> > support 2 HC schemes, not 10 HC schemes.  I'm unclear on what the 
> > burden is to vendors, as they don't necessarily have to 
> implement both 
> > schemes?
> 
> Both sides need to support the same protocol, which means 
> alternatives either increases complexity of reduces to 
> chances for interoperability.

Once again, only 1 of 2 alternatives can be chosen, not a huge list to
choose from.  Therefore, to me it doesn't seem like a dramatic increase
in complexity.  Some additional reasoning as to why we want ECRTP
support in HCoIPsec, is because we feel that ECRTP is still a viable HC
scheme and that it isn't a "dead" protocol.  It was recently specified
in an RFC (i.e. ECRTP over MPLS), so there is interesting in using ECRTP
today.  In addition, ECRTP/CRTP is supported by two big vendors Cisco
and Juniper. 

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: [email-masked]
Date: Mon, 02 Oct 2006 23:17:45 +0200

Hi Rohan,

> the two HC schemes, by plugging ECRTP into ROHC.  This is still another

I am certainly opposed to the idea of "plugging" legacy hc schemes into RoHC, 
especially without having strong technical motivations and proper requirements 
to do so. My opinion is that solving HCoverIPSec for eCRTP is definitely not a 
motivation for this WG or for the IETF to work that particular solution. I 
also mentionned this earlier in a mail I previously wrote:

http://www1.ietf.org/mail-archive/web/rohc/current/msg04419.html
and also in a related thread:
http://www1.ietf.org/mail-archive/web/rohc/current/msg04435.html

Unless I have missed part of the discussion, for which then I'd appreciate you 
give me the right pointer to the mail archive, my understanding is that it is 
not exactly the case that the idea was supported in some form of consensus, as 
recent discussions on the RoHC wg mailing saw opposition to this idea, 
especially with respect to the recent charter update proposal.

I am also looking forward to hear more about the proposal not requiring 
registration.

Regards,

///Ghyslain