[Pals] Re: Opsdir last call review of draft-ietf-pals-ple-09

--===============2934290302252489053==
Content-Type: multipart/alternative; boundary="0000000000002cbd7206274b8b10"

--0000000000002cbd7206274b8b10
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Tony,

Are you OK with Christian's reply and the updates in -10? I noticed that
you haven't updated the "Has issues" tag in the Datatracker and the draft
is on the 12/5 telechat agenda.

Thanks,
Andy


On Tue, Nov 5, 2024 at 2:05=E2=80=AFAM Christian Schmutzer (cschmutz) <
[email protected]> wrote:

> Hi Tony,
>
> Thank you for your very detailed review. I am trying to address your
> comments inline via [cs]. Mentioned changes are incorporated in the -10
> revision I just published
>
> Christian
>
> On 21.10.2024, at 21:55, Tony Li via Datatracker <[email protected]> wrote=
:
>
> Reviewer: Tony Li
> Review result: Has Issues
>
> OPSDIR Last Call Review of draft-ietf-pals-ple
>
> Reviewer: Tony Li
> Status:
>
> Overall:
>
> Details:
>
> Section 1:
>
> Please expand the acronyms PE and CE on first use.
>
> Some discussion comparing and contrasting this to other pseudowire
> standards would be most helpful to those who are not subject matter
> experts. What is the relationship of this work to RFC 4906? RFC 4842?
> RFC4448, etc.? Why would an operator choose one or another?  This is
> part of your marketing, so I would think that you would very much want
> to expound on this.
>
>
> [cs] good point. I tried to be brief so far - maybe too much so. I change=
d
> the first paragraph as follows to be more explicit. More details are in
> following paragraphs, see also subsequent comments
>
> OLD
> This document describes a method called Private Line Emulation (PLE) for
> encapsulating high-speed bit-streams as Virtual Private Wire Service (VPW=
S)
> over Packet Switched Networks (PSN). This emulation suits applications
> where signal transparency is required and data or framing structure
> interpretation of the PE would be counter productive.
>
> NEW
> This document describes a method called Private Line Emulation (PLE) for
> encapsulating high-speed bit-streams as Virtual Private Wire Service (VPW=
S)
> over Packet Switched Networks (PSN).
>
> This emulation suits applications where carrying Protocol Data Units
> (PDUs) as defined in [RFC4906] or [RFC4448] is not enough, physical layer
> signal transparency is required and data or framing structure
> interpretation of the PE would be counter productive.
>
>
> [cs] the comparison to I tried to cover with this sentence
>
> Also SONET/SDH add/drop multiplexers or cross-connects can be
> interconnected without interfering with the multiplexing structures and
> networks mechanisms. This is a key distinction to Circuit Emulation over
> Packet (CEP) defined in [RFC4842] where demultiplexing and multiplexing i=
s
> desired in order to operate per SONET Synchronous Payload Envelope (SPE)
> and Virtual Tributary (VT) or SDH Virtual Container (VC). Said in another
> way, PLE does provide an independent layer network underneath the SONET/S=
DH
> layer network, whereas CEP does operate at the same level and peer with t=
he
> SONET/SDH layer network.
>
>
> As an example: if the payload is Ethernet, then frame level
> transport is adequate for most applications. In fact, the only thing
> that I can think of where it would not be adequate is if it were
> transporting PTP. I have some concerns about transporting PTP based on
> clocking that is itself derived from PTP, but I assume someone who
> knows PTP well has thought about that already. Wouldn't it be easier
> just to provide PTP directly as a service?
>
>
> [cs] I totally agree that for the most part frame level transport is
> enough. but L2 control protocol tunnelling has been proven to be a
> challenge over the years and still is with the most recent example of EAP=
OL
> (IEEE802.1x) for MACSEC not being passed. I tried to cover this in a more
> generic way with the following sentence
>
> One example of such case is two Ethernet connected Customer Edge (CE)
> devices and the need for Synchronous Ethernet operation between them
> without the intermediate Provider Edge (PE) devices interfering or
> addressing concerns about Ethernet control protocol transparency for PDU
> based carrier Ethernet services, beyond the behaviour definitions of Metr=
o
> Ethernet Forum (MEF) specifications.
>
>
> Section 3.2:
>
> OLD
>
> After the NSP the IWF is generating the payload of the VPWS which is
> carried via a PSN tunnel.
>
> NEW
>
> After the NSP, the IWF is generating the payload of the VPWS which is
> carried via a PSN tunnel.
>
>
> [cs] done
>
> Section 4.3:
>
> Is there actually a market for this service? AFAIK, SONET/SDH is a
> legacy service with little to no new deployment. While SONET/SDH
> transport across a packet network seems like a possible migration
> strategy, will SONET/SDH customers actually be willing to explore new
> technology for supporting legacy services?  I would hate to see us
> going to the effort of creating standards that don't have an impact on
> the market.
>
>
> [cs] You are absolutely right, no-one is deploying new SONET/SDH networks=
.
> However while lots of SDH networks got dismantled already, the rate of
> SONET network decommissioning is slower than someone would expect.
>
> I have had numerous customer discussions on this aspect and one common
> scenario I see is that people try to modernise their DWDM networks by
> moving from non-coherent (direct detect) optical transmission which is
> generally limited to 10Gbps per wavelength, to coherent transmission whic=
h
> allows 100s of Gbps (even Tbps) per wavelength. However these new DWDM
> platforms are often not designed to pickup 2.5G OC48 or even 10G SONET
> connections. PLE is giving you an option to =E2=80=9Caggregate=E2=80=9D t=
hose 2.5G or 10G
> TDM connections onto a bigger packet pipe carried over coherent DWDM
> without the need to daisy-chaining legacy muxponders with a state of the
> art coherent DWDM system.
>
> Section 5.1:
>
> Using BIT-EMU in the SRH next-header field seems unusual. Why not
> request a code point for PLE itself?
>
>
> [cs] the idea was to have a generic/common next-header that can also be
> used for SRv6 PSN scenarios for other bitstreams PWs such SAToP (RFC4553)=
,
> CESoP (RFC5086) and CEP (RFC4842) that were previously defined. The commo=
n
> EVPN-VPWS control plane aspects for  example are covered in
> https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-bitstream-vpws=
-signalling
>
>
> Section 5.1.2:
>
> If the L bit is set, the payload of the packet would seem to be wholly
> irrelevant.  Must the payload be attached? If so, that would seem like
> a waste of bandwidth.
>
>
> [cs] good point, however I wonder from a practical perspective, how much
> of use would this temporary extra capacity be? Wouldn=E2=80=99t operators=
 in their
