Alex,
Well aware of RSVP-TE. I believe MPLS to be different than intserv.
I also believe MPLS Labels could become moot in theory with the correct
use of the flowlabel and become what the label does for MPLS via the flow
label. Then I believe tunneling like RSVP-TE could be eliminated to
distribute the labels. I don't believe all of this will scale but we will
see soon once the economy upturns and broadband is recharged in the
market.
I would like to see tunnels, NAT, etc all go away. The flowlabel if used
correctly can contribute to that possibility.
We are at a stand still here. Its too bad. I guess I will have to
produce a draft supporting Brian's "b" and state the case and the
performance gain on the overall network.
I think RSVPv6 is a moot point there is not enough implementations to
worry about. But it was a good exercise in using the flow label instead
of the IPv4 transport+port fields and digging past the header to define
the flowspec and queue classification. Also it can be set for path msgs
using the v6 base API which gets past directly to the header. RSVPv6 and
the RSVP API (RAPI) peforms better with IPv6 because of the flowlabel and
by orders of magnitude from what we saw testing video and audio.
I suggest we do this real time at the next Sun Connectathon and show
RSVPv6 and take measurements.
RSVPv6 is useful to private enterprise Intranets as IPv6 inteserv tool
today. But not on across the Internet unless we mesh with diffserv.
As far as IPv6 being left behind IPv4 for routing metrics you predict.
As far as I am concerned who cares if its not E2E which is being totally
lost with IPv4 lack of address space. So I don't accept that argument.
IPv4 has no way of differentiating the header or the addresses except by
digging past the header. We have the opportunity to do that with IPv6
and fix that error in IPv6 today and not have to bother with all the
AND/OR Gates being built in fast path today. Its absurd to continue this
with IPv6 IMO.
regards,
/jim
On Mon, 20 Aug 2001, Alex Conta wrote:
> Jim,
>
> Please reexamine.
>
> As a hint, note that MPLS, which is using *mutable* labels, is using
> RSVP-TE (extension of RSVP
> for Traffic Engineering) as one of the label distribution mechanisms.
>
> Alex
>
>
> Jim Bound wrote:
> >
> > Yes I would as a note. I want what we orginally called for and to make
> > sure nothing breaks RSVPv6 which uses the flowlabel too.
> >
> > /jim
> >
> > On Fri, 17 Aug 2001, Tim Chown wrote:
> >
> > > On Fri, 17 Aug 2001, Francis Dupont wrote:
> > >
> > > > In your previous mail you wrote:
> > > >
> > > > I think the WG needs to decide once and for all whether the flow label is
> > > > a) a CATNIP or MPLS-like routing handle
> > > > or b) a QOS hint for intserv only
> > > > or c) a QOS hint for intserv and diffserv
> > > > or d) a waste of bits
> > > >
> > > > => I vote for b)
> > >
> > > So would you vote to mandate that the field is non-mutable in transit too?
> > >
> > > tim
> > >
> > > --------------------------------------------------------------------
> > > 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]
> > --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
