Minutes IETF109: roll
minutes-109-roll-00

 #        IETF - ROLL IETF 109
Thursday, 19th November 2020 - 9:00-11:00 UTC                            
Thursday Session III Material:
https://datatracker.ietf.org/meeting/109/session/roll

## Bluesheet/Attendees:
* NOT NEEDED, attendance is recorded in Meetecho

**INES has a power outage.**

## Summary of action points
- Pascal and Ines to merge the two repos where ideas/features/requirements for
RFC6550bis are kept [DONE]
  * ROLL WG GitHub repo for this topic is https://github.com/roll-wg/RFC6550bis
  * right after this meeting, Pascal has uploaded his own content to the ROLL
  WG GitHub mentioned above.
- Dominique to provide pointers to prior discussion of DAO-ACK behavior where
it was concluded that Root Ack is needed: IETF103,
https://youtu.be/7cwhMLaddqU?t=3408 [DONE]. More pointers:
  * discussions on ML about interpretation of DAO-ACK behaviour, e.g. as far
  back as 2015
    https://mailarchive.ietf.org/arch/msg/roll/8jf7B4O_SSz575fjv59EMH2xs7g/
  * description of the issues in draft-ietf-roll-rpl-observations, Section 4,
  first published in Sept 2018
    https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-04
  * ROLL session at IET103 meeting (Nov 5, 2018, Bangkok)
    slides:
    https://datatracker.ietf.org/meeting/103/materials/slides-103-roll-roll-ietf103-v2-00.pdf
    minutes: https://datatracker.ietf.org/doc/minutes-103-roll/ Excerpt
    "Pascal: *we could specify a mechanism to get an ACK from the root all the
    way down the DODAG. Could be a new draft. ACTION: new draft on ACK from the
    root?*" Video: (from time 56:45, about 6 mn)
    https://youtu.be/7cwhMLaddqU?t=3408
  * resulting draft
  https://datatracker.ietf.org/doc/draft-jadhav-roll-storing-rootack/ first
  published Apr 2020
- Chairs to organize an interim meeting dedicated to PDAO in-depth discussion
- Participants to study PDAO based on draft and slides/video of this meeting,
before the interim - Chairs to bring discussion of 6550bis/V2 options to the
ML, ask for contributors.

## Agenda (UTC):

9:00 - 9:10am -- Introduction: WG Status (Ines/Dominique)
9:15 - 9:35 --  draft-ietf-roll-dao-projection (Pascal)
9:35 - 9:50 -- draft-ietf-roll-unaware-leaves (Pascal)
9:50 - 10:00 -- draft-ietf-roll-turnon-rfc8138 (Pascal)
10:00 - 10:20-- draft-jadhav-roll-storing-rootack (Rahul)
10:20 - 10:55 -- RFC 65550bis status  (Michael/all)
10:55 - 11:00 -- Open Floor (Everyone)

Ines lost power at her house.
May be on audio channel.

## [09:06] Introduction (Ines/Dominique)

Jabber issue, no connection from/to meetecho until window reload
Chair going through note well, shown on screen
agenda bashing, milestones
AODV-RPL not moving, lack of response from authors to IESG

Milestones presented
Using github issues as tickets
No question from the audience

## [09:15] DAO projection (Pascal)
https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/

Pascal: This provides new operation in RPL, making it capable of SDN-type of
operation. A controller lays out so-called Tracks, which are complex paths
between an ingress node and an egress node. Similar to a tunnel, but can be
multipath. Also, no need for encapsulation in the general case, an RPI is
enough. Kows of one implementation in the works. Not a lot happening on the
mailing list. This draft was originally only about laying out the track, but
later found that a mechanism was missing to provide full topology info to the
root. New Sibling option. Main change is that, now, main DODAG has to be
operated in Non-Storing Mode, which is mode most used, root already has
topology information about DODAG, only element to be added are the siblings.

