RFC 5145

Framework for MPLS-TE to GMPLS Migration

📅 published March 2008, from ietf

Framework for MPLS-TE to GMPLS Migration 🦋

Okay bestie, so this is RFC 5145 💖 It was written by K. Shiomoto, Ed. from NTT, and it's an Informational doc from the Network Working Group, dated March 2008. Its header doesn't list any RFCs it obsoletes or updates ✨

Status of This Memo

This memo is here to give the Internet community information 📚 It's not a standard of any kind, and you're free to share it around as much as you like 🌈

Abstract

Moving from Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) to Generalized MPLS (GMPLS) is basically upgrading an MPLS-TE control plane into a GMPLS control plane 🔥 The strategy you pick depends on a bunch of stuff, like the service provider's deployment plan, customer demand, and operational policy 💅

This doc walks through several migration models and strategies for going from MPLS-TE to GMPLS 🦋 While you're migrating, MPLS-TE and GMPLS devices or networks can end up coexisting, and that can mean they need to interwork with each other 🫶 The interworking stuff gets discussed because it shapes which strategy makes sense. It's a framework that gives operators a migration toolkit to help them choose a good strategy 🧰

It also lists some solutions that can help with interworking, and points out a few potential issues too ⭐

Table of Contents

   1. Introduction ....................................................3
   2. Conventions Used in This Document ...............................3
   3. Motivations for Migration .......................................4
   4. MPLS to GMPLS Migration Models ..................................5
      4.1. Island Model ...............................................5
           4.1.1. Balanced Islands ....................................6
           4.1.2. Unbalanced Islands ..................................6
      4.2. Integrated Model ...........................................7
      4.3. Phased Model ...............................................8
   5. Migration Strategies and Toolkit ................................8
      5.1. Migration Toolkit ..........................................9
           5.1.1. Layered Networks ....................................9
           5.1.2. Routing Interworking ...............................11
           5.1.3. Signaling Interworking .............................12
           5.1.4. Path Computation Element ...........................13
   6. Manageability Considerations ...................................13
      6.1. Control of Function and Policy ............................13
      6.2. Information and Data Models ...............................14
      6.3. Liveness Detection and Monitoring .........................14
      6.4. Verifying Correct Operation ...............................14
      6.5. Requirements on Other Protocols and Functional
           Components ................................................14
      6.6. Impact on Network Operation ...............................15
      6.7. Other Considerations ......................................15
   7. Security Considerations ........................................15
   8. Acknowledgements ...............................................16
   9. References .....................................................16
      9.1. Normative References ......................................16
      9.2. Informative References ....................................17
   10. Contributors' Addresses .......................................17

1. Introduction ✨

Migrating from Multiprotocol Label Switching Traffic Engineering (MPLS-TE) to Generalized MPLS (GMPLS) means evolving an MPLS-TE-based control plane into a GMPLS-based one 💖 So the network being migrated here is a packet-switching network 📦

There are a few reasons people do this, mainly wanting the new features and functions that GMPLS protocols added, which just aren't in MPLS-TE for packet networks 🎀 Also, before you migrate a packet-switching network, you might decide to migrate a lower-layer network that has no control plane (say, one run by a management plane) over to a GMPLS control plane first 🧚 That can create a need for MPLS-TE/GMPLS (transport network) interworking, which gives you better TE support and makes the later packet-switching migration easier 🌸

The strategy gets picked based on the service provider's deployment plan, customer demand, deployed network equipment, operational policy, and more 💅 But whatever transition mechanisms you use should also keep newly introduced GMPLS networks running consistently, while hurting the operation of existing MPLS-TE networks as little as possible 🫶

This doc describes several migration strategies and the interworking scenarios that pop up during migration 🦋 It also looks at what this means for network deployments and protocol usage 👑 Since GMPLS signaling and routing protocols aren't the same as MPLS-TE control protocols, interworking mechanisms between MPLS-TE and GMPLS networks (or network elements) might be needed to smooth over those differences 🔥

Quick note: MPLS-TE and GMPLS protocols can coexist as "ships in the night" with no interworking issues at all 🚢🌙

2. Conventions Used in This Document 📝

Okay so, this is not a requirements document 🙈 But the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119], so the recommendations that get made are clear 💜

