Subject: Re: AW: Usage of IPv6 flow label

From: Jim Bound <[email-masked]>
Date: Fri, 01 Dec 2000 11:47:16 -0500

i think the first battleground for ipv6 and the wg is what problem are
we trying to solve and the different agendas/paradigms folks are
wanting.

Right now I see 3 camps 

me/itojun/jochen - e2e flowlabel initiated by the client/api

brian/others - I want layer 4 information in the flowlabel

alex/other - integrate mpls labels and some of brian above

no one is ahead, none are cast in stone, no one has anything over the
other...or more influence as to what the IETF consensus will be....

hmmm let the games begin but no one should think they are winning this
and I think we need to hear from real customers and users too.

/jim
--------------------------------------------------------------------
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: "Thomas Eklund" <[email-masked]>
Date: Mon, 4 Dec 2000 20:46:28 +0100

Hi Francis,
I actually agree with you on the semantics of a SPI.

>    The SPI doesn't have the semantics.
> 
> => I disagree, the SPI has the semantics we'd like to give to it.
> 
>    A QOS classifier needs to *know*
>    the port and protocol numbers; that's how it takes its decisions.
> 
> PS: I am in no camp. I believe Jim/Itojun/... are right but the
> flow label is not protected by AH then a router may rewrite it.
> As it is not a stack it should be rewritten only closed to the source
> (ie. if you want to rewrite it anywhere you should encapsulate packets
> before, the decapsulation will restore the original flow label).
> In the future I can see two cases:
>  - the flow label is set by the source (first camp)
>  - the flow label is set by an edge router (with the DiffServ 
> definition
>    of what is an edge router) because the source box (or its user) is
>    too dumb to deal with QoS/..., according to the edge 
> router manager.
> I think we'll get a mixed situation.

Which Is what I support too.

-- thomas

---

From: "Thomas Eklund" <[email-masked]>
Date: Mon, 4 Dec 2000 21:21:25 +0100

Hi steve,

> > - the flow label is set by an edge router (with the
> DiffServ definition
> If the Flow Label is set by something other than the source node, how
> do you guarantee its uniqueness, over the topological scope in which
> it must be unique?  Do you need to invent a protocol between
> the routers
> on a LAN to divvy up the Flow label space?

It could be set as the MPLS protocol sets its traffic flows and distributed
to how MPLS distributes its flow info in its domain (RSVP-TE, LDP). This was
what I have had in mind.

And you would utilize the flow label inside the ip header and get rid of the
intemediate L2.5 protocol (MPLS).

The intention was of course to map the traffic onto a LSP in the edge router
inside your domain..

This could be done i a label stacked approach to which we will need the
dest. option Jim was talking about. The host sets the flow label for the
session as propose by Itojun and Jochen's approach. Into the backbone/core
of your network we might want to do traffic engineering and to use the flow
label for that purpose. And if we have one bit telling that the flow label
should be distributed to the other end, we need a dest option for the
original flow (which had a semantic in the access) that needs to be swapped
back at the egress of your domain. Then we have the "new" flow label in the
core that we do TE on.

> What happens when the LAN
> partitions, then routers in the different partitions assign duplicate
> Flow Labels, and then the partition heals?

It is solved exatcly as it is solved in mpls in the core and in the access
we would need to integrate admission control in the access router.

So the host signals for a flowlabel to the access router that do admission
control and also verifies the uniqueness of the flow-label in the access...

-- thomas

---

From: "Thomas Eklund" <[email-masked]>
Date: Mon, 4 Dec 2000 21:35:25 +0100

Hi Steve,
> I thought core routers classified packets for diffserv
> packets according
> to the arrival interface and the arriving DSCP bits, *not*
> the 5-tuple.

You are reffering to a BA classification that is done inside a diffserv
domain.

If you sit on a diffserv edge you must be able to do a full MF
classification that could include (src/dst MAC addresses, VLAN ID, 802.1 P
priority, src/dst IP address, src/dst subnetmask, DSCP, Protocolfield,
src/dst port TCP, src/dst UDP, TCP flags etc..) and map it into a DSCP.

-- thomas

---

From: Scott Bradner <[email-masked]>
Date: Mon, 4 Dec 2000 22:44:58 -0500 (EST)

> It was the Congestion Experienced bits defined by Raj Jain at Digital.
> Close to the ECN bits from Sally but not as robust.

teh "DEC Bit" also had different semantics but was trying to geach
the same goal

Scott