RFC 8131

RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing

📅 published March 2017, from ietf

RFC 8131: RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and Resource Sharing 🎀

Okay bestie, the title block first! 💖 RFC 8131 is an Informational document from the IETF, published in March 2017 (ISSN 2070-1721). It's not on the Standards Track, so it's here to explain, not to lay down the law. The authors are X. Zhang, H. Zheng (Ed.), R. Gandhi (Ed.), Z. Ali, and P. Brzozowski. They're from Huawei Technologies, Cisco Systems, Inc., and ADVA Optical. It doesn't obsolete or update any other RFC, because the title block doesn't list any. 🦋

Abstract ✨

Okay so, in non-packet transport networks there's a need for the GMPLS end-to-end recovery scheme to bring up a restoration Label Switched Path (LSP) while the working and/or protecting LSPs stay reserved in the network after a failure. Main character energy 👑

This document walks through how the LSP association gets provided with RSVP-TE signaling for GMPLS end-to-end recovery, when a restoration LSP is used and the failed LSP is not torn down. It also covers resource-sharing-based setup and teardown of LSPs, plus LSP reversion procedures. No new signaling extensions are defined here, and it is strictly informative in nature. 💅

Status of This Memo 🌸

Not an Internet Standards Track specification, just published for information. 🍓

This is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details. 🧚

For the current status, errata, and feedback info, go to http://www.rfc-editor.org/info/rfc8131. 💜

Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please read them carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License. 🫶

Table of Contents 📚

1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
   2.1. Terminology ................................................4
   2.2. Abbreviations ..............................................4
3. Overview ........................................................4
   3.1. Examples of Restoration Schemes ............................5
        3.1.1. 1+R Restoration .....................................5
        3.1.2. 1+1+R Restoration ...................................6
               3.1.2.1. 1+1+R Restoration - Variants ...............7
   3.2. Resource Sharing by Restoration LSP ........................7
4. RSVP-TE Signaling Procedure .....................................8
   4.1. Restoration LSP Association ................................8
   4.2. Resource Sharing-Based Restoration LSP Setup ...............8
   4.3. LSP Reversion .............................................10
        4.3.1. Make-While-Break Reversion .........................10
        4.3.2. Make-Before-Break Reversion ........................11
5. Security Considerations ........................................12
6. IANA Considerations ............................................13
7. References .....................................................13
   7.1. Normative References ......................................13
   7.2. Informative References ....................................13
Acknowledgements  .................................................14
Contributors ......................................................14
Authors' Addresses ................................................15

1. Introduction 🦋

Okay, so GMPLS [RFC3945] is a whole family of protocols. It includes Open Shortest Path First - Traffic Engineering (OSPF-TE) [RFC4203] and Resource Reservation Protocol - Traffic Engineering (RSVP-TE) [RFC3473]. Together they can set up Label Switched Paths (LSPs) in non-packet transport networks. 🔥

GMPLS extends MPLS so it works with interfaces that can do Time Division Multiplexing (TDM), Lambda Switching, and Fiber Switching. These switching technologies come with several protection schemes [RFC4426] [RFC4427] (for example 1+1, 1:N, and M:N). It's giving protection squad 🛡️✨

RSVP-TE signaling has been extended to support different GMPLS recovery schemes, like end-to-end recovery [RFC4872] and segment recovery [RFC4873]. As described in [RFC6689], an ASSOCIATION object with Association Type "Recovery" [RFC4872] can be signaled in the RSVP Path message to identify the LSPs for restoration. An ASSOCIATION object with Association Type "Resource Sharing" [RFC4873] can also be signaled in the RSVP Path message, this time to identify the LSPs for resource sharing. Section 2.2 of [RFC6689] reviews the procedure for providing LSP associations for GMPLS end-to-end recovery, and Section 2.4 of that document reviews the procedure for providing LSP associations for sharing resources. 📝

Generally, GMPLS end-to-end recovery schemes set up the restoration LSP after the failure has been detected and notified on the working LSP. For a recovery scheme with revertive behavior, the restoration LSP is set up while the working LSP and/or protecting LSP are not torn down in the control plane because of a failure. In non-packet transport networks, working LSPs are typically set up over preferred paths, so service providers want to keep the resources for those working LSPs reserved. That way the service can revert to the preferred path (the working LSP) once the failure is repaired. The result is deterministic behavior and a guaranteed Service Level Agreement (SLA). 💖

