Subject: [Rift] RIFT PGP

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 9 May 2018 22:29:38 +0000

Hi Alia,

We are sorting through the outstanding issues/items with the RIFT and one of them is the PGP schema/policy definition that Tony listed as red items in his London presentation.

I see the following the incomplete schema:

union TIEElement {
    ...
    /** @todo: policy guided prefixes */
}

Any plan to finish it soon?
Do we need some normative definition for the policy or are the descriptive examples in 4.2.4.2 good enough?

Additionally, I have the following questions/comments:

   ... Because the RIFT adjacency is between nodes and
   there may be parallel links between the two nodes, the policy-guided
   prefix is considered to start with the next-hop set that has all
   links to the originating node Y.

It seems to be saying that only one adjacency is formed between two nodes no matter how many parallel links there are between them. However according to Tony each link has its own adjacency. On the other hand, I don't think this is relevant in this context so perhaps just remove the first clause?

   Add Cost T:   For each appearance of community S in P.community_list,
      if the node X has community S, then add T to P.cost.

In the above text, "community S" is a bit strange. Seems that the first appearance should be "community (S, T)", and I am not sure what "if the node X has community S" should be - should it be "community (S,0)"?

   Accumulate Min-BW T:   Let bw be the sum of the bandwidth for
      P.next_hop_set.  If that sum is less than T, then replace (S,T)
      with (S, bw).

Notice that in the above, there is not requirement of "if the node X has community S" as in the previous example. Is that intended?

   Add Community T if Node matches S:   If the node X has community S,
      then add community T to P.community_list.

The above is again a bit strange, given the earlier text quoted below:

   ... The length of a community is a 64 bits number and it
   can be written as a single field M or as a multi-field (S = M[0-31],
   T = M[32-63]) in these examples.

For the following:

4.2.4.3.  Store Policy-Guided Prefix for Route Computation and
          Regeneration

   Once a policy-guided prefix has completed ingress filtering and
   policy, it is almost ready to store and use.  It is still necessary
   to adjust the cost of the prefix to account for the link from the
   computing node X to the originating neighbor node Y.

   There are three different policies that can be used:

Could the "three different policies" in the above text changed to "three different methods"? They seem to be different from the ingress policy in the previous section. Or is it that what method to use is actually controlled by a policy that matches on some communities? If so it would be good to talk about some explicit examples as in the previous section.

Now for the following:

4.2.4.5.  Overlap with Disaggregated Prefixes

   PGPs may overlap with prefixes introduced by automatic de-
   aggregation.  The topic is under further discussion.  The break in
   connectivity that leads to infeasibility of a PGP is mirrored in
   adjacency tear-down and according removal of such PGPs.
   Nevertheless, the underlying link-state flooding will be likely
   reacting significantly faster than a hop-by-hop redistribution and
   with that the preference for PGPs may cause intermittent black-holes.

Wondering if any progress has been made there?

Thanks.
Jeffrey