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

"Andrew G. Malis" <agmalis@gmail.com> Sun, 16 June 2024 13:26 UTC

Return-Path: <agmalis@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 81D61C15106C; Sun, 16 Jun 2024 06:26:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 15XBOgiVeY6b; Sun, 16 Jun 2024 06:26:04 -0700 (PDT)
Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 ED3A7C151093; Sun, 16 Jun 2024 06:26:03 -0700 (PDT)
Received: by mail-pg1-x52e.google.com with SMTP id 41be03b00d2f7-681ad26f4a5so2182494a12.2; Sun, 16 Jun 2024 06:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718544363; x=1719149163; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=d8Yphfn3g70cgt+LheLRtLIkACwll3ee4g9PpAj1Z/I=; b=VGMKEEHnd/LQxYD7txYB8EkWxljAlT3mTkPrzrXq0YWyis5Y1QIhMq2pQuki8snOL0 t38KxkytCwRtvkVFdJzEwpv1gvW+EeVAnYHg7WCV0TcI/Stf58s5KVHc2xQEFYEf9S3h 0T8tCYm5vCNaVI6801tpBEAt5YTwYQUoOBC0g+JmH2lweC5crtlV/jtz0lyUZkicCYA7 0EwxIJTGAtkJ2Nvg5EB83FR0wrVstLSrhnVuGJoBknqVhKgUIpOimURCUv9S70snKdG4 qoYwN5NypBUVQAZYeqCej3LADA+O9y3IFLqZas5W1jFYUx0qDTN/lTeKwjNVQbTob18r cO8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718544363; x=1719149163; h=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=d8Yphfn3g70cgt+LheLRtLIkACwll3ee4g9PpAj1Z/I=; b=CZ+iVkF8minyqgoL7CR/T1fB7Xhe6kWrvIGg/VW2QoHSntknBdqannJsReQMtBrWri O4mNPxzuQ2IE3UcoRC4P4nNPwbYVFXRwQOComEDseWdbOPGMS3ei97SgLVEwFuCrzH+1 5F+zZpug/3G7jm4GFiTTD7YObnZROlGtZJFZEyvfZ1SeoqGDIQIzH8RMP77VYivCYYWq SPpOewJCqIqI5X1X1gU2EO1EKLSmv5FIfFx9jN1x5dv+cybIP9fFH/QoON4ojDtS3zho f6PH4SeipJwW4Lx/fekEAyFHfjlN+T9Zp8mO2y2gmx3scPmqypdrHxxcg5HmXB0PjxLW NIRQ==
X-Forwarded-Encrypted: i=1; AJvYcCU8v93xcYHGNQvJilSCGXp3zPTceUa09FjWEao++rK34uPcilZgEDlur/slp8MAJ7hJoz9tqNa3coDJ5RwuYsMcnMTwRFlcKyyjhDSL8i7y1lBw9TO6zJ6kWeNE1vcm/8UnJndZwZvPrFhImOpJ5ax91hiWUB7M3Fx8p04pr7m9TrFg3sVCGGDOYNnepPU3a74XA6usCg==
X-Gm-Message-State: AOJu0YznnPz6sPbX7EV4UV63arubvmGp2w+KGCBf8mwN5OOkRXykD8nt LTsFPxPXuR0RZ11IytFyzS88EeYKUk4puLAXosEOJOGp4BXB7BC1CCqSgceJGOd5VVBfJJ3jpZy /6zVJ2+uamEjVyffmlO0l4Ew8xWc=
X-Google-Smtp-Source: AGHT+IESwaxO1M+sg1FCRb0J/lA4wfwXcqvCfNpkdGO8BRCdybixorQjYwS007G7175TOsJIliVp00LRQLaguymOK7Q=
X-Received: by 2002:a05:6a20:2d14:b0:1b6:d91c:6453 with SMTP id adf61e73a8af0-1bae7f0f0a4mr7961081637.36.1718544362782; Sun, 16 Jun 2024 06:26:02 -0700 (PDT)
MIME-Version: 1.0
References: <CABUE3Xn7XyqQAUJpr9qGx-yG3Au=OX00sgX8uZ4vOBHLpLdhrw@mail.gmail.com> <8DB06D5B-E2E5-4BC9-ACA2-EBE552E51266@cisco.com> <CABUE3XkUYP6BE8soG2_i8EB1+CMLr81FWMTfbYbtJ8e8nndDEQ@mail.gmail.com>
In-Reply-To: <CABUE3XkUYP6BE8soG2_i8EB1+CMLr81FWMTfbYbtJ8e8nndDEQ@mail.gmail.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Sun, 16 Jun 2024 09:25:46 -0400
Message-ID: <CAA=duU2RRYTU4bZMjGKUq06a0RzAtxFzjWO=ZSUVsXWuQkpPoA@mail.gmail.com>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000464bdb061b01cac2"
Message-ID-Hash: BFWPI6KVNCPX2TUCSPHYYPGA7ZWHKXLR
X-Message-ID-Hash: BFWPI6KVNCPX2TUCSPHYYPGA7ZWHKXLR
X-MailFrom: agmalis@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: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>, "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/g3kkaoh3CbbyxEbsoa7tkjq0m6g>
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>

Tal,

Thanks again for your review and also reviewing Christian's reply.

I'm concerned regarding your suggestion that
draft-filsfils-spring-net-pgm-extension-srv6-usid be made a normative
reference, as it is only an individual draft right now and there's no
guarantee that it'll even become a WG draft, never mind an RFC, and making
it a normative reference would hold up publishing this draft for quite a
while, unless we get special dispensation from the IESG. Do you see any way
we can get around making draft-filsfils normative?

I'm much less concerned regarding draft-ietf-spring-srv6-srh-compression,
as that is currently in WG last call.

Thanks again,
Andy


On Sun, Jun 16, 2024 at 1:12 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com>
wrote:

> 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