idnits 2.17.00 (12 Aug 2021) /tmp/idnits53309/draft-thubert-roll-eliding-dio-information-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6550, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 427 has weird spacing: '...ed form then ...' == Line 431 has weird spacing: '...in full then ...' == Line 434 has weird spacing: '... elided then ...' -- The document date (17 October 2019) is 947 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-01) exists of draft-ietf-roll-mopex-cap-00 ** Downref: Normative reference to an Informational RFC: RFC 7102 ** Downref: Normative reference to an Informational RFC: RFC 7228 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ROLL P. Thubert, Ed. 3 Internet-Draft Cisco Systems 4 Updates: 6550 (if approved) D. Barthel 5 Intended status: Standards Track Orange Labs 6 Expires: 19 April 2020 R.A. Jadhav 7 Huawei Tech 8 17 October 2019 10 Eliding and Querying RPL Information 11 draft-thubert-roll-eliding-dio-information-01 13 Abstract 15 This document presents a method to safely elide a group of global RPL 16 options by synchonizing the state associated with each of these 17 options between parent and child using a new sequence counter in DIO 18 messages. A child that missed a DIO message with an update of any of 19 those protected options detects it by the change of sequence counter 20 and queries the update with a DIS Message. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 19 April 2020. 39 Copyright Notice 41 Copyright (c) 2019 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Updated DIO Base Object . . . . . . . . . . . . . . . . . 5 63 4.2. Updated DIS Base Object . . . . . . . . . . . . . . . . . 6 64 4.3. New Abbreviated Option Option . . . . . . . . . . . . . . 7 65 5. RCSS Operation . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Updating the RCSS . . . . . . . . . . . . . . . . . . . . 8 67 5.2. RCSS Freshness and Parent selection . . . . . . . . . . . 9 68 5.3. RCSS of an Option . . . . . . . . . . . . . . . . . . . . 10 69 6. Synchronizing Options . . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 8.1. New DODAG Information Object Flags . . . . . . . . . . . 11 73 8.2. New RPL Control Message Option . . . . . . . . . . . . . 12 74 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 75 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 76 11. Informative References . . . . . . . . . . . . . . . . . . . 13 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 Classical Link State protocol synchronize their Link State Database 82 (LSDB) by sequencing every change. Each interested node maintains 83 the last sequence of the LSDB it is synchronizing with. If the last 84 known sequence number is older than the current, the node needs to 85 learn one by one all the state changes between the last known and the 86 current state. 88 [RPL] does not operate that way. With RPL, the routing information 89 is repeated over and over in DODAG Information Object (DIO) and 90 Destination Advertisement Object (DAO) messages. There is no concept 91 of synchronization. The most recent information overrides a previous 92 one and a stale state eventually times out. 94 The RPL way was designed to enable routing from most nodes to most 95 nodes most of the time in a Low-Power Lossy Network (LLN) where the 96 quality of the links and the cost of communications does not permit 97 to maintain a permanent synchronization. 99 This principle was applied to both the routing and non-routing 100 information such as configuration settings, prefix information, and 101 node capabilities. 103 This non-routing state is carried in RPL Messages as options. Some 104 of the DIO options may be needed to decide whether a node can join a 105 network as a leaf or as a router, and may affect the parent selection 106 or the address selection. It is thus critical that each node 107 maintains its state to the freshest and selects parents that are also 108 synchronized to the freshest. 110 [RPL] allows a parent to elide options in the DIO messages that it 111 sends repeatedly, to conserve battery and save bandwidth. When it 112 does so, a newcomer child that missed DIOs that contained the 113 configuration option may operate on default or partial information. 114 If it is pessimistic, it may query all possible the information even 115 when it is not needed. Conversely, a node that slept may have missed 116 a DIO with a change in some critical information and may not be even 117 aware of it, so it may fail to query for the update and operate on 118 deprecated parameters. 120 This document uses a new sequence counter called RCSS to synchronize 121 the state in a child node with that of its parent, and recursively 122 with that of the whole network, to the latest setting from the Root. 124 The protected options are: 126 1. The Route Information Option (RIO) defined in section 6.7.5 of 127 [RPL] 129 2. The DODAG Configuration Option (DCO) defined in section 6.7.6 of 130 [RPL] 132 3. The Prefix Information Option (PIO) defined in section 6.7.10 of 133 [RPL] 135 4. The Extended MOP Option (MOPex) defined in [MOPEX-CAP] 137 5. The Global Capabilities Option (GCO) defined in [MOPEX-CAP] 139 Any change in those options causes an increment of the RCSS and 140 enables a network-wide synchronization to the new state. If the 141 change impacts the routing substantially, the Root should decide to 142 increment the Version Number at the same time to fully rebuild the 143 DODAG with the new settings of the options. It must be noted that 144 the operation of the Version Number in itself provides no guarantee 145 that the non-routing state is fully resynchronized everywhere unless 146 all the options are present in all the DIO messages. 148 2. Terminology 150 2.1. BCP 14 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 154 "OPTIONAL" in this document are to be interpreted as described in BCP 155 14 [RFC2119][RFC8174] when, and only when, they appear in all 156 capitals, as shown here. 158 2.2. References 160 The Terminology used in this document is consistent with and 161 incorporates that described in Terms Used in Routing for Low-Power 162 and Lossy Networks [RFC7102]. 164 Other terms in use in LLNs are found in Terminology for 165 Constrained-Node Networks [RFC7228]. 167 A glossary of classical RPL acronyms is given in Section 2.3. 169 The term "byte" is used in its now customary sense as a synonym for 170 "octet". 172 "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO 173 and DIS messages are defined in the "RPL: IPv6 Routing Protocol for 174 Low-Power and Lossy Networks" [RPL] specification. 176 This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware 177 Leaf (RAL) consistently with [USE_OF_RPL_INFO]. 179 The term RPL-Unaware Leaf (RUL) is used to refer to a node that uses 180 a RPL router (without necessarily knowing it) as 6LR and depends on 181 that router to obtain reachability for its addresses inside the RPL 182 domain. On the contrary, the term RPL-Aware Node (RAN) is used to 183 refer to a RAL or a RPL router that participates to RPL and 184 advertises its addresses of prefixes by itself. 186 2.3. Glossary 188 This document often uses the following acronyms: 190 DODAG Destination-Oriented Directed Acyclic Graph 191 LLN Low-Power and Lossy Network 193 RPI RPL Packet Information (an Option in the Hop-By_Hop Header) 195 RAL RPL-Aware Leaf 197 RAN RPL-Aware Node, a RPL router or a RPL-Aware Leaf 199 RS Router Solicitation 201 RCSS RPL Configuration State Sequence 203 RPL IPv6 Routing Protocol for LLNs (pronounced ripple) 205 RUL RPL-Unaware Leaf 207 3. Updating RFC 6550 209 This document adds a new field called RCSS to the DIO message. The 210 RCSS is a sequence counter set by the Root and operated as specified 211 in Section 7 of [RPL], more in Section 5. 213 This document also introduces a new RPL Control Message Option called 214 the Abbreviated Option Option (AOO). The AOO is the compressed 215 replacement of a protected option that indicates the RCSS of the last 216 change of that option, but elides its content, more in Section 4.3. 218 This document modifies the DIS Base Objectto enable the individual 219 query of the protected options by a node that missed a change, more 220 in Section 4.2. 222 4. Message Formats 224 4.1. Updated DIO Base Object 226 The format of the DIO Base Object is defined in section 6.3.1 of 227 [RPL]. This specification uses a 8th octet that was reserved in 228 [RPL] to transport the RCSS. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | RPLInstanceID |Version Number | Rank | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |G|0| MOP | Prf | DTSN | Flags | RCSS | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 + + 239 | | 240 + DODAGID + 241 | | 242 + + 243 | | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Option(s)... 246 +-+-+-+-+-+-+-+-+ 248 Figure 1: Updated DIO Base Object 250 Updated fields: 252 RCSS 253 One Byte, the RPL Configuration State Sequence 255 4.2. Updated DIS Base Object 257 The DIS Base Object is use by a child to query from a parent the most 258 recent changes in protected options. This specification adds flags 259 to indicate which options are requested and the freshest RCSS to 260 which the querying node was synchronized. 262 0 1 2 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 |R|D|P[M|O| Flg | LastSync RCSS | Option(s)... 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 2: Updated DIS Base Object 270 Updated fields: 272 R 273 One Bit, indicates that the RIO is requested 275 D 276 One Bit, indicates that the DCO is requested 278 P 279 One Bit, indicates that the PIO(s) is(are) requested 281 M 282 One Bit, indicates that the MOPex is requested 284 O 285 One Bit, indicates that the GCO is requested 287 Last Synchronized RCSS 288 One Byte, indicates the freshest RCSS to which the querier was 289 synchronized 291 4.3. New Abbreviated Option Option 293 When a protected option is unchanged from the previous DIOs, the Root 294 MAY replace it with its abbreviated version. The abbreviated version 295 of an option is transported in a 4-bytes long Abbreviated Option 296 Option (AOO). The AOO indicates the RCSS at which the protected 297 option was last changed. 299 0 1 2 3 300 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 2 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Option Type | Option Length | Abbrev. opt. | Last Mod RCSS | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 3: Abbreviated Option Option Format 307 Option fields: 309 Option Type 310 One byte indicating "Abbreviated Option", see Table 2 in 311 Section 8.2 313 Option Length 314 MUST be set to 2 indicating Option data of 2 bytes 316 Abbreviated Option 317 The Option Type of the option being abbreviated 319 Last Modification RCSS 320 The RCSS at which the option was last modified 322 5. RCSS Operation 324 Settings and updates to network-wide parameters are initiated by the 325 Root and propagated down the DODAG in RPL Control Message Options in 326 DIO messages. The DIO messages arrive asynchronously via different 327 parents and may confuse a child. The RCSS allows the child to keep 328 synchronized to the latest settings network-wide parameters that are 329 propagated in protected options. 331 The RCSS is a sequence number that is operated as specified in 332 section 7.2 of [RPL]. The scope of an RCSS is one DODAG within one 333 RPL Instance. The RCSS applies to a DIO Message and a same value of 334 the RCSS can be used in DIO messages that are sent consecutively with 335 no change in the protected options. 337 The Root of the DODAG is autoritative to set and update the RCSS and 338 the options that it protects. The RCSS and the protected options are 339 propagated together down the DODAG without a change, more in 340 Section 5.1. 342 The RCSS allows a child node to recognize the fresher DIO Message(s) 343 as received from one or more advertising parents and to use only 344 parents with a consistent state of network-wide parameters, more in 345 Section 5.2. 347 By extension, the RCSS is also defined for each protected option. A 348 child associates an option with the values of the RCSS indicated in 349 DIO Messages in which the option is advertised and uses it to assess 350 the relative freshness of different versions of an option, more in 351 Section 5.3. 353 Unchanged options may be sent in full, elided, or in the abbreviated 354 form specified in Section 4.3. Eliding an option is NOT RECOMMENDED 355 as it may cause multiple children to resynchronize the option even if 356 it was not changed. 358 If the link MTU does not permit to send a single DIO message with all 359 the options packaged then the options may be spread over multiple 360 consecutive DIO messages with the same RCSS that are sent in a rapid 361 sequence. 363 5.1. Updating the RCSS 365 The RCSS is incremented by the Root using a lollipop technique as 366 specified in section 7.2 of [RPL]. RCSS values are comparable if 367 they are within a window of comparison of SEQUENCE_WINDOW increments 368 or one indicates a reboot. 370 A reboot of the Root is detected when the RCSS moves from the 371 circular to the straight part of the lollipop. In order to maximize 372 the chances of detection, the straight part should be kept very short 373 with a RECOMMENDED initialization at 252 or above. 375 During the straight part of the lollipop, a second reboot of the Root 376 might not be recognized and a same value of the RCSS may reappear 377 with different settings in the protected options. For that reason 378 the protected options MUST be provided in full with each increment on 379 the RCSS during the straight part of the lollipop. 381 When a field is modified in one of the protected options, the Root 382 MUST send a DIO with an incremented RCSS and the modified protected 383 option(s) in full. The Root MAY also update the Version Number to 384 form a new DODAG altogether. 386 The Root SHOULD jump rapidly away from the straight part once the 387 network has sufficiently settled by resetting the RCSS to 0, which 388 places the RCSS in the circular region of the lollipop, where the 389 protected options MAY be elided or abbreviated. 391 5.2. RCSS Freshness and Parent selection 393 A child node maintains the freshest RCSS received from its parents in 394 each of the RPL Instances that it participates to, and uses that RCSS 395 for its own DIO messages. 397 A child and a candidate parent are out-of-sync when the RCSS values 398 that they maintain for a RPL Instance are not comparable. A child 399 MUST NOT use a parent that is out-of-sync unless no other parent is 400 available, in which case it MAY align its RCSS and resynchronize to 401 that parent. 403 When a child receives from a candidate parent a DIO with an RCSS that 404 is fresher than the one it is using, the child MUST synchronize the 405 state relative to the protected options with that parent. The child 406 node MUST refrain from using that parent and the new state including 407 the RCSS, until it has synchronized all of the protected options to 408 that RCSS. When it is fully synchronized, the child may then use 409 that parent and the new RCSS. 411 Using a back-level parent may cause packets to be dropped, 412 misunderstood or misrouted. The child SHOULD refrain from using a 413 parent that exposes an older RCSS if the change causes an 414 incompatibility issue. 416 5.3. RCSS of an Option 418 By extension, the RCSS of an option is maintained by a child as the 419 freshest RCSS indicated by a DIO message from a candidate parent in 420 which the option was present in the abbreviated form or in full. A 421 child maintains a state for the freshest RCSS received for each of 422 the protected options and synchronizes its state for each option to 423 the freshest RCSS of that option. 425 When a child receives a DIO from a candidate parent, for each option: 427 If the Option is advertised in the abbreviated form then the RCSS 428 that the DIO advertises for the option is the Last Modification 429 RCSS of the AOO, else 431 If the Option is advertised in full then the RCSS that the DIO 432 advertises for the option is the RCSS of the DIO, else 434 If the Option is elided then the RCSS is unspecified but it is at 435 most as fresh as the RCSS of the DIO, and the RCSS of the DIO is 436 assumed for the comparison 438 This means that if an Option is advertised in both the abbreviated 439 form and in full in a same DIO message then the RCSS in the AOO has 440 precedence. 442 To keep the RCSS comparable for each option, the RCSS of an option 443 must lazily progress along with the global RCSS even if there was no 444 change in the options. Each parent including the Root MUST advertise 445 a new RCSS for each of the protected options at least once within a 446 sliding window of SEQUENCE_WINDOW increments. 448 When an option was not changed for a new RCSS, one parent may 449 advertise it in the abbreviated form while another sends the option 450 in full only, e.g., in response to a DIS message. A fresher RCSS 451 indicates that the option is either the same or carries a more recent 452 update than the one with an older RCSS. 454 The RCSS of an option may be obtained from a DIO message that carries 455 the option in full even if the RCSS of the DIO is not the freshest 456 across parents, as long as the RCSS of the DIO is fresher than the 457 current one for that option. 459 If current value of the maintained RCSS for an given option is not as 460 fresh or fresher than that advertised in a DIO message, then the 461 child MUST update its state for that option as specified in 462 Section 6. 464 6. Synchronizing Options 466 A child can resynchronize any of the protected options to the latest 467 RCSS by sending a DIS Message to a candidate parent that advertises 468 that RCSS in DIO messages. The child MUST set the desired 469 combination of 'R', 'D', 'P', 'M' and 'O' flags to indicate the 470 option(s) that it needs updated. The child MUST signal in the Last 471 Synchronized RCSS field of the DIS the freshest value of RCSS for 472 which it was fully synchronized, or a conventional value of OUT-OF- 473 SYNC-RCSS of 129 if it was never synchronized or is out-of-sync with 474 the parent. 476 The DIO message that is sent in response MUST contain in full all the 477 options that are requested and that were updated since the Last 478 Synchronized RCSS in the DIS Message. This means all of the 479 protected options of the child was never synchronized or is out-of- 480 sync with the parent. The other options MUST be added in the 481 abbreviated form. The options MAY be spread over more than one DIO 482 message sent in a quick sequence and the child SHOULD wait a 483 reasonable technology-dependent time before it retries the request. 485 7. Security Considerations 487 TBD 489 8. IANA Considerations 491 8.1. New DODAG Information Object Flags 493 5 new bits are allocated in the Registry for the DODAG Information 494 Object (DIO) Flags defined for [RPL]. 496 +------------+----------------------------+--------------+ 497 | Bit Number | Capability description | Defining RFC | 498 +============+============================+==============+ 499 | 0 | 'R' bit "RIO requested" | THIS RFC | 500 +------------+----------------------------+--------------+ 501 | 1 | 'D' bit "DCO requested" | THIS RFC | 502 +------------+----------------------------+--------------+ 503 | 2 | 'P' bit "PIO(s) requested" | THIS RFC | 504 +------------+----------------------------+--------------+ 505 | 3 | 'M' bit "MOPex requested" | THIS RFC | 506 +------------+----------------------------+--------------+ 507 | 4 | 'O' bit "GCO irequested" | THIS RFC | 508 +------------+----------------------------+--------------+ 510 Table 1: New DIO Flags 512 8.2. New RPL Control Message Option 514 A new entry is required for the new option of type "Abbreviated 515 Option", from the "RPL Control Message Options" space defined for 516 [RPL]. 518 +----------+--------------------+--------------+ 519 | Code | Description | Defining RFC | 520 +==========+====================+==============+ 521 | TBD IANA | Abbreviated Option | THIS RFC | 522 +----------+--------------------+--------------+ 524 Table 2: New Option Type 526 9. Acknowledgments 528 10. Normative References 530 [MOPEX-CAP] 531 Jadhav, R. and P. Thubert, "Mode of Operation extension 532 and Capabilities", Work in Progress, Internet-Draft, 533 draft-ietf-roll-mopex-cap-00, 9 August 2019, 534 . 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 543 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 544 2014, . 546 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 547 Constrained-Node Networks", RFC 7228, 548 DOI 10.17487/RFC7228, May 2014, 549 . 551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 553 May 2017, . 555 [RPL] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 556 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 557 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 558 Low-Power and Lossy Networks", RFC 6550, 559 DOI 10.17487/RFC6550, March 2012, 560 . 562 [USE_OF_RPL_INFO] 563 Robles, I., Richardson, M., and P. Thubert, "Using RPL 564 Option Type, Routing Header for Source Routes and IPv6-in- 565 IPv6 encapsulation in the RPL Data Plane", Work in 566 Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-31, 567 7 August 2019, . 570 11. Informative References 572 Authors' Addresses 574 Pascal Thubert (editor) 575 Cisco Systems, Inc 576 Building D, 45 Allee des Ormes - BP1200 577 06254 Mougins - Sophia Antipolis 578 France 580 Phone: +33 497 23 26 34 581 Email: pthubert@cisco.com 583 Dominique Barthel 584 Orange Labs 585 28 chemin du Vieux Chêne 586 38243 Meylan 587 France 589 Email: dominique.barthel@orange.com 591 Rahul Arvind Jadhav 592 Huawei Tech 593 Kundalahalli Village, Whitefield, 594 Bangalore 560037 595 Karnataka 596 India 598 Phone: +91-080-49160700 599 Email: rahul.ietf@gmail.com