Re: [mpls] Comments to draft-ietf-bfd-mpls-mib-00

[venkatesan mahalingam <[e-mail]>]

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]>
To: "[e-mail]" <[e-mail]>
Subject: Comments to draft-ietf-bfd-mpls-mib-00
Message-ID:
        <[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