Subject: Re: [Rift] Mail regarding draft-ietf-rift-rift

From: Antoni Przygienda <[email-masked]>
Date: Mon, 2 Jul 2018 05:04:52 +0000

Hey Nagendra, I see some careful reading has been done ;-) thanks for that. Stuff inline & I’m copying the discussion through to the list so other people can benefit from it …

--- tony

<[email-masked]<mailto:[email-masked]>> spake:

Hi Authors,

Please find some comments on the draft:

1.       Section 4.2.2 (and few other sections) define the use of TTL=1 for link scoped communication. As defined in RFC5082, TTL of 1 can be spoofed. But a TTL of value 255 cannot be. While OSPF/LDP uses GTSM as optional feature for backward compatibility, RIFT being a new protocol, I think GTSM can be made mandatory for better security.

Yeah, conscious choice. I hate the 255 stuff for the fact that we’re talking multicast here and that’s an ugly thing to run away from you with TTL. I vote to stay on 1. What RIFT needs is an envelope with proper hash, nonce, lifetime out the TIE and so on. I talked about that @ the interim and we can pick that topic up and start working on it but it’s right now doesn’t make it to the top of my priority list, maybe RIFTv2. That will give us proper security on the protocol (when needed) rather than GTSM which really is just a hack IMO (and I’m aware some people may play with the flamethrower knobs already ;-)

2.       REQ#1 suggests that the control plane should discover the cabling violation and prevent adj formation. Based on section 4.2.2, if I have a mis-cabling between nodes at Level 2 and Level 0 (instead of connecting to Level 1 for example), it appears the adjacency will be formed. Applying the 8 step rules for this scenario, I couldn't find how the node can detect miscabling and avoid the adjacency formation. Am I missing something that prevents such condition?.

Clause 4.2.2/paragraph 8/roman iv (double iii) right now ;-) takes care of that ;-)

3. Table 1 in Section 4.2.3.2, defines that Prefix N-TIE contains "directly reachable" prefixes. By "directly reachable", I am assuming that prefixes that are directly connected. Is my assumption right?. If so, I am trying to understand if there is any need to advertise additional prefixes that are not directly connected (like a redistribution from a leaf connecting a site or so)?.

Yes, so this is ongoing discussion whether we should have a special TIE for redistributed stuff or use something like ‘E’ flag. I think it will go towards the 2nd, i.e. looks like OSPF and we’ll use the `PrefixAttributes` to encode that since I wouldn’t want to “hack the metric” and use ‘top bits’ and such stuff. That is bit expensive encoding wise (if you redistribute a lot) but cleanest. Opinions?

4. Section 4.3.4.1 mentions the use of highest Originator ID as one of the tie-breaking consideration. I hope you meant System ID?. This is the only section that uses this term.

Yepp, good catch, corrected. It’s system ID. I’ll call that “originator’s System ID”

5. Section 4.3.5, discusses about the use of BFD (RFC5881) for fast failure detection. There are equal benefits in considering S-BFD (RFC7881). In any scenarios involving failure detection with unidirectional benefit, S-BFD is more appropriate. If you think it is reasonable, we can get some details around S-BFD and its applicability.

Yep, would love to. For many reasons being able to drive BFD with the protocol would be very desirable and I’m agnostic how we do it, I just made sure we exchange BFD discriminators in LIEs. Good topic for conversation in Montreal?

6. Section 4.2.8 discusses about automatic prefix dis-aggregation. Per my reading, I think the prefix dis-aggregation is always based on S-TIE adjacency difference. But I think we also need to consider the N-TIE adjacency failures. For example, a node at level 2 may loose all its upstream neighbors (towards Spine) but all its southbound adjacencies are intact. In this case, the node MUST dis-aggregate the prefixes (with a simple split horizon) and advertise back southbound. In Figure 2, if Node112 looses all its northboth adj ro Spine21 and Spine22 but still have the adj to Leaf112, I understand it will stop advertising default route. But with this, Leaf111 will not use it even to reach Prefixes connected to Leaf112.