In this document we go over procedures for GMPLS LSP associations, resource-sharing-based LSP setup, teardown, and LSP reversion for non-packet transport networks. Here's what's covered:

  • The procedure for providing LSP associations for GMPLS end-to-end recovery using a restoration LSP, where the working and protecting LSPs are not torn down and their resources stay reserved in the network after the failure.
  • The procedure for resource sharing using the Shared Explicit (SE) flag in conjunction with an ASSOCIATION object. In [RFC3209], the Make-Before-Break (MBB) method assumes the old and new LSPs share the SESSION object and signal the SE flag in the SESSION_ATTRIBUTE object for sharing resources. According to [RFC6689], an ASSOCIATION object with Association Type "Resource Sharing" in the Path message lets resources be shared across LSPs with different SESSION objects.
  • The procedures for LSP reversion and resource sharing, when using the end-to-end recovery scheme with revertive behavior.

This document is strictly informative in nature and does not define any RSVP-TE signaling extensions. 🌸

2. Conventions Used in This Document 🎀

2.1. Terminology 💅

The reader is assumed to know the terminology in [RFC3209], [RFC3473], [RFC4872], and [RFC4873]. The terminology for GMPLS recovery is defined in [RFC4427]. 📖

2.2. Abbreviations 🔤

  • GMPLS: Generalized Multiprotocol Label Switching
  • LSP: Label Switched Path
  • MBB: Make-Before-Break
  • MPLS: Multiprotocol Label Switching
  • RSVP: Resource Reservation Protocol
  • SE: Shared Explicit (flag)
  • TDM: Time Division Multiplexing
  • TE: Traffic Engineering

3. Overview 🧚

The GMPLS end-to-end recovery scheme, as defined in [RFC4872] and discussed in this document, only switches normal traffic to an alternate LSP after the working LSP fails. That alternate LSP isn't even partially established until then. The new alternate route is selected at the LSP head-end node. It may reuse resources of the failed LSP at intermediate nodes, and it may include additional intermediate nodes and/or links. Plot twist, it's a whole new route 🦋

3.1. Examples of Restoration Schemes 🌈

Two forms of end-to-end recovery schemes are described in the following sections: 1+R restoration and 1+1+R restoration. Other forms of end-to-end recovery schemes exist too, and they can use these signaling techniques. ✨

3.1.1. 1+R Restoration 🍓

One example of the recovery scheme considered in this document is 1+R recovery. The 1+R recovery scheme is shown in Figure 1. In this example, a working LSP on path A-B-C-Z is pre-established. Typically, after a failure is detected and notified on the working LSP, a second LSP on path A-H-I-J-Z is set up as a restoration LSP. Unlike a protecting LSP, which is set up before the failure, a restoration LSP is set up when it's needed, after the failure. 🔥

       +-----+    +-----+     +-----+     +-----+
       |  A  +----+  B  +-----+  C  +-----+  Z  |
       +--+--+    +-----+     +-----+     +--+--+
           \                                /
            \                              /
          +--+--+       +-----+        +--+--+
          |  H  +-------+  I  +--------+  J  |
          +-----+       +-----+        +-----+

Figure 1: An Example of 1+R Recovery Scheme 🧚

During failure switchover with the 1+R recovery scheme, working LSP resources generally aren't released, so the working and restoration LSPs coexist in the network. Still, the working and restoration LSPs can share network resources. 🤝 Typically, once the failure on the working LSP has been recovered, the restoration LSP isn't needed anymore. It gets torn down while the traffic is reverted to the original working LSP. Bye bye, restoration LSP 👋💜

Okay bestie, that's the end of part 1! 🎀 Part 2 picks up with 3.1.2 (1+1+R Restoration) and then Section 4, the RSVP-TE Signaling Procedure, so stay tuned. 💅✨

3.1.2. 1+1+R Restoration ✨