In the rest of this doc, the term "GMPLS" covers both packet switching capable (PSC) and non-PSC. If you need to be specific, the terms "PSC GMPLS" or "non-PSC GMPLS" get used explicitly 🌈

In general, the term "MPLS" means MPLS traffic engineering (MPLS-TE) only ([RFC3209], [RFC3630], and [RFC3784]). It leaves out other MPLS protocols, like the Label Distribution Protocol (LDP) ✨ TE functionalities of MPLS could be migrated to GMPLS, but non-TE functionalities couldn't. If non-TE MPLS is what's meant, it gets spelled out explicitly 🍓

The reader is assumed to already know the terminology from [RFC3945] 📖

3. Motivations for Migration 🌸

Every service provider has their own reasons for migrating, so this section just gives background so the migration discussions make sense in context 💖 Sections 4 and 5 have examples that show the migration models and processes ✨

Upgrading an MPLS-capable Label Switching Router (LSR) to include GMPLS capabilities can happen for one or more reasons, and this list isn't exhaustive 🎀

  • To add all GMPLS PSC features to an existing MPLS network (upgrade MPLS LSRs). 🔥
  • To add specific GMPLS PSC features and operate them within an MPLS network (e.g., [RFC4872] and [RFC4873]). 🦋
  • To integrate a new GMPLS PSC network with an existing MPLS network (without upgrading any of the MPLS LSRs). 🧩
  • To allow existing MPLS LSRs to interoperate with new non-MPLS LSRs supporting only GMPLS PSC and/or non-PSC features. 🫶
  • To integrate multiple control networks, e.g., managed by separate administrative organizations, and which independently utilize MPLS or GMPLS. 👑
  • To build integrated PSC and non-PSC networks. The non-PSC networks are controlled by GMPLS. 🌈

The goal of migrating from MPLS to GMPLS is for all LSRs, and the entire network, to support GMPLS protocols 💅 Along the way, you'll have various interim situations, which bring about the interworking situations described in this doc 🧚 Those interim situations might hang around for a good while, but the ultimate goal is not to keep them around 🙅‍♀️ For this document, they should be treated as temporary and transitory ⏳

4. MPLS to GMPLS Migration Models 👑

Three reference migration models get described below 🦋 Multiple migration models may coexist in the same network 💜

4.1. Island Model 🏝️

In the island model, "islands" of network nodes running one protocol exist inside a "sea" of nodes using the other protocol 🌊 It's giving archipelago energy 💖

For example, picture an island of GMPLS-capable nodes (PSC) dropped into a legacy MPLS network 🎀 That island could be made of newly added GMPLS nodes, or it could come from upgrading existing nodes that used to run MPLS protocols ✨

The opposite is also pretty possible. An island might be MPLS-capable inside a GMPLS sea 👀 That could happen in the later stages of migration, once all but a few islands of MPLS-capable nodes have been upgraded to GMPLS 🔥

It's also possible that a lower-layer, manually-provisioned network (like a Time Division Multiplexing (TDM) network) gets built under an MPLS PSC network 🧱 While both networks are being migrated to GMPLS, the lower-layer network might get migrated first. That would look like a GMPLS island within an MPLS sea 🌸

Lastly, you can treat individual nodes as islands 🧚 You could upgrade or insert a single GMPLS-capable node inside an MPLS network and treat that GMPLS node as an island 💅

Over time, collections of MPLS devices get replaced or upgraded to make new GMPLS islands or extend existing ones 🫶 Separate GMPLS islands can also join together until the whole network is GMPLS-capable 🌈

From a migration and interworking point of view, we need to look at how these islands are positioned and how Label Switched Paths (LSPs) connect between them 🦋

Four categories of interworking scenarios are considered: (1) MPLS-GMPLS-MPLS, (2) GMPLS-MPLS-GMPLS, (3) MPLS-GMPLS, and (4) GMPLS-MPLS. In case 1, the interworking behavior is examined based on whether the GMPLS islands are PSC or non-PSC 💖

