Mark,
Yeah... you may be right... we added the intro part to start the draft because mentioning
the construction "using Flow-Label" seems to have toxic email storm effect on
email lists around v6. Hence the disclaimers on flow-label usage at the start of the
text. Maybe it is wrongly placed and gives the wrong impression indeed... it is for sure
not the intent... It is our intent to set flow-label on the outer tunnel header, and this
is done by the router which is imposing the IPv6 tunnel outer header, but we are not
fiddling on the fly with transit flow-labels at all. This seems not to break any IPv6
rules I think.
However, as you point out the case of SRv6 EH insert, is a different story and
requires a bit more thought. It is possible also, but needs to use the SRv6
Opaque value-containers to carry the original Flow-label across the domain to
reconstruct the original flow-label value. Nevertheless, RFC8200 seems rather
restrictive on EH insertion, and hence we conveniently assumed that chances are
low for it to become reality due to IPv6 specification complexities and we
disregarded EH inject.
G/
-----Original Message-----
From: Mark Smith [mailto:[email protected]]
Sent: Tuesday, November 7, 2017 09:04
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [v6ops] FW: New Version Notification for
draft-fioccola-spring-flow-label-alt-mark-01.txt
Hi Gunter,
On 7 November 2017 at 17:56, Van De Velde, Gunter (Nokia - BE/Antwerp)
<[email protected]> wrote:
Hi Mark,
The flow label of the original packet is untouched. It is never manipulated in
this proposal. The flow label that is set in this proposal is done at the SRv6
tunnel-head end which imposes the SRv6 encapsulation header. It is this
encapsulation header which has the flow label which is used in this draft.
So basically, it is just the SRv6 tunnel outer encap header which is used for
alternate packet marking. And this is set only one time by the original SRv6
tunnel head-end router (which is the source address of the IPv6 SRv6
tunnel...). This outer SRv6 header is removed when the packet exits the SRv6
domain, and the original flow label appears again untouched. This does not
break any RFC at all because all because the original flow-label of the
original IPv6 packet is never touched.
So, in this proposal there is no device which is changing flow-labels at all.
It is only during the imposing of the SRv6 outer header, that the flow label
field is set once for Alternate marking purposes inside the outer SRv6 tunnel
header.
Hope it clarifies?
It does, although it seems to be contrary to quite a lot of the introduction
text:
"The flow label is an immutable field recommended to contain a pseudo-
random value [RFC6437]. However, in most packets it has the default
value of zero, although some TCP/IP stacks do set it according to
[RFC6437].
[RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used
in controlled environment,..."
"Based on these considerations, it is allowed to use the flow label
field in a managed domain, assuming when a packet leaves the domain,
the original flow label value MUST be restored."
and the later reference to
"[I-D.voyer-6man-extension-header-insertion]" all seems to be setting up a case
to justify modifying the original packet's flow label value and then restoring it using
the original value that has been somehow sent or signalled to the network egress.
As you've said, when tunnelling, the original packet and its flow label value
is entirely preserved, so there doesn't need to be any of the above text. Even
the text about hosts not setting the FL value isn't really necessary, as tunnel
end-points, as a function at the
IPv6 layer, are hosts that originate packets, so they can set the FL value to
what ever they like because they're originating the (tunnel) packet.
I think it might be better to avoid using two of the FL bits to encode the
marking method, as that also deviates from RFC6437 (I seem to remember we also
thought about using some bits in the FL to encode something during that time,
and also abandoned it.)
I'm not across the Alternate Marking Method work, so this might be a dumb
question or suggestion. Within a measurement domain, is there ever going to be
a mix of single and double marking, such that it needs to be encoded
per-packet? If a domain can only support one of them at any one time, then I
think that could be encoded in the configuration of the SRv6 tunnel end points,
rather than encoding it in a couple of the FL bits.
Also, there is now an IPv6 Performance and Diagnostics Destination Option which
may be a IPv6 conventional way of encoding this marking or measurement
information in the outer IPv6 tunnel header (i.e.
[Outer IPv6 HDR][PDM][Inner/Original IPv6 Packet])
"IPv6 Performance and Diagnostic Metrics (PDM) Destination Option"
https://tools.ietf.org/html/rfc8250
Regards,
Mark.
G/
-----Original Message-----
From: Mark Smith [mailto:[email protected]]
Sent: Tuesday, November 7, 2017 06:16
To: Van De Velde, Gunter (Nokia - BE/Antwerp)
<[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [v6ops] FW: New Version Notification for
draft-fioccola-spring-flow-label-alt-mark-01.txt
On 7 November 2017 at 02:59, Van De Velde, Gunter (Nokia - BE/Antwerp)
<[email protected]> wrote:
If any feedback or comments (preferably constructive), then please
have the discussion including SPRING WG in cc
So this draft, similar to the IPv6 EH insertion draft, doesn't answer the
fundamental question of why.
What technical and engineering reasons justify reusing the flow label field,
contrary to its specification? What alternatives were considered that don't
violate the the flow label specification, and why are their drawbacks so
significant that they justify ignoring the flow label specification? Use of
IPv6 fields can be novel, however the novelty has to fit within the
specifications to ensure interoperability.
"[RFC6436] and [RFC6437] open the door for IPv6 Flow Label to be used
in controlled environment,"
I'm sure it doesn't. During the original discussions that resulted in RFC6437,
I suggested the idea of Flow Label domains similar to DSCP domains. It was
ignored for valid reasons. This is the discussion mentioned in the first
paragraph of appendix A in RFC6436.
"A model was discussed in an earlier version of this document which
defined a notion of 'flow label domain' analogous to a differentiated
services domain [RFC2474]. This model would have encouraged local
usage of the flow label as an alternative to any form of generic use,
but it required complex rules for the behavior of domain boundary
routers, and proved controversial in discussion."
Here's what the flow label specification RFC says,
"Once set to a non-zero value, the Flow Label is expected to be
delivered unchanged to the destination node(s). A forwarding node
MUST either leave a non-zero flow label value unchanged or change it
only for compelling operational security reasons as described in
Section 6.1"
I don't think the use in this draft is a "compelling operational security
reason".
A network can have a number of egress points. To be able to restore flow label
values upon egress, either all of the flow label restoration state for all
in-flight packets' flow label values will have to be kept synchronised at all
of the egress points, or kept synchronised in accordance with where the routing
protocol determines is the current egress point for the packet.
In this latter case, while in flight, the egress point could change, meaning
the packet's egress path changes, and there then occurs a race between when the
packet reaches the exit point and the flow label restoration state for that
packet reaches that egress point so that it can be restored.
So are packets going to be held/delayed upon ingress such that they can never reach the
egress point before their original flow label value information reaches that egress point
first? If they're not, then there is no assurance that the original flow label value can
be restored, and the domain isn't closed anymore. The modified packet leaves the
"closed domain" with the modification unrestored.
"The IPv6 protocol includes a flow label in every packet
header, but this field is, according to [RFC6294], not used in
practice."
RFC6294 was published in 2011, 6 years ago. Implementations have changed since
then.
The Linux kernel is setting flow label values per RFC6437 per Tom Herbert's
Linux kernel patch in the order of 2 years ago.
Random flow labels look to be also being set by Mac OS X around the
same time (July 2015) -
https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html
Windows was the major hold out - the latest Windows 10 Creater Update is now
setting Flow Labels.
https://www.ietf.org/mail-archive/web/ipv6/current/msg22820.html
It seems people are starting to believe "closed domains" can be used to justify
modifying packets in flight, in any way they'd like to modify them. In theory and in
specifications, the modifications are guaranteed to be reversed at egress, in practice,
contrary to specifications, implementations and network operations are not guaranteed and
perfect. The reversal may not occur at egress due to implementation bugs, partial device
failures or operator configuration error or omission. These sorts of in-flight changes
are not conservative, making them contrary to the Robustness Principle.
As shown by RFC1918 address and route leaks, "closed domains" attached to the
Internet aren't guaranteed to be closed. A closed domain network can only be truly closed
off from the Internet if it is completely isolated with an air gap.
Regards,
Mark.
G/
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, October 26, 2017 16:35
To: Giuseppe Fioccola <[email protected]>; Van De
Velde, Gunter (Nokia - BE/Antwerp) <[email protected]>;
Muley, Praveen (Nokia - US/Mountain View) <[email protected]>;
Mauro Cociglio <[email protected]>
Subject: New Version Notification for
draft-fioccola-spring-flow-label-alt-mark-01.txt
A new version of I-D,
draft-fioccola-spring-flow-label-alt-mark-01.txt
has been successfully submitted by Giuseppe Fioccola and posted to the IETF
repository.
Name: draft-fioccola-spring-flow-label-alt-mark
Revision: 01
Title: Using the IPv6 Flow Label for Performance Measurement with
Alternate Marking Method in Segment Routing
Document date: 2017-10-26
Group: Individual Submission
Pages: 8
URL:
https://www.ietf.org/internet-drafts/draft-fioccola-spring-flow-label-alt-mark-01.txt
Status:
https://datatracker.ietf.org/doc/draft-fioccola-spring-flow-label-alt-mark/
Htmlized:
https://tools.ietf.org/html/draft-fioccola-spring-flow-label-alt-mark-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-fioccola-spring-flow-label-alt-mark-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-fioccola-spring-flow-label-alt-mark-01
Abstract:
[RFC6294] makes a survey of Proposed Use Cases for the IPv6 Flow
Label. The IPv6 protocol includes a flow label in every packet
header, but this field is, according to [RFC6294], not used in
practice. This document describes how the alternate marking method
can be used as the passive performance measurement method in a IPv6
domain.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/v6ops