> capacity planning process always consider the worst case, i.e. that those
> high capacity / high value constant bitstream elephant flows are always
> present?
>
> Other bitstream RFCs did include text that implementations MAY omit the
> payload for packets with L-bit set. If the WG thinks this has value, we c=
an
> add it
>
> Section 6.2:
>
> OLD
>
> The PLE payload size MUST be a integer number of bytes.
>
> NEW
>
> The PLE payload size MUST be an integer number of bytes.
>
>
> [cs] done
>
> Section 7.2.2:
>
> OLD
>
> The CE-bound NSP function will continue to inject the appropriate
> native downstream fault indication signal until a pre-configured
> amount of payloads is stored in the jitter buffer.
>
> NEW
>
> The CE-bound NSP function will continue to inject the appropriate
> native downstream fault indication signal until a pre-configured
> amount of payload is stored in the jitter buffer.
>
>
> [cs] done
>
> Section 7.3:
>
> OLD
>
> UAS-PLE SHALL be counted after configurable number of consecutive
> SES-PLE have been observed, ...
>
> NEW
>
> UAS-PLE SHALL be counted after a configurable number of consecutive
> SES-PLE have been observed, ...
>
>
> [cs] done
>
> You write that "PLE SHOULD provide the following functions to monitor
> the network performance to be inline with expectations of transport
> network operators."  All well and good.  However, more consideration
> for the expectations of packet switched network operators would very
> much be in order. How this is done is up to you, but more information
> is definitely needed from an operational perspective.
>
> From the near-end, I would like to see something like:
>     - Current fault status and explanation
>     - Time of last fault
>     - Time of last good data
>     - Media specific link details (e.g., loss of signal but no loss
>       of light; signal but errors; FEC statistics)
>
>
> [cs] I have enhanced this part of the document to now have two sections
> =E2=80=9CPLE performance monitoring=E2=80=9D and =E2=80=9CPLE Fault Manag=
ement=E2=80=9D. Can you please
> have a look at the new -10 revision and let me know if that provides enou=
gh
> detail?
>
> For the far-end, I would also like to see similar data.  I was
> expecting a similar far-end requirement for transport network
> operators, beyond just a comment about the R bit.
>
>
> [cs] we are following the lead of other bitstream PWs already defined. In
> particular RFC4842 (CEP) which also only defines far-end fault indication
> (R bit).
>
> I guess your point is =E2=80=9Ccan we do better?". OTN (G.709) which is s=
omewhat
> supposed to be mimicking by PLE does provide Backward Error Indication
> (BEI). But OTN has the luxury of lots of overhead bytes that can be used
> for doing that but also it is a TDM technology where you deal with bit
> errors in frames/timeslots.
>
> To do the same in PLE we would need some piece of overhead that allows th=
e
> far-end to Indicate lost packets. Using some unused parts of the control
> word? Or something else? =E2=80=A6 I wonder if this is worth the effort? =
I tend to
> think, no.
>
> Maybe a good reference point to judge this is that ITU also didn't specif=
y
> =E2=80=9CErrored Seconds (ES)=E2=80=9D for ethernet (i.e. a 1 second inte=
rval with only a
> few packets being lost), just "Severely Errored Seconds (SES)=E2=80=9D wh=
ich is
> inline with PLE communication far-end packet loss state (PLOS) via the R =
bit
> https://www.itu.int/rec/T-REC-Y.1563/en
>
>
> This data MUST be provided by management interface and SHOULD be
> provided by a YANG model, which can be out of scope for this document.
>
> If a signaling protocol is involved, it should provide its own
> operational indications. You should call this out.
>
>
> [cs] as with other bitstream PW specs before, the signalling protocol
> details are defined as out of scope in section 7.1 and are covered in
> dedicated documents =E2=80=A6 so I assume that would also mean we can lea=
ve this to
> be covered in the respect documents, right?
>
> Section 8:
>
> I believe that your point here is that you require low jitter and low
> loss. That much I agree with. There are, however, many ways of
> accomplishing this, so I think that Diffserv is not a 'MUST' and would
> better off being a 'SHOULD'.  Providers may achieve low jitter and low
> loss by over-provisioning, for example, or through traffic engineering
> mechanisms.
>
>
> [cs] I made some change to this section in my response to Tommy Pauly=E2=
=80=99s
> review. What do you think about this text?
>
> The PSN providing connectivity between PE devices of a PLE VPWS has to
> ensure low jitter and low loss. The exact mechanisms used are beyond the
> scope of this document and may evolve over time. Possible options, but no=
t
> exhaustively, are a Diffserv-enabled [RFC2475] PSN with a per domain
> behavior [RFC3086] supporting Expedited Forwarding [RFC3246].
> Traffic-engineered paths through the PSN with bandwidth reservation and
> admission control applied. Or capacity over-provisioning.
>
> Section 9:
>
> If a signaling protocol is used, then it is responsible for its own
> security.  You should call this out.
>
> Please discuss SRv6 security.
>
> You make a point of only accepting data from 'valid interfaces'.
> However, this is somewhat challenging as you have no authentication
> mechanisms in this proposal. The receiver is wholly dependent on
> data plane security. If you want to provide a more secure proposal, I
> would suggest adding a cryptographic authentication mechanism.
> Preferably one that provides protection against replay attacks.
>
>
> [cs] With regards to authentication. We are following the lead of other P=
W
> RFCs that use the same / a similar sentence as below and some pointers to
> security considerations for the relevant PSNs. Isn=E2=80=99t that enough?
>
> 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.
>
> [cs] On the point of =E2=80=9Cvalid interfaces=E2=80=9D I also replied to=
 Christian H. My
