Subject: RE: Regarding the Options headers

From: "Thomas Eklund" <[email-masked]>
Date: Wed, 15 Nov 2000 17:32:15 +0100

Hi Francis,
see below.
> => I understand your concern but I have just replied to Robert Elz
> a MUST for the layout of extension header chain would be too strong
> then you must support any layout, including crazy/exotic.
>
>    This is no problem if you do it in a sw based router where
> you have all the
>    time in the world to parse your header
>
> => no, a software based router wants to be fast too and will
> just look at
> the destination address (me/them) and the next header type
> (zero/non-zero).

I was expecting that answer..:-)

>
>    but it becomes an issue when you implement IPv6 in asic!!
>
> => just don't do layer 4 classification in a router?
> Seriously I expect to avoid a IPv4-like situation where
> options are not
> used because they are processed slowly then not used then...

this is just to easy to say that. layer 4 classification will be used in the
campus backbone/high-end enterprise and with the current solution it is very
difficult to do it if you have any speed (we see 1GE links today and we will
see even 10 GE links very soon)  so it is an issue if we want ipv6 hot "hit"
in the enterprise networks and campus networks...

if we dont solve the problem that IPv4 routers do today we are on the wrong
path...

One might argue that why not use intserv and treat the flowlabel as a
intserv flow and let the router map several flow into traffic classes of
aggregated traffic (DSCP classes) but then it is up to the flow label to
decide and that is as we know undefined....

>
>    Have people thought about/What do people think about
> changing the length
>    field
>
> => which one? The IPv6 header length field *is* useful and there is no
> free space.

I meant the Payload Length.... This is the whole point... I think you missed
my point.
I wanted a chance to classify on the trnasport header without having to have
a loop that first look into the first "next header" and then looks into the
senocd extension header "next header" pointer and then look into the next
one and in the next one...

This require a loop to run which makes it "practically" impsossible to
implement in an asic (which is the only way to go if you want speed and a
future proven roadmap for higher bandwidth with Moores law) it will let you
implement this in a processor based approach and because you will have a
loop consuming your pipiline stages in you network processor you will have a
VERY difficult task to solve!! (Eventhough I'm in favour of something
between a NP and a dedicated ASIC)

If we had a chance to mask out the offset where the transport header where
immediataly (without the need for a loop) then we can mask out the remaining
length that is the new "payload + transport header" and add it to the new
"IP header length" (that consists of basic header + extension headers)...

And then it is very easy to classify on layer 4.

I think that this would be a big improvement for ipv6.

>
> => I think nothing good of this. It is not the job of a
> router to look at
> inside packets (ESP will save us!)

People that implement this in hardware see this problem TODAY...
And of course if the packet is encrypted with an ESP then it is no use to
classify on L4 but then we could have a flag in the flow label field that "
signalled inband" that we have no way to do this, than we could aggregate
this in the router and block any QoS related policy that included layer for
instance...
But in most cases there sits a firewall at the same place where we have the
edge router and then the traffic comes unencrypted to the router and we
might want to classify the traffic into a DSCP based on layer 4 info (As a
side note: I have spoken to several operators that do exactly this way today
for IPv4

>    And I would also like to define a mandatory limit on the
> length of the IP
>    header incl extension headers.
>
> => the maximum size of one extension header is 2048
> ((255+1)*8) octets,
> this is already far more than the minimal MTU (1280) then I
> expect nobody
> will get a consensus for that.
Which is not so good if there are any speeds in an edge router...

>
>    What do people think?
>
> => do the layer >= 4 classification at the edge and use DS
> byte, flow label,
> ... to mark packets. I believe this is the IntServ/DiffServ
> lesson: core
> routers should route <dot>

Of course I'm in favour of having the edge routers classify the packets.

But this was not the issue I raised here - I hope you understand what I
concerns?

-- thomas

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 16 Nov 2000 10:01:34 +0100

this is just to easy to say that. layer 4 classification will be used in the
   campus backbone/high-end enterprise and with the current solution it is very
   difficult to do it if you have any speed (we see 1GE links today and we will
   see even 10 GE links very soon)

=> today a standard box can't run at 1GE then I suppose your links are not
the host-router links but already campus backbone links. There are no good
definition of what is an edge router but it seems that the campus backbone
is too fast, ie. edge devices are between hosts and the backbone.

   so it is an issue if we want ipv6 hot "hit"
   in the enterprise networks and campus networks...
   
=> if an ASIC can do layer >= 4 classification at the host-router link speed
then this will work. Today hosts used in number crunching places are
cheap dual-CPU PC boxes in clusters (according to what I saw at CERN)
then it works. I don't believe we'll see again fast boxes with many
high speed buses (mainframes are history, minis are history, workstations
become history, ...) then the high-speed router camp should win.

=> I don't believe IPv6 has a real disavantage here, it is more a problem
of "IPv6 is not yet here then don't put man power on it". Packets in the
same flow are similar enough than the caching & hashing strategy works.

=> this is what to do for core routers. There is and will be no other
solutions because core routers need to be *fast*!   

=> I had the wish I missed it. You can't reuse the payload length because
it is *not* free. You propose to create a very different protocol with
a different (likely larger) header...

=> the extension header chain is in the base design of IPv6: you want
another protocol. BTW I'd like to know what is the transport header
in VPNs (which are more and more common).

=> QoS related policy that included layer >= 4 was proved as unfeasible
in RSVP trials. The issue was more the unscalable nature of signaling
than classification but in order to use QoS related policy you have to
solve the untracktable signaling problem first...

   But in most cases there sits a firewall at the same place where we have the
   edge router and then the traffic comes unencrypted to the router

=> stop here. Even if today IPsec is VPN we expect in the future to have
end-to-end IPsec.
But if you believe there is a firewall then the firewall has the same
problem (it wants to apply layer >= 4 filtering rules) then you can
mark (DSCP + flow label) packets at the same place: or I don't understand
your argument or we agree?

   and we
   
   >...

=> I believe the core routers are not able to classify the packets then
my position is a bit more than "in favour".

Regards

[email-masked]