Subject: [Srcomp] Draft meeting minutes: 2/24/2021

From: Ron Bonica <[email-masked]>
Date: Wed, 24 Feb 2021 15:59:54 +0000

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

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

  *   Create an appendix in the requirements document
     *   Title: Disputed Requirements
     *   Copy the IPv6-based requirement from the backlog to the Disputed Requirements. Text provided below.
  *   Weiqiang to send mail to the WG asking whether the Point-to-multipoint requirement is in scope. Text provided below.
     *   If so, copy the Point-to-multipoint requirement to the main body of the requirements document

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

  *   The group discussed the requirement not to violate any PS/BCP documents. Darren asked to defer discussion until he could formulate alternative text.
  *   The group discussed the parsing requirement (text provided below). There was general agreement except for the final sentence about debugging.
  *   The group discussed the addressing requirements and realized that there are two possible interpretations of the current text.

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

  *   Weiqiang to send mail to the WG asking whether the Point-to-multipoint requirement is in scope.
  *   Darren to propose alternative text for the PS/BCP requirement
  *   Ron to refine the text for the addressing requirement
  *   All to review and comment on the use-cases that Darren proposed for the analysis document

REFERENCED REQUIREMENTS
------------------------------------------

Short Name: IPv6-based

   Description: The compression mechanism requires every node along the
   packet's delivery path to be IPv6-capable.  It MUST not require any
   node along the packet's forwarding path to support any other
   forwarding plane (e.g., IPv4, MPLS)

   Rational: According to RFC 8402, SRv6 is an instantiation of the SR
   Architecture over the IPv6 data plane.

   Metric: A compliant solution requires every node along the packet's
   delivery path to be IPv6-capable.  It does not require any node
   along the packet's forwarding path to support any other forwarding
   plane (e.g., IPv4, MPLS)

Short Name: Point-to-Multipoint

   Description: The compression mechanism SHOULD support point-to-
   multipoint SR paths.

   Rationale: Many VPN services require point-to-multipoint SR paths.

   Metric: A compliant proposal can encode a multicast address in the
   ultimate segment of the segment list.

Short Name: Parsing

   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 consumer of the compressed SID list can locate the active segment and the next segment correctly.
   In all foreseeable failure modes, it must be possible to identify (i.e., debug) the source of the failure.

Juniper Business Use Only