I'm usually just a listener on this group, but I have to put in my 2 cents
here.
I am a consultant designing the network for a new "campus in a high rise"
for a major financial institution.
1) Mainframes and minis are NOT dead. Talk to anyone at IBM, Sun, or HP,
or other high-end
server manufacturers. These boxes TODAY have Gig-E interfaces and can
consume a
significant fraction (and not just brief bursts).
2) Even the edges are getting faster. User workstations all have 100bT
Fdx interfaces.
Streaming video is a requirement. Uplinks from my edge switches are
Gig-E.
3) Latency is a serious issue. Users currently have 3ms or better
round-trip latency to every
server in the company. They will not tolerate a reduction in this SLA,
rather it must improve
with each new generation of hardware.
4) Need I say it ... Moore's law is NOT dead. Expect all feeds and speeds
to continue to go up and up...
Therefore, IPv6 MUST be implemented in hardware, and MUST forward at line
rates
(ALL future line rates!) with layer 4 QoS, ACLs, and all the other goodies
that we dream up at the same time.
Or else!
Or else it will stay a research toy and not fulfill its destiny of
replacing IPv4 in the Real Internet.
So there's the challenge. Find some way to, as Jean-Luc Picard would say,
"make it so".
Have fun guys! :-)
John Burgess
Principal Consultant
Predictive Systems, Inc.
Francis Dupont <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
11/16/00 04:01 AM
To: [EMAIL PROTECTED]
cc: "'Steve Deering'" <[EMAIL PROTECTED]>, "'Brian Zill'"
<[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Regarding the Options headers
In your previous mail you wrote:
> 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)
=> 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.
if we dont solve the problem that IPv4 routers do today we are on the
wrong
path...
=> 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.
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....
=> this is what to do for core routers. There is and will be no other
solutions because core routers need to be *fast*!
> 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 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...
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...
=> 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).
> => 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...
=> 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
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
>...
Of course I'm in favour of having the edge routers classify the
packets.
=> I believe the core routers are not able to classify the packets then
my position is a bit more than "in favour".
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
