idnits 2.17.1 draft-eckert-anima-grasp-dnssd-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 155: '...ng to RFC6335, the objective MUST uses...' RFC 2119 keyword, line 164: '...", the objective SHOULD use an objecti...' RFC 2119 keyword, line 189: '... MUST be a CBOR map and the reuseabl...' RFC 2119 keyword, line 208: '...useable elements SHOULD be defined to ...' RFC 2119 keyword, line 214: '...s that are a map MUST permit and reser...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Jul 1, 2018) is 2126 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) == Missing Reference: 'RFC8126' is mentioned on line 612, but not defined == Unused Reference: 'I-D.ietf-anima-grasp' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC6763' is defined on line 665, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-anima-autonomic-control-plane' is defined on line 671, but no explicit reference was found in the text == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-16 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ANIMA WG T. Eckert 3 Internet-Draft Huawei 4 Intended status: Standards Track Jul 1, 2018 5 Expires: January 2, 2019 7 DNS-SD compatible service discovery in GRASP 8 draft-eckert-anima-grasp-dnssd-01 10 Abstract 12 DNS Service Discovery (DNS-SD) defines the common framework for 13 applications to announce and discover services. This includes 14 service names, service instance names, common parameters for 15 selecting a service instance (weight, priority) as well as service 16 specific parameters. 18 GRASP is intended to also be used for service discovery. Reinventing 19 service discovery for GRASP with a similar set of fetures would 20 result in duplication of work. Therefore, this document defines how 21 to use GRASP to announce and discover services in a way that inherits 22 DNS-SD features and also tries to be compatible in spirit as much as 23 possibel while still maintaining the intended simplicity of GRASP. 25 The goal of this document is to permit defining service and their 26 parameters once and then use that in GRASP, mDNS and (unicast) DNS. 27 Future work can also define DNS-SD <-> GRASP gateway functions. 29 In support of service discovery, this document also defines name 30 discovery and schemes for reuseable elements in GRASP objectives 31 which are designed to be extensible so that future work that 32 identifies elements required across multiple objectives do not need 33 to define a scheme how to do this. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 2, 2019. 51 Copyright Notice 53 Copyright (c) 2018 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. Specification (Normative) . . . . . . . . . . . . . . . . . . 4 70 2.1. Service and Name Objectives . . . . . . . . . . . . . . . 4 71 2.2. Objective Value Reuseable Elements Structure . . . . . . 4 72 2.3. Reuseable Elements . . . . . . . . . . . . . . . . . . . 6 73 2.3.1. Sender Loop Count . . . . . . . . . . . . . . . . . . 6 74 2.3.2. Service Element . . . . . . . . . . . . . . . . . . . 6 75 2.3.3. Name Element . . . . . . . . . . . . . . . . . . . . 9 76 3. Explanations (Informative) . . . . . . . . . . . . . . . . . 11 77 3.1. Using GRASP service announcements . . . . . . . . . . . . 11 78 3.2. Further comparison with DNS-SD . . . . . . . . . . . . . 13 79 3.3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 13 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 83 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 15 84 7.1. 01 - . . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 7.2. 00 - Initial version . . . . . . . . . . . . . . . . . . 15 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 88 8.2. Informative References . . . . . . . . . . . . . . . . . 15 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Overview 93 DNS Service Discovery (DNS-SD) defines the common framework for 94 applications to announce and discover services. This includes 95 service names, service instance names, common parameters for 96 selecting a service instance (weight, priority) as well as service 97 specific parameters. 99 GRASP is intended to also be used for service discovery. Reinventing 100 service discovery for GRASP with a similar set of fetures would 101 result in duplication of work. Therefore, this document defines how 102 to use GRASP to announce and discover services in a way that inherits 103 DNS-SD features and also tries to be compatible in spirit as much as 104 possibel while still maintaining the intended simplicity of GRASP. 106 The goal of this document is to permit defining service and their 107 parameters once and then use that in GRASP, mDNS and (unicast) DNS. 108 Future work can also define DNS-SD <-> GRASP gateway functions. 110 GRASP exists as so-called GRASP-Domains, which are networks across 111 which GRASP is run. This document primarily defines how to perform 112 service discovery across such a domain leveraging GRASPs options to 113 perform unsolicited flooding of announcements or flooding of requests 114 and finding the closest service instances. The initial use case of 115 this document is to support what in DNS-SD is done via mDNS but in 116 larger networks - GRASP-Domains. Beside the efficient flooding, 117 GRASP provides reliability and security (depending on the so called 118 substrate used by GRASP, such as the autonomic control plane - ACP). 119 Providing compatibility with existing mDNS service announcer or 120 clients is possible, but not described in this version of the 121 document. 123 The encoding of information choosen in this document does not try to 124 use GRASP solely as a transport layer, but to also leverage the CBOR 125 structure of GRASP messages to natively encode the message elements 126 required for services in a way that is most simple - instead of using 127 GRASP only as e.g.: an encapsulation of otherwise unchanged DNS 128 message encodings. This is done to minimize the amount of coding 129 required (and not require any DNS code unless future gateway 130 functions are requireed), to increase the simplicity, minimize the 131 amount of data on the wire and allow easier extensibility. On the 132 downside, the mechanisms provided here do not cover the whole slew of 133 possible options of DNS/DNS-SD, but instead only those deemed to be 134 required. Others can be added later. 136 In support of service discovery, this document also defines name 137 discovery and schemes for reuseable elements in GRASP objectives 138 which are designed to be extensible so that future work that 139 identifies elements required across multiple objectives do not need 140 to define a scheme how to do this. 142 2. Specification (Normative) 144 2.1. Service and Name Objectives 146 Unsolicited, flooded announcements (M_FLOOD) in GRASP and solicited 147 flooded discovery (M_DISCOVERY) operate on the unit of GRASP 148 objective-names. Therefore a scheme is required to indicate services 149 via objective-names. Note: future work may wants to reuse the 150 encodings related to services (defined below in this document) inside 151 other (multicast or unicast only) objective exchanges, in which case 152 the service names are not impacted. 154 When an objective is meant to be solely about a service name as 155 defined and registered according to RFC6335, the objective MUST uses 156 an objective-name of SRV.. This naming scheme allows 157 to avoid creating duplicate and potentially inconsistent registration 158 of names for those objectives vs. registrations done for example for 159 DNS-SD. The primary use case for this naming scheme are therefore 160 service names that are intended to be used in both DNS-SD and GRASP. 162 When an objective is meant announcement and discovery of a DNS 163 compatible such as "www-internal" in "www- 164 internal.example.com", the objective SHOULD use an objective-name of 165 NAME.. See Section 2.3.3for more details. 167 See Section 5 for the detailled IANA asks relating to these 168 definitions. 170 2.2. Objective Value Reuseable Elements Structure 172 Because service discovery, as explained in the prior section, needs 173 to utilize different objectives, it requires cross-objective 174 standardized encoding of the elements of services. GRASP did not 175 define standardized message elements for the message body (called 176 "objective-value") of GRASP messages. Therefore, this document 177 introduces such a feature. 179 [RFC-editor: please remove all occurances of XXXX in rfcXXXX with the 180 RFC number assigned to this document and remove this edit note.] 181 objective-value /= { 1*elements } 182 elements //= ( @rfcXXXX: { 1*relement } ) 184 relement = ( relement-codepoint => relement-value ) 185 relement-codepoint = uint 186 relement-value = any 188 If an objective wants to use reuseable elements, the objective-value 189 MUST be a CBOR map and the reuseable elements are found under the key 190 "@rfcXXXX". Objectives that do not want reuseable elements as 191 defined here can use any objective-value format including a CBOR map, 192 but they can not use the "@rfcXXXX" key if they use a map. This 193 approach was choosen as the hopefully least intrusive mechanism given 194 how by nature all of "objective-value" is meant to be defined by 195 individual objective definitions. 197 The value of "@rfcXXXX" is a map of reuseable elements. Each 198 relement has an IANA registered element-name and codepoint (see 199 Section 5). The element-name is for documentation purposes only, 200 CBOR encodings only use the numeric codepoint for encoding efficiency 201 to minimize the risk for this solution to not be applicable to low- 202 bitrate neworks such as in IoT. 204 Format and semantic of the relement-value is determined by the 205 specification of the reuseable element as is the fact whether more 206 than one instances of the same reuseable element are permitted. 208 Reuseable elements SHOULD be defined to be extensible. The methods 209 used depend on the complexity of the element and the likely need to 210 extend/modify the element with backward or non-backward compatible 211 information. The following is a set of initial options to choose 212 from: 214 Element values that are a map MUST permit and reserve key value 0 215 (numerical) for private extensions of the element defined by the 216 individual objective. 218 Element values that are a map MUST NOT use bareword key values 219 starting with a "_". These too are for private extensions defined by 220 the individual objective. 222 Element values SHOULD be defined so that additional keys in maps and 223 additional elements at the end of arrays can be ignored by prior 224 versions of the definition. Whenever a newer definition is made for 225 an element where this rule is violated, the element SHOULD be changed 226 in a way for older version recipients to recognize that it is not 227 compatible with it. 229 One method to indicate compatibility is a traditional version 230 ".". Within the same version number, 231 increasing version numbers must be backward compatible. 232 Different version numbers are not expected to be compatible 233 with each other. If they are, then this can be indicated by 234 including multiple version numbers. 236 A compressed form of version compatibility information is the use of 237 a simple bitmask element where each bit indicates a version that the 238 represented data is compatible with. 240 2.3. Reuseable Elements 242 2.3.1. Sender Loop Count 244 relement-codepoint //= ( &(sender-loop-count:1) => 1..255 ) 246 Sender-loop-count is set by the sender of an objective message to the 247 same value as the loop-count of the message. On receipt, distance = 248 ( sender-loop-count - loop-count ) is the distance of the sender from 249 the receiver in hops. This element can be used for informational 250 purposes in M_FLOOD and M_DISCOVERY messages and may be required to 251 be used in these messages by the specification of other elements 252 (such as the service element described below). This element MUST 253 occur at most once. If a receiver expects to use the distance but 254 sender-loop-count was not announced, then distance SHOULD be assumed 255 to be 255 by the receiver. 257 2.3.2. Service Element 259 The srv-element (service element) is a reuseable element to request 260 or announce a service instance or to request and list service 261 instance names. 263 relement-codepoint //= ( &(srv-element:2) => context-element ) 265 context-element = { 266 ?( &(private:0) => any), 267 ?( &(msg-type:1 => msg-type), 268 ?( &(service:2) => tstr), 269 *( &(instance:3) => tstr), 270 ?( &(domain:4) => tstr), 271 ?( &(priority:5) => 0..65535 ), 272 ?( &(weight:6) => 0..65535 ), 273 *( &(kvpairs:7) => { *(tstr: any) }, 274 ?( &(range:8) => 0..255 ), 275 *( &(clocator:9) => clocator), 276 } 277 clocator = [ context, locator-option ] 278 context = cstr 279 locator-option = ; from GRASP 281 msg-type = &( describe: 0, describe-request:1, 282 enumerate:2, enumerate-request:3 ) 284 Service: A service name registered according to RFC6335. If it is 285 not present, then objective-name MUST be SRV. where 286 is the service-name. 288 Instance: The of a DNS-SD Service Instance Name ( 289 . . ). It is optional, see 290 Section 3.2. 292 Domain: The equivalent of the field of a DNS-SD Service 293 Instance Name. If domain is not present, this is equivalent to 294 ".local" in DNS (as introduced by mDNS) and implies the unnamed 295 "local" domain, which is the GRASP domain across which the message 296 is transmitted. 298 Priority, Weight: Service Instance selection criteria as defined in 299 RFC2782. If either one is not present, its value defaults to 0. 301 Kvpairs: Map of key/value pairs that are service parameters in the 302 same format as the key/value pairs in TXT field(s) of DNS-SD TXT 303 records as defined in RFC6763, section 6.3. 305 Range: Allows to flexibly combine distance and priority/weight based 306 service selection according to the definition of distance in 307 Section 2.3.1. 309 If min-distance is the distance of the closest service announcer, 310 and min-range the range announced by it, then the recipient MUST 311 consider the priority/weight of all service announcers that are 312 not further away than (min-distance + min-range). If not 313 included, range defaults to 255. 315 If range is announced, the sender-loop-count element MUST also be 316 announced. 318 Clocator: The "contextual locator" allows to indicate zero or more 319 locators for the indicated service instance. The context element 320 indicates in which context the locator-option is to be resolved. 321 The reserved context value of "" (empty string) indicates the 322 GRASP domain used, aka: the "local" context in which the service 323 announcement is made. The reserved context value of "0" indicates 324 the default routing context of the announcing node. This is often 325 called "global table", "VRF 0" or "default VRF" on nodes using the 326 "VRF" abtraction. Any other value is a string specifying a 327 context such as another VRF. 329 The mechanism by which originator and recipient of the srv-element 330 agree on common naming for contexts is outside the scope of this 331 specification. The context therefore allows to indicate locators 332 both for the context through which the GRASP message distributed 333 the srv-element (GRASP domain) as well as that for other contexts. 334 Assume the GRASP domain is the ACP, then clocators in ACP would 335 have a context of "", clocators in the global routing table (part 336 of the data-plane) a context of "0", and clocators on other VRFs 337 (also part of data-plane) a clocator that is their sring name. 339 If no locators are indicated, then the locator of the service(s) 340 is the optional locator-option of the GRASP message in which the 341 objective is contained meant to be used for the service(s) 342 indicated and the clocator implied is "". 344 If locator(s) are indicated, the messages location-option must be 345 ignored for the service (but may be necessary to be present for 346 other purposes of the objective). 348 Msg-type Type (aka: intention) of the srv-element. If not present, 349 it is assumed to be "describe". 351 Describe: Describes one service instance. At least one clocator is 352 required for a positive response, all other fields are permitted, 353 but optional. "Describe" is used in M_FLOOD for unsolicited 354 announcements of services (flooded), in M_RESPONSE messages for 355 solicited announcements of a service and in M_NEGOTIATE for 356 negotiated announcements (both unicasted). If clocator is not 357 included, then all fields except service and instance (and msg- 358 type and private) must not be included and the srv-element 359 provides a negative reply: No information about this service/ 360 service instance. This is only permitted in unicasted "describe" 361 messages. 363 Describe-request: Request for a "describe" reply. It is used in 364 M_DISCOVERY (flooded) for solicited discovery of services or in 365 M_REQ_SYN (unicasted) for negotiated discovery of service 366 instance(s). In "describe-request", only service is mandatory 367 (but can be provided via the objective-name field of the message), 368 and domain is optional. "Instance" is optional. If provided, 369 then the recipient is asked to provide information about the named 370 instance only. All other fields of srv-element are to be ignored 371 by the receiver in this specification, but a semantic for setting 372 them may be introduced in followup work, specifically to filter 373 replies by the indiciated fields. 375 "Describe-request" without instance MAY be answered by "Enumerate" 376 (see below) if the responder has so many instances that it thinks 377 the initiator should rather first select one or fewer instances 378 and ask for their description. The sender of te "Describe- 379 request" MUST be prepared to accept that answer and as necessary 380 follow up with "Describe-request" with the instance names of 381 interest. 383 Enumerate: Used in the same GRASP messages as "describe", but 384 instead of providing information about one service instance, it is 385 listing service instance names. The purpose of enumerate is the 386 same as browsing a service in DNS-SD. It would be followed by 387 some human or automated selection of one or more instances and 388 then a "describe" M_REQ_SYN request for those instances sent to 389 the source of the "enumerate" to learn about the locators and 390 other parameters of the service instances. 392 In this specification, all fields other than service, instance and 393 domain (and msg-type and private) must be unset in "enumerate". 395 Enumerate-request: Requests an "enumerate" reply. It is used in the 396 same way as "Describe-request" except that instance would usually 397 not be set (because in that case it is more useful to send a 398 "Describe-request"). 400 2.3.3. Name Element 402 The NAME, elements is meant to provide basic name resolution 403 comparable to mDNS name resolution for GRASP domains where this is 404 desirable and no better name resolution exist - for example in the 405 ACP where there is no requirement for DNS. 407 Because the GRASP service lookup (unlike) DNS does not mandate that 408 nodes have names (not even service instance names), the use of names 409 is primarily meant to support legacy software. New designs should 410 instead look up only services and service instance names, and nodes 411 should announce their names as service instance names for the 412 services they offer: 414 For example consider a GRASP (ACP) domain of "example.com". The node 415 providing some "www" service could have a name "www-internal" which 416 means GRASP objective NAME.www-internal, that objective value would 417 include primarily the nodes IP address(es) and the port number for 418 the www service would have to be guessed (80). Better, the node 419 would announce GRASP objective SRV.www and the objective value would 420 include the service instance name www-internal and the (TCP) port 421 information (80 or a non-default port). 423 relement-codepoint //= ( &(name-element:3) => context-element ) 425 context-element //= { 426 *( &name:10) => tstr), 427 } 429 ipv6-address-option = [O_IPv4_ADDRESS, ipv6-address] 430 ipv4-address-option = [O_IPv6_ADDRESS, ipv6-address] 431 locator-option /= ipv4-address-option 432 locator-option /= ipv6-address-option 434 Name information is carried in the name-element relement. It is a 435 context-element like the one used for srv-element except that it adds 436 the name component and that it does not permit the service and 437 instance components and that it allows only describe and describe- 438 request values in the msg-type. Clocators MUST use the ipv6-address- 439 option or ipv4-address-option in the locator-option component. 441 TBD: Unclear if/how we should best formalize the differences in the 442 context element permitted information between services and names. 443 The above is quite informal. 445 Priority, weight, kvpairs, range (and of course private) MAY be used 446 in describe messages to support multiple instances of the same name, 447 as used for name anycast/prioritycast. 449 Nodes may have multiple names. These can be listed in the name 450 component. If a nodes names have the notion of a primary name and 451 secondary names then the primary name should be the first in the list 452 of names. In DNS-SD, the name pointed to by CNAME RRs can be 453 considered to be the primary name. A describe-request for a non- 454 primary name SHOULD return in the list of names the requested name 455 and the primary name. 457 Note that there is no reverse lookup defined in this version of the 458 document (no lookup from IP address to name). 460 3. Explanations (Informative) 462 3.1. Using GRASP service announcements 464 TBD: This section contains a range of details that should become 465 normative in later versions. 467 This section provides a step by step walk-through of how to use GRASP 468 service announcements and compares it to DNS-SD. 470 The most simple method to use GRASP service discovery is to select 471 (and if still neessary, register) a and start one or 472 more agents (e.g.: ASAs) announcing their service instance(s) via 473 GRASP. At minimum, an agent should periodically (default 60 seconds) 474 announce the service instance via GRASP M_FLOOD messages as an 475 objective SRV. with a srv-element and a sender-loop- 476 count element (default 255). The ttl of the GRASP message should be 477 3.5 times the announcement period, e.g.: 210000 msec. 479 Consumers of the service will use GRASP to learn of the service 480 instances and select one. This approach is most similar to the use 481 of DNS-SD with mDNS except that the scope of the announcement is a 482 whole GRASP domain (such as the ACP) as opposed to a single IP subnet 483 in mDNS and that mDNS primarily relies on request & reply but in its 484 standard not on periodic unsolicited announcements. We describe here 485 the unsolicited flooding option via M_FLOOD first because it is 486 recommended for services with a dense population of service consumers 487 and it is most simple to describe. 489 On the service announcer, the parameters priority, weight and range 490 of the service instance can be selected from intent or configuration 491 - or left at default. The default range 255 will result in selection 492 of a random target of the service like in DNS-SD. Setting priority/ 493 weight allows to prioritize and weigh the selection as in DNS-SD. 494 Setting range to 0 allows to select the closest target, priority/ 495 weight are only compared between targets of the same shortest 496 distance. Distance based options are not available in DNS-SD because 497 it does not expect that network distance is available to arbitrary 498 DNS-SD client. It is available to GRASP clients though. Using 0 < 499 range < 255 allows for a hybrid priority/weight and distance based 500 service selection (e.g.: Select the highest priority instance within 501 a range of 5 hops). 503 If the service is a non-GRASP service, then the result of the service 504 discovery has to be a transport locator to which the client can open 505 a connection and talk the protocol implied by the service. This 506 transport locator(s) have to be put into the clocator parameter. The 507 context of the clocator would normally be "", aka: the transport 508 locator is in the IP reachability associated with the GRASP domain 509 (e.g.: IPv6 of the ACP for ACP GRASP domain). 511 If an ACP service is announced via ACP GRASP, then the locator(s) can 512 be O_IPv6_LOCATOR or O_FQDN_LOCATOR. The O_IPv6_LOCATOR is used if 513 the service is defined to be available via some transport layer port 514 (TCP, UDP or other). The determination of the actual transport 515 connection to be used is the same as in DNS-SD: If the transport 516 protocol is not TCP or UDP, it has to be implied by the specification 517 of or can be detailled in kvpairs which carries the 518 same information as DNS-TXT TXT RRs of the service. Alternatively, 519 the transport-proto field of the locator can contain any valid IP 520 protocol directly (TBD), which is not possible in DNS-SD. 522 Like DNS-SD, service discovery via GRASP does not require allocation 523 and use of well-known ports for services. Unlike DNS-SD, there is no 524 need in GRASP to define service instance names or target names. In 525 DNS SD, PTR RRs resolve from a service name to a set of service 526 instance named. SRV and TXT RRs resolve from service instance names 527 to service instance parameters including the target. A target is the 528 DNS host name of the service instance. It gets resolved via A/AAAA 529 RRs to IPv4/IPv6 addresses of the targ. In GRASP service discovery, 530 host names are not used. Service instance names are optional too. 531 Service instance names are useful for human diagnostics and human 532 selection of service instances. In fully automated environments, 533 they can be are less important. For diagnostic purposes, it is 534 recommended to give service instances service instance names in GRASP 535 service announcements. 537 A locator with O_URI_LOCATOR type can be used in GRASP to indicate a 538 URI for the transport method for a service instance. If the URI 539 includes a host part, care must be taken to use only IP addresses in 540 the host part if the context of the GRASP domain does not support 541 host name resolution - such as the ACP - or to use the GRASP name 542 resolution mechanisms described elsewhere in this document. And that 543 the addresses indicated are also reachable in the GRASP domain. For 544 example, in service announcemenets across a DULL GRASP domain, only 545 the IPv6 link-local addresses on that subnet must be used (this 546 applies equally when using the O_IPv6_LOCATOR). 548 Instead of using M_FLOOD to periodically announce service instances, 549 M_DISCOVERY can be used to actively query for service instances. The 550 msg-type type must then be "describe-request". Because no periodic 551 flooding is necessary, this solution is more lightweight for the 552 network when the number of requesting clients is small. Note though 553 that the M_DISCOVERY will terminate as soon as a provider of the 554 objective is found, so the service instances found will be based on 555 distance and therefore selection of instance by priority and weight 556 will not work equally well as with M_FLOOD. Consider for example a 557 central service instance in the NOC that should always be used (for 558 example for centralized operational diagnostics) unless the WAN 559 connection is broken, in which case distributed backup service 560 instances should be used. With the current logic of M_DISCOVERY this 561 is not possible. 563 3.2. Further comparison with DNS-SD 565 Neither the GRASP SRV.* objective-name, the service name nor any 566 other parameter explicitly indicate the second label "_tcp" or "_udp" 567 of DNS-SD entries. DNS-SD, RFC6763 explains how this is an 568 unnecessary, historic artefact. 570 This version of the document does not define an equivalent to "_sub" 571 structuring of service enumeration. 573 This version of the document does not define mechanisms for reverse 574 resolution of arbitrary services: An inquirer may unicast M_SYNC_REC 575 to a node with a series of objectives with specific service names of 576 interest and describe-request, but there is no indication of "ANY" 577 service. 579 3.3. Open Issues 581 TBD: Examine limitations mentioned in "in this version of the text/ 582 document". 584 TBD: The GRASP specification does currently only permit TCP and UDP 585 for the transport-proto element. This draft should expand the GRASP 586 definitions to permit any valid IP protocol. We just need to decide 587 whether this should only apply to the locator in the srv element or 588 also retroative to the locator-option in GRASP messages (maybe not 589 there ?). 591 TBD: A fitting CBOR representation for a kvpair key without value 592 needs to be specified so that it can be distinguished from an empty 593 value as outlined in RFC6763 section 6.4. 595 TBD: In this version, every service/service-instance is an element by 596 itself. Future versions of this document may add more encoding 597 options to allow more compact encoding of recurring fields. 599 TBD: Is there a way in CDDL to formally define the string names of 600 the relement-codepoint's ? 602 4. Security Considerations 604 TBD. 606 5. IANA Considerations 608 This document requests a new "GRASP Objective Value Standard 609 Elements" table in the GRASP Parameter Registrar. The values in this 610 table are names and a unique numerical value assigned to each name. 611 Future values MUST be assigned using the RFC Required policy defined 612 by [RFC8126]. The numerical value is simply to be assigned 613 sequentially. The following initial values are assigned by this 614 document: 616 sender-loop-count 1 [defined in rfcXXXX] 618 srv-element 2 [defined in rfcXXXX] 620 name-element 3 [defined in rfcXXXX] 622 This document updates the handling of the "GRASP Objective Names" 623 Table introduced in the GRASP IANA considerations as follows: 625 Assignments for objective-names of the form "SRV." and 626 "NAME." are special. 628 Assignment of "SRV." can only be requested if is also a 629 registered service-name according to RFC6335. The specification 630 required for registration of a "GRASP Objective Name" MUST declare 631 that the intended use of the objective name in GRASP is intended to 632 be compatible with the indended use of the registered service name. 634 Registration of "SRV." in the "GRASP Objective Name" table is 635 optional, but recommended for all new service-names that are meant to 636 be used with GRASP. Non-registration can for example happen with 637 DNS-SD <-> GRASP gateways that inject pre-existing service-names into 638 GRASP. Note that according to the GRASP RFC, registration is 639 mandatory, so this exemption for "SRV." is also an update to 640 that specification. 642 There MUST NOT be any assignment for objective names of the form 643 "NAME.". These names are simply used by GRASP nodes without 644 registration (just like names in mDNS). 646 6. Acknowledgements 648 7. Change log [RFC Editor: Please remove] 650 7.1. 01 - 652 Only refreshing, no changes since -00. 654 7.2. 00 - Initial version 656 8. References 658 8.1. Normative References 660 [I-D.ietf-anima-grasp] 661 Bormann, C., Carpenter, B., and B. Liu, "A Generic 662 Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- 663 grasp-15 (work in progress), July 2017. 665 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 666 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 667 . 669 8.2. Informative References 671 [I-D.ietf-anima-autonomic-control-plane] 672 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 673 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 674 plane-16 (work in progress), June 2018. 676 Author's Address 677 Toerless Eckert 678 Futurewei Technologies Inc. 679 2330 Central Expy 680 Santa Clara 95050 681 USA 683 Email: tte+ietf@cs.fau.de