Provisioning and Routing Use Cases for Data Registry System
90 likes | 128 Vues
Explore the use cases, changes, and proposed updates for provisioning Session Establishment Data (SED) and routing in the data registry system. Discuss identity operations, peering, and future steps.
Provisioning and Routing Use Cases for Data Registry System
E N D
Presentation Transcript
Use Cases & Requirements IETF#77, Anaheim, CA.
Introduction • The latest I-D revision can be found at: • http://tools.ietf.org/search/draft-ietf-drinks-usecases-requirements-01 • The design team has since discussed additional use cases, and changes to existing use cases (in -01) • This slide deck presents the existing set of use cases, some of the proposed changes, and a couple of new use cases • Additional use cases will be presented by other participants
Recap • Registry is the authoritative source for provisioned session establishment data (SED) and related information • Local Data Repository is the data store component of an addressing server that provides resolution responses • Registry is responsible for distributing SED and related information to the Local Data Repositories Registry 1. Provision SED 2. Distribute SED Local Data Repository Local Data Repository
Use Cases in -01 (1 of 2) • Process • Near-real-time provisioning • Deferred provisioning • Offline (batch) provisioning • Routing • Intra-network SED • Inter-network SED (direct and selective peering) • Support for aggregations (i.e., destination groups) • Indirect (transit) peering • Provisioning an authoritative name server • LUF-only provisioning • LUF + LRF provisioning
Use Cases in -01 (2 of 2) • Identity • Public Identity operations • TN range operations • Administration • Peering Offer/Acceptance • Moving SSP from one destination group to another • Number Portability • Need clarity around use cases
Comments & Questions (1 of 2) • A couple of use cases have been questioned since they introduce protocol complexity without illustrated benefits • #1: Aggregation of Data Recipients into a Data Recipient Group, for selective peering • This is only required when you want to modify a set of record routes that are shared by a large number of SSPs; do we expect this? • #2: Provisioning using effective date and time • This introduces complexities when a real-time operation changes the state that was prevalent when the deferred operation was requested
Comments & Questions (2 of 2) • A few new use cases have been proposed; only a couple are presented here • #1: Source based LUF response • SSP may wish to present a different target domain, based on the querying entity; for instance, different target domains for international and domestic querying entities • #2: Multiple target domains within a LUF-only response • e.g., Authoritative and non-authoritative target domains
(Proposed) Data Model ROUTING GROUP SED Record DATA RECIPIENT DESTINATION GROUP Public Identity TN Range RN
Next Steps • Discuss and accept/reject the proposed use cases ? • Re-check the requirements list? • Create a cross-reference of requirements against the protocol documents?