Subject: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 26 Feb 2018 15:24:46 +0000

Hi All,

This is a new draft to document the usage of Alternate Marking in native IPv6 networks when IPv6 tunnels are used (i.e. when SRv6 is used). Feedback on the work is welcome. 

G/ 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, February 26, 2018 14:41
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-v6ops-ipv6-alt-mark-00.txt

A new version of I-D, draft-fioccola-v6ops-ipv6-alt-mark-00.txt
has been successfully submitted by Giuseppe Fioccola and posted to the IETF repository.

Name:		draft-fioccola-v6ops-ipv6-alt-mark
Revision:	00
Title:		IPv6 Performance Measurement with Alternate Marking Method
Document date:	2018-02-26
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-fioccola-v6ops-ipv6-alt-mark-00.txt
Status:         https://datatracker.ietf.org/doc/draft-fioccola-v6ops-ipv6-alt-mark/
Htmlized:       https://tools.ietf.org/html/draft-fioccola-v6ops-ipv6-alt-mark-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-fioccola-v6ops-ipv6-alt-mark-00

Abstract:
   This document describes how the alternate marking method can be used
   as the passive performance measurement method in an IPv6 domain, and
   will discuss the strengths and the weaknesses of the implementation
   options available to network operations.

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: Tom Herbert <[email-masked]>
Date: Mon, 26 Feb 2018 13:21:13 -0800

On Mon, Feb 26, 2018 at 7:24 AM, Van De Velde, Gunter (Nokia -
> This is a new draft to document the usage of Alternate Marking in native IPv6 networks when IPv6 tunnels are used (i.e. when SRv6 is used). Feedback on the work is welcome.

Hi,

I believe the following requirement contradicts flow label solution
having "easier backward compatibility":

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

RFC6438 states that the flow label for ECMP occupies the full 20 bits
and that "The same flow label value MUST be used for all packets in a
single user flow". There is no concept of a mask in that RFC and not
all network elements support a flow label mask (Linux does not for
instance), so the default solution will be to disable flow label for
load-balancing. That is unfortunate in itself, but since extension
headers are in use there may be devices in the network that don't
parse over extension headers to find transport ports for the hash, so
load-balancing with flow granularity may be lost as a result.

Tom

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Feb 2018 11:26:33 +1300

> load-balancing with flow granularity may be lost as a result.

Well, I haven't read the new draft yet, but from earlier discussion
with Gunter and his colleagues, I believe their proposal would leave
19 bits of entropy in the flow label, with just one bit forced to
zero, when the packet *leaves* the domain. I think that does give
enough entropy for flow-label based ECMP to operate well *outside*
the domain. The same would apply to server load-balancing (RFC7098).
However, as far as I can see, this technique definitely creates
problems for a site that relies internally on ECMP or server
load-balancing.

  Brian

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Tue, 27 Feb 2018 08:50:15 +0000

Indeed, the proposal would leave 18 bits for entropy (worst case is that 2 bits are used for Alternate marking according the Alternate marking standard).

An important aspect to keep in mind that is about the outer header of the tunneled traffic, and not the payload inside IPv6 headers. These outer tunnel headers do not always reach the DC because they are removed by the DCI or ASBR when sending traffic beyond. 

The motivation that triggered this work is the passive measurement of MBH traffic in a pure IPv6 underlay environment. This is area where specialized HW (name your preferred network device vendor) is active, and these routers can use flowlabel in any form to generate entropy. It is a nodal capability and is under control of the operator to configure on or not to configure. 

Yes, it is an important operational consideration, to document that the application domain of this draft, if not done so yet.

G/

-----Original Message-----
From: Brian Carpenter [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, February 26, 2018 23:27
To: Tom Herbert <[email-masked]>; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>
Cc: [email-masked] WG <[email-masked]>
Subject: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt

> load-balancing with flow granularity may be lost as a result.

Well, I haven't read the new draft yet, but from earlier discussion with Gunter and his colleagues, I believe their proposal would leave
19 bits of entropy in the flow label, with just one bit forced to zero, when the packet *leaves* the domain. I think that does give enough entropy for flow-label based ECMP to operate well *outside* the domain. The same would apply to server load-balancing (RFC7098).
However, as far as I can see, this technique definitely creates problems for a site that relies internally on ECMP or server load-balancing.

  Brian 

>> 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-v6ops-ipv6-alt-mark-00.txt
>>
>>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 28 Feb 2018 16:25:06 -0800

On Tue, Feb 27, 2018 at 12:50 AM, Van De Velde, Gunter (Nokia -
> The motivation that triggered this work is the passive measurement of MBH traffic in a pure IPv6 underlay environment. This is area where specialized HW (name your preferred network device vendor)…

I'm not sure a standard Internet protocol could be based on
assumptions that only specialized HW is used, or that all devices
support a feature that has not been standardized (i.e. applying a mask
to flow label for ECMP).

> Yes, it is an important operational consideration, to document that the application domain of this draft, if not done so yet.
Another question I have concerns this purported benefit:

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

The "significant on-the-wire tax" is at least something like 64 bytes
(IP hdr + SR header + 1 SID)! The passive measurement requires a grand
total of two bits and is always used in conjunction with SR AFAICT.
Wouldn't it be easier to just put these two bits somewhere in the
segment routing EH instead of redefining a standard field in IPv6
header with sematics that have long been applied in deployment?

Tom