[mpls] Gunter Van de Velde's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)

Gunter Van de Velde via Datatracker <noreply@ietf.org> Wed, 04 September 2024 13:13 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from [10.244.2.118] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id 13196C180B77; Wed, 4 Sep 2024 06:13:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Gunter Van de Velde via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172545561773.1661558.9099729767144725332@dt-datatracker-68b7b78cf9-q8rsp>
Date: Wed, 04 Sep 2024 06:13:37 -0700
Message-ID-Hash: YBJZMFAZYILW5HQFUTJOTFL4BDEVJGR6
X-Message-ID-Hash: YBJZMFAZYILW5HQFUTJOTFL4BDEVJGR6
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-mpls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-mpls-inband-pm-encapsulation@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org, tsaad@cisco.com
X-Mailman-Version: 3.3.9rc4
Reply-To: Gunter Van de Velde <gunter.van_de_velde@nokia.com>
Subject: [mpls] Gunter Van de Velde's No Objection on draft-ietf-mpls-inband-pm-encapsulation-15: (with COMMENT)
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/b-NGZNNN7BUgYJ0dbOWS15j0ToQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Owner: <mailto:mpls-owner@ietf.org>
List-Post: <mailto:mpls@ietf.org>
List-Subscribe: <mailto:mpls-join@ietf.org>
List-Unsubscribe: <mailto:mpls-leave@ietf.org>

Gunter Van de Velde has entered the following ballot position for
draft-ietf-mpls-inband-pm-encapsulation-15: No Objection

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


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-inband-pm-encapsulation/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Gunter Van de Velde, RTG AD, comments for
draft-ietf-mpls-inband-pm-encapsulation-15

# Thanks for the Shepherd writeup from Tony Li, providing useful insight in the
origins of the document and the relationship with MNA.

#Thanks to Darren Dukes for the early RTGDIR review.

#GENERIC COMMENTS
#================
## I support the DISCUSS from John Scudder

## I was flipping between NoObjection and DISCUSS as there are items that to me
look serious enough to be discussed more in detail in the WG. However, the
existing DISCUSS items from fellow IESG area directors will most likely cause
that to happen anyway.

## I got confused with the text handling The Traffic Class (TC) and Time To
Live (TTL) fields of the XL and FLI where first the formal procedure is them to
equal and next to state they MAY be different?

## If there is formal requirement to set some fields to 0 or 1 with a MUST,
then exception procedures should be provided when a (transit) router receives
an mpls packet with potentially non-conforming fields set. Should the packet be
dropped? allowed? tagged? ICMP message created

## When inserting labels, then this impacts the packet IP MTU. This seems not
discussed?

## The exact definition of 'unique' is not defined in the document. Does unique
mean unique over  time? unique for any flow at any given time?  If a controller
reboots, will it have to harvest all used LFIs that are running in the
infrastructure?

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

84         [RFC9341] describes a performance measurement method, which can be
85         used to measure packet loss, delay, and jitter on data traffic.

[minor]
RFC9341 describes this as "live" traffic and not data traffic. I believe there
is a substantial difference between the two

"
   This document describes the Alternate-Marking technique to perform
   packet loss, delay, and jitter measurements on live traffic.
"

87         it is referred to as the Alternate-Marking Method.  [RFC8372]
88         discusses aspects to consider when developing a solution for MPLS
89         flow identification for performance monitoring of MPLS flows.

[minor]
RFC8372 says the following:

"
   This document discusses aspects to consider when developing a
   solution for MPLS flow identification.  The key application that
   needs this solution is in-band performance monitoring of MPLS flows
   when MPLS is used to encapsulate user data packets.
"

Hence the phrase construct is not 100% correct. Maybe the following should be
considered instead:

"
[RFC8372] outlines key considerations for developing a solution for MPLS flow
identification, intended for use in performance monitoring of MPLS flows. "

98         Note that in parallel to the work of this document, there is ongoing
99         work on MPLS Network Actions (MNA) [I-D.ietf-mpls-mna-fwk].
100        Considering the MPLS performance measurement with the Alternate-
101        Marking method can also be achieved by MNA encapsulation, it is
102        agreed that this document will be made Historic once the MNA solution
103        of performance measurement with the Alternate-Marking method is
104        published as an RFC.

[minor]
As other ADs suggested, this looks as an unusual statement.
What is the value of this section when the document is a proposed standard. Can
it not be simply a rfc editor note and remove it when becoming RFC? (this is a
non-blocking comment/observation)

196        The Traffic Class (TC) and Time To Live (TTL) fields of the XL and
197        FLI MUST use the same values of the label immediately preceding the
198        XL.  In this case the TC and TTL for the XL and FLI MAY be of
199        different values.

[major]
These two phrases seem to contradict each other. First sentence say they MUST
use same values and the second sentence suggest that they MAY be different. How
is exception handling when a receiver receives (first sentence) the where FLI
and XL and TC/TTL is not identical?

214        FL in a label stack.  The TTL for the FL MUST be zero to ensure that
215        it is not used inadvertently for forwarding.  The BoS bit for the FL
216        depends on whether the FL is placed at the bottom of the MPLS label
217        stack, i.e., the BoS bit for the FL is set only when the FL is placed
218        at the bottom of the MPLS label stack.

[minor]
What is the formal handling procedure when a receiver received (a transit node
or mpls recipient) a packet where the FL is NOT zero?

412        service and the MPLS transport would be generated.  In this case, the
413        transit node needs to look up both of the two Flow-IDs by default.

[minor]
"the" transit node? Not sure the exact meaning of "the" is in this context.
There may be many transit nodes that the flow traverses. Would in this context
using the word "a transit node" not be more technically correct?

418        Whether using the two methods mentioned above or other methods to
419        allocate Flow-ID, the NMS/controller MUST ensure that every generated
420        Flow-ID is unique within the administrative domain and MUST NOT have
421        any value in the reserved label space (0-15) [RFC3032].

[major]
I think that there should be understanding on what unique exactly means. for
example, if at time=1 there is allocated FL=1234. next and time=2 the flow no
longer exists. And at time=3 for a new unrelated flow there is allocation of
FL=1234. Would that count as being unique?

What happens when the controller that allocated rebooted and lost all awareness
of allocated LFIs? can it create new, potentially non-unique (over time) LFIs?

438        the on-path nodes is outside the scope of this document.  However,
439        [I-D.xzc-lsr-mpls-flc-frld] provides a method to achieve this.

[minor]
The [I-D.xzc-lsr-mpls-flc-frld] document is not a WG accepted document. Is it
really your objective to have this current standards based document fateshare
with this not addopted informative reference?

451     7.  Equal-Cost Multipath Considerations

[minor]
Any concerns with mixing ELI/EL and FL? any impact between identifying flow and
the entropy caused by Entropy Labels?