P-PNC awareness of underlying Optical tunnels' SRLGs

[italobusi]

In case of partial summarization, should the P-PNC be made aware of the SRLGs of the underlying Optical tunnels?

See: https://github.com/FabioPeruzzini/actn-poi/blob/master/minutes/minutes-2021-04-20.md#l3vpn-issue-38

[italobusi]

@italobusi : provide an example of how multi-layer/multi-domain path computation can be performed with partial summarization

[italobusi]

As discussed in https://github.com/FabioPeruzzini/actn-poi/pull/50#pullrequestreview-654294059, the resolution of this issue may have an impact on the current text in section 2.2 (to be assessed)

[italobusi]

2021-05-11 weekly call

It seems useful to consider also scenarios where the P-PNC would perform path computation in the packet layer without relying on MDSC having the full visibility of the packet layer resources.

In this case, the P-PNC needs to be aware of optical tunnel's SRLGs as well as the potential optical tunnels in order to perform single-domain/multi-layer path computation.

It is worth noting that when O-PNC performs optical restorarion, the SRLGs of the optical tunnel can change and the P-PNC needs to be informed about this change.

Conclusion: keep analysing the partial summarization scenario and, in parallel, investigate which option can be considered to support the summarization scenario where the MDSC delegates single-domain/multi-layer path computation to P-PNC (or L-MDSC)

[italobusi]

2021-06-01 ACTN POI call

The MDSC could retrieve the optical tunnel SRLG from the O-PNC and provide them to the P-PNC

See: https://github.com/FabioPeruzzini/actn-poi/blob/master/minutes/minutes-2021-06-01.md

[jbrentfoster]

uploaded a slide for this Multi_Layer_SRLG.pptx

[italobusi]

2021-08-11: @Paolo-Volpato , @italobusi :

In the current scenario, the setup of new multi-layer IP Links is triggered by multi-layer path computation which is performed by the MDSC.

P-PNC may still perform single-layer path computation to perform re-routing (faster than MDSC re-routing). MDSC can perform multi-layer or multi-domain re-re-routing only when the P-PNC single-layer re-rerouting fails. Therefore, P-PNC still needs to be aware of the multi-layer SRLGs.

In another possible scenario, the setup of new multi-layer IP Links is triggered by multi-layer planning which can also be performed by the MDSC.

In this case, the MDSC can delegate the single-layer path computation to the P-PNC since path computation is not triggering the setup of new multi-layer IP Links. P-PNC still needs to be aware of the multi-layer SRLGs.

Mixed cases are possible where MDSC can delegate or not path computation to P-PNC on a case-by-case, e.g., by policy decision or taking over multi-layer path computation when the single-layer path computation perfomed by the P-PNC fails.

In all these cases, MDSC requires the whole knoledge of the IP layer topology from the P-PNCs (either for multi-layer path computation or for multi-layer planning)

[italobusi]

• [ ] Review the current text and see if anything is missing about the Optical tunnels' SRLG information to be provided to P-PNCs

[italobusi]

2021-09-07 ACTN POI Call

Agreement: do not describe the configuration of the delay but write the text not to preclude this: the P-PNC should have mechanisms to restrict the attributes the MDSC can configure (e.g., restrict configuration only to the SRLG values)

There is this editors' note in the draft: Analyze how TI-LFA can take into account multi-layer SRLG disjointness, providing that SRLG information is provided by the O-PNCs to the P-PNC through the MDSC.

• [ ] update the draft text based on this discussion

[italobusi]

2021-11-23 ACTN POI Call (Slot 1)

Need to clarify which YANG data model can be used to provide the SRLG information

[italobusi]

2022-09-20 ACTN POI Call (Slot 2)

There is no yang model/automated way to pass SRLG to MSDC and P-PNC. It can be written that srlg should be properly configured in MDSC and P-PNC manually and verify it. Another option suggested by Jeff, dont provide SRLG to P-PNC, MDSC will be doing the multi-layer co-relation with SRLG information and inform to P-PNC for the next course of action. It will be again discussed in next meeting/4th Oct once Italo is back

[italobusi]

2022-09-27 ACTN POI Call (Slot 1)

Discussed again during the call as Gabriele agreed there is no current YANG data model for delivering the optical SRLGs from MDSC to P-PNC but Cisco made a lot of work on this and could provide a proposal to be discussed with the team

Agreed between all that at least the two modes of operations need to be supported as described in section 2.1.2:

