Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
Michael Richardson <mcr+ietf@sandelman.ca> Mon, 16 March 2020 18:43 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 1F7303A0F17 for <roll@ietfa.amsl.com>; Mon, 16 Mar 2020 11:43:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 PVdJZ_1ys0GE for <roll@ietfa.amsl.com>; Mon, 16 Mar 2020 11:43:50 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0003A0EF6 for <roll@ietf.org>; Mon, 16 Mar 2020 11:43:49 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 312853897C; Mon, 16 Mar 2020 14:42:26 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32F9054E; Mon, 16 Mar 2020 14:43:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, roll@ietf.org
In-Reply-To: <3A00F2FF-C119-496C-BC53-87DBD6C375B4@cisco.com>
References: <158410288420.3321.7400803802055697408@ietfa.amsl.com>, <23773.1584304056@localhost> <3A00F2FF-C119-496C-BC53-87DBD6C375B4@cisco.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
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-sha256"; protocol="application/pgp-signature"
Date: Mon, 16 Mar 2020 14:43:43 -0400
Message-ID: <9766.1584384223@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/mk9xaVVRj1leLctM10yV2wGukMk>
Subject: Re: [Roll] New Version Notification for draft-ietf-roll-unaware-leaves-11.txt
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: Mon, 16 Mar 2020 18:44:07 -0000
Following up publically, as an author re-read from the beginning. Pascal has carried this document very far since it was started last summer, and I've been rather out of the loop due to other commitments. My intense thanks to Pascal for this. My changes are at: https://github.com/roll-wg/roll-unaware-leaves/pull/1 Pascal Thubert (pthubert) <pthubert@cisco.com> wrote: > Actually Michael it would be real great if you could reread unaware > leaves. I asked the chairs to make the last call. I believe it’s ready > now and as you know it blocks cluster c310. Yeah, I know. I wish we had used markdown :-) 1) I notice the Abstract is a single complex sentence. I think we should split it up somehow. I will think on this after reading it all through. 2) I have a bunch of typos/missing words that I'll commit directly to github. 3) Should we say: A RUL is a plain <xref target="RFC8504" /> Host that needs a RPL-Aware Router to obtain routing services over the RPL network. that is, insert RFC8504 here? Or should we actually say RFC8504/RFC8505, because we depend upon EARO? I'd like to get Carsten to review this actually, as we are really updating what it means to be a "Host" on a constrained network. How can we split this up into three sentences: This specification leverages the Address Registration mechanism defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to request that the 6LR injects the relevant routing information for the Registered Address in the RPL domain on its behalf. I think that this paragraph (3.2.1) should get turned into part of the abstract: This document specifies how the "R" flag is used in the context of RPL. A 6LN is a RUL that requires reachability services for an IPv6 address iff it sets the "R" flag in the EARO used to register the address to a RPL router. Conversely, this document specifies the behavior of a RPL Router acting as 6LR depending on the setting of the "R" flag in the EARO. The RPL Router generates a DAO message for the Registered Address upon an NS(EARO) iff the "R" flag is set. I wonder if the word "Conversely," is needed. Maybe: A 6LN is a RUL that requires reachability services for an IPv6 address. It sets the "R" flag in the EARO in order to register the address to a RPL router. This is described in RFC8505. This document specifies the behavior of a RPL Router that processes EARO messages that have the the "R" flag set in the EARO. Not sure if this is abstract content, but I like the above. You really like the word "Conversely" :-) I am concerned that there is so much repeating of 8505, that this will confuse some reviewers. I guess we do Update 8505, but maybe we should hit them a bit harder on the head that they need to understand it first. section 4: I keep wondering if we haven't created a new Storing-Mode MOP here, that should get a new MOP value (or mopex) value. But, I see that 6.3.1. contains the compromise text we worked out at IETF106. let me think: a storing root that does not set the P bit (because it does not support this functionality) will cause 6LR that support this to not support RUL processing, and not support RULs. Should such 6LRs also essentially not do RAs in that context? Does this also enable RFC8505/EARO processing? I find section 4 really dense, and I wonder if it wouldn't be better to move sections 4 and 5 later in the document, so that we are referring back. I'm not sure here. section 6.1: In order to obtain routing services from a 6LR, a RUL MUST implement [RFC8505] and set the "R" flag in the EARO option. The RUL MUST NOT request routing services from a 6LR unless the 6LR originates RA messages with a CIO that has the L, P and E flags are all set as discussed in Section 3.3.1. -> I think that rather than have MUST NOT, which I think does not lead to good interop failure results, I suggest we write: A RUL that receives a CIO from a potential (6LR) router that has the L, P and E flags set, SHOULD set the "R" flag in the EARO in order to request routing services from that 6LR. A RUL that has multiple potential routers SHOULD prefer the router that can provide the desired routing services. If there are no available routers, the connection of the RUL fails. (XXX- Can the RUL use the EARO process in the absence of L/P/E to signal the error? I think that deployment of 8505 without this document is a very small window, so this won't work in general) ... The RUL MUST register to all the 6LRs from which it requests routing services. section 6.2: A 6LR that is upgraded to act as a border router for external routes advertises them using Non-Storing Mode DAO messages that are unicast directly to the Root, even if the DODAG is operated in Storing Mode. yes, but it should only request them from routers which support R, right? The RPL data packets always carry a Hop-by-Hop Header to transport a RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates its packets with an RPI, the 6LR needs to tunnel them to the Root to add the RPI. As a rule of a thumb and except {FOR} the very special case above, the packets from and to a RUL are always encapsulated using an IP-in-IP tunnel between the Root and the 6LR that serves the RUL. I think that this should reference [UseOfRPLinfo] section 7.1.4, section 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, 8.2.3, 8.2.4, 8.3.3 and 8.3.4. section 9.1: In a same fashion, if an additional routing protocol is deployed on a same network, that additional routing protocol may need to handle the keep alive procedure for the addresses that it serves. I believe that this might scare our routing colleagues into thinking that we intend to deploy things in parallel on LLNs. Do we need to say this at all? (I understand that you are just expressing an outward requirement on anyone that wants to do this. Maybe we can put this in a section of it's own so that someone can point to it in the future? Quite reasonable, someone could attach a non-constrained wired network on the edge of an LLN, and run OSPFv3 or something there. But there would be no overlap with the LLN) section 9.1.1, I think that the column that says "6LN" should say "RUL" instead. Yes, 6LN is not wrong, but I think it's not helpful. Do we need to say something about LLNs which do not have a 6LBR? Or is this degenerate case self-evident? section 9.2.1: "By the 6LN" -> "By the RPL unaware 6LN"? * The 6LN can register to more than one 6LR at the same time. In that case, it MUST use the same value of TID for all of the parallel Address Registrations. I'd like to motivate this statement, I think it should reference RFC8505 section 5.2. Just so that no part of this process is "new" > Even without support for RPL, a RUL may be aware of opaque values to be > provided to the routing protocol. If the RUL has a knowledge of the RPL I just looked to see if we return RPLInstanceID in CoJP, and we don't :-( Someone could write a document in RPL to add that. > A RUL that places an > RPI in a data packet MUST indicate the RPLInstanceID that corresponds > to the RPL Instance the packet should be injected into. All the > flags and the Rank field are set to zero as specified by section 11.2 > of [RFC6550]. It has never been clear to me how much security isolation RPLInstanceID should have. Is it as strong as 802.1Q VLAN tags? Or is much softer, just a bit more interesting than IPv6 Flow? If it's intended to be as strong as VLAN tags, then there is an admission control control that the 6LR must do. > Extended Duplicate Address > messages with the 6LBR is avoided if the RPL Root has indicated that > it proxies for it. I'm misplaced how the RPL root has indicated this. Is it in the DAO-ACK? 9.2.2: > * RPL Non-Storing Mode is used, and the 6LR indicates one of its > global or unique-local IPv6 unicast addresses as the Parent > Address in the associated RPL Transit Information Option (TIO). I think that this is an instruction that RPL Non-Storing mode is TO BE used, (not a conditional sentence). I suggest we number these points so that implementers can argue about them better, and make them all more declarative. There is a commented out sentence in the XML, which I think we can remove. I understand the use of "iff" throughout, but I'm not sure others will notice it as other than a typo of "if". I turned the next paragraph into a numbered point, but maybe the trailing ';' now does not work. I'm not sure that the reverse direction provides anything useful. Opinions? Should the rest of the If/In case be changed to a section on 6LR processing of DAO-ACK, and a section on processing of DCO? Right now processing is described by each role. I'm for that, but I think we should split it up as well by message. Is section 12 RFC6550 multicast actually implemented by anyone? Given MPL, I didn't think you needed both, but maybe I don't understand multicast. Section 12 RFC6550 would have been something I would have removed for 6550bis, so I wonder if we should be doing anything with it. section 12.3, I think that instead of reducing the size of the Flags field, I suggest that we say that we are allocating 4 bits of the Flag field as the ROVRsize. (I found it really confusing to figure out btw) ---- I wish I had time to implement this in unstrung and the Linux kernel. :-( I need to clone myself. -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification for draft-iet… Michael Richardson
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)
- Re: [Roll] New Version Notification for draft-iet… Pascal Thubert (pthubert)