Subject: RE: Flow Label consistency question

From: "Bound, Jim" <[email-masked]>
Date: Fri, 22 Apr 2005 06:09:13 -0400

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian E Carpenter
> Sent: Friday, April 22, 2005 5:38 AM
> To: Ran Liebermann
> Cc: [email-masked]
> 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
> > [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: David Malone <dwmalone=[email-masked]>
Date: Fri, 22 Apr 2005 11:46:49 +0100

On Fri, Apr 22, 2005 at 06:09:13AM -0400, Bound, Jim wrote:
> over the network per 3697.

I guess this means that if an ICMP error message is generated then
the chunk of the original packet quoted by the ICMP error should
reflect the e2e flow label?

Using the flow label to validate recieved ICMP error messages is
quite appealing in light of draft-gont-tcpm-icmp-attacks-03. It
could also be used for validating ICMP messages generated by UDP
packets, where sequence numbers are not available but a flow label
could be set.

	David.

---

From: Ran Liebermann <[email-masked]>
Date: Sun, 24 Apr 2005 18:55:27 +0300

Hello all,

> packets, where sequence numbers are not available but a flow label

This is an interesting security point, but it could mean some
proccessing overhead when not needed. For example in UDP DNS queries
draft-gont-tcpm-icmp-attacks-03 shouldn't have that much of an impact
since no session is established.

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.
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.

--
Ran.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Apr 2005 15:20:34 +0200

Ran Liebermann wrote:
...
> and enforce a zero label on all ingress traffic in order to allow

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.

> 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

---

From: Kit Plummer <[email-masked]>
Date: Mon, 25 Apr 2005 07:19:40 -0700

> zero on all ingress traffic from customers.

If this is the case, and I hope it is...wouldn't is simply make more  
sense for the SP to ignore the FL all together?  Therefore, if the FL  
were pertinent on the other end...

---

From: Ran Liebermann <[email-masked]>
Date: Mon, 25 Apr 2005 18:23:01 +0300

Hi Brian and all,

> why the 6LSA people wrote their recent draft.

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?

Other than that, using the label for 6LSAs would just spare the need
to encapsulate the packet with MPLS.

Regards,
--
Ran.

---

From: Steven Blake <[email-masked]>
Date: Mon, 25 Apr 2005 11:28:57 -0400

> former value of the original data). Can you think of an application

See shim6.

> to encapsulate the packet with MPLS.

How do you stack flow labels?

Regards,

// Steve

---

From: Kit Plummer <[email-masked]>
Date: Mon, 25 Apr 2005 08:37:26 -0700

> former value of the original data). Can you think of an application

Lower-level Flow(data) classification.  Think isolated (or not),  
military networks.

---

From: Ran Liebermann <[email-masked]>
Date: Mon, 25 Apr 2005 18:49:57 +0300

> How do you stack flow labels?

Ofcourse if you need multiple label stacks you'll have to either
encapsulate it by another IPv6 header (oversized for this reason) or
by a slimmer MPLS header.

Regards,
--
Ran.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 26 Apr 2005 14:32:34 -0700

Ran Liebermann wrote:
> restore the original value. 

The 6LSA BS is just that. People want an MPLS label without having to do the
work of building an MPLS network. Get over the thought that there is only
one policy entity on the path and realize that if some router mucks with the
FL then the next policy decision will be based on invalid bits. The Flow is
e2e, and the label that describes that flow is also e2e. 

> If it should be used for QoS the value

WTFO??? QoS is potentially important all the way up the stack. Just because
you don't see the value does not mean that a stack will not prioritize
packet handling after the packets are received.

> signalling be embedded in upper layers data?

Signalling is needed at every policy decision point along the path,
including the receiver. The DSCP is mutable and the FL is not. For
consistent policy decisions there has to be a set of bits that are exactly
as set at the origin.

> former value of the original data). Can you think of an application

Consider an app that has multiple data streams running over different ports.
A receiver might use those for bundling during stack processing. 

> to encapsulate the packet with MPLS.

MPLS is a localized function. IP is about traversing multiple
administrations and types of L2 media.  6LSA is nothing more than a way to
break an end to end architecture by trying to put localized L2 semantics in
the end to end header. Get over it. If you want local label semantics build
an MPLS network. For those that need end to end capabilities use IP and
don't mangle the headers. 

Tony