RE: Comments to draft-ietf-bfd-mpls-mib-00

[Muly Ilan <[e-mail]>]

Hi Venkat.,

Regarding the 3rd issue, of "session mode". I haven't requested to define a MIB object for the coordinated/independent modes.
I merely suggested to rename "bfdMplsSessMode" to "bfdMplsSessFunction" to avoid misunderstandings.

Muly

From: venkatesan mahalingam [mailto:[e-mail]]
Sent: Wednesday, July 18, 2012 8:41 AM
To: Muly Ilan
Cc: [e-mail]; mpls; Kannan KV Sampath; Sam Aldrin; Thomas Nadeau
Subject: Re: Comments to draft-ietf-bfd-mpls-mib-00


Thanks Muly for your comments, please see my answers inlined with the tag [VM].

Cheers,
Venkat.

Date: Mon, 16 Jul 2012 14:08:32 +0000
From: Muly Ilan <[e-mail]<mailto:[e-mail]>>
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Comments to draft-ietf-bfd-mpls-mib-00
Message-ID:
        <[e-mail]<mailto:[e-mail]>>
Content-Type: text/plain; charset="us-ascii"

Hi,

1.
In section 5.2.2, Example of BFD Session configuration for Maintenance Entity of MPLS-TP TE tunnel, the object mplsOamIdMeProactiveOamSessIndex of the ME table in draft-vkst-mpls-tp-oam-id-mib is not mentioned.
It would be helpful to explain that when a BFD session with bfdMplsSessMapType=mep(6) is created in the bfdSessTable, the value of the object mplsOamIdMeProactiveOamSessIndex should be updated with the BFD session index.

[VM] OK

2.
For the associated bidirectional LSPs case there would be two unidirectional MEs that together operate the BFD session. To which one of the MEs should the map pointer, bfdMplsSessMapPointer, point?
I think it may point to either one of the unidirectional MEs i.e. make it implementation specific, but this should be described in the MIB.
[VM] This draft suggests to map each ME of LSP/PW entry with the BFD session entry, for associated bidirectional case, having an BFD session entry to point to either one of the unidirectional ME is purely implementation specific, IMO, nothing needs to be described.

3.
The term "session mode" in RFC6428 refers to coordinated operation vs. independent operation. However the current object bfdMplsSessMode sets the BFD functionality to cc(1) or cv(2). Suggest to rename the object to bfdMplsSessFunction.
[VM] IMO,MIB object for coordinated & independent session mode operation is not required as we can infer it from bfd.MinRxInterval value 0.



bfdMplsSessMode denotes the BFD message format (CC/CV) to be carried in the BFD control packet, IMO this MIB object should be retained.

if this MIB object name does not convey the right meaning, we might need to choose appropriate MIB object name.

4.
There's a need to configure what is the consequent action upon mis-connectivity defect and LOC defect. Possible values: alarm only, alarm and block data.
Separate configuration for mis-connectivity and for LOC. Default value for mis-connectivity is alarm and block data. Default value for LOC is alarm only.
Maybe a common behavior for all BFD sessions is sufficient. In this case define two scalar objects.
[VM] OK

5.
Suggest to add counters for received and transmitted CC and CV packets. Need separate counters for CC and CV.
[VM] OK

Regards,

Muly