> bad I was taking a MPLS specific text from RFC7432 and made it generic. I
> changed the section to now have the relevant data plane text in one place
> as follows
>
> NEW
> The PSN is assumed to be trusted and secure. Considerations about the MPL=
S
> core network outlined in [RFC4381] are applicable.
>
> For MPLS based PSNs, one of the requirements for protecting the data plan=
e
> is that the MPLS packets be accepted only from valid interfaces. For a PE=
,
> valid interfaces comprise links from other routers in the PE's own AS. Fo=
r
> an ASBR, valid interfaces comprise links from other routers in the ASBR's
> own AS, and links from other ASBRs in ASes that have instances of a given
> PLE PWs. It is especially important in the case of multi-AS PLE PWs that
> one accepts PLE packets only from valid interfaces.
>
> When a Segment Routing (SR) based PSN is used (MPLS or SRv6) the
> considerations in Section 8 of [RFC8402] and Section 9.3 of [RFC9252] are
> applicable.
>
>
> Section 12:
>
> I'm not understanding the distinction that you're making between
> informative and normative. Why is SONET normative, but Fibre Channel
> informative? Why is PWE3 normative?  Please review all of your
> references.
>
>
> [cs] changed to informative, also went through the references and made
> changes where applicable
>
>

--0000000000002cbd7206274b8b10
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Tony,<div><br></div><div>Are you OK with Christian&#39;s r=
eply and the updates in -10? I noticed that you haven&#39;t updated the &qu=
ot;Has issues&quot; tag in the Datatracker and the draft is on the 12/5 tel=
echat agenda.</div><div><br></div><div>Thanks,</div><div>Andy</div><div><br=
></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 5, 2024 at 2:05=E2=80=AFAM Christian Schmutzer (cschmutz=
) &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>
<div dir=3D"auto">
Hi Tony,
<div><br>
</div>
<div>Thank you for your very detailed review. I am trying to address your c=
omments inline via [cs]. Mentioned changes are incorporated in the -10 revi=
sion I just published=C2=A0</div>
<div><br>
</div>
<div>Christian=C2=A0</div>
<div>
<div><br>
<blockquote type=3D"cite">
<div>On 21.10.2024, at 21:55, Tony Li via Datatracker &lt;<a href=3D"mailto=
:[email protected]" target=3D"_blank">[email protected]</a>&gt; wrote:</div>
<br>
<div>
<div>Reviewer: Tony Li<br>
Review result: Has Issues<br>
<br>
OPSDIR Last Call Review of draft-ietf-pals-ple<br>
<br>
Reviewer: Tony Li<br>
Status:<br>
<br>
Overall:<br>
<br>
Details:<br>
<br>
Section 1:<br>
<br>
Please expand the acronyms PE and CE on first use.<br>
<br>
Some discussion comparing and contrasting this to other pseudowire<br>
standards would be most helpful to those who are not subject matter<br>
experts. What is the relationship of this work to RFC 4906? RFC 4842?<br>
RFC4448, etc.? Why would an operator choose one or another?=C2=A0 This is<b=
r>
part of your marketing, so I would think that you would very much want<br>
to expound on this.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
[cs] good point. I tried to be brief so far - maybe too much so. I changed =
the first paragraph as follows to be more explicit. More details are in fol=
lowing paragraphs, see also subsequent comments</div>
<div><br>
</div>
<div>OLD</div>
<div>
<div>This document describes a method called Private Line Emulation (PLE) f=
or encapsulating high-speed bit-streams as Virtual Private Wire Service (VP=
WS) over Packet Switched Networks (PSN). This emulation suits applications =
where signal transparency is required
 and data or framing structure interpretation of the PE would be counter pr=
