Re: [Anima] draft-ietf-anima-autonomic-control-plane-06

[Michael Richardson <[e-mail]>]

Toerless Eckert <[e-mail]> wrote:
    > I may be wrong, but it looks to me as if MichaelRs comments and reference to
    > this new draft about RPL IPinIP header stuff makes it sound as if we MUST
    > somehow support these IPinIP headers in ACP:

It's an argument that we have to have in the ACP document.
Yes, we can get away without the RPI header.  I'm not happy about it, but I
can live with it.  I'd like to be tolerant of including them, however.
RFC2460bis text lets us clearly state this, and the useofrplinfo revised
document will, I think make it clearly ignorable.

    > Also, during the last IETF, i think MichaelR said something to the extend that
    > the "profile" defined for RPL via the latest -06 version should rather go into
    > some form of RPL profile draft.... But if i remember correctly, Pascal told me
    > there is no such "RPPL profile" draft format.

Not at all. The RPL profile template is at:
    https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-template/
    (yes, it's expired, never to be published)

    https://datatracker.ietf.org/doc/rfc7733/ (section 4)
    https://datatracker.ietf.org/doc/rfc8036/ (section 7)

are examples of the RPL profile.

    > This is something i would prefer as the mandatory minimum ACP requirements
    > because i am fearful of asking all type of equipment to support RPL routing
    > protocol specific IPinIP header processing. I am not even sure if i could
    > today expect to get this IPinIP header processing in all linux that i
    > might

At present RPI is not supported in current Linux kernels, but there are
people working on it.  RPI headers are produced by OpenWSN and Contiki
implementations now.

    > Not using IPinIP headers does of course come at the limitation of  - if i
    > understand it correctly - a single instance with a single (active) root.
    > As long as we can have automatic root election so that we have root redundancy,
    > i think this is a sufficient minimum functionality for ACP.

There is always one root per instance, RPI lets you have multiple instances.
RPI provides for loop detection (and the resulting: fast repair) which I think
that we actually rather need if we expect this to be used for critical function.

If we aren't going to depend RPI,  we'll need to carefully tweak the RPL
parameters so that we get frequent enough announcements.  We may be able to
leverage the IPsec DPD messages to detect link down's and do reparent events
though.  That should be easily written up in the ACP document.

    > - It seems to be easy to make IPinIP support SHOULD for endpoints. Such an
    > endpoint could only use the default instance/root of RPL. Right ?

Yes.

    > - It is less clear to me if/how its possible to introduce partial support
    > for IPinIP on transit nodes. I am hping that RPL can automatically
    > figure out that additional instances/dodags can only work across paths
    > where all transit nodes support IPinIP. Then the problem is solved.
    > If this si something RPL can not singnal, then it seems as if a
    > transit node without IPinIP support would kill non-default instance/transit
    > paths.

We have to do this globally, I think, we will need to define a signal for
this, and we have to put this into the DIO.  I think this will be generally
useful for RPL.  Probably it deserves a seperate draft, but let's start it
in the ACP document first.

    > - I am very interested to make non IPinIP capable transit nodes sufficient
    > for MUST ACP requirements because i am quite sure that a relevant part of
    > HW accelerated forwarding engines will not support IPinIP routing, so any
    > mandatory introduction of IPinIP would kill HW acceleration for ACP. Which IMHO
    > would make me ask to rethink the choice of ACP default routing
    > protocol.

I agree.
Note that the worst situation of IPinIP is that the header has to be added
and removed at each hop, and the outer IP is a link-local address.  Inside
the IPsec tunnel, it probably looks like:

   IPll ESP RPI IP ULP

With the IPll ESP RPI part being added/removed at each hop.  Based upon 20
years of building drivers for hardware acceleration, I don't think that this
will matter much to HW accel.

    > Q1: Do we agree on this direction ?

    > Q2: How can we finalize the sufficient/necessary text mods to ACP to express
    > this ? (profile definition etc..)

We need to convene an ACP design team call.

I don't think that we can get to that until the voucher and brski and grasp
documents are into WGLC.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-