Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

From: Bob Hinden <[email-masked]>
Date: Sun, 20 Dec 2020 11:10:43 -0800

This message starts a new three week 6MAN Working Group Last Call on advancing:

       Title           : IPv6 Application of the Alternate Marking Method
       Authors         : Giuseppe Fioccola
                         Tianran Zhou
                         Mauro Cociglio
                         Fengwei Qin
                         Ran Pang
	Filename        : draft-ietf-6man-ipv6-alt-mark-02.txt
	Pages           : 15
	Date            : 2020-10-13

as a Proposed Standard.  We normally do two week last calls, but given the holidays, we think three weeks is appropriate.

Substantive comments and statements of support for publishing this document should be directed to the [email-masked] mailing list.  Editorial suggestions can be sent to the authors.  This last call will end on 10 January 2021.

Thanks,
Bob & Ole

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-02.txt
> Date: October 13, 2020 at 7:10:42 AM PDT
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Maintenance WG of the IETF.
> 
>        Title           : IPv6 Application of the Alternate Marking Method
>        Authors         : Giuseppe Fioccola
>                          Tianran Zhou
>                          Mauro Cociglio
>                          Fengwei Qin
>                          Ran Pang
> 	Filename        : draft-ietf-6man-ipv6-alt-mark-02.txt
> 	Pages           : 15
> 	Date            : 2020-10-13
> 
> Abstract:
>   This document describes how the Alternate Marking Method can be used
>   as the passive performance measurement tool in an IPv6 domain and
>   reports implementation considerations.  It proposes how to define a
>   new Extension Header Option to encode alternate marking technique and
>   both Hop-by-Hop Options Header and Destination Options Header are
>   considered.
> 
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6man-ipv6-alt-mark-02
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-02
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-02
> 
> 
> 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.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Dec 2020 11:28:37 +1300

Issues:
-------

> 2.  Alternate Marking application to IPv6
...
>       Anyway this does not impact the
>       traffic since the measurement can be done only for the nodes
>       configured to read the Option.

I'm not sure what this means. Does it mean this?:

     This does not affect throughput on nodes that do not recognize
     the option.

But is that true, because of the issues with HbH processing that
motivated draft-hinden-6man-hbh-processing? Isn't it possible that
this option will force packets onto the "slow path" even in
nodes that do not recognize it? The later discussion in section 4
"Use of the AltMark Option" does not mention this.

>    An important point that will also be discussed in this document is
>    the the uniqueness of the FlowMonID and how to allow disambiguation
>    of the FlowMonID in case of collision.  [RFC6437] states that the
>    Flow Label cannot be considered alone to avoid ambiguity since it
>    could be accidentally or intentionally changed en route for
>    compelling operational security reasons and this could also happen to
>    the IP addresses that can change due to NAT.  But the Alternate
>    Marking is usually applied in a controlled domain, which would not
>    have NAT and there is no security issue that would necessitate
>    rewriting Flow Labels.  So, for the purposes of this document, both
>    IP addresses and Flow Label should not change in flight and, in some
>    cases, they could be considered together with the FlowMonID for
>    disambiguation.

