Subject: RE: Higher level question about flow label

From: Thomas Eklund <[email-masked]>
Date: Mon, 20 Aug 2001 00:00:53 +0200

Dear Brian,
The intention is not to combine those at the same time the idea I support is
to let people have both and let the user decide.

Baically I see two different scenarios:
1) service provider, hop-by-hop semantic and wants the flowlabel to resemble
mpls flow label
2) enterprise, end-to-end (within the admin doman i.e. the enerprise) where
you probably would like a intserv model.

I dont see the need for defining a diffserv model since you have a diffserv
label today, but if there is many ISP that want more DSCP then I would
support it (eventhough the ISP Í talk is not looking for that in a near
future).
regards 
  Thomas

-----Original Message-----
From: Brian E Carpenter
To: Thomas Eklund
Cc: 'Francis Dupont '; 'ipng '
Sent: 2001-08-19 21:30
Subject: Re: Higher level question about flow label

Thomas,

How can you combine a routing handle usage with intserv usage?
These usages are totally disjoint. It's one or the other.

The historical fact (thanks to Frank Solensky for pointing this out in
private mail) is that we rejected the routing handle usage right at
the beginning of IPv6, even though some people disagreed and still
regret
it. But we also moved the language about the flow label to an appendix
in RFC 2460, which means that many implementors seem to have ignored it.
I believe it is time to clean up that ambiguity.

BTW it's the presence of an ESP header that tells you if the packet is
encrypted. I don't see any need for a bit.

   Brian

Thomas Eklund wrote:
> 
> I vote for a semantics where you have MPLS or intserv style semantics
and I
> would also like a bit telling if the packet is encrypted or not.
> 
> [email-masked]
> -PS: Intserv is not 100% dead because there is an environment
(wireless)
> -where to get more bandwidth is really expensive (in Europe at least
:-).
> -PPS: there is another usage: flow-based switching for fast routing
> -but I don't believe this really helps (petabit router vendors?)
> 
> --> No there is no need in term of a flow based switching fast routing
since
> the memory where you store the routing tables are so huge today. 512 K
IPv4
> prefixes could be stored in one CAM memory and usually you can use
several
> to obtain larger tables - all the CAM vendors support between 1 - 4 M
IPv4
> prefixes to be stored in their CAM and do one look up in a clock
cycle.
> 
> But many people are using flow to do traffic engneering and that's
where I
> belive the "mpls" op by hop semantic is needed. for the flow label. It
would
> also be easier to signal up to the routing protocls like IS-IS, OSPF.
BGP
> etc when a change occured.
> 
> -- thomas
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Jim Bound <[email-masked]>
Date: Sun, 19 Aug 2001 23:37:18 -0400 (EDT)

thomas,

the flowlabel with src global addr can be used by the CAM or SRAM for
CATNIP or MPLS lookup.

Why differentiate types of use?

With b the Intserv model one gets a is my belief?

thanks

/jim

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2001 15:06:58 -0500

Thomas,

The diffserv issue is that diffserv currently cannot properly classify packets
that are hidden by ESP headers. If it wasn't for that, I personally wouldn't
have gone near the flow label.

I believe that mixing the two types of semantics in one field is an
unacceptable complication that we should avoid on general engineering
principles. Even mixing two types of QOS semantics bothers me, but not
as much.

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Aug 2001 13:11:09 -0700 (PDT)

> have gone near the flow label.

   Huh? I thought that one of the requirements for ESP was to
   copy the DSCP to the outer header. If I recall correctly,
   this bothers some people from a traffic analysis standpoint,
   but that seems to be part and parcel with QoS so that doesn't
   hold much water IMO.

	     Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2001 16:26:28 -0500

The point is that when a packet crosses an administrative domain boundary,
the downstream ISP typically wants to reclassify the packet all over again, 
i.e. does not accept the incoming DSCP as definitive. This was a very
clearly stated ISP requirement at the start of diffserv and is fundamental
in the diffserv architecture.

  Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Aug 2001 13:32:50 -0700 (PDT)

> in the diffserv architecture.

    Right... I must be missing something. You copy the inner DSCP
    to the tunneled packet header, it traverses the network just like
    normal with whatever re-writing rules apply at the administrative
    edges, and once the packet is decapsulated, you copy the outer
    DSCP back into the inner and goes along its merry way.

    What am I missing?

	 Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2001 16:41:55 -0500

>     DSCP back into the inner and goes along its merry way.

The tunnel aspect is discussed in RFC 2983 in some detail. The problem I mention
is when the packet is inside a transport mode ESP header when it crosses
an ISP boundary, and the SLA in place requires reclassification (i.e.the 
downstream ISP has not contracted to honor the upstream ISP's DSCP
values). I think you're missing the distinction in diffserv between
BA and MF classifiers (see RFC 2474 and 2475).

  Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 21 Aug 2001 13:46:22 -0700 (PDT)

