On 11/07/2017 05:03 AM, Mark Smith wrote: > 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."
Maybe this comes from the time when SR considered header insertion? Anyway, I agree that the text should be modified in this respect, since, as Gunter noted, there's no FL being modified, since it's a new (encapsulating) packet. FWIW, I also think that references to header insertion should be eliminated (including pointers to individual submissions that propose that), since RFC8200 does not allow it. Thanks, -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