I think this is a very important point that should probably have its
own sub-section 2.1 "Controlled Domain". It answers the question of
whether this new option is deployable: yes, in a controlled domain.
(That's why this draft is referenced in RFC8799.)

> 4.  Use of the AltMark Option
...
>    In summary, it is possible to list the alternative possibilities:
> 
>    o  Destination Option => measurement only by node in Destination
>       Address.
> 
>    o  Hop-by-Hop Option => every router on the path with feature
>       enabled.
> 
>    o  Destination Option + any Routing Header => every destination node
>       in the route list.

While looking at the 3rd bullet here, I noticed an inconsistency in
RFC8200. Section 4.4. of RFC8200 says:

>>>    The Routing header is used by an IPv6 source to list one or more
>>>    intermediate nodes to be "visited" on the way to a packet's
>>>    destination.

So "destination" clearly means the final destination, not the
intermediate nodes in the source route. But section 4.1 of RFC8200
("Extension Header Order") says:

>>>    note 1: for options to be processed by the first destination that
>>>            appears in the IPv6 Destination Address field plus
>>>            subsequent destinations listed in the Routing header.

To avoid ambiguity, I think the first and third bullets in the
above list should be modified:

   o  Destination Option not preceding a Routing Header => measurement
      only by node in Destination Address.

   o  Hop-by-Hop Option => every router on the path with feature
      enabled.

   o  Destination Option preceding a Routing Header => every destination
      node in the route list.

> 5.3.1.  Uniqueness of FlowMonID

This section would be more helpful if it discussed the importance of
a low rate of ambiguous IDs on the usefulness of the measurements.
Does it really matter if the measurements for 2 flows are confounded
0.1% of the time? Would this cause significant harm to the operator
or their clients? Is this harm important enough to justify the
complications of avoiding it?

(For ECMP/LAG, RFC6438 page 6 states that rare collisions for the
flow label are acceptable, but your case may be different.)

Nits:
-----

>    In consequence to the previous document and to the discussion within
>    the community, it is possible to state that the only correct and
>    robust choice that can actually be standardized would be the use of a
>    new TLV to be encoded in the Options Header (Hop-by-Hop or
>    Destination Option).

That sentence is best described as "baroque". I suggest something much
simpler, such as:

Consquently, a robust choice is to standardize a new Hop-by-Hop or
Destination Option.

>    Note that the FlowMonID is different from the Flow Label field of the
>    IPv6 Header ([RFC8200]).  Flow Label is used for application service,
>    like load-balancing/equal cost multi-path (LB/ECMP) and QoS.

"Application service" really doesn't describe ECMP or LAG which are
traffic engineering mechanisms, and I'm not aware of any real application
of the flow label that could be described as QoS management. 

>  Flow Label cannot be considered alone to avoid ambiguity since it
>  could be accidentally or intentionally changed en route...

The other reason is that since the flow label is pseudo-random, there
is always a finite probability of collision. (Although as noted above,
for load balancing, statistically rare ambiguity is OK.)

> 4.  Use of the AltMark Option...
>    ... In this way an unrecognized Hop-by-
>    Hop Option may be just ignored without impacting the traffic.

This duplicates the earlier text about "traffic". Delete?

There are many minor syntax errors; here are a couple of examples
chosen at random:

> The Alternate Marking Method has become mature to be implemented...

> [I-D.fioccola-v6ops-ipv6-alt-mark] reported a summary on the possible...

So there is quite a bit of work for the RFC Editor.

Regards
   Brian Carpenter

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 22 Dec 2020 10:37:30 +0000

Hi Brian,
Thanks a lot for your detailed revision.
Please find my replies inline with [GF].

Regards,

Giuseppe 

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter
Sent: Monday, December 21, 2020 11:29 PM
To: 6man <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Re: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Issues:
-------

...

But is that true, because of the issues with HbH processing that motivated draft-hinden-6man-hbh-processing? Isn't it possible that this option will force packets onto the "slow path" even in nodes that do not recognize it? The later discussion in section 4 "Use of the AltMark Option" does not mention this.

[GF]: Yes, it is possible. The three high-order bits of the Options Header defined in this draft are 000 and, in theory, as per RFC8200 and draft-hinden-6man-hbh-processing, this means "skip if do not recognize and data do not change en route". RFC8200 also mentions that the nodes only examine and process the HbH Options header if explicitly configured to do so. For these reasons, this HbH Option should not affect the throughput. Anyway, in practice, we are fully aware that the things may be different and it can happen that packets with HbH are forced onto the slow path, and this is a general issue. In the next revision we can include something more on that, even in section 4.

>    cases, they could be considered together with the FlowMonID for

I think this is a very important point that should probably have its own sub-section 2.1 "Controlled Domain". It answers the question of whether this new option is deployable: yes, in a controlled domain.
(That's why this draft is referenced in RFC8799.)

[GF]: Agree, we can define a new subsection here to highlight the concept. I would also add the reference to RFC8799.

...

>>>            subsequent destinations listed in the Routing header.

To avoid ambiguity, I think the first and third bullets in the above list should be modified:

[GF]: Good suggestion. The wording you propose is more complete and avoids ambiguity. I will replace the bullets in the next revision of the draft.

> 5.3.1.  Uniqueness of FlowMonID

This section would be more helpful if it discussed the importance of a low rate of ambiguous IDs on the usefulness of the measurements.
Does it really matter if the measurements for 2 flows are confounded 0.1% of the time? Would this cause significant harm to the operator or their clients? Is this harm important enough to justify the complications of avoiding it?

(For ECMP/LAG, RFC6438 page 6 states that rare collisions for the flow label are acceptable, but your case may be different.)

[GF]: Yes, in this section we can introduce that the uniqueness of FlowMonID may not be a problem in some cases. But, for large scale measurements where it is possible to monitor a big number of flows, the disambiguation of the Flow Monitoring Identification field is something to take into account.

Nits:
-----

>    new TLV to be encoded in the Options Header (Hop-by-Hop or

That sentence is best described as "baroque". I suggest something much simpler, such as:

Consquently, a robust choice is to standardize a new Hop-by-Hop or Destination Option.

[GF]: Ok, I will replace the sentence.

>    like load-balancing/equal cost multi-path (LB/ECMP) and QoS.

"Application service" really doesn't describe ECMP or LAG which are traffic engineering mechanisms, and I'm not aware of any real application of the flow label that could be described as QoS management. 

[GF]: I see, Iet me reword this sentence and leave only LB and ECMP.

> could be accidentally or intentionally changed en route...

The other reason is that since the flow label is pseudo-random, there is always a finite probability of collision. (Although as noted above, for load balancing, statistically rare ambiguity is OK.)

[GF]: Good point. I will also add this argument in the next version.

[GF]: Yes

Regards
   Brian Carpenter

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

---

From: Cociglio Mauro <[email-masked]>
Date: Tue, 22 Dec 2020 12:09:14 +0000

Hi all,
I support the adoption as co-author.
Best regards.
Mauro Cociglio
_____________________
Mauro Cociglio
TIM - CT.TIS.IPT
Via G. Reiss Romoli, 274
10148 - Torino (Italy)
Tel.: +390112285028
Mobile: +393357669751
_____________________

TIM - Uso Interno - Tutti i diritti riservati.

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Sunday, December 20, 2020 8:11 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Thanks,
Bob & Ole

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

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: Cociglio Mauro <[email-masked]>
Date: Tue, 22 Dec 2020 15:13:49 +0000

Hi all,
I support the publication as co-author.
Best regards.
Mauro Cociglio
_____________________
Mauro Cociglio
TIM - CT.TIS.IPT
Via G. Reiss Romoli, 274
10148 - Torino (Italy)
Tel.: +390112285028
Mobile: +393357669751
_____________________

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Sunday, December 20, 2020 8:11 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Thanks,
Bob & Ole

---

From: Riccardo Sisto <[email-masked]>
Date: Tue, 22 Dec 2020 16:22:52 +0100

Hi all,
I support publication.
Best regards,

Riccardo Sisto

-- 
========================================================
Riccardo Sisto
Politecnico di Torino - Dip. di Automatica e Informatica
Corso Duca degli Abruzzi, 24 - I-10129 Torino - ITALY
Phone: +39 011 090 7073 - Fax: +39 011 090 7099
e-mail: [email-masked]
web: http://staff.polito.it/riccardo.sisto
========================================================

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Sunday, December 20, 2020 8:11 PM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

as a Proposed Standard.  We normally do two week last calls, but given the 
holidays, we think three weeks is appropriate.

Substantive comments and statements of support for publishing this document 
should be directed to the [email-masked] mailing list.  Editorial suggestions 
can be sent to the authors.  This last call will end on 10 January 2021.

Thanks,
Bob & Ole

---

From: Haoyu Song <[email-masked]>
Date: Tue, 22 Dec 2020 17:52:30 +0000

I support the publication. Thanks!

Haoyu

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Bob Hinden
Sent: Sunday, December 20, 2020 11:11 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Thanks,
Bob & Ole

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-6man-ipv6-alt-mark%2F&amp;data=04%
> 7C01%7Chaoyu.song%40futurewei.com%7Cdb0c42d15daa416d002708d8a51b04ef%7
> C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637440882812739982%7CUnkno
> wn%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C1000&amp;sdata=AdcGnM5GiMktG4e7POpg7LcWXRvruRxZ3UFlqiB
> iZIM%3D&amp;reserved=0
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-ietf-6man-ipv6-alt-mark-02&amp;data=04%7C01%
> 7Chaoyu.song%40futurewei.com%7Cdb0c42d15daa416d002708d8a51b04ef%7C0fee
> 8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637440882812739982%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> I6Mn0%3D%7C1000&amp;sdata=EOlKIi3840GFohok97ytPdbUy8setzCrJxlmP0845AE%
> 3D&amp;reserved=0
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-6man-ipv6-alt-mark-02&amp;d
> ata=04%7C01%7Chaoyu.song%40futurewei.com%7Cdb0c42d15daa416d002708d8a51
> b04ef%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637440882812749978%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ZqGSOhoy4VJRcENsoEoLaF52scQWlVO4
> T8hW9ArV4g8%3D&amp;reserved=0
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-6man-ipv6-alt-mark-02&amp;data=
> 04%7C01%7Chaoyu.song%40futurewei.com%7Cdb0c42d15daa416d002708d8a51b04e
> f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637440882812749978%7CUn
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6Pu470IGQQ1FyJxCsZA5g7%2F8j7ZJvVUdjm
> V3fLz9Grw%3D&amp;reserved=0
> 
> 
> https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ie
> tf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Chaoyu.song%40futurewei.
> com%7Cdb0c42d15daa416d002708d8a51b04ef%7C0fee8ff2a3b240189c753a1d5591f
> edc%7C1%7C0%7C637440882812749978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
> jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata
> =j1%2FJnuLZio%2B%2F06wkn6mnZrCgqEgpyxj1l8JtNfc5NFI%3D&amp;reserved=0
>

---

From: Ran Pang(联通集团中国联通研究院-本部) <[email-masked]>
Date: Wed, 23 Dec 2020 02:13:36 +0000

Hi all,

Best regards,
Pang Ran

From: Bob Hinden<mailto:[email-masked]>
Date: 2020-12-21 03:10
To: IPv6 List<mailto:[email-masked]>
CC: Bob Hinden<mailto:[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>
This message starts a new three week 6MAN Working Group Last Call on advancing:

Thanks,
Bob & Ole

> ftp://ftp.ietf.org/internet-drafts/
如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: "qinfengwei" <[email-masked]>
Date: Wed, 23 Dec 2020 10:25:21 +0800

I support the publication as a co-editor。

Thanks，
Fengwei Qin

-----邮件原件-----
发件人: ipv6 [mailto:[email-masked]] 代表 Bob Hinden
发送时间: 2020年12月21日 03:11
收件人: IPv6 List
抄送: Bob Hinden
主题: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

This message starts a new three week 6MAN Working Group Last Call on
advancing:

Thanks,
Bob & Ole

---

From: Gyan Mishra <[email-masked]>
Date: Tue, 22 Dec 2020 22:05:18 -0500

I support publication.

Thanks

Gyan

On Tue, Dec 22, 2020 at 12:52 PM Haoyu Song <[email-masked]>
wrote:

> Substantive comments and statements of support for publishing this
> document should be directed to the [email-masked] mailing list.  Editorial
> suggestions can be sent to the authors.  This last call will end on 10
> January 2021.
>
> Thanks,
> Bob & Ole
>
>
>
> > Begin forwarded message:
> >
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: "Xiejingrong (Jingrong)" <[email-masked]>
Date: Wed, 23 Dec 2020 03:30:00 +0000

I support the publishing of this document.

Thanks
Jingrong

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Monday, December 21, 2020 3:11 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Thanks,
Bob & Ole

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Wed, 23 Dec 2020 04:16:21 +0000

Hi,

I support the publication.

Thanks!

Best regards,
Shuping

发件人：Bob Hinden <[email-masked]>
收件人：IPv6 List <[email-masked]>
抄 送：Bob Hinden <[email-masked]>
时 间：2020-12-21 03:11:35
主 题：Working Group Last Call for

Substantive comments and statements of support for publishing this document should be directed to the [email-masked]<mailto:[email-masked]> mailing list. Editorial suggestions can be sent to the authors. This last call will end on 10 January 2021.

Thanks,
Bob & Ole

> Begin forwarded message:
>
> From: [email-masked]<mailto:[email-masked]>
> To: < [email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>
> Reply-To: [email-masked]<mailto:[email-masked]>
>
>

---

From: Guido Marchetto <[email-masked]>
Date: Wed, 23 Dec 2020 08:59:54 +0100

Dear all,

Best regards,
Guido Marchetto

========================================================
Guido Marchetto
Politecnico di Torino
Control and Computer Engineering Department
Corso Duca degli Abruzzi, 24 - 10129 Torino - ITALY
Phone: +39 011 090 7094 - Fax: +39 011 090 7099
e-mail: [email-masked]
========================================================

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 23 Dec 2020 17:41:02 -0800

Dear All,
I've read the draft and I support its publication.

I have a question related to the operation of a node that applies the
Alternate Marking to a flow. As I understand it, the marking node (let's
call it that) will add an IPv6 header with the Options Header that includes
the AltMark Option. Is my understanding correct? If it is, then there would
be an impact on the packet sizes for the monitored flow. Some packets with
the additional IPv6 header might exceed the MTU. Should that be noted in
the Security Considerations? Can it be mitigated?

Also, text can benefit from editorial updates. I can give it a try if the
authors like to send me a text copy.

Regards,
Greg

On Sun, Dec 20, 2020 at 11:11 AM Bob Hinden <[email-masked]> wrote:

> submission

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 24 Dec 2020 11:20:02 +0000

Hi Greg,
Thanks a lot for your support.
Regarding your question, your understanding is correct, Alternate Marking bits are carried by the Options Header and it may have some impact on the path MTU. We can surely mention this point in the Security Considerations. Anyway the relative small size (48 bit in total) of this HBH/DOH and its application to a controlled domain mitigate the problem.

Your help for the revision is appreciated. We will work on a new version after the WGLC and then I can send you a text copy.

Regards,

Giuseppe

From: ipv6 [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: Thursday, December 24, 2020 2:41 AM
To: Bob Hinden <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Dear All,

I have a question related to the operation of a node that applies the Alternate Marking to a flow. As I understand it, the marking node (let's call it that) will add an IPv6 header with the Options Header that includes the AltMark Option. Is my understanding correct? If it is, then there would be an impact on the packet sizes for the monitored flow. Some packets with the additional IPv6 header might exceed the MTU. Should that be noted in the Security Considerations? Can it be mitigated?

Also, text can benefit from editorial updates. I can give it a try if the authors like to send me a text copy.

Regards,
Greg

On Sun, Dec 20, 2020 at 11:11 AM Bob Hinden <[email-masked]<mailto:[email-masked]>> wrote:
This message starts a new three week 6MAN Working Group Last Call on advancing:

Thanks,
Bob & Ole

> To: <[email-masked]<mailto:[email-masked]>>
> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: stefano previdi <[email-masked]>
Date: Sun, 27 Dec 2020 22:27:54 +0100

Hi,

I support the publication of this document.

Thanks.
s.

> On Dec 20, 2020, at 8:10 PM, Bob Hinden <[email-masked]> wrote:
>

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Mon, 28 Dec 2020 01:50:19 +0000

Yes, I support. This extension is useful for performance measurement, hope to publish it ASAP.

Thanks,
Cheng

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Monday, December 21, 2020 3:11 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Thanks,
Bob & Ole

---

From: Lizhenbin <[email-masked]>
Date: Mon, 28 Dec 2020 07:33:56 +0000

Hi All,
Yes, I support the last call. 

Best Regards,
Zhenbin (Robin)

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
Sent: Monday, December 21, 2020 3:11 AM
To: IPv6 List <[email-masked]>
Cc: Bob Hinden <[email-masked]>
Subject: Working Group Last Call for <draft-ietf-6man-ipv6-alt-mark>

Thanks,
Bob & Ole