oductive.</div>
<div><br>
</div>
<div>NEW</div>
<div>
<div>This document describes a method called Private Line Emulation (PLE) f=
or encapsulating high-speed bit-streams as Virtual Private Wire Service (VP=
WS) over Packet Switched Networks (PSN).=C2=A0</div>
<div><br>
</div>
<div>This emulation suits applications where carrying Protocol Data Units (=
PDUs) as defined in [RFC4906] or [RFC4448] is not enough, physical layer si=
gnal transparency is required and data or framing structure interpretation =
of the PE would be counter productive.</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>[cs] the comparison to I tried to cover with this sentence</div>
<div><br>
</div>
<div>Also SONET/SDH add/drop multiplexers or cross-connects can be intercon=
nected without interfering with the multiplexing structures and networks me=
chanisms. This is a key distinction to Circuit Emulation over Packet (CEP) =
defined in [RFC4842] where demultiplexing
 and multiplexing is desired in order to operate per SONET Synchronous Payl=
oad Envelope (SPE) and Virtual Tributary (VT) or SDH Virtual Container (VC)=
. Said in another way, PLE does provide an independent layer network undern=
eath the SONET/SDH layer network,
 whereas CEP does operate at the same level and peer with the SONET/SDH lay=
er network.</div>
<div><br>
</div>
</div>
<div><br>
<blockquote type=3D"cite">
<div>
<div>As an example: if the payload is Ethernet, then frame level<br>
transport is adequate for most applications. In fact, the only thing<br>
that I can think of where it would not be adequate is if it were<br>
transporting PTP. I have some concerns about transporting PTP based on<br>
clocking that is itself derived from PTP, but I assume someone who<br>
knows PTP well has thought about that already. Wouldn&#39;t it be easier<br=
>
just to provide PTP directly as a service?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] I totally agree that for the most part frame level transport is e=
nough. but L2 control protocol tunnelling has been proven to be a challenge=
 over the years and still is with the most recent example of EAPOL (IEEE802=
.1x) for MACSEC not being passed.
 I tried to cover this in a more generic way with the following sentence</d=
