RFC 8099
OSPF Topology-Transparent Zone
RFC 8099: OSPF Topology-Transparent Zone ✨
okay bestie, this one is giving a whole glow-up for OSPF 💅🦋 It's an Experimental doc, so it's a "try it, test it, tell us how it goes" kind of spec, not a finished standard 🧪 Published in February 2017 by the IETF, and it comes from a squad of authors: H. Chen and R. Li (Huawei Technologies), A. Retana (Cisco Systems, Inc.), Y. Yang (Sockrate), and Z. Liu (China Mobile) 🫶 It's listed as ISSN 2070-1721, and it does not obsolete or update any other RFCs 🌸
The whole vibe is hiding the messy inside of a network from everyone outside it 🙈 A Topology-Transparent Zone (TTZ) is a group of routers and their links inside one OSPF area, and routers outside the zone don't even know it exists 👑
Status of This Memo 💜
This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🧪
It does define an Experimental Protocol for the Internet community, and it's an IETF product with IETF consensus 🎀 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the full tea ☕
Info about the current status, errata, and feedback is at http://www.rfc-editor.org/info/rfc8099 🔗
Copyright Notice 🌈
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 stood on the publication date. Read those carefully, bestie, because they spell out your rights and restrictions 📜 Any Code Components pulled out of this doc must include Simplified BSD License text (Section 4.e of the Trust Legal Provisions) and come with no warranty, as the Simplified BSD License describes 💅
Table of Contents 📖
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Conventions Used in This Document . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Topology-Transparent Zone . . . . . . . . . . . . . . . . . . 5
5.1. Overview of Topology-Transparent Zone . . . . . . . . . . 5
5.2. TTZ Example . . . . . . . . . . . . . . . . . . . . . . . 6
6. Extensions to OSPF Protocols . . . . . . . . . . . . . . . . 8
6.1. General Format of TTZ LSA . . . . . . . . . . . . . . . . 8
6.2. TTZ ID TLV . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. TTZ Router TLV . . . . . . . . . . . . . . . . . . . . . 9
6.4. TTZ Options TLV . . . . . . . . . . . . . . . . . . . . . 10
6.5. Link Scope TTZ LSA . . . . . . . . . . . . . . . . . . . 12
7. Constructing LSAs for TTZ . . . . . . . . . . . . . . . . . . 12
7.1. TTZ Migration Process . . . . . . . . . . . . . . . . . . 13
8. Establishing Adjacencies . . . . . . . . . . . . . . . . . . 14
8.1. Discovery of TTZ Neighbors . . . . . . . . . . . . . . . 14
8.2. Adjacency between TTZ Edge and TTZ-External Router . . . 17
9. Advertisement of LSAs . . . . . . . . . . . . . . . . . . . . 17
9.1. Advertisement of LSAs within TTZ . . . . . . . . . . . . 17
9.2. Advertisement of LSAs through TTZ . . . . . . . . . . . . 18
10. Computation of Routing Table . . . . . . . . . . . . . . . . 18
11. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Configuring TTZ . . . . . . . . . . . . . . . . . . . . 18
11.2. Migration to TTZ . . . . . . . . . . . . . . . . . . . . 19
11.3. Adding a Router into TTZ . . . . . . . . . . . . . . . . 21
12. Manageability Considerations . . . . . . . . . . . . . . . . 22
13. Security Considerations . . . . . . . . . . . . . . . . . . . 22
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
15.1. Normative References . . . . . . . . . . . . . . . . . . 23
15.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Prototype Implementation . . . . . . . . . . . . . . 24
A.1. What Is Implemented and Tested . . . . . . . . . . . . . 24
A.2. Implementation Experience . . . . . . . . . . . . . . . . 25
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 271. Introduction 🌸
Networks grow as the business grows and traffic piles up 📈 For scalability and manageability, OSPF networks usually get a hierarchical design by regrouping routers into areas. That regrouping is often hard and can cause service interruptions 😭
Let's be real, reorganizing one area into several (or several into even more) is a very challenging and time-consuming job, because it means big architecture changes 💀 Take the single-area case: the network starts with one area, the backbone. That backbone gets reorganized into a new backbone plus a bunch of non-backbone areas. Each non-backbone area connects to the new backbone through the Area Border Routers (ABRs) between it and the backbone (see RFC 2328, Section 3) 🦋 You have to plan the topology carefully ahead of time to keep backbone continuity and non-backbone reachability intact, and you usually have to change the configs on lots of routers so routing stays consistent 🫠
Second issue: the services on the network can get interrupted during that reorg, because every OSPF interface whose area changes goes down with its old area and comes back up in the new one 🙀
So this doc presents a TTZ inside an OSPF area and describes OSPFv2 extensions to support it. It's scalable and fixes the problems above ✨ A TTZ hides its internal topology from the outside world and doesn't directly advertise any internal TTZ information to any router outside of it 👑
2. Terminology 📚
TTZ link or TTZ-internal link: A link whose ends are both within a single TTZ. 🔗
TTZ-internal router: A router whose links are TTZ-internal links inside a single TTZ. 🧚
TTZ-external router: A router outside of a TTZ that has no TTZ-internal links. 🌍
TTZ-external link: A link not configured to be within a TTZ. 🛤️
TTZ edge router: A router is called a TTZ edge router if some, but not all, of its links are within a single TTZ. 🌉
TTZ router: A TTZ-internal router or a TTZ edge router. 💖
3. Conventions Used in This Document 🎀
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 [RFC2119]. 📖✨
4. Requirements 📋
A TTZ may be deployed to resolve some critical issues in existing networks and future networks. The requirements for a TTZ are listed below 💅
- Routers outside a TTZ MUST NOT require any changes to operate with the TTZ.
- A TTZ MUST be enclosed in a single area.
- A TTZ MUST hide the topology of the TTZ from any router outside of the TTZ.
5. Topology-Transparent Zone 🦋
5.1. Overview of Topology-Transparent Zone 🌈
A TTZ is identified by a TTZ identifier (ID). It's made of a group of routers and a number of links connecting those routers 🫶 A TTZ MUST be contained within an OSPF area.
A TTZ ID is a 32-bit number that uniquely identifies a TTZ 🔢 The TTZ ID SHOULD NOT be 0, so it doesn't get confused with Area 0 🙈 The same TTZ ID MUST be configured on the routers and/or links that make up a specific TTZ instance. All TTZ instances in an OSPF area MUST be unique.
Besides doing what an OSPF area does, an OSPF TTZ makes some upgrades, including:
- An OSPF TTZ represents a set of TTZ edge routers, connected by a full mesh of virtual connections between them. 🕸️
- Non-TTZ link-state information is handled as normal. TTZ routers receive the link-state information about the topology outside of the TTZ, store it, and flood it through the TTZ to the routers outside of the TTZ. 🌊
Part 1 of 6 is done, bestie 💖 Ready for part 2 whenever you are, let's keep the glow going 🦋✨
5.2. TTZ Example ✨
okay so let's look at a real TTZ 🦋 Here's area X with a TTZ called TTZ 600 sitting in the middle of it, and honestly the layout is giving main character energy:
TTZ 600 ---- TTZ-Internal Link
\ ==== Normal Link
Area X \ ^~^~^~^~^~^~^~^~^~^~^~^~
( )
===[R15]========(==[T61]----[T81]---[T63]==)======[R29]===
|| ( | \ / | ) ||
|| ( | \ / | ) ||
|| ( [T75] \ / | ) ||
|| ( | ___\ / | ) ||
|| ( | / [T71] [T79] ) ||
|| ( | [T73] / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
|| ( | / \ | ) ||
===[R17]========(==[T65]---[T77]----[T67]==)======[R31]===
\\ (// \\) //
|| //v~v~v~v~v~v~v~v~v~v~v~\\ ||
|| // \\ ||
|| // \\ ||
\\ // \\ //
======[R23]==============================[R25]=====
// \\
// \\so every router in that picture lives in area X 🏠 The ones starting with T (that's T61, T63, T65, T67, T71, T73, T75, T77, T79, and T81) are also inside TTZ 600 💖 The TTZ-internal links that connect them come along for the ride too. To make a TTZ in the first place, you have to configure it (refer to Section 11) 💅
there are two kinds of routers in a TTZ: TTZ-internal routers and TTZ edge routers 🌸 TTZ 600 has four TTZ edge routers, which are T61, T63, T65, and T67. Each one has at least one neighbour inside TTZ 600 AND at least one neighbour outside it 🫶 Like, T61 is a TTZ edge router because R15 is outside TTZ 600, and it also has T71, T75, and T81 hanging out inside TTZ 600 🎀
then TTZ 600 also has six TTZ-internal routers: T71, T73, T75, T77, T79, and T81 🧚 Every single one of them has ALL of its neighbours inside TTZ 600. T71 is the perfect example, since its neighbours T61, T63, T65, T67, and T73 are all in there ✨ And here's the rule: by definition, a TTZ-internal router can never also be an ABR 🙅♀️
the big idea of a TTZ is that it hides its own insides from everyone else 🦋 It doesn't directly advertise any internal info about itself to routers outside the TTZ. Nobody outside gets to see the internal stuff, period 🔒
so, for example, TTZ 600 doesn't tell any outside router about T71 🙈 It also doesn't tell them about the link between T61 and T71. Total mystery vibes, iconic 👑
this next picture is area X from the point of view of a router OUTSIDE TTZ 600, once the TTZ exists 👀
Area X ==== Normal Link
===[R15]===========[T61]=========[T63]=========[R29]===
|| || \\ // || ||
|| || \\ // || ||
|| || \\ // || ||
|| || \\// || ||
|| || //\ || ||
|| || // \\ || ||
|| || // \\ || ||
|| || // \\ || ||
|| || // \\ || ||
===[R17]===========[T65]=========[T67]=========[R31]===
\\ // \\ //
|| // \\ ||
|| // \\ ||
|| // \\ ||
\\ // \\ //
======[R23]============================[R25]=====
// \\
// \\from outside, a TTZ looks like nothing more than its TTZ edge routers all connected to each other 🌈 So R15 just sees T61, T63, T65, and T67 linked together, and that's the whole story 💅
and it gets even better! A router outside the TTZ also sees each TTZ edge router with its normal connections to the outside routers 🍓 For instance, R15 sees that T61, T63, T65, and T67 have normal connections to R15; R29; R17 and R23; and R25 and R31, respectively. Bestie, that is SO organised 😭🔥
6. Extensions to OSPF Protocols 🌟
okay so the link-state info about a TTZ includes router Link-State Advertisements (LSAs) 💜 Those can be packed into and advertised as opaque LSAs [RFC5250] inside the TTZ. Some control info about a TTZ can also go into opaque LSAs inside the TTZ 🎀 We call these TTZ opaque LSAs, or TTZ LSAs for short ✨
6.1. General Format of TTZ LSA 🦋
here's the general format of a TTZ LSA 💖 It has a Link-State (LS) Type = 10/9 and a TTZ LSA Type, and it holds a bunch of TLVs inside it 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type = 10/9|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TTZ LSA Type(9)| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+there are THREE TTZ LSAs with LS Type 10 🌸
- TTZ router LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Router TLV.
- TTZ control LSA: a TTZ LSA containing a TTZ ID TLV and a TTZ Options TLV.
- TTZ indication LSA: a TTZ LSA containing a TTZ ID TLV with E = 0, which tells you the router that originated it is a TTZ-internal router 🫶
and there is ONE TTZ LSA with LS Type 9 🍓
- TTZ discovery LSA: a TTZ LSA containing a TTZ ID TLV and an optional TTZ Options TLV.
6.2. TTZ ID TLV 🎀
the TTZ ID TLV has the format below 💅 It carries a TTZ ID (refer to Section 5.1) and some flags. Its TLV-Length is 8 octets ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ ID TLV Type (1) | TLV-Length (8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) |E|Z|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E = 1: Indicating a router is a TTZ edge router
Z = 1: Indicating a router has migrated to TTZokay, this part is serious 🙏 When a TTZ router originates a TTZ LSA that contains a TTZ ID TLV, it MUST set flag E to 1 in that TTZ ID TLV if it's a TTZ edge router, and to 0 if it's a TTZ-internal router. It also MUST set flag Z to 1 after it has migrated to TTZ, and to 0 before it migrates to TTZ or after it rolls back from TTZ (refer to Section 6.4) 🔥
6.3. TTZ Router TLV 👑
the TTZ Router TLV is formatted like this 🦋 It has the same content as a standard OSPF router LSA (RFC 2328), with a few modifications 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ RT TLV Type (2) | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ... ~
Note: TOS = Type of Servicefor a router link, the existing 8-bit Link Type field gets split into two fields 🧁
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| I | Type-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I bit flag:
1: Router link is a TTZ-internal link.
0: Router link is a TTZ-external link.
Type-1: The kind of the link. The values for Type-1 are the same
as those for Type defined in RFC 2328, Section 12.4.1.the Link Type field is 8 bits, and values 128-255 of that field are reserved (refer to [RFC4940]) 💜 That leaves the bottom 7 bits free to tell you the type of a TTZ-internal or external link. Clever, right? 🧚✨
6.4. TTZ Options TLV 🎀
okay so this is the TTZ Options TLV, and it's giving control panel 🎛️ 💅. Here's how it's laid out:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TTZ OP TLV Type (3) | TLV-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OP | Reserved (MUST be zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And these are the four OP values you can get:
OP Value Meaning (Operation)
0x001 (T): Advertising TTZ Topology Information for Migration
0x010 (M): Migrating to TTZ
0x011 (N): Advertising Normal Topology Information for Rollback
0x100 (R): Rolling Back from TTZSo the OP field is 3 bits, and it's the thing that tells you which operation is happening 🔥. It can be 0x001 for T, 0x010 for M, 0x011 for N, or 0x100 for R, and each one maps to one of the four operations above. If you receive any of the other values, you just ignore it 💀. No drama.
Advertising TTZ Topology Information for Migration (T): Once a user configures a TTZ router to advertise TTZ topology info, this one kicks off 🦋. The TTZ router originates a TTZ control LSA with a TTZ Options TLV whose OP is T. It also originates its other TTZ LSAs, like a TTZ router LSA or a TTZ indication LSA. When another TTZ router gets the LSA with OP set to T, it originates its own TTZ LSA the way Section 7 describes 🫶.
Migrating to TTZ (M): Once a user configures a TTZ router to migrate to TTZ, the migration is triggered ✨. The TTZ router originates a TTZ control LSA with a TTZ Options TLV whose OP is M, and then it migrates to TTZ itself. When another TTZ router gets the LSA with OP set to M, it migrates to TTZ too. When a router migrates, it computes routes using both the TTZ topology and the topology outside of the TTZ 🗺️. A TTZ-internal router also updates its TTZ indication LSA with Z = 1. A TTZ edge router updates its TTZ router LSA with Z = 1, and it updates its router LSA to virtualize the TTZ. Whether a router counts as internal or edge comes down to its configurations, so check out Section 11.1 for that 🙈.
Advertising Normal Topology Information for Rollback (N): Once a user configures a TTZ router to advertise normal topology info, this one is triggered 🌸. The TTZ router originates a TTZ control LSA with a TTZ Options TLV whose OP is N. It also advertises its normal LSAs, like its normal router LSA, and it stops advertising its other TTZ LSAs. When another TTZ router gets the LSA with OP set to N, it forwards the LSA, advertises its normal LSAs, and stops advertising its TTZ LSAs too 🧚.
Rolling back from TTZ (R): Once a user configures a TTZ router to roll back from TTZ, the rollback starts 🍓. The TTZ router originates a TTZ control LSA with a TTZ Options TLV whose OP is R, and then it rolls back from TTZ. When another TTZ router gets the LSA with OP set to R, it rolls back from TTZ as well 💜.
After a TTZ router originates a TTZ control LSA because of one of the configurations above, it flushes that TTZ control LSA if the OP in the LSA is set for that configuration and the configuration gets removed. Clean-up on the way out, periodt 🧹✨.
6.5. Link Scope TTZ LSA 🌈
A TTZ LSA with LS Type 9 looks like this 👑:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type = 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|TTZ LSA Type(9)| Instance ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ TTZ ID TLV ~
+---------------------------------------------------------------+
| |
~ (TTZ Options TLV) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+So this LSA always has a TTZ ID TLV, and it may also have an optional TTZ Options TLV tagging along 🎀. Its whole job is to help you discover a TTZ neighbor 🔍💖.
7. Constructing LSAs for TTZ ✨
okay this is where it all gets built 🏗️. For a TTZ, the topology is represented by the LSAs its TTZ routers generate for the link states inside the TTZ. That's a mix of TTZ router LSAs from TTZ edge routers, TTZ indication LSAs from TTZ-internal routers, normal router LSAs, and network LSAs 🧩. The TTZ router LSAs and TTZ indication LSAs MUST be generated after advertising TTZ topology information for migration is triggered. No skipping ahead, bestie 🙅♀️.
A TTZ edge router generates a TTZ router LSA that has a TTZ ID TLV and a TTZ Router TLV 💅. The TTZ ID TLV has the ID of the TTZ the router belongs to, and flag E is set to 1, which tells everyone the LSA came from a TTZ edge router. The TTZ Router TLV holds the TTZ-external links to routers outside the TTZ and the TTZ-internal links to routers inside it, as described in Section 6. This TTZ router LSA is constructed and advertised inside the TTZ 🦋.
A TTZ-internal router generates a TTZ indication LSA that has a TTZ ID TLV with the ID of the TTZ it belongs to. Flag E is set to 0, which means the LSA came from a TTZ-internal router 🌸. A TTZ-internal router still generates its regular router LSA too. And if a TTZ router is a Designated Router (DR), it originates its regular network LSA as well 🧚.
After a TTZ edge router gets a trigger to migrate to TTZ, like a TTZ control LSA with OP set to M, it MUST originate its normal router LSA to virtualize the TTZ 🫧. In general, that LSA has three groups of links.
The first group is the router links to the TTZ-external routers. These are normal router links, and there is one router link for every adjacency between this TTZ edge router and a TTZ-external router 🔗.
The second group is the "virtual" router links to the other TTZ edge routers. For each of the other TTZ edge routers, there's a point-to-point (P2P) router link pointing to it from this TTZ edge router. The cost of that link is the cost of the shortest path from this TTZ edge router to the other one, inside the TTZ 🛣️.
The LSA may also have a third group, which is the stub links for the loopback addresses inside the TTZ that nodes outside of the TTZ need to reach 🏝️.
7.1. TTZ Migration Process 🚀
Once migration to TTZ is triggered, a TTZ router computes routes using its TTZ topology (see Section 10). A TTZ edge router then originates its normal router LSA to virtualize the TTZ in two steps 🪜:
- Step 1: The router updates its router LSA by adding a P2P link to each of the other known edge routers in the TTZ. It also adds stub links for the loopback addresses in the TTZ that should be accessible from outside the TTZ, following the operator's configuration policies 🎯.
- Step 2: After MaxLSAGenAdvTime (0.3 s) or sr-time + MaxLSAAdvTime (0.1 s), it removes the TTZ links from its router LSA. Here, sr-time is the time from updating its router LSA until it gets the ack for that LSA and receives the updated router LSAs from the other TTZ edge routers. Put simply, it removes the TTZ links after it has sent its updated router LSA and received the updated router LSAs from the other TTZ edge routers for MaxLSAAdvTime, or after it has sent its updated router LSA for MaxLSAGenAdvTime ⏳. MaxLSAAdvTime and MaxLSAGenAdvTime SHOULD be set to 100 ms and 300 ms, respectively, but they MAY be configurable 🎛️. MaxLSAAdvTime is the maximum time for an LSA to reach all the routers in an area. MaxLSAGenAdvTime is the maximum time for all TTZ router LSAs to be generated by all TTZ edge routers and advertised to all the routers in an area, counted from when the first TTZ router LSA is generated 🌍.
⚠️ Why the two steps? This is to avoid a possible route down or change in a TTZ-external router while the TTZ is being virtualized. If each TTZ edge router added its P2P links to the other TTZ edge routers and removed its TTZ links in one step, a route going through the TTZ at a TTZ-external router could go down or change before all the router LSAs from the TTZ edge routers reached it 😭. When that TTZ-external router computes routes with some of those router LSAs, bidirectional checks for some of the P2P links would fail. So the route taking the shortest path for the P2P link that fails the bidirectional check would go down or change 💀.
To roll back from a TTZ smoothly after a TTZ edge router gets a trigger to roll back from TTZ, it MUST originate its normal router LSA in the same two steps but in reverse 🔄. In Step 1, it first updates its normal router LSA by adding the normal links for the links configured as TTZ links into the LSA 🧵. In Step 2, it removes the P2P links to the other edge routers of the TTZ, which were used for virtualizing the TTZ, along with the stub links for the loopback addresses, from its updated router LSA. This happens after it has sent its updated router LSA and received the updated router LSAs from the other TTZ edge routers for MaxLSAAdvTime, or after it has sent its updated router LSA for MaxLSAGenAdvTime 🌷.
8. Establishing Adjacencies 🤝
okay bestie, this section is all about the TTZ adjacencies, so that's where we're headed next 💖.
8.1. Discovery of TTZ Neighbors
okay so, when routers A and B are connected by a P2P link and already have a normal adjacency, they TTZ discover each other through a TTZ LSA of LS Type 9 with a TTZ ID TLV. we call this one D-LSA for short 💅✨
If two ends of the link have different TTZ IDs or only one end is configured with a TTZ ID, TTZ adjacency over the link MUST NOT be "formed". 🙅♀️ no vibes, no adjacency.
If two ends of the link have the same TTZ ID and Z flag value, A and B are TTZ neighbors 🫶 here's the sequence of events for this case:
A B
Configure TTZ Configure TTZ
D-LSA (TTZ ID=100)
----------------------> Same TTZ ID and Z
A is B's TTZ Neighbor
D-LSA (TTZ ID=100)
Same TTZ ID and Z <----------------------
B is A's TTZ NeighborA sends B a D-LSA with TTZ ID after the TTZ is configured on it. B sends A a D-LSA with TTZ ID after the TTZ is configured on it. 💌
When A receives the D-LSA from B and determines they have the same TTZ ID and Z flag value, B is A's TTZ neighbor. A also sends B all the TTZ LSAs it has, and originates its TTZ LSA when one of the following conditions is met. 🦋
- Z = 0 and there is a TTZ LSA with OP for T.
- Z = 1.
B is symmetric to A and acts similarly to A. bestie, it's a mirror situation 🪞
If two ends of the link have the same TTZ ID but the Z flags are different, a TTZ adjacency over the link MUST be "formed" in the following steps. 🎀 Suppose that A has migrated to TTZ and B has not (i.e., flag Z in A's D-LSA is 1, and flag Z in B's D-LSA is 0).
A B
Configure TTZ Configure TTZ
D-LSA(TTZ ID=100,Z=1)
----------------------> Same TTZ ID, but
different Z
A is B's TTZ Neighbor
D-LSA(TTZ ID=100,Z=0)
Same TTZ ID, but <----------------------
different Z
B is A's TTZ Neighbor
TTZ LSAs
----------------------->
TTZ LSAs
<-----------------------When A receives the D-LSA from B and determines they have the same TTZ ID but its Z = 1 and B's Z = 0, A sends B all the TTZ LSAs it has and triggers B to migrate to TTZ. 🚀 A then updates and sends B its D-LSA by adding a TTZ Options TLV with OP for M, after sending B all the TTZ LSAs.
D-LSA(TTZ ID=100,OP=M)
Add TTZ Options -----------------------> Migrate to TTZ
TLV with OP for M
D-LSA(TTZ ID=100,Z=1) Migrated to TTZ
<----------------------- Set Z=1
D-LSA(TTZ ID=100,Z=1)
Remove ----------------------->
TTZ Options TLVWhen B receives the D-LSA from A and determines they have the same TTZ ID but its Z = 0 and A's Z = 1, B sends A all the TTZ LSAs it has. 📬
When B receives the D-LSA from A with OP for M, it starts to migrate to TTZ. B then updates and advertises its LSAs as needed. 🌸
After receiving B's D-LSA with Z = 1, A updates and sends B its D-LSA by removing the TTZ Options TLV. It also updates and advertises its LSAs as needed. ✅
When a number of routers connected through a broadcast link have normal adjacencies among them, they also TTZ discover each other through D-LSAs. 🌈 The Designated Router (DR) for the link MUST "form" TTZ adjacencies with the other routers if all the routers attached to the link have the same TTZ ID configured on the connections to the link. Otherwise, the DR MUST NOT "form" any TTZ adjacency with any router attached to the link. 🙈
When a number of routers connected through a broadcast link have TTZ adjacencies among them, and a misconfigured router is introduced on the broadcast link, the DR for the link MUST NOT "form" any TTZ adjacency with this misconfigured router. 🚫 bestie, the DR is the bouncer here 💅
For routers connected via a link without any adjacency among them, they TTZ discover each other through D-LSAs in the same way as described above, after they form a normal adjacency. 💜
A TTZ adjacency over a link MUST be removed when one of the following events happens. 💀
- TTZ ID on one end of the link is changed to a different one.
- TTZ ID on one end of the link is removed.
- The D-LSA is not received after the D-LSA-MAX-RETRANSMIT-TIME or is explicitly flushed. The D-LSA-MAX-RETRANSMIT-TIME SHOULD be set to 60 minutes, but MAY be configurable. ⏰
- Normal adjacency over the link is down.
When the TTZ ID on one end of the link is removed, the corresponding D-LSA is flushed. 🧹
8.2. Adjacency between TTZ Edge and TTZ-External Router
A TTZ edge router forms an adjacency with any TTZ-external router to which it is connected. 🧚
When the TTZ edge router synchronizes its link-state database with the TTZ-external router, it sends the TTZ-external router the information about all the LSAs except for the LSAs belonging to the TTZ that are hidden from any router outside of the TTZ. 🙊 some secrets stay inside the group chat, iykyk
At the end of the link-state database synchronization, the TTZ edge router originates its own router LSA for virtualizing the TTZ and sends this LSA to its adjacent routers, including the TTZ-external router. 🎉
9. Advertisement of LSAs
LSAs can be divided into a couple of classes according to their Advertisements. 🍓 The first class of LSAs is advertised within a TTZ. The second is advertised through a TTZ.
9.1. Advertisement of LSAs within TTZ
Any LSA about a link state in a TTZ is advertised only within the TTZ. It is not advertised to any router outside of the TTZ. For example, a router LSA generated for a TTZ-internal router is advertised only within the TTZ. 🔒 main character, inside the walls only
Any network LSA generated for a broadcast or Non-Broadcast Multi-Access (NBMA) network in a TTZ is advertised only within the TTZ. It is not advertised outside of the TTZ. 🫧
Any opaque LSA generated for a TTZ-internal TE link is advertised only within the TTZ. ⭐
After migrating to TTZ, every edge router of a TTZ MUST NOT advertise any LSA about a link state in the TTZ to any router outside of the TTZ. The TTZ edge router determines whether an LSA is about a TTZ-internal link state by checking if the advertising router of the LSA is a TTZ-internal router (i.e., there is a TTZ indication LSA generated by the TTZ-internal router that has the same advertising router). 🕵️♀️
For any TTZ LSA originated by a router within the TTZ, every edge router of the TTZ MUST NOT advertise it to any router outside of the TTZ. 🙅♀️ not sharing that with outsiders
9.2. Advertisement of LSAs through TTZ
Any LSA about a link state outside of a TTZ received by an edge router of the TTZ is advertised using the TTZ as transit. 🚌 For example, when an edge router of a TTZ receives an LSA from a router outside of the TTZ, it floods it to its neighboring routers both inside and outside of the TTZ. This LSA may be any LSA, such as a router LSA that is advertised within an OSPF area. 🦋
The routers in the TTZ continue to flood the LSA. When another edge router of the TTZ receives the LSA, it floods the LSA to its neighboring routers both inside and outside of the TTZ. 🌊
10. Computation of Routing Table
After a router migrates to TTZ, the computation of the routing table on the router is the same as that described in RFC 2328, Section 16 with one exception. 🧮 The router in a TTZ ignores the router LSAs generated by the TTZ edge routers for virtualizing the TTZ. It computes routes using the TTZ router LSAs and the regular LSAs, excluding the router LSAs for virtualizing the TTZ. That is, it computes routes using the TTZ topology and the topology outside of the TTZ, excluding the links for virtualizing the TTZ. 💖 one plot twist and that's it
11. Operations
11.1. Configuring TTZ
This section proposes some options for configuring a TTZ. 📋
1. Configuring TTZ on Every Link in TTZ
If every link in a TTZ is configured with the same TTZ ID as a TTZ link, the TTZ is determined. A router with some links in a TTZ and some links not in this TTZ is a TTZ edge router. A router with all its links in a TTZ is a TTZ-internal router. 🎀
2. Configuring TTZ on Routers in TTZ
A same TTZ ID is configured on every TTZ-internal router in a TTZ and on every TTZ edge router's links connecting to the routers in the TTZ. 🫶
A router configured with the TTZ ID on some of its links is a TTZ edge router. A router configured with the TTZ ID only is a TTZ-internal router. All the links on a TTZ-internal router are TTZ links. This option is simpler than option 1 above. 😌✨
For a TTZ edge router X with different TTZ IDs on its different links, router X connects two or more different TTZs. In this case, router X originates its router LSA for virtualizing the TTZs. This LSA includes the normal links connecting to routers outside of these TTZs and the virtual links to the other edge routers of each of these TTZs. Router X also originates its TTZ router LSA for each of the TTZs. The TTZ router LSA for TTZ N includes the links to the routers outside of these TTZs, the virtual links to the other edge routers of the other TTZs, and the TTZ links to the routers in TTZ N. 🧠🌈
11.2. Migration to TTZ ✨
okay so, for a group of routers and a bunch of links connecting them in an area, moving over to work as a TTZ without any service interruption takes a few steps or stages 🧚
Stage one: a user configures the TTZ feature on every router in the TTZ. During this stage a router does not originate or advertise its TTZ topology information 🙈 It will discover its TTZ neighbors.
Stage two: after configuring TTZ, a user issues a configuration on one router in the TTZ. That triggers every router in the TTZ to generate and advertise TTZ information among the routers in the TTZ 🔥 When the router gets the configuration, it originates a TTZ control LSA with OP for T (meaning TTZ information generation and advertisement for migration). It also originates its own TTZ LSA, such as a TTZ router LSA or a TTZ indication LSA, and advertises that LSA to its TTZ neighbors. When another router in the TTZ receives the LSA with OP for T, it originates its own TTZ LSA. In this stage, every router in the TTZ has dual roles 👯♀️ One role is to function as a normal router. The other is to generate and advertise TTZ information.
Stage three: a user checks whether a router in the TTZ is ready for migration to TTZ. A router is ready after it has received all the TTZ LSAs, including TTZ router LSAs from TTZ edge routers and TTZ indication LSAs from TTZ-internal routers. This information may be displayed on a router through a configuration 👀
Then a user activates TTZ by using a configuration such as migrate to TTZ on one router in the TTZ. That router migrates to TTZ and, after it receives the configuration, generates and advertises a TTZ control LSA with OP for M (meaning Migrating to TTZ). After another router in the TTZ receives the TTZ control LSA with OP for M, it also migrates to TTZ. So activating TTZ on one TTZ router propagates to every router in the TTZ, and they all migrate 💖
For an edge router of the TTZ, migrating to work as a TTZ router means generating a router LSA to virtualize the TTZ and flooding this LSA to all of its neighboring routers. That happens in two steps, as described in Section 7 ✨
In normal operations for migration to TTZ and rollback from TTZ, a user issues a series of configurations following certain procedures. In an abnormal case, for example, two conflicting configurations are issued on two TTZ routers in a TTZ at the same time. When a TTZ router detects a conflict, it issues an error and logs the error 🚨
A conflicting configuration may be detected on the router where the configuration is issued, so some abnormal cases may be prevented 🛡️ When a configuration for migration or rollback is issued on a router, the router checks whether it is in a correct sequence of configurations for migration or rollback, using the information it has. For migrating a part of an area to a TTZ, the correct sequence of configurations is in general as follows:
- configure TTZ on every router in the part of the area to be migrated to TTZ;
- configure on one router in the TTZ to trigger every router in the TTZ to generate and advertise TTZ information for migration; and
- configure on one router in the TTZ to trigger every router in the TTZ to migrate to TTZ.
After a router receives a configuration to migrate to TTZ, which is for step 3), it determines whether step 2) has been performed by checking if it has received or originated TTZ LSAs. If it has not, it issues an error to an operator (generation and advertisement of TTZ information for migration to TTZ is not done yet) and rejects the configuration at this time 🙅♀️
After a router receives a TTZ LSA with OP for M for step 3) from another router, it determines whether step 2) has been performed by checking if it has received or originated TTZ LSAs. If it has not, it issues an error and logs the error, and it does not migrate to TTZ. In this case, if it is a TTZ edge router, it does not originate its router LSA for virtualizing the TTZ 😭
After a router receives a configuration to generate and advertise TTZ information, which is for step 2), it determines whether step 1) has been performed by checking if TTZ is configured on it. If TTZ is not configured on it, it issues an error to an operator (TTZ is not configured on it yet) and rejects the configuration at this time 🌸
For rolling back from TTZ, the correct sequence of configurations is below.
- configure on one router in the TTZ to trigger every router in the TTZ to advertise normal LSAs and stop advertising TTZ LSAs; and
- configure on one router in the TTZ to trigger every router in the TTZ to roll back from TTZ.
After a router receives a configuration to roll back from TTZ, which is for step 2), it determines whether step 1) has been performed by checking if it has received a TTZ LSA with OP for N. If it has not, it issues an error to an operator (advertise normal LSAs and stop advertising TTZ LSAs as rolling back from TTZ is not done yet) and rejects the configuration at this time 🧸
After a router receives a TTZ LSA with OP for R for step 2) from another router, it determines whether step 1) has been performed by checking if it has received a TTZ LSA with OP for N. If it has not, it issues an error and logs the error, and it does not roll back from TTZ.
After a router receives a configuration to advertise normal LSAs and stop advertising TTZ LSAs for rolling back from TTZ, which is for step 1), it checks whether it has any TTZ LSAs. If it does not, it issues an error to an operator (no TTZ to be rolled back) and rejects the configuration at this time 🫶
11.3. Adding a Router into TTZ 🎀
When a non-TTZ router (let's call it R1) is connected via a P2P link to a migrated TTZ router (let's say T1), and there is a normal adjacency between them over that link, a user can configure TTZ on both ends of the link to add R1 into the TTZ that T1 belongs to. They TTZ discover each other as described in Section 8 🦋
When a number of non-TTZ routers are connected via a broadcast or NBMA link to a migrated TTZ router (say T1), and there are normal adjacencies among them, a user configures TTZ on the connection to the link on every router to add the non-TTZ routers into the TTZ that T1 belongs to. The DR for the link "forms" TTZ adjacencies with the other routers connected to the link if they all have the same TTZ ID configured for the link. This is determined through the TTZ discovery process described in Section 8 🌈
12. Manageability Considerations 🧚
Section 11 ("Operations") outlines the configuration process and deployment scenarios for a TTZ. The configurable item is enabling a TTZ on a router and/or an interface on a router. The TTZ function may be controlled by a policy module and assigned a suitable user privilege level to enable. A suitable model may be required to verify the TTZ status on routers participating in the TTZ, including their role as an internal or edge TTZ router. The mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those indicated in [RFC2328] 📋
13. Security Considerations 🔐
A notable beneficial security aspect of TTZ is that the TTZ is enclosed in a single area, and TTZ could be used to mask the internal topology. External routers that are not participating in the TTZ will not be aware of the internal TTZ topology.
Okay but here's the scary part 💀 It should be noted that a malicious node could inject TTZ LSAs with the OP field set to M or R. That could trigger migration into or out of a TTZ and may result in the isolation of some routers in the network 😱 Good security practice might reuse the OSPF authentication and other security mechanisms described in [RFC2328] and [RFC7474] to mitigate this type of risk. Please take this seriously, bestie 🫶
14. IANA Considerations 🌷
Under the registry name "Opaque Link-State Advertisements (LSA) Option Types" [RFC5250], IANA has assigned a new Opaque Type registry value for TTZ LSA, as follows:
+====================+===============+=======================+
| Registry Value | Opaque Type | reference |
+====================+===============+=======================+
| 9 | TTZ LSA | This document |
+--------------------+---------------+-----------------------+IANA has created and will maintain a new registry 🍓
- OSPFv2 TTZ LSA TLVs
Initial values for the registry are given below. The future assignments are to be made through IETF Review [RFC5226].
Value OSPFv2 TTZ LSA TLV Name Definition
----- ----------------------- ----------
0 Reserved
1 TTZ ID TLV see Section 6.2
2 TTZ Router TLV see Section 6.3
3 TTZ Options TLV see Section 6.4
4-32767 Unassigned
32768-65535 Reserved15. References 📚
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, http://www.rfc-editor.org/info/rfc2119.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, http://www.rfc-editor.org/info/rfc2328.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, http://www.rfc-editor.org/info/rfc5250.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, http://www.rfc-editor.org/info/rfc7474.
[RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007, http://www.rfc-editor.org/info/rfc4940.
15.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, http://www.rfc-editor.org/info/rfc5226.
Appendix A. Prototype Implementation ✨
A.1. What Is Implemented and Tested ✨
1. Command-Line Interface (CLI) Commands for TTZ
okay so the CLIs we built and tested cover two things 💖
- the CLIs of the simpler option for configuring TTZ, and
- the CLIs for controlling migration to TTZ.
2. Extensions to OSPF Protocols for TTZ
bestie, every extension in "Extensions to OSPF Protocols" (Section 6) is implemented and tested 🔥 the one exception is rolling back from TTZ. the testing showed some iconic stuff:
- from the outside, a TTZ looks like its edge routers just connected to each other 🦋 any router outside the TTZ sees those edge routers as normal routers, connecting to each other and to some other routers. it's giving minimalism.
- the link-state info about the routers and links inside the TTZ stays inside the TTZ 🔒 it is not advertised to any router outside of the TTZ. secrets stay secret 🤫
- TTZ is transparent 👀 a router inside a TTZ sees the topology (link state) outside of it, and a router outside sees the topology beyond the TTZ. the link-state info outside the TTZ gets advertised through the TTZ. the whole thing is so seamless, I'm obsessed.
- TTZ is backward compatible 🫶 any router outside a TTZ doesn't need to support or know about TTZ. no drama, no upgrades required for the neighbors.
3. Smooth Migration to TTZ
the procedures and protocol extensions for smooth migration to TTZ are implemented and tested 🌸 the results were so good:
- a part of an OSPF area got smoothly migrated to a TTZ with no routing disruptions 😭 the routes on every router stayed stable the whole time that part of the area was moving into the TTZ.
- migration to TTZ is very easy to operate. literally main character energy 💅
4. Add a Router to TTZ
adding a router into a TTZ is implemented and tested 🧚 and it's so clean:
- a router can be easily added into a TTZ and become a TTZ router.
- the router added into the TTZ isn't seen on any router outside the TTZ, but it's still a full part of the TTZ. like a VIP who doesn't need to be on the guest list 👑
5. Leak TTZ Loopbacks Outside
leaking loopback addresses in a TTZ out to routers outside the TTZ is implemented and tested 🌈 the results:
- the loopback addresses inside the TTZ get advertised to the routers outside the TTZ.
- those loopback addresses are reachable from a router outside the TTZ. ✨ they can actually be reached, periodt.
A.2. Implementation Experience 🎀
ngl the TTZ implementation reuses the existing OSPF code and adds some simple logic on top. a couple of engineers started working on it in the middle of June 2014 and finished coding just before the end of July 2014 💀 after some testing and bug fixes, it works as expected. two months, the glow-up is real 🌟
in our implementation, the link-state info in a TTZ opaque LSA is stored in the same link-state database as the link-state info in a normal LSA. for each TTZ link in the TTZ opaque LSA there's an extra flag, and that flag is what tells a TTZ link apart from a normal link 🏷️
here's the routing logic, fr fr:
- before migration to TTZ, every router in the TTZ computes its routing table using the normal links.
- after migration to TTZ, every router in the TTZ computes its routing table using the TTZ links and the normal links.
- if both a TTZ link and a normal link exist, the TTZ link is the one used. the TTZ link wins, it's giving priority 👑
Acknowledgements 🫶
the authors want to thank Acee Lindem, Abhay Roy, Christian Hopps, Dean Cheng, Russ White, Tony Przygienda, Wenhu Lu, Lin Han, Kiran Makhijani, Padmadevi Pillay Esnault, and Yang Yu for their valuable comments on this spec. iykyk, and everyone who reviewed it deserves a huge hug 💜
Contributors 🌸
these people contributed significantly to the content of this document and should be considered co-authors 💅
Mehmet Toy
United States of America
Email: mehmet.toy@verizon.com
Gregory Cauchie
France
Email: greg.cauchie@gmail.com
Anil Kumar SN
India
Email: anil.sn@huawei.com
Ning So
United States of America
Email: ningso01@gmail.com
Lei Liu
United States of America
Email: lliu@us.fujitsu.comwe also want to shout out the contribution of the following individuals 🦋
Veerendranatha Reddy Vallem
India
Email: veerendranatharv@huawei.com
William McCall
United States of America
will.mccall@rightside.coAuthors' Addresses 🖋️
Huaimo Chen
Huawei Technologies
Boston, MA
United States of America
Email: huaimo.chen@huawei.com
Renwei Li
Huawei Technologies
2330 Central expressway
Santa Clara, CA
United States of America
Email: renwei.li@huawei.com
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Rd.
Raleigh, NC 27709
United States of America
Email: aretana@cisco.com
Yi Yang
Sockrate
Cary, NC
United States of America
Email: yyang1998@gmail.com
Zhiheng Liu
China Mobile
No.32 Xuanwumen West Street, Xicheng District
Beijing 100053
China
Email: liu.cmri@gmail.comthat's the whole spec, bestie 🌈✨ thank you for reading all of it 🧚💖
📦 where this page comes from
- ietf: rfc8099 2017-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms