[RTG-DIR]Re: RtgDir Last Call review: draft-ietf-pals-ple

Tal Mizrahi <tal.mizrahi.phd@gmail.com> Sun, 16 June 2024 05:12 UTC

Return-Path: <tal.mizrahi.phd@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092F1C14F5FC; Sat, 15 Jun 2024 22:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham 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 o-_8B0_2DiHL; Sat, 15 Jun 2024 22:12:26 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 67D7AC14F5F9; Sat, 15 Jun 2024 22:12:23 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-57cc112407dso235746a12.3; Sat, 15 Jun 2024 22:12:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718514741; x=1719119541; darn=ietf.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OnW7/D2VDFeVWC8LuNojqSHP+Ig3DR2XsolHTt8sON4=; b=UeUT25xc9x4eQ8lS8m95i0jEf1OWIdMS23xA3dpk3udWJ0IbXIzJFgtK9YQ+DEDXsQ YtQM71d8uzLHVgv8D6z9YzyLrMVBfvQ9w62Du0kkh21s7GMiQmGy57QqxVAX0Cgz413c MTPo3hcGk43/9hIsaTz+00CRvtFe/Uhzq80bYLhNoGAElar0Vlg7EO5AFBBMRWCT1hwS gpcKr9uI0ADkvEpJE5Aj9D9/TmdajCwnVUJqlGzskbyPur4bRUesJ28ybCdUOkACu5Wt RzuR/dwmax762mrC5yg38UO7DVCQlwOcmYbomQtviBnJwDgCaRWqN8dGF4+0fePhw3jQ IIlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718514741; x=1719119541; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OnW7/D2VDFeVWC8LuNojqSHP+Ig3DR2XsolHTt8sON4=; b=n4kdPFSie5VkfYx4C3WdOfclIfLQ6+aN39XYnwEAtBsFAQO0hAlYdFaX7aGSnDa3Zi HLpnsJWx+oyv/KLIvMxwhpg/cGxVEsBFY7Ta5SHdFIcNPB7U2MR9gBfcXp9Itfu89GCU 16vRgJQ2CH9aGU8h9a1/89LPZ9RKGzzWYkWllnR6/EhMVJh02+pMazHN9S01MCZMk32T A3MwBXM68+rqF32eoX7ncjFbx0hxaWsKLOghvrd3GWRd1IzGaX0cxKqCQ6ZxpeVDQ8H+ clcL+QKBJ3vD/3me0LlDxHsrOG0bd6XqMXiXmUJercI4B+XYKb2bgt1sG26WZzB15FCc zM8Q==
X-Forwarded-Encrypted: i=1; AJvYcCU4W7dt8QiUFA7RgCmR3UGhiUuwpLL9NV2XrfDgEBFYd/aFRcy9dlsP5kjvTJIGn8k1TmaIPsntO8Na2GXqMH3w3hIAhAM/e67D4DlWY2fenHhjTfiVoF6o2Opf8L3Z47GwOws3zDyb5NVdJmuamnsSV7nGMslihzKo4Z39qSMMpdKtAg==
X-Gm-Message-State: AOJu0Yw7Ze3FFkUGRT8jU9Z3A+4EIGWd5rVqu48BWdYV2kTKYYR7q3df h4OM8RGP9qhWygrjUmlRDOskTQA8D6tBrVBcILhqBLE7fm+hTBBgl2KY5xrK8Y/EBD6Y+VZ5WNT n4YzZXmTn4uHCBkLOtalzE4z99fWx2bxdv3FfN7Mi
X-Google-Smtp-Source: AGHT+IEjYR2kmz3pS5WMRB8aP0iBwrlyN9fCNMkKrbrmbdnYFloMzIG2p5zz8Eo6wa7Ge2G00zloJSGmv+pRhF68/Yc=
X-Received: by 2002:a17:906:c20e:b0:a6f:27e2:8129 with SMTP id a640c23a62f3a-a6f60dccd43mr391272466b.3.1718514740575; Sat, 15 Jun 2024 22:12:20 -0700 (PDT)
MIME-Version: 1.0
References: <CABUE3Xn7XyqQAUJpr9qGx-yG3Au=OX00sgX8uZ4vOBHLpLdhrw@mail.gmail.com> <8DB06D5B-E2E5-4BC9-ACA2-EBE552E51266@cisco.com>
In-Reply-To: <8DB06D5B-E2E5-4BC9-ACA2-EBE552E51266@cisco.com>
From: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Date: Sun, 16 Jun 2024 08:12:08 +0300
Message-ID: <CABUE3XkUYP6BE8soG2_i8EB1+CMLr81FWMTfbYbtJ8e8nndDEQ@mail.gmail.com>
To: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: CGQ2FEIF3QR33WEF7ERZ4CRZSECDBTNL
X-Message-ID-Hash: CGQ2FEIF3QR33WEF7ERZ4CRZSECDBTNL
X-MailFrom: tal.mizrahi.phd@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "rtg-ads@ietf.org" <rtg-ads@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "pals@ietf.org" <pals@ietf.org>, "draft-ietf-pals-ple@ietf.org" <draft-ietf-pals-ple@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [RTG-DIR]Re: RtgDir Last Call review: draft-ietf-pals-ple
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/yztoHl_dvCcaq_p5sHyFA5Vx-ss>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

