Re: [Roll] 6LoRH type in useofRPLinfo
Alvaro Retana <aretana.ietf@gmail.com> Wed, 03 July 2019 21:58 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96F0120173; Wed, 3 Jul 2019 14:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Level:
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-qrI5jVJ2b0; Wed, 3 Jul 2019 14:58:40 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550EF12016D; Wed, 3 Jul 2019 14:58:40 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id i11so3534029edq.0; Wed, 03 Jul 2019 14:58:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=AS280MyNq+5Fhz3Yf6nKT5tY7qEsvHM+4waDWCno8f0=; b=exBj3wloQqowTI8DRRZDZ9K75anzF06T2CdEnfSYVRDV0wnXS2CE7Ie9YoJda8aZFw VlT6j0QmlsiMP9uJDwPtrNujn/LJbBQZY5YP9EZUk+xSGe292tgFW/nl7bDDvahuekUy Yv2oNrakH/hgRHM78Ne01gvtmmE0aH3NbJFXI3OjuyLDPPhBFz5oMaFTcafYdJsXy4SE OLGcB2Y+MrcN5g5YDrZRjKsN3tb907ZN3JEzaJGgVtzrX3HmqpWJHfOoFQDugR1Rxb22 AjCf+QGuW1q3WEsYNKxuhLuRgyRQKbX1Ks61KFJDc/6aSt4i6pzo5ql+WEWY42YTGWqP PIZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=AS280MyNq+5Fhz3Yf6nKT5tY7qEsvHM+4waDWCno8f0=; b=OjgbMQyiGOcV6wA8Nk6v1muJH8DtdaFXtUxJlZAJq45EK5H/1VZ3Jy6dAVhyuM7xSr Gps0NxtMOYbFo1A/qy5wRsfmL3QMhBRHsMbmuyUPWrL++Uu03Jh+PGAXBb1LSPmUI8zm ZXXSLHTo6HCMcGEvofD3a1dtvXUBmsQ9mRARYpRqLA4DPQbT5VskmIA2FyKGZU42AilX ykADCHVeDN7r9bKzMoOot1twzcmCJjWoZvMxluUK2jHFUqkLjbgRL7tMe6EReDL5BU5X hEM5F2XB+HmNC7lC7PRiFTk36db8qKCW+VeeewIffqv9EbzbR1KvYdtRtHv1Q7qknnUo 3k/g==
X-Gm-Message-State: APjAAAUtKxImMcSl9dcKKnJ6ZPsp3QysBuZzgAK/M/lygfo++e2V8uha 7tgb5qbScoVlV1sNRRE1BnX0vpSWHZuTHHZ4BIgAVA==
X-Google-Smtp-Source: APXvYqwQ1aLdy/I/TS44QxRgEn7gleIX7QLll5P2vkSdgCB+69gB1wRC4tkrwhJi/jbqaR9WXDk21ebVuNGns3GL4dY=
X-Received: by 2002:a17:906:24c1:: with SMTP id f1mr16647675ejb.285.1562191118891; Wed, 03 Jul 2019 14:58:38 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 3 Jul 2019 14:58:38 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <MN2PR11MB3565F5ED23571E3C9A6394B9D8F80@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB35652590F29701C0F9097C1FD8F80@MN2PR11MB3565.namprd11.prod.outlook.com> <MN2PR11MB3565F5ED23571E3C9A6394B9D8F80@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Wed, 03 Jul 2019 14:58:38 -0700
Message-ID: <CAMMESswsF59pv3ydz64KQEz=-boZf1Tx=iBW7vybd-HbifMEMw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, draft-ietf-roll-useofrplinfo@ietf.org, Peter van der Stok <consultancy@vanderstok.org>, roll-chairs <roll-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b68026058ccdf62c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/CQADQeJ410XfnVHF7prPSg751n4>
Subject: Re: [Roll] 6LoRH type in useofRPLinfo
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 03 Jul 2019 21:58:45 -0000
Pascal: We’re already at version -30. Please take a look at the text there — the figure in the corresponding section (§4.3) now looks like this: +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... |11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP |Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld +-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+... Is that correct? If not, please provide an update. I am getting ready to approve this document. I am changing the state to “Revised-ID Needed” — let me know if a change is not needed. Thanks! Alvaro. On July 2, 2019 at 10:14:53 AM, Pascal Thubert (pthubert) ( pthubert@cisco.com) wrote: Dear all Actually since there is only one entry in the SRH the drawing in fig 20 of RFC 8138 must be adapted for a size of 0 (meaning 1 entry) and a total length of 4 octets. +-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... |11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld +-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-... <-4bytes-> <- RFC 6282 <https://tools.ietf.org/html/rfc6282> -> No RPL artifact All the best, Pascal *From:* Pascal Thubert (pthubert) *Sent:* mardi 2 juillet 2019 16:07 *To:* 'Routing Over Low power and Lossy networks' <roll@ietf.org> *Subject:* 6LoRH type in useofRPLinfo Dear all Reviewing again https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-25 I think we made a mistake in Fig 3: The format of RFC 8138 compressed packet is presented as: +--+-----+---+--------------+-----------+-----------+-----------+ |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI-6LoRH |LOWPAN IPHC| +--+-----+---+--------------+-----------+-----------+-----------+ But it should really be as fig 20 in RFC 8138, meaning the RPI is before the IP-in-IP: +-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-... |11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP |Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld +-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-... <-8bytes-> <- RFC 6282 <https://tools.ietf.org/html/rfc6282> -> No RPL artifact Figure 20: Example Compressed Packet with SRH Data is removed from the left as consumed. Removing the IP-in-IP removes everything left of it including RPI. What gets forwarded to the unaware leaf starts at the LOWPAN_IPHC. What’s worth noting is that in Storing Mode the SRH contains the address of the 6LR that decapsulates. IOW the SRH encodes the destination of IP-in-IP, whereas the root is the source so the encapsulator in the IP-in-IP 6LoRH is elided… All the best, Pascal _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
- [Roll] 6LoRH type in useofRPLinfo Pascal Thubert (pthubert)
- Re: [Roll] 6LoRH type in useofRPLinfo Pascal Thubert (pthubert)
- Re: [Roll] 6LoRH type in useofRPLinfo Alvaro Retana
- Re: [Roll] 6LoRH type in useofRPLinfo Ines Robles