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

"Andrew G. Malis" <agmalis@gmail.com> Mon, 17 June 2024 12:33 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 68D51C14F5E0; Mon, 17 Jun 2024 05:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, 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 2QHGspaWtwOl; Mon, 17 Jun 2024 05:33:32 -0700 (PDT)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 0AB4FC14F689; Mon, 17 Jun 2024 05:33:20 -0700 (PDT)
Received: by mail-pj1-x102f.google.com with SMTP id 98e67ed59e1d1-2c2e0ca8f90so3604930a91.0; Mon, 17 Jun 2024 05:33:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718627599; x=1719232399; 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=UtBMtD01pC5UpbpcPSsEyJMua23+acJ6492CeH14Y6w=; b=l0qJpMbnX3RgWf4Jgl6nI/NuU/TXsDYpelthrGQn2QTNU+4nbvOCL4TW931jWlUkIc 3a7VxNwFG4D2wBMEvxE8ZwuHBZ3k9EIAeBuckNl1PBX/t1sBXdt9JEpi9MT2ky6fALW0 cPlid6pU6CFfJPVZeYSM+UKcvTo0Zj0bUh47n7c/JU50oER3eBb5GBrLogK1EBHjMzDe VDOegWQJBBUK2KS0w3I0xXoWhplPAiassMIOER6RfkY3tkoY5AFxZmlqd3BX63NNuAiz 7f5kJsGK5HQ6xZxBFusM12n6um8xpkZ5F7E1qBROln9sB6QZZ2PPD128W14MuBl47owr qVTQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718627599; x=1719232399; 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=UtBMtD01pC5UpbpcPSsEyJMua23+acJ6492CeH14Y6w=; b=Qtlj5W127LXSsDA0ACs024Gk2loeAYeXpZstW9V1CDZ2Yja41YOwJekVK8AeQvJ0mr jEvEfr6MpnXv9vloq+1awBIwuYihi9o2+EkGoaRTHi0YEPGtDELOvq/cgocvgQVIru8m bCrhFviS2ATF90AgE0QjHRoRxUu6AkYaEs3l0I+LGNgmeAIuRQZpLQrEnrU4J5VmC/Jn +bMWHmSCQUFSwisQyeqBFngq8mxZ7unTC05WSdPeGUq5CxRpnuPFngbReND3DPbsfWp/ B32Yz8TBclB4AF4v9o2eyFmgvqRw3dgG49DSTBoCf8SbyqaXRLBx7VHq+jsAgSRaw9Ng BC1w==
X-Forwarded-Encrypted: i=1; AJvYcCXf2YKAYtoyhweU/YLP+y6C+E5urehP85cNjy8ik4oMlcMDgnmmXo/GYQsbY+CfRxEwRrev7DiNCBqK61WqAE4bNQkYuZvLnqgLlITZx5nnIh2Ul01HXJxYvitO1Fo8HtiGiu4/3tppWfe6ungF0F+bVPvH59PEioUXrRGoAvEwW9DxHcC5mUb4B7EzZvASGnMrBkG+tg==
X-Gm-Message-State: AOJu0YwLgztFK3BNRNpivZuewwkp4B+VBIoOraMaDR7nxMR8N1Bsa7xs PoKFFHTxwflW/eqMB4EbM5wcIJ3Ykkx9dQDxd7aiP3uz+3bfvVdkGGHRgd+bKBsUYBnZ3CPFeHn NzFONCIltnFulQQQJ04oS6uMEO6w=
X-Google-Smtp-Source: AGHT+IHcsa9vlDdxS9daeDRfaAO0+snWI6hFbrrWLJKsPAB3P62jN9xxAnqLLJZPNzlgDtumTLuCW9zc9sHHmrJu6+k=
X-Received: by 2002:a17:90a:66c3:b0:2c4:ab0b:9d9e with SMTP id 98e67ed59e1d1-2c4db241ebemr9226655a91.15.1718627598746; Mon, 17 Jun 2024 05:33:18 -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> <CAA=duU2RRYTU4bZMjGKUq06a0RzAtxFzjWO=ZSUVsXWuQkpPoA@mail.gmail.com> <CABUE3XnP3qNnZYd+xFERp0O53=Nn4YPwLoOnk_yUMdpy04wfcw@mail.gmail.com> <CAA=duU2D4=xVz7yTevn5Qff-PuQ3E3NRe0ha8amnUax15CLNdQ@mail.gmail.com> <C19B7155-40CF-4654-B65E-5FEDA58174E3@cisco.com>
In-Reply-To: <C19B7155-40CF-4654-B65E-5FEDA58174E3@cisco.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Mon, 17 Jun 2024 08:33:01 -0400
Message-ID: <CAA=duU2Bpha6QuC3qL=rUtkjG4jDGy0xpC30R-MJCEijZRFAgg@mail.gmail.com>
To: "Christian Schmutzer (cschmutz)" <cschmutz@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000864ab4061b152bfe"
Message-ID-Hash: 5V7RW6AXVEZLCGM5MIZMM4WWMM2FTLLT
X-Message-ID-Hash: 5V7RW6AXVEZLCGM5MIZMM4WWMM2FTLLT
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: Tal Mizrahi <tal.mizrahi.phd@gmail.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/F-r6CrgxTzP4XyqSKX0hnIoGDMQ>
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>

Christian,

Thanks. I look forward to the next revision, after which we can start
getting ready for IESG submission.

Cheers,
Andy


On Mon, Jun 17, 2024 at 1:13 AM Christian Schmutzer (cschmutz) <
cschmutz@cisco.com> wrote:

> Hi Andy and Tal,
>
> Works for me and agree on RFC8986 being normative. I will first describe
> the behaviours and only after that insert a note to the two informative
> references that don’t really define anything with respect to PLE but
> provide context which I thought may be useful.
>
> Christian
>
> On 16.06.2024, at 21:28, Andrew G. Malis <agmalis@gmail.com> wrote:
>
> Tal,
>
> That sounds good to me, thanks!
>
> Christian, how about you?
>
> Cheers,
> Andy
>
>
> On Sun, Jun 16, 2024 at 2:10 PM Tal Mizrahi <tal.mizrahi.phd@gmail.com>
> wrote:
>
>> Hi Andy,
>>
>> That is an interesting question.
>> The text that was suggested by Christian seemed to assume that the
>> reader is familiar with the previous endpoint behaviors (End.DX2,
>> End.DX2 with NEXT-CSID and End.DX2 with REPLACE-CSID).
>> Therefore, the text does not explain the meaning of the new endpoint
>> behaviors, because a reader who is familiar with the DX2 endpoint
>> behaviors would understand what the new DX1 behaviors do.
>>
>> A possible way around this is to add more detailed text to the current
>> document that explains for each of these new behaviors (End.DX1,
>> End.DX1 with NEXT-CSID and End.DX1 with REPLACE-CSID) what exactly it
>> means and the corresponding pseudo-code. The similarity to the DX2
>> behaviors could be mentioned as a side note, and thus the two drafts
>> (srh-compression and srv6-usid) could be informative references. I
>> believe RFC 8986 should probably be normative anyway.
>>
>> Please let me know if that makes sense.
>> Cheers,
>> Tal.
>>
>> On Sun, Jun 16, 2024 at 4:26 PM Andrew G. Malis <agmalis@gmail.com>
>> wrote:
>> >
>> > 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
>>
>
>