Subject: [Srcomp] Comments on Section 2.2.2.1 (was RE: 2.2. Forwarding Efficiency)

From: Ron Bonica <[email-masked]>
Date: Tue, 25 May 2021 20:53:24 +0000

Darren,

The following are comments on Section 2.2.2.1:

  *   "Segment lists may contain transport, adjacency, service, binding
      or VPN segments."

     *   Maybe we should say "Segment list may contain transport segments (e.g., adjacency, binding, prefix) and VPN segments (e.g., END.DT4, END, DX4)
  *   "When processing a segment, all proposals process the IPv6 header and routing header, if present.
     *   However, the degree to which they process it varies. When a node encounters a CRH with Segments Left equal to zero, it skips over it. When a node encounters (__insert types here__) with segments left equal to 0, it examines the routing header to process flags, tags and TLVs.
  *   "The CRH routing header and CRH SIDs are not used when a single VPN segment is present in the segment list.  CRH proposes non-compressed SRv6 SID is used in the destination address of the outer IPv6 header."
     *   The CRH routing header and CRH SIDs are not used when a single VPN segment is present in the segment list.  CRH can encode VPN service information in either a classic SRv6 SID, found in the IPv6 Destination Address or in a TPF option found in the Destination Options header.
  *   "When the ultimate VPN segment is represented by a TPF header, the outer IPv6 header, CRH header and TPF header are processed at the ultimate segment endpoint."
     *   Not true when there is only one segment in the path and, therefore, the TPF is absent
     *   Even when it is true, the amount of CRH processing required is negligible. All you have to do is examine Segments Left, determine that its value is zero and skip over it.
  *   "CSID, VSID and UIDSR use [RFC8754] reduced behavior when a segment list can be expressed as a single destination address, resulting in only an outer IPv6 header present.
     *   The CRH also has a reduced mode
  *   "The 16-bit variant of CSID encodes 4 or fewer transport SIDs in a single CSID container."
     *   Unless functionality required in SRH flags, tags and TLVs are required
     *   Unless the addressing scheme doesn't support it
  *   "The 32-bit variants of CSID, VSID, and UIDSR global VPN SIDs are used to encode the VPN SID in a single segment.
     *   Do you really mean to say that CSID, VSID and UIDSR can use 16-bit transport SIDs and 32 bit VPN SIDs. If so, shouldn't we make the point that CRH-16 and TPF (32-bits) can also be used in the same packet?
  *   The tables are confusing to the point of being misleading
     *   What do the stars mean?
     *   We should break the tables in the following:
        *   16-bit Transport
        *   16-bit Egress PE
        *   32-bit Transport
        *   32-bit Egress PE
     *   In each of the tables, we should note scenarios where a single node has to process two SIDs, and therefore, process the same header twice.
     *   This analysis may make the tables large enough to be moved to an Appendix
  *   The conclusion should say that (__insert types here__) have been implemented and demonstrated to forward at similar and acceptable speeds. Therefore, the degree to which this analysis distinguishes between compression mechanisms may not be significant.

                                                                     Ron

Juniper Business Use Only
From: Srcomp <[email-masked]> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, May 24, 2021 10:18 PM
To: [email-masked]
Subject: [Srcomp] 2.2. Forwarding Efficiency

[External Email. Be cautious of content]

Here is the section 2.2 proposed text for review.

2.2.  Forwarding Efficiency

   The compression proposal SHOULD minimize the number of required
   hardware resources accessed to process a segment.