> in the diffserv architecture.

Oh. I now see what I missed. Why doesn't including
the SPI into the flow key work? You wouldn't be
able to police based on port numbers (ie try to be
a firewall), but some would say that's a feature
not a bug.

	Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 22 Aug 2001 14:45:47 -0500

> a firewall), but some would say that's a feature

That probably depends on your degree of paranoia about traffic analysis :-)

The SPI is certainly a possible way to identify a flow, but it doesn't help
you decide whether that flow needs real time or best effort service. 

   Brian

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 22 Aug 2001 17:05:38 -0400

>    but that seems to be part and parcel with QoS so that doesn't

It seems that it would be appropriate for an implementation to
"reclassify" packets at the time of encapsulation into ESP -- the
packet is, after all, going through a logical trust boundary as it's
being encrypted..

This reclassification could involve copying the inner DSCP into the
outer header, or it could involve painting all packets the same shade
of black to discourage traffic analysis, or running it through some
other mapping function.

						- Bill

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Aug 2001 14:22:03 -0700 (PDT)

> packet is, after all, going through a logical trust boundary as it's

   If I understand Brian's concern correctly, that may
   not necessarily be the case. The security gateway may
   be on egress from my network and hence controlled by me.
   If the service provider wants to reclassify those packets,
   it would need to be done at the next hop router from the
   security gateway (ie on a router they controlled).

   I'm still not sure I understand the policing they are
   trying to accomplish though; it seems sort of weird
   to have port level classification on the other side of the
   trust boundary to set the proper DSCP, unless it's just
   provide a service that could (should?) have been done at
   your egress router. Otherwise it seems like
   the user would be shooting themselves in the foot since
   the normal method is for the policer to police to a 
   certain SLA on a given aggregate traffic class. This
   to my mind would argue for the classification to be
   done on *before* it is encapsulated with ESP, but the
   policing done on the aggregate where it doesn't care
   about the port data.

   Ie:

   luserdata------------>SG---------------------->AR
                     (classifies,              (polices
		      remarks dscp,		SLA against
		      encrypts)			DSCP, remarks)

		      Mike

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 22 Aug 2001 17:08:41 -0400

> a firewall), but some would say that's a feature

Well, except that there's no such thing as a "well known SPI"..

When done correctly, SPI's are random and short lived, with semantics
only visible to the SA endpoints, so they just turn into a slightly
less useful form of pseudorandom flow label (since multiple "flows"
may share an SA, and the SPI's change over time as the SA's time out
and are rekeyed).

				- Bill

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 22 Aug 2001 17:35:00 -0400

>    be on egress from my network and hence controlled by me.
...

> 		      remarks dscp,		SLA against

No, there are two trust boundaries in the above network; the
subscriber's is inside SG, and the provider's is inside AR...

					- Bill

---

From: Michael Thomas <[email-masked]>
Date: Wed, 22 Aug 2001 14:42:51 -0700 (PDT)

> subscriber's is inside SG, and the provider's is inside AR...

   Correct, however I'm not sure why that's pertinent
   to what I wrote. I'm trying to understand why this
   setup is deficient.

	    Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Aug 2001 11:45:13 -0500

The issue is that if the packet is classified prior to being
encrypted, what do you do if a downstream ISP declines to
believe the classification (DCSP value) and wishes to reclassify
the packet? The proposal is to put enough semantics in the flow
label to allow some degree of classification.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Sat, 25 Aug 2001 11:48:18 -0700 (PDT)

> label to allow some degree of classification.

   I'm sorry, but this sounds like you're approaching the
   problem backward. If you want transport friendliness so
   that you can reclassify packets, you should beat up on 
   the Ipsec WG to revive the transport friendly ESP as
   working group item. Trying to jam the relevant transport
   header into a 20 bit field sounds like a *way* losing
   proposition which has a zero percent possibility of being
   future proof. It's bad enough that we have these middle
   boxes trying to look at L4+ headers, but trying to 
   *replicate* data into an obviously too small field for
   every unknown and uninvented protocol going forward...
   ick.

	Mike

---

From: Alex Conta <[email-masked]>
Date: Mon, 27 Aug 2001 09:17:36 -0400

>    every unknown and uninvented protocol going forward...

The problem is simple, in spite of all the twists and spins. 

You need to identify flows, and for that you use some fields in the
network header and/or host-to-host header. Reviving the transport
friendly ESP would do only partial good, since the problem of
walking though all the extension headers remains.

And thus, the validity of the request to have the flow label available
for all IP QoS, including Diffserv, remains.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Aug 2001 10:39:29 -0500

For sure you can't squeeze all the bits into 20, which is why
we went for the PHB ID option where no squeezing is required.

As for beating up on IPSEC... that would take a bigger guy than me :-)

   Brian