Hi Francis,
> > => 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...
What you are saying might be ONE way of doing it, but I have talked to
several ISP that use this today in the access - what do you say to them?
Invent a new protocol or something else?
Note in ipv4 you have a protocol field that could be used to determine the
offset in the packet for TCP and you dont have that option in ipv6. ok, most
of the info is parsed at the destination in destination options for ipv6 and
the whole idea is to only parse the basic header along the path. but there
are many scenarios where this is not enough and people want to have a chance
to classify on layer 4
> => today a standard box can't run at 1GE then I suppose your
My box do. And Apple's new computer is shipping with GE interfaces for
instance...
> 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.
If you look at figures from Garter Group, IDC, DellOro, you see a trend that
GE will enter the LAN market very fast... just like FE entered the market
fast when it come and people used the same cabling but upgraded from 10 Mb
to FE.
> 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...
Yes - with a chance to make a deterministic implementation of it in asic, np
etc...
>
> 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 know - and I'm not proposing any change of it! Simply a change of the
interpretation of the length field which would have many benefits when you
implement it in hw.
But once again - most of the ISP's I spoken to run vpn with mpls and build
there network in a very pragmatic way (mostly based on over provisioning)
and dont use esp for instance...
But if you would base your VPN on ipsec with both ah and esp then you
probably want to have the vpn endpoint as close to the CPE as possible
(where there is no speed) and then you will need a way of managing the vpn
further up in the backbone which would require some kind of tag (mpls, flow
label etc) and some might also want to do traffic engineering to improve the
availability of the vpn...
> > => I think nothing good of this. It is not the job of a
> > router to look at
> > inside packets (ESP will save us!)
This trend is driven from the operators and the router vendors ingrate more
and more into its boxes... You need to look into the packet at every edge
(backbone/WAN edge, MAN edge, LAN edge/access edge etc.) This is also a
natural way to go when you go up in speeds.
>
> 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.
Dont mix the RSVP/intserv based approach with layer 4 classification
possibilities in a full MF classifier...
> 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.
I'm a believer of the en-to-end model as well but that was NOT the issue
here.
> 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?
This would probably be one out many solutions... And as I said before since
this is not standardised today then the operators label their traffic with
802.1Q tag, mpls tag or something else just to achive this..
> => I believe the core routers are not able to classify the
> packets then
> my position is a bit more than "in favour".
I was not talking about core routers...
-- 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 PROTECTED]
--------------------------------------------------------------------
