From tony1athome@gmail.com Fri May 3 13:23:04 2024 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2F9C14F6A7; Fri, 3 May 2024 13:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMAA0SSxFrlS; Fri, 3 May 2024 13:22:59 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2CCCC14F60E; Fri, 3 May 2024 13:22:59 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1ec4b2400b6so388655ad.3; Fri, 03 May 2024 13:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714767779; x=1715372579; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:from:to:cc:subject:date:message-id:reply-to; bh=6sz+7UUEshlnp93621dlmK7sz6BhSpqc+eacX8P0N9Q=; b=bOm0QIkiJj/hYEqoToUae7uceEaZfkeSTAhThB3opqatYjWV6HG8ZbuPlwdCJolJZ1 K6Hk7OLWEMttHuR+ggRq4oFykeT28FsjwFQ8DLrOE6pWtxEhecx/U/vyUo/Akfh98rWN Ti3+KFoK9hea73+JywsE3fEQMPU1ja1pWn2RGHd/Lt5fXkTAkGU3kdlqZWj0L4WWSLkF hg0lJ1QioJRpguSOF2CjUAZ9kyNKy/hdM/41y+hu2cyCwP1cNVYB4RjEbNU77cs3AAtW XXWvGajnrgPCeHgJaLcTHb8qFn78MfffLmta/hCdWjaMQSoPEs3lpdBkY96j+K/IGUYg R19w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714767779; x=1715372579; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6sz+7UUEshlnp93621dlmK7sz6BhSpqc+eacX8P0N9Q=; b=vwMP5O/am81QWHsHpax69hd30eucDLakn43+Dvu156jTkOgjNT0yUL4uEgBmkHjyBf Mpghv/ccV3eL9yVacma+6o3QEiHXc2WkFySFWIrNvbJwa1VahEbEsRUgRKFzUPIilKb6 T+Sx/QVvGhVPdbLXg7m1igttiy/0u6H5NgVe/kLABzN7XCF1hdVr1oKe/VzJJj3EH3Dr cmJsB47C10NgjEzEiLllioLvY+P0U35OGNVSoGCbC9EtD54L8G1ehay85+0XGa29t2yK p4UjEoa6gE5btGRP1KePkVRn87tDOCjhFOqRL5KJcbVpUJ7niV+XrfPH6pZ6QswVqEny VDjg== X-Forwarded-Encrypted: i=1; AJvYcCXsdpgo8qI6tN0iacBpUgXNRkdIjSwwoZDRZ0aJVTvdPg3YjsLmfUC9M0/M8iMxozA2LYp6TGnWIcg9b+25rHAitdF1Ig== X-Gm-Message-State: AOJu0YxpAXp/ys2Peb1KgoYxrYP6pDL89IwNSuqhWy9oAkaRih0NZFyA qmwCVNlYWZXwlPu7BSRGXXDT62ZKxPnnYMrr/jnRLZElBU36muw1 X-Google-Smtp-Source: AGHT+IFW7VQ1CGJDK7SHFaQQVrf72JxDI4It7Jagh1wW2g1seXdJhiwbeXG8CBPsSFnag2KqBAAfig== X-Received: by 2002:a17:903:32c7:b0:1e6:7700:1698 with SMTP id i7-20020a17090332c700b001e677001698mr4968194plr.35.1714767778808; Fri, 03 May 2024 13:22:58 -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 e4-20020a170902d38400b001e3dff1e4d1sm3670137pld.268.2024.05.03.13.22.57 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 May 2024 13:22:58 -0700 (PDT) Sender: Tony Li From: Tony Li Message-Id: <05DFBE81-1A89-4E43-815A-8E168419E541@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_7F2CF824-AC71-4661-B48B-2F1D01256A6A" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.500.171.1.1\)) Date: Fri, 3 May 2024 13:22:47 -0700 In-Reply-To: Cc: mpls , mpls-chairs To: Greg Mirsky References: <2576EDD5-2D41-4635-AF38-7A63BD595154@tony.li> X-Mailer: Apple Mail (2.3774.500.171.1.1) Archived-At: Subject: Re: [mpls] WG last call: draft-ietf-mpls-inband-pm-encapsulation X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2024 20:23:04 -0000 --Apple-Mail=_7F2CF824-AC71-4661-B48B-2F1D01256A6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [WG chair hat: on] Hi Greg, Yes, existing implementations that are using an experimental code point = could continue to do so if the document were published as Experimental. = However, this would leave us in an awkward situation where an = experimental code point is effectively allocated to the protocol but not = documented in the registry. This seems sub-optimal. The whole point of = experimental code points is that they do not become permanent. I cannot speak to why there was no request for early allocation. Sorry, = I=E2=80=99m late ot the party here. If it was my proposal, I would have. Regards, Tony > On May 3, 2024, at 1:13=E2=80=AFPM, Greg Mirsky = wrote: >=20 > Hi Tony, > thank you for your prompt clarification of the eSPL value allocation. = I assume that the listed implementations, or some of them, are already = deployed. As I understand it, they all use some value as FLI, most = likely the same one across all the implementations. As you've pointed = out, using a value from the Unassigned or Reserved ranges of the = Extended Special-Purpose MPLS Label Values=C2=A0registry = would be squatting.=20 > About potential squatting (that, as I believe, should not be = encouraged). If I was considering an early implementation of this draft, = I'd use a value from the Experimental range (240-255). If that is the = case for this draft, moving it to the Experimental track, in my opinion, = is reasonable. On the other hand, if the implementers of earlier version = of the draft did use a value from Unassigned range without the early = allocation, why wouldn't they ask for allocation of that specific value = rather than letting IANA to pick one for them and be forced to change = their implementations in case the two values turned to be different? >=20 > Regards, > Greg >=20 > On Fri, May 3, 2024 at 1:00=E2=80=AFPM Tony Li > wrote: >>=20 >> [WG chair hat: on] >>=20 >> Hi Greg, >>=20 >> I will let the authors respond to the bulk of the comments here, but = I do want to address some process concerns. >>=20 >> Currently, the registry action for the 'Extended Special-Purpose MPLS = Label Values' registry is =E2=80=99Standards Action=E2=80=99. If this = document were to be published as Experimental, then it would not be = allowed to allocate a permanent code point, resulting in the = implementations squatting on a code point. This is sub-optimal. >>=20 >> It appears that there was no early allocation done for a code point, = so the squatting is already obviously occurring. Also sub-optimal. >>=20 >> First publishing as Standards Track and then shifting to Historical = allows for code point allocation. >>=20 >> Regards, >> Tony >>=20 >>=20 >>> On May 3, 2024, at 12:37=E2=80=AFPM, Greg Mirsky = > wrote: >>>=20 >>> Hi, Tony and All, >>> I've read the latest version of the draft. Please find my comments = below: >>> The proposed mechanism, as stated in Abstract, applies to "MPLS live = traffic". I couldn't find the definition of the term "live traffic" and = appreciate it if you can clarify it for me. Does that apply to any MPLS = packet or a particular class of MPLS packets in a network? >>> I appreciate that the document mentions work on Synonymous Flow = Labels. However, it is not clear to me why SFL-based application of the = AMM is characterized as hop-by-hop, while the solution described in the = draft - as edge-to-edge. I would appreciate it if the authors can = clarify that characterization of measurement methods, particularly since = the T-bit (defined in Figure 1) differentiates between edge-to-edge and = hop-by-hop measurements using the proposed solution. >>> Furthermore, it seems like the comparison of the impact on an MPLS = packet of the proposed solution and IOAM is inaccurate. As I understand = it, contrary to the statement in Introduction that "the former doesn't = introduce any new header whereas the latter introduces a new In-situ OAM = header", both introduce (unlike SFL-based application of AMM) extra = ancillary data in an MPLS packet. >>> And, on the last paragraph in Introduction. I believe that = publishing a draft on Standard track and then moving it to Historic once = another solution is standardized by IETF is sub-optimal. I recognize the = value of the work put in by implementers of the described in the draft = solution. The deployment experience is invaluable. On the other hand, = there seems to be an agreement that the MNA is the preferred mechanism = to support AMM in the MPLS networks. (Note that = draft-ietf-mpls-mna-usecases is being updated to include AMM as another = use cases of on-path telemetry in the MPLS networks, in addition of = IOAM). Hence my proposal to switch this document to Experimental track = (see my question about the requested IANA allocation below). >>> The list of implementations is impressive and suggests that there = are several deployments. If that is the case, which value of eSPL for = Flow-ID Label Indicator is used? >>> In conclusion, I don't support progressing this draft on the = Standard track. I would support progressing it as Experimental or = Informational (perhaps that means that the IANA section is removed). >>>=20 >>> Regards, >>> Greg >>>=20 >>> On Thu, Apr 25, 2024 at 8:09=E2=80=AFAM Tony Li > wrote: >>>>=20 >>>> [WG chair hat: on] >>>>=20 >>>>=20 >>>> Hi all, >>>>=20 >>>> This starts a 2 week working group last call on = draft-ietf-mpls-inband-pm-encapsulation. >>>>=20 >>>> This last call ends at 12:01 PM PDT, Thurs. May 9, 2024. >>>>=20 >>>> Please send all comments to the mailing list. >>>>=20 >>>> Regards, >>>> Tony >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mpls mailing list >>>> mpls@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mpls >>=20 --Apple-Mail=_7F2CF824-AC71-4661-B48B-2F1D01256A6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

