[Pals] [Shepherding AD review] review of draft-ietf-pals-p le-07.txt
"Gunter van de Velde \(Nokia\)" <[email protected]> Wed, 25 Sep 2024 15:39:19 +0000
| Newsgroups | gmane.ietf.pwe3 |
|---|---|
| Message-ID | <AS1PR07MB8589DEB0A106FEF9E78F84FEE0692@AS1PR07MB8589.eurprd07.prod.outlook.com> |
--===============0708033181635694434==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_AS1PR07MB8589DEB0A106FEF9E78F84FEE0692AS1PR07MB8589eurp_"
--_000_AS1PR07MB8589DEB0A106FEF9E78F84FEE0692AS1PR07MB8589eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
# Gunter Van de Velde, RTG AD, comments for draft-ietf-pals-ple-07
Hi Authors,
The review details some questions and some observations that occurred when =
going through the document.
Many thanks to produce this document and all the work to bring it in the cu=
rrent quality technological write-up.
The referenced line numbers are derived from the idnits tool:
https://author-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/archive=
/id/draft-ietf-pals-ple-07.txt
#GENERIC COMMENTS
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
## This draft is not an easy read. It has significant very specific technol=
ogies and requires rather in-depth understanding.
## I believe that the document is nearly ready for the next step in the IES=
G processing pipeline after looking through the mostly editorial comments.
#DETAILED COMMENTS
#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
##
134 (SAToP) defined in [RFC4553]. The applicability is expanded b=
eyond
135 the narrow set of PDH interfaces (T1, E1, T3 and E3) to allow =
the
136 transport of signals from many different technologies such as
GV> Maybe expand that PDH =3D Plesiochronous Digital Hierarchy (PDH) standa=
rd in the terminology section
382 4. Emulated Services
383
384 This specification does describe the emulation of services fro=
m a
385 wide range of technologies such as TDM, Ethernet, Fibre Channe=
l or
386 OTN as bit stream or structured bit stream as defined in
387 Section 3.3.3 of [RFC3985] and Section 3.3.4 of [RFC3985].
GV> proposed editorial rewrite:
"
This specification describes the emulation of services from a wide range of=
technologies, such as TDM, Ethernet, Fibre Channel, or OTN, as bit streams=
or structured bit streams, as defined in Section 3.3.3 and Section 3.3.4 o=
f RFC3985.
"
661 Over time many different Fibre Channel interface types have be=
en
662 specified in FC-PI-x and FC-FS-x standards with a varying set =
of
663 characteristics such as optional vs mandatory FEC and single-l=
ane vs
664 multi-lane transmission.
GV> are FC-PI-x and FC-FS-x mentioned in the reference section? I did not f=
ind when searching
680 The PSN-bound IWF is mapping the received 8B/10B code stream a=
s is
681 into the basic PLE payload.
GV> s/as is/directly/
767 Note : the use of rate compensation is for further study.
GV> Not sure this comment belongs in a standards track document as written.=
Maybe it should say in addition that it is out-of-scope of this draft
787 Note: Invalid transmission words typically are a consequence o=
f the
788 CE-bound IWF inserting replacement data in case of lost PLE pa=
ckets,
789 or if the far-end PSN-bound NSP function did set sync headers =
to 11
790 due to uncorrectable FEC errors.
GV> What does "set sync headers to 11" exactly mean? is that a value to fil=
l into the headers somewhere?
932 When processing the Upper-Layer header of a packet matching a =
FIB
933 entry locally instantiated as an End.DX1 SID, N does the follo=
wing:
934
935 S01. If (Upper-Layer header type =3D=3D TBA1 (bit-stream) ) {
936 S02. Remove the outer IPv6 header with all its extension he=
aders
937 S03. Forward the remaining frame to the IWF I
938 S04. } Else {
939 S05. Process as per {{Section 4.1.1 of RFC8986}}
940 S06. }
GV> What confused me was how this exactly fits together with the pseudocode=
provided in previous paragraph.
Maybe these should be combined for a full understanding of the target logic=
(similar as in the appendix of [I-D.draft-ietf-spring-srv6-srh-compression=
]
983 * RSV
984
985 These bits are reserved for future use. This field MUST be=
set to
986 zero by the sender and ignored by the receiver.
GV> Maybe it is useful to give the following some thoughts.
The rfc8126 definition of reserved vs unassigned is followed:
Unassigned: Not currently assigned, and available for assignment
via documented procedures. While it's generally clear that
any values that are not registered are unassigned and
available for assignment, it is sometimes useful to
explicitly specify that situation. Note that this is
distinctly different from "Reserved".
Reserved: Not assigned and not available for assignment.
Reserved values are held for special uses, such as to extend
the namespace when it becomes exhausted. "Reserved" is also
sometimes used to designate values that had been assigned
but are no longer in use, keeping them set aside as long as
other unassigned values are available. Note that this is
distinctly different from "Unassigned".
Reserved values can be released for assignment by the change
controller for the registry (this is often the IESG, for
registries created by RFCs in the IETF stream).
"Unassigned" (available for assignment) or "Reserved" (not available unless=
released by an RFC), as described in RFC 8126.
Note: It isn't clear whether "Unused" means "not currently used" or "can ne=
ver be used."
969 * L
970
971 Set by the PE to indicate that data carried in the payload =
is
972 invalid due to an attachment circuit fault. The downstream=
PE
973 MUST play out appropriate replacement data. The NSP MAY in=
ject an
974 appropriate native fault propagation signal.
GV> what does play out exactly mean? (I suspect my english skills confuse m=
e)
Kind Regards,
G/
--_000_AS1PR07MB8589DEB0A106FEF9E78F84FEE0692AS1PR07MB8589eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Aptos;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Aptos",sans-serif;
mso-ligatures:standardcontextual;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:11.0pt;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"en-BE" link=3D"#467886" vlink=3D"#96607D" style=3D"word-wrap:=
break-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"en-BE"># Gunter Van de Velde, RTG AD, =
comments for draft-ietf-pals-ple-07<o:p></o:p></span></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal">Hi Authors,<br>
<br>
<o:p></o:p></p>
<p class=3D"MsoNormal">The review details some questions and some observati=
ons that occurred when going through the document.
<o:p></o:p></p>
<p class=3D"MsoNormal"><o:p> </o:p></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Many thanks to produce this doc=
ument and all the work to bring it in the current quality technological wri=
te-up.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">T</span><span lang=3D"en-BE">he=
referenced line numbers are derived from the idnits tool:<o:p></o:p></span=
></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><a href=3D"https://author-tools=
.ietf.org/api/idnits?url=3Dhttps://www.ietf.org/archive/id/draft-ietf-pals-=
ple-07.txt">https://author-tools.ietf.org/api/idnits?url=3Dhttps://www.ietf=
.org/archive/id/draft-ietf-pals-ple-07.txt</a><o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">#GENERIC COMMENTS<o:p></o:p></s=
pan></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">## This d</span><span lang=3D"E=
N-US">raft </span>
<span lang=3D"en-BE">is not an easy read. It has significant very specific =
technologies and requires rather in-depth understanding.<o:p></o:p></span><=
/p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">## I believe that the document =
is nearly ready for the next step in the IESG processing pipeline after loo=
king through the mostly editorial comments.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">#DETAILED COMMENTS<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">#=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">##<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">134 &nbs=
p; (SAToP) defined in [RFC4553]. The applicability=
is expanded beyond<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">135 &nbs=
p; the narrow set of PDH interfaces (T1, E1, T3 and E3) =
to allow the<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">136 &nbs=
p; transport of signals from many different technologies=
such as<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> Maybe expand that PDH =
=3D Plesiochronous Digital Hierarchy (PDH) standard</span><span lang=3D"EN-=
US"> in the terminology section<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">382 &nbs=
p; 4. Emulated Services<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">383<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">384 &nbs=
p; This specification does describe the emulation of ser=
vices from a<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">385 &nbs=
p; wide range of technologies such as TDM, Ethernet, Fib=
re Channel or<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">386 &nbs=
p; OTN as bit stream or structured bit stream as defined=
in<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">387 &nbs=
p; Section 3.3.3 of [RFC3985] and Section 3.3.4 of [RFC3=
985].<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> proposed editorial rewri=
te:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">"<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">This specification describes th=
e emulation of services from a wide range of technologies, such as TDM, Eth=
ernet, Fibre Channel, or OTN, as bit streams or structured bit streams, as =
defined in Section 3.3.3 and Section
3.3.4 of RFC3985.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">"<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">661 &nbs=
p; Over time many different Fibre Channel interface type=
s have been<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">662 &nbs=
p; specified in FC-PI-x and FC-FS-x standards with a var=
ying set of<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">663 &nbs=
p; characteristics such as optional vs mandatory FEC and=
single-lane vs<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">664 &nbs=
p; multi-lane transmission.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> are FC-PI-x and FC-FS-x =
mentioned in the reference section? I did not find when searching<o:p></o:p=
></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">680 &nbs=
p; The PSN-bound IWF is mapping the received 8B/10B code=
stream as is<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">681 &nbs=
p; into the basic PLE payload.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> s/as is/directly/<o:p></=
o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">767 &nbs=
p; Note : the use of rate compensation is for further st=
udy.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> Not sure this comment be=
longs in a standards track document as written. Maybe it should say in addi=
tion that it is out-of-scope of this draft<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">787 &nbs=
p; Note: Invalid transmission words typically are a cons=
equence of the<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">788 &nbs=
p; CE-bound IWF inserting replacement data in case of lo=
st PLE packets,<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">789 &nbs=
p; or if the far-end PSN-bound NSP function did set sync=
headers to 11<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">790 &nbs=
p; due to uncorrectable FEC errors.<o:p></o:p></span></p=
>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> What does "set sync=
headers to 11" exactly mean? is that a value to fill into the headers=
somewhere?<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">932 &nbs=
p; When processing the Upper-Layer header of a packet ma=
tching a FIB<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">933 &nbs=
p; entry locally instantiated as an End.DX1 SID, N does =
the following:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">934<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">935 &nbs=
p; S01. If (Upper-Layer header type =3D=3D TBA1 (bit-str=
eam) ) {<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">936 &nbs=
p; S02. Remove the outer IPv6 header w=
ith all its extension headers<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">937 &nbs=
p; S03. Forward the remaining frame to=
the IWF I<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">938 &nbs=
p; S04. } Else {<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">939 &nbs=
p; S05. Process as per {{Section 4.1.1=
of RFC8986}}<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">940 &nbs=
p; S06. }<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> What confused me was how=
this exactly fits together with the pseudocode provided in previous paragr=
aph.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">Maybe these should be combined =
for a full understanding of the target logic (similar as in the appendix of=
[I-D.draft-ietf-spring-srv6-srh-compression]<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">983 &nbs=
p; * RSV<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">984<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">985 &nbs=
p; These bits are reserved for future =
use. This field MUST be set to<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">986 &nbs=
p; zero by the sender and ignored by t=
he receiver.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> Maybe it is useful to gi=
ve the following some thoughts.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">The rfc8126 definition of reser=
ved vs unassigned is followed:<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> =
Unassigned: Not currently assigned, and available for assignment<o:p>=
</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; via documented procedures. While =
it's generally clear that<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; any values that are not registered are =
unassigned and<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; available for assignment, it is sometim=
es useful to<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; explicitly specify that situation. =
; Note that this is<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; distinctly different from "Reserve=
d".<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> =
Reserved: Not assigned and not available for assignment.<o:p></o:p></=
span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; Reserved values are held for special us=
es, such as to extend<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; the namespace when it becomes exhausted=
. "Reserved" is also<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; sometimes used to designate values that=
had been assigned<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; but are no longer in use, keeping them =
set aside as long as<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; other unassigned values are available.&=
nbsp; Note that this is<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; distinctly different from "Unassig=
ned".<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; Reserved values can be released for ass=
ignment by the change<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; controller for the registry (this is of=
ten the IESG, for<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"> &=
nbsp; registries created by RFCs in the IETF =
stream).<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">"Unassigned" (availab=
le for assignment) or "Reserved" (not available unless released b=
y an RFC), as described in RFC 8126.
<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">Note: It isn't clear whether &q=
uot;Unused" means "not currently used" or "can never be=
used."<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">969 &nbs=
p; * L<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">970<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">971 &nbs=
p; Set by the PE to indicate that data=
carried in the payload is<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">972 &nbs=
p; invalid due to an attachment circui=
t fault. The downstream PE<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">973 &nbs=
p; MUST play out appropriate replaceme=
nt data. The NSP MAY inject an<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">974 &nbs=
p; appropriate native fault propagatio=
n signal.<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE">GV> what does play out exact=
ly mean? (</span><span lang=3D"EN-US">I suspect</span><span lang=3D"en-BE">=
my english skills confuse me)<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">Kind Regards,<o:p></o:p></span>=
</p>
<p class=3D"MsoNormal"><span lang=3D"EN-US">G/<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"en-BE"><o:p> </o:p></span></p>
</div>
</body>
</html>
--_000_AS1PR07MB8589DEB0A106FEF9E78F84FEE0692AS1PR07MB8589eurp_--
--===============0708033181635694434==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KUGFscyBtYWls
aW5nIGxpc3QgLS0gcGFsc0BpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBhbHMtbGVhdmVAaWV0Zi5vcmcK
--===============0708033181635694434==--