Subject: draft-fz-6man-ipv6-alt-mark next steps

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 27 Apr 2020 10:46:54 +0000

Dear All,
We would like to update you about the status of draft-fz-6man-ipv6-alt-mark, considering the comments received during the 6MAN interim meeting.

After some offline discussions with 6MAN chairs and Magnus Westerlund as TSV AD, we agree to revise the draft and describe in detail how the alternate marking method can work for IPv6, in order to move RFC 8321 from normative to informative reference and lighten the dependency on RFC8321 that is Experimental. This approach makes sense since we are defining a new generalized data field designed for the deployment of the method, indeed a new field (FlowMonID) is introduced and is not previously defined in RFC 8321.

The decision about the intended status of the draft still needs to be resolved. We consider the Alternate Marking Method a mature technology and there are already a couple of applications in Standards Track (i.e. https://datatracker.ietf.org/doc/draft-ietf-bier-pmmm-oam/ and https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-sfl/). For this reason we would keep this document Standards Track as well.

We are working on the new version that will be published soon.

We would really appreciate hearing your thoughts and inputs, so that we can include them in the revision that is work in progress.

Best Regards,

Giuseppe and Tianran

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 27 Apr 2020 15:46:50 +0000

Giuseppe,

It does make sense indeed the re-arrange the references (and hence the dependencies).

Like expressed at the virtual meeting, I have some concerns with the use of hop-by-hop options extension header as it usually requires the packets with HbH to be processed on the slow path and in 2020, I am afraid that many routers will simply ignore/skip the HbH.

-éric

From: ipv6 <[email-masked]> on behalf of Giuseppe Fioccola <[email-masked]>
Date: Monday, 27 April 2020 at 12:47
To: 6man WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: draft-fz-6man-ipv6-alt-mark next steps

Dear All,

Best Regards,

Giuseppe and Tianran

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2020 08:56:32 -0700

> Like expressed at the virtual meeting, I have some concerns with the use of hop-by-hop options extension header as it usually requires the packets with HbH to be processed on the slow path and in 2…

Eric,

RFC8200 allows routers to skip HBH extension headers, so it is no
longer a requirement that intermediate nodes process HBH. There might
still be some routers that drop packets with HBH, however in this
particular case the protocol is likely deployed in a limited domain so
any problems can be addressed in that context (as opposed to trying to
fix all the routers across the whole Internet).

Tom

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 27 Apr 2020 15:58:59 +0000

Tom

I do not disagree ;-) as your statement complements my previous one

-éric

-----Original Message-----
From: Tom Herbert <[email-masked]>
Date: Monday, 27 April 2020 at 17:57
To: Eric Vyncke <[email-masked]>
Cc: Giuseppe Fioccola <[email-masked]>, 6man WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-fz-6man-ipv6-alt-mark next steps

    Eric,

    Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2020 09:00:48 -0700

Eric,

Do you see a problem if routers ignore Alt Mark HBH?

Tom

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 27 Apr 2020 16:09:26 +0000

Not at all but I wanted to make sure that authors are aware that adding AltMrk in a HbH option on a router will also require line cards / ASIC / NPU / ... able to selectively process HbH headers ;-)

This is all my (minor) point ;-)

-éric

-----Original Message-----
From: Tom Herbert <[email-masked]>
Date: Monday, 27 April 2020 at 18:02
To: Eric Vyncke <[email-masked]>
Cc: Giuseppe Fioccola <[email-masked]>, 6man WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-fz-6man-ipv6-alt-mark next steps

    Eric,

    Tom

---

From: Giuseppe Fioccola <[email-masked]>
Date: Mon, 27 Apr 2020 16:45:25 +0000

Hi Eric,
Thank you for the feedback.
I agree on the hop-by-hop options and we already made some consideration within the draft. Maybe I can highlight more the drawbacks of HBH in order to address your comment.
The good thing is that, if some routers skip or ignore Alt Mark HBH, the measurement is not undermined since it can be done for the remaining routers that support it.
AltMark can also be encoded as destination option, but in some cases the end-to-end measurement is not enough and HBH gives more information.

Regards,

Giuseppe

-----Original Message-----
From: Eric Vyncke (evyncke) [mailto:[email-masked]] 
Sent: Monday, April 27, 2020 6:09 PM
To: Tom Herbert <[email-masked]>
Cc: Giuseppe Fioccola <[email-masked]>; 6man WG <[email-masked]>; [email-masked]
Subject: Re: draft-fz-6man-ipv6-alt-mark next steps

-éric

-----Original Message-----
From: Tom Herbert <[email-masked]>
Date: Monday, 27 April 2020 at 18:02
To: Eric Vyncke <[email-masked]>
Cc: Giuseppe Fioccola <[email-masked]>, 6man WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: draft-fz-6man-ipv6-alt-mark next steps

    Eric,

    Tom

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 27 Apr 2020 18:58:33 +0000

Giuseppe

Agreed that the HbH is not a blocking point but let's indeed ensure that the I-D documents the potential issues.

Regards

-éric