2.2.1.  Headers Parsed (PRS)

   Forwarding efficiency is calculated against the reference scenarios
   above, recording and summarizing the differences in header parsing
   for different SID types.

   o  Segment lists may contain transport, adjacency, service, binding
      or VPN segments.
   o  When processing a segment, all proposals process the IPv6 header
      and routing header, if present.
   o  CRH header parsing is as follows:

      *  The CRH routing header and CRH SIDs are not used when a single
         VPN segment is present in the segment list.  CRH proposes a
         non-compressed SRv6 SID is used in the destination address of
         the outer IPv6 header.
      *  With one or more transport segments, the CRH is always present.
         The outer IPv6 header and CRH are processed.
      *  When the ultimate VPN segment is represented by a TPF header,
         the outer IPv6 header, CRH header and TPF header are processed
         at the ultimate segment endpoint.
   o  CSID, VSID and UIDSR use [RFC8754] reduced behavior when a segment
      list can be expressed as a single destination address, resulting
      in only an outer IPv6 header present.
   o  The 16-bit variant of CSID encodes 4 or fewer transport SIDs in a
      single CSID container.
   o  The 32-bit variants of CSID, VSID, and UIDSR global VPN SIDs are
      used to encode the VPN SID in a single segment.

        +-------------------+------+-----+---------+------+-------+
        | 16-bit            | CSID | CRH | CRH+TPF | VSID | UIDSR |
        +-------------------+------+-----+---------+------+-------+
        | PRS(48B.0T).V)    | *1*  | *1* | *1*     | *1*  | *1*   |
        | PRS(48B.1-4T).V)  | *1*  | 2   | 2 or 3  | 2    | 2     |
        | PRS(48B.5-15T).V) | *2*  | *2* | 2 or 3  | *2*  | *2*   |
        |                   |      |     |         |      |       |
        +-------------------+------+-----+---------+------+-------+

             Table 3: Headers parsed, 16-bit SIDs, 48B.0-15T.V

      +----------------------+------+-----+---------+------+-------+
     | 32-bit               | CSID | CRH | CRH+TPF | VSID | UIDSR |
      +----------------------+------+-----+---------+------+-------+
      | PRS(48B.0T.V) at the | *1*  | *1* | *1*     | *1*  | *1*   |
      | PRS(48B.1-15T.V)     | *2*  | *2* | 2 or 3  | *2*  | *2*   |
      +----------------------+------+-----+---------+------+-------+

             Table 4: Headers parsed, 32-bit SIDs, 48B.0-15T.V

   Conclusion: CSID requires less header parsing than other proposals.

2.2.2.  Lookups Performed (LKU)

   Some proposals require a different number of lookups per packet,
   depending on the SID type and segment list.

   A strict TE path is considered with a 48B.1..15T.V segment lists,
   where each transport segment is an adjacency segment.

   When lookups are performed at each adjacency segment endpoint:

   o  CSID and VSID require an LPM lookup for IPv6 header destination
      address

Bonica, et al.          Expires November 25, 2021               [Page 6]

Internet-Draft             SRCOMP Requirements                  May 2021

   o  CRH requires an LPM lookup for the destination address, and an EM
      lookup for the next label in the CRH to retrieve the next segment
      address to place in the IPv6 header destination address field.

            +--------------------+------+-----+------+-------+
            | 16-bit or 32-bit   | CSID | CRH | VSID | UIDSR |
            +--------------------+------+-----+------+-------+
            | D.LKU(48B.1-15T.V) | *1*  | 2   | *1*  | *1*   |
            +--------------------+------+-----+------+-------+

      Table 5: Strict TE: Lookups performed, 16-bit SIDs, 48B.1-15T.V

   Conclusion: CSID VSID and UIDSR require fewer lookups for strict TE
   paths.

   A loose TE path is considered with a 48B.2..15T.V segment lists with
   a combination of prefix and adjacency segments.

   o  At a prefix segment endpoint, where the next segment in the
      segment list is a prefix segment:

      *  CSID, VSID, and UIDSR 16-bit and 32-bit require an LPM for the
         IPv6 DA, and an LPM for the next segment in the segment list.
      *  CRH requires an LPM for the IPv6 DA and an EM for the next
         label.  When the adjacent node is not a CRH node, a third EM
         for the adjacency is required.
   o  At a prefix segment endpoint, where the next segment in the
      segment list is a local adjacency segment:

      *  CSID 16-bit requires an LPM for the IPv6 DA containing the
         combined prefix and local adjacency segment.
      *  VSID and UIDSR 16-bit require an LPM for the IPv6 DA containing
         the prefix segment and an LPM for the next segment, the local
         adjacency segment.
      *  CSID, VSID and UIDSR 32-bit require a single LPM for the IPv6
         DA containing the global adjacency segment.
      *  CRH 16-bit and 32-bit require an LPM for the IPv6 DA and an EM
         for the next adjacency segment.

         +  An additional lookup is required when the adjacent node does
            not support CRH (for a third lookup below).
   o  A note on EM vs LPM

      *  Implementation of a lookup as an LPM or EM is a local decision.
      *  The above designation of lookups as EM or LPM may not match a
         specific implementation.

   +------------------------------------+------+--------+------+-------+
   | 16-bit                             | CSID | CRH    | VSID | UIDSR |
   +------------------------------------+------+--------+------+-------+
   | LKU(48B.2-15T.V) @ prefix segments | *2*  | *2*    | *2*  | *2*   |
   | LKU(48B.2-15T.V) @ adjacency       | *1*  | 2 or 3 | 2    | 2     |
   | segments                           |      |        |      |       |
   +------------------------------------+------+--------+------+-------+

      Table 6: Loose TE: Lookups performed, 16-bit SIDs, 48B.2-15T.V

   +------------------------------------+------+--------+------+-------+
   | 32-bit                             | CSID | CRH    | VSID | UIDSR |
   +------------------------------------+------+--------+------+-------+
   | LKU(48B.2-15T.V) @ prefix segments | *2*  | *2*    | *2*  | *2*   |
   | LKU(48B.2-15T.V) @ adjacency       | *1*  | 2 or 3 | *1*  | *1*   |
   | segments                           |      |        |      |       |
   +------------------------------------+------+--------+------+-------+

      Table 7: Loose TE: Lookups performed, 32-bit SIDs, 48B.2-15T.V

   Conclusion: CSID requires fewer lookups for loose TE paths.

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Thu, 27 May 2021 12:47:20 +0000

