MPLS-TE-MIB

Appreciate to comment on below :

1- For mplsTunnelConfigured , is it represent (Head-end +mid-point +

tail-end) Tunnel or just Head-end .

2- MplsTunnelIndex is defined in mpls-tc-mib as :

MplsTunnelIndex ::= TEXTUAL-CONVENTION

STATUS current

DESCRIPTION

"A unique index into mplsTunnelTable.

For tunnels signaled using RSVP, this value

should correspond to the RSVP destination

port used for the RSVP-TE session."

SYNTAX Integer32 (1..65535)

For RSVP-TE ,could it be stated as "correspond to "Tunnel ID" "

instead of "destination port used " . and add a reference to RFC

3209 .

3- mplsTunnelIndexIndex is defined as :

mplsTunnelIndexIndex OBJECT-TYPE

SYNTAX MplsTunnelIndex

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"Uniquely identifies this row."

::= { mplsTunnelEntry 1 }

mplsTunnelIndexindex which is a tunnelId is not unique key to

identify a row ,say for middle-point nodes where 2 tunnel from

different Head-end could by chance selected the same Tunnel_iD .

Also at Head-end during tunnel optimization

4- MplsTunnelInstanceIndex is defined as :

MplsTunnelInstanceIndex ::= TEXTUAL-CONVENTION

STATUS current

DESCRIPTION

"Instance index into mplsTunnelTable. The

tunnel entry with instance index 0 should

refer to the configured tunnel interface

(if one exists), and values greater an 0

should be used to indicate signaled (or backup)

tunnel LSP instances. For tunnel LSPs signaled using

RSVP, this value should correspond to the

RSVP source port used for the RSVP-TE session."

SYNTAX Unsigned32 (0..65535)

For RSVP-TE , could we use the term "LSP ID" instead of "source port "

5- mplsTunnelIngressLSRID

for RSVP-TE it is stated that this object will be equal to

"Extended Tunnel ID" .

From RFC3209 , "extented tunnel ID" normally will have a value of all

zeros ie: no restriction/mandatory on the Head-end node to populate

this filed with's it ID .

If the node do not populate "Extended Tunnel ID" ie"left all zeros

could we state that in such case mplsTunnelIngressLSRID to take the

value of " IPv4/6 Tunnel sender address" extracted from RSVP-TE

sender_template object .

6-mplsTunnelEgressLsrID is defined as :

mplsTunnelEgressLSRId OBJECT-TYPE

SYNTAX MplsLsrIdentifier

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"Specifies the egress LSR ID."

::= { mplsTunnelEntry 4 }

MplsLsridentifier is defined as :

MplsLsrIdentifier ::= TEXTUAL-CONVENTION

STATUS current

DESCRIPTION

"The Label Switching Router (LSR) identifier is the

first 4 bytes of the Label Distribution Protocol

(LDP) identifier."

SYNTAX OCTET STRING (SIZE (4))

i guess in case of RSVP-TE mplsTunnelEgressLSRID is not well defined ,

could it be better to state explicitly that in case of RSVP-TE

mplsTunnelEgressLSRID is equal to " IPV4/6 Tunnel End point Address"

which could be extracted from the session object .

7- For mplsTunnelName and mplsTunnelDescr

both fileds could be only populated by a Head-end node . guess it will

be easier for mang and troubleshooting that Mid-Point and Tail-end

also display such info .

Directly from RFC 3209 : mplsTunnelname could be populated from

"session name" part of session attribute object .

as an extention to RFC3209 : we could define an object in the range

"Class-Num = 11bbbbbb" to carry mplstunnelName and mplsTunnelDescr .

Mid-Point and tail-end node will use such object to populate

mplsTunelName and mplsTunnelDescr .

8-mplsTunnelISIf

Guess it worth to add in the definition " If this variable is set to

true then mplsTunnelInstance should be set to zero " .

9- mplsTunnelXCpointer

if mplsTunnelISIF is set to true what is the value of

mplsTunnelXcpointer .

we have 2 cases :

case1 : it is 0.0

case2 : it point to the same entry in mplsXCTable as the primary

instance (ie: the instance which is currently used to forward

traffic ) .

10- It will be clearer to a reader if the draft could clarify the

following :

A- For all fileds in mplsTunnelTable ,what are the applicable one's

for I- Head-end , II-Mid-Point , III- Tail-end

specially for Mid-Point and Tai-end how a node could populate such

fileds ie: say for RSVP-TE what fields in the signalling PDU's are

used to populate those MIB fileds .

B- For Head-end node where mplsTunnelISIF is set to true (for Mid-

Point and Tail-End : mplsTunnelISIF could not take the value of true )

what are the applicabel fileds .

Brgds

The MPLS-OPS Archive

MPLS-TE-MIB