[Srcomp] Markup on Section 2.2.2

[Ron Bonica <[e-mail]>]

Folks,

IMO, Section 2.2.2 requires significant work. A few suggestions are below [RB]

                                         Ron



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:

[RB] We can delete the following text if we make the table more descriptive

   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.

[RB] End of text to be deleted

[RB] This is the more descriptive table

            +--------------------+---------+---------+---------+---------+
            | 16-bit or 32-bit   | CSID    | CRH     | VSID    | UIDSR   |
            +--------------------+---------+---------+---------+---------+
            | D.LKU(48B.1-15T.V) | IPv6 DA | IPv6 DA | IPv6 DA | IPv6 DA |
            |                    |    (LPM)|    (LPM)|    (LPM)|   (LPM) |
            |                    |         | CRH SID |         |         |
            |                    |         |    (EM) |         |         |
            +--------------------+---------+---------+---------+---------+

      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.

[RB] However, the cost of an EM is generally much less than the cost of an LPM.

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

[RB] We should replace this text with a table like the one below:

   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.

[RB] End of text to be deleted
[RB] Table

            +--------------------+---------+---------+---------+---------+
            | 16-bit or 32-bit   | CSID    | CRH     | VSID    | UIDSR   |
            +--------------------+---------+---------+---------+---------+
            | D.LKU(48B.1-15T.V) | IPv6 DA | IPv6 DA | IPv6 DA | IPv6 DA |
            |                    |    (LPM)|    (LPM)|    (LPM)|   (LPM) |
            |                    |         | CRH SID |         |         |
            |                    |         |    (EM) |         |         |
            +--------------------+---------+---------+---------+---------+

                              Table 5: Loose TE: Prefix segment followed by prefix segment. Lookups performed, 16-bit SIDs, 48B.1-15T.V


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

[RB] Same here. A more descriptive table is better than text

   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.

[RB] Why would you do an LPM on a CRH SID 😉
[RB] What would the result of an EM on a CSID yield 😉


   +------------------------------------+------+--------+------+-------+
   | 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