The MPLS WG Archive

[George Swallow <swallow@cisco.com>]

> I was envisioning a case where a bandwidth change was not a separate tunnel
> setup, the LSP ID changed without any interruption or change in the
> conntectivity of the path . If there is build the new then tear down the
> old, then there is no gap in any monitoring case.
 
If you change the LSP-ID, that changes the sender-template.  Ipso
facto a new setup.

> As for TTSI, it's simply a node specific LSP Identifier that allows for an
> IPv4/v6 LSR ID and 32 bits for an LSP identifier. The assumption is that the
> originating LSR most usefully administers LSP-IDs independently of the
> individual control protocol used. The initial draft of Y.1711 was focused on
> P2P ER-LSPs which meant RSVP-TE or CR-LDP, hence the stipulation that the
> first two bytes of the LSP-ID were padded with zeros to align with LSP-ID as
> defined in the signalling protocols. If there is a problem with this, it is
> not leaping out at me....

As we use it, an (RSVP-TE) LSP-ID is *only* unique to the tunnel.  We
just use it as an instance number and increment it when we reroute or
change bandwidth.  If I setup five tunnels they will have five
different tunnel-IDs, but they can *all* have the same LSP-ID.

To uniquely identify a TE-Tunnel LSP. you need *all* of the fields in
the session and sender-template objects.  That why we carry those in
LSP ping.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824