Other main change in draft: how to signal a track that is not linear sequence
of nodes. Hard to install in one message. Now one 1 P-DAO message installs 1
segment: to put segments together in a Track, bind them together with a Track
ID. Segments can be modified in runtime, without disabling the whole track. 1
pdao message contains 1 list of hops only (VIO or SR-VIO), multiple targets
possible (RTO). Neighbors of egress are reachable over track, they can be
signalled as targets. Thinking about track being bidirectionnal or
unidirectionnal, see discussion later. In summary, track made of multiple
segments correlated through TrackID, need to improve how do we do the
encapsulation and what we signal (egress, ingress, elided?).

topology awareness: still use regular DAOs in Non-Storing Mode, but now also
advertise siblings. May not want to adverstise every sibling, problem of
selecting siblings out of scope. Real deployment may need some intelligence to
do that.

Track id for now is local instance id of a DODAG rooted at the egress. If track
is made bidirectional, will need discussion.

Change in the structure of the PDAO option, to now make sure it is always
compressed. 6LoRH compression mandated. The compression self descriptive, btw
one of the compression modes is "no compression". For Storing Mode, strict
sequence of addresses is required, so that can always forward without a loop.
Loop avoidance was delicate part of the design. That's why strict source
routing is required in Storing Mode.

For NSM, we allowed non-strict, but there needs to be another non-storing mode
path between non-consecutive nodes, track within tracks, something like that.
Not easy, discussion on the ML. In NSM, if RFC8138 is deployed, we want the
optimized format to be used by the root. This way, what you find in this option
is exactly what goes into the data packet header. Encapsulating node never has
to compute compression, just use the already-compressed address. Only Root
computes compression, since RH always comes from the Root. Complexity in only
at the Root.

Should we signal the ingress in this list and should be signal the egress in
this list? If the ingress address is in the list, then the ingress has to
consume the address from the routing header when it forwards the (PDAO) packet.
It is is not in the list, how does the ingress know which address of its
addresses it should use to forward the packet? Important since source address
serves as a reference for the compression.

For different type of compressions (2 bytes, 4 bytes) in the sequence of
addresses, need more than one SRH-6LORH, because SRH-6LoRH defines only one
type of compression.

(slide 6)
Encapsulation rules: if source and destination of data packet are not ingress
and egress of track (not quite exact, to be reworded in the draft). - First
case: want to complement NSM DODAG with SM PDAO along the path, in order to
shorten the source routing header. RPI is always the one of main DODAG. No
encapsulation needed, just forward along the SM PDAO between the loose
source-routed nodes. - Same thing as you forward along segments of the track.
RPI contains TrackID. No encapsulation needed, just want TrackID to be seen as
you forward along the track. In summary, clarification needed in what is needed
to be encapsulated and what is not needed.

When using source routing header (i.e., with NSM PDAO), normally need to
encapsulate to insert header. Would require to encapsulate when forwarding into
segment. But if you do, destination becomes the endpoint of the segment, no
longer track endpoint. Packet no longer signals the track anymore, but the
segment. Acceptable, but might not be what you want. Another way is to "refill"
the routing header. Looks a lot like routing header insertion. To be discussed.
In summary, proposal is that as you forward into next segment, source address
changes, header changes, but no encapsulation, destination stays the track
egress, RPI always from the egress name space.

(slide 7)
Situation shown here is storing mode PDAO, sent from Root to track egress,
forwarded to track ingress along reverse path, ingress sends AKC back to the
Root. Data packet comes from outside the track. Should normally be encapsulated
and header inserted with final destination the track egress, and RPI is this
TrackID. Basic RPL local instance behavior.

(slide 8, see also slide 10)
Now the complex case: non-storing mode, 2 consecutive segments in a 3 hops
loose source routed track. Assume for now intermediate segments are non-storing
(note that P-DAO arrow is wrong direction in drawing). Would need to
encapsulate at ingress of segment, add SRH with final destination LH2 (which
may be egres s or neighbor of egress) and TrackID in name space of LH2. Egress
decapsulates, forwards to LH2. LH2 has non-stronih path to LH3, encapsulates.
Along the segments, you dont recognize the main Track, which is hidden inside
the encapsulation.