Hi Christian and authors,

Thanks for considering my comments.
The changes you suggested make sense to me.

Regarding the new endpoint behaviors, please note:
- The IANA section will need to be updated accordingly.
- You may need to move the references to normative: {{?RFC8986}},
{{?I-D.draft-ietf-spring-srv6-srh-compression}},
{{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}}.
Specifically the last two, which may still be subject to changes.

Cheers,
Tal.

On Sat, Jun 8, 2024 at 12:16 PM Christian Schmutzer (cschmutz)
<cschmutz@cisco.com> wrote:
>
> Hi Tal,
>
> Sorry for taking so long. Below our comments and proposal for addressing your issues.
>
> Can you please let us know your thoughts. Upon your feedback we will work towards uploading a new version addressing the issues.
>
> regards
> Christian
>
> On 15.05.2024, at 01:20, Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about
> the Routing Directorate, please see
> https://wiki.ietf.org/en/group/rtg/RtgDir
>
> Document: draft-ietf-pals-ple-04
> Reviewer: Tal Mizrahi
> Intended Status: Standards Track
>
> Summary:
> I have some concerns about this document that I think should be
> resolved before publication.
>
> The draft is well-written and clear from a grammatical and structural
> perspective. However, there is a very long list of normative
> references that are cited in almost every paragraph of the document,
> making it very difficult to follow for a reader who is somewhat
> familiar with the area but is not an expert in the area.
>
>
> [cs]
> PLE has a lot of similarities with RFC 4553 and other referenced specifications. We felt references are better as it avoids duplication of text across documents, but I see your point. We will work through the document and add a bit more text / context before calling out a RFC reference.
>
> Here an example from the introduction section. Will do something similar for other sections.
>
> before:
>
> The mechanisms described in this document follow principals similar to [RFC4553] but expanding the applicability beyond the narrow set of PDH interfaces (T1, E1, T3 and E3) and allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds by treating them as bit-stream payload defined in sections 3.3.3 and 3.3.4 of [RFC3985].
>
>
> after:
>
> The mechanisms described in this document follow principles similar to Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) defined in [RFC4553]. The the applicability is expanded beyond the narrow set of PDH interfaces (T1, E1, T3 and E3) to allow the transport of signals from many different technologies such as Ethernet, Fibre Channel, SONET/SDH [GR253]/[G.707] and OTN [G.709] at gigabit speeds. The signals are treated as bit-stream payload which was defined in the Pseudo Wire Emulation Edge-to-Edge (PWE3) architecture in [RFC3985] sections 3.3.3 and 3.3.4.
>
>
> Where applicable we will remove the reference and just have appropriate text. Once example
>
> before:
>
> Similar to [RFC4553] and [RFC5086] the term Interworking Function (IWF) is used to describe the functional block that encapsulates bit streams into PLE packets and in the reverse direction decapsulates PLE packets and reconstructs bit streams.
>
>
> after:
>
> The term Interworking Function (IWF) is used to describe the functional block that encapsulates bit streams into PLE packets and in the reverse direction decapsulates PLE packets and reconstructs bit streams.
>
>
>
> Issues:
> - The target audience of the document should be clarified, preferably
> in the abstract. On a related note, throughout the document it is a
> bit difficult to distinguish between requirements defined for
> operators vs. requirements defined for implementers. Perhaps the
> authors could give some thought as to whether this issue can be
> mitigated.
>
>
> [cs]
> the target audience is implementers. We adjusted the abstract to reflect that
>
> before:
>
> This document describes a method for encapsulating high-speed bit-streams as virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency.
>
>
> after:
>
> This document describes methods and requirements for implementing the encapsulation of high-speed bit-streams into virtual private wire services (VPWS) over packet switched networks (PSN) providing complete signal transport transparency.
>
>
> - The security considerations should be more detailed. The cited
> references are a good start, but the following issues should also be
> discussed:
>
>  - The requirement for synchronization is potentially a
> vulnerability. An on-path attacker may compromise the synchronization,
> and thus compromise the service. You may want to take a look at RFC
> 7384.
>
>  - The requirements for low jitter, low loss and bandwidth
> reservation (section 8) are also potentially an attack vector. You may
> take a look at RFC 9055 for example.
>
>
> [cs]
> We have added a couple of sentences to provide more details, plus referred to respective RFCs for more information
>
> before:
>
> As PLE is leveraging VPWS as transport mechanism the security considerations described in [RFC7432] and [RFC3985] are applicable.
>
>
>
> after:
>
> As PLE is leveraging VPWS as transport mechanism the security considerations described in [RFC7432] and [RFC3985] are applicable.
>
> PLE does not enhance or detract from the security performance of the underlying PSN. It relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required.
>
> A data plane attack may force PLE packets to be dropped, re-ordered or delayed beyond the limit of the CE-bound IWF's dejitter buffer leading to either degradation or service disruption. Considerations outlined in [RFC9055] are a good reference.
>
> Clock synchronization leveraging PTP is sensitive to Packet Delay Variation (PDV) and vulnerable to various threads and attacked vectors. Considerations outlined in [RFC7384] should be taken into account.
>
>
>
> - The following two endpoint behaviors are defined in the IANA
> considerations section, but not defined anywhere in the document.
> These endpoint behaviors should either be removed or specified in
> detail:
> End.DX1 with NEXT-CSID
> End.DX1 with REPLACE-CSID
>
>
> [cs]
> Good point and I realised we have also forgotten to add the required encaps description. We have reworded this section as follows (in markdown syntax)
>
> When a SRv6 PSN layer is used, a SRv6 service SID does provide the demultiplexing mechanism and the mechanisms defined in {{?RFC8402}} and {{?RFC9252}} section 6 do apply. Both SRv6 service SIDs with the full IPv6 address format defined in {{?RFC8986}} and compressed SIDs (C-SIDs) with format defined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} can be used.
>
> Two new encapsulation behaviors H.Encaps.L1 and H.Encaps.L1.Red are defined in this document. The behavior procedures are applicable to both SIDs and C-SIDs.
>
> The H.Encaps.L1 behavior encapsulates a frame received from an IWF in a IPv6 packet with an SRH. The received frame becomes the payload of the new IPv6 packet.
>
> * The next header field of the SRH MUST be set to TBA1.
>
> * The push of the SRH MAY be omitted when the SRv6 policy only contains one segment.
>
> The H.Encaps.L1.Red behavior is an optimization of the H.Encaps.L1 behavior.
>
> * H.Encaps.L1.Red reduces the length of the SRH by excluding the first SID in the SRH of the pushed IPv6 header. The first SID is only placed in the destination address field of the pushed IPv6 header.
>
> * The push of the SRH MAY be omitted when the SRv6 policy only contains one segment.
>
> Three new "Endpoint with decapsulation and bit-stream cross-connect" behaviors called End.DX1, End.DX1 with NEXT-CSID and End.DX1 with REPLACE-CSID are defined in this document.
>
> These new behaviors are variants of End.DX2 defined in {{?RFC8986}}, End.DX2 with REPLACE-CSID defined in {{?I-D.draft-ietf-spring-srv6-srh-compression}} and End.DX2 with NEXT-CSID defined in {{?I-D.draft-filsfils-spring-net-pgm-extension-srv6-usid}} and all have the following procedures in common.
>
> The End.DX1 SID MUST be the last segment in an SR Policy, and it is associated with a CE-bound IWF I. When N receives a packet destined to S and S is a local End.DX1 SID, N does the following:
>
> ~~~~
> S01. When an SRH is processed {
> S02.   If (Segments Left != 0) {
> S03.     Send an ICMP Parameter Problem to the Source Address
>          with Code 0 (Erroneous header field encountered)
>          and Pointer set to the Segments Left field,
>          interrupt packet processing, and discard the packet.
> S04.   }
> S05.   Proceed to process the next header in the packet
> S06. }
> ~~~~
>
> When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.DX1 SID, N does the following:
>
> ~~~~
> S01. If (Upper-Layer header type == TBA1 (bit-stream) ) {
> S02.    Remove the outer IPv6 header with all its extension headers
> S03.    Forward the remaining frame to the IWF I
> S04. } Else {
> S05.    Process as per {{Section 4.1.1 of RFC8986}}
> S06. }
> ~~~~
>
>
>
> - Regarding the following paragraph, I wonder whether it is necessary
> to define the exact clock frequency in an IETF document. Even ITU-T
> G.8261 and IEEE 1588 do not define a specific clock frequency.
> Interoperability does not necessarily require both endpoints to have
> the same clock frequency.
>      For bit-streams up to 200 Gbps the frequency of the
>      clock used for generating timestamps MUST be 125 MHz based on a
>      the common clock I.  For bit-streams above 200 Gbps the frequency
>      MUST be 250 MHz.
>
>
> [cs]
> For differential clock recovery (DCR) to work the peer node must know which clock was used to create the timestamps. RFC4553 section 4.3.2 is pretty clear about this as well and we are following the same approach here in specifying this aspect for PLE.
>
> "The frequency of the clock used for generating timestamps MUST be …”
>
> “options associated with its usage (the timestamping clock frequency, the timestamping mode, selected PT and SSRC values) MUST be agreed upon between the two SAToP IWFs …”
>
>
>
> Nits:
> - "principals" => "principles" ?
>
>
> [cs]
> Thanks, will take care of it when publishing the next version
>