1 / 6

Experimental/private join attributes

This document analyzes the current landscape of join attribute registries, specifically focusing on the allocation of experimental and private code points. It highlights the strict allocation based on IETF review and raises concerns about supporting attributes lacking sufficient review. The need for a registry to prevent conflicts and the idea of making code point allocation more liberal is discussed. Proposed changes include allowing private code points and expanding the type space, along with the ongoing draft that suggests new experimental attribute code points.

avram-johnston
Télécharger la présentation

Experimental/private join attributes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Experimental/private join attributes

  2. Current join attribute registry • 64 code points, used 4 so far • Explicit RPF and LISP join attributes use 3 more. • Allocation based on IETF review • RFC needed (I believe), but may get early allocation when document is stable • Fairly strict, no code points available for experiments or private use • Make it more liberal? • Concerns with supporting attributes that have not had sufficient review?

  3. Experimental code points? • What if someone wants to experiment with a new implementation/protocol requiring a new code point? • RFC 3692 recommends having at least one value for experiments • For experiments only, should not be used in products. Different experiments are likely to use the same value, hence not for general deployments. • Should be ignored by default

  4. Private code points? • Set aside some attributes for more private use? • Less strict, e.g. require documentation? • Registry needed to avoid conflicts? • Expand the type space? • Or do we believe that attributes should be reviewed? • If we allow private code points, would anyone ask for code points that require review?

  5. Encoded-Source Address Encoding Type Field registry • 256 values • 0 is native, 1 for join attributes. • Allocation based on IETF review • Fairly strict, any need for experimental or private use?

  6. draft-atwood-pim-reserve-exp-00 • New draft submitted this Monday • Proposes 2 experimental attribute code points and 4 experimental encondig types • Is this what we want?

More Related