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

["Andrew G. Malis" <[e-mail]>]

Tal,

That sounds good to me, thanks!

Christian, how about you?

Cheers,
Andy


On Sun, Jun 16, 2024 at 2:10 PM Tal Mizrahi <[e-mail]>
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 <[e-mail]> 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 <[e-mail]>
> 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)
> >> <[e-mail]> 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 <[e-mail]>
> 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
>