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

[Brian E Carpenter <[e-mail]>]

> 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
On 02/03/2018 06:28, Tom Herbert wrote:
> On Thu, Mar 1, 2018 at 9:10 AM, Fioccola Giuseppe
> <[e-mail]> wrote:
>> Hi Tom,
>> Thanks for your feedbacks!
>> My answers inline tagged as [GF].
>>
>> Giuseppe
>>
>> -----Messaggio originale-----
>> Da: v6ops [mailto:[e-mail]] Per conto di Tom Herbert
>> Inviato: giovedì 1 marzo 2018 01:25
>> A: Van De Velde, Gunter (Nokia - BE/Antwerp)
>> Cc: [e-mail] 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) <[e-mail]> 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.
>>
> 
> 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
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>