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

[Toerless Eckert <[e-mail]>]

Thanks, Michael. Inline.

On Wed, Jun 07, 2017 at 06:21:45PM -0400, Michael Richardson wrote:
> 
> 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.

Great. I thought in Chicago you said you would volunteer converting the current section
about Roll profile in ACP spec into that format. Is that offer still valid ?

>     > 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.

I hope i am restating Pascals argument correctly that the RPI based repair is
only needed when you do want to be lazy on DAO state maintenance. Given
how our profile asks for aggressive starte maintenance, tht should be sufficient
(as it is on any other routing protocols).

> 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.

Good point. I guess thats details that would go beyond RPL profile.
Text suggestions welcome, otherwise i'll try to make up something.

>     > - 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.

Like with the GRASP discuss in the last email, i would like to see that we
keep the option of pushing out difficult, longer-term stuff stuff into
separate drafts to finally close on some ANI Minimum-to-implement option.

Btw: I am very interested to have some more high-available ACP option, but
that would be even more work, eg: Something like MRT support with RPL.
Maybe we can discuss in Prague..

>     > - 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.

Well... If i look at the routing requirements that i see:
  - ability to have different NOCs are separate roots
  - ability to have MRTs

I think i could easier resolve those requirements with (S/M,D) based
forwarding entries than with IPinIP header fields to specify an instance.
But i guess that such approaches would be novel for RPL and (see above)
therefore require more work.

>     > 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.

Sure.

Cheers
    Toerless

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