Subject: [CCAMP] Questions on draft-vkst-mpls-tp-oam-id-mib-01

From: Jaihari Kalijanakiraman <[email-masked]>
Date: Tue, 3 Jan 2012 22:56:50 +0530

Hi Authors,

Happy new year to all..

I have few queries on the draft..

1. The draft "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-03<http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-03>"
talks about configuration of various OAM functions for an LSP or MEG.
Shouldnt the MIB have objects to configure these OAM functions as part of
MEG configuration?

2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for
MPLS-TP*"?

3. The ME table has objects for configuring PhbTCValues for OAM packets. As
per MPLS-TP OAM framework, the OAM packets has to fate share with the data
traffic. If thats the case, what is the use for these objects?

4. The RFC 6427 "*MPLS Fault Management OAM*" talks about server layer MEP
sending FM message to the client layer MEPs.. How these server-client
relationships be configured or derived? Shouldnt there be objects for
identifying the server-client relationships??

*Thanks & Regards,*
*Jai Hari M.K.
IP Infusion.*

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 03 Jan 2012 18:02:17 +0000

> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for 
Without prejudice to any decisions on Y.1731 and MPLS-TP.

Wouldn't such a MIB be a derivative of the Y.1731 MIB?

Stewart

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Jan 2012 14:03:47 -0500

Stewart,

	The question of whether or not to allow "configuration" via the OAM protocols (or protocol extensions) was something I raised several months ago in PWE3, although it was also discussed in MPLS as I recall in Taipei as well. It seems to have arisen again.   The conclusions in PWE3 were to allow configuration of only OAM-related things (i.e.: not allowing expansion of the protocols for general configuration). Presumably configuration via MIBs there is still okay. In MPLS I recall the chairs stating that configuration was a thing reserved for NetConf when the question of MIB-based configuration was raised for WG MIB drafts in general (and in particular WRT to the MPLS-TP MIBs).    Those positions seem slightly at odds with each other.  And now your answer now seems inconsistent with those as well.

	Can we get a single answer from the ADs/IESG on this that pertains to all MPLS-TP related work?

	--Tom

On Jan 3, 2012, at 1:02 PM, Stewart Bryant wrote:

> 
>> 2. Will this MIB be enhanced also to configure "*Y.1731 based OAM for MPLS-TP*"?
>> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 3 Jan 2012 10:12:28 -0800

[speaking as a co-author of the MIB]

I echo what Stewart has said.
In addition, unless IETF standardizes a specific technology, in this case, Y.1731 based MPLS TP OAM, it is not prudent to add MIB objects supporting that specific technology. If at all the need arises and the requirement needs to be fulfilled, will surely address that. At this point we do not see the need.

Cheers
Sam

Sent from my iPad

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 5 Jan 2012 15:37:20 -0800

Dear Tom, et al.,
I had to refresh my recollection of the discussion in Taipei. According to
minutes we don't have the decision regarding the use of MIBs to configure
MPLS-TP objects. Somewhere in my memory stuck that the proposal was to
limit new MPLS-TP MIBs to R/O and I wonder if it is self-inflicted memory
or one of options chairs and the WG is looking into.

Regards,
Greg

On Tue, Jan 3, 2012 at 11:03 AM, Thomas Nadeau <[email-masked]>wrote:

>
>        Stewart,
>
>        The question of whether or not to allow "configuration" via the OAM
> protocols (or protocol extensions) was something I raised several months
> ago in PWE3, although it was also discussed in MPLS as I recall in Taipei
> as well. It seems to have arisen again.   The conclusions in PWE3 were to
> allow configuration of only OAM-related things (i.e.: not allowing
> expansion of the protocols for general configuration). Presumably
> configuration via MIBs there is still okay. In MPLS I recall the chairs
> stating that configuration was a thing reserved for NetConf when the
> question of MIB-based configuration was raised for WG MIB drafts in general
> (and in particular WRT to the MPLS-TP MIBs).    Those positions seem
> slightly at odds with each other.  And now your answer now seems
> inconsistent with those as well.
>

---

From: Sam Aldrin <[email-masked]>
Date: Thu, 5 Jan 2012 15:51:50 -0800

Hi Greg,

The question was in fact got asked over email by WG chairs, and also by me, when I presented at Quebec and Taipei. The decision was still inconclusive, though the strongest indication given thus far is "TP MIB's should be readonly, albeit OAM configuration like Bfd, ping etc". The other comment George gave at Taipei was "Netconf will be used for configuration".

I have sent a request to WG chairs, after Taipei, to provide a conclusive answer, so that, we could update the drafts accordingly. Yet to receive a answer though.

HTH,
Sam

Sent from my iPad

On Jan 5, 2012, at 3:37 PM, Greg Mirsky <[email-masked]> wrote:

> Dear Tom, et al.,
> I had to refresh my recollection of the discussion in Taipei. According to minutes we don't have the decision regarding the use of MIBs to configure MPLS-TP objects. Somewhere in my memory stuck that the proposal was to limit new MPLS-TP MIBs to R/O and I wonder if it is self-inflicted memory or one of options chairs and the WG is looking into.
> 
> Regards,
> Greg
> 
> On Tue, Jan 3, 2012 at 11:03 AM, Thomas Nadeau <[email-masked]> wrote:
> 
>        Stewart,
>

---

From: Thomas D Nadeau <[email-masked]>
Date: Fri, 6 Jan 2012 07:45:47 -0500

I need to dig up the email, but I am pretty sure that Matthew had sent out a note clarifying things for PWE3. For MPLS I believe that George made the statement at the meeting (the second one in Taipei).  In any event, the point still remains that that there is no clear and consistent directive on this from the IESG right now across various WGs where it needs to be.

--Tom