Now, what the draft allows to do, subject to discussion, is:
a node that is both end of segment and start of subsequent segment, can remove
outer header and place a new one with same final destination, keeping the RPI,
jsut changing the source and the sequence of hops. This node become source
(hence, this is not header insertion), adds list of hops to LH3, keep final
destination. Last entry is always the same, final destination, RPI always the
same. You don't encapsulate track into track, it's a sort of "reload" of the
routing header. Allows to keep signalling the main track, for QoS or other
processing.

Alvaro: you said last hop in segment can remove header. Have you presented this
at 6man? Pascal: aware of what's going on at 6man, SRV6 discussion about header
insertion. Pascal: first is to have this discussion at ROLL. If group is happy
with re-encapsulation, no need to go to 6man. Pascal: If the group finds that
avoiding re-encapsulation is worth it, then need to go to 6man and find what we
do. Different from what is currently discussed at 6man. Here, between LH1 and
segment egress, the last entry in the routing header is the final destination.
Because we want to signal the track as being the final destination and the RPI
being the RPL instance ID in the namespace of the final destination. Pascal: if
LH2 is itself the egress of the first segment (and not a neighor of the
egress), all the routing header has been consumed but entry for itself, it
consumes it, next entry is final destination. It's loose routing between LH2
and Dest. LH2 removes ecapsulation header and do a new encapsulation header
with LH2 as source, new routing entries, and Dest as the final destination. LH2
was not the final destination, yet still removed routing header and placed a
new one, with LH2 as source. The discussions as 6man about not being able to
track down who inserted the header do not apply here. __We__ know who inserted
it. Alvaro: discussion at 6man was more about removal of headers.
Recommendation is to go and show this to 6man, related to interpretation of
8200, once determined that ROLL wants to do that.

(slide 9)
Now intermediate segments are storing mode.
Intermediate node (called Relay on the slide) receives packet with destination
the final destination and Track the TrackID of final destination. Does not need
to re-encapsulate. Situation is similar to PDAOs used to shorten path within
non-storing mode route, discussed earlier. Relay does not need to change RPI,
no encapsulation, just forwarding. Routing table was populated by  P-DAO2,
instead of P-DAO1, but nothing changed. Need to make sure loops are avoided.
Controller's jobs to avoid them.

Questions brought on the ML
- lifetime unit: could it be made heterogeneous. Discussion on the ML?
- what about making a track bidirectional? complex, because TrackID is
different based on direction, encapsulation with header reload will be
problematic.

Help needed on
- loop avoidance
- maintain reachability of siblings
- ingress/egress identification in RPO

Still a lot of work to be done,
Pascal: requesting chairs to form a stronger team, to get this to completion
MCR: we need a session devoted to this, with diagrams
Pascal: an interim would be good.
MCR: need to review on Youtube to digest all this before we can discuss it.
Pascal: all these features needed to build redundant, multipath DNS-based RPL.

## [09:59] Unaware leaves (Pascal)
https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/
Thanks Alvaro for the many detailed reviews.
Remaining work linked to turnon-rfc8138 and useofRPLinfo: describe re-use of
configuration bits with MOP7. The latter will be the normative place. Clarified
what this draft updates: updates RFC6775, not NPDAO. Update of RPL status is in
this draft. Now in IETF last call.

## [10:01] Turnon RFC8138 (Pascal)
https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/
9 updates through IESG review. Still BK's DISCUSS on MOP7 and flags definition.

Alvaro: BK waiting to see the actual doc where we talk about MOP 7. When he
gets it, we should be OK.

