Hi Jim,
Of course it can, a CAM is programmable and that's not he problem, in fact
the current with the current CAM you could do a 576 bit wide lookup if you
are smart (and those bits does not need to be consecutive in the packet) in
OC-192 which is sufficient for IPv6 multicast.
It can but I dont belive in a model where the intserv bits will be carried
end-to-end (over some transit provider) and can be trusted on the other end.
I would put my two cents on the model where the intserv flow label only is
going to be used within the enterprise or within an administrative domain
(like an Radio Access Network in 3G)
What I also think that b will be a good model where for instance you could
signal the flow end to end over a VPN.
The a model could really benfit when it comes to native TE for IPv6. You
also really simplify the mpls model and get a the same approach for IPv6
where you could do TE over your IPv6 flows. That mean that you would make
IPv6 "link-layer ware". I see many benefits of such an approach besides the
obvius one the intserv which I also support.
-- thomas
>-----Original Message-----
>From: Jim Bound [mailto:[EMAIL PROTECTED]]
>Sent: den 20 augusti 2001 05:37
>To: Thomas Eklund
>Cc: 'Brian E Carpenter '; ''Francis Dupont ' '; ''ipng ' '
>Subject: RE: Higher level question about flow label
>
>
>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]
--------------------------------------------------------------------
