Re: [Srcomp] Proposed changes for Section 2.2.2

["Darren Dukes (ddukes)" <[e-mail]>]

This isn’t accurate for all scenarios – it is best to isolate strict vs loose TE paths for all scenarios as in the original proposed text.

Darren

On 2021-06-07, 6:54 PM, "Srcomp" <[e-mail]> wrote:


New Text
-------------

This section details the number of lookups required for each compression solution in each of the following scenarios:


-          A prefix segment where the next segment is also a prefix segment

-          A prefix segment where the next segment is an adjacency segment

-          An adjacency segment where the next segment is a prefix segment

-          An adjacency segment where the next segment is also an adjacency segment


Lookups are categorized as Longest Prefix Match (LPM) or Indexed. Typically, an Indexed lookup consumes fewer resources than an LPM lookup.

Table x describes all scenarios except for two exception cases.

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


            [1] On IPv6 Destination Address
            [2] On CRH SID

      Table X: A prefix segment where the next segment is also a prefix segment.

One exception (Table X+1) is encountered on a local adjacency segment that:


-          Is preceded by another adjacency segment

-          Includes non-SRv6 aware nodes


            +--------------------+-----------+------------+-------+--------+
            | 16-bit or 32-bit   | CSID      | CRH        | VSID  | UIDSR  |
            +--------------------+-----------+------------+---- --+--------+
            | D.LKU(48B.1-15T.V) | LPM [1]   | LPM [1]    |       | LPM[1] |
            |                    | Indexed[2]| Indexed [3]|       |        |
            +--------------------+-----------+------------+-------+--------+


            [1] On a prefix SID, located in the IPv6 Destination Address.
            [2] On a locally allocated adjacency SID, located after the prefix SID in the IPv6 destination address.
            [3] On CRH SID

      Table X+1 : First Exception Case

In this exception case, CSID requires a prefix SID to deliver the packet to the processing node and a locally allocated adjacency SID to determine local behavior.

Another exception (Table X+2) can be encountered on any segment that:


-          Is preceded by another adjacency segment

-          Includes non-SRv6 aware nodes


            +--------------------+-----------+------------+-------+--------+
            | 16-bit or 32-bit   | CSID      | CRH        | VSID  | UIDSR  |
            +--------------------+-----------+------------+---- --+--------+
            | D.LKU(48B.1-15T.V) | LPM [1]   | LPM [1]    |       | LPM[1] |
            |                    |           | Indexed [2]|       |        |
            |                    |           | Indexed [3]|       |        |
            +--------------------+-----------+------------+-------+--------+

            [1] On IPv6 Destination Address
            [2] On CRH SID. This SID updates the IPv6 destination address but does not forward the packet
            [3] On CRH SID. This SID forwards the packet but does not update the IPv6 address


      Table X+2 : Second Exception Case

In this exception case, CRH requires on CRH SID to update the IPv6 address another to forward the packet.

Conclusion: In the nominal case, CSID, VSID, and UIDSR required one LPM lookup. CRH requires one LPM lookup and one indexed lookup.

In the first exception case, described above,  CSID and CRH both required one LPM lookup and one Indexed lookup.

In the second exception case, described above, CSID, VSID, and UIDSR required one LPM lookup. CRH requires one LPM lookup and two indexed lookups.


OLD Text
------------
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
   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.



Juniper Business Use Only