Subject: RE: Additional Index for TE-MIB: mplsTunnelTable

From: manikantan <[email-masked]>
Date: Mon, 5 Jun 2000 18:33:40 +0530

Hello Thomas

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

Mani> Thanks for the clarification.

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

Mani> Sorry for not being clear with the above question. I have raised the
above question when I try to compare RSVP-TE and CRLSP and look for the 
differences, issues for interworking if any etc.,

The concept of instances of Tunnels has been explained as follows
in the TE MIB <draft-03.txt - 10 March 2000>

  "Uniquely identifies an instance of a tunnel. It 
   is useful to identify multiple instances of
   tunnels for the purposes of backup and parallel
   tunnels."

When I think to apply the instance value as part of RSVP message and 
transmit downstream, the LSP ID in the sender Template object fits 
perfectly.

(Another question, IS this the way it is to be done?)

The usage of LSP ID is very helpful in the "make-before-break" situation
for a RSVP Tunnel re-route (i.e., tunnel modification). (Reference Section 
4.6.4 Reroute procedure in rsvp-mpls-tunnel-05.txt draft).

As the usage for the reroute can be done very well with the concept of instances,
i.e., tunnel instance id, (Scope for the utilization for backup and parallel tunnels not 
available, or I would have missed out), I attempt to apply the same
in the CRLSP case too.. i.e. instances -- used for re-routing. 

Hence my question is, since the CRLSP Draft - LSPID-TLV has the action flag
for modification ( reroutes), is it that the instances are not required or reroutes?

Now my understanding is that it is not required and the instance id will
be always the same and equals zero ( with the answer to my first question is "0". )

Hope I am clear now.

thanks in advance
with best regards
mani

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 8 Jun 2000 05:59:04 +0100

Hi.  Sorry to be so slow jumping in.

<Paul>
>>>     So now I am wondering, do you need the tunnel cookie 
>>>    (since it is the source address and the tunnel index)?

<Tom>
>>      I believe that we are going to eliminate the cookies
>>      from the MIB. There was some discussion about this a
>>      while back.

I recall this discussion, and I think you are accurately 
representing the consensus.

What you are saying is that the cookie is replaced with a 
explicit fields.  This is good.

You're all right that about the information required to 
identify a tunnel anywhere apart from the source.

Now we come to the issue of signaling.

You have made the (reasonable) assumption that the Tunnel_ID
(Tunnel ID in the RSVP LSP_TUNNEL_IPvx Session Objects, or
Local CR-LSP ID in the CR-LDP LSPID TLV).  This is not,
however, a requirement yet.  I suggest we make it so by 
adding text to the Description for mplsTunnelIndex.

   "This value is exchanged in the signaling protocols
    to help to uniquely identify the tunnel at remote
    LSRs.  In RSVP this field is maps to the Tunnel ID
    field of the Session Object.  In CR-LDP it maps to
    the CR-LSP ID field in the LSPID TLV."

Although putting this wording in may seem restrictive (why
should an implementation not pick its LSP IDs in its own 
way?) I think it is compatible with your requirements that
we force MIB-configured LSPs to signal this information in
a consistent way.

How, then do you propose that the tunnel instance is signaled?
You could use the Extended Tunnel ID in RSVP but that conflicts
with where you need to signal the source address. Are you
proposing an extension to the protocols or are you happy that
tunnel instance is only visible at the source?  If this is the
case, I'd suggest reserving the value zero for use at all LSRs
apart from the ingress.  Suitable text for the Description
might be...

   "When this MIB row reflects a tunnel for which this LSR is
    not the ingress and when the signaling protocol is not
    capable of signaling the tunnel instance of a particular
    tunnel, the value of this field SHOULD be zero."

Lastly, I'd like to look at how this approach fits with merging
in RSVP.  I don't want to open up the whole subject but rather
to float a concern.

In RSVP (2205) you can merge flows if the Session IDs match (and
some other conditions).  For RSVP this amounts very much to 
ensuring that the destinations match.

In RSVP-TE it would make sense to allow merging of LSPs if many of
the same conditions hold.  The Session ID, is extended to include
the Tunnel ID and the extended Tunnel ID.

One interpretation is that you may merge LSPs if they are on the same
session, i.e. if the Session IDs are the same.  Thus, if you want to
prevent merge but allow make-before-break, you set merge_permitted,
but also fill in the Extended Tunnel ID to contain your source IP 
address.  If you want to allow merge, you set the extended Tunnel ID
to all zeros, and we can merge with any LSP that carries the same 
Tunnel ID.

It becomes a configuration issue at the ingresses to ensure that all 
Tunnels that we want to be merged use the same Tunnel ID (in your
scheme, by making sure they have the same mplsTunnelIndex on each
ingress).  

This, however, means we can't pass the source address (which doesn't
really have a meaning once we've merged).  Is this OK with your
planned use of the MIB?

Regards,
Adrian
--
Adrian Farrel  mailto:[email-masked]
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 19 Jun 2000 08:58:31 -0400

Hi,

         Responses are highlighted in blue.

>It is not clear to me how to represent a bi-directional tunnel with the MIB.
>Some of my confusion may come from the fact that I don't understand the
>mplsTunnelDirection object. For example, what does it mean to have this object
>set to "bi-directional"? Does it mean that this row refers to a bi-directional
>tunnel? Does the TunnelDirection (in, out) have any significance at the tunnel
>midpoint? What role does the cookie (or the lack of one!) play in
>bi-directional tunnels?

         We will remove this object since it is a vestage from the
time when we had bi-directional tunnels in mind (this will be
removed along with the cookie objects). This will instead be replaced
by an object which indicates whether the LSR is a tunnel src, dst, or
intermediate point.

         --Tom