Subject: Re: WGLC for BFD base MIB and TC - ends November 8

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 10 Nov 2013 22:28:50 +0000

BFDers,

The BFD co-chairs asked me to gauge consensus on this WG Last Call for draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended this past Friday.

In my view, there is good support for these two documents, including from implementors, and consensus to move forward and be sent to the IESG.

Before that, the following needs to be taken into account:
1. Fix the Nits identified by idnits [1] [2]
2. Ask the OPS ADs for a MIB Doctor review [3] (“after the Working Group Last Call and before the IETF Last Call”)

Thanks,

— Carlos.

[1] http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bfd-mib-14.txt
[2] http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bfd-tc-mib-02.txt
[3] http://www.ietf.org/iesg/directorate/mib-doctors.html

On Oct 24, 2013, at 3:06 PM, Jeffrey Haas <[email-masked]> wrote:

> This email is to initiate working group last call on the BFD MIB and
> Textual-Convention documents:
> 
> http://tools.ietf.org/html/draft-ietf-bfd-mib-14
> http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-02
> 
> The last call will complete on November 8, the end of IETF week.  Time will
> be available during the Vancouver IETF BFD session to discuss last call
> comments.
> 
> I will be serving as document shepherd (RFC 4858) for this WGLC. 
> 
> Due to the small nature of the BFD working group and the fact that both
> working group chairs have contributed to the documents, we have gotten
> Carlos Pignataro ([email-masked]) to volunteer to serve as an
> independent party to gauge working group consensus.
> 
> In order to facilitate the transparency of this WGLC, please remember to
> send all comments to the working group mailing list.
> 
> As is often the case with MIB documents, implementations typically do not
> exist for the final form of the document.  Typically enterprise MIBs are
> implemented at some point in the document life cycle and then later the
> implementor will revise to match the published RFC, including OID
> code-points assigned by IANA.  Reviewers examining the MIB against deployed
> implementations are requested to bear in mind implementability of the final
> document vs. existence proof of the running code.
> 
> Finally, note that no IPR polling has been done for these documents.  MIBs,
> being IETF data models of things that themselves may have IPR, tend not to
> have IPR against them.  However, if someone is aware of IPR against these
> documents, please state it for the WG.
> 
> -- Jeff (for the chairs)

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Mon, 11 Nov 2013 23:15:32 +0000

Hi,

Nits have been addressed, and new IDs have been posted (1 taken care of).

http://tools.ietf.org/html/draft-ietf-bfd-mib-15
http://tools.ietf.org/html/draft-ietf-bfd-tc-mib-03

Jeff, if would like me to engage MIB doctors (2), then please let me know. Otherwise I'll assume that you will.

-Nobo
(for BFD base/TC MIB authors)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carlos Pignataro (cpignata)
> Sent: Sunday, November 10, 2013 5:29 PM
> To: Jeffrey Haas
> Cc: [email-masked]
> Subject: Re: WGLC for BFD base MIB and TC - ends November 8
> 
> BFDers,
> 
> The BFD co-chairs asked me to gauge consensus on this WG Last Call for
> draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended this
> past Friday.
> 
> In my view, there is good support for these two documents, including from
> implementors, and consensus to move forward and be sent to the IESG.
> 
> 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for a MIB Doctor
> review [3] ("after the Working Group Last Call and before the IETF Last Call")
> 
> Thanks,
> 
> - Carlos.
> 
> > The last call will complete on November 8, the end of IETF week.  Time
> > will be available during the Vancouver IETF BFD session to discuss
> > last call comments.
> >
> > Due to the small nature of the BFD working group and the fact that
> > both working group chairs have contributed to the documents, we have
> > gotten Carlos Pignataro ([email-masked]) to volunteer to serve as
> > an independent party to gauge working group consensus.
> >
> > In order to facilitate the transparency of this WGLC, please remember
> > to send all comments to the working group mailing list.
> >
> > As is often the case with MIB documents, implementations typically do
> > not exist for the final form of the document.  Typically enterprise
> > MIBs are implemented at some point in the document life cycle and then
> > later the implementor will revise to match the published RFC,
> > including OID code-points assigned by IANA.  Reviewers examining the
> > MIB against deployed implementations are requested to bear in mind
> > implementability of the final document vs. existence proof of the running
> code.
> >
> > Finally, note that no IPR polling has been done for these documents.
> > MIBs, being IETF data models of things that themselves may have IPR,
> > tend not to have IPR against them.  However, if someone is aware of
> > IPR against these documents, please state it for the WG.
> >
> > -- Jeff (for the chairs)

---

From: Mach Chen <[email-masked]>
Date: Tue, 12 Nov 2013 01:18:16 +0000

Hi Carlos and all,

Thanks for doing this, I have one question to the WG. Since the BFD over LAG draft is also in publication process, and there are some implementations and deployment requirements, but the MIB drafts seem lack of supporting the BFD over LAG scenario ( e.g., a variable to describe the dedicated multicast MAC) . Does the WG plan to fix this in these two drafts ? Or there will be a separate document that will cover this in the future?

