The MPLS WG Archive

[manikantan <manis@future.futsoft.com>]

Hello Thomas 

#Hi,
#I would like to modify the mplsTunnelEntry to include
#a few more objects as well as indexes. I wanted to
#bring these changes to the list for discussion before
#adding them to the TE MIB due to the fact that they
#constitute a significant change, and we did not want to
#surprise anyone. This change comes from my implementation
#experience with the current version of the MIB, so it is
#grounded in an actual implementation.
#
#I would like to add five additional values to the mplsTunnelTable
#as well as augment the current indexes with two more indexes:

mani> Hope you have not mentioned the five additional values in 
this mail, as I could not see it. Are you providing these five
additional values in an another mail?

#
#mplsTunnelSrcAddrType     INTEGER,
#mplsTunnelSrcAddrIPv4   InetAddresIPv4,
#mplsTunnelSrcAddrIPv6   InetAddresIPv6,

mani> You have listed here three objects, whereas above you 
have mentioned of two more indexes. Does the above three form
index to the TE Tunnel table or the "mplsTunnelSrcAddrIPv4" and
"mplsTunnelSrcAddrIpv6" are the two indexes in addition to the
earlier indexes of "mplsTunnelIndex" and "mplsTunnelInstance"?

#      Now let me explain why. When you want to examine the tunnel
#      entry at a midpoint, it is possible for tunnelId/tunnelInstance
#      collisions to occur because the mplsTunnelId + mplsTunnelInstance
#      variables are not guaranteed to be unique within an MPLS domain.
#      A simple example of this occurs when LSR A has tunnelId = 1,
#      tunnelInstance = 0 and LSR B has tunnelId = 1, tunnelInstance = 0
#      which utilize the same next hop, LSR C. If one examines the
#      tunnel table at LSR C, it is impossible to distinguish both tunnels;
#      hence, the third index. A fourth index is required because we need
#      to support V6 addresses.
#
#      An additional benefit of the added indexes is that one can now
#      sort tunnelEntries based on src address, which is quite useful
#      at mid-points and tunnel tails. For this same reason, it might be
#      useful to add the tunnel destination address to the indexes of
#      this table as well.
#
#      --Tom

mani> To me the added indexes of Source address is valid and acceptable
as we found during our implementation that the triplet < Tunnel index,
Tunnel Instance and Source address> alone forms/identifies a unique
tunnel and not just the <Tunnel index and the Tunnel Instance>

Regarding the Destination Address as an index, this is not required to 
be added as index but can be added as a value/field in the MplsTunnelEntry.
Reason: A tunnel can be uniquely identified with the triplet < Tunnel index,
Tunnel Instance and Source address>. The Destination address present
will give added information as to what is the end point of the Tunnel

Following are some of my thoughts/doubts, which I have when I apply
the TE MIB with respect to both RSVP-TE Tunnels and CRLDP (CRLSP Paths).

I feel that the TE MIB fits perfectly with the RSVP-TE Tunnel extensions.
Reasons being, The indexes to identify a unique Tunnel 
1) Tunnel ID
2) Tunnel Instance
3) Tunnel Ingress Address ( or Source address either IPv4 or IPv6) 
are available in the RSVP objects.

The LSP_TUNNEL_IPv4 Session Object helps carrying the Tunnel Id and the
Tunnel Ingress Address (IPv4 address)in the Extended Tunnel Id field.

The LSP_TUNNEL_IPv6 Session Object helps carrying the Tunnel ID and the 
Tunnel Ingress Address (IPv6 address) in the Extended Tunnel Id field.

The LSP_TUNNEL_IPv4 Sender Template object helps carrying the
Tunnel Instance in the LSP ID field In case of IPv4 Tunnel, similarly the 
LSP_TUNNEL_IPv6 Sender Template object helps carrying the Tunnel Instance 
in the LSPID field incase of IPv6 tunnels.
(Here I have assumed the Tunnel instance mapped to the LSP Id)

