[Bier] Review Comments - draft-ietf-bier-bar-ipa-05

[Xiejingrong <[e-mail]>]

Hi authors,
I am assigned as Doc shepherd for this draft.
I think the document is useful to clarify the BAR/IPA field defined in RFC8401/RFC8444.
My main suggestion is adding some real examples of IPA/BAR to make this document more clear and deployable.
Please see below for the comments.

1. For the following rules 1# and #2, how if there are conflictions of BC(X) and RC(X)?
For example, BC(X) says “prefer RED links and exclude BLUE links”, while RC(X) says “prefer BLUE links and exclude RED links”.
   1.  Apply the BIER constraints, resulting in BC(X).
   2.  Apply the routing constraints, resulting in RC(BC(X)).
   3.  Select the algorithm AG as following:
       A.  If BA is NULL, AG is set to RA.
       B.  If BA is not NULL, AG is set to BA.
   4.  Run AG on RC(BC(X)).

Should the combination of IPA/BAR be specified (following text be changed to new text) ?
[ORIG TEXT]
   When a new BAR value is defined, its corresponding BC/BA semantics MUST be specified.
   For a new IGP Algorithm to be used as a BIER IPA, its RC/RA semantics MUST also be clear.
[NEW TEXT]
   When a new BAR value is defined, its corresponding BC/BA semantics MUST be specified, and the combination of BAR and IPA MUST also be specified.
   For a new IGP Algorithm to be used as a BIER IPA, its RC/RA semantics MUST be specified, and the combination of BAR and IPA MUST also be specified.


2. For the function of bypassing Non-BIER routers (6.9 of RFC8279), this document is not clear.
Two possible options I can think of:
(a) Run AG on RC(BC(x)) to find the BFR-NBR of a BFER, and then run RA on RC(x) to find the IGP next-hop toward the BFR-NBR if BFR-NBR is not a directly connected NBR.
(b) Run AG on RC(BC(x)) to find the BFR-NBR of a BFER, and then run AG on RC(BC(x)) to find the IGP next-hop toward the BFR-NBR if BFR-NBR is not a directly connected NBR.

(a) looks better to me, since the finding of IGP next-hop toward the BFR-NBR seems to be a pure IGP behavior.
It is also notable that, incorrect combination of IPA and BAR may cause black hole of building a BIFT item to a BFER.
For example, a non-directly-connected BFR-NBR is found but the IGP next-hop toward the BFR-NBR could not be found according to the IPA+BAR.


3. For the above rule #1, the doc is not clear what does the BC(x) mean if BC = NULL. So does the rule #2 when RC = NULL.


4. I think one or two examples of IPA/BAR should be given to make it clear as an update to RFC8401/RFC8444.
(1)IPA = 0, and IPA = 1
IPA = 0 means that, RA = SPF based on link metric, RC = permit any node to overwrite the SPF path to the BFR-prefix of a BFR.
IPA = 1 means that, RA = SPF based on link metric, RC = Not permit overwriting the SPF path to the BFR-prefix of a BFR.

Text from draft-ietf-isis-segment-routing-extensions for reference:
      0: Shortest Path First (SPF) algorithm based on link metric.  This
      is the well-known shortest path algorithm as computed by the IS-IS
      Decision process.  Consistent with the deployed practice for link-
      state protocols, algorithm 0 permits any node to overwrite the SPF
      path with a different path based on local policy.

      1: Strict Shortest Path First (SPF) algorithm based on link
      metric.  The algorithm is identical to algorithm 0 but algorithm 1
      requires that all nodes along the path will honor the SPF routing
      decision.  Local policy MUST NOT alter the forwarding decision
      computed by algorithm 1 at the node claiming to support algorithm 1.

(2)BAR = 0, and BAR = 1
BAR = 0 means that, BA = NULL, BC = NULL
BAR = 1 means that, BA = NULL, BC = exclude non-BIER routers

Is the above interpretation of IPA = 0 correct ?
If it is, then maybe the use of IPA/BAR = 1/1 is allowed, but IPA/BAR = 0/1 is not allowed ?
If IPA/BAR = 0/1 is used, run AG on RC(BC(x)) to get the non-directly-connected BFR-NBR of a BFER seems difficult.


5.  editorial suggestions:
The topology could be a default topology, a multi-topology [RFC5120] topology.
Suggested:
The topology could be a default topology, or a non-default topology as defined in [RFC5120].

For a particular topology X (which could be a default topology or multi-topolgy topology)
Suggested:
For a particular topology X (which could be a default topology or non-default topology)


Thanks
Jingrong