Best regards,
Mach

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Carlos Pignataro (cpignata)
> Sent: Monday, November 11, 2013 6:29 AM
> To: Jeffrey Haas
> Cc: [email-masked]
> draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended this past
> Friday.
> 
> [1]
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bfd-mib-14.txt
> [2]
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-bfd-tc-mib-02.t
> xt
> > implementability of the final document vs. existence proof of the running code.
> >

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 12 Nov 2013 02:21:28 +0000

[speaking as contributor to both LAG and MIB documents]

Hi Mach,

My thought on this is that BFD on LAG is a variant of single-hop BFD, thus [LAG member, IP address] is sufficient to uniquely describe an uBFD session. I know of an implementation that is using this approach, and it seems to satisfy user needs.

Certainly there's no OID to describe multicast MAC nor interface MAC, of uBFD session. Benefit of being able to read such OID seems very marginal. Whether anyone ever want to write to such OID (to switch to/from multicast from/to interface MAC?) is also questionable.

New UDP port is automatically covered by TC MIB as well.

Thus my preference would be use existing BFD base/TC MIB as is for BFD on LAG.

-Nobo

> Behalf Of Mach Chen
> Sent: Monday, November 11, 2013 8:18 PM
> To: Carlos Pignataro (cpignata); Jeffrey Haas
> Cc: [email-masked]
> Subject: RE: WGLC for BFD base MIB and TC - ends November 8
> 
> Hi Carlos and all,
> 
> Thanks for doing this, I have one question to the WG. Since the BFD over
> LAG draft is also in publication process, and there are some
> implementations and deployment requirements, but the MIB drafts seem
> lack of supporting the BFD over LAG scenario ( e.g., a variable to describe
> the dedicated multicast MAC) . Does the WG plan to fix this in these two
> drafts ? Or there will be a separate document that will cover this in the
> future?
> 
> Best regards,
> Mach
> 
> > draft-ietf-bfd-mib-14 and draft-ietf-bfd-tc-mib-02. The WGLC ended
> > this past Friday.
> >
> > In my view, there is good support for these two documents, including
> > from implementors, and consensus to move forward and be sent to the
> IESG.
> >
> > 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for a
> > MIB Doctor review [3] ("after the Working Group Last Call and before
> > the IETF Last Call")
> >
> > Thanks,
> >
> > - Carlos.
> >
> > [1]
> > > The last call will complete on November 8, the end of IETF week.
> > > Time will be available during the Vancouver IETF BFD session to
> > > discuss last call comments.
> > >
> > > gotten Carlos Pignataro ([email-masked]) to volunteer to serve
> > > as an independent party to gauge working group consensus.
> > >
> > > In order to facilitate the transparency of this WGLC, please
> > > remember to send all comments to the working group mailing list.
> > >
> > > As is often the case with MIB documents, implementations typically
> > > do not exist for the final form of the document.  Typically
> > > enterprise MIBs are implemented at some point in the document life
> > > cycle and then later the implementor will revise to match the
> > > published RFC, including OID code-points assigned by IANA.
> > > Reviewers examining the MIB against deployed implementations are
> > > requested to bear in mind implementability of the final document vs.
> existence proof of the running code.
> > >

---

From: Mach Chen <[email-masked]>
Date: Tue, 12 Nov 2013 02:51:39 +0000

Hi Nobo,

Thanks for your prompt response!

Pls see my reply inline..
> My thought on this is that BFD on LAG is a variant of single-hop BFD, thus [LAG
> member, IP address] is sufficient to uniquely describe an uBFD session. I know of
> an implementation that is using this approach, and it seems to satisfy user needs.
> 
> Certainly there's no OID to describe multicast MAC nor interface MAC, of uBFD
> session. Benefit of being able to read such OID seems very marginal. Whether
> anyone ever want to write to such OID (to switch to/from multicast from/to
> interface MAC?) is also questionable.

Yes, I agree that it is very marginal. 

I am not sure whether there will be writing, but there should be reading of such OID.

The "multicast MAC or interface MAC" is just the one that came into my mind, I am not sure whether there are some uncovered places. 

If the "multicast MAC or interface MAC" is the only one need to be considered, IMHO, it's maybe easy to modify the BFD base MIB to fix it.

Best regards,
Mach

> > Thanks for doing this, I have one question to the WG. Since the BFD
> > over LAG draft is also in publication process, and there are some
> > lack of supporting the BFD over LAG scenario ( e.g., a variable to
> > describe the dedicated multicast MAC) . Does the WG plan to fix this
> > in these two drafts ? Or there will be a separate document that will
> > cover this in the future?
> >
> > Best regards,
> > Mach
> >
> > > 1. Fix the Nits identified by idnits [1] [2] 2. Ask the OPS ADs for
> > > a MIB Doctor review [3] ("after the Working Group Last Call and
> > > before the IETF Last Call")
> > >
> > > Thanks,
> > >
> > > - Carlos.
> > >
> > > [1]
> > > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf
> > > -b
> > > fd-mib-14.txt
> > > [2]
> > > http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf
> > > -b
> > > fd-tc-mib-02.t
> > > xt
> > > > This email is to initiate working group last call on the BFD MIB
> > > > and Textual-Convention documents:
> > > >
> > > > both working group chairs have contributed to the documents, we
> > > > have gotten Carlos Pignataro ([email-masked]) to volunteer to
> > > > serve as an independent party to gauge working group consensus.
> > > >
> > > > MIBs, being IETF data models of things that themselves may have
> > > > IPR, tend not to have IPR against them.  However, if someone is
> > > > aware of IPR against these documents, please state it for the WG.
> > > >
> > > > -- Jeff (for the chairs)

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 12 Nov 2013 15:25:10 -0500

Mach,

> I am not sure whether there will be writing, but there should be reading of such OID.

I spent some time reviewing the BFD MIBs specially with the LAG
cases in mind.  The conclusion I arrived at included the following:
- the *base* MIBs are capable of handling the subsets of behavior that are
  not feature specific to the BFD MPLS MIB or LAG scenarios.  
- the superset of feature elements were largley covered by the port number
  change.
- the one minor element was the mac address.
- As BFD continues to evolve, a single MIB can never address 100% of the use
  cases.

The latter is the main point here, I think.  As you suggest, there's really
only a single object (maybe two) that distinguishes the additional details
of BFD on LAG: Whether we're using the multicast MAC as part of the
procedures and what the MAC is for the session.

> If the "multicast MAC or interface MAC" is the only one need to be considered, IMHO, it's maybe easy to modify the BFD base MIB to fix it.

My suggestion would be that if you find that specific detail interesting, it
is in-charter for the Working Group to add an extension MIB for the base MIB
for the necessary feature-specific objects.

Did you have any interest in authoring that?

-- Jeff

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Nov 2013 01:07:13 +0000

Hi Jeff,

I am OK to progress the two drafts as it be. 

As for the extension draft, yes, I am interesting. But based on the fact that there is only one element left, so maybe we could just wait and put it into other extension draft in the future. 

Best regards,
Mach

> Jeffrey Haas
> Sent: Wednesday, November 13, 2013 4:25 AM
> To: Mach Chen
> Cc: Carlos Pignataro (cpignata); [email-masked]
> > > My thought on this is that BFD on LAG is a variant of single-hop
> > > BFD, thus [LAG member, IP address] is sufficient to uniquely
> > > describe an uBFD session. I know of an implementation that is using this
> approach, and it seems to satisfy user needs.
> > >
> > > Certainly there's no OID to describe multicast MAC nor interface
> > > MAC, of uBFD session. Benefit of being able to read such OID seems
> > > very marginal. Whether anyone ever want to write to such OID (to
> > > switch to/from multicast from/to interface MAC?) is also questionable.
> >
> I spent some time reviewing the BFD MIBs specially with the LAG cases in mind.
> The conclusion I arrived at included the following:
> The latter is the main point here, I think.  As you suggest, there's really only a
> single object (maybe two) that distinguishes the additional details of BFD on LAG:
> Whether we're using the multicast MAC as part of the procedures and what the
> MAC is for the session.
> 
> > The "multicast MAC or interface MAC" is just the one that came into my mind, I
> am not sure whether there are some uncovered places.
> >
> > If the "multicast MAC or interface MAC" is the only one need to be considered,
> IMHO, it's maybe easy to modify the BFD base MIB to fix it.
> 
> My suggestion would be that if you find that specific detail interesting, it is
> in-charter for the Working Group to add an extension MIB for the base MIB for
> the necessary feature-specific objects.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 12 Nov 2013 22:47:40 -0500

Mach,

> I am OK to progress the two drafts as it be. 

Excellent.  That clears the last comment on those drafts.

> As for the extension draft, yes, I am interesting. But based on the fact that there is only one element left, so maybe we could just wait and put it into other extension draft in the future. 

The objects in question would be particular to the LAGs extension.  It would
thus be appropriate for them to go into a standalone draft.  This would
allow implementations that do not support the LAG feature to not have their SNMP
implementations entangled with other features in such a MIB.

-- Jeff

---

From: Mach Chen <[email-masked]>
Date: Wed, 13 Nov 2013 05:48:43 +0000

Jeff,

> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Wednesday, November 13, 2013 11:48 AM
> To: Mach Chen
> Cc: Jeffrey Haas; Carlos Pignataro (cpignata); [email-masked]
> > As for the extension draft, yes, I am interesting. But based on the fact that
> there is only one element left, so maybe we could just wait and put it into other
> extension draft in the future.
> 
> thus be appropriate for them to go into a standalone draft.  This would allow
> implementations that do not support the LAG feature to not have their SNMP

Yes, I just realize it.

Best regards,
Mach