[Roll] direction of draft-robles-roll-useofrplinfo

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 04 July 2015 21:23 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1A16B1A1A31 for <roll@ietfa.amsl.com>; Sat, 4 Jul 2015 14:23:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9os5aoPhGb4v for <roll@ietfa.amsl.com>; Sat, 4 Jul 2015 14:23:10 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BE91A1A2C for <roll@ietf.org>; Sat, 4 Jul 2015 14:23:09 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A65920012 for <roll@ietf.org>; Sat, 4 Jul 2015 17:38:54 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id D022063B10; Sat, 4 Jul 2015 17:23:07 -0400 (EDT)
Received: from sandelman.ca (localhost []) by sandelman.ca (Postfix) with ESMTP id B0E6D63AE8 for <roll@ietf.org>; Sat, 4 Jul 2015 17:23:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Sat, 04 Jul 2015 17:23:07 -0400
Message-ID: <11261.1436044987@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/uTlkmrkPt1fJ_QK4G2OfzYBCyVg>
Subject: [Roll] direction of draft-robles-roll-useofrplinfo
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Jul 2015 21:23:12 -0000

You will recall that the ROLL WG was rechartered back in March to include two
new work items:

Work Items:
- Details about when to use RFC6553, RFC6554, and IPv6-in-IPv6 encapsulation.
- Details about how to compress RFC6553, RFC6554, and IP headers in the
  6LoWPAN adaptation layer context
  (from https://datatracker.ietf.org/wg/roll/charter/ )

Noting a certain lack of enthusiasm to get item one started, yet knowing that we
need to get it very clear, Ines and I wrote draft-robles-roll-useof-rplinfo.

The document is now at:
        (you can comment)
    https://github.com/ietf-roll/useofrplinfo (fork it and send pull request)

We anticipate asking the WG to adopt it; we would also like to have help
editing this document, but regardless we should diverge slightly to talk
about conflicts.  As both of your WG chairs are authors, on the advice of
a routing AD, we will be seeking another party to judge consensus, and we
will also need a document shepherd.

Now about, the document, from the table of contents:

  3.  Sample/reference topology
  4.  Example flow from leaf to root  . .
  5.  Example flow from leaf to Internet
  6.  Example flow from leaf to leaf  . .
  7.  Example flow from Internet to leaf
  8.  Example flow from root to leaf  . .

The first thing is that I think we will adopt the numbering for the nodes
that Pascal's document had.

The purpose of having these example flows is to make precise what node
inserts what header, where the headers are removed (and potentially
re-added), and what headers are either modified or untouched during the flow.

Pessimistically, we need all the various headers (RPI, RH3 and IPIP) on every
packet, but actually, that may not always be true.  Getting the rules well
established is important if we are going to be able to compress things well.

Additionally, each flow has potential changes between storing and non-storing

  1) Are the situations where it is okay for RPI information to flow out to
     the Internet?  For instance, in an P2MP situation (such as AMI) where
     the collection point is RPL aware, could we drop the IPIP header
     (5. example), given that the leaf node will insert the RPI, and on
     upwards flows we do not need RH3 headers (for both storing and

  2) Are there situations, such as leaf to leaf in a non-storing situation,
     where the originating leaf can avoid an IPIP header having to be
     inserted by the Root, by inserting the RH3 header (empty) itself?

     i.e. set Segments Left = 0, but reserve space for them using the ext
     header len.  Then the root could fill them in.

  3) Are there additional situations in which we can or should dispense with
     one or more of these headers?

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/