okay so 1+1+R is another example of the recovery scheme this doc is about 💅 here, a restoration LSP gets set up for the working LSP and/or the protecting LSP after the failure has been detected 👀 Figure 2 shows the vibe:

          +-----+       +-----+        +-----+
          |  D  +-------+  E  +--------+  F  |
          +--+--+       +-----+        +--+--+
            /                              \
           /                                \
       +--+--+    +-----+     +-----+     +--+--+
       |  A  +----+  B  +-----+  C  +-----+  Z  |
       +--+--+    +-----+     +-----+     +--+--+
           \                                /
            \                              /
          +--+--+       +-----+        +--+--+
          |  H  +-------+  I  +--------+  J  |
          +-----+       +-----+        +-----+

Figure 2: An Example of 1+1+R Recovery Scheme 🦋

so in this example, there's a working LSP on path A-B-C-Z and a protecting LSP on path A-D-E-F-Z, both pre-established 💜 then the failure gets detected and notified on the working LSP or the protecting LSP, and bam, a third LSP on path A-H-I-J-Z gets set up as the restoration LSP 🔥 the restoration LSP is the one that protects against a failure of both the working and protecting LSPs, which is giving main character energy 👑 during failover with 1+1+R, the failed LSP resources generally don't get released, so the working, protecting, and restoration LSPs all coexist in the network 🌸 the restoration LSP can share network resources with the working LSP, and it can also share with the protecting LSP 🫶 usually, the restoration LSP gets torn down once the traffic is reverted to the original LSP and isn't needed anymore 🧚

there are two possible models when you use a restoration LSP with 1+1+R 🍓

  • A restoration LSP is set up after either a working or a protecting LSP fails. Only one restoration LSP is present at a time.
  • A restoration LSP is set up after both the working and protecting LSPs fail. Only one restoration LSP is present at a time.

3.1.2.1. 1+1+R Restoration - Variants 🎀

there are two more variants you can get with a restoration LSP and 1+1+R, iykyk 🙈

  • A restoration LSP is set up after either a working or protecting LSP fails. Two different restoration LSPs may be present, one for the working LSP and one for the protecting LSP.
  • Two different restoration LSPs are set up after both working and protecting LSPs fail, one for the working LSP and one for the protecting LSP.

and in all of these models, if a restoration LSP also fails, it gets torn down and a brand new restoration LSP gets set up 💀 the drama never ends fr

3.2. Resource Sharing by Restoration LSP ✨

                          +-----+      +-----+
                          |  F  +------+  G  +--------+
                          +--+--+      +-----+        |
                             |                        |
                             |                        |
   +-----+    +-----+     +--+--+      +-----+     +--+--+
   |  A  +----+  B  +-----+  C  +--X---+  D  +-----+  E  |
   +-----+    +-----+     +-----+      +-----+     +-----+

Figure 3: Resource Sharing in 1+R Recovery Scheme 🌈

okay so using the network in Figure 3 as an example of the 1+R recovery scheme 🦋 LSP1 (A-B-C-D-E) is the working LSP, and we're assuming it allows resource sharing when the LSP traffic gets dynamically restored 💖 once a link along LSP1 fails, say Link C-D, node A has to decide which alternative path to use to signal the restoration LSP and reroute the traffic 😭 here, A-B-C-F-G-E gets picked as the restoration LSP path, and the resources on the path segment A-B-C get reused by this LSP ✨ the working LSP isn't torn down and just coexists with the restoration LSP 💅 when the head-end node A signals the restoration LSP, nodes C, F, G, and E reconfigure their resources (as listed in Table 1 of this document) to set up the LSP by sending a cross-connection command to the data plane 🫶

in the revertive recovery scheme, once the failure gets repaired, the resources on nodes C and E need to be reconfigured to set up the working LSP again (using a procedure described in Section 4.3 of this document) by sending a cross-connection command to the data plane 🔄 then the traffic gets reverted back to the original working LSP 👑

4. RSVP-TE Signaling Procedure 💜

4.1. Restoration LSP Association 🎀

