[ippm] Re: WG Last Call: draft-ietf-ippm-alt-mark-deployme nt-05 (Ends 2026-05-28)

--===============0816573714287194514==
Content-Language: en-GB
Content-Type: multipart/alternative;
 boundary="_000_DB9PR07MB77716D1514EE1A8E055CFD74D6162DB9PR07MB7771eurp_"

--_000_DB9PR07MB77716D1514EE1A8E055CFD74D6162DB9PR07MB7771eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Marcus,


My main comment on the deployment draft is the language around controlled d=
omain.


Also, an early sentence says =93The Alternate Marking Method MUST be deploy=
ed in a controlled domain for security and compatibility reasons.=94  I thi=
nk you mean =93MUST only=94, else every controlled domain MUST have alt-mar=
k deployed(!).  But also, I don't see these security reasons defined anywhe=
re.  There=92s a pointer to the security test in RFC8799, but that=92s rath=
er vague, and also doesn=92t state the reasons.


The networks I work with are the set of global R&E networks. It=92s quite p=
ossible that endpoints or elements in those networks may wish to use alt-ma=
rk, and use it over multiple administrative domains.  In those cases, the n=
etworks are not a controlled domain as such. We peer and carry R&E traffic =
in R&E networks and to/from commercial networks.  We don=92t generally act =
as transit between commercial networks.  But there=92s strong collaboration=
.  If you take the example of diffserv, we don=92t rewrite DSCP fields, whi=
ch I would consider not dissimilar to alt-mark, at the very least for the I=
Pv6 EH case.  We=92d not set up some IPsec path for a specific data movemen=
t just to use alt-mark.  SO it would be nice to recognise the R&E world and=
 not prescribe things that we=92d simply not do.


For IPv6, which is a use case I=92d expect to see, as we=92re already using=
 IPv6 EHs and the flow label for traffic marking, then the question comes t=
o whether the EHs are carried across domain boundaries, but that=92s very m=
uch an IPv6-specific question and the subject of much debate in the 6man an=
d v6ops WGs.


Tim

On 29/05/2026, 08:13, "Marcus Ihlar" <[email protected]=
etf.org> wrote:

Thanks to all who have contributed, while we do see good support we also go=
t some substantive reviews.
In addition, we have requested an early ops-dir review, with a deadline set=
 to Friday, June 5.
We will extend the last call for this duration, so more reviews are welcome=
.

BR
Marcus on behalf of IPPM/BMWG chairs

-----Original Message-----
From: Marcus Ihlar via Datatracker <[email protected]>
Sent: Thursday, 7 May 2026 12:03
To: [email protected]; [email protected]; ipp=
[email protected]; [email protected]; [email protected]
Subject: WG Last Call: draft-ietf-ippm-alt-mark-deployment-05 (Ends 2026-05=
-28)

This message starts a WG Last Call for:
draft-ietf-ippm-alt-mark-deployment-05

This Working Group Last Call ends on 2026-05-28

Please note that this WGLC runs in parallel with a last call for draft-ietf=
-ippm-alt-mark-yang with the intention of progressing both documents at the=
 same time.

Abstract:
   This document provides a framework for Alternate Marking deployment
   and includes considerations and guidance for the deployment of the
   methodology.

File can be retrieved from:

Please review and indicate your support or objection to proceed with the pu=
blication of this document by replying to this email keeping [email protected] =
in copy. Objections should be explained and suggestions to resolve them are=
 highly appreciated.

Authors, and WG participants in general, are reminded of the Intellectual P=
roperty Rights (IPR) disclosure obligations described in BCP 79 [1].
Appropriate IPR disclosures required for full conformance with the provisio=
ns of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.
Sanctions available for application to violators of IETF IPR Policy can be =
found at [3].

Thank you.

