[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?
- [mpls] Gunter Van de Velde's No Objection on draf… Gunter Van de Velde via Datatracker
- [mpls] Re: Gunter Van de Velde's No Objection on … xiao.min2
- [mpls] Re: Gunter Van de Velde's No Objection on … Gunter van de Velde (Nokia)
- [mpls] Re: Gunter Van de Velde's No Objection on … xiao.min2
- [mpls] Re: Gunter Van de Velde's No Objection on … Gunter van de Velde (Nokia)
- [mpls] Re: Gunter Van de Velde's No Objection on … xiao.min2
- [mpls] Re: Gunter Van de Velde's No Objection on … Gunter van de Velde (Nokia)