when a GMPLS end-to-end recovery scheme needs a restoration LSP while keeping the resources for the working and/or protecting LSPs reserved in the network after the failure, the restoration LSP gets set up with an ASSOCIATION object. Its Association Type is set to "Recovery" [RFC4872], and its Association ID and Association Source are set to the Association ID and Association Source signaled in the Path message of the LSP it's restoring 🧚 for example, when a restoration LSP is signaled for a failed working LSP, the ASSOCIATION object in the Path message of the restoration LSP has the Association ID and Association Source set to the ones signaled in the working LSP for the "Recovery" Association Type 🍓 same deal if a restoration LSP is set up for a failed protecting LSP: the ASSOCIATION object in its Path message gets the Association ID and Association Source signaled in the protecting LSP for the "Recovery" Association Type 🌸

the procedure for signaling the PROTECTION object is specified in [RFC4872] 📜 specifically, a restoration LSP used for a working LSP is set up with the P bit cleared in the PROTECTION object in its Path message, and a restoration LSP used for a protecting LSP is set up with the P bit set in the PROTECTION object in its Path message 💅

4.2. Resource Sharing-Based Restoration LSP Setup 🦋

GMPLS LSPs can share resources during LSP setup if they have the Shared Explicit (SE) flag set in the SESSION_ATTRIBUTE objects [RFC3209] in the Path messages that create them, and:

  • As defined in [RFC3209], LSPs have identical SESSION objects, and/or
  • As defined in [RFC6689], LSPs have matching ASSOCIATION objects with the Association Type set to "Resource Sharing" signaled in their Path messages. In this case, LSPs can have different SESSION objects, i.e., a different Tunnel ID, Source and/or Destination signaled in their Path messages. 🫶

as described in Section 2.5 of [RFC3209], the whole point of make-before-break is to not disrupt traffic or adversely impact network operations while TE tunnel rerouting is in progress ✨ in non-packet transport networks, the nodes set up cross-connections along the LSP during the RSVP-TE signaling procedure. but here's the tea: a cross-connection can't simultaneously connect a shared resource to different resources in two alternative LSPs, so nodes may not be able to fulfill this request when LSPs share resources 😭

for LSP restoration upon failure, as explained in Section 11 of [RFC4872], the reroute procedure may reuse existing resources 🌈 the intermediate nodes reconfiguring cross-connections during rerouting doesn't further impact the traffic, since the traffic was already interrupted by the failed LSP 💀

the node actions for setting up the restoration LSP can be sorted into the following categories 📋

-----------------------------------+---------------------------------
|        Category                  |        Action                  |
-----------------------------------+---------------------------------
| Reusing existing resource on     | This type of node needs to     |
| both input and output interfaces | reserve the existing resources |
| (nodes A & B in Figure 3).       | and no cross-connection        |
|                                  | command is needed.             |
-----------------------------------+---------------------------------
| Reusing an existing resource only| This type of node needs to     |
| on one of the interfaces, either | reserve the resources and send |
| input or output interfaces, and  | the reconfiguration            |
| using new resource on the        | cross-connection command to its|
| other interfaces.                | corresponding data plane       |
| (nodes C & E in Figure 3).       | node on the interfaces where   |
|                                  | new resources are needed, and  |
|                                  | it needs to reuse the existing |
|                                  | resources on the other         |
|                                  | interfaces.                    |
-----------------------------------+---------------------------------
| Using new resources on both      | This type of node needs to     |
| interfaces.                      | reserve the new resources      |
| (nodes F & G in Figure 3).       | and send the cross-connection  |
|                                  | command on both interfaces.    |
-----------------------------------+---------------------------------

Table 1: Node Actions during Restoration LSP Setup 📊

depending on whether or not the resource is reused, the node actions are different 🙃 this is different from a normal LSP setup, since some nodes don't need to reconfigure the cross-connection at all 💅 and whether the control plane node needs to send a cross-connection setup or modification command to its corresponding data plane node(s) depends on checking whether the LSPs are sharing resources 🔍

4.3. LSP Reversion 🔄

if the end-to-end LSP recovery scheme uses revertive behavior, as described in Section 3 of this document, traffic can be reverted from the restoration LSP to the working or protecting LSP once its failure has been recovered ✨ there are two methods for achieving LSP reversion:

  1. Make-While-Break Reversion: resources associated with a working or protecting LSP are reconfigured while the reservations for the restoration LSP are removed.
  2. Make-Before-Break Reversion: resources associated with a working or protecting LSP are reconfigured before the reservations for the restoration LSP are removed.

