Subject: RE: Usage of IPv6 flow label

From: "Elwyn Davies" <[email-masked]>
Date: Tue, 28 Nov 2000 16:21:59 -0000

Hi.

1.  draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this draft
are not something that we should be supporting - it proposes polluting a
network layer header with application layer info.  If an application needs
to multiplex streams onto a single socket in the way proposed it could
equally well format the PDU in an appropriate way without layer pollution.

2. draft-itojun-ipv6-flowlabel-api-00 - this draft seems entirely sensible
apart possibly from the desire to modify the flow label whenever the
extension headers change.  This should probably be under user control.
Otherwise the network layer is allowed to control its own destiny whilst
providing some useful information which allows routers simply to tie up the
relationship between the packets of a flow.

3.  The e2e mutability issue has been done to death in DiffServ for code
points and it sounds like the whole argument is being trotted out again.
The one and only fundamental point is that if the flow label is mutable,
information is generally lost when it is changed after original setting and
can never be restored unless there is some additional agency available to
regenerate the information (entropy argument).  If the label is changed in a
way that does not lose information then it doesn't matter;  likewise, if you
don't care about the loss of information then go ahead and change it.

4. The flow label could clearly (also) be used as a signalling method to
help out with inter-domain MPLS issues when you need to cross exchange
points where the whole MPLS header has to be removed.

I concur fully with Brian Carpenter's points on orthogonality of DiffServ
and MPLS.  As we know some of the proposals for combining MPLS and DiffServ
have an implicit (i.e. signalled during path setup) connection between label
and DSCP (as opposed to just intepreting the bits in the label).  This is
obviously important to MPLS because if there is an MPLS header, the router
(LSR) shouldn't go poking around in the encapsulated packet to determine
what the DSCP is (If MPLS is used as originally intended, the payload might
not be an IP packet of any kind!). So:
A. If there is an MPLS (Shim) header, that header specifies either
implicitly or explicitly the DSCP to be used.  The DSCP and flow label in
the IPv6 header are never inspected once the packet is flowing down the MPLS
path.
B. If there isn't, you could use the flow label for flowy type things (like
helping with determining what MPLS path should be used at the beginning of
each of, perhaps, several serially crossed MPLS domains), but the DSCP in
the packet should be used to drive the DiffServ operations.

Regards,
Elwyn Davies

----------------------------------------------------------------------------
------

Elwyn B Davies

Tel: +44 1279 405498 (ESN 742 - 5498)
Email: [email-masked]

Technical Strategy Manager - IP Networks
Advanced Technology Centre
Nortel UK
London Road
Harlow
Essex
UK
CM17 9NA

"The Folly is mostly mine"
and the opinions are mine and not those of my employer.

============================================================================
======

---

From: Alex Conta <[email-masked]>
Date: Thu, 30 Nov 2000 04:16:01 -0500

Elwyn

> Elwyn Davies wrote:
>  [...]
> 
> 3.  The e2e mutability issue has been done to death in DiffServ for
> code points and it sounds like the whole argument is being trotted out
> again.  The one and only fundamental point is that if the flow label
> is mutable, information is generally lost when it is changed after
> original setting and can never be restored unless there is some
> additional agency available to regenerate the information (entropy
> argument).  If the label is changed in a way that does not lose
> information then it doesn't matter;  likewise, if you don't care about
> the loss of information then go ahead and change it.
> 

More explicitly, the information can be a combination of labels and
state in 
each router, ala MPLS. Labels can change from one node to another, but
the 
state in which node, links the input label value to the output label
value, 
without affecting the information being transmitted.

> 4. The flow label could clearly (also) be used as a signalling method
> to help out with inter-domain MPLS issues when you need to cross
> exchange points where the whole MPLS header has to be removed.
> 

I am not sure about the practical value of this.
If two MPLS domains are logically disjoint, I think that there are
practical
reasons - they are not physically adjacent, or if they are, the logical 
separation is desired, which seems to make more sense with a new MPLS 
classification at the downstream domain border.

> I concur fully with Brian Carpenter's points on orthogonality of
> DiffServ and MPLS. 
[...]
> Elwyn Davies

I think the orthogonality is relative.
MPLS labels may carry Diffserv, and Intserv information, and may be
derived
based on Diffserv, and Intserv information. I would not necessarily call
that
orthogonal.

Alex