Sender: Tony Li <tony1athome@gmail.com>
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\))
From: Tony Li <tony.li@tony.li>
In-Reply-To: 
 <172501904944.250685.15035516054798308423@dt-datatracker-68b7b78cf9-q8rsp>
Date: Fri, 30 Aug 2024 08:51:16 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <130354D3-1693-487B-82E5-D7FF6FD48616@tony.li>
References: 
 <172501904944.250685.15035516054798308423@dt-datatracker-68b7b78cf9-q8rsp>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Message-ID-Hash: XRYVZ4HPIKJQYBIS3CNQVNNDLQ43ZT6Y
CC: The IESG <iesg@ietf.org>,
 draft-ietf-mpls-inband-pm-encapsulation <draft-ietf-mpls-inband-pm-encapsulation@ietf.org>,
 mpls-chairs <mpls-chairs@ietf.org>, mpls <mpls@ietf.org>, tsaad@cisco.com
Precedence: list
Subject: =?utf-8?q?=5Bmpls=5D_Re=3A_=C3=89ric_Vyncke=27s_Abstain_on_draft-ietf-mpls-i?=
	=?utf-8?q?nband-pm-encapsulation-15=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/mpls/Z3EDKHWrt6UIa_Z4PF7cT7tPx5s>


Hi =C3=89ric,

I would like to respond to your non-technical point.  I will leave it to =
the authors to respond to your other issues.

Work on this draft predates the work on MNA by quite a bit. It has found =
interest with vendors and operators and has had multiple implementations =
that are now deployed in production. The proponents of the draft have =
correctly asked that we progress the draft as the work on the technology =
has converged. This is exactly what the IETF is supposed to do: =
standardize running code.

Work on MNA is still progressing, and no replacement for this =
functionality is currently documented, but it is quite clear that MNA is =
the direction that we would like to go in the longer term. After long =
discussions with all parties involved, we came to this agreement and =
recording it in the RFC itself seemed like the most appropriate =
mechanism to ensure that the agreement was on record and that the =
industry was aware of the direction that we are taking. This allows =
vendors and operators to plan accordingly. Technology evolves over time =
and it is helpful to the industry as a whole if we provide leadership =
and insight into future directions.

While I understand that this is an unusual situation, we are trying to =
ensure that we respect the interests of the IETF as a whole, vendors, =
and operators in this matter and craft a compromise that best suits all =
involved, both in the present and the future. This decision was not =
taken lightly but came about after extensive negotiations. We would =
respectfully ask that you not characterize this in terms that are =
suggestive of terrorism.

I apologize that there was not an adequate discussion of this in the =
shepherd=E2=80=99s writeup.

Regards,
Tony Li
MPLS co-chair


> On Aug 30, 2024, at 4:57=E2=80=AFAM, =C3=89ric Vyncke via Datatracker =
- noreply at ietf.org <mailforwards@cloudmails.net> wrote:
>=20
> =C3=89ric Vyncke has entered the following ballot position for
> draft-ietf-mpls-inband-pm-encapsulation-15: Abstain
>=20
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut =
this
> introductory paragraph, however.)
>=20
>=20
> Please refer to =
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-position=
s/=20
> for more information about how to handle DISCUSS and COMMENT =
positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> =
https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
>=20
> # =C3=89ric Vyncke, INT AD, comments for =
draft-ietf-mpls-inband-pm-encapsulation-15
>=20
> Thank you for the work put into this document. As this I-D is about =
very
> specific protocols, I have only reviewed it from the high level =
perspective.
>=20
> I am balloting ABSTAIN because I am neither comfortable nor confident =
that
> having a time bomb (see below about MNA) in a published RFC is =
sensible.
>=20
> Please find below some non-blocking COMMENT points (but replies would =
be
> appreciated even if only for my own education), and some nits.
>=20
> Special thanks to Tony Li for the shepherd's write-up even if more =
information
> about the 'time bomb' would have assisted my reading.
>=20
> I hope that this review helps to improve the document,
>=20
> Regards,
>=20
> -=C3=A9ric
>=20
> # COMMENTS (non-blocking)
>=20
> ## Having the time bomb...
>=20
> Both the shepherd's write-up and section 1 `it is agreed that this =
document
> will be made Historic` contain a trigger bomb to make this document =
historic.
> No explanations are given, so I guess that this was a WG compromise =
but without
> any further justification, it is hard to tell and hard to judge the =
IETF
> consensus.
>=20
> Why has the MPLS WG (and IETF Last Call and then the IESG) worked on =
this
> document if it was clear that it will become historic ?
>=20
> I am not convinced that `it is agreed` in an IETF RFC is meaningful.
>=20
> If the authors or the MPLS WG have a precedent case in a published =
RFC, then I
> will be happy to read it.
>=20
> ## Section 2.1
>=20
> Beyond acronyms expansions, some information references (e.g., for =
IPFIX or
> MNA), or some concise definitions (e.g., for eSPL or cSPL) would be =
useful for
> the readers.
>=20
> ## Section 3
>=20
> Possibly linked to my lack of MPLS expertise, I wonder why fields MUST =
be
> identical and MAY differ in `The Traffic Class (TC) and Time To Live =
(TTL)
> fields of the XL and FLI MUST use the same values of the label =
immediately
> preceding the XL. In this case the TC and TTL for the XL and FLI MAY =
be of
> different values. ` Should `In this case` be more specific ?
>=20
> What is the expected behavior when the TC/TTL are not using the same =
value ? Is
> this specified in other MPLS document or should it be specified in =
this I-D ?
>=20
> ## Section 4
>=20
> Also probably due to my own lack of expertise, how can a transit MPLS =
node know
> that it needs to do 'deep packet inspection' ?
>=20
> BTW, as 'deep packet inspection' is usually used in a security context =
to look
> in the application payload, may I suggest to use 'labels look-ahead' =
or
> something similar ?
>=20
> ## Section 7
>=20
> Please add a reference for `Synonymous Flow Label`.
>=20
> ## Section 8
>=20
> While I understand that it is not clean when packets with those labels =
leak
> outside the admin domain, what are the *actual security issues* ? =
E.g., DoS ?
> privacy ?
>=20
> # NITS (non-blocking / cosmetic)
>=20
> ## Section 3
>=20
> Rather than `as shown in figure below` please use the figure number.
>=20
>=20
>=20