[Teas] What dynamic TE link attributes could be deduced from the Hierarchy TE tunnel supporting the link?

[Igor Bryskin <[e-mail]>]

Oscar and All,

There was a question in the Monday’s meeting: “What dynamic TE link attributes could be deduced from the Hierarchy TE tunnel supporting the link?”
Just to be on the same page:

Hierarchy TE tunnel (also known in GMPLS as H-LSP or FA-LSP) is a tunnel supporting a dynamic TE link.

Dynamic TE links show up in (and disappear from) a TE topology as a result of multi-layer traffic engineering. Dynamic TE link (supported by Hierarchy TE tunnel dynamically set up in a server layer network) is automatically (i.e. without explicit configuration request) added to a client layer network TE topology to augment the topology with additional flexibility to ensure successful completion of the path computation for and provisioning of a client layer network connection /LSP. For example, am ODUk hierarchy TE tunnel can support a dynamic Ethernet layer TE link to enable provisioning an Ethernet layer connection on a network that does not have sufficient static Ethernet layer connectivity.

Likewise, dynamic TE link is automatically removed from the TE topology (and supporting it hierarchy TE tunnel is released) as soon as the TE link stops being used by at least one client layer connection/LSP.

The following parameters/attributes of a dynamic TE link could be deduced from the supporting hierarchy TE tunnel:

1)      TE topology ID, local/remote node/link IDs – from the hierarchy TE tunnel’s configuration;

2)      Layer ID – from the tunnel’s TTPs inter-layer locks and adaptation capabilities;

3)      Maximum bandwidth, unreserved bandwidth – from the resources allocated for and on the tunnel;

4)      Protection capabilities and status – from the connections supporting the tunnel;

5)      Underlay TE paths – from actual paths (RROs) of the connections supporting the tunnel

6)      SRLGs – could be computed as overlaps with the tunnels/connections supporting other TE links


As of today some of the dynamic TE tunnel attributes cannot be deduced from the supporting hierarchy TE tunnels. Examples: TE metric, administrative colors. There is a couple of options we can consider to manage such attributes:

a)      Use locally configured on the topology provider defaults/templates to set initial values and allow for their subsequent modification via explicit configuration requests;

b)     Add such attributes to the hierarchy TE tunnel configuration (i.e. next to already provided TE topology local/remote node/link IDs)
Cheers,
Igor