[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-deployment/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-deployment-0=
5

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-alt-mark-deploy=
ment-05
_______________________________________________
ippm mailing list -- [email protected]
To unsubscribe send an email to [email protected]

--_000_DB9PR07MB77716D1514EE1A8E055CFD74D6162DB9PR07MB7771eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<p style=3D"direction: ltr; line-height: normal; margin: 0px;"><span style=
=3D"font-family: Arial; font-size: 12pt; color: rgb(0, 0, 0);">Hi Marcus,</=
span></p>
<p style=3D"line-height: normal; margin: 0px; min-height: 18px;"><span styl=
e=3D"font-family: Arial; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></p>
<p style=3D"line-height: normal; margin: 0px;"><span style=3D"font-family: =
Arial; font-size: 12pt; color: rgb(0, 0, 0);">My main comment on the deploy=
ment draft is the language around controlled domain.</span></p>
<p style=3D"line-height: normal; margin: 0px; min-height: 18px;"><span styl=
e=3D"font-family: Arial; font-size: 12pt; color: rgb(0, 0, 0);"><br>
</span></p>
<p style=3D"line-height: normal; margin: 0px;"><span style=3D"font-family: =
Arial; font-size: 16px;">Also, an early sentence says =93The Alternate Mark=
ing Method MUST be deployed in a controlled domain for security and compati=
bility reasons.</span><span style=3D"font-family: Arial;">=94</span><span s=
tyle=3D"font-family: Arial; font-size: 16px;">&nbsp;
 I think you mean =93MUST only=94, else every controlled domain MUST have a=
lt-mark deployed(!). &nbsp;But also, I don't see these security reasons def=
ined anywhere. &nbsp;There=92s a pointer to the security test in RFC8799, b=
ut that=92s rather vague, and also doesn=92t state the
 reasons.</span></p>
<p style=3D"line-height: normal; margin: 0px;"><span style=3D"font-family: =
Arial; font-size: 16px;"><br>
</span></p>
<p style=3D"line-height: normal; margin: 0px; min-height: 18px;"><span styl=
e=3D"font-family: Arial; font-size: 16px;">The networks I work with are the=
 set of global R&amp;E networks. It</span><span style=3D"font-family: Arial=
;">=92s quite possible that endpoints or elements
 in those networks may wish to use alt-mark, and use it over multiple admin=
istrative domains. &nbsp;In those cases, the networks are not a controlled =
domain as such. We peer and carry R&amp;E traffic in R&amp;E networks and t=
o/from commercial networks. &nbsp;We don=92t generally
 act as transit between commercial networks. &nbsp;But there=92s strong col=
laboration. &nbsp;If you take the example of diffserv, we don=92t rewrite D=
SCP fields, which I would consider not dissimilar to alt-mark, at the very =
least for the IPv6 EH case. &nbsp;We=92d not set up some
 IPsec path for a specific data movement just to use alt-mark. &nbsp;SO it =
would be nice to recognise the R&amp;E world and not prescribe things that =
we=92d simply not do.</span></p>
<p style=3D"line-height: normal; margin: 0px; min-height: 18px;"><span styl=
e=3D"font-family: Arial; font-size: 16px;"><br>
</span></p>
<p style=3D"line-height: normal; margin: 0px; min-height: 18px;"><span styl=
e=3D"font-family: Arial;">For IPv6, which is a use case I=92d expect to see=
, as we=92re already using IPv6 EHs and the flow label for traffic marking,=
 then the question comes to whether the
 EHs are carried across domain boundaries, but that=92s very much an IPv6-s=
pecific question and the subject of much debate in the 6man and v6ops WGs.<=
/span></p>
<p style=3D"line-height: normal; margin: 0px; min-height: 18px;"><span styl=
e=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; col=
or: rgb(0, 0, 0);"><br>
</span></p>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
Tim</div>
<div style=3D"direction: ltr; font-family: Aptos, Arial, Helvetica, sans-se=
rif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div id=3D"mail-editor-reference-message-container">
<div class=3D"ms-outlook-mobile-reference-message skipProofing">
<meta name=3D"Generator" content=3D"Microsoft Exchange Server">
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing">On 29/05/20=
26, 08:13, &quot;Marcus Ihlar&quot; &lt;marcus.ihlar=3D40ericsson.com@dmarc=
.ietf.org&gt; wrote:</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing"><br>
</div>
<div class=3D"PlainText" style=3D"font-size: 11pt;">Thanks to all who have =
contributed, while we do see good support we also got some substantive revi=
ews.<br>
In addition, we have requested an early ops-dir review, with a deadline set=
 to Friday, June 5.<br>
We will extend the last call for this duration, so more reviews are welcome=
.<br>
<br>
BR<br>
Marcus on behalf of IPPM/BMWG chairs<br>
<br>
-----Original Message-----<br>
From: Marcus Ihlar via Datatracker &lt;[email protected]&gt;<br>
Sent: Thursday, 7 May 2026 12:03<br>
To: [email protected]; [email protected]; ipp=
[email protected]; [email protected]; [email protected]<br>
Subject: WG Last Call: draft-ietf-ippm-alt-mark-deployment-05 (Ends 2026-05=
-28)<br>
<br>
This message starts a WG Last Call for:<br>
draft-ietf-ippm-alt-mark-deployment-05<br>
<br>
This Working Group Last Call ends on 2026-05-28<br>
<br>
Please note that this WGLC runs in parallel with a last call for draft-ietf=
-ippm-alt-mark-yang with the intention of progressing both documents at the=
 same time.<br>
<br>
Abstract:<br>
&nbsp;&nbsp; This document provides a framework for Alternate Marking deplo=
yment<br>
&nbsp;&nbsp; and includes considerations and guidance for the deployment of=
 the<br>
&nbsp;&nbsp; methodology.<br>
<br>
File can be retrieved from:<br>
<br>
Please review and indicate your support or objection to proceed with the pu=
blication of this document by replying to this email keeping [email protected] =
in copy. Objections should be explained and suggestions to resolve them are=
 highly appreciated.<br>
<br>
Authors, and WG participants in general, are reminded of the Intellectual P=
roperty Rights (IPR) disclosure obligations described in BCP 79 [1].<br>
Appropriate IPR disclosures required for full conformance with the provisio=
ns of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any.<br>
Sanctions available for application to violators of IETF IPR Policy can be =
found at [3].<br>
<br>
Thank you.<br>
<br>
[1] <a href=3D"https://datatracker.ietf.org/doc/bcp78/" data-outlook-id=3D"=
9bb57b02-9aac-47f8-abc5-184e5bcfd782">
https://datatracker.ietf.org/doc/bcp78/</a><br>
[2] <a href=3D"https://datatracker.ietf.org/doc/bcp79/" data-outlook-id=3D"=
b2e4fe5d-a67d-4684-8db2-933c4502c268">
https://datatracker.ietf.org/doc/bcp79/</a><br>
[3] <a href=3D"https://datatracker.ietf.org/doc/rfc6701/" data-outlook-id=
=3D"260bd9e9-fbf8-494b-921a-a040db496fca">
https://datatracker.ietf.org/doc/rfc6701/</a><br>
<br>
The IETF datatracker status page for this Internet-Draft is:<br>
<a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-deploy=
ment/" data-outlook-id=3D"91601cc3-52ce-4474-9267-cec59e32edb0">https://dat=
atracker.ietf.org/doc/draft-ietf-ippm-alt-mark-deployment/</a><br>
<br>
There is also an HTMLized version available at:<br>
<a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-d=
eployment-05" data-outlook-id=3D"e8d65d47-767e-40e4-a021-164737a0c17f">http=
s://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-deployment-05</a=
><br>
<br>
A diff from the previous version is available at:<br>
<a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-alt-=
mark-deployment-05" data-outlook-id=3D"7d59f3a8-c74b-478c-9f64-14ec3a973a80=
">https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-alt-mark-depl=
oyment-05</a><br>
_______________________________________________<br>
ippm mailing list -- [email protected]<br>
To unsubscribe send an email to [email protected]<br>
</div>
</div>
</body>
</html>

--_000_DB9PR07MB77716D1514EE1A8E055CFD74D6162DB9PR07MB7771eurp_--


--===============0816573714287194514==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaXBwbSBtYWls
aW5nIGxpc3QgLS0gaXBwbUBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IGlwcG0tbGVhdmVAaWV0Zi5vcmcK

--===============0816573714287194514==--