In case of CRLSP the values carried in the TLVs does not map to the TE MIB
directly ( Or I might be missing out something and not clear).

The LSPID-TLV helps carrying the Tunnel ID in the "Local CR-LSP ID" field
and the Ingress LSR Router ID helps carrying the Tunnel Ingress Address.
Current specifications does not deal with the "Tunnel Instances" that
is dealt in the TE MIB. 

Hence my doubts are:
1) Should the Tunnel Instance be always treated as "0" when CRLSP tunnels are 
made?

2) Is it that the LSPID-TLV has Action flag to indicate modification of the 
Tunnel, it is not required to identify instances in CRLSP? Reason : The usage
of instance (When the instance value is mapped to the LSP_ID of the Sender
Template object) is sending indication for reroutes in RSVP?.

3) Since the LSPID-TLV in <draft-ietf-mpls-crldp-03.txt> provides support
for only IPV4 node initiated tunnels, modification will/may be required 
as follows:

LSPID-TLV 1 : IPv4 Sender

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|  LSPID-TLV-IPV4 (0x0821)  |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved        |ActFlg |      Local CR-LSP ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Ingress LSR Router ID  - IPv4 Address           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
        A fourteen-bit field carrying the value of the  LSPID-TLV-IPV4 type
        which is 0x821.

   Length
        Specifies the length of the value field in bytes.

   ActFlg
        Action Indicator Flag: A 4-bit field that indicates explicitly
        the action that should be taken if the LSP already exists on
        the LSR receiving the message. A set of indicator code points
        is proposed as follows:

                0000: indicates initial LSP setup
                0001: indicates modify LSP
   Reserved
        Zero on transmission.  Ignored on receipt.

   Local CR-LSP ID
        The Local LSP ID is an identifier of the CR-LSP locally unique
        within the Ingress LSR originating the CR-LSP.

   Ingress LSR Router ID
        An LSR may use any of its own IPv4 addresses in this field.

 
LSPID-TLV 2 : IPv6 Sender

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|  LSPID-TLV-IPV6 (0x0822)  |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved        |ActFlg |      Local CR-LSP ID          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Ingress LSR Router ID  - IPv6 Address           |
   |                                                               |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type
        A fourteen-bit field carrying the value of the  LSPID-TLV-IPV6 type
        which is 0x822.

   Length
        Specifies the length of the value field in bytes.

   ActFlg
        Action Indicator Flag: A 4-bit field that indicates explicitly
        the action that should be taken if the LSP already exists on
        the LSR receiving the message. A set of indicator code points
        is proposed as follows:

                0000: indicates initial LSP setup
                0001: indicates modify LSP
   Reserved
        Zero on transmission.  Ignored on receipt.

   Local CR-LSP ID
        The Local LSP ID is an identifier of the CR-LSP locally unique
        within the Ingress LSR originating the CR-LSP.

   Ingress LSR Router ID
        An LSR may use any of its own IPv6 addresses in this field.

4) The destination address (IPv4 or IPv6) can be carried in the RSVP-TE
objects - LSP_TUNNEL_SESSION_IPv4 or LSP_TUNNEL_SESSION_IPv6 respectively.
However in the case of CRLSP such a provision is not available. Hence 
support for this needs to be added in CRLDP too, to enable 
 a) TE MIB to be used for both CRLSP Tunnel and RSVP-TE tunnels
 b) Easy interworking of CRLSP and RSVP-TE Tunnels.

Above are my humble thoughts, 

thanks in advance
with best regards
mani
 
/*-------------------------------------------------------------------*/
S.Manikantan
Future Software Private Limited
480-481, Anna salai, Nandanam,
Chennai, Tamil Nadu, 600 035,
India.
Phone	: +91-44-4330550
Fax	: +91-44-4344157.
Email	: manis@future.futsoft.com
http://www.futsoft.com
/*--------------------------------------------------------------------*/