For sure you can't squeeze all the bits into 20, which is why
we went for the PHB ID option where no squeezing is required.
As for beating up on IPSEC... that would take a bigger guy than me :-)
Brian
Alex Conta wrote:
>
> Michael Thomas wrote:
> >
> > Brian E Carpenter writes:
> > > The issue is that if the packet is classified prior to being
> > > encrypted, what do you do if a downstream ISP declines to
> > > believe the classification (DCSP value) and wishes to reclassify
> > > the packet? The proposal is to put enough semantics in the flow
> > > label to allow some degree of classification.
> >
> > I'm sorry, but this sounds like you're approaching the
> > problem backward. If you want transport friendliness so
> > that you can reclassify packets, you should beat up on
> > the Ipsec WG to revive the transport friendly ESP as
> > working group item. Trying to jam the relevant transport
> > header into a 20 bit field sounds like a *way* losing
> > proposition which has a zero percent possibility of being
> > future proof. It's bad enough that we have these middle
> > boxes trying to look at L4+ headers, but trying to
> > *replicate* data into an obviously too small field for
> > every unknown and uninvented protocol going forward...
> > ick.
> >
>
> The problem is simple, in spite of all the twists and spins.
>
> You need to identify flows, and for that you use some fields in the
> network header and/or host-to-host header. Reviving the transport
> friendly ESP would do only partial good, since the problem of
> walking though all the extension headers remains.
>
> And thus, the validity of the request to have the flow label available
> for all IP QoS, including Diffserv, remains.
>
> Alex
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
