Re: [Srcomp] 2.2. Forwarding Efficiency

[Ron Bonica <[e-mail]>]

Darren,


Please see https://mailarchive.ietf.org/arch/msg/srcomp/F68_Ah6yo1K-wapmNjO2anVqm2Y/. In particular, please see the part about "The proponent of a compression mechanism will always be given the opportunity to propose initial text".



                                                                  Ron





Juniper Business Use Only
From: Srcomp <[e-mail]> On Behalf Of Darren Dukes (ddukes)
Sent: Monday, May 24, 2021 10:18 PM
To: [e-mail]
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.