Subject: Re: [Idr] draft-hb-idr-sr-p2mp-policy (3/10 to 3/24/2022) - Adoption call - TEA attribute - for "Replication segment Route OIF" route

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 7 Apr 2022 13:46:16 +0000

Hi Sue, Hootman,

>From https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-05#section-3.2.3:

replication segment SAFI NLRI: <route-type non-sahred/shared
                                tree replication-segment-oif>
Attributes:
   Tunnel Encaps Attribute (23)
      Tunnel Type: (TBD Replication-Segment-oif)
         segment-list
            weight (optional)
            protection (optional, must be present when protection flag is enabled for downstream-nodes)
            segment
            segment
              ...
         segment-list
            weight (optional)
            protection (optional, must be present when protection flag is enabled for downstream-nodes)
            segment
            segment
              ...
         segment-list (protection segment list)
            protection (protecting the first segment list, can't have weight sub-tlv)
            segment
            segment
            ...
       ...
    ...

The above quoted text listed three segment lists. I suppose the first two are for load-balancing purposes (traffic will be sent out of one of the two but not both). The third one is used to protect the first one.

My understanding is that the protection correlation (e.g.. the 3rd segment list protects the 1st segment list) is through a "protection sub-TLV" in *all* segment lists:

3.4.3<https://datatracker.ietf.org/doc/html/draft-hb-idr-sr-p2mp-policy-05#section-3.4.3>.  Protection sub-tlv

   Protection sub-tlv is optional, if FRR is desired for the downstream

   node this sub-tlv can be used to identify the protection segment

   list.  To identify protection segment list this sub-tlv provides a

   segment list identifier.  If protection is desired under the endpoint

   all the segment lists should have this sub-tlv.  A protection segment

   list can not have a weight sub-tlv and it can not participate in

   ECMP.  That said a segment list that is being protected can have a

   weight sub-tlv and participate in ECMP.

With that, *each* segment list is given an ID, and both the ID and protecting ID are listed in this sub-TLV. I think this has unnecessary overhead both in the encoding and in the logic to assign the ID and to correlate the protection. For comparison, draft-bess has a much simpler and direct approach (https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-08#section-3.1.6):

   The Backup Tunnel sub-TLV is used to specify the backup paths for the
   tunnel.  The length is two-octet.  The value part encodes a one-octet
   flags field and a variable length Tunnel Encapsulation Attribute.  If
   the tunnel goes down, traffic that is normally sent out of the tunnel
   is fast rerouted to the tunnels listed in the encoded TEA.

                  +--------------------------------+
                  | Sub-TLV Type (1 Octet, TBD)    |
                  +--------------------------------+
                  | Sub-TLV Length (2 Octets)      |
                  +--------------------------------+
                  | P | rest of 1 Octet Flags      |
                  +--------------------------------+
                  | Backup TEA (variable length)   |
                  +--------------------------------+

The backup (for protection) sub-TLV is directly encoded as a sub-tlv of the protected "tunnel" (i.e., a replication branch to a downstream node). BTW, even the protecting/backup tunnel itself can have load-balance branches if the controller chooses to do so.

Now for the first two load-balancing segment lists (traffic will be load-balanced out of them), draft-bess uses this approach (https://datatracker.ietf.org/doc/html/draft-ietf-bess-bgp-multicast-controller-08#section-3.1.2):

   Consider that a multicast packet needs to be sent to a downstream
   node, which could be reached via four paths P1~P4.  If it does not
   matter which of path is taken, an "Any-Encapsulation" tunnel with the
   Tunnel Endpoint Sub-TLV specifying the downstream node's loopback
   address works well.  If the controller wants to specify that only
   P1~P2 should be used, then a "Load-balancing" tunnel needs to be
   used, listing P1 and P2 as member tunnels of the "Load-balancing"
   tunnel.

   A load-balancing tunnel has one "Member Tunnels" Sub-TLV defined in
   this document.  The Sub-TLV is a list of tunnels, each specifying a
   way to reach the downstream.  A packet will be sent out of one of the
   tunnels listed in the Member Tunnels Sub-TLV of the load-balancing
   tunnel.

The first paragraph in the above text is not SR-specific and uses "any-encapsulation" tunnel. I want to point out that that it can be a "Segment List" tunnel as well (with just the node sid of the downstream node and load balancing to that node sid will happen automatically).

Jeffrey

Juniper Business Use Only