Figure 1 shows an example of the island model for MPLS-GMPLS-MPLS interworking ✨ The model has a transit GMPLS island sitting in an MPLS sea 🌊 The nodes on the edge of the GMPLS island (G1, G2, G5, and G6) are called "island border nodes" 🎀 If the GMPLS island were non-PSC, then all nodes except the island border nodes in the GMPLS-based transit island (G3 and G4) would be non-PSC devices, meaning optical equipment (TDM, Lambda Switch Capable (LSC), and Fiber Switch Capable (FSC)) 🔆

   .................  ..........................  ..................
   :      MPLS      :  :          GMPLS         :  :     MPLS       :
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :|R1 |__|R11|___| G1 |_________|G3 |________| G5 |___|R31|__|R3 |:
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :      ________/ :  :  _______/  |   _____ / :  :  ________/     :
   :     /          :  : /          |  /        :  : /              :
   :+---+  +---+   +----+         +-+-+        +----+   +---+  +---+:
   :|R2 |__|R21|___| G2 |_________|G4 |________| G6 |___|R41|__|R4 |:
   :+---+  +---+   +----+         +---+        +----+   +---+  +---+:
   :................:  :........................:  :................:

      |<-------------------------------------------------------->|
                                  e2e LSP

                  Figure 1: Example of the island model
                    for MPLS-GMPLS-MPLS interworking

We're only one part in, so there's a lot more coming up 🧚💖

4.1.1. Balanced Islands ✨

Okay so in the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS cases, LSPs start and end using the same protocols 🫶. Possible strategies include:

  • tunneling the signaling across the island network using LSP nesting or stitching [RFC5150] (the latter is only for GMPLS-PSC) 🎀
  • protocol interworking or mapping (both are only for GMPLS-PSC) 💅

4.1.2. Unbalanced Islands

Okay, so you already know there are two island interworking models that support bordering islands 🌸 GMPLS(PSC)-MPLS and MPLS-GMPLS(PSC) island cases are likely to pop up when the migration strategy isn't built around a core infrastructure, and instead has edge nodes (ingress or egress) sitting in islands with different capabilities. It's giving real-life messy network 😭

In this case, an LSP starts or ends in a GMPLS (PSC) island and, correspondingly, ends or starts in an MPLS island. The only way to handle this mode of operation is protocol interworking or mapping 🧚. Figure 2 shows the reference model for this migration scenario. The head-end and tail-end LSRs live in distinct control plane clouds ☁️.

............................  .............................
:            MPLS          :  :       GMPLS (PSC)         :
:+---+        +---+       +----+        +---+        +---+:
:|R1 |________|R11|_______| G1 |________|G3 |________|G5 |:
:+---+        +---+       +----+        +-+-+        +---+:
:      ______/  |   _____/ :  :  ______/  |   ______/     :
:     /         |  /       :  : /         |  /            :
:+---+        +---+       +----+        +-+-+        +---+:
:|R2 |________|R21|_______| G2 |________|G4 |________|G6 |:
:+---+        +---+       +----+        +---+        +---+:
:..........................:  :...........................:

  |<-------------------------------------------------->|
                      e2e LSP

           Figure 2: GMPLS-MPLS interworking model

Quick reminder, bestie: this scenario is also affected by the directionality of the LSP, and the direction in which the LSP is established 👑.

4.2. Integrated Model

The second migration model is a more integrated migration strategy 💜. New devices that can run both MPLS and GMPLS protocols get introduced into the MPLS network.

In the integrated model, there are two types of nodes during migration:

  • those that support MPLS only (legacy nodes); and
  • those that support MPLS and GMPLS.

Here's the vibe: as existing MPLS devices get upgraded to support both, the network keeps running with an MPLS control plane, but some LSRs can also operate with a GMPLS control plane 🦋. So, LSPs are provisioned using MPLS protocols where one end point of a service is a legacy MPLS node, and/or where the selected path between end points goes through a legacy node that isn't GMPLS-capable. But where the service can be provided using only GMPLS-capable nodes [RFC5073], it may be routed accordingly, and it can reach a higher level of functionality by using GMPLS features ✨.

Once every device in the network is GMPLS-capable, the MPLS-specific protocol elements may be turned off, and no new devices need to support these protocol elements 🎀.

In this model, the questions to be addressed are about the coexistence of the two protocol sets within the network. Actual interworking is not a concern 🙈.

4.3. Phased Model

The phased model introduces GMPLS features and protocol elements into an MPLS network one by one 🌈. For example, some objects or sub-objects (such as the Explicit Route Object (ERO) label sub-object, [RFC3473]) might be introduced into the signaling used by LSRs that are otherwise MPLS-capable. This would produce a kind of hybrid LSR 🧚.

