[Bier] [BIER] Comment on draft-zzhang-bier-php-00

[Senthil Dhanaraj <[e-mail]>]

Hi Jeffrey,

Well written, Simple way to support BIER incapable egress nodes !
Few comments/questions, kindly check.

Section (3)

   o  The payload after BIER header is MPLS packet with downstream-        // SEN1
      assigned label at top of stack (i.e., the Proto field in the BIER
      header is 2), For example, labels from a Domain-wide Common Block
      (DCB) are used as specified in [I-D.zzhang-bess-mvpn-evpn-
      aggregation-label].

[SEN1] You mean upstream assigned label ?
              MVPN - Ingress PE pushes the upstream assigned label (allocated by self) before BIER header
              +
              Proto = 2 in BIER header = MPLS packet with upstream-assigned label at top of stack



   For MPLS encapsulation, a BIER incapable router, if acting as a

   multicast flow overlay router, MUST signal its BIER information as

   specified in [RFC8401<https://tools.ietf.org/html/rfc8401>] or [I-D.ietf-bier-ospf-bier-extensions<https://tools.ietf.org/html/draft-zzhang-bier-php-00#ref-I-D.ietf-bier-ospf-bier-extensions>] or [I-

   D.ietf-bier-idr-extensions], with the Label Range Base in the BIER

   MPLS Encapsulation sub-TLV set to Implicit Null Label [RFC3032<https://tools.ietf.org/html/rfc3032>].



   For non-MPLS encapsulation, a PHP sub-sub-TLV is included in the BIER

   sub-TLV attached to the BIER incapable router's BIER prefix to

   request BIER PHP from other BFRs.  The sub-sub-TLV's type is TBD, and

   the length is 0.  The PHP sub-sub-TLV MAY be used for MPLS               // SEN2

   encapsulation as well.

[SEN2] Like the idea of using PHP sub-sub-TLV for MPLS encapsulation as well.
               I'd imagine,

o   Inclusion of PHP sub-sub-TLV by non-BIER capable nodes would help to avoid mandating the inclusion of

"MPLS Encap sub-TLV with Implicit Label" for all / each-of-the the BSL(s) configured/discovered in the network

o   It is possible to restrict the advertisement of "MPLS Encap with Implicit label" only for the un-supported BSL(s) by a

BIER capable Egress PE.

Thoughts?





   If a BFR follows section 6.9 of [RFC8279]<https://tools.ietf.org/html/rfc8279#section-6.9> to handle BIER incapable

   routers, it must treat a router as BIER incapable if the Label Range

   Base dvertised by the router is Implicit Null, or if the router

   advertises a PHP sub-sub-TLV, so that the router is not used as a

   transit BFR.                                                             // SEN3



   If the downstream neighbor for a BIER prefix is the one advertising      // SEN3

   the prefix with a PHP sub-sub-TLV or with an Implicit Null Label as

   the Label Range Base in its BIER MPLS Encapsulation sub-sub-TLV, then

   when the corresponding BIRT or BIFT entry is created/updated, the

   forwarding behavior MUST be that the BIER header is removed and the

   payload be sent to the downstream router without the BIER header,

   either directly or over a tunnel.

[SEN3] Can we make the text to be more precise/clear ?
              Consider cases where an egress node may act as transit also (ex: below)

             [A] --- B -- [C]
                          |        |
                          D - [E]

[C] : Non bier capable Egress
@ B: [C] is the nexthop for E  as well


Thanks,
Senthil Dhanaraj
Network Business Line

Huawei Technologies India Pvt. Ltd
Survery No. 37, Next to EPIP Area, Kundalahalli, Whitefield
Bengaluru-560066, Karnataka
Tel: [phone] Ext:71881 Email: [e-mail]
[Company_logo]