Subject: Re: Regarding the Options headers

From: [email-masked]
Date: Fri, 17 Nov 2000 06:59:03 -0500

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-masked]>
Sent by: [email-masked]
11/16/00 04:01 AM

        To:     [email-masked]
        cc:     "'Steve Deering'" <[email-masked]>, "'Brian Zill'" 
<[email-masked]>, [email-masked]
        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-masked]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------

--------------------------------------------------------------------
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: Ignatios Souvatzis <[email-masked]>
Date: Fri, 17 Nov 2000 13:31:33 +0100

> that we dream up at the same time.

I'm wondering:

- Are you also saying that end-to-end ESP must be made a MUST NOT? (in which
  case you are complaining much too late, I think).

While I'm convinced that the Power Router Vendors Out There will implement 
option header chasing for filtering purposes as soon as they think they can
sell it, getting at Level 4 on encrypted traffic is simply impossible. Well,
we should hope so.

Regards,
	-is