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

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

Christian,

Thanks! We'll get the process going from here.

Cheers,
Andy


On Fri, Jun 28, 2024 at 11:26 AM Christian Schmutzer (cschmutz) <
[e-mail]> wrote:

> Hi Andy,
>
> Fyi I just uploaded a new version of the draft:
> - addressing Tal’s RtgDir review comments
> - checked all references against normative / informative
> - added missing terminology definitions
> - minor editorial changes as I saw fit
>
> regards
> Christian
>
> On 17.06.2024, at 14:33, Andrew G. Malis <[e-mail]> wrote:
>
> 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) <
> [e-mail]> 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 <[e-mail]> 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 <[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
>>>
>>
>>
>