Subject: Re: [spring] [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Nov 2017 13:27:30 +1300

Hi,

> but this field is, according to [RFC6294], not used in practice.

I don't think it's very useful to cite in 2017 a document
published in 2011 based on realities in 2010 or earlier.
Actually I think you can actually delete the whole phrase;
since the proposal tries to respect RFC6437, it is
irrelevant anyway.

The draft cites RFC2460 but that is obsolete; please cite
RFC8200 instead.

> The use of the other 18 bits is not specified in this document	
> because is out of scope here.  But it should follow [RFC6437].

I think is a slight simplification. What you are saying is 
the 18 bits should be a pseudo-random number (following the
guidance given in 6437 for all 20 bits) and the 2 bits will
have local semantics but will be set to 00 (I assume) for
packets that leave the domain, thus retaining 18 bits
of entropy instead of 20. (Which means there will only
be about 256k possible flow label values, instead of a
million, but that is still plenty of scope for load
balancing.)

Regards
   Brian

On 07/11/2017 04:59, Van De Velde, Gunter (Nokia - BE/Antwerp) wrote:
> If any feedback or comments (preferably constructive), then please have the discussion including SPRING WG in cc
> 
> G/
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2017 16:35
> To: Giuseppe Fioccola <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>; Mauro Cociglio <[email-masked]>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 Nov 2017 16:15:41 +1100

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

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 7 Nov 2017 06:56:20 +0000

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-masked]] 
Sent: Tuesday, November 7, 2017 06:16
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]; [email-masked]
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-masked]> 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.

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.

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.

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

Windows was the major hold out - the latest Windows 10 Creater Update is now setting Flow Labels.

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.

> To: Giuseppe Fioccola <[email-masked]>; Van De 
> Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; 
> Muley, Praveen (Nokia - US/Mountain View) <[email-masked]>; 
> Mauro Cociglio <[email-masked]>
> Subject: New Version Notification for 
> draft-fioccola-spring-flow-label-alt-mark-01.txt
>
>

---

From: Mark Smith <[email-masked]>
Date: Tue, 7 Nov 2017 19:03:31 +1100

Hi Gunter,

> 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 pu…

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.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 7 Nov 2017 08:23:27 +0000

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-masked]] 
Sent: Tuesday, November 7, 2017 09:04
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

Hi Gunter,

> 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 pu…

It does, although it seems to be contrary to quite a lot of the introduction text:

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])

Regards,
Mark.

> Subject: Re: [v6ops] FW: New Version Notification for 
>> A new version of I-D,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Nov 2017 08:17:55 -0300

>    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-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Nov 2017 08:21:01 -0300

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

My take: Make that as explicit as here, and I bet there will be no need
to discuss further 8fingers crossed :-) ).

> 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 origi…

Same here: If EH insertion is not allowed, it shouldn't even be
mentioned. If eventually it is allowed, a new (possibly updating this
one) doc could address the topic.

Thanks!

Cheers,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 7 Nov 2017 09:23:14 -0500

Is there an implicit assumption that ALL traffic in a domain will be 
using SRv6 encapulating headers?

If not, then how will devices know whether they can mark the "ecn bits" 
of the flow label" on a particular packet?

If you are assuming complete deployment, how is that practical for 
operational networks?

Yours,
Joel

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 7 Nov 2017 16:35:02 +0000

Hi Joel,
Thanks for your comments. See my answers inline tagged as [GF].

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: spring [mailto:[email-masked]] Per conto di Joel M. Halpern
Inviato: martedì 7 novembre 2017 15:23
A: Van De Velde, Gunter (Nokia - BE/Antwerp); Mark Smith
Cc: [email-masked]; [email-masked]
Oggetto: Re: [spring] [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

Is there an implicit assumption that ALL traffic in a domain will be using SRv6 encapulating headers?

[GF]: not only, the document considers also IPv6 tunneled packets.

[GF]: The devices can be instructed on how to select the flow to be monitored. A packet flow can be defined by a set of selection rules used to match a subset of the packets. These rules specify a set of headers fields: Identification Fields (e.g. TCP 5-tuple). Once the flow has been identified, It can be marked and monitored.

If you are assuming complete deployment, how is that practical for operational networks?

[GF]: Agree, the management aspects of the alternate marking applications have to be well defined and we are working on it in a new coming companion draft for alternate marking foundation document.

Yours,
Joel

_______________________________________________
spring mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spring

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. 

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. 

Rispetta l'ambiente. Non stampare questa mail se non è necessario.