This approach may seem simpler to implement, because you can quickly and easily pick up new key functions without upgrading the whole protocol implementation 💅. It's most likely to be used where there's a desire to rapidly implement one particular function within a network, without having to install and test the full GMPLS function 🍓.

Interoperability concerns get exacerbated by this migration model, unless all LSRs in the network are updated simultaneously and there is a clear understanding of which subset of features goes into the hybrid LSRs 😭.

Interworking between a hybrid LSR and an unchanged MPLS LSR would put the hybrid LSR in the role of a GMPLS LSR, as described in the previous sections, and put the unchanged LSR in the role of an MPLS LSR. Different hybrids inside the network will complicate matters considerably 💀. So this model is only appropriate when the set of new features to be deployed is well known and limited, and when the network operators of the ISP(s) involved, plus all vendors whose equipment will be involved in the migration, clearly understand and agree on that set of features 🫶🔥.

5. Migration Strategies and Toolkit

An appropriate migration strategy is selected by a network operator based on factors including the service provider's network deployment plan, customer demand, existing network equipment, operational policy, support from its vendors, etc. 👑

For PSC networks, the migration strategy involves choosing between the models described in the previous section. The choice depends on the final objective (full GMPLS capability, partial upgrade to include specific GMPLS features, or no change to existing IP/MPLS networks), and on the immediate objectives (full, phased, or staged upgrade) 🌸.

For PSC networks serviced by non-PSC networks, two basic migration strategies can be considered 🦋. In the first strategy, the non-PSC network is made GMPLS-capable first, and then the PSC network is migrated to GMPLS. This might happen when GMPLS-based non-PSC sub-networks are introduced into legacy MPLS-based networks to expand network capacity 💖. After that, the legacy MPLS-based PSC network is migrated to be GMPLS-capable, as described in the previous paragraph. Finally, the entire network, including both PSC and non-PSC nodes, may be controlled by GMPLS 🎀.

The second strategy is to migrate the PSC network to GMPLS first, and then enable GMPLS within the non-PSC network. The PSC network gets migrated as described before, and once the entire PSC network is completely converted to GMPLS, GMPLS-based non-PSC devices and networks may be introduced without any issues of interworking between MPLS and GMPLS 🧚.

These migration strategies and the migration models described in the previous section are not necessarily mutually exclusive. Mixtures of all strategies and models could be applied. The migration models and strategies you pick will give rise to one or more of the interworking cases described in the following section 💅✨.

5.1. Migration Toolkit

As we've covered, an essential part of any migration and deployment strategy is how the MPLS and GMPLS (or hybrid) LSRs interwork 🫶. This section sets out some of the alternatives for achieving interworking between MPLS and GMPLS, and identifies some of the issues that need to be addressed. This document does not describe solutions to these issues 🙈.

Note that it is possible to consider upgrading the routing and signaling capabilities of LSRs from MPLS to GMPLS separately 🌈.

5.1.1. Layered Networks

In the balanced island model, LSP tunnels [RFC4206] are a solution for carrying end-to-end LSPs across islands of incompatible nodes 🦋. Network layering is often used to separate domains of different data plane technology. It can also separate domains of different control plane technology (such as MPLS and GMPLS protocols), and the solutions developed for multiple data plane technologies can be usefully applied to this situation [RFC3945], [RFC4206], and [RFC4726]. [MLN-REQ] gives a discussion of the requirements for multi-layered networks 💜.

The GMPLS architecture [RFC3945] identifies three architectural models for supporting multi-layer GMPLS networks, and these models may be applied to separating MPLS and GMPLS control plane islands 👑.

  • In the peer model, both MPLS and GMPLS nodes run the same routing instance, and routing advertisements from within islands of one level of protocol support are distributed to the whole network. This is achievable only, as described in Section 5.1.2, either by direct distribution or by mapping of parameters.

Signaling in the peer model may result in contiguous LSPs, stitched LSPs [RFC5150] (only for GMPLS PSC), or nested LSPs. If the network islands are non-PSC, then the techniques of [MLN-REQ] may be applied, and these techniques may be extrapolated to networks where all nodes are PSC, but where there is a difference in signaling protocols 🎀.

  • The overlay model preserves strict separation of routing information between network layers. This is suitable for the balanced island model, and there is no requirement to handle routing interworking. Even though the overlay model preserves separation of signaling information between network layers, there may be some interaction in signaling between network layers 🧚.

