Subject: Re: [mpls] Comments to draft-ietf-mpls-tp-te-mib-02

From: Muly Ilan <[email-masked]>
Date: Tue, 3 Apr 2012 08:21:01 +0000

Looks good.

Thanks,

Muly

From: Venkatesan Mahalingam [mailto:[email-masked]]
Sent: Tuesday, April 03, 2012 8:42 AM
To: Muly Ilan
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments to draft-ietf-mpls-tp-te-mib-02

Muly Ilan, Hi
Sorry for the delayed response.

Thanks for the comments. Please find below the reply tagged [VM].

Regards,
Venkat.
On Sun, Apr 1, 2012 at 9:35 AM, Muly Ilan <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I have 2 comments to draft-ietf-tp-te-mib-02:

1.       In mplsXCExtTable - suggest to make the mplsXCExtTunnelPointer a read-only object. The NE can automatically fill in this backward pointer value when the manager sets the mplsTunnelXCPointer in the mplsTunnelTable. This will be similar to the existing backward pointers mplsInSegmentXCIndex & mplsOutSegmentXCIndex.

[VM] Yes, we will consider this change in our next version.

2.       In mplsTunnelExtTable - suggest to add a columnar object mplsTunnelExtRemoteTunnelIndex. This will hold the index of the bidirectional tunnel at the egress LSR. To support LSP connectivity verification per RFC6428, detection of mis-connectivity defect, the (global-id, node-id, tunnel-num and lsp-num) should be known at both ends. The global-id and node-id of the remote LSR are available from mplsNodeConfigTable. Assuming co-routed LSPs, the lsp-num is given by mplsXCLspId. The only missing identifier is the remote tunnel-num since per RFC6370 each end can have its own tunnel number.
[VM] Yes, your suggestion is exactly matching with our next version update. Please find below the expected additional MIB objects for mplsTunnelExtTable,
1. mplsTunnelExtDestTnlIndex
2. mplsTunnelExtDestTnlInstance
    3. mplsTunnelExtDestTnlValid - TRUE/FALSE
       TRUE will be set if MIB objects mplsTunnelExtDestTnlIndex and mplsTunnelExtDestTnlInstance are used for destionation tunnel indentification, FALSE will be set otherwise.
    4. mplsTunnelExtOppositeDirTnlValid - TRUE/FALSE
     TRUE will be set if MIB object mplsTunnelOppositeDirPtr is used for destination tunnel identifiction, FALSE will be set otherwise.

Regards,

Muly Ilan
Senior System Architect, R&D
T: +972-3-765-7035 | M: +972-54-470-1004 | F: +972-3-644-0930  | [email-masked]<mailto:[email-masked]>
RAD Data Communications Ltd. 24, Raoul Wallenberg St. Tel-Aviv 69719, Israel  | www.rad.com<http://www.rad.com>

---

From: Venkatesan Mahalingam <[email-masked]>
Date: Mon, 2 Apr 2012 22:42:05 -0700

Muly Ilan, Hi

Regards,
Venkat.
On Sun, Apr 1, 2012 at 9:35 AM, Muly Ilan <[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> I have 2 comments to draft-ietf-tp-te-mib-02:****
>
> **1.       **In mplsXCExtTable – suggest to make the mplsXCExtTunnelPointer
> a read-only object. The NE can automatically fill in this backward pointer
> value when the manager sets the mplsTunnelXCPointer in the mplsTunnelTable.
> This will be similar to the existing backward pointers mplsInSegmentXCIndex
> & mplsOutSegmentXCIndex.
>
> **2.       **In mplsTunnelExtTable – suggest to add a columnar object
> mplsTunnelExtRemoteTunnelIndex. This will hold the index of the
> bidirectional tunnel at the egress LSR. To support LSP connectivity
> verification per RFC6428, detection of mis-connectivity defect, the
> (global-id, node-id, tunnel-num and lsp-num) should be known at both ends.
> The global-id and node-id of the remote LSR are available from
> mplsNodeConfigTable. Assuming co-routed LSPs, the lsp-num is given by
> mplsXCLspId. The only missing identifier is the remote tunnel-num since
> per RFC6370 each end can have its own tunnel number.****
>
> **[VM] Yes, your suggestion is exactly matching with our next version
> update. Please find below the expected additional MIB objects
> for mplsTunnelExtTable,
>
    3. mplsTunnelExtDestTnlValid - TRUE/FALSE
       TRUE will be set if MIB objects mplsTunnelExtDestTnlIndex and
mplsTunnelExtDestTnlInstance are used for destionation tunnel
indentification, FALSE will be set otherwise.
    4. mplsTunnelExtOppositeDirTnlValid - TRUE/FALSE
     TRUE will be set if MIB object mplsTunnelOppositeDirPtr is used for
destination tunnel identifiction, FALSE will be set otherwise.

>  **
>
> ** **
>
> Regards,****
>
> ** **
>
> *Muly Ilan***
>
> Senior System Architect, R&D****
>
> T: +972-3-765-7035 | M: +972-54-470-1004 | F: +972-3-644-0930  |
> [email-masked] ****
>
> RAD Data Communications Ltd. 24, Raoul Wallenberg St. Tel-Aviv 69719,
> Israel  | www.rad.com****
>
> ** **
>
> ** **
>