RFC 8001

RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information

📅 published January 2017, from ietf

Okay bestie, this one is all about RSVP-TE (including GMPLS) and how a network can automatically collect SRLG info for a TE link that's formed by an LSP. 🦋 It's a Standards Track document from the IETF, published in January 2017. The editors are F. Zhang (Huawei), O. Gonzalez de Dios (Telefonica Global CTO), C. Margaria (Juniper), M. Hartley (Cisco), and Z. Ali (Cisco). Nobody obsoletes anything here, and it doesn't update any other RFCs. Pure vibes, no drama. ✨

The ISSN is 2070-1721 🌸

Abstract ✨

This doc adds extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE), GMPLS included, so that SRLG information gets collected automatically for the TE link formed by a Label Switched Path (LSP). It's giving "the network does the research for you" 🧚

Status of This Memo 🎀

This is an Internet Standards Track document. 💅

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 7841. 📚

Info about the current status, errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc8001. 🔗

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 in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of 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 that license. ⚖️

Table of Contents 🗂️

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Applicability Example: Dual-Homing . . . . . . . . . . . .  3
2.  Requirements Language  . . . . . . . . . . . . . . . . . . . .  5
3.  RSVP-TE Requirements . . . . . . . . . . . . . . . . . . . . .  5
  3.1.  SRLG Collection Indication . . . . . . . . . . . . . . . .  5
  3.2.  SRLG Collection  . . . . . . . . . . . . . . . . . . . . .  6
  3.3.  SRLG Update  . . . . . . . . . . . . . . . . . . . . . . .  6
  3.4.  SRLG ID Definition . . . . . . . . . . . . . . . . . . . .  6
4.  Encodings  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
  4.1.  SRLG Collection Flag . . . . . . . . . . . . . . . . . . .  6
  4.2.  RRO SRLG Subobject   . . . . . . . . . . . . . . . . . . .  7
5.  Signaling Procedures . . . . . . . . . . . . . . . . . . . . .  8
  5.1.  SRLG Collection  . . . . . . . . . . . . . . . . . . . . .  8
  5.2.  SRLG Update  . . . . . . . . . . . . . . . . . . . . . . . 10
  5.3  Domain Boundaries . . . . . . . . . . . . . . . . . . . . . 10
  5.4.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . 11
6.  Manageability Considerations . . . . . . . . . . . . . . . . . 11
  6.1.  Policy Configuration . . . . . . . . . . . . . . . . . . . 11
  6.2.  Coherent SRLG IDs  . . . . . . . . . . . . . . . . . . . . 11
7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
  8.1.  RSVP Attribute Bit Flags . . . . . . . . . . . . . . . . . 12
  8.2.  ROUTE_RECORD Object  . . . . . . . . . . . . . . . . . . . 12
  8.3.  Policy Control Failure Error Subcodes  . . . . . . . . . . 13
9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
  9.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
  9.2.  Informative References . . . . . . . . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

1. Introduction 🦋

Okay, so it's super important to know which Traffic Engineering (TE) links in a network could be at risk from the same failures. A set of links counts as a Shared Risk Link Group (SRLG) if they share some resource whose failure can knock out every link in the set [RFC4202]. 💀

Then there's the other side of it. As [RFC4206] and [RFC6107] describe, a Hierarchical LSP (H-LSP) or a stitched LSP (S-LSP) can be used to carry one or more other LSPs. Both the H-LSP and the S-LSP can be formed as a TE link, and that's where it gets interesting, because you need to know the SRLG info of the LSPs that are going to carry other LSPs. 🧚

So this doc gives you a signaling mechanism that collects the SRLGs an LSP uses, and those can then be advertised as properties of the TE link that LSP forms. It's literally the main character move 👑

1.1. Applicability Example: Dual-Homing 💅

This is an iconic use case for the SRLG collection procedures in this doc: getting LSP diversity in a dual-homing setup. 🎀 It's illustrated in Figure 1, which assumes the overlay model from [RFC4208] is in use. In this example, operator policy stops routing info from being exchanged over the User-Network Interface (UNI). 🙈

                        +---+    +---+
                        | P |....| P |
                        +---+    +---+
                       /              \
                  +-----+               +-----+
         +---+    | PE1 |               | PE3 |    +---+
         |CE1|----|     |               |     |----|CE2|
         +---+\   +-----+               +-----+   /+---+
               \     |                     |     /
                \ +-----+               +-----+ /
                 \| PE2 |               | PE4 |/
                  |     |               |     |
                  +-----+               +-----+
                        \              /
                        +---+    +---+
                        | P |....| P |
                        +---+    +---+

                     Figure 1: Dual-Homing Configuration

