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

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 6 Nov 2017 15:59:58 +0000

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

---

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 6 Nov 2017 17:13:05 -0800

On Mon, Nov 6, 2017 at 7:59 AM, Van De Velde, Gunter (Nokia -
Hi,

Per section 3, either all the switches in a domain need to be update
to mask the bits or use flow label for ECMP needs to be disabled for
the domain. Neither of these options seem very desirable to me.

Can the assigned bits be in the high order bits of the flow label?
This might make some manipulation easier.

>From section 1:

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

In this proposal, if two bits are overwritten by an intermediate node,
how are their original values restored when leaving the domain?

Tom

---

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:44:16 +0000

Hi Tom,

-->
From section 1:

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

In this proposal, if two bits are overwritten by an intermediate node, how are their original values restored when leaving the domain?
-->

GV>  Because the field that are being fiddled with are on the IPv6 SRv6 outer encapsulation header. When the original packet leaves the controlled domain, then that header is removed again, and the original IPv6 packet with original headers appear again. 

G/

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Tuesday, November 7, 2017 02:13
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

On Mon, Nov 6, 2017 at 7:59 AM, 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
>
> G/
>
> 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
>
>
Hi,

Per section 3, either all the switches in a domain need to be update to mask the bits or use flow label for ECMP needs to be disabled for the domain. Neither of these options seem very desirable to me.

From section 1:

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

In this proposal, if two bits are overwritten by an intermediate node, how are their original values restored when leaving the domain?

Tom

---

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

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

---

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

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: Tom Herbert <[email-masked]>
Date: Tue, 7 Nov 2017 07:16:15 -0800

On Mon, Nov 6, 2017 at 10:44 PM, Van De Velde, Gunter (Nokia -
> GV>  Because the field that are being fiddled with are on the IPv6 SRv6 outer encapsulation header. When the original packet leaves the controlled domain, then that header is removed again, and the…
Gunter,

If the measurements are always coincident with the use of SRv6 then
why not put the measurement information in the SR EH or some other EH
(hop-by-hop or est opt maybe) used only in the controlled domain? This
also could be more flexible since the algorithm wouldn't be
constrained to just two bits of data.

Tom

---

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

A transit router does not look at EHs if it is not configured for the IPv6 Destination address.. so its not usable in that case.

G/

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Tuesday, November 7, 2017 16:16
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

Gunter,

If the measurements are always coincident with the use of SRv6 then why not put the measurement information in the SR EH or some other EH (hop-by-hop or est opt maybe) used only in the controlled domain? This also could be more flexible since the algorithm wouldn't be constrained to just two bits of data.

Tom

---

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.

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Nov 2017 08:58:35 -0800

On Tue, Nov 7, 2017 at 7:26 AM, Van De Velde, Gunter (Nokia -
> A transit router does not look at EHs if it is not configured for the IPv6 Destination address.. so its not usable in that case.
They do look at hop-by-hop options. Previously it was required that
all nodes in the path must process them, but that was relaxed a bit in
RFC8200. If they are only used for tunneling across a controlled
domain then the typical concern that intermediate nodes don't properly
handle hop-by-hop options can be addressed.

Tom

---

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

To me it seems that looking at FL is much easier for a HW based router then looking at EHs in a hop-by-hop fashion…

G/

On 07/11/2017, 17:58, "Tom Herbert" <[email-masked]> wrote:

    Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Nov 2017 10:14:51 -0800

On Tue, Nov 7, 2017 at 9:13 AM, Van De Velde, Gunter (Nokia -
> To me it seems that looking at FL is much easier for a HW based router then looking at EHs in a hop-by-hop fashion…

Easier for whom? Repurposing bits in the IP header even for a narrow
use case in a closed system doesn't seem particularly easy to
standardize or deploy. As Mark pointed out there's a lot of complexity
around ensuring that the system really is closed and all required
behavior is maintained.

Another obvious question with this approach is does it mean that flow
label bits are now fair game to be defined for even more purposes?
Latency measurement isn't be the only potential use case. For
instance, I know there's a lot of people that want hosts to mark
packets with a "retransmitted" bit so that routers can keep stats for
tracked flows. IMO, if using flow bits like this is the right answer
then there should be a generic protocol specification that defines the
operation and how bits are allocated for all the potential uses.

Tom

---

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

Hi Tom,

The closed system here is defined by the SRv6 tunnels… The flow-label is set “only” by the tunnel head-end router “on the outer IPv6 header”. The tunnel head-end router can do this because it is the device that created the outer IP header.
The original IPv6 packet is riding inside the tunnel, and as result the original flow label and original IPv6 header is left untouched. The closed system is the network between the tunnel head-end (=where the 
outer IPv6 header is added) and the tunnel tail-end (=where the outer header is removed). This type of closed system is easy to deploy… take for example a MPLS/VPN backbone…. Or a VxLAN network… The SRv6 network is something of similar simplicity.

The IPv6 device that generates an IPv6 packet can set the flow label, and that is what devices have been doing all the time. This draft proposes nothing new from that perspective. 

Why do you say ‘repurposing’ the bits? Nothing is repurposed. This proposal is respecting RFC6437. In our informational proposal the flow-label just remains flow-label. Routers can be made to match upon flow-label values easily. I know my Nokia products can do that very easily, because the flow-label is always found at the same place in the IPv6 header. However, checking on EHs is a few dimensions more complicated. When I must make my router match for content in EHs, then first it must check if the relevant EH is inserted, then the corresponding EH must be identified and then the content has to be checked… This EH checking is non-trivial as result… For a HW based router (my Nokia router for example) the checking of flow-label is as simple as checking for a DSCP value because the operation involved is exactly the same.

Tom, if your additional suggestions for using flow labels is respecting RFC6437 then what stops you from documenting those thoughts? The alternate marking principle documented in this draft for SRv6 is something that is driven by operator themselves, and is based upon real operator requirement. Feel free to further discuss with the Telekom Italia co-authors (Guiseppe and Mauro) on TI needs for such passive measurement mechanism (loss, latency, jitter, etc). 

G/

On 07/11/2017, 19:14, "Tom Herbert" <[email-masked]> wrote:

    
    
    Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Nov 2017 12:15:56 -0800

On Tue, Nov 7, 2017 at 11:53 AM, Van De Velde, Gunter (Nokia -
Gunter,

I believe section 3 imposes new requirements on flow label usage. Specifically:

"The methodology SHOULD be used within a controlled domain where the
load-balancing based on flow label is disabled.  Otherwise, the
network element MUST mask the Mark Field (MF), so it will not change
hashing calculation for the same flow because only 18 bits + 2 zeros
are used for the entropy."

This implies that the proposal is not compatible with the canonical
use of flow label for ECMP. If option one is selected then the only
use of the flow label is to express the MF bits the whole flow label
has been repurposed and we lose the value of flow hashing. Option 2
requires an implementation change to routers function, and as I
pointed, there would likely be other uses of bits so this really
should be defined as a configurable mask. As I said before, neither of
these options seem desirable.

Tom

---

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

In this case, the controlled domain reflects to the fact that it is operator choice that grabs control of packet handling within its own network.
The operator adds through policy the outer SRv6 header. The operator has in fact then three options regarding flow label:

1) Just do not do anything with Flow-label (leave it default)
2) Alternate marking only and NO usage of entropy 
3) Alternate marking and entropy (in this case the entropy SHOULD be based upon 18 bits instead of 20 bits because otherwise paths may be changed when the marking changes (e.g. periods of 5 minutes per marking period) …. This is however not a MUST because some operators do not care if because of marking change.

Fwiw right now, most vendors allow a wide breath of options for entropy hashing upon an IP header… and many of the combinations do not have a formal RFC attached for that operation at all. This hash upon 18 bits of flow label would just be another flavour of entropy that operator can enable upon the router … it is not hard ... I as vendor can deliver this and I need no standard for this because it is nodal behaviour… An embodiment of an improved hash upon the flow-label could indeed make use of wild-cards … A wildcard match upon flow-label for entropy could be another proposal to potentially have new flow-label field usage… however, it comes at a cost… each bit that is removed from the entropy hash , results is LESS entropy, which is undesirable also. Also advanced wild-card based hash for entropy upon flow-label goes beyond the need for Alternate marking within the operator controlled domain, hence we see no need for such type of wild card based hash…

G/

On 07/11/2017, 21:15, "Tom Herbert" <[email-masked]> wrote:

    Gunter,

    
    
    Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 7 Nov 2017 14:28:25 -0800

> Why do you say ‘repurposing’ the bits? Nothing is repurposed. This proposal is respecting RFC6437. In our informational proposal the flow-label just remains flow-label. Routers can be made to match…

I don't believe the EH processing needs to be complicated. In this
case the assumption is that network operator is inserting the headers
so the HBH EH with a latency measurement option could be implemented
to always be in the same position, have the same length, and only set
with one option for latency. The router processingcan be optimized to
handle this case. Existence and verification of the EH can all be done
with simple checks and TCAM could be used to match the common header
pattern. The IP header and extension header should fit well within the
parsing buffer of typical routers.

> Tom, if your additional suggestions for using flow labels is respecting RFC6437 then what stops you from documenting those thoughts? The alternate marking principle documented in this draft for SRv…

The fact that operators want passive latency measurements is not the
same as saying that applying a format to the flow label is a
requirement. It is the mechanism of this proposal this is in question.

Tom

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 8 Nov 2017 05:05:16 +0000

There few other drawbacks that we considered when we selected to use Flow-label instead of an EH solution for SRv6 alternate marking:

* easier backward compatibility because nothing breaks if a transit router does not have the capability of understanding the Flow label context... in that case the flow-label in the outer tunnel header is just a flow-label
* Having a HbH EH seems less backward compatible, and will be less easy to use unless ALL routers in the domain support these type of headers in the fast-path... it just seems complex because of all the if-then-but involved to implement, use and operate...
* For HW based routers (i.e. in Nokia case having user-plane switching capability scale of 2.8T per NPU) the support nearly comes for free as support is already there... nothing extra is needed from a nodal perspective
* Less bits on the wire... going SRv6 has already a significant bits-on-wire tax because of the outer IPv6 header and the SRv6 EH and all the source routing headers

So, indeed a new type of EH may be a solution space proposal, however, I do not think it is as pragmatic as using the flow-label in the outer IPv6 SRv6 header because of all the benefits flow-label usage gives. The Flow-label proposal, is basically something that routers can do right now,  and it does not break any IPv6 rules and is expected to be supported in line-rate by the fast path switching of routers by default.

Indeed she solution proposed in the draft, is for the moment assumed to be exclusive from other usages (with exception of entropy) of the flow-label in the controlled operator domain... it does not necessary have to be exclusive, but it seems the most pragmatic. Currently, operator traditionally do not use flow-label at all, hence the above assumption seems reasonable. 

G/ 

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Tuesday, November 7, 2017 23:28
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

On Tue, Nov 7, 2017 at 11:53 AM, Van De Velde, Gunter (Nokia -
BE/Antwerp) <[email-masked]> wrote:
> The original IPv6 packet is riding inside the tunnel, and as result 
> the original flow label and original IPv6 header is left untouched. The closed system is the network between the tunnel head-end (=where the outer IPv6 header is added) and the tunnel tail-end (=where the outer header is removed). This type of closed system is easy to deploy… take for example a MPLS/VPN backbone…. Or a VxLAN network… The SRv6 network is something of similar simplicity.
>

I don't believe the EH processing needs to be complicated. In this case the assumption is that network operator is inserting the headers so the HBH EH with a latency measurement option could be implemented to always be in the same position, have the same length, and only set with one option for latency. The router processingcan be optimized to handle this case. Existence and verification of the EH can all be done with simple checks and TCAM could be used to match the common header pattern. The IP header and extension header should fit well within the parsing buffer of typical routers.

> Tom, if your additional suggestions for using flow labels is respecting RFC6437 then what stops you from documenting those thoughts? The alternate marking principle documented in this draft for SRv…

The fact that operators want passive latency measurements is not the same as saying that applying a format to the flow label is a requirement. It is the mechanism of this proposal this is in question.

Tom

>     > To me it seems that looking at FL is much easier for a HW based 
> router then looking at EHs in a hop-by-hop fashion…
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 8 Nov 2017 07:57:15 +0000

> -----邮件原件-----
> 发件人: v6ops [mailto:[email-masked]] 代表 Van De Velde, Gunter
> (Nokia - BE/Antwerp)
> 发送时间: 2017年11月8日 4:37
> 收件人: Tom Herbert
> 抄送: [email-masked]
> 主题: Re: [v6ops] FW: New Version Notification for
> In this case, the controlled domain reflects to the fact that it is operator choice
> that grabs control of packet handling within its own network.
> The operator adds through policy the outer SRv6 header. The operator has in
> fact then three options regarding flow label:
> 
> 3) Alternate marking and entropy (in this case the entropy SHOULD be based
> upon 18 bits instead of 20 bits because otherwise paths may be changed when
> the marking changes (e.g. periods of 5 minutes per marking period) …. This is
> however not a MUST because some operators do not care if because of marking
> change.

In option 3, it would require a few changes to the RFC6437-compatible behaviors of intermediate routers within a controlled network domain. Hence it seems better and safer to disable the FL-based load-balancing mechanism in this special case, especially when the existing load-balancing mechanism (e.g., five-tuple-based LB) is good enough, IMHO. 

Best regards,
Xiaohu

> Fwiw right now, most vendors allow a wide breath of options for entropy
> hashing upon an IP header… and many of the combinations do not have a
> formal RFC attached for that operation at all. This hash upon 18 bits of flow
> label would just be another flavour of entropy that operator can enable upon
> the router … it is not hard ... I as vendor can deliver this and I need no standard
> for this because it is nodal behaviour… An embodiment of an improved hash
> upon the flow-label could indeed make use of wild-cards … A wildcard match
> upon flow-label for entropy could be another proposal to potentially have new
> flow-label field usage… however, it comes at a cost… each bit that is removed
> from the entropy hash , results is LESS entropy, which is undesirable also. Also
> advanced wild-card based hash for entropy upon flow-label goes beyond the
> need for Alternate marking within the operator controlled domain, hence we
> see no need for such type of wild card based hash…
> 
> G/
> 
>     > The closed system here is defined by the SRv6 tunnels… The flow-label is
> set “only” by the tunnel head-end router “on the outer IPv6 header”. The
> tunnel head-end router can do this because it is the device that created the
> outer IP header.
>     > The original IPv6 packet is riding inside the tunnel, and as result the
> original flow label and original IPv6 header is left untouched. The closed system
> is the network between the tunnel head-end (=where the
>     > outer IPv6 header is added) and the tunnel tail-end (=where the outer
> header is removed). This type of closed system is easy to deploy… take for
> example a MPLS/VPN backbone…. Or a VxLAN network… The SRv6 network is
> something of similar simplicity.
>     >
>     > The IPv6 device that generates an IPv6 packet can set the flow label, and
> that is what devices have been doing all the time. This draft proposes nothing
> new from that perspective.
>     >
>     Gunter,
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 Nov 2017 07:33:41 -0800

> In option 3, it would require a few changes to the RFC6437-compatible behaviors of intermediate routers within a controlled network domain. Hence it seems better and safer to disable the FL-based l…
Five-tuple hash requires parsing into the transport layer to get the
ports. In the proposed use case there will be extension headers (at
least a routing header) so routers would need to parse over those.
It's unlikely that such parsing is consistently implemented and
besides that the whole point of using the flow label for ECMP is to
obviate the need for routers to perform DPI.

Tom

---

From: joel jaeggli <[email-masked]>
Date: Wed, 8 Nov 2017 08:16:26 -0800

> obviate the need for routers to perform DPI.

The flow label is unprotected in the header which makes it hard to use
to hash to stateful endpoints. it would be helpful if nothng ever
changed it or did so consistently but in fact devices that do so exist.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 8 Nov 2017 09:25:32 -0800

> changed it or did so consistently but in fact devices that do so exist.
Joel,

The problem isn't at stateful endpoints, it's with middleboxes that
maintain flow state. The result of a flow label change at an endpoint
is OOO packets which any transport protocol is expected to gracefully
handle. A middlebox that maintains state expects all packets of the
flow to got through it, so if there is a flow label change (or other
routing change) packets for the flow may bypass the device (like a
firewall or NAT) with the flow state. It's likely they're forwarded
through a peer device that doesn't have any state for the flow and so
dropped packets ensue.

This has created an implicit requirement on network architecture that
all packets of a flow need to follow the same path. From a host
perspective there are good reasons to change the flow label, for
instance we can modulate the the flow label for a failing connection
as a form of source routing to try for a better route through the
network. However, from a practical perspective I suppose the
recommendation should be that by default the flow label should be
constant for the lifetime of the flow.

Tom

---

From: joel jaeggli <[email-masked]>
Date: Wed, 8 Nov 2017 10:16:43 -0800

> constant for the lifetime of the flow.

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

Disgusting get out of jail-free card not-withstanding that's
unequivical. If It changes I cannnot use it for hashing in my load
balancer function.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 8 Nov 2017 19:10:24 +0000

While an interesting discussion, it has little to do with the current proposal and use-case scenario.
The solution is not used on the Internet, but in a 100% operator controlled environment.

In the current proposal there is no middleware fiddling en-route with the original flow-label at all. 
The original packet flow-label remains unchanged and is carried INSIDE the tunnel as normal tunnel payload.

Keep in mind that the operator is the big boss inside the network it controls. The operator knows how the network looks like. The operator knows how to orchestrate and consume the available bandwidth. The operator knows how all traffic must flow within its network. The operator can architect through IPv6 segment routing to avoid certain Firewalls or Load-balancers or other middleware if particular middleware does not support required features. The operator is the single authority within the network. It is not the role of IETF to dictate functionality an operator wants to use or not use. 

That being said, it is for some operators perfectly fine to live with entropy generated by 18 bits, instead of 20 bits, 
Assuming it provides advanced measurement capabilities and does not break any RFCs. It is for routers a reasonable solution to generate entropy based upon 18 bits instead of on 20 flow-label bits. 

G/

-----Original Message-----
From: joel jaeggli [mailto:[email-masked]] 
Sent: Wednesday, November 8, 2017 19:17
To: Tom Herbert <[email-masked]>
Cc: Xuxiaohu <[email-masked]>; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Subject: Re: [v6ops] 答复: FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

On 11/8/17 09:25, Tom Herbert wrote:
>>>>> In this case, the controlled domain reflects to the fact that it 
>>>>> is operator choice that grabs control of packet handling within its own network.
>>>>> The operator adds through policy the outer SRv6 header. The 
>>>>> operator has in fact then three options regarding flow label:
>>>>>
>>>>> 3) Alternate marking and entropy (in this case the entropy SHOULD 
>>>>> be based upon 18 bits instead of 20 bits because otherwise paths 
>>>>> may be changed when the marking changes (e.g. periods of 5 minutes 
>>>>> per marking period) …. This is however not a MUST because some 
>>>>> operators do not care if because of marking change.
>>>>
>> The flow label is unprotected in the header which makes it hard to 
>> use to hash to stateful endpoints. it would be helpful if nothng ever 

6437 says

Disgusting get out of jail-free card not-withstanding that's unequivical. If It changes I cannnot use it for hashing in my load balancer function.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Nov 2017 08:35:17 +1300

> unequivical. If It changes I cannnot use it for hashing in my load

Sure. But if a local domain chooses to restrict itself to hashing
18 bits that's its privilege; we don't specify the hash algorithm.
And if the packet is forwarded outside the local domain, the other
two bits need to be set to consistent values for use on the outside.
I think the draft meets those conditions.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 12 Nov 2017 12:23:13 +1100

Hi Gunter,

> * Having a HbH EH seems less backward compatible, and will be less easy to use unless ALL routers in the domain support these type of headers in the fast-path... it just seems complex because of al…

I think that is an advantage of using destination addresses to encode
this processing.

In addition to identifying a host, I think in IP a destination address
is also and more fundamentally identifying an exit point from the
forwarding domain. It indicates where processing for forwarding to the
DA stops, and where other more complex processing of the packet is to
occur, using information past the fixed IP header, and likely in the
payload. Processing of the IPv6 Routing Header EH, or information in
the payload e.g. transport and further upper layer processing are
examples.

Using the DA to encode this more complex processing means that it is
easy to retrofit into existing devices and models. There is no need to
replace existing IPv6 forwarding devices, because they already support
DA based forwarding. An SR box with the DA could be hung off the side
of an existing router, do its magic, and then resubmit the newly SR
processed packet back into the conventional forwarding domain, to be
forwarded onto the next SR box that owns the specified DA (Inspired by
how Ipsilon Networks added IP forwarding to ATM networks).

> * Less bits on the wire... going SRv6 has already a significant bits-on-wire tax because of the outer IPv6 header and the SRv6 EH and all the source routing headers

"Scrounging" bits from other fields because the SRv6 header has become
large seems to be trying to avoid fixing the problem where it is
caused.

I'd guess a lot of this size has come from the use of 128 bit IPv6
addresses to identify segments. I think a question is do they really
need to be that large?

I thought about per-packet overhead in the context of IPv6 tunnelling
a few years ago. It occurred to me that if tunnel end-points were
identified using /64s rather than /128s, then the IID parts of the
outer IPv6 source and destination addresses could be used for
something else. If those other things came from the inner packet, then
they could be removed from the inner packet, reducing the effective
tunnelling overhead.

I wrote up some of those ideas in "Enhancing Virtual Network
Encapsulation with IPv6"
(https://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-07).
More recently I took the next step and developed a tunnelling method,
although the savings weren't quite as high as I'd hoped due to the 8
octet minimum size requirement of an Extension Header - "Skinny IPv6
in IPv6 Tunnelling"
(https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00)

IPv6 networks have a lot of /64s. In this draft's scenario, ULA
addressing should be being used for the outer header addressing to
minimise leaking. ULA /48s have 65K /64s, and if that isn't enough,
multiple ULA /48 prefixes can be used to generate more /64s.

It would be a significant change to SR at this time I'd suspect,
however I think using /64s as Segment IDs rather than /128s would make
a significant SRH size overhead saving, avoiding the need to try to
leverage other non-SR fields, such as the Flow Label,  for SR or
related information.

Regards,
Mark.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Sun, 12 Nov 2017 02:32:52 +0000

In SRv6 we had similar on the reality of the need of 128 bits vs 64 bits inside the SRH header.... It was strongly opposed by the editors of the SRv6 dataplane draft. Reason was that it did not provides the same capability of uniquely identifying a single system.

I think it is a good question to ask and a valid optimization for a range of use-cases. Question is if the use-cases are strong enough to justify the perceived benefits of 128 bits vs 64 bits. This is a discussion to have in SPRING wg if that is something that is found worthy a discussion

G/

-----Original Message-----
From: Mark Smith [mailto:[email-masked]] 
Sent: Sunday, November 12, 2017 09:23
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

Hi Gunter,

On 8 November 2017 at 16:05, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> * easier backward compatibility because nothing breaks if a transit 
> router does not have the capability of understanding the Flow label 
> context... in that case the flow-label in the outer tunnel header is 
> just a flow-label

I think that is an advantage of using destination addresses to encode this processing.

In addition to identifying a host, I think in IP a destination address is also and more fundamentally identifying an exit point from the forwarding domain. It indicates where processing for forwarding to the DA stops, and where other more complex processing of the packet is to occur, using information past the fixed IP header, and likely in the payload. Processing of the IPv6 Routing Header EH, or information in the payload e.g. transport and further upper layer processing are examples.

Using the DA to encode this more complex processing means that it is easy to retrofit into existing devices and models. There is no need to replace existing IPv6 forwarding devices, because they already support DA based forwarding. An SR box with the DA could be hung off the side of an existing router, do its magic, and then resubmit the newly SR processed packet back into the conventional forwarding domain, to be forwarded onto the next SR box that owns the specified DA (Inspired by how Ipsilon Networks added IP forwarding to ATM networks).

> * For HW based routers (i.e. in Nokia case having user-plane switching 
> capability scale of 2.8T per NPU) the support nearly comes for free as 
> support is already there... nothing extra is needed from a nodal 
> perspective
> * Less bits on the wire... going SRv6 has already a significant 
> bits-on-wire tax because of the outer IPv6 header and the SRv6 EH and 
> all the source routing headers
>

"Scrounging" bits from other fields because the SRv6 header has become large seems to be trying to avoid fixing the problem where it is caused.

I'd guess a lot of this size has come from the use of 128 bit IPv6 addresses to identify segments. I think a question is do they really need to be that large?

I thought about per-packet overhead in the context of IPv6 tunnelling a few years ago. It occurred to me that if tunnel end-points were identified using /64s rather than /128s, then the IID parts of the outer IPv6 source and destination addresses could be used for something else. If those other things came from the inner packet, then they could be removed from the inner packet, reducing the effective tunnelling overhead.

I wrote up some of those ideas in "Enhancing Virtual Network Encapsulation with IPv6"
(https://tools.ietf.org/html/draft-smith-enhance-vne-with-ipv6-07).
More recently I took the next step and developed a tunnelling method, although the savings weren't quite as high as I'd hoped due to the 8 octet minimum size requirement of an Extension Header - "Skinny IPv6 in IPv6 Tunnelling"
(https://tools.ietf.org/html/draft-smith-skinny-ipv6-in-ipv6-tunnelling-00)

IPv6 networks have a lot of /64s. In this draft's scenario, ULA addressing should be being used for the outer header addressing to minimise leaking. ULA /48s have 65K /64s, and if that isn't enough, multiple ULA /48 prefixes can be used to generate more /64s.

It would be a significant change to SR at this time I'd suspect, however I think using /64s as Segment IDs rather than /128s would make a significant SRH size overhead saving, avoiding the need to try to leverage other non-SR fields, such as the Flow Label,  for SR or related information.

Regards,
Mark.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 15 Nov 2017 07:56:00 +0000

Hi All,

Based upon the feedback in v6ops, the authors reached realization that the proposed method has a more general alternate marking applicability with ipv6 tunnels. This because SRv6 can be seen as a well documented use case scenario of IPv6 tunnel encapsulation. 

Hence, the authors will respin the draft draft-fioccola-spring-flow-label-alt-mark-01 into a new v6ops draft creating a more general IPv6 tunnel approach. The controlled domain for marking in that case is contained between tunnel head and tail end.
(and SRv6 will be traveling within the v6 encap tunnel as payload)

Thanks for the feedback form all,
G/

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Van De Velde, Gunter (Nokia - BE/Antwerp)
Sent: Sunday, November 12, 2017 10:33
To: Mark Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

G/

-----Original Message-----
From: Mark Smith [mailto:[email-masked]]
Sent: Sunday, November 12, 2017 09:23
To: Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-spring-flow-label-alt-mark-01.txt

Hi Gunter,

Regards,
Mark.