heads up 🚨 in non-packet transport networks, both of the above reversion methods will cause some traffic disruption when the restoration LSP and the LSP being restored share resources and the cross-connections need reconfiguring on intermediate nodes 💔

4.3.1. Make-While-Break Reversion ✨

Okay so in this reversion method, the head-end just asks for the restoration LSP to be deleted 🗑️. Removing the reservations for the restoration LSP kicks off a reconfiguration of the resources tied to the working or protecting LSP on every node where resources are shared. The working or protecting LSP state was never removed from the nodes when the failure happened, so it's still sitting there 🧚. Whenever the reservation for the restoration LSP gets removed from a node, the data plane gets reconfigured to reflect the working or protecting LSP reservations as signaling moves along. Eventually, once the whole restoration LSP is deleted, the data plane config fully matches the working or protecting LSP reservations on the entire path. And that's it, reversion is complete 💅

Make-while-break is pretty simple in its logic, but it has a few limitations that may not be acceptable in some networks 🙈:

  • No rollback 🔙

If, for some reason, reconfiguring the data plane on one of the nodes to match the working or protecting LSP reservations fails, falling back to the restoration LSP is no longer an option 💀. Its state might already have been removed from other nodes.

  • No completion guarantee 😭

Deleting an LSP doesn't come with any guarantee of completion. If RSVP packets get lost due to a node or link failure, an LSP can end up only partially deleted. To help with this, RSVP could maintain soft state reservations and eventually remove whatever's left through refresh timeouts. But that approach isn't feasible in non-packet transport networks, where control and data channels are often separated, so soft state reservations aren't useful there 🥲.

One could argue that graceful LSP deletion [RFC3473] would provide a guarantee of completion. That's true for most cases, ngl 🫶. But many implementations will time out graceful deletion if the LSP isn't removed within a certain amount of time, e.g., due to a transit node fault. After that, deletion procedures that provide no completion guarantees will be attempted. So in corner cases, a completion guarantee just can't be provided 🫠.

  • No explicit notification of completion to head-end node 👀

Sometimes it'd be super useful for the head-end to know when the data plane has been reconfigured to match the working or protecting LSP reservations. That knowledge could be used to kick off things like enabling alarm monitoring, power equalization, and more. Unfortunately, for the reasons mentioned above, make-while-break reversion doesn't have that explicit notification 💔.

4.3.2. Make-Before-Break Reversion 🦋

This reversion method can be used to overcome the limitations of make-while-break reversion. It's similar in spirit to the MBB concept used for re-optimization. Instead of relying on deletion of the restoration LSP, the head-end chooses to establish a new reversion LSP. That reversion LSP duplicates the configuration of the resources on the working or protecting LSP and uses identical ASSOCIATION and PROTECTION objects in the Path message of that LSP. Only if the setup of this LSP is successful will the other (restoration and working or protecting) LSPs be deleted by the head-end. MBB reversion has two parts 👑:

A) Make part:

Creating a new reversion LSP following working or protecting the LSP. The reversion LSP shares all of the resources of the working or protecting LSP and may share resources with the restoration LSP. As the reversion LSP is created, resources are reconfigured to match its reservations. So after the reversion LSP is created, the data plane configuration reflects working or protecting LSP reservations 🌸.

B) Break part:

After the "make" part is finished, the original working or protecting and restoration LSPs are torn down, and the reversion LSP becomes the new working or protecting LSP. Removing reservations for working or restoration LSPs doesn't cause any resource reconfiguration on the reversion LSP. Nodes follow the same procedures for the "break" part of any MBB operation 🔥. So after the working or protecting and restoration LSPs are removed, the data plane configuration is exactly the same as before restoration started. Thus, reversion is complete 🎀.

MBB reversion uses make-before-break characteristics to overcome the challenges of make-while-break reversion, as follows:

  • Rollback 🛟

If the "make" part fails, the (existing) restoration LSP will still be used to carry existing traffic, since the restoration LSP state was not removed. The same logic applies here as for any MBB operation failure.

  • Completion guarantee 🔒