The overlay model requires the establishment of control plane connectivity for the higher layer across the lower layer 🌸.

  • The augmented model allows limited routing exchange from the lower-layer network to the higher-layer network. Generally speaking, this assumes that the border nodes provide some form of filtering, mapping, or aggregation of routing information advertised from the lower-layer network. This architectural model can also be used for balanced island model migrations. Signaling interworking is required as described for the peer model 💖.
  • The border peer architecture model is defined in [RFC5146]. It is a modification of the augmented model where the layer border routers have visibility into both layers, but no routing information is otherwise exchanged between routing protocol instances. This architectural model is particularly suited to the MPLS-GMPLS-MPLS island model for PSC and non-PSC GMPLS islands. Signaling interworking is required as described for the peer model 🔥.

5.1.2. Routing Interworking

okay so migration might need some routing interworking between MPLS and GMPLS 🛣️ GMPLS takes the TE info the IGPs advertise and adds non-PSC info plus extended PSC info. The GMPLS stuff rides along as extra TLVs next to the MPLS stuff, so MPLS LSRs can "see" every GMPLS LSR as if it were an MPLS PSC LSR 👀 They also see the other GMPLS info, but they just ignore it and flood it along transparently across the MPLS network so other GMPLS LSRs can use it. iconic behavior, honestly 🦋

  • Routing separation is achieved in the overlay and border peer models, and it's so convenient bestie 💅 Only the border nodes have to know about the different protocol variants, and no mapping is required. It's suitable for the MPLS-GMPLS-MPLS and GMPLS-MPLS-GMPLS island migration models.
  • Direct distribution means MPLS routing info gets flooded into the GMPLS network, and GMPLS routing info gets flooded into the MPLS network. The border nodes don't try to filter anything 🙈 This works because MPLS routers will ignore GMPLS routing info they don't understand, but they'll keep flooding it anyway. The extra GMPLS info won't mess with how MPLS LSRs pick their routes. That's totally fine in a PSC-only network, but in a peer architecture network with non-PSC nodes it can get messy 💀 MPLS nodes can't tell the switching types of the other LSRs, so they'll try to signal end-to-end LSPs assuming every LSR is PSC. Island border nodes would then have to take triggered action to set up tunnels across islands with different switching capabilities.

GMPLS LSRs might feel the impact when the GMPLS-specific info is missing from advertisements that MPLS LSRs start. Specific procedures might be needed to keep GMPLS nodes behaving consistently 🧚 If that gets sorted out, then direct distribution can be used in all migration models, except the overlay and border peer architectural models, where the problem just doesn't show up.

  • Protocol mapping converts routing advertisements so they can be received in one protocol and sent out in the other 🌈 For example, a GMPLS routing advertisement could have all of its GMPLS-specific info stripped out and then get flooded as an MPLS advertisement. This needs careful standardization of the correct behavior, especially when an MPLS advertisement needs default values for GMPLS-specific fields generated before it can be flooded further. There's also a real risk of confusion in closely meshed networks where lots of LSRs have both MPLS- and GMPLS-capable interfaces 😭 This option for routing interworking during migration is NOT RECOMMENDED for any migration model. Also, converting GMPLS-specific sub-TLVs into MPLS-specific ones without stripping the GMPLS-specific ones counts as a variant of the solution in the bullet above (unknown sub-TLVs should be ignored [RFC3630] but must continue to be flooded).
  • Ships in the night means both the MPLS and GMPLS routing protocol variants run in the same network at the same time, as separate routing protocol instances 🚢 The two instances are independent and only create routing adjacencies between LSRs of the same type. This mode may be appropriate for the integrated migration model ✨

5.1.3. Signaling Interworking

signaling protocols are the ones that actually set up LSPs, so they're the main thing to worry about for interworking during migration 🔥 Compatibility gets tricky because MPLS and GMPLS signaling use different encodings and codepoints, and also because they don't offer exactly the same functionality.

  • Tunneling and stitching [RFC5150] (the GMPLS-PSC case) can help you avoid direct protocol interworking during migration in the island model, since protocol elements get carried across migration islands transparently without being inspected 🦋 Still, you may need to put in care to get the functional mapping right, because one set of features might need to be supported across a network built for a different set. In general this is pretty easy in the MPLS-GMPLS-MPLS model, but it can be hard in the GMPLS-MPLS-GMPLS model. For example, when end-to-end bidirectional LSPs are requested, the MPLS island doesn't support bidirectional LSPs, so that's a whole vibe check 😬

