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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