## [10:04] Storing mode RootAck (Rahul)
https://datatracker.ietf.org/doc/draft-jadhav-roll-storing-rootack/
Rahul did not join the meeting, Dominique going through the slides
Alvaro (in chat): why not hold DAO-ACK downwards until DAO-ACK has been
received from upward? MCR: we had this discussion earlier, (exact meeting to be
identified), but concluded that it could not be done this way. Because of
aggregation probably. My code originally did it this way, but I changed it as a
result of the discussion. Pascal: for RFC6550bis, make sure DOA/DAO-ACK
sequence is clarified, it seems this was subject to interpretation in original
6550. Note to be added to repo for 6550bis. Pascal: TODO: merge the two github
repos capturing requirements for 6550bis. Rahul finally joins, close to the end
of the session (time 1:46:45 in Youtube video). * rename dao ack to root ack *
draft updated to explain the K flag aggregation. * RootACK no longer used for
Root to query capability of node, as was the case in previous version.
Capabilities draft specifies own mechanism for querying. * Clarified that for
RUL, 6LR waits for root ack before sending NA to RUL * Dominique (repeating
Alvaro's question): why not cascade DAOs up and DAO ACKs down? * Rahul:
complexity in state, see RPL observations draft
draft-ietf-roll-rpl-observations, Section 4. Could replicate this information
in this draft. Mostly state handling at intermediate drafts. * Dominique: TIO
can list prefixes instead of addresses. Then draft says RootACK to be sent to
address extracted from TIO. What if TIO contains a prefix; not an address? *
Rahul: even if 6LR advertises prefix, should still send address of its
interface in this prefix. Same approach as with DIO. Will clarify this in the
draft. Dominique will raise the point on the ML anyway. * Pascal: Rahul
requested to send full address in DIO, change implemented in unaware leaves
draft (and updates 6550). Prefix send, and also full 128 bit address. * Rahul:
will clarify it in the draft.

## [10:12] RFC6550bis (Michael)

Shooting for Internet Standard.
One thing we could do is drop off of 6550 stuff that was never used, like
secure forms of RPL messages. Internet Standard requires evidence of
interoperability. Not much interop testing done at ROLL, maybe at other
associations or fora? Need to document which parts have actually interoperated,
which haven't. Good to do anyway.

Other thing we can do is RFC6550bis:
1) open up 6550, take the stuff that we use, merge all the new stuff that we
are going to have RFC for into it; and cycle at proposed standard. New document
with everything needed into it. Probably 2-3 years effort, requires 1/3 FTE
(Full Time Equiv) Person time for editing. Think should be done at some point.
In 2021? We could do something else 2) clarify how to use RFC 6550 , as a
"start here" document for RPL: write an overview document to navigate between
6550 and the ones we are now producing. Would clarify parts of RFC6550. v2
would be a profile, a set of items that work together and can expand and do new
things (e.g., with MOP=7), without having new documents have to obsolete prior
stuff.

