Subject: draft-nordmark-multi6-sim-00.txt

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Sun, 26 Oct 2003 00:36:50 +0200

Erik,

Regarding your draft draft-nordmark-multi6-sim-00.txt, I'm interested to know if you are considered the implications of using the
next header field ?. Let me explain.

When we met several times in the Atlanta IETF for the "multi6 rebel's WG", one of the solutions that we have been discussing was the
one from Marcelo.

The main inconvenient was the lack of support from the vendors to any option that means using next headers to support multi6
solutions.

In fact I believe you were on a couple of the 7-8 meetings that we had, right ?

This question is not only for you, but also for the router manufacturers that have already implemented IPv6 support in hardware
(most of them actually !). I'm sure they are on this mailing list ...

I understand that this can be implemented in software, as most probably, most of the multihoming applications will not be
"performance critical" to create a constrain with the current generations of IPv6 hardware implementations. In fact this is a
general problem for the usage of next header in the case of routers ... but this is probably a discussion to be done in the IPv6 WG.

This question is somehow valid also for the draft-nordmark-multi6-noid-00.txt.

Regards,
Jordi

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 26 Oct 2003 17:06:54 +0100

On 26 okt 2003, at 0:36, JORDI PALET MARTINEZ wrote:

> Regarding your draft draft-nordmark-multi6-sim-00.txt, I'm interested 
> to know if you are considered the implications of using the

[doing special header processing is expensive in routers with hardware 
IPv6 support]

Yes, this is a good point. I like the idea of using the 6 bit diffserv 
field for this. This field is modifyable in transit and doesn't impact 
any processing at the receiving end or in routers that don't support 
diffserv or type of service processing.

There is a slight disadvantage that this field is only 6 bits, but I 
don't think it's necessary to populate all possible combinations of 
service levels and yes/no on the rewriting, so in practice this 
shouldn't have to be a huge problem.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Oct 2003 00:28:01 +0100 (CET)

> When we met several times in the Atlanta IETF for the "multi6 rebel's WG",
> one of the solutions that we have been discussing was the one from Marcelo.
> 
> The main inconvenient was the lack of support from the vendors to any option
> that means using next headers to support multi6 solutions.
> 

I don't recall such a discussion so I might not have been in the room.

Was the concern based on the routers doing packet classification (based
on e.g. port numbers), or something else?

  Erik

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 27 Oct 2003 00:48:00 +0100

Hi Erik,

Yes, I'm sure you participated, but may be not in the complete meeting.

The concern was regarding the hardware already in the factory, which took a long time to be designed, not considering extension
headers, so if we use them, it should be a firmware process, instead of hardware based, with the consequent lower performance.

Regards,
Jordi

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Oct 2003 10:37:55 +0100 (CET)

> The concern was regarding the hardware already in the factory, which took a
> long time to be designed, not considering extension headers, so if we use
> them, it should be a firmware process, instead of hardware based, with the
> consequent lower performance.

Yes, but routers don't look at any extension headers (except the hop-by-hop
header) in the forwarding path.

Thus the only issues I can think of here is the desire to do
QoS classification or (firewall) filtering on ULP header fields.
I don't know what classes of routers support such things at wire-speed
today.
Are there other issues?

  Erik

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Mon, 27 Oct 2003 10:55:07 +0100

I need to read the document again then ...

I understood that the routers rewrite but the information is in the extension header ...

Anyway, its a question that probably requires the answers from the router manufacturers, to see if this is viable.

Regards,
Jordi

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 27 Oct 2003 12:50:55 +0100 (CET)

> I understood that the routers rewrite but the information is in the

The information that is it ok to rewrite the locators is
in the IPv6 nextheader field - a designated value should be allocated
for the M6 protocol in SIM to have this semantics (in addition
to indentifying to the endnode that the this is a multihoming
packet) . The information that gets rewritten
is the IPv6 source field.

Thus there is no need to parse additional extension headers to do the
rewriting. If hop-by-hop options are used the HBH header would 
need to be looked at to see whether its nextheader value says "rewrite ok".
Presumably a routing header could also be placed before the M6 header
thus the nextheader field in the routing header would need to be inspected.

But other extension headers (destination options, ESP, AH, fragment)
are placed after the M6 header.

FWIW NOID and CB64 take the same approach except that in order to
avoid a shim M6 header in every packet the router need to
look for a nextheader value in a range of 8 values to mean "rewrite ok".

  Erik

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Oct 2003 18:21:27 +0100

Er, the diffserv field isn't available for that... we use it
for diffserv...

And I wish people would think about routers that will be shipped ten or fifty
years from now. If the solution is sub-optimal for today's hardware, that
should not in itself be a show-stopper.

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Oct 2003 22:30:43 +0100

> Er, the diffserv field isn't available for that... we use it

Using diffserv for signalling whether rewriting is allowed doesn't get 
too much in the way of regular diffserv use. (Hm, didn't we have a very 
similar discussion just recently?)

Worst case, twice the number of code points would be needed: one for 
service level x without rewriting and one for service level x with 
rewriting, one for service level y without rewriting... Best case, only 
a single DSCP would be used up: default without rewriting, in addition 
to default with rewriting and all other service levels with rewriting.

> should not in itself be a show-stopper.

Interesting point. I sort of agree. I don't think it applies here, 
though. Using the diffserv bits is the most logical and cleanest choice 
if we can make it work, and I believe we can.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Oct 2003 10:41:40 +0100

> similar discussion just recently?)

I think it does. There are moves afoot to define recommended service
classes and recommended DSCP mappings (for example 
draft-baker-diffserv-basic-classes-**.txt) and overloading these bits within
a mere 6 bit code space seems to me to be one bridge too far. I'd much rather
look at using two different flow labels, where we have a much larger code
space and no suggestion of pre-existing semantics.

> if we can make it work, and I believe we can.

My point is that even if people think it is slow to look at an extra header
today, this is probably irrelevant in the long term. 

   Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 30 Oct 2003 12:34:24 +0100

On 30 okt 2003, at 10:41, Brian E Carpenter wrote:

>> too much in the way of regular diffserv use.

> draft-baker-diffserv-basic-classes-**.txt)

Why???

I'm continously amazed by what the IETF does and does not find useful 
work.

> and overloading these bits within
> a mere 6 bit code space seems to me to be one bridge too far.

Maybe we should hear from people who are using diffserv operationally.

> I'd much rather

Except that you're not supposed to change the flow label for a packet / 
session, and the fact that many existing hosts come up with random flow 
labels so it's impossible to set aside values.

>>> And I wish people would think about routers that will be shipped ten
>>> or fifty years from now. If the solution is sub-optimal for today's 
>>> hardware, that should not in itself be a show-stopper.

> today, this is probably irrelevant in the long term.

And my point was that using the diffserv field is the logical choice, 
irrespective of the performance of other candidates. So the question is 
whether there is a reason that invalidates overloading diffserv. This 
is where we disagree.

However, the meta-question is whether we can come up with something 
that can ALWAYS work, or if we have to create several alternatives that 
cater to different needs. I think using the next header field isn't 
going to to be popular with the firewall crowd. DSCP and flow label may 
have similar problems.