RE: Flow Label consistency question

["Bound, Jim" <[e-mail]>]

The flowlabel must be restored end-to-end, but can be mutable in route
over the network per 3697.  See current 6LSA submissions now we are
determining where to work on this within the IETF currently, as one
example. Prototype implementation has been done and effort is underway
to determine how to begin test and beat on this via Moonv6
www.moonv6.org and other networks.  Should have URL of presentation Sham
Chakravorty did at combined meeting event between ARIN www.arin.net and
NAv6TF www.nav6tf.org this week www.arin.net/ARIN-XV, which is done well
and presents how the flowlabel is used in 6LSA.

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chakravorty-6lsa
-01.txt

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chakravorty-bcc-
flowlabel-00.txt

ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-chakravorty-bcc-
fec-00.txt

/jim



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Brian E Carpenter
> Sent: Friday, April 22, 2005 5:38 AM
> To: Ran Liebermann
> Cc: [e-mail]
> Subject: Re: Flow Label consistency question
> 
> Ran,
> 
> You probably need to go through the mail archive and meeting minutes
> from the period when RFC 3697 was being developed to find all the
> arguments. That was most of 2002 and 2003. But I think the simplest
> form of the argument is that it is intended to allow rapid
> classification of a packet as belonging to a specific e2e flow,
> regardless of where that classification happens - and the only way
> to do that is an e2e label. If you allow mutability of the label,
> you break that property. If you want a mutable local field for
> QoS, use diffserv. If you want a mutable local field for switching,
> use MPLS.
> 
> It is true (see my comments on draft-chakravorty-bcc-flowlabel-00.txt)
> that this property allows certain use cases and makes life diffcult
> for others. But the converse would also be true.
> 
>     Brian
> 
> Ran Liebermann wrote:
> > Hi,
> > 
> > I've been reading a few drafts and RFCs in this matter and 
> I couldn't
> > find an explanation why the Flow Label field has to read the
> > destination with the same value the source sent it.
> > 
> > Wouldn't it introduce a whole lot of new capabilities 
> (without as many
> > limitations) if the Flow Label field had only local significance?
> > 
> > I've read drafts that describe local significance uses for the Flow
> > Label field, but still they state that the destination has 
> to receive
> > this field as it was sent by the source. This ofcourse, if 
> we plan to
> > change this field hop-by-hop, requires some sort of synchronization
> > between the first-hop-router after the source and penultimate router
> > before the packet reaches it's destination.
> > 
> > I'd appreaciate if someone can explain this matter a little bit.
> > 
> > Thanks,
> > --
> > Ran.
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------