Re: [Srcomp] Draft Minutes Jan 27 2021

["Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>]

Ron, thx indeed my view is to split and 2nd requirement I question. Why and on what basis should we exclude anything that uses other ipv6 semantics that are available in IETF. So in my view any solution that is based on the IPv6 semantics, that is ipv6 Header, extension header, next header, etc should all be possible and we have other criteria to debate the efficiency of them.

So is essence I am questioning the 2nd requirement and I would leave this out of the req doc.

From: Ron Bonica <[e-mail]>
Date: Monday, 1 February 2021 at 21:47
To: "Henderickx, Wim (Nokia - BE/Antwerp)" <[e-mail]>, Ron Bonica <rbonica=[e-mail]>, "[e-mail]" <[e-mail]>, Darren Dukes <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: [Srcomp] Draft Minutes Jan 27 2021

Folks,

Wim’s comment suggests that we are actually looking at two distinct requirements. We seem to have agreement on one while we are debating the other. So, let’s separate them into two requirements as follows:



Short Name: Preservation of non-routing information.

Description: The compression mechanism MUST preserve non-routing information in the IPv6 header chain.

Rationale: SRv6 ingress nodes encode non-routing information in the IPv6 header chain. This information can be encoded in the following fields:

- Hop Count
- DSCP bits
- ECN bits
- Flow label
- HBH Options Extension header
- Fragment Extension header
- Authentication Extension header
- Encrypted Security Payload Extension header
- Destination Options Extension header

Some of these fields are mutable (e.g., Hop Count) while others are immutable (e.g., Fragment Extension Header).

Some of these fields contain information that is required by every node along a packet’s delivery path (e.g., Hop Count). Others contain information that is required only by the packet’s ultimate destination (e.g., Fragment Extension Header).

Therefore, the compression mechanism MUST NOT prevent this information from being delivered, in an IPv6 header chain,  to any node that needs it.

Metric: In a  compliant proposal, the SR ingress node encapsulates its payload (e.g.., Ethernet, IP, TCP) in an IPv6 header. The SRv6 header contains both routing and non-routing information. The IPv6 header and the information that it contains persists until it is removed by either by the SR egress node or a penultimate node.


 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 not require any node along the packet’s forwarding path to support any other forwarding plane (e.g., IPv4, MPLS)








Juniper Business Use Only
From: Srcomp <[e-mail]> On Behalf Of Henderickx, Wim (Nokia - BE/Antwerp)
Sent: Saturday, January 30, 2021 1:40 AM
To: Ron Bonica <rbonica=[e-mail]>; [e-mail]; Darren Dukes (ddukes) <[e-mail]>; srcomp <[e-mail]>
Subject: Re: [Srcomp] Draft Minutes Jan 27 2021

[External Email. Be cautious of content]

I have been thinking a bit on this and here is my current thought.

Why would we limit solutions that use other things like ipv6 and extension headers?
I do agree with the fact we should not loose information along the path, like DSCP, ECN, etc
But what is the motivation to be strict ? I don’t believe we can make this call, hence I would make this less strict and focus on the loss of information along the path here.
The solution should be compliant to ipv6 symantics.


From: Srcomp <[e-mail]<mailto:[e-mail]>> on behalf of Ron Bonica <rbonica=[e-mail]<mailto:rbonica=[e-mail]>>
Date: Friday, 29 January 2021 at 18:24
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Darren Dukes <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Srcomp] Draft Minutes Jan 27 2021

Hi Chongfeng,

Like every other requirement in the document, this requirement imposes constraints upon the compression mechanism. Namely,


  *   The compression mechanism MUST be encoded in the IPv6 forwarding plane (i.e., an IPv6 header or an extension header)
  *   The IPv6 header or extension header in which it is encoded MUST be imposed at the SR ingress node and maintained until the SR egress or penultimate hop.

                                                                                         Ron



Juniper Business Use Only
From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Friday, January 29, 2021 7:59 AM
To: Ron Bonica <[e-mail]<mailto:[e-mail]>>; Darren Dukes (ddukes) <[e-mail]<mailto:[e-mail]>>; srcomp <[e-mail]<mailto:[e-mail]>>
Subject: Re: Re: [Srcomp] Draft Minutes Jan 27 2021

[External Email. Be cautious of content]

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<mailto:rbonica=[e-mail]>
Date: 2021-01-28 03:18
To: Darren Dukes (ddukes)<mailto:ddukes=[e-mail]>; [e-mail]<mailto:[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:


  1.  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.


  1.  The compression mechanism is either:

  1.  Encoded in the IPv6 header

b.       Encoded in an IPv6 extension header that follows the IPv6 header.

c.       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:


  1.  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.


  1.  The compression mechanism is either:

  1.  Encoded in the IPv6 header

e.       Encoded in an IPv6 extension header that follows the IPv6 header.

f.        Encode in both.





Juniper Business Use Only
From: Srcomp <[e-mail]<mailto:[e-mail]>> On Behalf Of Darren Dukes (ddukes)
Sent: Wednesday, January 27, 2021 11:53 AM
To: [e-mail]<mailto:[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.