Definitions in draft-ietf-teas-yang-te-21

[italobusi]

During the review of draft-ietf-ccamp-transport-nbi-app-statement-05, the CCAMP WG Transport NBI DT has noted that the following definitions, provided in draft-ietf-teas-te-topo-and-tunnel-modeling-04, should actually be better moved/copied to draft-ietf-teas-yang-te:

o TE tunnel - a connection-oriented service provided by a layer network of delivery of a client's data between source and destination tunnel termination points. A TE tunnel in a server layer network may support a link in a client layer network (e.g. OCh layer TE tunnel supporting ODU4 link). In Figure 20, a TE tunnel interconnects tunnel termination points resident on switches C-R2 and C-R3. A TE tunnel is realized via (supported by, mapped onto) one or more layer network connections/LSPs

o TE tunnel hand-off point - an access link or inter-domain link by which a multi-domain TE tunnel enters or exits a given network domain, in conjunction with a layer network resource (such as a wavelength channel or ODUk container) allocated on the access/inter-domain link for the TE tunnel.

o TE tunnel segment - a part of a multi-domain TE tunnel that spans a given network domain and is directly and fully controlled by the domain's controller, DC. TE tunnel segment is a fragment of a multi-domain TE tunnel between

 1. the source tunnel termination point and the TE tunnel hand-off
    point outbound from the TE tunnel's first domain (head TE tunnel
    segment);

 2. inbound and outbound TE tunnel hand-off points into/from a given
    domain (transit TE tunnel segment);

 3. inbound TE tunnel hand-off point into the TE tunnel's last
    domain and the destination tunnel termination point (tail TE
    tunnel segment);

We would propose to add these definitions to draft-ietf-teas-yang-te-21

Thanks, Italo (on behalf of the Transport NBI DT)

See mail to TEAS WG: https://mailarchive.ietf.org/arch/msg/teas/H2Pd3sym1SkvS1YBW9mhZzqSspg

See also issue in TNBI DT github: https://github.com/danielkinguk/transport-nbi/issues/77

[tsaad-dev]

Tarek to look into bringing the definitions.

[italobusi]

@italobusi : check which definition could be put in this draft (better not to define terms which are not used in the document)

[tsaad-dev]

AI (team): please review the latest ID version.

[italobusi]

@italobusi : check which definition could be put in this draft (better not to define terms which are not used in the document)

What about adding the following definitions:

TE Tunnel: a connection-oriented service provided by a layer network of delivery of a client's data between source and destination tunnel termination points.

TE Tunnel Segment: a part of a multi-domain TE tunnel that spans a given network domain.

TE Tunnel Hand-off: an access link or inter-domain link by which a multi-domain TE tunnel enters or exits a given network domain.

The tunnel segment definition is assumed by this piece of code:

    container path-in-segment {
      presence "The end-to-end tunnel starts in a previous domain;
                this tunnel is a segment in the current domain.";
      description
        "If an end-to-end tunnel crosses multiple domains using
         the same technology, some additional constraints have to be
         taken in consideration in each domain.
         This tunnel is a segment that needs to be coordinated
         with previous segment stitched on head-end side.";
      uses te-types:label-set-info;
    }
    container path-out-segment {
      presence
        "The end-to-end tunnel is not terminated in this domain;
         this tunnel is a segment in the current domain.";
      description
        "If an end-to-end tunnel crosses multiple domains using
         the same technology, some additional constraints have to be
         taken in consideration in each domain.
         This tunnel is a segment that needs to be coordinated
         with previous segment stitched on head-end side.";
      uses te-types:label-set-info;
    }

The tunnel hand-off definition could be used to improve the description above (the path-in-segment and path-out-segment in fact are used to configure the hand-off points)

[italobusi]

   device.  When the model is used to manage a TE controller, the
   'tunnels' list contains all TE tunnels originating from device(s)
   that the TE controller manages.

My understanding is that when this model is used to manage a TE controller, the 'tunnels' list contains also the tunnel segments terminated or transiting through the domain.

[italobusi]

   The 'lsps' container includes the set of TE LSP(s) that are
   instantiated.  A TE LSP is identified by a 3-tuple ('tunnel-name',
   'node', 'lsp-id').  When the model is used to manage a specific
   device, the 'lsps' list contains all TE LSP(s) that traverse the
   device (including ingressing, transiting and egressing the device).

What about the case when this model is used to manage a TE controller?

I remember we have discussed this case but I do not remember the conclusion. It would be worthwhile writing it.

[italobusi]

      *  compute-only: A primary path of TE tunnel is, by default,
         provisioned so that it can is instantiated in forwarding to
         carry traffic as soon as a valid path is compute.  In some
         cases, a TE tunnel may be provisioned for the only purpose of
         computing a path and reporting it without the need to
         instantiate the LSP or commit any resources.  In such a case,
         the primary-path is configured in 'compute-only' mode to
         distinguish it from default behavior.  A 'compute-only' primary
         path is configured as a usual TE tunnel with associated per
         path constraint(s) and properties on a device or controller.
         The device or controller computes the feasible path(s) subject
         to configured constraints.  A client may query the 'compute-
         only' computed path properties 'on-demand', or alternatively,
         can subscribe notified of computed path(s) and whenever the
         path properties change.

The compute-only leaf is defined for all the paths (primary, primary-reverse, secondary, secondary-reverse).

[italobusi]

      *  te-topology-identifier: A container that includes the topology
         identifier associated with the tunnel.

My understanding is that this te-topology-identifier container, which is within the hierarchical-link container, represents the topology where the hierarchical link, supported by this TE tunnel, is instantiated.

[italobusi]

The 'lsps' container includes the set of TE LSP(s) that are instantiated. A TE LSP is identified by a 3-tuple ('tunnel-name', 'node', 'lsp-id'). When the model is used to manage a specific device, the 'lsps' list contains all TE LSP(s) that traverse the device (including ingressing, transiting and egressing the device).

2020-09-25 TEAS Call Proposed text:

When the model is used to manage a TE controller, the 'lsps' list contains all TE LSP(s) that traverse all the devices (including ingressing, transiting and egressing the device) that the TE controller manages.

[italobusi]

connection-oriented

TE Tunnel: section 1.2 of [RFC3209]

TE Tunnel Segment: a part of a multi-domain TE tunnel that spans a given network domain.

No need to define TE Tunnel Hand-off

@all: Review the TE Tunnel Segment definition

[tsaad-dev]

agreement is to move ahead with the proposed text from Italo.

[italobusi]

@tsaad-dev : add these definitions to the draft

@italobusi : send a mail to Adrian asking to include updated definitions for TE tunnel and TE tunnel segment to RFC3272-bis draft, taking into account the definition in the TE tutorial

[italobusi]

2022-02-04 TE Call

@tsaad-dev : add these definitions to the draft

@italobusi : send a mail to Adrian asking to include updated definitions for TE tunnel and TE tunnel segment to RFC3272-bis draft, taking into account the definition in the TE tutorial

Done in xxxhttps://datatracker.ietf.org/doc/html/[draft-ietf-teas-yang-te-27](https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-te-27)

No need to take actions for RFC3272-bis