Subject: Re: draft-fioccola-v6ops-ipv6-alt-mark-00 and RFC7837

From: Fred Baker <[email-masked]>
Date: Wed, 4 Apr 2018 18:58:15 -0700

Catching up now that I'm home.

Punting to the process path is an implementation question. There are a number of implementations that do, a number of implementations that ignore unrecognized HBH options, probably some that drop packets containing unrecognized HBH options (not that it is recommended, but I'll bet someone does it), and in the future one could imagine implementations that handle it in hardware.

I wouldn't make broad assumptions.

> On Mar 28, 2018, at 1:38 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> May i assume the following assumption for the intended measurement use-case:
>   On the router there should be no difference regarding forwarding behavior
>   when a packet is either 'marked' or 'not market'? It is assumed that the router does
>   never fallback to slow path when a marking is present.
> 
> This brings me to the following: Does placement of ALTERNATE MARKING in a new IPv6 HbH extension header not punt those packets to CPU for local processing?
> 
> G/
> 
> -----Original Message-----
> From: Fioccola Giuseppe [mailto:[email-masked]]
> Sent: Wednesday, March 28, 2018 10:27
> To: Fred Baker <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: R: draft-fioccola-v6ops-ipv6-alt-mark-00 and RFC7837
> 
> Hi Fred,
> You are right! It would be best to allow the performance measurement both end to end and hop by hop.
> Probably we have to extend the Destination Options to Hop-by-Hop Options field.
> Thanks,
> 
> Giuseppe,
> 
> -----Messaggio originale-----
> Da: Fred Baker [mailto:[email-masked]]
> Inviato: martedì 27 marzo 2018 19:17
> A: Fioccola Giuseppe
> Cc: [email-masked]; [email-masked]
> Oggetto: Re: draft-fioccola-v6ops-ipv6-alt-mark-00 and RFC7837
> 
> A characteristic of the Destination Options field is that it is interpreted by a system designated by the destination address. In a unicast scenario, there is obviously only one of those; in an anycast scenario, it might apply to a variety of systems, each with different routing. Is that a characteristic of your use case? I understood you to be measuring to a system that the traffic passed through, but not identifying the system in the destination address.
> 
>> On Mar 22, 2018, at 10:33 AM, Fioccola Giuseppe <[email-masked]> wrote:
>> 
>> Hi All,
>> After the discussion about the bits from the flow label field, the authors would consider a new alternative.
>> RFC 7837 specifies an IPv6 destination option capable of carrying Congestion Exposure markings. We could redefine this RFC, that is experimental, and use 2 bits from the Reserved field to encode the alternate marking method for an HBH option.
>> We would like to ask your opinion.
>> 
>> Thanks,
>> 
>> Giuseppe
>> 
>> 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.
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 4 Apr 2018 23:06:24 -0400

<AD Hat Off>

> On Apr 4, 2018, at 9:58 PM, Fred Baker <[email-masked]> wrote:
> 

+1.  I would like to point to an alternate document (working draft only) where we explored the various alternatives for the conex markings before we settled on the “least evil” (as Tim eloquently put it) one 

https://tools.ietf.org/html/draft-krishnan-conex-ipv6-02

I am guessing a similar exercise could be done for draft-fioccola- to see what the potential alternatives and the associated compromises are.

Thanks
Suresh

---

From: Fioccola Giuseppe <[email-masked]>
Date: Thu, 5 Apr 2018 15:43:40 +0000

Hi Suresh,
Thank you for the suggestion!
A similar structure with the Requirements for alternate marking IPv6 packets and possible Solutions can be very effective for our draft.

Best Regards,

Giuseppe

-----Messaggio originale-----
Da: Suresh Krishnan [mailto:[email-masked]] 
Inviato: giovedì 5 aprile 2018 05:06
A: Fred Baker; Van De Velde, Gunter (Nokia - BE/Antwerp)
Cc: [email-masked]; [email-masked]
Oggetto: Re: draft-fioccola-v6ops-ipv6-alt-mark-00 and RFC7837

<AD Hat Off>

Thanks
Suresh