Suresh Krishnan <suresh.krish...@ericsson.com> wrote: > On 11-02-04 01:05 PM, Thomas Narten wrote: > >> Right off, I don't have enough understanding of what kind of >> architecture conex envisions to have any useful thoughts, but if you >> are thinking of using HBH options, the effort is certainly faces >> significant challenges.
I don't believe anyone on the ConEx list _likes_ the idea of using hop-by-hop options -- it's just hard to grok the alternatives. >> But rather than saying "don't use HBH" I'll suggest that you make the >> case for why HBH is the least worse way of designing conex. IMHO, that's a null case. ;^) >> Understanding that use of HBH for anything implies serious >> questions about whether anyone will actually implement/deploy it. We don't even rise to the level of discussing implementation in routers. > Fully agree with you. Hop-by-hop options are not really suitable for > conex at all, just like you said. Before the last IETF, we went through > the alternatives for performing conex markings on IPv6 datagrams. These > were the requirements we were working with > > R1: The information needs to be visible to all interested nodes on the > path. > R2: The information needs to be able to traverse nodes that do not > understand the markings. > R3: The presence of the marking mechanism should not significantly alter > the processing of the packet. That's pretty much where we stand. Hop-by-hop is pretty-much ruled out. Destination-Options is _so_ confusing that we hestitate to mention it. To add to the confusion, our primary algorithm talks of piggy-backing on the ECN bits, and the most serious proposal so far (developed for IPv4-land) talks of sort-of-redefining one of the four values of ECN to show what I'll call "congestion-predicted" and adding one additional bit to make sure all cases are covered. (I don't think it would help at this stage to go into more detail of that proposal: there clearly are other ways we could cover-the-cases, and actually it's premature to say we wouldn't want more than one-bit precision on "congestion-predicted" -- however that proposal _does_ seem adequate for useful experiments. We are, after all, chartered to produce an Experimental spec.) > There were no real suitable mechanisms for IPv6 that met these > requirements other than using some free bits in the header. We would > greatly appreciate any hints you can provide us in this regard. It's early enough in the ConEx process that we're open to some quite fundamentally different approaches. For example, we have discussed how to expose congestion (along the path, at the IP layer) in cases where ECN isn't deployed. We're exploring the possible -- and not really expecting to like what we find. ;^) -- John Leslie <j...@jlc.net> -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------