The MPLS WG Archive

["Thomas D. Nadeau" <tnadeau@cisco.com>]

        Hi Mani,

        My comments are inline and are highlighted in blue.

> 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?

        No, that was a typo. There should only be two additional
indexes for the tunnelEntry: mplsTunnelSrcAddrIPv4 and
mplsTunnelSrcAddrIPv6.

> #
> #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"?

        No, that was a typo. ;) There should only be two additional
indexes for the tunnelEntry: mplsTunnelSrcAddrIPv4 and
mplsTunnelSrcAddrIPv6.  They are both added to uniquely identify
a tunnel entry, in particular, at a midpoint where two tunnels
may converge on the same LSR.

> #      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>

        Great. This is exactly what I have found. 8)

> 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

        Great.

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

        Yes.

> 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?.

        So what are you advocating here?

        --Tom