[WG chair hat: = on]

Hi Greg,

Yes, existing = implementations that are using an experimental code point could continue = to do so if the document were published as Experimental.  However, = this would leave us in an awkward situation where an experimental code = point is effectively allocated to the protocol but not documented in the = registry.  This seems sub-optimal.  The whole point of = experimental code points is that they do not become = permanent.

I cannot speak to why there was no = request for early allocation.  Sorry, I=E2=80=99m late ot the party = here. If it was my proposal, I would = have.

Regards,
Tony


On May 3, 2024, at = 1:13=E2=80=AFPM, Greg Mirsky <gregimirsky@gmail.com> = wrote:

Hi Tony,
thank you for your prompt = clarification of the eSPL value allocation. I assume that the listed = implementations, or some of them, are already deployed. As I understand = it, they all use some value as FLI, most likely the same one across all = the implementations. As you've pointed out, using a value from the = Unassigned or Reserved ranges of the Extended Special-Purpose MPLS Label = Values registry would be squatting. 
About = potential squatting (that, as I believe, should not be encouraged). If I = was considering an early implementation of this draft, I'd use a value = from the Experimental range (240-255). If that is the case for this = draft, moving it to the Experimental track, in my opinion, is = reasonable. On the other hand, if the implementers of earlier version of = the draft did use a value from Unassigned range without the early = allocation, why wouldn't they ask for allocation of that specific value = rather than letting IANA to pick one for them and be forced to change = their implementations in case the two values turned to be = different?

