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

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Jeffrey,
Please find below my comments marked with [XJR]

Thanks
Jingrong

From: Jeffrey (Zhaohui) Zhang [mailto:[e-mail]]
Sent: Wednesday, October 30, 2019 9:52 AM
To: Xiejingrong (Jingrong) <[e-mail]>; [e-mail]
Cc: BIER WG <[e-mail]>
Subject: RE: Review Comments - draft-ietf-bier-bar-ipa-05

Hi Jingrong,

Thank you for shepherding the document. Please see zzh> below.

From: Xiejingrong <[e-mail]<mailto:[e-mail]>>
Sent: Monday, October 7, 2019 11:56 PM
To: [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: Review Comments - draft-ietf-bier-bar-ipa-05

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)).

Zzh> An operator would be expected to do the reasonable things and not specify conflicting BC and RC for a sub-domain. Even if he did specify conflicting BC and RC, the rules are clear – apply BC first and then RC. In your example, you end up with no links to use. I think that’s acceptable.
[XJR] I assume this is a point need to be pointed out, since it is useful for avoiding misconfiguration, and this document is intent to explain the BAR and IPA.

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.

Zzh> As long as BC/BA or RC/RA semantics are clear, the combination is clear once you apply the rules, right?
[XJR] the combination is not clear due to the following comments ---- combination of BAR and IPA is not only responsible for calculating the BFR-NBR of a BFER, but also responsible of calculating the next-hop of a non-directly-connected BFR-NBR.

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.

Zzh> I don’t follow the above. The spec does say that for a particular subdomain if your own BAR/IPA is different from a BFR’s, then that BFR is considered as not BIER capable and whatever method you use to deal with incapable routers apply. I think that’s straightforward.
[XJR] it is reasonable for me to describe the overall method of dealing with incapable routers in RFC8279, but this doc is responsible for making this more detailed, since it is a specification of BAR/IPA and may be used to address the incapable routers as a use case of BAR.

(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.

Zzh> BC means BIER specific constraints. If BC is NULL it means no constraints.

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.

Zzh> It seems to me that the general rules are clear enough and adding the above examples only makes things more complicated?

(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

Zzh>  BAR 0 is already defined in 8401/8444. BAR 1 has not been officially defined (even thought it was used as an example in various discussions) and it’s not good to use it as an example here.
[XJR] Example is better than precept. One may find it difficult to define any new BAR/IPA according to this document if there is no examples, since the basic idea of BAR/IPA have been put in 8401/8444 since its proposal.

Is the above interpretation of IPA = 0 correct ?

Zzh> Honestly speaking I’m not good at interpreting IPA definitions.

If it is, then maybe the use of IPA/BAR = 1/1 is allowed, but IPA/BAR = 0/1 is not allowed ?

Zzh> I don’t see why 0/1 is not allowed. Using your example, BAR1 simply says excluding non-BIER routers, i.e. as if they don’t exist (or treated as always down). I don’t see why BAR 1 would conflict with ANY IPA.
[XJR] One may find a non-directly-connected BFR-NBR by using BAR+IPA, but may failed to find the next-hop of the non-directly-connected BFR-NBR according to IPA.

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)

Zzh> Sure I can change that.
Zzh> Thanks!
Zzh> Jeffrey

Thanks
Jingrong