Subject: Re: Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

From: "Bitar, Nabil N" <[email-masked]>
Date: Wed, 2 Jan 2013 11:28:41 -0500

Hi Dave,
Sorry for a late reply addressing your comments. Please, see inline.

Thanks,
Nabil

From: "Black, David" <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 20, 2012 8:57 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>, Sagessi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please
see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-pwe3-mpls-eth-oam-iwk-06
Reviewer: David L. Black
Review Date: August 20, 2012
IETF LC End Date: August 20, 2012

Summary:
This draft is basically ready for publication, but has nits that
should be fixed before publication.

<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
     longer pages, the longest (page 1) being 61 lines

<NB> That will be fixed.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]<mailto:[email-masked]>        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Fri, 4 Jan 2013 11:17:28 -0500

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 <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 2, 2013 11:28 AM
To: "Black, David" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Bitar, Nabil N" <[email-masked]<mailto:[email-masked]>>, Sagessi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

Hi Dave,

Thanks,
Nabil

Summary:

<NB> Thanks.

<NB> Done.

<NB> Thanks. Done.

<NB> changed it to :

<NB> That will be fixed.

Thanks,
--David

---

From: Huub van Helvoort <[email-masked]>
Date: Fri, 04 Jan 2013 17:30:14 +0100

All,

> MEP Maintenance End Point

MEP  "ME End Point" or "Maintenance Entity End Point"
> MIP  Maintenance End Point

MIP  "ME Intermediate Point" or "Maintenance Entity Intermediate Point"

> - MEP:  Maintenance End Point is responsible for origination and
> termination of OAM frames for a given MEG.

- MEP:  Maintenance Entity End Point is responsible for origination

> - MIP: Maintenance Intermediate Point is located between peer MEPs and
> can process OAM frames but does not initiate or terminate them.

- MIP: Maintenance Entity Intermediate Point is located between

Regards, Huub.

---

From: Huub van Helvoort <[email-masked]>
Date: Mon, 07 Jan 2013 22:35:24 +0100

Hello Nabil,

Greg is almost right.

RDI == Remote Defect Indication

This is the abbreviation used in IEEE 802.1ag, Y.1731, G.707, G.8121
and rfc6428.

Regards, Huub.
====

> can we avoid different interpretation of the same abbreviation (RDI):
>
> 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
> <[email-masked] <mailto:[email-masked]>> 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____
>
>     AISAlarm Indication Signal____
>
>     ACAttachment Circuit____
>
>     BFDBidirectional Forwarding Detection____
>
>     CCContinuity Check____
>
>     CCMContinuity Check Message____
>
>     CECustomer Equipment____
>
>     CVConnectivity Verification____
>
>     E-LMI Ethernet Local Management Interface____
>
>     EVCEthernet Virtual Circuit____
>
>     LDPLabel Distribution Protocol____
>
>     LoSLoss of Signal____
>
>     MAMaintenance Association____
>
>     MDMaintenance Domain____
>
>     MEMaintenance Entity____
>
>     MEGMaintenance Entity Group____
>
>     MEPMaintenance End Point____
>
>     MIPMaintenance End Point____
>
>     MPLSMultiprotocol Label Switching____
>
>     MS-PW Multi-Segment Pseudowire____
>
>     NSNative Service____
>
>     OAMOperations, Administration, and Maintenance____
>
>     PEProvider Edge____
>
>     PSNPacket Switched Network____
>
>     PWPseudowire____
>
>     RDIRemote Defect Indication for Continuity Check Message____
>
>     S-PESwitching Provider Edge____
>
>     TLVType Length Value____
>
>     T-PETerminating 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: t.p. <[email-masked]>
Date: Tue, 8 Jan 2013 10:03:19 +0000