Regards,
Greg

On= Fri, May 3, 2024 at 1:00=E2=80=AFPM Tony Li <tony.li@tony.li> = wrote:

[WG chair hat: = on]

Hi Greg,

I will let the = authors respond to the bulk of the comments here, but I do want to = address some process concerns.

Currently, the = registry action for the 'Extended Special-Purpose MPLS = Label Values' registry is =E2=80=99Standards Action=E2=80=99. If this = document were to be published as Experimental, then it would not be = allowed to allocate a permanent code point, resulting in the = implementations squatting on a code point. This is = sub-optimal.

It appears that there was no = early allocation done for a code point, so the squatting is already = obviously occurring. Also sub-optimal.

First = publishing as Standards Track and then shifting to Historical allows for = code point = allocation.

Regards,
Tony

On May 3, 2024, at = 12:37=E2=80=AFPM, Greg Mirsky <gregimirsky@gmail.com> = wrote:

Hi, Tony and All,
I've read the latest = version of the draft. Please find my comments = below:
  • The proposed mechanism, as stated in Abstract, = applies to "MPLS live traffic". I couldn't find the definition of the = term "live traffic" and appreciate it if you can clarify it for me. = Does that apply to any MPLS packet or a particular class of MPLS packets = in a network?
  • I appreciate that the document mentions work on = Synonymous Flow Labels. However, it is not clear to me why SFL-based = application of the AMM is characterized as hop-by-hop, while the = solution described in the draft - as edge-to-edge. I would appreciate it = if the authors can clarify that characterization of measurement methods, = particularly since the T-bit (defined in Figure 1) differentiates = between edge-to-edge and hop-by-hop measurements using the proposed = solution.
  • Furthermore, it seems like the comparison of the = impact on an MPLS packet of the proposed solution and IOAM is = inaccurate. As I understand it, contrary to the statement in = Introduction that "the former doesn't introduce any new header whereas = the latter introduces a new In-situ OAM header", both introduce (unlike = SFL-based application of AMM) extra ancillary data in an MPLS = packet.
  • And, on the last paragraph in Introduction. I believe = that publishing a draft on Standard track and then moving it to Historic = once another solution is standardized by IETF is sub-optimal. I = recognize the value of the work put in by implementers of the = described in the draft solution. The deployment experience is = invaluable. On the other hand, there seems to be an agreement that the = MNA is the preferred mechanism to support AMM in the MPLS networks. = (Note that draft-ietf-mpls-mna-usecases is being updated to include AMM = as another use cases of on-path telemetry in the MPLS networks, in = addition of IOAM). Hence my proposal to switch this document to = Experimental track (see my question about the requested IANA allocation = below).
  • The list of implementations is impressive and suggests = that there are several deployments. If that is the case, which value of = eSPL for Flow-ID Label Indicator is used?
In = conclusion, I don't support progressing this draft on the Standard = track. I would support progressing it as Experimental or Informational = (perhaps that means that the IANA section is = removed).

Regards,
Greg

On Thu, Apr 25, 2024 at 8:09=E2=80=AFAM Tony Li = <tony.li@tony.li> wrote:

[WG chair hat: on]


Hi all,

This starts a 2 week working group last call on = draft-ietf-mpls-inband-pm-encapsulation.

This last call ends at 12:01 PM PDT, Thurs. May 9, 2024.

Please send all comments to the mailing list.

Regards,
Tony


_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
=


= --Apple-Mail=_7F2CF824-AC71-4661-B48B-2F1D01256A6A--