[Pals] Re: Opsdir last call review of draft-ietf-pals-ple-09
Tony Li <[email protected]> Mon, 25 Nov 2024 16:53:15 -0800
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <[email protected]> |
--===============8744091249064949459== Content-Type: multipart/alternative; boundary="Apple-Mail=_3784F92A-73ED-44C6-B6C9-354E161C7C10" --Apple-Mail=_3784F92A-73ED-44C6-B6C9-354E161C7C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Andy, Christian, Thank you for the updates. I=E2=80=99ve reviewed the changes and will = mark this as Ready. Several of your responses below are extremely helpful and material and I = would like to encourage you to include these in the document. However, = that=E2=80=99s wholly optional at this point. Regards, Tony > On Nov 19, 2024, at 2:27=E2=80=AFPM, Andrew G. Malis = <[email protected]> wrote: >=20 > Tony, >=20 > 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. >=20 > Thanks, > Andy >=20 >=20 > On Tue, Nov 5, 2024 at 2:05=E2=80=AFAM Christian Schmutzer (cschmutz) = <[email protected] <mailto:[email protected]>> wrote: >> Hi Tony, >>=20 >> 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=20 >>=20 >> Christian=20 >>=20 >>> On 21.10.2024, at 21:55, Tony Li via Datatracker <[email protected] = <mailto:[email protected]>> wrote: >>>=20 >>> Reviewer: Tony Li >>> Review result: Has Issues >>>=20 >>> OPSDIR Last Call Review of draft-ietf-pals-ple >>>=20 >>> Reviewer: Tony Li >>> Status: >>>=20 >>> Overall: >>>=20 >>> Details: >>>=20 >>> Section 1: >>>=20 >>> Please expand the acronyms PE and CE on first use. >>>=20 >>> 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. >>=20 >> [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 following paragraphs, see also subsequent comments >>=20 >> OLD >> This document describes a method called Private Line Emulation (PLE) = for encapsulating high-speed bit-streams as Virtual Private Wire Service = (VPWS) 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. >>=20 >> NEW >> This document describes a method called Private Line Emulation (PLE) = for encapsulating high-speed bit-streams as Virtual Private Wire Service = (VPWS) over Packet Switched Networks (PSN).=20 >>=20 >> 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. >>=20 >>=20 >> [cs] the comparison to I tried to cover with this sentence >>=20 >> 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 = is 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/SDH layer network, whereas CEP does operate at the same level = and peer with the SONET/SDH layer network. >>=20 >>=20 >>> 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? >>=20 >> [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 = EAPOL (IEEE802.1x) for MACSEC not being passed. I tried to cover this in = a more generic way with the following sentence >>=20 >> 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 = Metro Ethernet Forum (MEF) specifications. >>=20 >>=20 >>> Section 3.2: >>>=20 >>> OLD >>>=20 >>> After the NSP the IWF is generating the payload of the VPWS which is >>> carried via a PSN tunnel. >>>=20 >>> NEW >>>=20 >>> After the NSP, the IWF is generating the payload of the VPWS which = is >>> carried via a PSN tunnel. >>=20 >> [cs] done >>=20 >>> Section 4.3: >>>=20 >>> 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. >>=20 >> [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.=20 >>=20 >> 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 which 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 those 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. >>=20 >>> Section 5.1: >>>=20 >>> Using BIT-EMU in the SRH next-header field seems unusual. Why not >>> request a code point for PLE itself? >>=20 >> [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 common EVPN-VPWS control plane aspects for example are = covered in = https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-bitstream-vpws-= signalling =20 >>=20 >>> Section 5.1.2: >>>=20 >>> 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. >>=20 >> [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? >>=20 >> 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 can add it >>=20 >>> Section 6.2: >>>=20 >>> OLD >>>=20 >>> The PLE payload size MUST be a integer number of bytes. >>>=20 >>> NEW >>>=20 >>> The PLE payload size MUST be an integer number of bytes. >>=20 >> [cs] done >>=20 >>> Section 7.2.2: >>>=20 >>> OLD >>>=20 >>> 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. >>>=20 >>> NEW >>>=20 >>> 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. >>=20 >> [cs] done >>=20 >>> Section 7.3: >>>=20 >>> OLD >>>=20 >>> UAS-PLE SHALL be counted after configurable number of consecutive >>> SES-PLE have been observed, ... >>>=20 >>> NEW >>>=20 >>> UAS-PLE SHALL be counted after a configurable number of consecutive >>> SES-PLE have been observed, ... >>=20 >> [cs] done >>=20 >>> 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. >>>=20 >>> =46rom 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) >>=20 >> [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 Management=E2=80=9D. Can you please have a look at the new -10 = revision and let me know if that provides enough detail? >>=20 >>> 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. >>=20 >> [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).=20 >>=20 >> I guess your point is =E2=80=9Ccan we do better?". OTN (G.709) which = 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 = can be used for doing that but also it is a TDM technology where you = deal with bit errors in frames/timeslots. >>=20 >> 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 control word? Or something else? =E2=80=A6 I wonder if this is worth = the effort? I tend to think, no. >>=20 >> Maybe a good reference point to judge this is that ITU also didn't = specify =E2=80=9CErrored Seconds (ES)=E2=80=9D for ethernet (i.e. a 1 = second interval with only a few packets being lost), just "Severely = Errored Seconds (SES)=E2=80=9D which 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 >>=20 >>=20 >>> 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. >>>=20 >>> If a signaling protocol is involved, it should provide its own >>> operational indications. You should call this out. >>=20 >> [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 = leave this to be covered in the respect documents, right? >>=20 >>> Section 8: >>>=20 >>> 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. >>=20 >> [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? >>=20 >> 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 not 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. >>=20 >>> Section 9: >>>=20 >>> If a signaling protocol is used, then it is responsible for its own >>> security. You should call this out. >>>=20 >>> Please discuss SRv6 security. >>>=20 >>> 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. >>=20 >> [cs] With regards to authentication. We are following the lead of = other 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 enough? >>=20 >> 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. >>=20 >> [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 >>=20 >> NEW >> The PSN is assumed to be trusted and secure. Considerations about the = MPLS core network outlined in [RFC4381] are applicable. >>=20 >> For MPLS based PSNs, one of the requirements for protecting the data = plane 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. For 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. >>=20 >> 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. >>=20 >>=20 >>> Section 12: >>>=20 >>> 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. >>=20 >> [cs] changed to informative, also went through the references and = made changes where applicable >>=20 --Apple-Mail=_3784F92A-73ED-44C6-B6C9-354E161C7C10 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: = after-white-space;"><div><br></div>Andy, = Christian,<div><br></div><div>Thank you for the updates. I=E2=80=99v= e reviewed the changes and will mark this as = Ready.</div><div><br></div><div>Several of your responses below are = extremely helpful and material and I would like to encourage you to = include these in the document. However, that=E2=80=99s wholly = optional at this = point.</div><div><br></div><div>Regards,</div><div>Tony</div><div><br = id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote = type=3D"cite"><div>On Nov 19, 2024, at 2:27=E2=80=AFPM, Andrew G. Malis = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div = dir=3D"ltr">Tony,<div><br></div><div>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.</div><div><br></div><div>Thanks,</div><div>Andy</div><div><br></di= v></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) <<a = href=3D"mailto:[email protected]">[email protected]</a>> = wrote:<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 comments inline via [cs]. Mentioned changes are incorporated in the = -10 revision I just published </div> <div><br> </div> <div>Christian </div> <div> <div><br> <blockquote type=3D"cite"> <div>On 21.10.2024, at 21:55, Tony Li via Datatracker <<a = href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>> 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? This = is<br> 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 following paragraphs, see also subsequent comments</div> <div><br> </div> <div>OLD</div> <div> <div>This document describes a method called Private Line Emulation = (PLE) for encapsulating high-speed bit-streams as Virtual Private Wire = Service (VPWS) 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.</div> <div><br> </div> <div>NEW</div> <div> <div>This document describes a method called Private Line Emulation = (PLE) for encapsulating high-speed bit-streams as Virtual Private Wire = Service (VPWS) over Packet Switched Networks (PSN). </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 signal 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 = 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 is 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/SDH layer network, whereas CEP does operate at the same level and peer with the SONET/SDH = layer 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'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 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 = EAPOL (IEEE802.1x) for MACSEC not being passed. I tried to cover this in a more generic way with the following = sentence</div> <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 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 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? I would hate to see = us<br> going to the effort of creating standards that don'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 = networks. However while lots of SDH networks got dismantled already, the = rate of SONET network decommissioning is slower than someone would = expect. </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 moving from non-coherent (direct detect) optical = transmission which is generally limited to 10Gbps per wavelength, to coherent transmission which 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 those 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.</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 be used for SRv6 PSN scenarios for other bitstreams PWs such SAToP = (RFC4553), CESoP (RFC5086) and CEP (RFC4842) that were previously = defined. The common EVPN-VPWS control plane aspects for example are covered in <a = href=3D"https://datatracker.ietf.org/doc/html/draft-schmutzer-bess-bitstre= am-vpws-signalling" = target=3D"_blank">https://datatracker.ietf.org/doc/html/draft-schmutzer-be= ss-bitstream-vpws-signalling</a> </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. 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 = 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?</div> <div><br> </div> <div>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 can 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 "PLE SHOULD provide the following functions to = monitor<br> the network performance to be inline with expectations of transport<br> network operators." All well and good. However, more = consideration<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> =46rom the near-end, I would like to see something like:<br> - Current fault status and explanation<br> - Time of last fault<br> - Time of last good data<br> - Media specific link details (e.g., loss of = signal but no loss<br> of light; signal but errors; FEC = statistics)<br> </div> </div> </blockquote> <div><br> </div> <div>[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 Management=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. 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 particular RFC4842 (CEP) which also only defines far-end fault = indication (R bit). </div> <div><br> </div> <div>I guess your point is =E2=80=9Ccan we do better?". OTN (G.709) = which 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 can 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 control 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't = specify =E2=80=9CErrored Seconds (ES)=E2=80=9D for ethernet (i.e. a 1 = second interval with only a few packets being lost), just "Severely = Errored 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 dedicated 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 'MUST' and = would<br> better off being a 'SHOULD'. 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 scope of this document and may evolve over time. Possible options, = but not 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.</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. You should call this out.<br> <br> Please discuss SRv6 security.<br> <br> You make a point of only accepting data from 'valid interfaces'.<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 = other 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 enough?</div> <div><br> </div> </div> </div> <div> <div> <div>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.</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 plane 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. For 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.</div> <div><br> </div> <div>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.</div> </div> <div><br> </div> <br> <blockquote type=3D"cite"> <div> <div>Section 12:<br> <br> I'm not understanding the distinction that you're making between<br> informative and normative. Why is SONET normative, but Fibre Channel<br> informative? Why is PWE3 normative? 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> </div></blockquote></div><br></div></body></html>= --Apple-Mail=_3784F92A-73ED-44C6-B6C9-354E161C7C10-- --===============8744091249064949459== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBhbHMtbGVhdmVAaWV0Zi5vcmcK --===============8744091249064949459==--