-----Original Message-----
From: Giuseppe Fioccola <[email-masked]>
Date: Monday, 27 April 2020 at 18:46
To: Eric Vyncke <[email-masked]>, Tom Herbert <[email-masked]>
Cc: 6man WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: draft-fz-6man-ipv6-alt-mark next steps

    Hi Eric,

    Regards,

    Giuseppe

    -----Original Message-----
    From: Eric Vyncke (evyncke) [mailto:[email-masked]] 
    Sent: Monday, April 27, 2020 6:09 PM
    To: Tom Herbert <[email-masked]>
    Cc: Giuseppe Fioccola <[email-masked]>; 6man WG <[email-masked]>; [email-masked]
    Subject: Re: draft-fz-6man-ipv6-alt-mark next steps

    -éric

    -----Original Message-----
    From: Tom Herbert <[email-masked]>
    Date: Monday, 27 April 2020 at 18:02
    To: Eric Vyncke <[email-masked]>
    Cc: Giuseppe Fioccola <[email-masked]>, 6man WG <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: draft-fz-6man-ipv6-alt-mark next steps

        Eric,

        Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2020 12:45:06 -0700

Eric,

I'm not sure this is needed. Any potential issues have more to do with
EH in general as opposed to specific problems with this use case. If
we need to mention such issues here, then it seems we would need to
mention them in every specification that defines a HBH option. For
instance, draft-ietf-6man-mtu-option-02 doesn't mention these issues.
It does, however, make some useful statements about use cases and
interoperability that might be appropriate text for this draft:

"This Hop-by-Hop option is intended to be used in environments like
Data Centers and on paths between Data Centers, to allow them to
better take advantage of paths able to support a large Path MTU.  The
method could also be useful in other environments, including the
general Internet."

and

"The Hop-by-Hop Option defined in this document is designed to take
advantage of this property of how Hop-by-Hop options are processed.
Nodes that do not support this Option SHOULD ignore them.  This can
mean that the value returned in the response message does not account
for all links along a path."

Tom

The Hop-by-Hop Option defined in this document is designed to take
   advantage of this property of how Hop-by-Hop options are processed.
   Nodes that do not support this Option SHOULD ignore them.  This can
   mean that the value returned in the response message does not account
   for all links along a path.

---

From: [email-masked]
Date: Mon, 27 Apr 2020 21:53:00 +0200

> AltMark can also be encoded as destination option, but in some cases the end-to-end measurement is not enough and HBH gives more information.

Indeed. _If_ you want to signal to routers on the path that should process the alt mark, then HBH is the option to use.
Using a different option for that purpose, would require routers to have to parse further into the header chain.

Regardless of the existing HBH or a new option with HBH properties, you need to expect that some routers will not process it unless explicitly configured. And that the packet drop probability is higher with the option than without.

Cheers,
Ole

---

From: Tom Herbert <[email-masked]>
Date: Mon, 27 Apr 2020 13:01:03 -0700

> Indeed. _If_ you want to signal to routers on the path that should process the alt mark, then HBH is the option to use.

+1

The draft also calls the decision to use extension headers the
preferred choice as opposed to flow label and IPv6 addresses. I would
say this is not only the preferred choice, but the only correct and
robust choice that could actually be standardized .

Tom

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 28 Apr 2020 14:59:03 +0000

Hi Ole, Tom,
Thanks a lot for your useful comments.
We will surely include your inputs in the revision that is work in progress.

In particular, I agree, the use of extension headers is the best choice that could actually be standardized and HBH is also useful to signal to routers on the path to process the alt mark, anyway it is to be expected that some routers cannot process it unless explicitly configured.

In addition, I think the reference text from draft-ietf-6man-mtu-option-02 is relevant and we can write a similar paragraph also in the alt-mark draft:
"The Hop-by-Hop Option defined in this document is designed to take advantage of the property of how Hop-by-Hop options are processed.
Nodes that do not support this Option SHOULD ignore them.  This can mean that the performance measurement does not account for all links and nodes along a path."

Regards,

Giuseppe

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, April 27, 2020 10:01 PM
To: Ole Troan <[email-masked]>
Cc: Giuseppe Fioccola <[email-masked]>; Eric Vyncke (evyncke) <[email-masked]>; 6man WG <[email-masked]>; [email-masked]
Subject: Re: draft-fz-6man-ipv6-alt-mark next steps

+1

The draft also calls the decision to use extension headers the preferred choice as opposed to flow label and IPv6 addresses. I would say this is not only the preferred choice, but the only correct and robust choice that could actually be standardized .

Tom

> > Not at all but I wanted to make sure that authors are aware that 
> > adding AltMrk in a HbH option on a router will also require line 
> > cards / ASIC / NPU / ... able to selectively process HbH headers ;-)
> >
> > Cc: Giuseppe Fioccola <[email-masked]>, 6man WG 
> > <[email-masked]>, "[email-masked]" <[email-masked]>
> >> Cc: Giuseppe Fioccola <[email-masked]>, 6man WG 
> >> <[email-masked]>, "[email-masked]" <[email-masked]>
> >>> ------------------------------------------------------------------
> >>> -- IETF IPv6 working group mailing list [email-masked] 
> >>> Administrative Requests: 
> >>> https://www.ietf.org/mailman/listinfo/ipv6
> > IETF IPv6 working group mailing list [email-masked] Administrative 
> > Requests: https://www.ietf.org/mailman/listinfo/ipv6