Subject: RE: Flow Label consistency question

From: "Bound, Jim" <[email-masked]>
Date: Sat, 14 May 2005 12:27:34 -0400

Please read the drafts it is restored. WOW.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Monday, April 25, 2005 9:21 AM
> To: Ran Liebermann
> Cc: [email-masked]
> Subject: Re: Flow Label consistency question
> 
> Ran Liebermann wrote:
> ...
> > I still see much more benefit in using the Flow Label for 6SLAs.
> > If this indeed will be a common use for the Flow Label then 
> we should
> > take into consideration that probably many (if not most) service
> > providers will not allow their customers to set the Flow Label field
> > and enforce a zero label on all ingress traffic in order to allow
> > 6SLAs to work properly.
> 
> Until 6LSA explains how it will restore the label to its
> original value, or the IETF changes its mind about immutability
> of the label, this just isn't going to happen. I think that's
> why the 6LSA people wrote their recent draft.
> 
> > Ofcourse if the label will also be used to classify traffic for
> > diffserv then this is one more reason for SPs to override 
> the label to
> > zero on all ingress traffic from customers.
> 
> Quite the opposite. In a diffserv model, the value of the label
> set by the source will be *input* to a diffserv domain boundary's
> diffserv classifier, just like the protocol number or port numbers.
> That's one of the use cases in which immutability of the label
> is a vital property.
> 
>    Brian
> 
> > Ran.
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email-masked]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 

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

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 14 May 2005 12:29:29 -0400

The flow label must be kept e2e is my interpretation.  Also I don't
believe routers or SPs should be resetting Traffic Class and that may be
a bug if this is not the case.
/jim 

> Behalf Of Kit Plummer
> Sent: Monday, April 25, 2005 11:37 AM
> To: Ran Liebermann
> Cc: Brian E Carpenter; [email-masked]
> On Apr 25, 2005, at 8:23 AM, Ran Liebermann wrote:
> 
> > Hi Brian and all,
> >
> > On 25/04/05, Brian E Carpenter wrote:
> >
> > On this you're right. Unless a new standard will obsolete 
> RFC 3697 the
> > label has to be restored to the original value.
> > But this is exactly the point - there is no apparent necessity to
> > restore the original value. If it should be used for QoS the value
> > should only mean something to nodes on the path of the flow, because
> > after it reaches it's destination then QoS is not important anymore
> > (but anyhow we have the Traffic Class byte for that). If it 
> should be
> > used for LSAs/TE the value shouldn't matter to the final destination
> > again but only to nodes in the flow's path. If it should be used for
> > some sort of a signalling to the destination - why shouldn't this
> > signalling be embedded in upper layers data?
> >
> > The only reason for the value of be kept e2e is if this value should
> > signal something to routers in the path of the flow (the reason why
> > not including the value in upper layers) and still be used by the
> > destination for something (for example - so that the 
> destination would
> > know what value the source put in there in order to insert 
> a new value
> > for returning traffic which has a meaning that's derived from the
> > former value of the original data). Can you think of an application
> > for that?
> 
> Lower-level Flow(data) classification.  Think isolated (or not),  
> military networks.
> 
>