Re: [Rift] Dear RIFT protocol and RIFT YANG co-author, plsreviewtheupdateofRIFT YANG model

[Bruno Rijsman <[e-mail]>]

I was just looking at the YANG data model, and I noticed that it does *not* allow different source addresses to be specified, so your question was sort of moot.

What it *does* allow is different RX addresses to be specified for TIEs and flooding traffic.  These are receive multicast addresses, so they will appear as the destination address on the packet.  They are not source addresses.

— Bruno

> On Jul 10, 2020, at 12:36 PM, Bruno Rijsman <[e-mail]> wrote:
> 
> Hi Sandy,
> 
> Thanks for the updated model; the next round of review comments will follow shortly.
> 
> Meanwhile, here are the answers to your questions:
>> And I have two questions:
>> 
>> There is a leaf "cost" in the neighbor grouping, is the "metric" duplicated with the "cost"?
>> 
> Currently, your YANG datamodel has both cost and metric attributes per neighbor (as well as bandwidth):
> 
> +--ro neighbor
>       +--ro cost?      uint32
>       +--ro metric?    uint32
>       +--ro bandwidth? uint32
> 
> Most of the text in the RIFT spec (including the definition) uses the term "cost" to mean the cost of a link to an immediately neighboring node. The term "distance" is used to mean the total cost of a path to a remote node.
> 
> The Thrift datamodel in the RIFT spec is super inconsistent in its terminology:
> 
>  /** neighbor of a node */
>  struct NodeNeighborsTIEElement {
>  /** level of neighbor */
>  1: required common.LevelType level;
>  /** Cost to neighbor.
>  @note: All parallel links to same node
>  incur same cost, in case the neighbor has multiple
>  parallel links at different cost, the largest distance
>  (highest numerical value) MUST be advertised.
>  @note: any neighbor with cost <= 0 MUST be ignored
>  in computations */
>  3: optional common.MetricType cost
>  = common.default_distance;
> 
> Note that the Thrift attribute is called "cost" but it's type is "MetricType" and it 's default value is "default_distance" 8-)
> 
> Bottom line: cost and metric are synonyms, we only need neighbor cost OR neighbor metric in the YANG (not both). I suggest that we only keep cost and get rid of metric. We do need bandwidth as a separate attribute.
> 
> Note: in a later e-mail I will send a rather long list of attributes that could be added to the YANG data model. bandwidth-adjusted-cost will be one of those additional attributes that I will suggest (see section 4.3.6. Fabric Bandwidth Balancing in the RIFT spec).
> 
>> If different source addresses can be used for LIE and TIE sending?
>> 
> 
> One thing to consider is that LIEs are always sent on IPv4 *and* IPv6.  Flooding packets (not just TIEs, but also TIDEs and TIREs) are sent on IPv4 *or* IPv6 but not both.
> 
> For a given address family, I think that it would be reasonable to require that LIEs and flooding traffic *must* be sent on the same source address. The reason is that once a neighbor has been discovered by virtue of receiving LIEs from a particular address, we want to open up a listening socket for that particular neighbor for flooding traffic. That flooding socket has the same remote address but potentially a different UDP port.
> 
> My implementation does not actually bind to a remote address, but I *could* have chosen to do so:
> 
> agg_101> show interface if_101_1 sockets
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | Traffic  | Direction | Family | Local Address                | Local Port | Remote Address  | Remote Port |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | LIEs     | Receive   | IPv4   | 224.0.0.81                   | 20001      | Any             | Any         |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | LIEs     | Receive   | IPv6   | ff02::a1f7%en0               | 20001      | Any             | Any         |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | LIEs     | Send      | IPv4   | 192.168.178.192              | 63729      | 224.0.0.71      | 20002       |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | LIEs     | Send      | IPv6   | fe80::4b0:a72c:c8eb:dd5a%en0 | 63730      | ff02::a1f7%en0  | 20002       |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | Flooding | Receive   | IPv4   | 192.168.178.192              | 20004      | Any             | Any         |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | Flooding | Receive   | IPv6   | fe80::4b0:a72c:c8eb:dd5a%en0 | 20004      | Any             | Any         |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> | Flooding | Send      | IPv4   | 192.168.178.192              | 54629      | 192.168.178.192 | 20003       |
> +----------+-----------+--------+------------------------------+------------+-----------------+-------------+
> 
>