The MPLS WG Archive

[Adrian Farrel <AF@datcon.co.uk>]

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:af@datcon.co.uk
Network Convergence Group
Data Connection Ltd., Chester, UK
http://www.datcon.co.uk/
Tel: +44 (0) 1244 313440  Fax: +44 (0) 1244 312422