thomas,
the flowlabel with src global addr can be used by the CAM or SRAM for
CATNIP or MPLS lookup.
Why differentiate types of use?
With b the Intserv model one gets a is my belief?
thanks
/jim
On Mon, 20 Aug 2001, 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
