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

[venkatesan mahalingam <[e-mail]>]

OK, thanks Muly.

Cheers,
Venkat.

On Thu, Jul 19, 2012 at 1:58 AM, Muly Ilan <[e-mail]> wrote:

>  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]>
> 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 ****
>