Thomas,
The diffserv issue is that diffserv currently cannot properly classify packets
that are hidden by ESP headers. If it wasn't for that, I personally wouldn't
have gone near the flow label.
I believe that mixing the two types of semantics in one field is an
unacceptable complication that we should avoid on general engineering
principles. Even mixing two types of QOS semantics bothers me, but not
as much.
Brian
Thomas Eklund wrote:
>
> Dear Brian,
> The intention is not to combine those at the same time the idea I support is
> to let people have both and let the user decide.
>
> Baically I see two different scenarios:
> 1) service provider, hop-by-hop semantic and wants the flowlabel to resemble
> mpls flow label
> 2) enterprise, end-to-end (within the admin doman i.e. the enerprise) where
> you probably would like a intserv model.
>
> I dont see the need for defining a diffserv model since you have a diffserv
> label today, but if there is many ISP that want more DSCP then I would
> support it (eventhough the ISP � talk is not looking for that in a near
> future).
> regards
> Thomas
>
> -----Original Message-----
> From: Brian E Carpenter
> To: Thomas Eklund
> Cc: 'Francis Dupont '; 'ipng '
> Sent: 2001-08-19 21:30
> Subject: Re: Higher level question about flow label
>
> Thomas,
>
> How can you combine a routing handle usage with intserv usage?
> These usages are totally disjoint. It's one or the other.
>
> The historical fact (thanks to Frank Solensky for pointing this out in
> private mail) is that we rejected the routing handle usage right at
> the beginning of IPv6, even though some people disagreed and still
> regret
> it. But we also moved the language about the flow label to an appendix
> in RFC 2460, which means that many implementors seem to have ignored it.
> I believe it is time to clean up that ambiguity.
>
> BTW it's the presence of an ESP header that tells you if the packet is
> encrypted. I don't see any need for a bit.
>
> Brian
>
> Thomas Eklund wrote:
> >
> > I vote for a semantics where you have MPLS or intserv style semantics
> and I
> > would also like a bit telling if the packet is encrypted or not.
> >
> > [EMAIL PROTECTED]
> > -PS: Intserv is not 100% dead because there is an environment
> (wireless)
> > -where to get more bandwidth is really expensive (in Europe at least
> :-).
> > -PPS: there is another usage: flow-based switching for fast routing
> > -but I don't believe this really helps (petabit router vendors?)
> >
> > --> No there is no need in term of a flow based switching fast routing
> since
> > the memory where you store the routing tables are so huge today. 512 K
> IPv4
> > prefixes could be stored in one CAM memory and usually you can use
> several
> > to obtain larger tables - all the CAM vendors support between 1 - 4 M
> IPv4
> > prefixes to be stored in their CAM and do one look up in a clock
> cycle.
> >
> > But many people are using flow to do traffic engneering and that's
> where I
> > belive the "mpls" op by hop semantic is needed. for the flow label. It
> would
> > also be easier to signal up to the routing protocls like IS-IS, OSPF.
> BGP
> > etc when a change occured.
> >
> > -- 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]
--------------------------------------------------------------------