iv>
<div><br>
</div>
<div>
<div>One example of such case is two Ethernet connected Customer Edge (CE) =
devices and the need for Synchronous Ethernet operation between them withou=
t the intermediate Provider Edge (PE) devices interfering or addressing con=
cerns about Ethernet control protocol
 transparency for PDU based carrier Ethernet services, beyond the behaviour=
 definitions of Metro Ethernet Forum (MEF) specifications.</div>
<div><br>
</div>
</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 3.2:<br>
<br>
OLD<br>
<br>
After the NSP the IWF is generating the payload of the VPWS which is<br>
carried via a PSN tunnel.<br>
<br>
NEW<br>
<br>
After the NSP, the IWF is generating the payload of the VPWS which is<br>
carried via a PSN tunnel.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] done</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 4.3:<br>
<br>
Is there actually a market for this service? AFAIK, SONET/SDH is a<br>
legacy service with little to no new deployment. While SONET/SDH<br>
transport across a packet network seems like a possible migration<br>
strategy, will SONET/SDH customers actually be willing to explore new<br>
technology for supporting legacy services?=C2=A0 I would hate to see us<br>
going to the effort of creating standards that don&#39;t have an impact on<=
br>
the market.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] You are absolutely right, no-one is deploying new SONET/SDH netwo=
rks. However while lots of SDH networks got dismantled already, the rate of=
 SONET network decommissioning is slower than someone would expect.=C2=A0</=
div>
<div><br>
</div>
<div>I have had numerous customer discussions on this aspect and one common=
 scenario I see is that people try to modernise their DWDM networks by movi=
ng from non-coherent (direct detect) optical transmission which is generall=
y limited to 10Gbps per wavelength,
 to coherent transmission which allows 100s of Gbps (even Tbps) per wavelen=
gth. However these new DWDM platforms are often not designed to pickup 2.5G=
 OC48 or even 10G SONET connections. PLE is giving you an option to =E2=80=
=9Caggregate=E2=80=9D those 2.5G or 10G TDM connections
 onto a bigger packet pipe carried over coherent DWDM without the need to d=
aisy-chaining legacy muxponders with a state of the art coherent DWDM syste=
m.</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 5.1:<br>
<br>
Using BIT-EMU in the SRH next-header field seems unusual. Why not<br>
request a code point for PLE itself?<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] the idea was to have a generic/common next-header that can also b=
e used for SRv6 PSN scenarios for other bitstreams PWs such SAToP (RFC4553)=
, CESoP (RFC5086) and CEP (RFC4842) that were previously defined. The commo=
n EVPN-VPWS control plane aspects
 for =C2=A0example are covered in=C2=A0<a href=3D"https://datatracker.ietf.=
org/doc/html/draft-schmutzer-bess-bitstream-vpws-signalling" target=3D"_bla=
nk">https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-bitstream-vp=
ws-signalling</a>=C2=A0=C2=A0</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 5.1.2:<br>
<br>
If the L bit is set, the payload of the packet would seem to be wholly<br>
irrelevant.=C2=A0 Must the payload be attached? If so, that would seem like=
<br>
a waste of bandwidth.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] good point, however I wonder from a practical perspective, how mu=
ch of use would this temporary extra capacity be? Wouldn=E2=80=99t operator=
s in their capacity planning process always consider the worst case, i.e. t=
hat those high capacity / high value constant
 bitstream elephant flows are always present?</div>