Please see inline.

On 2021-05-25, 4:53 PM, "Ron Bonica" <rbonica=[email-masked]> wrote:

Darren,

-          “Segment lists may contain transport, adjacency, service, binding
      or VPN segments.”

o   Maybe we should say “Segment list may contain transport segments (e.g., adjacency, binding, prefix) and VPN segments (e.g., END.DT4, END, DX4)

[DD] we can but I think readers know what these are

-          “When processing a segment, all proposals process the IPv6 header and routing header, if present.

o   However, the degree to which they process it varies. When a node encounters a CRH with Segments Left equal to zero, it skips over it. When a node encounters (__insert types here__) with segments left equal to 0, it examines the routing header to process flags, tags and TLVs.

[DD] this is a local implementation decision per segment.  The header is still parsed.

-          “The CRH routing header and CRH SIDs are not used when a single VPN segment is present in the segment list.  CRH proposes non-compressed SRv6 SID is used in the destination address of the outer IPv6 header.”

o   The CRH routing header and CRH SIDs are not used when a single VPN segment is present in the segment list.  CRH can encode VPN service information in either a classic SRv6 SID, found in the IPv6 Destination Address or in a TPF option found in the Destination Options header.

[DD] Not true, CRH does no encoding of VPN service information as an uncompressed SRv6 SID.  CRH is not used at all when a single segment is present in the segment list.  It relies on the uncompressed SRv6 SIDs and the SRv6 control plane signalling, no CRH at all.  This is probably most correct “CRH proposes non-compressed SRv6 SID is used in the destination address of the outer IPv6 header CRH is not used in this case.”

-          “When the ultimate VPN segment is represented by a TPF header, the outer IPv6 header, CRH header and TPF header are processed at the ultimate segment endpoint.”

o   Not true when there is only one segment in the path and, therefore, the TPF is absent

o   Even when it is true, the amount of CRH processing required is negligible. All you have to do is examine Segments Left, determine that its value is zero and skip over it.
[DD] It is still present and parsed.

-          “CSID, VSID and UIDSR use [RFC8754] reduced behavior when a segment list can be expressed as a single destination address, resulting in only an outer IPv6 header present.

o   The CRH also has a reduced mode

-          “The 16-bit variant of CSID encodes 4 or fewer transport SIDs in a single CSID container.”

o   Unless functionality required in SRH flags, tags and TLVs are required

o   Unless the addressing scheme doesn’t support it

-          “The 32-bit variants of CSID, VSID, and UIDSR global VPN SIDs are used to encode the VPN SID in a single segment.

o   Do you really mean to say that CSID, VSID and UIDSR can use 16-bit transport SIDs and 32 bit VPN SIDs. If so, shouldn’t we make the point that CRH-16 and TPF (32-bits) can also be used in the same packet?
[DD] No. for CSID, the VPN SID is allocated from the GIB, so only one SID is needed.

-          The tables are confusing to the point of being misleading

o   What do the stars mean?

o   We should break the tables in the following:

§  16-bit Transport

§  16-bit Egress PE

§  32-bit Transport

§  32-bit Egress PE

o   In each of the tables, we should note scenarios where a single node has to process two SIDs, and therefore, process the same header twice.

o   This analysis may make the tables large enough to be moved to an Appendix

[DD] We are counting headers parsed.  Lookups is the next section.

-          The conclusion should say that (__insert types here__) have been implemented and demonstrated to forward at similar and acceptable speeds. Therefore, the degree to which this analysis distinguishes between compression mechanisms may not be significant.

[DD] There is no analysis to support that text.
                                                                     Ron