Subject: Re: Higher level question about flow label

From: Alex Conta <[email-masked]>
Date: Tue, 04 Sep 2001 13:13:38 -0400

Francis,

Your idea has value. Unfortunately, it poses the same type of problem
for IPv6 fast processing as the 5-tuple classification, which makes it a
non-acceptable alternative to the flow label (field in the main header). 

Regards,
Alex

Francis Dupont wrote:
> 
>  In your previous mail you wrote:
> 
>    Unfortunately I think the extension header mechanism is probably
>    too heavy as Francis says, but I want to think a bit longer about
>    that (and re-read kre's last message and some of Jarno's messages).
> 
> => this is heavy but we can do more with this than with 20 bits,
> in fact we can do more with this than with protocol/ports (*)...
> The basic idea is to make (still unknown) avantages greater than
> (already known) drawbacks.
> 
> Regards
> 
> [email-masked]
> 
> (*) I have two different kinds of ideas about this:
>  - first I don't fully understand what ISPs will do with protocol/ports
>    because SLAs are not signaling: rules will be very coarse like
>    "remark TCP port 80 to lower than best effort"... Perhaps protocol/ports
>    are not designed for classification (:-). Of course, to pack them into
>    20 bits (or less!) won't make these field more useful!
>  - if we use available bits with a better semantics both we need less
>    (even less than 20 bits because we deal with macro flows in Diffserv
>    but look at the last point) and we can do more with them, for instance
>    code a stack of DSCPs (a good solution for the rewrite/restore issue).
>  - a destination option (in a header just after the IPv6 header or
>    the hop-by-hop/please-use-the-slow-path header) provides a lot of bits
>    and is expandable, in fact it can (i.e. should) be expandable on the
>    fly: a stack of annotations for classification? MTU is not a real issue
>    because backbones have already larger MTUs than edge networks for
>    other reasons, the last edge router just needs to cleanup the stack.
> --------------------------------------------------------------------
> 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-masked]
> --------------------------------------------------------------------