Re: [Srcomp] Comments on 2.2.2.2 (was RE: 2.2. Forwarding Efficiency)

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

From: Srcomp <[e-mail]> on behalf of "Chengli (Cheng Li)" <[e-mail]>
Date: Wednesday, 2 June 2021 at 08:45
To: "Darren Dukes (ddukes)" <ddukes=[e-mail]>, Ron Bonica <rbonica=[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Srcomp] Comments on 2.2.2.2 (was RE: 2.2. Forwarding Efficiency)

Hi please see my comments below.

Thanks,
Cheng


From: Srcomp [mailto:[e-mail]] On Behalf Of Darren Dukes (ddukes)
Sent: Thursday, May 27, 2021 8:09 PM
To: Ron Bonica <rbonica=[e-mail]>; [e-mail]
Subject: Re: [Srcomp] Comments on 2.2.2.2 (was RE: 2.2. Forwarding Efficiency)



On 2021-05-25, 5:46 PM, "Ron Bonica" <rbonica=[e-mail]<mailto:rbonica=[e-mail]>> wrote:

Folk,


-          The paragraph above table 5

o   We should note that the cost of an EM lookup is miniscule compared to the cost of an LPM lookup


[DD] This is very hardware dependent, and whether an implementation chooses to perform an LPM or exact match is a local implementation choice that is not within the scope of analysis.
[Cheng] Well, it is hard to say that how much difference between them, depends on implementation. Better to leave it and move forward.
WH> I agree, we should capture what the requirement states.



-          Table 5

o   We should not that CRH requires one LPM lookup and one EM lookup
[DD] that is done in the text description above.
WH> agreed


-          Conclusion after Table 5

o   We should note that for (__ insert routing type__) implementation demonstrate similar and acceptable forwarding rates. Therefore, distinction described in this section are negligible.

[DD] There is no analysis to support that text.
[Cheng]Agree.
WH> What matters here is the # lookups in my view



-          In a loose TE path, on a prefix segment where the next segment is also a prefix segment, you say that the CRH requires a second EM for the adjacency. But there are no adjacency SIDs in this use-case. We are talking about a prefix segment followed by another prefix segment.
[DD] If you mean “when the adjacent node is not a CRH...” yes, that sentence can be deleted when the next segment is prefix segment, it is correctly present for adjacency segments.


-          In a loose TE path, on a prefix segment where the next segment is an adjacency segment, you should note that the CSID requires another segment, and therefore another LPM, to get to the node that instantiates the adjacency segment.
[DD]  The text covers this: “CSID 16-bit requires an LPM for the IPv6 DA containing the combined prefix and local adjacency segment.”
WH> it can be combined in the same lookup, which makes CSID efficient and deterministic


-          Conclusion after Table 6

o   We should note that for (__ insert routing type__) implementation demonstrate similar and acceptable forwarding rates. Therefore, distinction described in this section are negligible.

[DD] There is no analysis to support that text.
[Cheng] I think we do not have analysis to support this statement.
WH> what matters is the # lookups as we know that this as an impact how efficient they might be.




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