<div><br>
</div>
<div>Other bitstream RFCs did include text that implementations MAY omit th=
e payload for packets with L-bit set. If the WG thinks this has value, we c=
an add it</div>
<div><br>
</div>
<blockquote type=3D"cite">
<div>
<div>Section 6.2:<br>
<br>
OLD<br>
<br>
The PLE payload size MUST be a integer number of bytes.<br>
<br>
NEW<br>
<br>
The PLE payload size MUST be an integer number of bytes.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] done</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 7.2.2:<br>
<br>
OLD<br>
<br>
The CE-bound NSP function will continue to inject the appropriate<br>
native downstream fault indication signal until a pre-configured<br>
amount of payloads is stored in the jitter buffer.<br>
<br>
NEW<br>
<br>
The CE-bound NSP function will continue to inject the appropriate<br>
native downstream fault indication signal until a pre-configured<br>
amount of payload is stored in the jitter buffer.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] done</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 7.3:<br>
<br>
OLD<br>
<br>
UAS-PLE SHALL be counted after configurable number of consecutive<br>
SES-PLE have been observed, ...<br>
<br>
NEW<br>
<br>
UAS-PLE SHALL be counted after a configurable number of consecutive<br>
SES-PLE have been observed, ...<br>
</div>
</div>
</blockquote>
<div><br>
</div>
[cs] done</div>
<div><br>
<blockquote type=3D"cite">
<div>
<div>You write that &quot;PLE SHOULD provide the following functions to mon=
itor<br>
the network performance to be inline with expectations of transport<br>
network operators.&quot; =C2=A0All well and good.=C2=A0 However, more consi=
deration<br>
for the expectations of packet switched network operators would very<br>
much be in order. How this is done is up to you, but more information<br>
is definitely needed from an operational perspective.<br>
<br>
>From the near-end, I would like to see something like:<br>
=C2=A0=C2=A0=C2=A0=C2=A0- Current fault status and explanation<br>
=C2=A0=C2=A0=C2=A0=C2=A0- Time of last fault<br>
=C2=A0=C2=A0=C2=A0=C2=A0- Time of last good data<br>
=C2=A0=C2=A0=C2=A0=C2=A0- Media specific link details (e.g., loss of signal=
 but no loss<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0of light; signal but errors; FEC statis=
tics)<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] I have enhanced this part of the document to now have two section=
s =E2=80=9CPLE performance monitoring=E2=80=9D and =E2=80=9CPLE Fault Manag=
ement=E2=80=9D. Can you please have a look at the new -10 revision and let =
me know if that provides enough detail?</div>
<br>
<blockquote type=3D"cite">
<div>
<div>For the far-end, I would also like to see similar data.=C2=A0 I was<br=
>
expecting a similar far-end requirement for transport network<br>
operators, beyond just a comment about the R bit.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
[cs] we are following the lead of other bitstream PWs already defined. In p=
articular RFC4842 (CEP) which also only defines far-end fault indication (R=
 bit).=C2=A0</div>
<div><br>
</div>
<div>I guess your point is =E2=80=9Ccan we do better?&quot;. OTN (G.709) wh=
ich is somewhat supposed to be mimicking by PLE does provide Backward Error=
 Indication (BEI). But OTN has the luxury of lots of overhead bytes that ca=
n be used for doing that but also it is a TDM
 technology where you deal with bit errors in frames/timeslots.</div>
<div><br>
</div>
<div>To do the same in PLE we would need some piece of overhead that allows=
 the far-end to Indicate lost packets. Using some unused parts of the contr=
ol word? Or something else? =E2=80=A6 I wonder if this is worth the effort?=
 I tend to think, no.</div>
<div><br>
</div>
<div>Maybe a good reference point to judge this is that ITU also didn&#39;t=
 specify =E2=80=9CErrored Seconds (ES)=E2=80=9D for ethernet (i.e. a 1 seco=
nd interval with only a few packets being lost), just &quot;Severely Errore=
d Seconds (SES)=E2=80=9D which is inline with PLE communication far-end
 packet loss state (PLOS) via the R bit</div>
<div><a href=3D"https://www.itu.int/rec/T-REC-Y.1563/en" target=3D"_blank">=
https://www.itu.int/rec/T-REC-Y.1563/en</a><br>
</div>
<div></div>
<div><br>
</div>
<div><br>
<blockquote type=3D"cite">
<div>
<div>This data MUST be provided by management interface and SHOULD be<br>
provided by a YANG model, which can be out of scope for this document.<br>
<br>
If a signaling protocol is involved, it should provide its own<br>
operational indications. You should call this out.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] as with other bitstream PW specs before, the signalling protocol =
details are defined as out of scope in section 7.1 and are covered in dedic=
ated documents =E2=80=A6 so I assume that would also mean we can leave this=
 to be covered in the respect documents,
 right?</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 8:<br>
