Received: from mail-pj2-x0f.google.com (mail-pj2-x0f.google.com [IPv6:2607:f8b0:4864:39::f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by mx.ietf.org (Postfix) with ESMTPS id E688346 for ; Tue, 15 Sep 2026 23:36:22 +0000 (UTC) Authentication-Results: mx.ietf.org; dkim=pass header.d=gmail.com header.s=20251104 header.b=WmqKo2dZ; dmarc=none; spf=pass (mx.ietf.org: domain of tony1athome@gmail.com designates 2607:f8b0:4864:39::f as permitted sender) smtp.mailfrom=tony1athome@gmail.com Received: by mail-pj2-x0f.google.com with SMTP id 98e67ed59e1d1-396ccb652d7so277281a91.0 for ; Tue, 15 Sep 2026 16:36:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1789515382; x=1790120182; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:sender:from:to:cc:subject:date:message-id:reply-to :content-type; bh=p+AKX3QowsNFzxSFBm+SFW1mwmmoADe68V77H0/sgvM=; b=WmqKo2dZoIeZA3VKehjGo8543vkGNL4ju+gty8ZrPUhw2N8Y483JoVT5r8hoBw4p1T ZJ3n96WAH5XmkNN4f6PbzooM1mAX5rM4W5yxZ3CDFY+uPpxYnUzOzgG7/djrIjm/fSQc mG0tul6/iN43bSaBMKUhf7VeJ1HHnoh/f1hOjn3aGjZMkkntrchLB/rX/IgO/enqtaaJ u6U7AsJMLmOjAvygDDKT/MZqODu0N7It/+6CqBVjmWilfznFrQx6LMPQgLNKDarA04oF 2Xy/z4QY1CINLJtfYsk9aESeOLPf+PTKH+0PWdrOcqtNnDk2zv2W/0mTDJdjyQ7G8FbO n9Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789515382; x=1790120182; h=references:to:cc:in-reply-to:date:subject:mime-version:content-type :message-id:from:sender:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=p+AKX3QowsNFzxSFBm+SFW1mwmmoADe68V77H0/sgvM=; b=YDlzuVFYEACDo2zuCgOoDGKEdGTADUGecKEIiTpm6OZlBN6nI2l6ibsK/lpeyKXXKN JrWT/NHlZe/w1NuQW9IN8rXptRiqVe2GAx2u4mRnvoB5aeAkia4dtJ0u5Sk0p51uQZDF y0t5LmqZMiOHJT7OILNDqr7lqR0drb0CgL7Jv+RF0h0N63dhX+Ndny3HE5iUTZ+Z0tdW sRwkly5gEEo5rQrF4MdpYDa5sGmdWE8oe78ZmC18uJco35ADpjAdOG9lJJMeSLXjlqSk OdKIbO4Um0ZlQ9CUyDm2cEMQdujiWvjIQU6t8KyFn0GvSBmV8w5dBsvxBhgxwsKVjboD 6saA== X-Gm-Message-State: AFuF++lYEUfX0SEfDVuM3NZWg/VWYtQIVe+rM4hi+Itn+TK0iJWRzkyL Bi8hTXqzdmJKab3Wd5gwkIY+443OVioLP6Nl66NUVmsK+7t278JeB7IA X-Gm-Gg: AYBFou3e0k5TEF2TsGSOZIAcv4PbJtzDKJNdVrHzbQ0DmQK0BNdGX3ZQf8ew0PSG4Wo f6v0tFth4PTw1/WxYkG7SA5Sil75wYtfscoJve9Nw4XnhMfG675SrjnRrYiJyVRnihoMX3kyPQy weL0cHA8J90YhpzBf9U40iX0AOHIVZPT54mLwNy4cEvKINkNVPSJXxXWymImXi2nSD8GEFtJU4s AgiucNg3/JD6xyrxZ5v852uicne8er9NZTVhkyyCiOYbXr0kVPb0V+HnUQj6ItrMZ6gwCu+gNGD X6Z/qQ8WAJZSEnmnpWB/KU+Vcz8kIAfqcilPVwAZFWHUXEInkfd7gUFPRydnE/aCJJnwfRATKCG zW9Fp1x4osf6DbVtx0xieASl7qr9ZR/zet4/UFtWc6zSP/ltC6sbj4D5D87Uo1s23MCgJExre6Y Q1M9LOGwldIidA87orRikxsyUqZqSHU8GaUXPKfAceeTyV4ZbLmrFQgs1V8pGXn+9dLYDadLgA0 QQREEeAraIZ3Ge+nSxdNpgWB3nKzIU2ecjE00dyL8EGsBc0 X-Received: by 2002:a17:90b:2252:b0:39d:ec42:df69 with SMTP id 98e67ed59e1d1-39e1e4d3ff4mr1016008a91.20.1789515381399; Tue, 15 Sep 2026 16:36:21 -0700 (PDT) Received: from smtpclient.apple (c-73-93-167-4.hsd1.ca.comcast.net. [73.93.167.4]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-33bf5af4f0bsm2629150eec.24.2026.09.15.16.36.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Sep 2026 16:36:20 -0700 (PDT) Sender: Tony Li From: Tony Li Message-Id: <6CFB6581-5616-4EFF-B3B7-B00654E090E4@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_37097E93-5A71-4971-B26D-5A3F63204D56" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.700.51.1.1\)) Date: Tue, 15 Sep 2026 16:36:09 -0700 In-Reply-To: To: bruno.decraene@orange.com References: X-Mailer: Apple Mail (2.3864.700.51.1.1) X-Spamd-Bar: / Message-ID-Hash: JWDFQSAYMLJTZKQLP2TDCVIZ36PSJBNM X-Message-ID-Hash: JWDFQSAYMLJTZKQLP2TDCVIZ36PSJBNM X-MailFrom: tony1athome@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-mpls.ietf.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: mpls , "draft-ietf-mpls-on-path-telemetry-flag@ietf.org" , "rtg-dir@ietf.org" X-Mailman-Version: 3.3.10 Precedence: list Subject: [mpls] Re: draft-ietf-mpls-on-path-telemetry-flag early Rtgdir review List-Id: Multi-Protocol Label Switching WG Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_37097E93-5A71-4971-B26D-5A3F63204D56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Bruno, This draft has now passed WGLC and is ready for publication. Have all = of your issues been addressed satisfactorily in -03? Thanks, Tony > On Aug 5, 2026, at 8:22=E2=80=AFAM, bruno.decraene@orange.com wrote: >=20 > Document: draft-ietf-mpls-on-path-telemetry-flag-02 > Title: MPLS On-Path Telemetry Network Action Flag for OAM > Reviewer: Bruno Decraene > Review result: Has Issues > =20 > Hello, > =20 > I have been approached (but not formally selected due to = misunderstanding on my side) to do a routing directorate =E2=80=9Cearly=E2= =80=9D review of this draft. > = https://www.ietf.org/archive/id/draft-ietf-mpls-on-path-telemetry-flag-02.= html > Having reviewed the draft, I=E2=80=99m sending the comments regardless = of the formal selection. > =20 > The routing directorate will, on request from the working group chair, = perform > an =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted = for publication to the > IESG. The early review can be performed at any time during the = draft=E2=80=99s lifetime > as a working group document. > =20 > Document: draft-ietf-mpls-on-path-telemetry-flag-02 > Reviewer: Bruno Decraene > Review date: 2026-08-05 > =20 > =20 > Summary > ------- > In general, the draft is clear and readable. Thank you. > I have some comments, including a few major ones, that I think should = be addressed before proceeding. > =20 > Major: > ------- > =C2=A77 > "This document requests IANA to allocate one bit position (TBA1, = suggested value 42)" > Draft should not indicate a suggested value. cf = https://datatracker.ietf.org/doc/html/rfc8126#section-3 > This looks very close to squatting code points, which leads to interop = issues. Please remove. > --- > =20 > =C2=A74.1 > "The P-flag is therefore placed at Bit Position 42" > This is codepoint squatting. > Please remove from the spec (until IANA has allocated a code point) > =20 > --- > =C2=A74.3 > This section essentially states that the data correlation is = unreliable. > I don't think that this is good enough for important networks. > (At minimum, this should be discussed in the operation consideration = section.) > =20 > --- > The document does not specify the interaction with MSD. > =20 > RFC 9491 says [MSD] "advertisements allow entities (e.g., centralized = controllers) to determine whether a particular Segment ID (SID) stack = can be supported in a given network." > https://datatracker.ietf.org/doc/html/rfc8491 > =20 > This document adds 3 LSE to the label stack. In some platforms, this = may reduce the MSD usable by SR-MPLS. MUST such node decrement their = MSD signaling (by 3) to allow controller to perform correct computation? > Such impact should probably be discussed in the ops consideration = section, as 3 may be relatively significant for some platform. > =20 > Minor: > ------- > =C2=A72 > "1: PBT-M avoids augmenting user packets with new headers " > Well, draft seems to do exactly that (augmenting user packet with a = new header). You may want to rephrase. (e.g. "large header") > -- > =20 > "3: PBT-M can avoid interfering with the normal forwarding." > pushing the MPLS MNA header seems to interfere with normal forwarding = (by reducing the available MSD on the Head Node, and the RLD on all = transit nodes) > -- > =20 > "4: For PBT-M, the types of data collected from each node can vary = depending on application requirements and node capability." > I would assume that this would be true even without PBT-M, otherwise = this would seem difficult to deploy. > -- > =20 > =C2=A73 > "Req. 1 (Packet Marking Bit): A user packet needs to be marked to = trigger the path-associated data collection. Since PBT-M aims to avoid = the need to augment user packets with new headers, it needs to reserve = or reuse a single bit from the existing header fields." > Do you mean an existing header field in a specification or in the = customer packet? > The former would still augment user packer. The latter would restrict = the usage to MPLS packets already carrying MNA. > Please clarify. > -- > =20 > "Req. 4 (Overhead and Security): Since each postcard packet has its = header, the overall network bandwidth overhead of PBT-M can be high. A = large number of postcards could add processing pressure on data = collecting servers. That can be used as an attack vector for DoS." > =20 > Also it add processing pressure on all transit nodes sending a = postcard. (which are likely more limited than a server) > --- > =C2=A74.1 > "Format D (labeled D) carries the P-flag." > =20 > The P-flag has never been defined/introduced as this point. May be = :s/P-flag/PBT-M indicator > --- > =20 > "If the bit is set to '1', a node is triggered to collect and export = the telemetry data as configured by the control plane." > =20 > Since this flag is essentially the main part of the specification, = could you please specify what "a node" is? > =20 > (in particular, according to Figure 1, this seems to include the Head = Node, which does not seem completely obvious) > =20 > --- > =C2=A74.3 > " Once this is done, the TTL (or the timestamp, if the network time is = synchronized) can be used to infer the flow forwarding path." > In the general case, the MPLS packet carries a label _stack_. > - The TTL may be set differently in each LSE. > - And even if not, since only the TTL of the top label is decremented, = TTL will be different across LSE. > =20 > Hence this does not seem to work as written. (e.g., after a POP, the = TTL on the top LSE is likely to _increase_) > You may want to expand, e.g., by specifying the use of all TTL of all = LSEs. > --- > =20 > "The first possible approach includes the flow ID in the OAM packets. = In case of MPLS, the MPLS label stack can serve as the flow ID." > I don't think that this is reliable enough. An MPLS LSP typically = aggregates a very large number of flows, so is not good enough to = identify a flow. > =20 > "If the packet marking interval is large enough, the flow ID is enough = to identify a user packet." > Probably the "interval between two successive packet marking = operation". > Again, I disagree that this is enough and reliable enough. If you = stand with your statement, please provides data, the math and the = resulting probabilities of collisions. > =20 > "As a result, it can be assumed that all the exported postcard packets = for the same flow during a short time interval belong to the same user = packet." > No, it cannot. This seems overly simplified. We need deterministic = behavior, and networks/spec which works all the time. Especially for a = troubleshooting tool. > =20 > "Alternatively, if the network is synchronized, then the flow ID plus = the timestamp at each node can also infer the postcard affiliation." > What do you mean by "synchronized"? How much precision? Does the = format of the timestamp account for different timezone? > =20 > "In many cases, such a rare error has no catastrophic consequence. = Therefore it is tolerable." > Says who? This seems like a personal opinion. I, for one, do not share = it. I don't think that this is good enough for an IETF spec. > Care to elaborate for the other cases which have catastrophic = consequences? > =20 > ---- > =C2=A74.4 Load Control > "PBT-M should not be applied to all the packets all the time." > So 99% works fine?? > It seems to me that the sentence should be much more conservative. = e.g., "PBT-M MUST be applied to a very small subset of packets." > =20 > Again, could be discussed in the ops consideration section. > =20 > "The RECOMMENDED default marks no more than 1 in 1000 packets (0.1%) = of any single flow, which keeps the added postcard traffic within = roughly 0.1% of the monitored flow rate." > =20 > This may be seen as still a significant number for some platforms. I = wish we had the same performance for IS-IS flooding, especially given = its importance relative for postcard. > I'd like to see a discussion and recommendation for reduced impact on = the router. e.g., I would not want IS-IS flooding performance be reduced = by postcard generation. > =20 > Also, the math for the monitored flow rate is not much detailed. It = seems to rely on assumptions such as the size of customer packets, the = size of the postcard, the number of nodes in transit (N nodes generates = N packets for a single customer packet)... Could you please detail your = assumptions and math? Especially since I expect a network operator to = re-evaluate the numbers based on its own deployment) > =20 > --- > "Marked packets in excess of these limits are forwarded normally but = do not trigger a postcard." > probably :s/are/MUST be > --- > =20 > "The postcard packets can be distributed to different collectors to = balance the processing load." > Section 4.3 seems to say that correlation is already hard/unreliable = with a single collector. Introducing multiple collectors would probably = significantly increase the difficulty and section 4.3 would need to be = updated to reflect this. > =20 > ---- > "Because PBT-M sends telemetry data by dedicated postcard packets, it = allows data aggregation and compression." > not being familiar with postcard, it's not clear to me what type of = data aggregation and compression you are referring to. > A priori, the proposal seems to be willing to track a packet on all = transit nodes. I'm not sure to see what aggregation one may do. > At minimum, please elaborate on which node is doing the data = aggregation: collector or transit node? > ----- > =C2=A76 Security Considerations > =20 > "Only the ingress node is allowed to set these flag bits." > =20 > You do mean "MPLS ingress node", not "LSP ingress" do you? > If so, I'm not seeing this restriction in the specification. And this = seems to significantly reduce its usage. > --- > =20 > "The other on-path nodes can only react to the bit values. " > What do you mean by "can only"? > It seems to me that any node could modify the flag en route. > If you don't want this to happen, you need measures to avoid this. = (e.g., cryptographic signature). Since this specification do not propose = any measure to propose any tampering of the flag, I find the sentence = misleading. Especially in a security consideration section. > --- > =20 > "Therefore, security measures MUST be taken to ensure the proper = functioning of these actions." > Right. Which are those security measures? And how effective are they? > This is the kind of discussion I would expect in a security = consideration section. > Especially for a specification which indicates that it can be used as = an attack vector for DoS. > =20 > --- > "Specifically, ingress filtering and the default rate-limiting posture = MUST be applied" > What do you mean by the former? > Please elaborate on the later (which postures, on which nodes). Any = existing reference to this posture? Otherwise, please specify those in = the body of this specification. > =20 > = __________________________________________________________________________= __________________________________ > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. --Apple-Mail=_37097E93-5A71-4971-B26D-5A3F63204D56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi = Bruno,

This draft has now passed WGLC and is ready = for publication.  Have all of your issues been addressed = satisfactorily in = -03?

Thanks,
Tony

<= div>
On Aug 5, 2026, at = 8:22=E2=80=AFAM, bruno.decraene@orange.com wrote:

Document: = draft-ietf-mpls-on-path-telemetry-flag-02
Title: MPLS On-Path Telemetry Network = Action Flag for OAM
Reviewer: Bruno Decraene
Review result: Has = Issues
 
Hello,
 
I= have been approached (but not formally selected due to misunderstanding = on my side) to do a routing directorate =E2=80=9Cearly=E2=80=9D review = of this draft.
Having reviewed the draft, I=E2=80=99m sending the = comments regardless of the formal selection.
 
The routing directorate will, on = request from the working group chair, = perform
an = =E2=80=9Cearly=E2=80=9D review of a draft before it is submitted for = publication to the
IESG. The early review can be performed at any time = during the draft=E2=80=99s lifetime
as a working group = document.
 
Document: = draft-ietf-mpls-on-path-telemetry-flag-02
Reviewer: Bruno = Decraene
Review = date: 2026-08-05
 
 
Summary
-------
In = general, the draft is clear and readable. Thank = you.
I have some = comments, including a few major ones, that I think should be addressed = before proceeding.
 
Major:
-------
=C2=A77
"This document requests IANA to allocate one bit position = (TBA1, suggested value 42)"
Draft should not indicate a suggested value. cf https://datatracker.ietf.org/doc/html/rfc8126#section-3
This looks very close to squatting code points, which = leads to interop issues. Please remove.
---
 
=C2=A74.1
"The P-flag is therefore placed at Bit = Position 42"
This is codepoint squatting.
Please remove from the spec (until = IANA has allocated a code point)
 
---
=C2=A74.3
This section essentially states that = the data correlation is unreliable.
I don't think that this is good enough = for important networks.
(At minimum, this should be discussed in the operation = consideration section.)
 
---
The= document does not specify the interaction with = MSD.
 
RFC= 9491 says [MSD] "advertisements allow entities (e.g., centralized = controllers) to determine whether a particular Segment ID (SID) stack = can be supported in a given network."
 
This document adds 3 LSE to the label stack. In some = platforms, this may reduce the MSD usable by SR-MPLS.  MUST such = node decrement their MSD signaling (by 3) to allow controller to perform = correct computation?
Such impact should probably be discussed in the ops = consideration section, as 3 may be relatively significant for some = platform.
 
Minor:
-------
=C2=A72
"1:= PBT-M avoids augmenting user packets with new headers = "
Well, draft seems = to do exactly that (augmenting user packet with a new header). You may = want to rephrase. (e.g. "large header")
--
 
"3: PBT-M can avoid interfering with = the normal forwarding."
pushing the MPLS MNA header seems to interfere with = normal forwarding (by reducing the available MSD on the Head Node, and = the RLD on all transit nodes)
--
 
"4:= For PBT-M, the types of data collected from each node can vary = depending on application requirements and node = capability."
I = would assume that this would be true even without PBT-M, otherwise this = would seem difficult to deploy.
--
 
=C2=A73
"Req. 1 (Packet Marking Bit): A user = packet needs to be marked to trigger the path-associated data = collection. Since PBT-M aims to avoid the need to augment user packets = with new headers, it needs to reserve or reuse a single bit from the = existing header fields."
Do you mean an existing header field in a specification = or in the customer packet?
The former would still augment user packer. The latter = would restrict the usage to MPLS packets already carrying = MNA.
Please = clarify.
--
 
"Req. 4 (Overhead and Security): Since each postcard = packet has its header, the overall network bandwidth overhead of PBT-M = can be high. A large number of postcards could add processing pressure = on data collecting servers. That can be used as an attack vector for = DoS."
 
Also it add processing pressure on all transit nodes = sending a postcard. (which are likely more limited than a = server)
---
=C2=A74.1
"Format D (labeled D) carries the = P-flag."
 
The= P-flag has never been defined/introduced as this point. May be = :s/P-flag/PBT-M indicator
---
 
"If= the bit is set to '1', a node is triggered to collect and export the = telemetry data as configured by the control = plane."
 
Since this flag is essentially the main part of the = specification, could you please specify what "a node" = is?
 
(in= particular, according to Figure 1, this seems to include the Head Node, = which does not seem completely obvious)
 
---
=C2=A74.3
" Once this is done, the TTL (or the = timestamp, if the network time is synchronized) can be used to infer the = flow forwarding path."
In = the general case, the MPLS packet carries a label = _stack_.
- The TTL = may be set differently in each LSE.
- And even if not, since only the TTL = of the top label is decremented, TTL will be different across = LSE.
 
Hence this does not seem to work as written. (e.g., after = a POP, the TTL on the top LSE is likely to = _increase_)
You= may want to expand, e.g., by specifying the use of all TTL of all = LSEs.
---
 
"The first possible approach includes the flow ID in the = OAM packets. In case of MPLS, the MPLS label stack can serve as the flow = ID."
I don't think that = this is reliable enough. An MPLS LSP typically aggregates a very large = number of flows, so is not good enough to identify a = flow.
 
"If= the packet marking interval is large enough, the flow ID is enough to = identify a user packet."
Probably the "interval between two successive packet = marking operation".
Again, I disagree that this is enough and reliable = enough. If you stand with your statement, please provides data, the math = and the resulting probabilities of = collisions.
 
"As= a result, it can be assumed that all the exported postcard packets for = the same flow during a short time interval belong to the same user = packet."
No, it = cannot. This seems overly simplified. We need deterministic behavior, = and networks/spec which works all the time. Especially for a = troubleshooting tool.
 
"Alternatively, if the network is synchronized, then the = flow ID plus the timestamp at each node can also infer the postcard = affiliation."
What do you mean by "synchronized"? How much precision? = Does the format of the timestamp account for different = timezone?
 
"In= many cases, such a rare error has no catastrophic consequence. = Therefore it is tolerable."
Says who? This seems like a personal opinion. I, for one, = do not share it. I don't think that this is good enough for an IETF = spec.
Care to elaborate = for the other cases which have catastrophic = consequences?
 
----
=C2=A74.4 Load Control
"PBT-M should not be applied to all = the packets all the time."
So 99% works fine??
It seems to me that the sentence = should be much more conservative. e.g., "PBT-M MUST be applied to a very = small subset of packets."
 
Again, could be discussed in the ops consideration = section.
 
"The RECOMMENDED default marks no more than 1 in 1000 = packets (0.1%) of any single flow, which keeps the added postcard = traffic within roughly 0.1% of the monitored flow = rate."
 
This may be seen as still a significant number for some = platforms. I wish we had the same performance for IS-IS flooding, = especially given its importance relative for = postcard.
I'd like to = see a discussion and recommendation for reduced impact on the router. = e.g., I would not want IS-IS flooding performance be reduced by postcard = generation.
 
Also, the math for the monitored flow rate is not much = detailed. It seems to rely on assumptions such as the size of customer = packets, the size of the postcard, the number of nodes in transit (N = nodes generates N packets for a single customer packet)... Could you = please detail your assumptions and math? Especially since I expect a = network operator to re-evaluate the numbers based on its own = deployment)
 
---
"Marked packets in excess of these limits are forwarded = normally but do not trigger a postcard."
probably :s/are/MUST = be
---
 
"The postcard packets can be distributed to different = collectors to balance the processing load."
Section 4.3 seems to say that = correlation is already hard/unreliable with a single collector. = Introducing multiple collectors would probably significantly increase = the difficulty and section 4.3 would need to be updated to reflect = this.
 
----
"Because PBT-M sends telemetry data by dedicated postcard = packets, it allows data aggregation and = compression."
not= being familiar with postcard, it's not clear to me what type of data = aggregation and compression you are referring = to.
A priori, the = proposal seems to be willing to track a packet on all transit nodes. I'm = not sure to see what aggregation one may do.
At minimum, please elaborate on which = node is doing the data aggregation: collector or transit = node?
-----
=C2=A76  Security = Considerations
 
"Only the ingress node is allowed to set these flag = bits."
 
You= do mean "MPLS ingress node", not "LSP ingress" do = you?
If so, I'm not = seeing this restriction in the specification. And this seems to = significantly reduce its usage.
---
 
"The other on-path nodes can only = react to the bit values. "
What do you mean by "can = only"?
It seems to = me that any node could modify the flag en = route.
If you don't = want this to happen, you need measures to avoid this. (e.g., = cryptographic signature). Since this specification do not propose any = measure to propose any tampering of the flag, I find the sentence = misleading. Especially in a security consideration = section.
---
 
"Therefore, security measures MUST be taken to ensure the = proper functioning of these actions."
Right. Which are those security = measures? And how effective are they?
This is the kind of discussion I would = expect in a security consideration section.
Especially for a specification which = indicates that it can be used as an attack vector for = DoS.
 
---
"Specifically, ingress filtering and the default = rate-limiting posture MUST be applied"
What do you mean by the = former?
Please = elaborate on the later (which postures, on which nodes). Any existing = reference to this posture? Otherwise, please specify those in the body = of this specification.
 
________________________________________________________=
____________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez =
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages =
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme =
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged =
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and =
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

= --Apple-Mail=_37097E93-5A71-4971-B26D-5A3F63204D56--