Subject: [babel] RFC 6126bis

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 07 Jul 2017 12:33:38 +0200

Dear all,

There've been some important changes to rfc6126bis in recent weeks, and
I'm not entirely comfortable with some of them.  I'll be very grateful for
reviewing.

1. Mandatory bits.  We've got two implementations, we've got two
   extensions that use them.  They're a good idea, I think they're fine.
   Please review paragraph 4.4.  I still need to write a IANA Considerations
   section.

2. Unicast hellos.  David has done some good work writing up the spec, and
   I've done my best to integrate his work stylistically into the
   document.  The text is much improved, but I'm still not comfortable
   with them.

   In particular: we've got no convincing use cases.  Plus, we're not
   entirely consistent about what is mandatory here: sending periodic
   Multicast Hellos is a mere SHOULD, parsing both kinds of Hellos is
   a MUST, but actually using both kinds of Hellos is not mandatory.
   Check the latest revision of Appendix A.2.2 for discussion.

   I also thing that Appendix A.4 should go.

3. Chouasne's algorithm, Paragraph 3.5.5.  This seems like a good idea,
   but we've got no implementation.

4. Revision to route acquisition.  I now understand more about feasibility
   than I did in 2011, so I've relaxed the conditions on unfeasible
   updates.  I'm realising that we could simplify the spec by removing the
   notion of feasible update (only routes can be feasible), but that would
   make implementations that follow RFC 6126 no longer compliant.  I'm
   going to revise the sample implementation ASAP.

   Please review carefully paragraphs 3.5.4 and 3.5.5.

I'm uncomfortable with going into last call.  I'll be arriving to Prague
on Friday 14th, but I have plans for Saturday.  Please drop me a mail if
you want to meet on Sunday or Monday morning.

-- Juliusz

---

From: "Russ White" <[email-masked]>
Date: Mon, 17 Jul 2017 05:51:07 -0400

>    Please review paragraph 4.4.  I still need to write a IANA Considerations

4.4 looks fine to me, particularly the last paragraph.

>    Check the latest revision of Appendix A.2.2 for discussion.

My question always goes back to this -- I don't know why the receiver needs to treat a unicast and multicast hello differently -- I probably missed some discussion here, it might be good (for my brain, anyway), to chat in Prague (I see you sitting just behind me now 😊 ). Maybe we are making this too hard?

>    I also thing that Appendix A.4 should go.

+1

>    but we've got no implementation.

I think so as well.  I wouldn't be _too_ worried about the implementation bit for right now. We can try to get this pushed into FRR at some point, but let's leave that problem for right now.

>    Please review carefully paragraphs 3.5.4 and 3.5.5.

These seem fine to me.

I'm happy to go to last call.

😊

Russ

---

From: Matthieu Boutier <[email-masked]>
Date: Mon, 17 Jul 2017 17:04:39 +0200

> I think so as well.  I wouldn't be _too_ worried about the implementation bit for right now. We can try to get this pushed into FRR at some point, but let's leave that problem for right now.

I've got an implementation (based on babeld) !  Tested (a little bit).  It
works quite well, but look at the following scenario :

     A
  1 / \ 1000
   /   \
  B     C
   \   /
  1 \ / 1
     D

Initially, the cost between A and C is important, so C has a route to A
via D, D via B, and finally B directly to A.  Then, A fails, so both B
and C can't reach A.

 1. B retracts its routes, it requests to its neighbours (A and D) an
    acknowledgement.

 2. D acks B's retraction, and do the same (retracts and requests ack)

*3. B receives the ack, A is remaining.
    B and C acks D's retraction.
    C retracts and requests ack.

 4. D receives B and C's acks.  It removes its unreachable route.
    D acks C's retraction.

*5. C receives D's retraction, but wait for A.

One thing is clear: B was using the A's route, so A will not use its route
and there is no reason to wait its acknowledgement.  Fine.  Implemented,
it works.  This gives:

 1. B retracts its routes, it requests to its neighbours (D only) an
    acknowledgement.

 2. D acks B's retraction, and do the same (retracts and requests ack to
      C only.)

 3. B receives the ack.  It removes its unreachable route.
    C acks D's retraction.
*   C retracts and requests ack to A, waiting until the route expires.

 4. D receives C's acks.  It removes its unreachable route.

So the question here is: could we consider that if a neighbour becomes
unreachable we can stop waiting for its acknowledgement ?

Matthieu

---

From: "Gwendoline Chouasne" <[email-masked]>
Date: Mon, 17 Jul 2017 17:24:03 +0200

> unreachable we can stop waiting for its acknowledgement ?

Can't you just ask for acknowledgments from all your neighbours but the
next-hop of the route that has been retracted, since it has already
retracted the route?

>> I think so as well.  I wouldn't be _too_ worried about the
>> implementation bit for right now. We can try to get this pushed into FRR
>> at some point, but let's leave that problem for right now.
>

---

From: "Gwendoline Chouasne" <[email-masked]>
Date: Mon, 17 Jul 2017 17:43:02 +0200

Sorry, I only just realized that your question was for the general case
(that is, the unreachable node is not the next-hop of the route)

Well, I'd say no, because you can't be sure that a the timeout time of the
routes is less than the timeout time for a node to be declared
unreachable.

But I'm not sure how nodes are declared unreachable.

Suppose you have this:

A----B----C---D

Say you're B, and you have a route R for prefix P through a node A.
Suppose that C uses this route through you.
Say the link to your other neighbour C is down for 5 seconds, and you
declare C unreachable.
Now you get a retractation from A for R. You send a retractation to all
your neighbours but don't wait for C's acknowledgement.
Then the link comes back up, and C still uses the route R through you.
At the same time, C learns a route to a less specific prefix P' through D,
and you learn it.

Now, for a packet matching both P and P', C will send it to you, and you
to C (until C times out the route R)