Re: [Srcomp] Draft Minutes Jan 27 2021

["[e-mail]" <[e-mail]>]

Hi, folks,
I remembered the DT mainly deal with how to reduce the length of the SID list in uncompressed approach, but the requirement item being discussed seems unrelated to this, is my understanding wrong?  :-)

Best regards
Chongfeng


 
From: Ron Bonica
Date: 2021-01-28 03:18
To: Darren Dukes (ddukes); [e-mail]
Subject: Re: [Srcomp] Draft Minutes Jan 27 2021
Folks,
 
May I propose the following update to reflect todays discussion:
 
Description: The compression mechanism must be IPv6-based. This means that:
 
The SR ingress node encapsulates its payload (e.g.., Ethernet, IP, TCP) in an IPv6 header. The IPv6 header persists until it is removed by either by the SR egress node or the penultimate node. 
 
The compression mechanism is either:
Encoded in the IPv6 header
Encoded in an IPv6 extension header that follows the IPv6 header.
Encode in both.
 
Rational: The SR ingress node determines  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
 
Non-routing information must not be lost. Premature removal of the IPv6 header may cause loss of non-routing information.
 
According to RFC 8402, SRv6 is an instantiation of the SR Architecture over the IPv6 data plane. The only elements of the IPv6 data plane are the IPv6 header and IPv6 extension headers. Therefore, an SRv6 compression mechanism must be encoded in either the IPv6 header or an IPv6 extension header.
 
Metric: A compliant proposal satisfies the following conditions:
 
The SR ingress node encapsulates its payload (e.g.., Ethernet, IP, TCP) in an IPv6 header. The IPv6 header persists until it is removed by either by the SR egress node or a penultimate node. 
 
The compression mechanism is either:
Encoded in the IPv6 header
Encoded in an IPv6 extension header that follows the IPv6 header.
Encode in both.
 
 
 
 
Juniper Business Use Only
From: Srcomp <[e-mail]> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, January 27, 2021 11:53 AM
To: [e-mail]
Subject: [Srcomp] Draft Minutes Jan 27 2021
 
[External Email. Be cautious of content]
 
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:
Review backlog document
Verify there are no missing requirements in the backlog
Send all such requirements to the list by Friday
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.  
The text below has been discussed in the call
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.
draft-filsfilscheng-spring-srv6-srh-comp-sl-enc
draft-decraene-spring-srv6-vlsid
draft-bonica-6man-comp-rtg-hdr
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.