Subject: Adoption of draft-vkst-bfd-mpls-mib

From: Jeffrey Haas <[email-masked]>
Date: Fri, 1 Jun 2012 11:12:38 -0400

Working Group,

This begins a one week poll for the adoption of
http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib
as a working group document.

Note that this appears to be currently within the scope of our charter:

: 1. Develop the MIB module for BFD and submit it to the IESG for publication
: as a Proposed Standard. 
: 
: 5. Assist in the standardization of the BFD protocol for MPLS-TP. The
: preferred solution will be interoperable with the current BFD specification. 

If our ADs disagree, we'll ask for a formal charter change to pick up this
item.

The room discussion regarding this draft during IETF 83 was positive.

-- Jeff

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 2 Jun 2012 17:31:11 +0100

Hi Jeff,

I don't disagree: this is clearly part of your charter.

The document claims to extend BFD-STD-MIB but there is no citation for that
module and I can find no active document on the charter page that includes that
module. Has something timed out? Is the cart in front of the horse?

And a meta-question (arising from recent pushback I have been getting for MIB
modules within the IESG)...
Notwithstanding MIB modules being a deliverable of the WG, you should only work
on them if there is a clear desire to build them into product and use them in
deployments. You should not spend cycles making MIBs just because they are in
the charter, and certainly not just because "here is a chance to publish an RFC"
:-)

Lastly, a number of objects in the module are read-create. This implies that the
plan is for the module to be used for (or at least capable of being used for)
configuring BFD behavior, not just monitoring it. I would like the WG to be
certain that this is function it wants. But that question does not need to gate
adoption if the WG chooses to work on the I-D.

Cheers,
Adrian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jeffrey Haas
> Sent: 01 June 2012 16:13
> To: [email-masked]
> Subject: Adoption of draft-vkst-bfd-mpls-mib
> 
> Working Group,
>

---

From: Jeffrey Haas <[email-masked]>
Date: Sat, 2 Jun 2012 19:00:58 -0400

Adrian,

> module. Has something timed out? Is the cart in front of the horse?

Yes, it's timed out.  It's in the enviable position of being also ready for
last call, but only once the authors republish it.  (Which they've been
prodded to do a few times in the last couple of months.)

> the charter, and certainly not just because "here is a chance to publish an RFC"

As anyone who follows MIBs is aware, I'm hardly the last person to say
"let's do a MIB, just because". :-)

> adoption if the WG chooses to work on the I-D.

As part of the IETF MPLS-TP work, I believe we (the IETF) are expected to
provide interfaces to configure that feature.  While I'll admit to not
playing enough in that field to know what the latest conversations have been
on this topic, the current choices are either SNMP or netconf.  I believe
there is more support for SNMP at this point.

It's probably worth prodding the MPLS chairs to offer a public opinion on
the matter.  I've cc'd them on this and will also forward the original email
to them.

-- Jeff

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 5 Jun 2012 17:35:39 -0400

Dear Chairs, Authors, et al.,
I think that this is needed work but the document needs some modifications:
- read-create objects can be modified into read-only as no firm requirement to support SNMP based configuration can be found;
- bfdMplsSessTable lacks object to reflect whether Coordinated or Independent monitoring mode being used per RFC 6428;
- bfdMplsSessTmrNegotiate object is non-standard and is not MPLS specific but is expression of local policy set by an operator. The bfdMplsSessTmrNegotiate should be removed from the bfdMplsSessTable table;
- list of modes for the bfdMplsSessMode object should include a mode, perhaps referred as bfd, which performs continuity check but does not support RDI functionality (RFC 5884 and RFC 5885);
- bfdMplsSessTable needs to reflect addressing used if bfdMplsSessMapType = mep(6) - IP or ICC;
- bfdMplsSessTable needs to reflect encapsulation type, IP or ACH/G-ACh, being used.

	Regards,
		Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Friday, June 01, 2012 8:13 AM
To: [email-masked]
Subject: Adoption of draft-vkst-bfd-mpls-mib

Working Group,

This begins a one week poll for the adoption of http://tools.ietf.org/html/draft-vkst-bfd-mpls-mib
as a working group document.

If our ADs disagree, we'll ask for a formal charter change to pick up this item.

-- Jeff

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 5 Jun 2012 16:55:14 -0700

> - read-create objects can be modified into read-only as no firm requirement to support SNMP based configuration can be found;

	Are you asking us to specifically make the MIB read-only?  If so, this would be at least the second request recently (third if you include mine).  However, it might be good to get some guidance from the WG chairs on this direction as making these changes can be potentially significant.

	--Tom

---

From: Sam Aldrin <[email-masked]>
Date: Tue, 5 Jun 2012 17:35:37 -0700

Sent from my iPad

>    Are you asking us to specifically make the MIB read-only?  If so, this would be at least the second request recently (third if you include mine).  However, it might be good to get some guidance…
We were asked specifically by the WG chairs, in the Paris WG session, to add read write option to the MIB. AD and MPLS WG chair also provided their comments and felt BFD MIB extension to support TP should have write support.

There are at least three vendors who are requesting write support as well.

