Re: Fwd: Adoption of draft-vkst-bfd-mpls-mib

[Loa Andersson <[e-mail]>]

Jeff,

thanks for forwarding.

The question whether we have a responsibility to *ITU-T* to provide
configuration MIBs for MPLS-TP is "interesting"!

Currently there is no explicit agreement on MPLS-TP deliverables
between IETF and ITU-T, the JWT agreement has dated.

However there are certain rules of conduct that governs the relationship
between two peer SDOs. This include for example that we liaise and
respond to liaisons when we see an interest in both organizations.
This means that we for example copy all wg last calls on MPLS-TP
documents to the Ad Hoc Team mailing list.

I am not aware of any interest expressed by ITU-T for configuration
MIBs, but on the other hand there is a clear interest from a number
of operators for such MIBs. In my mind this would be the reason to
keep the read-write.

However I'd lkie our OPS and RTG ADs opinion on this.

/Loa

On 2012-06-06 20:23, Jeffrey Haas wrote:
> Loa had forwarded the following response that was partially posted:
>
>> Begin forwarded message:
>>
>>> From: Loa Andersson<[e-mail]>
>>> Subject: Re: Adoption of draft-vkst-bfd-mpls-mib
>>> Date: June 5, 2012 10:38:03 PM EDT
>>> To: Gregory Mirsky<[e-mail]>
>>> Cc: Thomas Nadeau<[e-mail]>, "[e-mail]"<[e-mail]>, Jeff Haas<[e-mail]>, David Ward<[e-mail]>
>>>
>>> hmmm tried to figure out the bfd chairs alias, but have yo give up
>>>
>>> /Loa
>>>
>>> On 2012-06-06 04:30, Loa Andersson wrote:
>>>> resend with what i hope is the correct address
>>>>
>>>>
>>>> On 2012-06-06 04:28, Loa Andersson wrote:
>>>>>
>>>>> Folks,
>>>>>
>>>>> this is intended to be a rtg-bfd document, isn't it? If so the guidance
>>>>> should from the from the rtg-bfd chairs.
>>>>>
>>>>> mpls chairs will support and help with reviews.
>>>>>
>>>>> My experience aldo tells me that it is a good idea to eep the
>>>>> mib-doctors in the loop.
>
> Question: Do we have a responsibility to ITU to provide configuration MIBs
> for MPLS-TP?  If so, since a MPLS-TP BFD MIB would build on a BFD MIB, we
> would need to keep read-write.
>
> As has been mentioned elsewhere in this thread, it sounds like there may be
> consumers of BFD read-create objects already.  As much as I tend to agree
> with Tom and company that writeable MIBs are a bad idea, we may be stuck
> with it.
>
> That said, bfdModuleReadOnlyCompliance, documents a read-only conformance
> for the MIB.  It is thus possible to implement this MIB without permitting
> configuration.
>
> -- Jeff
>
>>>>>
>>>>> /Loa
>>>>>
>>>>> On 2012-06-06 02:42, Gregory Mirsky wrote:
>>>>>> 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:[e-mail]]
>>>>>> Sent: Tuesday, June 05, 2012 4:55 PM
>>>>>> To: Gregory Mirsky
>>>>>> Cc: Jeffrey Haas; [e-mail]
>>>>>> Subject: Re: Adoption of draft-vkst-bfd-mpls-mib
>>>>>>
>>>>>>
>>>>>> On Jun 5, 2012:2:35 PM, at 2:35 PM, Gregory Mirsky wrote:
>>>>>>
>>>>>>> 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;
>>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>>> - 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: [e-mail] [mailto:[e-mail]] On
>>>>>>> Behalf Of Jeffrey Haas
>>>>>>> Sent: Friday, June 01, 2012 8:13 AM
>>>>>>> To: [e-mail]
>>>>>>> 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.
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> --
>>>
>>>
>>> Loa Andersson                         email: [e-mail]
>>> Sr Strategy and Standards Manager            [e-mail]
>>> Ericsson Inc                          phone: [phone]
>>>                                               [phone]
>>

-- 


Loa Andersson                         email: [e-mail]
Sr Strategy and Standards Manager            [e-mail]
Ericsson Inc                          phone: [phone]
                                              [phone]