• option 2 we called “Partial summarisation”: we should have the possibility to request a optical circuit with SRLG exclusion with a previous optical circuit. Gabriele explained how this was done with UNI-GMPLS. Similarly O-PNC should perform the optical impairment validation and path computation for the new optical circuit and provides back to MDSC the list of SRLGs for this new optical circuit along with path (RRO), lambda, power etc. MDSC then should be able to share these SRLGs with the P-PNC that will perform the SR-TE path computation for the new requested IP VPN service. If existing optical circuit is modified (e.g. after restoration) then O-PNC will notify MDSC of the new path characteristics (including new SRLGs) and MDSC will have to update the P-PNC that will act in consequence.

• option 3 we called “Full knowledge”: Centralised MDSC gathers all information about optical networks underneath including SRLGs from O-PNCs and performs multi-layer path computation and then push the optical circuit request towards O-PNC and the end-to-end SR-TE path request and the L3VPN/L2VPN service binding towards the P-PNC. As commented by Gabriele, apart from possible scalability issues it is not likely that MDSC can perform the optical impairment validation and path computation. Today this is done by the O-PNC in conjunction with Vendor planning tool for a good accuracy. At MDSC level it would mean that all the Vendor information (all characteristics of their NEs along with their optical impairment algorithms) is shared with an open-source planning tool like GNPy for example.

Sergio mentioned that this topic of path computation between MDSC and O-PNC was discussed a lot in TEAS for generic model https://datatracker.ietf.org/doc/html/draft-ietf-teas-yang-path-computation and in CCAMP for the specific optical path computation model https://datatracker.ietf.org/doc/html/draft-gbb-ccamp-otn-path-computation-yang and https://datatracker.ietf.org/doc/html/draft-gbb-ccamp-optical-path-computation-yang (which are currently polled for adoption as CCAMP WG drafts)

[italobusi]

2022-10-04 ACTN POI Call (Slot 2)

The MDSC can write the SRLGs of the underlay optical path in the running DS for the IP link within the te-srlgs and te-nsrlgs lists

The P-PNC can report in the operational DS these configured SRLGs plus additional SRLG it can discover within the packet domain

Jeff: is it possible the MDSC to request the O-PNC to setup an optical tunnel with disjoint SRLG than another tunnel?

In the current TE tunnel model it is possible to request the setup of secondary paths which are node/link/SRLG disjoint from the primary path within the same tunnel but it seems not possible to request the setup of two paths belonging to two different tunnels

With path computation it is possible to request the computation of two disjoint paths even if they belong to two different tunnels using the synchronization container

The example in https://github.com/FabioPeruzzini/actn-poi/files/6665830/Multi_Layer_SRLG.pptx has been analyzed

The example is assuming the colored optics in the router. In case of grey interface, the "Add/Drop SRLG" can be renamed as "Transponder SRLG"

The O-PNC can report the list of the optical tunnel SRLGs which include Conduit SRLG, Transponder SRLG, ROADM degree SRLG and ROADM node SRLG

The MDSC configures this values for the overlay IP link

The P-PNC will report the SRLGs of this IP link adding the Line Card SRLG to the list configured by the MDSC

The list of SRLGs for an optical tunnel can be quite a long list. Being able to deal with such a long list is an implementation issue and therefore outside the scope of the document.

The SRLG of an optical tunnel are reported by the O-PNC to the MDSC within the path-srlg-lists (computed-path-properties), for each path. In case the optical tunnel is configured with protection or restoration, the translation of the optical paths SRLG into IP link SRLG list is a matter of MDSC policy and the list of SRLGs configured by the MDSC to the P-PNC can also change dynamically when the optical path changes:

[italobusi]

2022-10-11 ACTN POI Call (Slot 1)

• [ ] @italobusi : add some text to describe, as a gap, the fact that the TE tunnel model does not allow requesting the setup of disjoint paths that belong to different TE tunnels

By looking at the SRLG value it is not possible to know whether a given SRLG is a Conduit SRLG, Transponder SRLG, ROADM degree SRLG or ROADM node SRLG. For the scope of the SRLG disjointness path computation this might not be an issue but there are cases where the operator is willing to know the type of SRLG

We have noted that the ietf-te YANG model supports the named-slrg definition but would like to get more information about how its use and also the definition of the cost associated with an SRLG

• [ ] @italobusi : send a mail to the TEAS WG to get more information about this issue

[italobusi]

2023-03-21 ACTN POI Call (Slot 2)

How to associate risk level with an SRLG? We will need to discuss with TE authors.

We will add some text that highlights this is a possible gap and should be investigated further in another document, or discussion.