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

[Tal Mizrahi <[e-mail]>]

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