Carsten (chat): option 2 is the way to go.
Pascal: also a median option, build an Internet Standard (RPLv1) with a few of
the docs (6550, 6553, 6554 and maybe 8138). Then build v2 profile pointing at
the v1 Internet Standard. MCR: you mean roll a few of the docs, cutting out
stuff. Relatively light editing process. Pascal: indeed, a 6550bis, which would
include UseOfRPLInfo. But unaware leaves would probably be left out. To be
discusssed. MCR: as soon as you add any doc, starting the melting pot scenario.
Pascal: then just prune/groom RFC6550, then write v2 profile. MCR: would like
to see interest from industry in this. Doing this would draw our resources,
couldn't do anything else. Pascal: say we just clean up 6550. Not much more
work that writing a document that says don't do this, don't do that. Just edit
in the original document. MCR: would be a better base to build v2 on top MCR:
Alvaro, is it possible to promote Proposed Standard into Internet Standard, say
UnawereLeaves, if interop proven later? MCR: specifically, if unaware leaves
and useofrplinfo become Proposed Standard RFCs, and no clarification needed,
and shown to be interoperable, v2 comes along, can they be promoted into
Internet Standard without changing the documents? Alvaro: not seen that done
before. Usually, there are changes when going Proposed Standard. I've seen
status changes done, but not to Internet Standard. We can try, at worse we need
to recycle an RFC number. Alvaro: you said stuff not used is security stuff.
Explain? MCR: in RFC6550, not well designed, not well explained. Also, in 2010,
asymmetric crypto was too slow, too high power. Today, situation is different,
see lots of cases in routing protocols solvable with technology already there.
I would rip out of 6550 all the symmetric crypto authentication. Alvaro: At
some point, some Sec AD is going to ask what about security? In routing area,
mostly gone away with explaining that if rogue nodes gets in the network, can
do all sort of things, not just on routing. MCR: security threats doc (RFC
7416), and applicability documents explain that. Alvaro: we need a compelling
story to explain why security is fine, either with a security solution or even
without it. Pascal: a lot of sec mechanisms do not depend on the routing
protocol. Establish RATS, ANIMA and deploy RPL above it. Pascal: tying security
into the routing protocol would slow down evolution MCR: tying security into
DAOs was to avoid a node announcing address it is not responsible for. Pascal:
8928, proof of ownership at 6lo. In unaware leaves, transporting that proof in
DIOs. MCR: need for a secure DAO. The 0x8x RPL messages (secured vesion) did
not get it right, and no one has implemented them. Could do a better job if we
started over. Question is what level of security do we want. Pascal: to prove
ownership of address, then create new draft with ROVR used in DAO. This would
be new behaviour compared to secure version of DAO in 6550, which is equivalent
to L2 security. MCR: indeed, right now, only relying on L2 security. Point of
secure DAO was to validate the announcement at a higher layer. Needed if RPL
network is "open", some nodes "less trusted". Pascal: have we decided what we
want to do? Just the RPL-v2 profile or first fix 6550 and then the v2 profile?
Ines (chat): bring it to the mailing list. MCR: need to figure what our
resources are. This (v2 profile?) is smallest document (among various
options?), but can't really start until we have the other things at least in WG
Last Call. MCR: need to figure out who is willing to write that document. Ines
(chat): describe the options, with pros and cons on the mailing list.
Dominique: can we narrow down the options now in order to reduce editorial work
to present the options on the ML? Is big melting pot out? Pascal: to ease
discussion, give names to things. Pascal: For example, a 6550bis is not adding
much stuff, only fixing stuff to get to Internet Standard. Pascal: The big
melting pot is RPLv2, adding new functionnality. Pascal: many examples of RFC
xxxxbis, they dont bring new stuff, they fix. OTOH, OSPFv2 brings new stuff.
Dominique: let's talk about the v2 option, the big melting pot. Do we have
resources, volunteers? Or can we just rule it out? MCR: at some point, we're
going to need to do this, but maybe not for a long time. We may discover that
somebody has interest and time, funding, but seems unlikely. Pascal: willing to
do the 6550 cleanup. MCR: get the xml from the RFC Editors, always useful
whichever way we go. Dominique: we'll bring it to the ML, describe the options
and see who's willing and available. Pascal: useofrplinfo is already a bug fix
for 6550, should be poured into 6550bis. Makes sense? MCR: gor going to
Internet Standard. Maybe only some pieces, the beginning. Agreed that 6550 is
not complete. Pascal: can we normatively reference it? Downref? MCR: the
example can be informally referenced. But the rules, clarified in the first few
pages, should be rolled in. Pascal: also need to clarify if 0x23 is the only
value used. MCR: worked on 8415, which obsoleted a bunch of docs. It's an
example of the melting pot activity. Took 4 years to do. Dominique: discussion
to be carried on the ML.

## [10:41] Open Floor (all)

## [10:46] Storing mode RootAck
Rahul joins meeting.
We jump back to Storing Mode RootAck.
Notes captured above, associated with first presentation of Storing Mode
RootAck [10:04]

## [10:57] Meeting adjourns