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

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Senthil,

Thanks for your comments. Please see zzh> below.

From: Senthil Dhanaraj <[e-mail]>
Sent: Thursday, July 26, 2018 5:49 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]>
Cc: [e-mail]
Subject: [BIER] Comment on draft-zzhang-bier-php-00

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

Zzh> I actually do mean downstream assigned labels, so the proto field should be 1 instead of 2. The reason is that after popping the BIER header, the egress PE no longer knows who sent the packet so upstream assigned label cannot be used.


   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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8401&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=qiNetIETZtcdfL8jFwNPIWa_vJLz6FHobuD-EvuPF6U&s=23Nv1IUosCe-VA8WXGpGVe_mBlUCxoQVBrS0d2R8hnw&e=>] or [I-D.ietf-bier-ospf-bier-extensions<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dzzhang-2Dbier-2Dphp-2D00-23ref-2DI-2DD.ietf-2Dbier-2Dospf-2Dbier-2Dextensions&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=qiNetIETZtcdfL8jFwNPIWa_vJLz6FHobuD-EvuPF6U&s=_dL7yHwU0dCkXdKzeQeO5r-7ALaROOLSkQMXkhwQ5HY&e=>] 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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc3032&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=qiNetIETZtcdfL8jFwNPIWa_vJLz6FHobuD-EvuPF6U&s=iAM1xNgHZOuaAuMSaQ2FdmOKYN9v4_OjfffJrEfLgEw&e=>].



   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?

Zzh> With PHP, there is no need to care if a BSL is supported by the PHP requester. Max SI is irrelevant as well. So, indeed the only thing needed is the PHP sub-sub-TLV, in sync with non-MPLS encap.

Zzh> Good idea on the second bullet. In that case, PHP sub-sub-TLV must not be used.





   If a BFR follows section 6.9 of [RFC8279]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8279-23section-2D6.9&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=qiNetIETZtcdfL8jFwNPIWa_vJLz6FHobuD-EvuPF6U&s=iM51BZYJjsuLL8teYHyyxjbtxKBoORMam4-mLq5TSD4&e=> 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

Zzh> The first sentence of the paragraph is to handle the above situation. [c] is considered BIER incapable, so B will ECMP bier packets to E via D natively or tunnel through C
Zzh> For the BIFT entry for C itself, the next sentence (the "// SEN3" mark seems to indicate that your comments is about that second sentence) describes how it is put into place. Because the downstream neighbor (for prefix C) is C requesting PHP, the forwarding behavior is to do PHP.

Thanks!
Jeffrey

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]<mailto:[e-mail]>
[Company_logo]