Subject: [trill] TRILL OAM Framework

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Tue, 3 Jul 2012 00:46:02 +0000

Hi,
We have published 
http://datatracker.ietf.org/doc/draft-salam-trill-oam-framework which
describes a proposed reference framework for TRILL OAM. The framework
leverages concepts widely adopted in 802.1ag, RFC6136, RFC6371, etc...

We invite and welcome your feedback on the initial draft.

Thanks
Samer

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jul 2012 12:25:48 +0200

Hi,

I have two basic comments to start: 

- The use of the OAM acronym conflicts with the recommendations in RFC
6291 / BCP 161 which recommends the OAM expansion in the IETF documents
to be Operations, Administration, and Maintenance
- 'OAM, in general, covers multiple areas, including: ...' - and then
FCAPS are listed. This is wrong. These are actually not 'aspects of OAM'
but the five functional areas in the OSI model for Network Management
defined in the 80s (ISO/IEC 7498-4). 

I do not know if this confusion between OAM and network management is
intentional or not, but it's a confusion. OAM and Network Management are
different things, there are areas of interaction and relations between
the two, but they need to be kept distinct and such confusions need to
be avoided.  

Regards,

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Samer Salam (ssalam)
> Sent: Tuesday, July 03, 2012 3:46 AM
> To: [email-masked]
> Cc: Tissa Senevirathne (tsenevir); Sam Aldrin
> Subject: [trill] TRILL OAM Framework
> 
> Hi,
> We have published
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill

---

From: "Tissa Senevirathne (tsenevir)" <[email-masked]>
Date: Tue, 3 Jul 2012 15:20:07 +0000

Dan

Thanks for the comments please see in-line.

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Tuesday, July 03, 2012 3:26 AM
To: Samer Salam (ssalam); [email-masked]
Cc: Tissa Senevirathne (tsenevir); Sam Aldrin
Subject: RE: [trill] TRILL OAM Framework

Hi,

- The use of the OAM acronym conflicts with the recommendations in RFC
6291 / BCP 161 which recommends the OAM expansion in the IETF documents to be Operations, Administration, and Maintenance

[Answer] According to RFC 6291, Operations (O of OAM) refers to activities related to  keep network up and running. Those includes finding problems before users are affected. These are the faults and performance issues.  It is  very similar to RFC 6371, where it says "... OAM  procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and Protection-switching management ... ". So to our best of knowledge we believe it is in line with 6291 and follow the other established RFC such as RFC 6371. However,  appreciate if you could specifically point out the conflicts and we are more than happy to correct/update/stream-line.  Are you referring to the same usage case below ?

- 'OAM, in general, covers multiple areas, including: ...' - and then FCAPS are listed. This is wrong. These are actually not 'aspects of OAM'
but the five functional areas in the OSI model for Network Management defined in the 80s (ISO/IEC 7498-4). 

[Answer] If the reference is to what is listed towards end of the Introduction then we can fix the usage .

Reference Text cut and pasted below from Introduction..

   OAM, in general, covers multiple areas, including:
   - Fault Management
   - Performance Management
   - Configuration
   - Accounting
   - Security

I do not know if this confusion between OAM and network management is intentional or not, but it's a confusion. OAM and Network Management are different things, there are areas of interaction and relations between the two, but they need to be kept distinct and such confusions need to be avoided.  

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:30:09 +0200

Hi Tissa,

See in-line. 

Regards,

Dan

> From: Tissa Senevirathne (tsenevir) [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2012 6:20 PM
> To: Romascanu, Dan (Dan); Samer Salam (ssalam); [email-masked]
> Cc: Sam Aldrin
> [Answer] According to RFC 6291, Operations (O of OAM) refers to
> activities related to  keep network up and running. Those includes
> finding problems before users are affected. These are the faults and
> performance issues.  It is  very similar to RFC 6371, where it says
"...
> OAM  procedures that fulfill the MPLS-TP OAM requirements for fault,
> performance, and Protection-switching management ... ". So to our best
> of knowledge we believe it is in line with 6291 and follow the other
> established RFC such as RFC 6371. However,  appreciate if you could
> specifically point out the conflicts and we are more than happy to
> correct/update/stream-line.  Are you referring to the same usage case
> below ?

[[DR]] According to RFC 6291 M is for Maintenance.

> Introduction then we can fix the usage .
[[DR]] It's wrong IMO to claim that FCAPS is about OAM. FCAPS is about
Network Management. It does not cover accounting, and seldom carries
security information for example. The paragraph about 'multiple areas'
should be taken out completely. You do not need it, just say that you
focus on carrying faults and performance functionality.

---

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Tue, 3 Jul 2012 17:24:01 +0000

Hi Dan,

Thanks for your comments. We will incorporate in the next revision.

Regarding FCAPS, will clarify that these are Management Functional Areas
(MFAs) per ITU-T M3010, X.700 and X.701.

Regards,
Samer

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 4 Jul 2012 18:56:07 +0200

> From: Samer Salam (ssalam) [mailto:[email-masked]]
> Sent: Tuesday, July 03, 2012 8:24 PM
> To: Romascanu, Dan (Dan); Tissa Senevirathne (tsenevir);
[email-masked]
> Cc: Sam Aldrin
> Subject: Re: [trill] TRILL OAM Framework
> 
> Hi Dan,
> 

Hi Samer,

This would work for me, but I think that the original definition of
FCAPS is the one in the OSI standard that I mentioned, first issued in
the mid 80s, and the ITU-T (and other) standards refer it. 

Thanks for addressing my comments. 

Regards,

Dan

---

From: "Samer Salam (ssalam)" <[email-masked]>
Date: Tue, 24 Jul 2012 02:05:25 +0000

Hi,

An updated version of the document has been uploaded, which incorporates
comments from Dan and others.

Feedback/comments appreciated.

Thanks
Samer