Single-homed customer edge (CE) devices hook up to one provider edge (PE) device through one UNI link. That link might be a bundle of parallel links, usually riding the same fiber cable. 🧵 The problem is that this single UNI link can be a single point of failure. You can dodge that by connecting the CE device to two PE devices through two UNI interfaces, one for CE1 and one for CE2, like Figure 1 shows. 🦋

For dual-homing, you can set up two connections (LSPs) from the source CE device to the same destination CE device. One connection goes through the UNI link to PE1, for example, and the other goes through the UNI link to PE2. 💖 To avoid single points of failure inside the provider network, you also need path (LSP) diversity there, so the two LSPs are end-to-end diverse between CE1 and CE2. This use case shows how to get path diversity inside the provider network using collected SRLG info. Since the two connections enter the provider network at different PE devices, the PE that gets the second connection request needs to know the extra path computation constraints so that the second LSP's path is disjoint from the first connection. 🫶

SRLG info is normally not shared between the provider network and the client network (that is, between PE and CE devices), so the challenge is how to solve the diversity problem when a CE is dual-homed. 😭 The RSVP extensions for collecting SRLG info in this doc make it possible to retrieve SRLG info for an LSP, and that's how you solve the dual-homing LSP diversity problem. For example, CE1 in Figure 1 might request LSP1 to CE2 via PE1, routed through PE3 to CE2. Then CE1 can request LSP2 to CE2 via PE2, with the constraint that it has to be maximally SRLG disjoint from LSP1. PE2, however, has no SRLG info associated with LSP1, and it needs that as input for its constraint-based path computation function. 🤔 If CE1 can retrieve the SRLG info for LSP1 from PE1, it can pass that discovered info to PE2 as part of the LSP2 setup request (RSVP PATH message), inside an EXCLUDE_ROUTE Object (XRO) or an Explicit Exclusion Route Subobject (EXRS) as described in [RFC4874]. Then PE2 can calculate a path for LSP2 that's SRLG disjoint from LSP1. The SRLG info for LSP1 can be retrieved when LSP1 is set up, or at any time before LSP2 is set up. ✨

When CE1 sends the setup request for LSP2 to PE2, it can also ask for SRLG info to be collected for LSP2 and sent to PE1 by re-signaling LSP1 with SRLG-exclusion based on LSP2's discovered SRLGs. 🌈 This keeps the two paths mutually diverse, which matters when the provider network can restore connections that failed because of a network failure (a fiber cut) inside the provider network. 🔥

Heads up though: knowing SRLG info, even for multiple LSPs, does not let a CE device derive the provider network topology. 👀 It would be possible, though, for an entity controlling multiple CE devices to derive some topology-related info. So this doc lets PE devices control the communication of SRLGs outside the provider network, if they want. 🛡️

2. Requirements Language 🎀

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]. 📖

3. RSVP-TE Requirements 💜

The SRLG collection process happens in three stages:

  • The LSP's ingress node requests that SRLG collection take place. 🚀
  • SRLG data is added to the Path and Resv ROUTE_RECORD Objects (RROs) by all nodes during signaling. 🧚
  • Changes to previously signaled SRLG data are made by sending updated Path and Resv messages as required. 💅

3.1. SRLG Collection Indication 🌸

The ingress node of the LSP needs be capable of indicating whether the SRLG info of the LSP is to be collected during the signaling procedure for setting up an LSP. There's no need for SRLG info to be collected without an explicit request from the ingress node. 🙅‍♀️

It may be preferable for the SRLG collection request to be understood by all nodes along the LSP's path. Or it may matter more that the LSP gets established successfully, even if it goes through nodes that can't supply SRLG info or haven't implemented the procedures in this doc. 🤷‍♀️ It's desirable for the ingress node to make the SRLG collection request in a way that best suits its own policy. 💖

(Part 1 of 3. Keep your seatbelt on, more is coming, bestie. 🎀✨ Section 3.2 onward is next!)

3.2. SRLG Collection 💖

okay so if somebody asks for it, the SRLG info gets collected while the LSP is being set up 🎀. Every hop adds the SRLG info to the Path RRO while it's processing the Path message 🦋. Then during Resv processing, each hop adds that same info to the Resv RRO too ✨. Iconic teamwork.

3.3. SRLG Update 🌸

this one's giving "things change, keep up" 😭. When the SRLG info of an existing LSP changes, and that LSP collected SRLG info during signaling, the relevant nodes of the LSP need to be able to update it. Which means the signaling procedure itself has to be capable of updating the new SRLG info 💅.

