The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2006-Jun> msg00107



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

[mpls] Reg: One clarification needed reg RFC 3209 on the scopeofTunnel ID

  • From: "Zafar Ali \(zali\)" <zali@cisco.com>
  • Date: Wed, 21 Jun 2006 02:24:41 -0400
  • Thread-Index: AcaUNx0ARcpl25W6S8KQ9VhvmEn7awAQvI+w
  • Thread-Topic: [mpls] Reg: One clarification needed reg RFC 3209 on the scopeofTunnel ID
  • X-Brightmail-Tracker: AAAAAA==
  • X-IronPort-AV: i="4.06,158,1149490800"; d="scan'208,217"; a="30111652:sNHT53383220"
  • X-OriginalArrivalTime: 21 Jun 2006 06:24:43.0065 (UTC)FILETIME=[6220B290:01C694FB]

 

From: Dutta, Pranjal [mailto:pdutta@riverstonenet.com]
Sent: Tuesday, June 20, 2006 3:00 AM
To: mpls@ietf.org
Subject: [mpls] Reg: One clarification needed reg RFC 3209 on the scope ofTunnel ID

Hi All,

           RFC 3209 states regarding uniquely identifying a LSP Tunnel as follows:

 

“A tunnel ID is part of the SESSION object.
   The SESSION object uniquely defines a traffic engineered tunnel.  The
 
 
 
Awduche, et al.             Standards Track                     [Page 7]
 
RFC 3209           Extensions to RSVP for LSP Tunnels      December 2001
 
 
   SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID.  The
   SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION
   object uniquely identifies an LSP tunnel”
 
So at the ingress LSR, a Session Object is identified with Tunnel ID, Dst IPV4/IPV6 Address of the Tunnel and Ext Tunnel ID (which can be set to source address). That means both tunnel_id and dst_addr uniquely identifies a LSP tunnel. 
 
You also need LSP ID; specifically (source IP address, Destination IP address, LSP ID, tunnel ID and ext tunnel ID) uniquely identify an LSP. 
Also note that a tunnel "can" have multiple LSP-es (e.g., during reopt).  
 
With respect to an ingress LSR does that mean that tunnel_id is specific to one particular destination  
 
 
 and the same tunnel_id may be used for
another tunnel (originating at the same LSR) that goes to diff. destination?
 
 No,  and I don't see any reason why you would like to reuse the tunnel ID field (bit space is not an issue in any deployment). 
 
Info on this would be of great help.
 
Thanks in advance,
Pranjal
 
 
 
 
 
 
 
 

 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls