|
Hi Greg.... CC per se has little inherent value....but that is
historical. CV does have proper value. CV and RDI however should
NOT be mutually dependent messages as the latter cannot be meaningfully associated
with (a CV flow on) p2mp connections. And BTW AIS (or FDI) has no value whatsoever in any pkt
networks....obvious for cl-ps but this is just as true for co-ps. It has
limited value in the co-cs mode with PVCs, where its origins stem from the fact
that (i) the fixed time resource (time-slot) allocated by a server to a client
link-connection has to be filled with something and (ii) that ‘something’
became binary all 1s simply because that was what the early TTL silicon
technology in the PDH produced on failure, ie + 5V. But when one considers
co-cs SVCs then AIS even here starts to look very silly....the underlying key point
being that *unless* there is a permanently fixed binding between a server and
its clients (even after server failure, ie client does not attempt to re-route
in *its* layer network) then where does the server know who to send the AIS
(FDI) to? AIS (FDI) should be strongly deprecated in all future work on
OAM. It took me a little time to fully realise this point. regards, Neil From: pwe3-bounces@xxxxxxxx
[mailto:pwe3-bounces@xxxxxxxx] On Behalf Of Greg Mirsky Dear Nabil, RDI Remote
Defect Indication for Continuity Check Message RDI Reverse
Defect Indication AFAIK, the latter form is the
interpretation used by both IEEE 802.1ag and Y.1731. How useful is the first
form? Regards, Greg On Fri, Jan 4, 2013 at 8:17 AM, Bitar, Nabil N <nabil.n.bitar@xxxxxxxxxxx>
wrote: Hi
Dave, Related
to abbreviations comment below and to be clearer, I renamed the original
terminology section to "Abbreviations and Terminology". I also
created a subsection called "Abbreviations" ,and
"Terminology" became the second subsection. Here iis how the
edits look 3. Abbreviations and Terminology
3.1. Abbreviations
AIS Alarm Indication Signal
AC Attachment Circuit
BFD Bidirectional Forwarding Detection
CC Continuity Check
CCM Continuity Check Message
CE Customer Equipment
CV Connectivity Verification E-LMI
Ethernet Local Management Interface
EVC Ethernet Virtual Circuit
LDP Label Distribution Protocol
LoS Loss of Signal MA
Maintenance Association
MD Maintenance Domain
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance End Point
MIP Maintenance End Point
MPLS Multiprotocol Label Switching MS-PW
Multi-Segment Pseudowire
NS Native Service
OAM Operations, Administration, and Maintenance
PE Provider Edge
PSN Packet Switched Network
PW Pseudowire
RDI Remote Defect Indication for Continuity Check Message RDI
Reverse Defect Indication
S-PE Switching Provider Edge TLV
Type Length Value
T-PE Terminating Provider Edge 3.2. Terminology
This document uses
the following terms with corresponding definitions: - MD Level:
Maintenance Domain (MD) Level which identifies a value in the range of 0-7
associated with Ethernet OAM frame. MD Level identifies the span of the
Ethernet OAM frame. -
MEP: Maintenance End Point is responsible for origination and
termination of OAM frames for a given MEG. - MIP:
Maintenance Intermediate Point is located between
peer MEPs and can process OAM frames but does not initiate or terminate them. Further, this
document also uses the terminology and conventions used in [RFC6310]. Thanks, Nabil From:
<Bitar>,
Nabil N <nabil.n.bitar@xxxxxxxxxxxxxxx> Hi
Dave, Sorry
for a late reply addressing your comments. Please, see inline. Thanks, Nabil From:
"Black,
David" <david.black@xxxxxxx> I am the assigned Gen-ART reviewer for this draft. For background
on Gen-ART, please Reviewer: David L. Black <NB>
Thanks. This
draft covers defect behavior for Ethernet pseudowires, including
defect state mapping and PE defect reporting behavior. The
draft is generally in good shape. I found a few minor nits. 1) The draft uses a
lot of acronyms - while each acronym appears to be expanded on
first use, an additional section near the start of the draft listing all
of them would be helpful. <NB>
Done. 2) There's a
typo in the first paragraph of section 2:
covers the following Ethernet OAM (Opertaions, Administration and Opertaions ->
Operations. <NB>
Thanks. Done. 3)
The following normative reference is incomplete - please add additional information
that will enable a reader to locate the referenced document:
[MEF16] "Ethernet Local Management Interface", MEF16, January
2006. [MEF16] "Ethernet Local Management Interface", Metro
Ethernet Forum Technical Specification MEF16, January 2006. <NB>
changed it to : 4) idnits
2.12.13 did not like the pagination:
== The page length should not exceed 58 lines per page, but there was 22 <NB>
That will be fixed. Thanks, --David ----------------------------------------------------
|