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? 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
