Subject: [Srcomp] Draft meeting minutes: 3/06/2021

From: Ron Bonica <[email-masked]>
Date: Fri, 5 Mar 2021 14:56:19 +0000

Attendees: Weiqiang, Chongfeng, Ron, Cheng, Darren, Peng

RESOLVED
--------------

  *   Move the parsing  Requirement (provided below) to the appendix for disputed requirements
  *   Move the addressing requirement (provided below) to the main body of the document
  *   Synchronize the addressing document with the requirements document
     *   Create new sections in the analysis document that reflect new sections in the main body of the requirements document
     *   Create an appendix in the analysis document that reflects the appendix in the requirements document
  *   Post new version of the requirements document to the DT mailing list for 24 hour last call
     *   Silence will be interpreted as consent
  *   Post new version of the requirements document on Sunday
  *   The DT will not meet during IETF week

DISCUSSED
---------------

  *   All discussed items were resolved

ACTION ITEMS
---------------------

  *   Darren to post new version of the requirements document to the DT mailing list ASAP
  *   Darren to post a new version of the analysis document to the DT mailing list. Not so urgent because it will not be posted to the IETF draft repository this week.
  *   All to participate in 24 hour last call, ending on Sunday
  *   Weiqiang to post requirements draft to IETF draft repository
  *   Ron to provide a slide on CRH for the analysis deck
  *   PSF to provide a slide on UID for the analysis deck (this action item may be completed already)
  *   Chengli to contact Bruno regarding VSID slide for the analysis deck
  *
REFERENCED REQUIREMENTS
------------------------------------------

Short Name: Parsability

Description: The compression mechanism MUST be parsable. That is, the node that consumes the compressed SID list must be able to decode the active and next segment. Parsing information MAY be conveyed in either the forwarding or control plane.

Rationale: Failure to parse the compressed SID list leads to undesired behaviors.

Metric: In the nominal case the producer and consumer of the SID list agree on the active segment and next segment. In forseeable failure modes it is possible to determine why the producer and consumer don't agree.

Address Planning

Description: Network operators require addressing plan flexibility, The compression mechanism MUST support flexible IPv6 address planning, it MUST support deployment by using GUA from different address blocks.

Rationale: The address planning of the network may vary based on the addressing scheme of the operator, so the solution MUST support a flexible addressing scheme. Operators need to deploy the solution based on their own address planning.

Metric: The compression proposal supports locators drawn from different prefixes with the solutions analysis indicating efficiency.

Juniper Business Use Only