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

From: Fioccola Giuseppe <[email-masked]>
Date: Thu, 1 Mar 2018 17:10:59 +0000

Hi Tom,
Thanks for your feedbacks!
My answers inline tagged as [GF].

Giuseppe

-----Messaggio originale-----
Da: v6ops [mailto:[email-masked]] Per conto di Tom Herbert
Inviato: giovedì 1 marzo 2018 01:25
A: Van De Velde, Gunter (Nokia - BE/Antwerp)
Cc: [email-masked] WG
Oggetto: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt

On Tue, Feb 27, 2018 at 12:50 AM, Van De Velde, Gunter (Nokia -
BE/Antwerp) <[email-masked]> wrote:
> 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.

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

[GF]: A mask to flow label for ECMP is only a possibility.

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

[GF]: I understand your point. For now it seems we focus only on SRv6 and flow label field but this is only an Use Case we considered as a consequence of our experiment (as described in RFC 8321). This new version of the draft does not give a unique solution but aims to analyze the several alternatives that can be taken into consideration for the choice of the marking field (Extension Header, IPv6 Address, Flow Label). Our intent is to understand, together with v6OPS WG, which is the better way to apply this technology to IPv6.

Tom

> 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
>
> On 27/02/2018 10:21, Tom Herbert wrote:
>> On Mon, Feb 26, 2018 at 7:24 AM, Van De Velde, Gunter (Nokia -
>> BE/Antwerp) <[email-masked]> wrote:
>>> 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.
>>>
>>
>> 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.
>
> 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
>
>>
>> Tom
>>
>>> 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
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>

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

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: Thu, 1 Mar 2018 09:28:09 -0800

> [GF]: I understand your point. For now it seems we focus only on SRv6 and flow label field but this is only an Use Case we considered as a consequence of our experiment (as described in RFC 8321).…

Okay, then I think you may want to add a couple of alternatives to the draft:

1) Adding a field to an existing proposed EH (e.g. SRv6) instead of
defining a new EH.
2) Using a field from an extensible encapsulation, such as GUE, to
carry the passive measurement bits. This technique was discussed at
length in nvo3.

The intended status should also be informational I would think.

Thanks,
Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Mar 2018 08:27:51 +1300

> The intended status should also be informational I would think.

Yes, that seems right to me - it's a description of possible practice
that is sort-of compatible with the existing standard if carefully
deployed.

Actual standardisation of bits in the IPv6 header belongs in 6MAN,
but remembering the heavy lifting involved in the present flow label
standard, IMHO this would be hard to achieve.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Thu, 1 Mar 2018 15:52:40 -0800

> The intended status should also be informational I would think.

Or Experimental, given that RFC 8321 that this appears to be based on is Experimental.

Also, this should only reference RFC8200, not RFC8200 and RFC2460.  The latter was obsoleted by RFC8200.

Thanks,
Bob

---

From: Fioccola Giuseppe <[email-masked]>
Date: Tue, 6 Mar 2018 10:25:22 +0000

Thank you for the suggestions,
I keep notes of these comments and will wait for further comments in London.
A new revision could be published after the IETF meeting.

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: Bob Hinden [mailto:[email-masked]] 
Inviato: venerdì 2 marzo 2018 00:53
A: Tom Herbert
Cc: Bob Hinden; Fioccola Giuseppe; [email-masked] WG; Van De Velde, Gunter (Nokia - BE/Antwerp)
Oggetto: Re: [v6ops] FW: New Version Notification for draft-fioccola-v6ops-ipv6-alt-mark-00.txt

Thanks,
Bob