I notice too that MEP and MIP are incorrectly expanded:-(

Tom Petch

----- Original Message -----
From: "Huub van Helvoort" <[email-masked]>
To: "Greg Mirsky" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Bitar, Nabil N"
<[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, January 07, 2013 9:35 PM
Subject: Re: [PWE3] Gen-ART review of
draft-ietf-pwe3-mpls-eth-oam-iwk-06

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 08 Jan 2013 11:17:41 +0100

Dear Greg,

You responded:

 > IEEE 802.1ag interprets MEP and MIP as:
 >
 >   * Maintenance association End Point
 >   * Maintenance domain Intermediate Point

Indeed, and MA == MEG, MD == ME.

 > Y.1731 interprets them as:
 >
 >   * Maintenance entity group (MEG) End Point
 >   * MEG Intermediate Point

Correct.

 > The reference to MD Level implies reference to IEEE 802.1ag, at least as
 > use of terminology, since Y.1731 doesn't have Maintenance Domain
 > construct and refers to the same value as MEG Level. I'd suggest to
 > follow one model, IEEE 802.1ag or Y.1731, terminology throughout the
 > document so that there's no need for re-mapping. I think that it is
 > easier to follow Y.1731.

I agree that this is the best.
These are the abbreviations used for MPLS-TP too.

Best regards, Huub.

 > On Fri, Jan 4, 2013 at 8:30 AM, Huub van Helvoort <[email-masked]
 > <mailto:[email-masked]>> wrote:
 >
 >     All,
 >

---

From: Loa Andersson <[email-masked]>
Date: Tue, 08 Jan 2013 12:01:52 +0100

Greg,

RFC 6428 expands RDI as:

    RDI: Remote Defect Indication

/Loa

On 2013-01-07 21:51, Greg Mirsky wrote:
> Dear Nabil,
>     To: "Black, David" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "Bitar, Nabil N"
>     <[email-masked]
>     <mailto:[email-masked]>>, Sagessi <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>
>     From: "Black, David" <[email-masked] <mailto:[email-masked]>>
>     To: "[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[email-masked]>>, "Bitar, Nabil
>     N" <[email-masked]
>     <mailto:[email-masked]>>, Sagessi <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     Cc: "Black, David" <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>,
>     "[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     see the FAQ at
>     <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
>     [MEF16] "Ethernet Local Management Interface", Metro Ethernet Forum
>     Technical Specification MEF16, January 2006.
>
>     <NB> changed it to :
>
>     4) idnits2.12.13 did not like the pagination:
>
>     +1 (508) 293-7953 <tel:%2B1%20%28508%29%20293-7953>             FAX:
>     +1 (508) 293-7786 <tel:%2B1%20%28508%29%20293-7786>
>     [email-masked] <mailto:[email-masked]>        Mobile: +1
>     (978) 394-7754 <tel:%2B1%20%28978%29%20394-7754>
>     _______________________________________________
>     pwe3 mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/pwe3
>
>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 7 Jan 2013 12:47:58 -0800

Dear Huub, Nabil, et al.,
IEEE 802.1ag interprets MEP and MIP as:

   - Maintenance association End Point
   - Maintenance domain Intermediate Point

   - Maintenance entity group (MEG) End Point
   - MEG Intermediate Point

The reference to MD Level implies reference to IEEE 802.1ag, at least as
use of terminology, since Y.1731 doesn't have Maintenance Domain construct
and refers to the same value as MEG Level. I'd suggest to follow one model,
IEEE 802.1ag or Y.1731, terminology throughout the document so that there's
no need for re-mapping. I think that it is easier to follow Y.1731.

Regards,
Greg

On Fri, Jan 4, 2013 at 8:30 AM, Huub van Helvoort <[email-masked]>wrote:

> ______________________________**_________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/pwe3<https://www.ietf.org/mailman/listinfo/pwe3>
>

---

From: Greg Mirsky <[email-masked]>
Date: Mon, 7 Jan 2013 12:51:15 -0800

Dear Nabil,

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 <[email-masked]>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****
>
>    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.****
>
> termination of OAM frames for a given MEG.****
>
> 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 <[email-masked]>
> To: "Black, David" <[email-masked]>, "[email-masked]" <
> [email-masked]>, "Bitar, Nabil N" <[email-masked]>,
> Sagessi <[email-masked]>, "[email-masked]" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> From: "Black, David" <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "Bitar, Nabil N" <
> [email-masked]>, Sagessi <[email-masked]>, "
> [email-masked]" <[email-masked]>
> Cc: "Black, David" <[email-masked]>, "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> [email-masked]        Mobile: +1 (978) 394-7754

---

From: <[email-masked]>
Date: Mon, 7 Jan 2013 22:25:34 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: 07 January 2013 20:51
To: Bitar, Nabil N
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

Dear Nabil,

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 <[email-masked]<mailto:[email-masked]>> 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

   AC    Attachment Circuit

   CC    Continuity Check

   CE    Customer Equipment

   LoS   Loss of Signal

   MD    Maintenance Domain

   ME    Maintenance Entity

   NS    Native Service

   PE    Provider Edge

   PW    Pseudowire

   TLV   Type Length Value

3.2. Terminology

Thanks,
Nabil

Hi Dave,

Thanks,
Nabil

Summary:

<NB> Thanks.

<NB> Done.

<NB> Thanks. Done.

<NB> changed it to :

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953<tel:%2B1%20%28508%29%20293-7953>             FAX: +1 (508) 293-7786<tel:%2B1%20%28508%29%20293-7786>
[email-masked]<mailto:[email-masked]>        Mobile: +1 (978) 394-7754<tel:%2B1%20%28978%29%20394-7754>
----------------------------------------------------

_______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 8 Jan 2013 16:45:46 +0000

Dear Huub and Loa,
my brain did s/Reverese/Remote/ by itself. Indeed, 802.1ag and Y.1731 use RDI for Remote Defect Indication, and nothing in Reverse. And that how draft-ietf-pwe3-mpls-eth-oam-iwk-06 should expand RDI as well.

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, January 08, 2013 3:02 AM
To: Greg Mirsky
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

Greg,

RFC 6428 expands RDI as:

/Loa

--

                                              +46 767 72 92 13 _______________________________________________

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Mon, 14 Jan 2013 09:35:00 -0500

Hi,
I will folloup on the other emails. Just catching up in reverse order. RDI
(Reverse defect indication) is what is used in RFC 6310 to indicate
failure in the rverse direction from the failure, and this document is
aligned with that. At the same time, RDI as Remote defect indication is
what is used for Ethernet CFM, so the attemot here is to call out
the acronyms used and in this case it is the same acronym that correspond
to two different terminologies, each with its own context identified.

Thanks,
Nabil

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Mon, 14 Jan 2013 09:36:39 -0500

Hi Greg,
Please, see my other email I just sent.

Thanks,
Nabil

From: Gregory Mirsky <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, January 8, 2013 11:45 AM
To: Loa Andersson <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Sagessi <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

Dear Huub and Loa,

        Regards,
                Greg

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, January 08, 2013 3:02 AM
To: Greg Mirsky
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [PWE3] Gen-ART review of draft-ietf-pwe3-mpls-eth-oam-iwk-06

Greg,

RFC 6428 expands RDI as:

/Loa

On 2013-01-07 21:51, Greg Mirsky wrote:
> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>
>     Hi Dave,
>     From: <Bitar>, Nabil N <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>
>     To: "Black, David" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
>     <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>, Sagessi <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     Cc: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>"
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     From: "Black, David" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     To: "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>"
>     <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>, "Bitar, Nabil
>     N" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>, Sagessi <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>
>     Cc: "Black, David" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>,
>     "[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>
>     <mailto:[email-masked]>>
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>        Mobile: +1
>     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

--

Loa Andersson                         email: [email-masked]<mailto:[email-masked]>
Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13 _______________________________________________
pwe3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Mon, 14 Jan 2013 11:06:36 -0500

Hi,
In agreement with below definitions in 802.1ag and Y.1731  and their
mappings.Will align the terminology definition in the draft with that of
802.1ag. Y.1731 has the terminology mapping to 802.1ag's as well.

Thanks,
Nabil

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 16 Jan 2013 11:17:29 +0100

Hello Nabil,

You replied:

> I will folloup on the other emails. Just catching up in reverse order.

 > RDI (Reverse defect indication) is what is used in RFC 6310 to indicate
> aligned with that.

RDI is used to indicate that the *remote* end has detected a defect
in the forward direction from local node towards the remote node.
In the reverse direction (from remote node to local node) there
is *no* defect. Expanding RDI as Reverse Defect Indication will
put people on the wrong foot.

> At the same time, RDI as Remote defect indication is

The same RFC6310 refers to G.775 and in appendix A.2 to ATM which both
expand RDI into Remote Defect Indiction. And this expansion is used
several times in RFC6310.
The additional "for Continuity Check Message" is never used in any
of these.

So I strongly suggest to expand RDI *only* as:
"Remote Defect Indication"
to avoid creating any further confusion.

Regards, Huub.

---

From: "Bitar, Nabil N" <[email-masked]>
Date: Wed, 16 Jan 2013 14:59:37 -0500

Hi Huub,
Please, see inline.

Thanks,
Nabil

>put people on the wrong foot.

<NB2>  CA Reverse defect indication is a logical definition in RFC 6310.
The mechanism used depends on the technology used. Here is what is in RFC
6310 and also in the draft in synergy with RFC 6310:

          Forward defect indication corresponds to the logical OR of:

* Local Attachment Circuit (ingress) Receive Fault,

* Local PSN-facing PW (egress) Transmit Fault, and

* PW Not Forwarding.

Reverse defect indication corresponds to the logical OR of:

* Local Attachment Circuit (egress) Transmit Fault and

* Local PSN-facing PW (ingress) Receive Fault.

Are you sating that there is a problem here, with RFC6310?
<NB2> 

>The additional "for Continuity Check Message" is never used in any
<NB> CCM is ised in the Ethernet part which is this draft in here.
Ethernet is not covered in RFC 6310.
>to avoid creating any further confusion.

<NB> Please, see above. There are different contexts per above where the
expanded terminology is applied. Are you suggesting still using Reverse
Defect Indication per above where needed but not to abbreviate it? RDI as
Remote Defect Indication part of Ethernet CFM is already there.

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 20 Jan 2013 23:49:57 +0100

Hello Nabil,

> Remote Defect Indication part of Ethernet CFM is already there.

Would it be possible to remove the dependency on the context by
prepending the PW defect notifications by "P-". I.e.:

P-RDI  PW Reverse Defect Indication
P-FDI  PW Forward Defect Indication

And usinf RDI  Remote Defect Indication.

Regards, Huub.