Did I missed this mechanism explained else where in the document?

Yupp, thay’s the trade-off consciously taken. You missed maybe that horizontal links still allow to advertise default and will be used to offload towards N connected spine.  The design chosen was driven based on customers’ input on the requirement that leaf’s should be simplest possible & hold minimum information.

7. Section 5.1 defines the below:

"An S Tie with a default IP prefix would be originated by Node 111 and
   Node 112 and each would be sent to Leaf 111 and Leaf 112.  Leaf 111
   and Leaf 112 would each send the S-TIE from Node 111 to Node 112 and
   the S-TIE from Node 112 to Node 111."

I was under impression that it is only the Node S-TIE that will be reflected and not the Prefix S-TIE. Assuming that the default Ip Prefix will be advertised using Prefix S-TIE, any reason why Prefix S-TIE is required to be reflected?.

Hmm, yeah, your reading is correct. A slip here. We do only reflect node TIEs (Pascal has other ideas but IMO we can’t get the necessary scalability otherwise).   To my defense, someone else wrote this section AFAIR ;-) will be corrected in -03

8. A flapping link at any level may result in continuous prefix agg/dis-agg causing a lot of flooding (and withdraw). We can use a simple dampening system while withdrawing the dis-aggregated prefix. Alternately, the dampening can be done at the Node S-TIE level where the node connecting to the flapping adj will advertise as if the adj is down till some stability. This will result in advertising more specific prefixes from other nodes (once) and avoid black holing and reduce the amount of flooding (proportional to the flap).

Yeah, we could do that & it’s probably an interesting idea given links do deteriorate in such nasty wasys ;-)

9. Per my reading, Node S-TIE will be originated and advertised only when there is a change in originating nodes adjacency. Let us assume in figure 2 that Node 111 is coming up for the first time (or rebooted). By the time when it comes up, all the adjacencies on Node 112 will be intact. So when Node111 originates Node S-TIE, it will be reflected to Node 112. But there will not be any reflection of S-TIE from Node112 to Node111. So it cannot compare to see if it should propagate any more specific prefix. The same holds true for Spine as it needs the reflected S-TIE to decide if or not it should originate the default route (as per section 4.2.8).

yes, there will be reflection. Flooding is under CSNPs (TIDEs and TIREs) and 111 will request the newly visible 112 node S-TIE (in a sense pull) based on flooding scopes. Generally flooding is reliable so it doesn’t matter what comes up when obviously.

Few minor nits and editorial changes below:

In Terminology section the Node TIE was compared to OSPF Node LSA. Technically it is OSPF "Router LSA". I think we dont use Node LSA term :)

yepp

In Terminology section, Northbound representation is not defined. While explicit, most of the other terminologies are defined for both direction :)

I pass on that unless other people remark on it. There’s ton context.

s/typical configuration forf Clos/typical configuration for Clos

ack

Step 8 of section 4.2.2 has 2 (iii) as below:

iii) both nodes are at level 0 AND both indicate support for
          Section 4.3.9 OR
iii) neither node is at level 0 and the neighboring node is at
          most one level away

corrected

In section 4.2.3.3,
s/flloding is initially more/flooding is initially more/
s/we provide as solution a close/we provide a solution as close

ack

A snip from Section 4.2.2 as below:

"A node tries to form a three way adjacency if and only if
   (definitions of LEAF_ONLY are found in Section 4.2.9)"

What is the need for the reference to LEAF_ONLY in this section?. I dont see 4.2.2 (or any subsequent sub-sections) uses LEAF_ONLY.

Level 0 is implied by LEAF_ONLY. I had all kind of level 0 _or_ LEAF in it but since it’s implied I dropped it out. However, the LEAF has implications here obviously. I tried to add something to clarify and move the sentence a bit …

--- tony