CC-ing the babel-users list. Do we want to move this discussion over there?
> [1] https://github.com/fingon/pybabel/blob/master/rfc6126-comments.txt Thanks for the comments. > 'recently heard from' = ? You mean Section 2.1? That's in the protocol overview section, so I think it's fine. The actual procedure is defined in Section 3.4.2, where it's hopefully clear that it's done for each neighbour. The problem is elsewhere -- we don't say when to discard a neighbour. The answer is that it doesn't matter, but it should be said somewhere. (The reference implementation discards a neighbour after we've missed 16 hellos in a row.) > 'timer' <> 'time value' distinction is somewhat lacking in my opinion; some > things require action at time point, and others do need just to be kept > track of (e.g. 'hello timer''s various incarnations) Where? I think I tried to be consistent -- a timer is something that is set to a value, decreases over time, and expires when it reaches zero. I got it wrong only once, saying that a timer "triggers" instead of "expires". Relative times are consistently called "interval". There are no absolute times in this protocol. > route table defined in 3.2.5 does not contain router id entries, yet 3.5.4 > refers to one Yes it does. Section 3.2.5 says that the route table includes o the source (prefix, plen, router-id) for which this route is advertised; Whether you implement that by actually storing these three pieces of data in the route table (and look-up sources each time you need a seqno) or as a pointer into the source table is an implementation detail, but in the conceptual data model the route table contains a router-id. > 3.5.4 what is 'id' in the updates and where is it stored? Section 3.5.3, "Encoding of updates". The problem is that I used "id" here instead of "router-id". > and what does the link cost = cost mean? Confusing because I cannot use italics for variables. Should have been "over a link with cost /cost/". Given the ASCII-only document, "cost" should be renamed to "C". > 3.5.5 describes what is done in 3.5.4, but to little point (imho) I disagree. 3.5.4 says that a retracted route is kept in the route table (the RIB). 3.5.5 says that this retracted route is actually reflected in the forwarding table (the FIB, the kernel routing table) as a blackhole route. One could very well imagine that the retracted route is a purely algorithmic data structure, that needs not be reflected in the forwarding table. > 3.6 'unfeasible route' = ?.. I assumed route table only contains feasible > routes to start with? Last point of 3.5.4 -- an unfeasible update is accepted, and a route table entry is maintained (although it cannot be selected). (You don't want to be discarding a redundant route when it becomes infeasible, since seqno numbers propagate at different speeds over different links -- there's a good chance that it will become feasible within a jiffy or two.) > 3.7.3: 'modified entry'; what if it was not modified? no gc reset? I > assume so.. The GC timer is reset in all cases (except for retractions). This should simply say "the entry" or "the entry under consideration". > 3.8.1.2 .. in response to a _seqno_ request, not route request Right, typo. > cannot parse 'no smaller'; not smaller? I think that's correct, but then I'm not a native speaker. > 3.8.2.1 is there necessarily seqno in the source table for all nodes? > much easier just to use seqno from the route that is being > retracted.. (maybe there is, but shrug) The only place seqnos are kept is the source table (look at the data model). There are no seqnos associated to either nodes or routes. The goal of this procedure is to get a seqno that will make the route feasible. Since feasibility is determined by the source table (Section 3.5.1), it's the seqno in the source table that's relevant. > SHOULD AE 1 or 3 for NH; why not 2? (ok, LL is better I guess..) This just says that the next-hop for an IPv6 prefix should be a link-local address. That's consistent with both RIPng and OSPFv3. -- Juliusz _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