<br>
I believe that your point here is that you require low jitter and low<br>
loss. That much I agree with. There are, however, many ways of<br>
accomplishing this, so I think that Diffserv is not a &#39;MUST&#39; and wo=
uld<br>
better off being a &#39;SHOULD&#39;.=C2=A0 Providers may achieve low jitter=
 and low<br>
loss by over-provisioning, for example, or through traffic engineering<br>
mechanisms.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] I made some change to this section in my response to Tommy Pauly=
=E2=80=99s review. What do you think about this text?</div>
<div><br>
</div>
<div>The PSN providing connectivity between PE devices of a PLE VPWS has to=
 ensure low jitter and low loss. The exact mechanisms used are beyond the s=
cope of this document and may evolve over time. Possible options, but not e=
xhaustively, are a Diffserv-enabled
 [RFC2475] PSN with a per domain behavior [RFC3086] supporting Expedited Fo=
rwarding [RFC3246]. Traffic-engineered paths through the PSN with bandwidth=
 reservation and admission control applied. Or capacity over-provisioning.<=
/div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 9:<br>
<br>
If a signaling protocol is used, then it is responsible for its own<br>
security.=C2=A0 You should call this out.<br>
<br>
Please discuss SRv6 security.<br>
<br>
You make a point of only accepting data from &#39;valid interfaces&#39;.<br=
>
However, this is somewhat challenging as you have no authentication<br>
mechanisms in this proposal. The receiver is wholly dependent on<br>
data plane security. If you want to provide a more secure proposal, I<br>
would suggest adding a cryptographic authentication mechanism.<br>
Preferably one that provides protection against replay attacks.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] With regards to authentication. We are following the lead of othe=
r PW RFCs that use the same / a similar sentence as below and some pointers=
 to security considerations for the relevant PSNs. Isn=E2=80=99t that enoug=
h?</div>
<div><br>
</div>
</div>
</div>
<div>
<div>
<div>PLE does not enhance or detract from the security performance of the u=
nderlying PSN. It relies upon the PSN mechanisms for encryption, integrity,=
 and authentication whenever required.</div>
</div>
</div>
<div>
<div>
<div><br>
</div>
<div>[cs] On the point of =E2=80=9Cvalid interfaces=E2=80=9D I also replied=
 to Christian H. My bad I was taking a MPLS specific text from RFC7432 and =
made it generic. I changed the section to now have the relevant data plane =
text in one place as follows</div>
<div><br>
</div>
<div>NEW</div>
<div>
<div>The PSN is assumed to be trusted and secure. Considerations about the =
MPLS core network outlined in [RFC4381] are applicable.</div>
<div><br>
</div>
<div>For MPLS based PSNs, one of the requirements for protecting the data p=
lane is that the MPLS packets be accepted only from valid interfaces. For a=
 PE, valid interfaces comprise links from other routers in the PE&#39;s own=
 AS. For an ASBR, valid interfaces comprise
 links from other routers in the ASBR&#39;s own AS, and links from other AS=
BRs in ASes that have instances of a given PLE PWs. It is especially import=
ant in the case of multi-AS PLE PWs that one accepts PLE packets only from =
valid interfaces.</div>
<div><br>
</div>
<div>When a Segment Routing (SR) based PSN is used (MPLS or SRv6) the consi=
derations in Section 8 of [RFC8402] and Section 9.3 of [RFC9252] are applic=
able.</div>
</div>
<div><br>
</div>
<br>
<blockquote type=3D"cite">
<div>
<div>Section 12:<br>
<br>
I&#39;m not understanding the distinction that you&#39;re making between<br=
>
informative and normative. Why is SONET normative, but Fibre Channel<br>
informative? Why is PWE3 normative?=C2=A0 Please review all of your<br>
references.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>[cs] changed to informative, also went through the references and made=
 changes where applicable</div>
</div>
<br>
</div>
</div>
</div>

</blockquote></div>

--0000000000002cbd7206274b8b10--


--===============2934290302252489053==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls
aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBhbHMtbGVhdmVAaWV0Zi5vcmcK

--===============2934290302252489053==--