Subject: RE: Flow label and its uses

From: "Bora Akyol" <[email-masked]>
Date: Wed, 18 Jan 2006 10:00:13 -0800

From a switching hardware perspective, it would be nice
to either define the use of this field as --endpoint only--
or label it "Reserved."

There has been significant time since RFC3697 and the lack
of applications may indicate that this field (with
the exception of NIMROD) may not have a use at all.

Regards

Bora

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Wednesday, January 18, 2006 5:03 AM
> To: Fred Baker
> Cc: Bora Akyol; [email-masked]
> Subject: Re: Flow label and its uses
> 
> Fred Baker wrote:
> > personally, I would label it reserved. I think the authors of RFC  
> > 3697 see it as something akin to a 20 bit DSCP, and if 
> someone wants  
> > to see it that way it's fine by me. In any event, that is 
> an ipv6wg  
> > question more than a v6ops question.
> 
> Indeed. And it isn't "reserved"; it *is* part of the header 
> with the semantics defined to the extent of RFC 3697. My 
> point is that people who want to use it, e.g. for load 
> balancing, ought to be writing drafts.
> 
>     Brian
> 
> > 
> > On Jan 17, 2006, at 3:50 PM, Bora Akyol wrote:
> > 
> >> A pointer to some reference material on NIMROD:
> >>
> >> http://ana-3.lcs.mit.edu/~jnc/nimrod/nimsl.html
> >>
> >> http://ana-3.lcs.mit.edu/~jnc/nimrod/docs.html
> >>
> >> http://www.ir.bbn.com/projects/nimrod
> >>
> >> Is there any use in keeping flow label as is, or should be 
> relabeled 
> >> as "Reserved"?
> >>
> >> I think there is some agreement that
> >> the label in
> >> (Label, IP Source Address, IP Destination Address) triplet 
> does not 
> >> add a whole lot of value.
> >>
> >> Regards,
> >>
> >> Bora
> >>
> >>
> >>> -----Original Message-----
> >>> From: Fred Baker [mailto:[email-masked]]
> >>> Sent: Tuesday, January 17, 2006 3:33 PM
> >>> To: Bora Akyol
> >>> Cc: Vishwas Manral; [email-masked]
> >>> Subject: Re: Flow label and its uses
> >>>
> >>> I'd encourage you to look at the big-internet archives (if they
> >>> exist) from about 1993. The flow label was proposed to 
> support the 
> >>> nimrod architecture, and in essence *was* what we later 
> described as 
> >>> "MPLS", but in the IPv6 header. That's one of the reasons 
> that the 
> >>> flow label isn't covered by the IPSEC checksum - so it could be 
> >>> managed appropriately at ingress and egress to the 
> various "flows" 
> >>> or "LSPs".
> >>>
> >>> Yes, there has been a lot of water under that bridge. Between 
> >>> requiring the flow label to pass unchanged and making the address 
> >>> fixed length and of the same construction as the IPv4 address, 
> >>> Nimrod became very difficult to implement in IPv6, and Noel still 
> >>> isn't very happy with the IPv6 community.
> >>>
> >>> On Jan 17, 2006, at 3:11 PM, Bora Akyol wrote:
> >>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Vishwas Manral [mailto:[email-masked]]
> >>>>
> >>>>
> >>>>> And a more recent draft
> >>>>> http://www.faqs.org/ftp/pub/internet-drafts/draft-chakravorty-
> >>>>> bcc-flowla
> >>>>> bel-00.txt
> >>>>
> >>>>
> >>>> This last one looks a lot like MPLS in IPv6 ;-)
> >>>>
> >>>> Bora
> >>>
> >>>
> >>>
> > 
> 
> 
>

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jan 2006 20:40:28 +0200 (EET)

Hi,

> the exception of NIMROD) may not have a use at all.

I've been watching this discussion with mild puzzlement.

There is (basically) nothing that the routers need to do with the flow 
label.  Whatever they might end up doing with it would likely mostly 
fall under the control plane, so it doesn't need to be put in the 
hardware.

So what's the problem?  Do you want to try to reuse the "basically 
unused 20 bits" for some local purposes?  That's not going to be 
allowed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Jan 2006 12:42:04 -0800

In the NIMROD scenario, the flow label identifies something akin to a  
virtual circuit; more properly, it identifies an aggregated route. A  
"map" (a bag of prefixes advertised by a network entity such as an  
ISP or an enterprise network) is connected to the network of  
reference by some route, and the flow label permits a high speed  
lookup, rather than looking up the prefix. It is very much like the  
MPLS label lookup done in MPLS routing. Sham's draft referenced  
earlier in the thread has a similar model.

RFC 3697 proposes that it be used for source classification of the  
traffic; the router is supposed to look up the flow label and use  
that in diffserv classification in a manner similar to the current  
use of the DSCP; the values an application could expect to find  
support for in the network would have to be installed in the path by  
some form of signaling or be well known in the network.

Either way, the forwarding implementation (whether software or  
firmware) is going to be looking up the flow label in the data path.  
Hence Bora's comment that it has to be aware of the flow label.

On Jan 18, 2006, at 10:40 AM, Pekka Savola wrote:

> There is (basically) nothing that the routers need to do with the  
> flow label.  Whatever they might end up doing with it would likely  
> mostly fall under the control plane, so it doesn't need to be put  
> in the hardware.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2006 15:22:40 +0100

> to either define the use of this field as --endpoint only--

I disagree pretty strongly. As defined now, this field *needs*
to be covered by hardware classifiers. It was to clarify that
point (which is ambiguous in RFC 2460) that the IPv6 WG
produced RFC 3697.
> the exception of NIMROD) may not have a use at all.

NIMROD is ancient history. I firmly believe the use cases
will come, once IPv6 is deployed to the extent that people
really care about load balancing etc.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Jan 2006 15:22:21 +0100

Pekka Savola wrote:
> fall under the control plane, so it doesn't need to be put in the hardware.

No, that's wrong if it gets used in line speed QOS classifiers. That's
what I'd expect in load balancing.

    Brian
> unused 20 bits" for some local purposes?  That's not going to be allowed.
>