Note that tunneling and stitching are not available in unbalanced island models, because in those cases the LSP end points use different protocols.

  • Protocol mapping is converting signaling messages between MPLS and GMPLS 💛 It needs careful documentation of the protocol fields and how they're mapped. This is relatively straightforward in the MPLS-GMPLS unbalanced island model for LSPs signaled in the MPLS-to-GMPLS direction. For LSPs signaled the other way it can get way more complex, and that leads to big complications when you want to provide GMPLS services over the MPLS island and terminate them at an egress LSR that isn't GMPLS-capable 💀 Also, in balanced island models, especially where there are lots of small (individual node) islands, repeatedly converting signaling parameters can lose information (and functionality) or cause mis-requests.
  • Ships in the night could be used in the integrated migration model so MPLS-capable LSRs can set up LSPs with MPLS signaling protocols, while GMPLS LSRs set up LSPs with GMPLS signaling protocols 🌸 LSRs that can handle both sets of protocols can work with both types of LSRs, and no conversion of protocols is needed. no cap, that's the dream 🫶

5.1.4. Path Computation Element

the Path Computation Element (PCE) [RFC4655] may give you an extra tool to help with MPLS to GMPLS migration 🧠 If a layered network approach (Section 5.1.1) is used, PCEs may be used to help compute paths for LSPs in the different layers [PCE-INT].

6. Manageability Considerations ✨

attention should be given during migration planning to how the network will be managed during and after migration 📋 For example, will the LSRs with different protocol capabilities be managed separately, or as one management domain? Like, in the Island Model, you can totally consider managing islands of one capability separately from the surrounding sea 🌊 And when islands have different switching capabilities, they might already have separate management in place before the migration. The migrated network might then want to merge the management, or keep the separation 🎀

6.1. Control of Function and Policy

the most critical control functionality happens at the exact moment of changeover between different levels of protocol support ⏰ That change might happen without a service halt, or during a period of network maintenance.

Where island boundaries exist, it must be possible to manage the relationships between protocols, and to indicate which interfaces support which protocols on a border LSR 🚧 Island borders are also a natural place to apply policy, so management should allow policies to be configured there 💜

6.2. Information and Data Models

no special information or data models are required to support migration 🙌 But note that migration in the control plane implies moving from MPLS management tools to GMPLS management tools. So during migration, it may be necessary for LSRs and management applications to support both MPLS and GMPLS management data 🍓

The GMPLS MIB modules are designed to support the MPLS protocols, and they're built on the MPLS MIB modules through extensions and augmentations 🧁 This may make it possible to migrate management applications ahead of the LSRs they manage ✨

6.3. Liveness Detection and Monitoring

migration won't add any new issues for Operations, Administration, and Management (OAM) beyond the ones that already exist for inter-domain OAM and for OAM across multiple switching capabilities 👀

Note, however, that if a flat PSC MPLS network is migrated using the island model, and is treated as a layered network using tunnels to connect across GMPLS islands, then requirements for a multi-layer OAM technique may be introduced into what was previously defined in the flat OAM problem-space 🥺 The OAM framework for MPLS/GMPLS interworking will need further consideration.

6.4. Verifying Correct Operation

the concerns for verifying correct operation (and especially correct connectivity) are the same as for liveness detection and monitoring 🔍 Specifically, the migration process may introduce tunneling or stitching [RFC5150] into what used to be a flat network.

6.5. Requirements on Other Protocols and Functional Components

no particular requirements are introduced on other protocols 🙆 As noted earlier, the management components may need to migrate in step with the control plane components, but that doesn't impact the management protocols themselves, just the data they carry.

It's also worth knowing that providing signaling and routing connectivity across a migration island for a layered architecture may require protocol tunnels (such as Generic Routing Encapsulation (GRE)) between island border nodes 🎀 Those tunnels may add extra configuration requirements at the border nodes.

6.6. Impact on Network Operation