3.4. SRLG ID Definition 🧚

The identifier of an SRLG (SRLG ID) is defined as a 32-bit quantity in [RFC4202]. This doc uses that definition too 🫶.

4. Encodings 🎀

4.1. SRLG Collection Flag 🦋

to tell nodes that SRLG collection is wanted, this doc defines a new flag in the Attribute Flags TLV (see [RFC5420]). So yeah, it's a new SRLG Collection Flag in the Attribute Flags TLV, period. A node that wants to say SRLG collection is desired MUST set this flag in an Attribute Flags TLV in an LSP_REQUIRED_ATTRIBUTES object (if collection is to be mandatory) or an LSP_ATTRIBUTES object (if collection is desired but not mandatory).

  • Bit Number (specified in Section 8.1): SRLG Collection Flag

The SRLG Collection Flag is meaningful on a Path message. If it's set to 1, it means the SRLG info SHOULD be reported to the ingress and egress node along the setup of the LSP.

The rules for the processing of the Attribute Flags TLV are not changed.

4.2. RRO SRLG Subobject 🌈

This doc defines a new RRO subobject (ROUTE_RECORD subobject) to record the SRLG info of the LSP. Its format is modeled on the RRO subobjects defined in [RFC3209].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |D|          Reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 SRLG ID 1 (4 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ~                           ......                              ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 SRLG ID n (4 octets)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type (8 bits)

The type of the subobject. The value is specified in Section 8.2.

Length (8 bits)

The Length field contains the total length of the subobject in octets, including the Type and Length fields. The Length depends on the number of SRLG IDs.

Direction bit (D-bit) (1 bit)

If not set, the SRLGs contained in this subobject apply to the downstream direction. If set, they apply to the upstream direction.

Reserved (15 bits)

This 15-bit field is reserved. It SHOULD be set to zero on transmission and MUST be ignored on receipt.

SRLG ID (4 octets)

This field contains one SRLG ID. There is one SRLG ID field per SRLG collected. There MAY be multiple SRLG ID fields in an SRLG subobject.

A node MUST NOT push an SRLG subobject in the ROUTE_RECORD without also pushing either an IPv4 subobject, an IPv6 subobject, an Unnumbered Interface ID subobject, or a Path Key Subobject (PKS).

As described in [RFC3209], the ROUTE_RECORD object is managed as a stack. The SRLG subobject MUST be pushed by the node before the node IP address or link identifier. The SRLG subobject SHOULD be pushed after the Attribute subobject, if present, and after the LABEL subobject, if requested. It MUST be pushed within the hop to which it applies.

[RFC5553] describes mechanisms to carry a PKS in the RRO so as to facilitate confidentiality in the signaling of inter-domain TE LSPs. RFC 5553 allows the path segment that needs to be hidden (that is, a Confidential Path Segment (CPS)) to be replaced in the RRO with a PKS. If the CPS contains SRLG subobjects, these MAY be retained in the RRO by adding them again after the PKS in the RRO. The CPS is defined in [RFC5520].

The rules for the processing of the LSP_REQUIRED_ATTRIBUTES, LSP_ATTRIBUTES, and ROUTE_RECORD objects are not changed.

5. Signaling Procedures ⭐

The ingress node of the LSP MUST be capable of indicating whether the SRLG info of the LSP is to be collected during the signaling procedure of setting up an LSP.

5.1. SRLG Collection 👑

Per [RFC3209], an ingress node starts recording the route info of an LSP by adding an RRO to a Path message. If an ingress node also wants SRLG recording, it MUST set the SRLG Collection Flag in the Attribute Flags TLV, which MAY be carried in either an LSP_REQUIRED_ATTRIBUTES object (when the collection is mandatory) or an LSP_ATTRIBUTES object (when the collection is desired, but not mandatory).

A node MUST NOT add SRLG information without an explicit request by the ingress node in the Path message.

When a node receives a Path message that carries an LSP_REQUIRED_ATTRIBUTES object with the SRLG Collection Flag set, if local policy determines that the SRLG information is not to be provided to the endpoints, it MUST return a PathErr message with

  • Error Code 2 (policy) and
  • Error subcode "SRLG Recording Rejected" (see Section 8.3 for value)

to reject the Path message.

When a node receives a Path message that carries an LSP_ATTRIBUTES object with the SRLG Collection Flag set, if local policy determines that the SRLG information is not to be provided to the endpoints, the Path message MUST NOT be rejected due to the SRLG recording restriction, and the Path message MUST be forwarded without any SRLG subobject(s) added to the RRO of the corresponding outgoing Path message.

If local policy permits the recording of the SRLG information, the processing node SHOULD add local SRLG information, as defined below, to the RRO of the corresponding outgoing Path message. The processing node MAY add multiple SRLG subobjects to the RRO if necessary. It then forwards the Path message to the next node in the downstream direction. The processing node MUST retain a record of the SRLG recording request for reference during Resv processing described below.

If the addition of SRLG information to the RRO would result in the RRO exceeding its maximum possible size or becoming too large for the Path message to contain it, the requested SRLGs MUST NOT be added. If the SRLG collection request was contained in an LSP_REQUIRED_ATTRIBUTES object, the processing node MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. If the SRLG collection request was contained in an LSP_ATTRIBUTES object, the processing node MAY omit some or all of the requested SRLGs from the RRO; otherwise, it MUST behave as specified by [RFC3209] and drop the RRO from the Path message entirely. Subsequent processing of the LSP proceeds as further specified in [RFC3209].

Following the steps described above, the intermediate nodes of the LSP can collect the SRLG information in the RRO during the processing of the Path message hop by hop. When the Path message arrives at the egress node, the egress node receives SRLG information in the RRO.

Per [RFC3209], when issuing a Resv message for a Path message that contains an RRO, an egress node initiates the RRO process by adding an RRO to the outgoing Resv message. The processing for RROs contained in Resv messages then mirrors that of the Path messages.

When a node receives a Resv message for an LSP for which SRLG Collection was specified in the corresponding Path message, then when local policy allows recording SRLG information, the node MUST add SRLG information to the RRO of the corresponding outgoing Resv message as specified below. When the Resv message arrives at the ingress node, the ingress node can extract the SRLG information from the RRO in the same way as the egress node.

Note that a link's SRLG information for the upstream direction cannot be assumed to be the same as that for the downstream direction.

  • For Path and Resv messages for a unidirectional LSP, a node SHOULD include SRLG subobjects in the RRO for the downstream data link only.
  • For Path and Resv messages for a bidirectional LSP, a node SHOULD include SRLG subobjects in the RRO for both the upstream data link and the downstream data link from the local node. In this case, the node MUST include the information in the same order for both Path messages and Resv messages. That is, the SRLG subobject for the upstream link is added to the RRO before the SRLG subobject for the downstream link.

If SRLG data is added for both the upstream and downstream links, the two sets of SRLG data MUST be added in separate SRLG subobjects. A single SRLG subobject MUST NOT contain a mixture of upstream and downstream SRLGs. When adding a SRLG subobject to an RRO, the D-bit MUST be set appropriately to indicate the direction of the SRLGs. If an SRLG ID applies in both directions, it SHOULD be added to both the upstream and downstream SRLG subobjects.

Based on the above procedure, the endpoints can get the SRLG information automatically. Then, for instance, the endpoints can advertise it as a TE link to the routing instance based on the procedure described in [RFC6107] and configure the SRLG information of the Forwarding Adjacency (FA) automatically.

5.2. SRLG Update 🦋

When the SRLG information of a link is changed, the endpoints of LSPs using that link need to be made aware of the changes. When a change to the set of SRLGs associated with a link occurs, the procedures defined in Section 4.4.3 of [RFC3209] MUST be used to refresh the SRLG information for each affected LSP if the local node's policy dictates that the SRLG change be communicated to other nodes.

5.3 Domain Boundaries 🌸

If mandated by local policy as specified by the network operator, a node MAY remove SRLG information from any RRO in a Path or Resv message being processed. It MAY add a summary of the removed SRLGs or map them to other SRLG values. However, this SHOULD NOT be done unless explicitly mandated by local policy.

5.4. Compatibility 💜

A node that does not recognize the SRLG Collection Flag in the Attribute Flags TLV is expected to proceed as specified in [RFC5420]. It is expected to pass the TLV on unaltered if it appears in an LSP_ATTRIBUTES object or to reject the Path message with the appropriate Error Code and Value if it appears in a LSP_REQUIRED_ATTRIBUTES object.

A node that does not recognize the SRLG RRO subobject is expected to behave as specified in [RFC3209]: unrecognized subobjects are to be ignored and passed on unchanged.

6. Manageability Considerations 🍓

6.1. Policy Configuration 🎀

okay so picture a border node sitting between an inter-domain or inter-layer network 🦋. Its SRLG processing policy MUST be capable of being configured, bestie. Non-negotiable 💅. Here's what has to be configurable:

  • Whether the node is allowed to participate in SRLG collection and notify changes to collected SRLG information to endpoint nodes as described in Section 5.2.
  • Whether the SRLG IDs of the domain or specific layer network can be exposed to the nodes outside the domain or layer network, or whether they SHOULD be summarized, mapped to values that are comprehensible to nodes outside the domain or layer network, or removed entirely as described in Section 5.3.

and then ngl the last bit is giving freedom 🌸: a node using [RFC5553] and PKS MAY apply the same policy.

6.2. Coherent SRLG IDs 🧚

so in a multi-layer, multi-domain setup, SRLG IDs can get configured by different management entities in each layer or domain 👀. Which is a whole vibe, because keeping a coherent set of SRLG IDs is a key requirement if you want to actually use the SRLG information properly 🔥. So SRLG IDs SHOULD be unique. ✨

Quick note 💖: current procedures are aimed at a scenario where the different layers and domains belong to the same operator or to several coordinated administrative groups. Making sure the coherence we just talked about actually holds is beyond the scope of this document.

Further scenarios, where coherence in the SRLG IDs cannot be guaranteed, are out of scope for this document and are left for further study 🌈.

7. Security Considerations 🔐

this part is serious, bestie 😭. This document builds on the mechanisms defined in [RFC3473], which also discusses related security measures. On top of that, [RFC5920] gives an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane.

The procedures in this document permit the transfer of SRLG data between layers or domains during the signaling of LSPs, subject to policy at the layer or domain boundary. As described in Sections 5.3 and 6.1, local policy as specified by the network operator will explicitly mandate the processing of information at domain or layer boundaries. Operators are the gatekeepers here, so the boundary policy really is the whole ballgame 💀.

8. IANA Considerations 📋

8.1. RSVP Attribute Bit Flags 🦋

IANA has created a registry and manages the space of the Attribute bit flags of the Attribute Flags TLV, as described in Section 11.3 of [RFC5420], in the "Attribute Flags" subregistry of the "Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" registry located at http://www.iana.org/assignments/rsvp-te-parameters.

This document introduces a new Attribute bit flag:

   Bit No     Name        Attribute   Attribute   RRO  ERO  Reference
                          Flags Path  Flags Resv
   ---------  ----------  ----------  ----------- ---  ---  ---------
   12         SRLG        Yes         No          Yes  No   RFC 8001,
              Collection                                    [RFC7570]
              Flag

8.2. ROUTE_RECORD Object 🌸

IANA manages the "Resource Reservation Protocol (RSVP) Parameters" registry located at http://www.iana.org/assignments/rsvp-parameters. This document introduces a new RRO subobject under the "Sub-object type - 21 ROUTE_RECORD - Type 1 Route Record" subregistry:

   Value    Description           Reference
   -----    -------------------   ---------
   34       SRLG subobject        RFC 8001

8.3. Policy Control Failure Error Subcodes 🙈

IANA manages the assignments in the "Error Codes and Globally-Defined Error Value Sub-Codes" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at http://www.iana.org/assignments/rsvp-parameters.

This document introduces a new value under "Sub-Codes - 2 Policy Control Failure":

   Value   Description               Reference
   -----   -----------------------   ---------
   21      SRLG Recording Rejected   RFC 8001

9. References 📚

9.1. Normative References 💜

9.2. Informative References 🧠

Acknowledgements 🫶

the authors want to give a huge shoutout to Dieter Beller, Vishnu Pavan Beeram, Lou Berger, Deborah Brungard, Igor Bryskin, Ramon Casellas, Niclas Comstedt, Alan Davey, Elwyn Davies, Dhruv Dhody, Himanshu Shah, and Xian Zhang for their useful comments and improvements to this document 💖✨.

Contributors 🌟

   Dan Li
   Huawei
   F3-5-B RD Center
   Bantian, Longgang District, Shenzhen  518129
   China

   Email: danli@huawei.com

Authors' Addresses 💅

   Fatai Zhang (editor)
   Huawei
   F3-5-B RD Center
   Bantian, Longgang District, Shenzhen  518129
   China

   Email: zhangfatai@huawei.com


   Oscar Gonzalez de Dios (editor)
   Telefonica Global CTO
   Distrito Telefonica, edificio sur, Ronda de la Comunicacion 28045
   Madrid  28050
   Spain
   Phone: +34 913129647

   Email: oscar.gonzalezdedios@telefonica.com


   Cyril Margaria
   Juniper
   200 Somerset Corporate Blvd., Suite 4001
   Bridgewater, NJ  08807
   United States of America

   Email: cmargaria@juniper.net


   Matt Hartley
   Cisco

   Email: mhartley@cisco.com


   Zafar Ali
   Cisco

   Email: zali@cisco.com

that's the whole RFC, bestie! 🌈👑 you made it!!

📦 where this page comes from