To the original comment that there is no requirement for write support for MIB, my answer is, there is no requirement to have just read only either. If there is consensus that, write option shouldnt exist in MIBs, it should be stated so. Otherwise, the confusion will persist every time.

Cheers
Sam

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 5 Jun 2012 20:42:09 -0400

Hi Tom,
yes, you can count me in. As for "guidance from the WG chairs", Which working group should provide such guidance - RTG-BFD or MPLS?

	Regards,
		Greg

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2012 4:55 PM
To: Gregory Mirsky
Cc: Jeffrey Haas; [email-masked]
Subject: Re: Adoption of draft-vkst-bfd-mpls-mib

On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote:

> - read-create objects can be modified into read-only as no firm 
> requirement to support SNMP based configuration can be found;

	--Tom

> - bfdMplsSessTable lacks object to reflect whether Coordinated or 
> Independent monitoring mode being used per RFC 6428;
> - bfdMplsSessTmrNegotiate object is non-standard and is not MPLS 
> specific but is expression of local policy set by an operator. The 
> bfdMplsSessTmrNegotiate should be removed from the bfdMplsSessTable 
> table;
> - list of modes for the bfdMplsSessMode object should include a mode, 
> perhaps referred as bfd, which performs continuity check but does not 
> support RDI functionality (RFC 5884 and RFC 5885);

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 27 Jun 2012 10:28:22 -0400

Sam,

> We were asked specifically by the WG chairs, in the Paris WG session, to add read write option to the MIB. AD and MPLS WG chair also provided their comments and felt BFD MIB extension to support TP…

This was under the presumption that we needed to provide this as part of our
MPLS-TP agreement with ITU.  After consulting with the MPLS chairs (or at
least, per Loa's answer) and our ADs, this doesn't appear to be the case. 

So, as a motivating factor, we don't need it.

> There are at least three vendors who are requesting write support as well.

*That* is far more interesting.  Per other discussions off-list, I was
considering polling the WG to see if we should consider removing the write
profile for the MIBs.

Would those three vendors be willing to go on record stating that they want
write-access to the MIB?  This wouldn't be a formal statement of "we'll
support this in X version of our software", just "we want the option to be
able to do SNMP SET in this MIB."  Having some sort of public statement for
this would help an upcoming OPS open-area meeting at the upcoming IETF in
Vancouver with regard to this general topic.

If the vendors aren't willing to publicly state this but are willing to
privately do so, that would also be helpful.

> To the original comment that there is no requirement for write support for MIB, my answer is, there is no requirement to have just read only either. If there is consensus that, write option shouldn…

In general, a read-only profile is desirable because there exists a set of
vendors who have no intention to provide SNMP SET access to their MIB
implementations.  Without a supporting conformance statement, those vendors
are not conformant.  Obviously the protocol works just fine read-only, but
it upsets the people who track such things in spreadsheets. :-)

-- Jeff

---

From: Muly Ilan <[email-masked]>
Date: Wed, 27 Jun 2012 14:49:23 +0000

Hi,

We, at RAD, plan to support the write-access to this BFD extension MIB.

Regards,

Muly Ilan
Senior System Architect, R&D
T: +972-3-765-7035 | M: +972-54-470-1004 | F: +972-3-644-0930  | [email-masked] 
RAD Data Communications Ltd. 24, Raoul Wallenberg St. Tel-Aviv 69719, Israel  | www.rad.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Wednesday, June 27, 2012 5:28 PM
To: Sam Aldrin
Cc: [email-masked]
Subject: Re: Adoption of draft-vkst-bfd-mpls-mib

Sam,

> We were asked specifically by the WG chairs, in the Paris WG session, to add read write option to the MIB. AD and MPLS WG chair also provided their comments and felt BFD MIB extension to support TP…

This was under the presumption that we needed to provide this as part of our MPLS-TP agreement with ITU.  After consulting with the MPLS chairs (or at least, per Loa's answer) and our ADs, this doesn't appear to be the case. 

> There are at least three vendors who are requesting write support as well.

*That* is far more interesting.  Per other discussions off-list, I was considering polling the WG to see if we should consider removing the write profile for the MIBs.

Would those three vendors be willing to go on record stating that they want write-access to the MIB?  This wouldn't be a formal statement of "we'll support this in X version of our software", just "we want the option to be able to do SNMP SET in this MIB."  Having some sort of public statement for this would help an upcoming OPS open-area meeting at the upcoming IETF in Vancouver with regard to this general topic.

If the vendors aren't willing to publicly state this but are willing to privately do so, that would also be helpful.

> To the original comment that there is no requirement for write support for MIB, my answer is, there is no requirement to have just read only either. If there is consensus that, write option shouldn…

In general, a read-only profile is desirable because there exists a set of vendors who have no intention to provide SNMP SET access to their MIB implementations.  Without a supporting conformance statement, those vendors are not conformant.  Obviously the protocol works just fine read-only, but it upsets the people who track such things in spreadsheets. :-)

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 27 Jun 2012 13:48:07 -0400

> The room discussion regarding this draft during IETF 83 was positive.

There was no objection to adopting this draft as a WG item.  Mailing list
discussion suggests that we'll have some work to do on this.

Authors, please submit this as draft-ietf-bfd-mpls-mib.

-- Jeff