Subject: Re: [Srcomp] Draft Minutes Jan 27 2021

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Wed, 3 Feb 2021 11:47:29 +0000

As per the group action item below, two items were raised on the list:
DEBUGGING – it is in the backlog document
SCALE – it is in the working version of the draft
https://github.com/IETF-srcomp/drafts

Thanks
  Darren
On 2021-01-27, 11:53 AM, "Srcomp" <[email-masked]> wrote:

Attendees: Weiqiang, PSF, Cheng Li, Wim, Darren, Ron, Chongfeng

Minutes
·         Analysis document will have authors listed in alphabetical order by last name.
·         ACTION for team:
o    Review backlog document
o    Verify there are no missing requirements in the backlog
o    Send all such requirements to the list by Friday
o    Darren to add any to the backlog doc in git.
·         PS or BCP requirement to be added to draft.
·         IPv6 Based needs to be added to the draft.
o    The text below has been discussed in the call
o    ACTION: Team to discuss on the list (See two options below as discussed)
·         ACTION: Weiqiang to send proposals to SPRING WG and request additional proposals.
o    draft-filsfilscheng-spring-srv6-srh-comp-sl-enc
o    draft-decraene-spring-srv6-vlsid
o    draft-bonica-6man-comp-rtg-hdr
o    draft-mirsky-6man-unified-id-sr

Short Name: IPv6 Based (Original + edited in call)
Description: The compression mechanism must be IPv6-based. The SR ingress node encapsulates its payload (e.g.., Ethernet, IP, TCP) in an IPv6 header.

The compression mechanism is either:
- Encoded in the IPv6 header
- Encoded in an IPv6 extension header that follows the IPv6 header.
- Encode in both.
The IPv6 header persists until it is removed by either by the SR egress node or a penultimate node.  Once the IPv6 header is completely processed and removed, it cannot be re-added.

Rational: The SR ingress node calculates routing and non-routing information regarding the SR path. Non-routing information includes:
-              DSCP bits
-              ECN bits
-              Flow label
-              Fragmentation information
-              Authentication information
-              Destination Options
-              Hop Count
The SR ingress node encodes routing and non-routing information in the IPv6 header and its extensions. If the IPv6 header were removed along the SR path, non-routing information would be lost.
Also, transit nodes may update the ECN bits in the IPv6 header. If the IPv6 header were removed, the ECN bits would be lost.

Metric: Non-routing information (e.g., DSCP, ECN, Destination Options) must be delivered from the source node to the destination node. It must not be delivered to an upper-layer protocol for the purposes of including it in a new IPv6 header.

Short Name: IPv6 Based (Darren’s draft proposal)
Description: The compression mechanism must be IPv6-based (within an IPv6 header or extension header). The SR ingress node encapsulates its payload (e.g.., Ethernet, IP, TCP) in an IPv6 header. The compression mechanism MUST not lose non-routing information in the IPv6 header within the SR domain.

Rationale: The IPv6 header carries information within the SR domain, including; DSCP bits, ECN bits, Flow label, Fragmentation and Authentication information, Destination Options, Hop Count.  Losing this information can result in failures.

Metric: A proposal that can preserve non-routing information in the IPv6 header within the SR Domain satisfies this requirement.