LSP setup is resilient against RSVP message loss, since Path and Resv messages are refreshed periodically. So, given that the network eventually recovers from node and link failures, reversion LSP setup is guaranteed to finish with either success or failure 🌈.

  • Explicit notification of completion to head-end node 🔔

The head-end knows the data plane has been reconfigured to match working or protecting LSP reservations on the intermediate nodes when it receives a Resv message for the reversion LSP 💜.

5. Security Considerations ⚠️

This is the part where we get serious, bestie 😤. This document reviews procedures defined in [RFC3209], [RFC4872], [RFC4873], and [RFC6689] and does not define any new procedures. It does not introduce any new security issues. Those security issues were already covered in [RFC3209], [RFC4872], [RFC4873], and [RFC6689] 🛡️.

6. IANA Considerations 🧚

This document does not require any IANA actions. No registries to touch, no drama 💖.

7. References 📚

7.1. Normative References

[RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
            Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
            <http://www.rfc-editor.org/info/rfc3209>.

[RFC3473]   Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Resource ReserVation
            Protocol-Traffic Engineering (RSVP-TE) Extensions",
            RFC 3473, DOI 10.17487/RFC3473, January 2003,
            <http://www.rfc-editor.org/info/rfc3473>.

[RFC4872]   Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
            Ed., "RSVP-TE Extensions in Support of End-to-End
            Generalized Multi-Protocol Label Switching (GMPLS)
            Recovery", RFC 4872, DOI 10.17487/RFC4872, May 2007,
            <http://www.rfc-editor.org/info/rfc4872>.

[RFC4873]   Berger, L., Bryskin, I., Papadimitriou, D., and A.
            Farrel, "GMPLS Segment Recovery", RFC 4873,
            DOI 10.17487/RFC4873, May 2007,
            <http://www.rfc-editor.org/info/rfc4873>.

[RFC6689]   Berger, L., "Usage of the RSVP ASSOCIATION Object",
            RFC 6689, DOI 10.17487/RFC6689, July 2012,
            <http://www.rfc-editor.org/info/rfc6689>.

7.2. Informative References

[RFC3945]   Mannie, E., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Architecture", RFC 3945,
            DOI 10.17487/RFC3945, October 2004,
            <http://www.rfc-editor.org/info/rfc3945>.

[RFC4203]   Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
            in Support of Generalized Multi-Protocol Label Switching
            (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
            <http://www.rfc-editor.org/info/rfc4203>.

[RFC4426]   Lang, J., Ed., Rajagopalan, B., Ed., and D.
            Papadimitriou, Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Recovery Functional Specification",
            RFC 4426, DOI 10.17487/RFC4426, March 2006,
            <http://www.rfc-editor.org/info/rfc4426>.

[RFC4427]   Mannie, E., Ed., and D. Papadimitriou, Ed., "Recovery
            (Protection and Restoration) Terminology for Generalized
            Multi-Protocol Label Switching (GMPLS)", RFC 4427,
            DOI 10.17487/RFC4427, March 2006,
            <http://www.rfc-editor.org/info/rfc4427>.

Acknowledgements 🙏

The authors would like to thank:

  • George Swallow for the discussions on the GMPLS restoration. 🗣️
  • Lou Berger for the guidance on this work. 🌟
  • Lou Berger, Vishnu Pavan Beeram, and Christian Hopps for reviewing this document and providing valuable comments. 💌

A special thanks to Dale Worley for his thorough review of this document 👑.

Contributors 💜

Gabriele Maria Galimberti
Cisco Systems, Inc.

Email: ggalimbe@cisco.com

Authors' Addresses 📮

Xian Zhang
Huawei Technologies
F3-1-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
China

Email: zhang.xian@huawei.com


Haomian Zheng (editor)
Huawei Technologies
F3-1-B R&D Center, Huawei Base
Bantian, Longgang District
Shenzhen 518129
China

Email: zhenghaomian@huawei.com


Rakesh Gandhi (editor)
Cisco Systems, Inc.

Email: rgandhi@cisco.com


Zafar Ali
Cisco Systems, Inc.

Email: zali@cisco.com


Pawel Brzozowski
ADVA Optical

Email: PBrzozowski@advaoptical.com
📦 where this page comes from