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

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

-06 has been posted, with the following additions:

3.  Examples

   As an example, one may define BAR=x with semantics of "excluding BIER
   incapable routers".  That BIER specific constraint can go with any
   IPA: whatever RCRA defined by the IPA are augmented with "excluding
   BIER incapable routers", i.e., BIER incapable routers are not put
   onto the candidate list during SPF calculation.

   Note that if the BC and RC happen to conflict and lead to an empty
   topology, then no native BIER forwarding path will be found.  That is
   a network design issue that an operator need to avoid when choosing
   BAR/IPA.

Thanks!
Jeffrey

From: Jeffrey (Zhaohui) Zhang
Sent: Monday, November 4, 2019 1:55 PM
To: Xiejingrong (Jingrong) <[e-mail]>; [e-mail]
Cc: BIER WG <[e-mail]>
Subject: RE: Review Comments - draft-ietf-bier-bar-ipa-05

Hi Jingrong,

Please see zzh2> below.

From: Xiejingrong (Jingrong) <[e-mail]<mailto:[e-mail]>>
Sent: Monday, November 4, 2019 7:18 AM
To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[e-mail]>>
Subject: RE: Review Comments - draft-ietf-bier-bar-ipa-05

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]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: BIER WG <[e-mail]<mailto:[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.
Zzh2> I thought that was obvious, but I’ll explicitly point that out.

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.
Zzh2> I don’t agree with the above. An operator may not care how the BFR-NBR is reached via any tunnel; even if that tunnel must be following IPA (which I don’t think this document should specify), it is not the combination of BAR and IPA that determines the nexthop for that tunnel, as there should be no BIER routers (that advertise the same BAR+IPA) on the tunnel path to the 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.
Zzh2> Details of dealing with incapable routers is outside the scope of this document. There are many ways to deal with incapable routers: section 6.9 of 8279 (and tethering extension); excluding in capable routers; whatever may be defined in the future.

(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.
Zzh2> I honestly don’t see why it is difficult and why an example will help defining new BAR/IPA. But I will add the following example:

  For example, one may define BAR=x with semantics of “excluding BIER incapable routers”. That BIER specific constraint can go with any IPA: whatever RCRA defined by IPA is augmented with “excluding BIER incapable routers”.

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.
Zzh2> That’s not a conflict of BAR/IPA definition; that’s just like requesting a RSVP-TE tunnel with 1G BW while all the links in the network are only 10M.
Zzh2> Thanks!
Zzh2> Jeffrey

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