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]
--------------------------------------------------------------------
