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

[Senthil Dhanaraj <[e-mail]>]

Hi Jeffrey,
Comments inline.
Thanks,
Senthil


From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: 26 July 2018 16:40
To: Senthil Dhanaraj <[e-mail]>
Cc: [e-mail]
Subject: RE: [BIER] Comment on draft-zzhang-bier-php-00

Senthil,

Thanks for your comments. Please see zzh> below.

From: Senthil Dhanaraj <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, July 26, 2018 5:49 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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.

Senthil>> My Bad ! Got it.
                    Just had a quick read of zzhang-bess-mvpn-evpn-aggregation-label - J
                    So we need zzhang-bess-mvpn-evpn-aggregation-label as well along with BIER-PHP to solve "Incapable BFERs"



   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.

SENTHIL>> Right, Meant the same !



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.
Senthil >> ok

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]