the migration process is likely to have a significant impact on network operation while it's in progress 😬 The main goal of migration planning should be to reduce that impact on network operation and on the services users perceive 💖

So planners should consider reducing the number of migration steps they perform, and minimizing the number of migration islands that get created 🧩

A network manager may prefer the island model, especially when migration will stretch over a significant operational period, because it lets the different network islands be administered as separate management domains 🌈 This is especially true for the overlay, augmented network and border peer models, where the details of the protocol islands stay hidden from the surrounding LSRs.

6.7. Other Considerations

a migration strategy may also mean moving an MPLS state to a GMPLS state for an in-service LSP 🦋 That can come up once all of the LSRs along the LSP's path have been updated to be both MPLS- and GMPLS-capable. Signaling mechanisms exist to swap an MPLS LSP for a GMPLS LSP without disrupting traffic, using make-before-break procedures [RFC3209] and [RFC3473]. These should be carefully managed under operator control 🔐

7. Security Considerations 🔐✨

okay so bestie, security is literally always getting poked at the admin boundaries 👀💅 some of the models in this doc create those boundaries, like between MPLS and GMPLS islands. and these boundaries let you apply or change the security kinda like when you cross an IGP area or Autonomous System (AS) boundary, even if the island boundaries are sitting inside an IGP area or AS 🫶

no changes are proposed to the security procedures already built into MPLS and GMPLS signaling and routing 🙅‍♀️ GMPLS signaling and routing just inherit their security mechanisms from MPLS signaling and routing, no changes at all. so there are no extra security issues in interworking scenarios, periodt 💖 and since MPLS and GMPLS signaling and routing security works hop-by-hop, and since every signaling and routing exchange this doc describes between any pair of LSRs is based on either MPLS or GMPLS, there are no changes needed to the security procedures 🦋

8. Acknowledgements 🌸

the authors are so grateful to Daisaku Shimazaki for chatting through the early work on this doc 🫶 they're also grateful to Dean Cheng and Adrian Farrel for their super valuable comments 👑

9. References 📚

9.1. Normative References 💜

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
  • [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
  • [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
  • [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
  • [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004.
  • [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, May 2007.
  • [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007.
  • [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, December 2007.

9.2. Informative References 🧚

  • [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
  • [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
  • [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, November 2006.
  • [RFC5150] Ayyangar, A., Kompella, A., Vasseur, JP., and A. Farrel, "Label Switched Path Stitching with Generalized Multiprotocol Label Switching Traffic Engineering", RFC 5150, February 2008.
  • [RFC5146] Kumaki, K., Ed., "Interworking Requirements to Support Operation of MPLS-TE over GMPLS Networks", RFC 5146, March 2008.
  • [MLN-REQ] Shiomoto, K., Papadimitriou, D., Le Roux, J.L., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)", Work in Progress, January 2008.
  • [PCE-INT] Oki, E., Le Roux, J-L., and A. Farrel, "Framework for PCE-Based Inter-Layer MPLS and GMPLS Traffic Engineering," Work in Progress, January 2008.

10. Contributors' Addresses 🎀

Dimitri Papadimitriou Alcatel Francis Wellensplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240 8491 EMail: dimitri.papadimitriou@alcatel-lucent.be

Jean-Louis Le Roux France Telecom av Pierre Marzin 22300 Lannion, France Phone: +33 2 96 05 30 20 EMail: jeanlouis.leroux@orange-ftgroup.com

Deborah Brungard AT&T Rm. D1-3C22 - 200 S. Laurel Ave. Middletown, NJ 07748, USA Phone: +1 732 420 1573 EMail: dbrungard@att.com

Zafar Ali Cisco Systems, Inc. EMail: zali@cisco.com

Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo 102-8460, JAPAN Phone: +81-3-6678-3103 EMail: ke-kumaki@kddi.com

Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 3441 EMail: oki.eiji@lab.ntt.co.jp

Ichiro Inoue NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 3441 EMail: inoue.ichiro@lab.ntt.co.jp

Tomohiro Otani KDDI Laboratories EMail: otani@kddilabs.jp

Editor's Address 💅

Kohei Shiomoto NTT Midori 3-9-11 Musashino, Tokyo 180-8585, Japan Phone: +81 422 59 4402 EMail: shiomoto.kohei@lab.ntt.co.jp

Copyright (C) The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌈

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

📦 where this page comes from